[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TYCPR01MB11332BE2EDB318950B9C7B54C86932@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Date: Tue, 3 Sep 2024 11:07:06 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, Ulf Hansson
<ulf.hansson@...aro.org>
CC: "vkoul@...nel.org" <vkoul@...nel.org>, "kishon@...nel.org"
<kishon@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
<conor+dt@...nel.org>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"geert+renesas@...der.be" <geert+renesas@...der.be>, "magnus.damm@...il.com"
<magnus.damm@...il.com>, "gregkh@...uxfoundation.org"
<gregkh@...uxfoundation.org>, "mturquette@...libre.com"
<mturquette@...libre.com>, "sboyd@...nel.org" <sboyd@...nel.org>, Yoshihiro
Shimoda <yoshihiro.shimoda.uh@...esas.com>, "linux-phy@...ts.infradead.org"
<linux-phy@...ts.infradead.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>, "linux-usb@...r.kernel.org"
<linux-usb@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-clk@...r.kernel.org"
<linux-clk@...r.kernel.org>, "linux-pm@...r.kernel.org"
<linux-pm@...r.kernel.org>, Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
Hi Claudiu,
> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@...on.dev>
> Sent: Tuesday, September 3, 2024 12:00 PM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>
>
>
> On 03.09.2024 13:31, Biju Das wrote:
> >>> During boot clr USB PWR READY signal in TF-A.
> >>> STR case, suspend set USB PWR READY signal in TF-A.
> >>> STR case, resume clr USB PWR READY signal in TF-A.
> >> As I said previously, it can be done in different ways. My point was
> >> to let Linux set what it needs for all it's devices to work. I think the way to go forward is a
> maintainer decision.
> >
> > I agree, there can be n number of solution for a problem.
> >
> > Since you modelled system state signal (USB PWRRDY) as reset control
> > signal, it is reset/DT maintainer's decision to say the final word whether this signal fits in reset
> system framework or not?
>
> I was thinking:
> 1/ Geert would be the best to say if he considers it OK to handle this
> in Linux
I agree Geert is the right person for taking SYSTEM decisions,
since the signal is used only during state transitions
(Table 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> 2/ if OK, then we should get approval from Ulf and Philipp on the power
> domain or reset approaches
Ok.
Cheers,
Biju
Powered by blists - more mailing lists