Message-ID: <1cec43f38ccd42d9a4d9a9c86365a24a@AUSX13MPC105.AMER.DELL.COM>
Date:   Tue, 1 Oct 2019 16:53:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <mika.westerberg@...ux.intel.com>
CC:     <linux-usb@...r.kernel.org>, <andreas.noever@...il.com>,
        <michael.jamet@...el.com>, <YehezkelShB@...il.com>,
        <rajmohan.mani@...el.com>,
        <nicholas.johnson-opensource@...look.com.au>, <lukas@...ner.de>,
        <gregkh@...uxfoundation.org>, <stern@...land.harvard.edu>,
        <anthony.wong@...onical.com>, <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 22/22] thunderbolt: Do not start firmware unless asked
 by the user

> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> Sent: Tuesday, October 1, 2019 9:59 AM
> To: Limonciello, Mario
> Cc: linux-usb@...r.kernel.org; andreas.noever@...il.com;
> michael.jamet@...el.com; YehezkelShB@...il.com; rajmohan.mani@...el.com;
> nicholas.johnson-opensource@...look.com.au; lukas@...ner.de;
> gregkh@...uxfoundation.org; stern@...land.harvard.edu;
> anthony.wong@...onical.com; linux-kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 22/22] thunderbolt: Do not start firmware unless asked by
> the user
> 
> 
> [EXTERNAL EMAIL]
> 
> On Tue, Oct 01, 2019 at 02:43:15PM +0000, Mario.Limonciello@...l.com wrote:
> > > -----Original Message-----
> > > From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> > > Sent: Tuesday, October 1, 2019 6:39 AM
> > > To: linux-usb@...r.kernel.org
> > > Cc: Andreas Noever; Michael Jamet; Mika Westerberg; Yehezkel Bernat;
> Rajmohan
> > > Mani; Nicholas Johnson; Lukas Wunner; Greg Kroah-Hartman; Alan Stern;
> > > Limonciello, Mario; Anthony Wong; linux-kernel@...r.kernel.org
> > > Subject: [RFC PATCH 22/22] thunderbolt: Do not start firmware unless asked by
> the
> > > user
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Since now we can do pretty much the same thing in the software
> > > connection manager than the firmware would do, there is no point
> > > starting it by default. Instead we can just continue using the software
> > > connection manager.
> > >
> > > Make it possible for user to switch between the two by adding a module
> > > pararameter (start_icm) which is by default false. Having this ability
> > > to enable the firmware may be useful at least when debugging possible
> > > issues with the software connection manager implementation.
> >
> > If the host system firmware didn't start the ICM, does that mean SW connection
> > manager would just take over even on systems with discrete AR/TR controllers?
> 
> Yes. This is pretty much the case with Apple systems now.

Potentially if system firmware started ICM can we accomplish the same thing by
resetting AR/TR that normally use ICM and then SW CM would take over?

Or is the ICM started up automatically when the controller is power cycled based
on something in the NVM?

I'm trying to find a way that I can usefully exercise some of this stuff on pre-USB4
controllers like AR/TR/ICL-TBT.

> 
> > >
> > > Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> > > ---
> > >  drivers/thunderbolt/icm.c | 14 +++++++++++---
> > >  drivers/thunderbolt/tb.c  |  4 ----
> > >  2 files changed, 11 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
> > > index 9c9c6ea2b790..c4a2de0f2a44 100644
> > > --- a/drivers/thunderbolt/icm.c
> > > +++ b/drivers/thunderbolt/icm.c
> > > @@ -11,6 +11,7 @@
> > >
> > >  #include <linux/delay.h>
> > >  #include <linux/mutex.h>
> > > +#include <linux/moduleparam.h>
> > >  #include <linux/pci.h>
> > >  #include <linux/pm_runtime.h>
> > >  #include <linux/platform_data/x86/apple.h>
> > > @@ -43,6 +44,10 @@
> > >  #define ICM_APPROVE_TIMEOUT		10000	/* ms */
> > >  #define ICM_MAX_LINK			4
> > >
> > > +static bool start_icm;
> > > +module_param(start_icm, bool, 0444);
> > > +MODULE_PARM_DESC(start_icm, "start ICM firmware if it is not running
> (default:
> > > false)");
> > > +
> > >  /**
> > >   * struct icm - Internal connection manager private data
> > >   * @request_lock: Makes sure only one message is send to ICM at time
> > > @@ -1353,13 +1358,16 @@ static bool icm_ar_is_supported(struct tb *tb)
> > >  {
> > >  	struct pci_dev *upstream_port;
> > >  	struct icm *icm = tb_priv(tb);
> > > +	u32 val;
> > >
> > >  	/*
> > >  	 * Starting from Alpine Ridge we can use ICM on Apple machines
> > >  	 * as well. We just need to reset and re-enable it first.
> >
> > This comment doesn't really seem as relevant anymore.  The meaning of it
> > has nothing to do with Apple anymore.
> 
> Actually it is still relevant. For USB4 the intent is to have FW/SW CM
> switch in ACPI spec instead. But that is still under discussion.

Like read a hint from an ACPI table that indicates which one driver should use?

The idea being early USB4 systems would test and ship with this bit set to
FW CM and later USB4 systems can have it set to SW CM?

I like that idea, but I think that you almost want the module parameter to indicate
which CM you want to "use" instead so you would override what was set in ACPI
either way, but default to auto.

cm=auto
TBT3 and less: follow NVM behavior
USB4: follow ACPI table, either use FW or SW CM.

cm=icm
Start up ICM, or error out if you can't.

cm=sw
Stop ICM if it's running, and initialize using kernel CM.

That would certainly allow running this across some more configurations really easily then.

> 
> > > +	 * However, only start it if explicitly asked by the user.
> > >  	 */
> > > -	if (!x86_apple_machine)
> > > -		return true;
> > > +	val = ioread32(tb->nhi->iobase + REG_FW_STS);
> > > +	if (!(val & REG_FW_STS_ICM_EN) && !start_icm)
> > > +		return false;
> >
> > This code is already in icm_firmware_start.  Maybe split it to a small function
> > So you can just have the more readable
> >
> > If (!icm_firmware_running(tb) && !start_icm))
> 
> Good point. I'll do that.

Powered by blists - more mailing lists