Message ID | 20240109171950.31010-1-afd@ti.com |
---|---|
Headers | show |
Series | Device tree support for Imagination Series5 GPU | expand |
* Andrew Davis <afd@ti.com> [240109 17:20]: > --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi > +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi > @@ -850,12 +850,19 @@ target-module@56000000 { > <SYSC_IDLE_SMART>; > ti,sysc-sidle = <SYSC_IDLE_FORCE>, > <SYSC_IDLE_NO>, > - <SYSC_IDLE_SMART>; > + <SYSC_IDLE_SMART>, > + <SYSC_IDLE_SMART_WKUP>; You probably checked this already.. But just in case, can you please confirm this is intentional. The documentation lists the smart wakeup capability bit as reserved for dra7, maybe the documentation is wrong. Regards, Tony
On 1/10/24 2:29 AM, Tony Lindgren wrote: > * Andrew Davis <afd@ti.com> [240109 17:20]: >> --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi >> +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi >> @@ -850,12 +850,19 @@ target-module@56000000 { >> <SYSC_IDLE_SMART>; >> ti,sysc-sidle = <SYSC_IDLE_FORCE>, >> <SYSC_IDLE_NO>, >> - <SYSC_IDLE_SMART>; >> + <SYSC_IDLE_SMART>, >> + <SYSC_IDLE_SMART_WKUP>; > > You probably checked this already.. But just in case, can you please > confirm this is intentional. The documentation lists the smart wakeup > capability bit as reserved for dra7, maybe the documentation is wrong. > It was an intentional change, although I'm not sure it is correct :) This is how we had it in our "evil vendor tree" for years (back when it was hwmod based), so when converting these nodes to use "ti,sysc" I noticed this bit was set, but as you point out the documentation disagrees. I'd rather go with what has worked before, but it doesn't seem to break anything either way, so we could also break this change out into its own patch if you would prefer. Andrew > Regards, > > Tony >
* Andrew Davis <afd@ti.com> [240117 15:52]: > On 1/10/24 2:29 AM, Tony Lindgren wrote: > > * Andrew Davis <afd@ti.com> [240109 17:20]: > > > --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi > > > +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi > > > @@ -850,12 +850,19 @@ target-module@56000000 { > > > <SYSC_IDLE_SMART>; > > > ti,sysc-sidle = <SYSC_IDLE_FORCE>, > > > <SYSC_IDLE_NO>, > > > - <SYSC_IDLE_SMART>; > > > + <SYSC_IDLE_SMART>, > > > + <SYSC_IDLE_SMART_WKUP>; > > > > You probably checked this already.. But just in case, can you please > > confirm this is intentional. The documentation lists the smart wakeup > > capability bit as reserved for dra7, maybe the documentation is wrong. > > > > It was an intentional change, although I'm not sure it is correct :) > > This is how we had it in our "evil vendor tree" for years (back when it > was hwmod based), so when converting these nodes to use "ti,sysc" I noticed > this bit was set, but as you point out the documentation disagrees. > > I'd rather go with what has worked before, but it doesn't seem to > break anything either way, so we could also break this change out into > its own patch if you would prefer. I agree it's best to stick what is known to work. How about let's add the related information to the patch description? Regards, Tony
* Tony Lindgren <tony@atomide.com> [240118 08:57]: > * Andrew Davis <afd@ti.com> [240117 15:52]: > > On 1/10/24 2:29 AM, Tony Lindgren wrote: > > > * Andrew Davis <afd@ti.com> [240109 17:20]: > > > > --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi > > > > +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi > > > > @@ -850,12 +850,19 @@ target-module@56000000 { > > > > <SYSC_IDLE_SMART>; > > > > ti,sysc-sidle = <SYSC_IDLE_FORCE>, > > > > <SYSC_IDLE_NO>, > > > > - <SYSC_IDLE_SMART>; > > > > + <SYSC_IDLE_SMART>, > > > > + <SYSC_IDLE_SMART_WKUP>; > > > > > > You probably checked this already.. But just in case, can you please > > > confirm this is intentional. The documentation lists the smart wakeup > > > capability bit as reserved for dra7, maybe the documentation is wrong. > > > > > > > It was an intentional change, although I'm not sure it is correct :) > > > > This is how we had it in our "evil vendor tree" for years (back when it > > was hwmod based), so when converting these nodes to use "ti,sysc" I noticed > > this bit was set, but as you point out the documentation disagrees. > > > > I'd rather go with what has worked before, but it doesn't seem to > > break anything either way, so we could also break this change out into > > its own patch if you would prefer. > > I agree it's best to stick what is known to work. How about let's add > the related information to the patch description? I'll update the commit message for it and apply these, no need to repost. Regards, Tony