All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: "Théo Lebrun" <theo.lebrun@bootlin.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Roger Quadros" <rogerq@kernel.org>,
	"Peter Chen" <peter.chen@kernel.org>,
	"Pawel Laszczak" <pawell@cadence.com>,
	"Nishanth Menon" <nm@ti.com>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Tero Kristo" <kristo@kernel.org>
Cc: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Grégory Clement" <gregory.clement@bootlin.com>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Théo Lebrun" <theo.lebrun@bootlin.com>
Subject: Re: [PATCH v4 4/9] usb: cdns3-ti: support reset-on-resume behavior
Date: Fri, 08 Mar 2024 13:58:25 -0800	[thread overview]
Message-ID: <7h4jdgperi.fsf@baylibre.com> (raw)
In-Reply-To: <20240307-j7200-usb-suspend-v4-4-5ec7615431f3@bootlin.com>

Théo Lebrun <theo.lebrun@bootlin.com> writes:

> Add match data support, with one boolean to indicate whether the
> hardware resets after a system-wide suspend. If hardware resets, we
> force execute ->runtime_resume() at system-wide resume to run the
> hardware init sequence.

Is "whether the hardware resets after a system-wide suspend" really a
function of the IP itself, or rather whether the IP is in a power domain
that might power down?

> No compatible exploits this functionality, just yet.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
>  drivers/usb/cdns3/cdns3-ti.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
> index 4c8a557e6a6f..f76327566798 100644
> --- a/drivers/usb/cdns3/cdns3-ti.c
> +++ b/drivers/usb/cdns3/cdns3-ti.c
> @@ -57,9 +57,14 @@ struct cdns_ti {
>  	unsigned vbus_divider:1;
>  	struct clk *usb2_refclk;
>  	struct clk *lpm_clk;
> +	const struct cdns_ti_match_data *match_data;
>  	int usb2_refclk_rate_code;
>  };
>  
> +struct cdns_ti_match_data {
> +	bool reset_on_resume;
> +};
> +
>  static const int cdns_ti_rate_table[] = {	/* in KHZ */
>  	9600,
>  	10000,
> @@ -101,6 +106,7 @@ static int cdns_ti_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, data);
>  
>  	data->dev = dev;
> +	data->match_data = device_get_match_data(dev);
>  
>  	data->usbss = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(data->usbss)) {
> @@ -220,8 +226,29 @@ static int cdns_ti_runtime_resume(struct device *dev)
>  	return 0;
>  }
>  
> +static int cdns_ti_suspend(struct device *dev)
> +{
> +	struct cdns_ti *data = dev_get_drvdata(dev);
> +
> +	if (data->match_data && data->match_data->reset_on_resume)
> +		return pm_runtime_force_suspend(dev);
> +	else
> +		return 0;
> +}
> +
> +static int cdns_ti_resume(struct device *dev)
> +{
> +	struct cdns_ti *data = dev_get_drvdata(dev);
> +
> +	if (data->match_data && data->match_data->reset_on_resume)
> +		return pm_runtime_force_resume(dev);
> +	else
> +		return 0;
> +}

Conditionally forcing runtime suspend/resume based on a property of the
IP doesn't feel right to me.

IMO, the device should always runtime suspend/resume, and in the
runtime PM hooks is where the conditional logic should be.

And speaking of the conditional logic... let's go back to whether
"resets_on_resume" is a property of the IP or the enclosing power
domain.

Instead of having an IP-specific flag, another way of approaching this
when ->runtime_resume() is called every time is simply for that hook to
check if a reset has happend.  Sometimes you can tell this simply by
reading a register that has been previously programmed by the driver but
has a known reset.  Simply check that regisister and you can tell
whether context has been lost.

Doing it this way makes the driver "smart" and then you don't have to
rely on bool flag based on the IP and dependent on the DT compatible.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: "Théo Lebrun" <theo.lebrun@bootlin.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Roger Quadros" <rogerq@kernel.org>,
	"Peter Chen" <peter.chen@kernel.org>,
	"Pawel Laszczak" <pawell@cadence.com>,
	"Nishanth Menon" <nm@ti.com>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Tero Kristo" <kristo@kernel.org>
Cc: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Grégory Clement" <gregory.clement@bootlin.com>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Théo Lebrun" <theo.lebrun@bootlin.com>
Subject: Re: [PATCH v4 4/9] usb: cdns3-ti: support reset-on-resume behavior
Date: Fri, 08 Mar 2024 13:58:25 -0800	[thread overview]
Message-ID: <7h4jdgperi.fsf@baylibre.com> (raw)
In-Reply-To: <20240307-j7200-usb-suspend-v4-4-5ec7615431f3@bootlin.com>

Théo Lebrun <theo.lebrun@bootlin.com> writes:

> Add match data support, with one boolean to indicate whether the
> hardware resets after a system-wide suspend. If hardware resets, we
> force execute ->runtime_resume() at system-wide resume to run the
> hardware init sequence.

Is "whether the hardware resets after a system-wide suspend" really a
function of the IP itself, or rather whether the IP is in a power domain
that might power down?

> No compatible exploits this functionality, just yet.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
>  drivers/usb/cdns3/cdns3-ti.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
> index 4c8a557e6a6f..f76327566798 100644
> --- a/drivers/usb/cdns3/cdns3-ti.c
> +++ b/drivers/usb/cdns3/cdns3-ti.c
> @@ -57,9 +57,14 @@ struct cdns_ti {
>  	unsigned vbus_divider:1;
>  	struct clk *usb2_refclk;
>  	struct clk *lpm_clk;
> +	const struct cdns_ti_match_data *match_data;
>  	int usb2_refclk_rate_code;
>  };
>  
> +struct cdns_ti_match_data {
> +	bool reset_on_resume;
> +};
> +
>  static const int cdns_ti_rate_table[] = {	/* in KHZ */
>  	9600,
>  	10000,
> @@ -101,6 +106,7 @@ static int cdns_ti_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, data);
>  
>  	data->dev = dev;
> +	data->match_data = device_get_match_data(dev);
>  
>  	data->usbss = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(data->usbss)) {
> @@ -220,8 +226,29 @@ static int cdns_ti_runtime_resume(struct device *dev)
>  	return 0;
>  }
>  
> +static int cdns_ti_suspend(struct device *dev)
> +{
> +	struct cdns_ti *data = dev_get_drvdata(dev);
> +
> +	if (data->match_data && data->match_data->reset_on_resume)
> +		return pm_runtime_force_suspend(dev);
> +	else
> +		return 0;
> +}
> +
> +static int cdns_ti_resume(struct device *dev)
> +{
> +	struct cdns_ti *data = dev_get_drvdata(dev);
> +
> +	if (data->match_data && data->match_data->reset_on_resume)
> +		return pm_runtime_force_resume(dev);
> +	else
> +		return 0;
> +}

Conditionally forcing runtime suspend/resume based on a property of the
IP doesn't feel right to me.

IMO, the device should always runtime suspend/resume, and in the
runtime PM hooks is where the conditional logic should be.

And speaking of the conditional logic... let's go back to whether
"resets_on_resume" is a property of the IP or the enclosing power
domain.

Instead of having an IP-specific flag, another way of approaching this
when ->runtime_resume() is called every time is simply for that hook to
check if a reset has happend.  Sometimes you can tell this simply by
reading a register that has been previously programmed by the driver but
has a known reset.  Simply check that regisister and you can tell
whether context has been lost.

Doing it this way makes the driver "smart" and then you don't have to
rely on bool flag based on the IP and dependent on the DT compatible.

Kevin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2024-03-08 21:58 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07  9:55 [PATCH v4 0/9] usb: cdns: fix suspend on J7200 by assuming reset-on-resume Théo Lebrun
2024-03-07  9:55 ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 1/9] dt-bindings: usb: ti,j721e-usb: fix compatible list Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07 15:02   ` Rob Herring
2024-03-07 15:02     ` Rob Herring
2024-03-07 18:14   ` Conor Dooley
2024-03-07 18:14     ` Conor Dooley
2024-03-07  9:55 ` [PATCH v4 2/9] dt-bindings: usb: ti,j721e-usb: add ti,j7200-usb compatible Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07 14:21   ` Rob Herring
2024-03-07 14:21     ` Rob Herring
2024-03-07 14:50     ` Théo Lebrun
2024-03-07 14:50       ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 3/9] usb: cdns3-ti: move reg writes from probe into ->runtime_resume() Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07 12:31   ` Roger Quadros
2024-03-07 12:31     ` Roger Quadros
2024-03-07 14:39     ` Théo Lebrun
2024-03-07 14:39       ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 4/9] usb: cdns3-ti: support reset-on-resume behavior Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07 12:34   ` Roger Quadros
2024-03-07 12:34     ` Roger Quadros
2024-03-08 21:58   ` Kevin Hilman [this message]
2024-03-08 21:58     ` Kevin Hilman
2024-03-14 13:40     ` Théo Lebrun
2024-03-14 13:40       ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 5/9] usb: cdns3-ti: pass auxdata from match data to of_platform_populate() Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07 12:38   ` Roger Quadros
2024-03-07 12:38     ` Roger Quadros
2024-03-07 14:47     ` Théo Lebrun
2024-03-07 14:47       ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 6/9] usb: cdns3: add quirk to platform data for reset-on-resume Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 7/9] usb: cdns3-ti: add J7200 support with reset-on-resume behavior Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 8/9] arm64: dts: ti: k3-j7200: use J7200-specific USB compatible Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun
2024-03-07  9:55 ` [PATCH v4 9/9] arm64: dts: ti: k3-am64: add USB fallback compatible to J721E Théo Lebrun
2024-03-07  9:55   ` Théo Lebrun

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=7h4jdgperi.fsf@baylibre.com \
    --to=khilman@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@bootlin.com \
    --cc=kristo@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=pawell@cadence.com \
    --cc=peter.chen@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=theo.lebrun@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.