linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: Utkarsh Patel <utkarsh.h.patel@intel.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	enric.balletbo@collabora.com, rajmohan.mani@intel.com,
	azhar.shaikh@intel.com
Subject: Re: [PATCH v3 2/4] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode
Date: Fri, 20 Nov 2020 13:22:18 +0200	[thread overview]
Message-ID: <20201120112218.GE4120550@kuha.fi.intel.com> (raw)
In-Reply-To: <20201119080906.GE3652649@google.com>

On Thu, Nov 19, 2020 at 12:09:06AM -0800, Prashant Malani wrote:
> Hi Utkarsh,
> 
> On Wed, Nov 18, 2020 at 10:32:09PM -0800, Utkarsh Patel wrote:
> > Configure Thunderbolt 3 cable generation value by filling Thunderbolt 3
> > cable discover mode VDO to support rounded Thunderbolt 3 cables.
> > While we are here use Thunderbolt 3 cable discover mode VDO to fill active
> > cable plug link training value.
> > 
> > Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
> > 
> > --
> > Changes in v3:
> > - Added a check for cable's TBT support before filling TBT3 discover mode
> >   VDO.
> > 
> > Changes in v2:
> > - No change.
> > --
> > ---
> >  drivers/platform/chrome/cros_ec_typec.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> > index 8111ed1fc574..68b17ee1d1ae 100644
> > --- a/drivers/platform/chrome/cros_ec_typec.c
> > +++ b/drivers/platform/chrome/cros_ec_typec.c
> > @@ -514,8 +514,18 @@ static int cros_typec_enable_usb4(struct cros_typec_data *typec,
> >  	else if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_CABLE)
> >  		data.eudo |= EUDO_CABLE_TYPE_RE_TIMER << EUDO_CABLE_TYPE_SHIFT;
> >  
> > -	data.active_link_training = !!(pd_ctrl->control_flags &
> > -				       USB_PD_CTRL_ACTIVE_LINK_UNIDIR);
> > +	/*
> > +	 * Filling TBT3 Cable VDO when TBT3 cable is being used to establish
> > +	 * USB4 connection.
> > +	 */
> > +	if (pd_ctrl->cable_gen) {
> > +		data.tbt_cable_vdo = TBT_MODE;
> > +
> > +		if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
> > +			data.tbt_cable_vdo |= TBT_CABLE_LINK_TRAINING;
> > +
> > +		data.tbt_cable_vdo |= TBT_SET_CABLE_ROUNDED(pd_ctrl->cable_gen);
> > +	}
> 
> I think the following would decouple Rounded Support and Active Cable Link
> Training?:
> 
> 	struct typec_thunderbolt_data data = {};
> ...
> 	if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
> 		data.tbt_cable_vdo |= TBT_CABLE_LINK_TRAINING;
> 
> 	data.tbt_cable_vdo |= TBT_SET_CABLE_ROUNDED(pd_ctrl->cable_gen);

I agree with this. We should not modify the data that we actually
have access to.

> 	if (data.tbt_cable_vdo)
> 		data.tbt_cable_vdo |= TBT_MODE;

That is wrong. If the LSRX communication is bi-directional, and/or the
data rates are non-rounded, the cable has to be TBT3 cable. So I think
what you would want is:

	if (!data.tbt_cable_vdo)
 		data.tbt_cable_vdo = TBT_MODE;

But of course we can not do that either, because we have to set the
TBT_MODE bit if there is any other data in tbt_cable_vdo (USB Type-C
spec does not define any other valid values except 0x0001 = TBT_MODE
for that field). Otherwise the mux driver should consider the data
corrupted. So we would have to do this:

        if (pd_ctrl->cable_gen &&
            pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
                data.tbt_cable_vdo = 0; /* We assume USB4 cable */
        else
 		data.tbt_cable_vdo |= TBT_MODE; /* It is for sure TBT3 cable */

But I would not do that. TBT3 cable can also support unidirectional
SBU communication and rounded data rates.

IMO safer bet for now would be to just claim that the cable is always
TBT3 cable until we have access to information that can really tell us
is the cable USB4 or TBT3.

But it's up to you guys.


Br,

-- 
heikki

  parent reply	other threads:[~2020-11-20 11:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19  6:32 [PATCH v3 0/4] Thunderbolt3/USB4 cable rounded and active cable plug link training support Utkarsh Patel
2020-11-19  6:32 ` [PATCH v3 1/4] usb: typec: Use Thunderbolt 3 cable discover mode VDO in Enter_USB message Utkarsh Patel
2020-11-20  8:05   ` Heikki Krogerus
2020-11-20  8:36     ` Prashant Malani
2020-11-20  8:52       ` Heikki Krogerus
2020-11-20 17:04         ` Patel, Utkarsh H
2020-11-19  6:32 ` [PATCH v3 2/4] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode Utkarsh Patel
2020-11-19  8:09   ` Prashant Malani
2020-11-20  2:32     ` Patel, Utkarsh H
2020-11-20  3:13       ` Prashant Malani
2020-11-20 11:22     ` Heikki Krogerus [this message]
2020-11-20 12:07       ` Prashant Malani
2020-11-20 13:36         ` Prashant Malani
2020-11-20 13:41         ` Heikki Krogerus
2020-11-19  6:32 ` [PATCH v3 3/4] usb: typec: intel_pmc_mux: Configure active cable properties for USB4 Utkarsh Patel
2020-11-19  6:32 ` [PATCH v3 4/4] usb: typec: Remove active_link_training variable from Enter_USB message Utkarsh Patel

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=20201120112218.GE4120550@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=azhar.shaikh@intel.com \
    --cc=enric.balletbo@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pmalani@chromium.org \
    --cc=rajmohan.mani@intel.com \
    --cc=utkarsh.h.patel@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;
as well as URLs for NNTP newsgroup(s).