| Message ID | 20200225204649.28220-1-s-anna@ti.com |
|---|---|
| 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
Hi Tony, The following series adds the ti-sysc support for the PRUSS IP present on some AM33xx, AM437x and AM57xx SoCs. This series is a revamped and more complete version of the previous attempt [1] made last year and includes support for AM33xx and AM437x now that the reset dependencies are fully upstream. The OCP master ports are not enabled by default now, and the ti-sysc bus driver only handles the important quirk needed for suspend/resume on AM33xx and AM437x SoCs. The series includes patches for both the ti-sysc bindings and the bus driver, along with all the DTS nodes. Patches are based on 5.6-rc1. The dts nodes can be added added independently of the corresponding hwmod cleanup [2]. This forms the foundation before the rest of the PRUSS platform drivers can be added. Please consider the series for 5.7, and I can post the PRUSS platform driver and/or PRUSS INTC driver for 5.8. The integration of the IP is different on different SoC families, and following are some differences: 1. AM33xx and AM437x SoCs need a PRCM reset line to be deasserted as well to be able to access any PRUSS registers. 2. AM437x has two PRUSS instances, with the smaller PRU-ICSS0 connected through the larger PRU-ICSS1. There is only a single interconnect target node added. AM57xx has no reset lines, and only requires the module to be enabled. 3. AM57xx has two identical instances, but do not require any reset lines. 4. PRUSS is present only on some SoCs on each SoC family: - AM3356 and above SoCs on AM335x family - AM4376 and above SoCs on AM437x family - AM57xx SoCs only; not supported on DRA7xx SoCs. The sanity testing can be done by turning on the power through the sysfs for now. These will be taken care of automatically when the PRUSS platform driver will invoke the pm_runtime_get_sync() and put_sync() as the PRUSS nodes will be children of the ti-sysc interconnect nodes. 1. AM335x echo on > /sys/bus/platform/devices/4a326000.target-module/power/control 2. AM437x echo on > /sys/bus/platform/devices/54426000.target-module/power/control 3. AM57xx echo on > /sys/bus/platform/devices/4b226000.target-module/power/control echo on > /sys/bus/platform/devices/4b2a6000.target-module/power/control Here are the version numbers from the CFG sub-module on these IPs that are used for the ti-sysc quirks: AM335x : 0x47000000 AM437x PRUSS1 : 0x47000200 AM437x PRUSS0 : 0x47010100 AM57xx PRUSS0 & PRUSS1 : 0x47000201 regards Suman [1] https://patchwork.kernel.org/cover/10796015/ [2] https://patchwork.kernel.org/cover/11402083/ Roger Quadros (1): dt-bindings: bus: ti-sysc: Add support for PRUSS SYSC type Suman Anna (11): bus: ti-sysc: Add support for PRUSS SYSC type ARM: dts: AM33xx-l4: Update PRUSS interconnect target-module node ARM: dts: AM4372: Add the PRU-ICSS interconnect target-module node ARM: dts: dra7: Add PRU-ICSS interconnect target-module nodes ARM: dts: am335x-bone-common: Enable PRU-ICSS interconnect node ARM: dts: am335x-evm: Enable PRU-ICSS interconnect node ARM: dts: am335x-evmsk: Enable PRU-ICSS interconnect node ARM: dts: am335x-icev2: Enable PRU-ICSS interconnect node ARM: dts: am437x-gp-evm: Enable PRU-ICSS interconnect node ARM: dts: am437x-sk: Enable PRU-ICSS interconnect node ARM: dts: am437x-idk: Enable PRU-ICSS interconnect node .../devicetree/bindings/bus/ti-sysc.txt | 1 + arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++ arch/arm/boot/dts/am335x-evm.dts | 4 ++ arch/arm/boot/dts/am335x-evmsk.dts | 4 ++ arch/arm/boot/dts/am335x-icev2.dts | 4 ++ arch/arm/boot/dts/am33xx-l4.dtsi | 21 ++++++-- arch/arm/boot/dts/am4372.dtsi | 23 +++++++++ arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++ arch/arm/boot/dts/am437x-idk-evm.dts | 4 ++ arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++ arch/arm/boot/dts/am57-pruss.dtsi | 50 +++++++++++++++++++ arch/arm/boot/dts/am5718.dtsi | 1 + arch/arm/boot/dts/am5728.dtsi | 1 + arch/arm/boot/dts/am5748.dtsi | 1 + arch/arm/boot/dts/dra7.dtsi | 2 +- drivers/bus/ti-sysc.c | 27 ++++++++++ include/dt-bindings/bus/ti-sysc.h | 4 ++ include/linux/platform_data/ti-sysc.h | 2 + 18 files changed, 157 insertions(+), 4 deletions(-) create mode 100644 arch/arm/boot/dts/am57-pruss.dtsi