From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Gil Fine <gil.fine@intel.com>
Cc: andreas.noever@gmail.com, michael.jamet@intel.com,
YehezkelShB@gmail.com, linux-usb@vger.kernel.org,
lukas@wunner.de
Subject: Re: [PATCH v4 0/6] thunderbolt: CL1 support for USB4 and Titan Ridge
Date: Mon, 6 Jun 2022 12:27:55 +0300 [thread overview]
Message-ID: <Yp3Imyq6Lny7DwvO@lahna> (raw)
In-Reply-To: <20220526105921.17214-1-gil.fine@intel.com>
Hi Gil,
On Thu, May 26, 2022 at 01:59:15PM +0300, Gil Fine wrote:
> v1 can be found here:
> https://lore.kernel.org/linux-usb/20220501203321.19021-1-gil.fine@intel.com/
> v2 can be found here:
> https://lore.kernel.org/linux-usb/20220509201656.502-1-gil.fine@intel.com/
> v3 can be found here:
> https://lore.kernel.org/linux-usb/20220511140549.10571-1-gil.fine@intel.com/
>
> Changes in v4:
> * Remove unnecessary struct tb_sw_tmu_config and fix some typos.
> * device_for_each_child() move from tb.c to tmu.c
> inside tb_switch_enable_tmu_1st_child().
>
> Changes in v3:
> * Fix to support the case of enabling CL1 entry after resume
> from runtime PM (if CL1 supported in the connected device)
>
> Changes in v2:
> * Handle CL1 and CL0s together since on the hardware level they are
> supported and enabled together
> * Use device_for_each_child() to set TMU mode of host router's 1st
> children
> * Use FIELD_x macros from include/linux/bitfield.h
> * Split single patch into two for clarity
> * Fix commit message
>
> In this series of patches, first, we address several issues in the CL0s
> implementation.
> Then, we add support for a second low power state of the
> link: CL1. Low power states (called collectively CLx) are used to reduce
> transmitter and receiver power when a high-speed lane is idle.
> We enable it, if both sides of the link support it, and only for the
> first hop router (i.e. the first device that connected to the
> host router). This is needed for better thermal management.
> CL1 improves power management that was intoduced by CL0s.
> Also, we add support of dynamic change of TMU mode to HiFi uni-directional
> once DisplayPort tunnel is created.
> This enables CL0s while DP tunnel exists.
> Due to Intel hardware limitation, once we changed the TMU mode to HiFi
> uni-directional (when DP tunnel exists), we don't change TMU mode back
> to normal uni-directional, even if DP tunnel is torn down later.
> Though, after sleep (or runtime PM) resume, the TMU is changed to normal
> uni-directional (if CLx supported in the connected device) to enable
> CL1 entry.
>
> Gil Fine (6):
> thunderbolt: Silently ignore CLx enabling in case CLx is not supported
> thunderbolt: CLx disable before system suspend only if previously
> enabled
> thunderbolt: Fix typos in CLx enabling
> thunderbolt: Change downstream router's TMU rate in both TMU uni/bidir
> mode
> thunderbolt: Add CL1 support for USB4 and Titan Ridge routers
> thunderbolt: Change TMU mode to HiFi uni-directional once DisplayPort
> tunneled
All applied to thunderbolt.git/next, thanks!
I changed "Unknown" to "unknown" in tb_switch_clx_name() to be
consistent with the rest of the driver.
prev parent reply other threads:[~2022-06-06 9:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 10:59 [PATCH v4 0/6] thunderbolt: CL1 support for USB4 and Titan Ridge Gil Fine
2022-05-26 10:59 ` [PATCH v4 1/6] thunderbolt: Silently ignore CLx enabling in case CLx is not supported Gil Fine
2022-05-26 10:59 ` [PATCH v4 2/6] thunderbolt: CLx disable before system suspend only if previously enabled Gil Fine
2022-05-26 10:59 ` [PATCH v4 3/6] thunderbolt: Fix typos in CLx enabling Gil Fine
2022-05-26 10:59 ` [PATCH v4 4/6] thunderbolt: Change downstream router's TMU rate in both TMU uni/bidir mode Gil Fine
2022-05-26 10:59 ` [PATCH v4 5/6] thunderbolt: Add CL1 support for USB4 and Titan Ridge routers Gil Fine
2022-05-26 10:59 ` [PATCH v4 6/6] thunderbolt: Change TMU mode to HiFi uni-directional once DisplayPort tunneled Gil Fine
2022-06-06 9:27 ` Mika Westerberg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yp3Imyq6Lny7DwvO@lahna \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=gil.fine@intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=michael.jamet@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox