| Message ID | 20200225204649.28220-7-s-anna@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ti-sysc support for PRUSS | expand |
* Suman Anna <s-anna@ti.com> [200225 20:47]: > The PRU-ICSS target module node was left in disabled state in the base > am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone > boards as they mostly use a AM3358 or a AM3359 SoC which do contain > the PRU-ICSS IP. Just get rid of the top level status = "disabled". The default is enabled, and the device is there for sure inside the SoC. And then there's no need for pointless status = "okay" tinkering in the board specific dts files so no need for this patch. Regards, Tony
On 2/26/20 12:29 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [200225 20:47]: >> The PRU-ICSS target module node was left in disabled state in the base >> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone >> boards as they mostly use a AM3358 or a AM3359 SoC which do contain >> the PRU-ICSS IP. > > Just get rid of the top level status = "disabled". The default > is enabled, and the device is there for sure inside the SoC. > And then there's no need for pointless status = "okay" tinkering > in the board specific dts files so no need for this patch. The IP is not available on all SoCs, and there are about 40 different board files atm across AM33xx and AM437x, and am not sure what SoCs they are actually using. regards Suman
* Suman Anna <s-anna@ti.com> [200226 20:35]: > On 2/26/20 12:29 PM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [200225 20:47]: > >> The PRU-ICSS target module node was left in disabled state in the base > >> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone > >> boards as they mostly use a AM3358 or a AM3359 SoC which do contain > >> the PRU-ICSS IP. > > > > Just get rid of the top level status = "disabled". The default > > is enabled, and the device is there for sure inside the SoC. > > And then there's no need for pointless status = "okay" tinkering > > in the board specific dts files so no need for this patch. > > The IP is not available on all SoCs, and there are about 40 different > board files atm across AM33xx and AM437x, and am not sure what SoCs they > are actually using. Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: Detect display subsystem related devices" if you can add runtime detection for the accelerators there similar to what I hadded for omap3. acclerators. Regards, Tony
* Tony Lindgren <tony@atomide.com> [200226 22:38]: > * Suman Anna <s-anna@ti.com> [200226 20:35]: > > On 2/26/20 12:29 PM, Tony Lindgren wrote: > > > * Suman Anna <s-anna@ti.com> [200225 20:47]: > > >> The PRU-ICSS target module node was left in disabled state in the base > > >> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone > > >> boards as they mostly use a AM3358 or a AM3359 SoC which do contain > > >> the PRU-ICSS IP. > > > > > > Just get rid of the top level status = "disabled". The default > > > is enabled, and the device is there for sure inside the SoC. > > > And then there's no need for pointless status = "okay" tinkering > > > in the board specific dts files so no need for this patch. > > > > The IP is not available on all SoCs, and there are about 40 different > > board files atm across AM33xx and AM437x, and am not sure what SoCs they > > are actually using. > > Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: > Detect display subsystem related devices" if you can add runtime > detection for the accelerators there similar to what I hadded for omap3. > acclerators. Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC revision handling". Regards, Tony
Hi Tony, On 2/26/20 4:39 PM, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [200226 22:38]: >> * Suman Anna <s-anna@ti.com> [200226 20:35]: >>> On 2/26/20 12:29 PM, Tony Lindgren wrote: >>>> * Suman Anna <s-anna@ti.com> [200225 20:47]: >>>>> The PRU-ICSS target module node was left in disabled state in the base >>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone >>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain >>>>> the PRU-ICSS IP. >>>> >>>> Just get rid of the top level status = "disabled". The default >>>> is enabled, and the device is there for sure inside the SoC. >>>> And then there's no need for pointless status = "okay" tinkering >>>> in the board specific dts files so no need for this patch. >>> >>> The IP is not available on all SoCs, and there are about 40 different >>> board files atm across AM33xx and AM437x, and am not sure what SoCs they >>> are actually using. >> >> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: >> Detect display subsystem related devices" if you can add runtime >> detection for the accelerators there similar to what I hadded for omap3. >> acclerators. > > Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC > revision handling". OK, looked down that path a bit more and looking through mach-omap2/id.c and soc.h, I see some of the part number infrastructure build on top of DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the generic family and the Silicon Revision number for AM33xx and AM437x and we currently do not have any infrastructure around exact SoC identification for AM33xx and AM437x atleast. Do you have the bit-field split for the DEV_FEATURE bits somewhere, because I couldn't find any in either the DM or the TRM. On AM437x, there is no difference between AM4372 and AM4376 DEV_FEATURE value even though the former doesn't have the PRUSS. On AM335x, may be bit 0 signifies the presence of PRUSS?? regards Suman
* Suman Anna <s-anna@ti.com> [200227 00:59]: > Hi Tony, > > On 2/26/20 4:39 PM, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [200226 22:38]: > >> * Suman Anna <s-anna@ti.com> [200226 20:35]: > >>> On 2/26/20 12:29 PM, Tony Lindgren wrote: > >>>> * Suman Anna <s-anna@ti.com> [200225 20:47]: > >>>>> The PRU-ICSS target module node was left in disabled state in the base > >>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone > >>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain > >>>>> the PRU-ICSS IP. > >>>> > >>>> Just get rid of the top level status = "disabled". The default > >>>> is enabled, and the device is there for sure inside the SoC. > >>>> And then there's no need for pointless status = "okay" tinkering > >>>> in the board specific dts files so no need for this patch. > >>> > >>> The IP is not available on all SoCs, and there are about 40 different > >>> board files atm across AM33xx and AM437x, and am not sure what SoCs they > >>> are actually using. > >> > >> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: > >> Detect display subsystem related devices" if you can add runtime > >> detection for the accelerators there similar to what I hadded for omap3. > >> acclerators. > > > > Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC > > revision handling". > > OK, looked down that path a bit more and looking through mach-omap2/id.c > and soc.h, I see some of the part number infrastructure build on top of > DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the > generic family and the Silicon Revision number for AM33xx and AM437x and > we currently do not have any infrastructure around exact SoC > identification for AM33xx and AM437x atleast. > > Do you have the bit-field split for the DEV_FEATURE bits somewhere, > because I couldn't find any in either the DM or the TRM. On AM437x, > there is no difference between AM4372 and AM4376 DEV_FEATURE value even > though the former doesn't have the PRUSS. On AM335x, may be bit 0 > signifies the presence of PRUSS?? OK not sure how that could be detected. Maybe check the efuses on the newer SoCs? Regards, Tony
On 2/26/20 8:07 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [200227 00:59]: >> Hi Tony, >> >> On 2/26/20 4:39 PM, Tony Lindgren wrote: >>> * Tony Lindgren <tony@atomide.com> [200226 22:38]: >>>> * Suman Anna <s-anna@ti.com> [200226 20:35]: >>>>> On 2/26/20 12:29 PM, Tony Lindgren wrote: >>>>>> * Suman Anna <s-anna@ti.com> [200225 20:47]: >>>>>>> The PRU-ICSS target module node was left in disabled state in the base >>>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone >>>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain >>>>>>> the PRU-ICSS IP. >>>>>> >>>>>> Just get rid of the top level status = "disabled". The default >>>>>> is enabled, and the device is there for sure inside the SoC. >>>>>> And then there's no need for pointless status = "okay" tinkering >>>>>> in the board specific dts files so no need for this patch. >>>>> >>>>> The IP is not available on all SoCs, and there are about 40 different >>>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they >>>>> are actually using. >>>> >>>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: >>>> Detect display subsystem related devices" if you can add runtime >>>> detection for the accelerators there similar to what I hadded for omap3. >>>> acclerators. >>> >>> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC >>> revision handling". >> >> OK, looked down that path a bit more and looking through mach-omap2/id.c >> and soc.h, I see some of the part number infrastructure build on top of >> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the >> generic family and the Silicon Revision number for AM33xx and AM437x and >> we currently do not have any infrastructure around exact SoC >> identification for AM33xx and AM437x atleast. >> >> Do you have the bit-field split for the DEV_FEATURE bits somewhere, >> because I couldn't find any in either the DM or the TRM. On AM437x, >> there is no difference between AM4372 and AM4376 DEV_FEATURE value even >> though the former doesn't have the PRUSS. On AM335x, may be bit 0 >> signifies the presence of PRUSS?? > > OK not sure how that could be detected. Maybe check the efuses on > the newer SoCs? OK, latest datasheeet has fixed these values up, and they are no longer identical. In anycase, none of the current AM437x board dts files in the kernel use AM4372, so atleast for AM4372, I can drop the status=disabled even without adding any SoC name support. regards Suman
* Suman Anna <s-anna@ti.com> [200227 21:29]: > On 2/26/20 8:07 PM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [200227 00:59]: > >> Hi Tony, > >> > >> On 2/26/20 4:39 PM, Tony Lindgren wrote: > >>> * Tony Lindgren <tony@atomide.com> [200226 22:38]: > >>>> * Suman Anna <s-anna@ti.com> [200226 20:35]: > >>>>> On 2/26/20 12:29 PM, Tony Lindgren wrote: > >>>>>> * Suman Anna <s-anna@ti.com> [200225 20:47]: > >>>>>>> The PRU-ICSS target module node was left in disabled state in the base > >>>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone > >>>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain > >>>>>>> the PRU-ICSS IP. > >>>>>> > >>>>>> Just get rid of the top level status = "disabled". The default > >>>>>> is enabled, and the device is there for sure inside the SoC. > >>>>>> And then there's no need for pointless status = "okay" tinkering > >>>>>> in the board specific dts files so no need for this patch. > >>>>> > >>>>> The IP is not available on all SoCs, and there are about 40 different > >>>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they > >>>>> are actually using. > >>>> > >>>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc: > >>>> Detect display subsystem related devices" if you can add runtime > >>>> detection for the accelerators there similar to what I hadded for omap3. > >>>> acclerators. > >>> > >>> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC > >>> revision handling". > >> > >> OK, looked down that path a bit more and looking through mach-omap2/id.c > >> and soc.h, I see some of the part number infrastructure build on top of > >> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the > >> generic family and the Silicon Revision number for AM33xx and AM437x and > >> we currently do not have any infrastructure around exact SoC > >> identification for AM33xx and AM437x atleast. > >> > >> Do you have the bit-field split for the DEV_FEATURE bits somewhere, > >> because I couldn't find any in either the DM or the TRM. On AM437x, > >> there is no difference between AM4372 and AM4376 DEV_FEATURE value even > >> though the former doesn't have the PRUSS. On AM335x, may be bit 0 > >> signifies the presence of PRUSS?? > > > > OK not sure how that could be detected. Maybe check the efuses on > > the newer SoCs? > > OK, latest datasheeet has fixed these values up, and they are no longer > identical. In anycase, none of the current AM437x board dts files in the > kernel use AM4372, so atleast for AM4372, I can drop the status=disabled > even without adding any SoC name support. OK sounds good to me. Thanks, Tony
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi index 6c9187bc0f17..e507ef74d8e6 100644 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi @@ -397,3 +397,7 @@ clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>; clock-names = "ext-clk", "int-clk"; }; + +&pruss_tm { + status = "okay"; +};
The PRU-ICSS target module node was left in disabled state in the base am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone boards as they mostly use a AM3358 or a AM3359 SoC which do contain the PRU-ICSS IP. Signed-off-by: Suman Anna <s-anna@ti.com> --- arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)