Add hwmod data for IPU & DSP processors/MMUs
Subsystems (4)
cover Add hwmod data for IPU & DSP processors/MMUs
Hi Tony,
The following series adds the hwmod data and the corresponding pdata quirks for the various MMUs associated with the IPU and DSP processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already supported on mainline) and providing a baseline for adding the OMAP remoteproc driver. The hwmod data for the consumers of these MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs, with an update to the OMAP4 ones.
Patches are baselined on your current for-next branch with commit a70cb93b6c2f ("Merge branch 'omap-for-v4.14/dt-v3' into for-next").
I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7, DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15) as well as the OMAP4 Panda and OMAP5 uEVM.
regards
Suman
Suman Anna (8):
ARM: DRA7: hwmod data: Add MMU data for IPUs
ARM: DRA7: hwmod data: Add MMU data for DSPs
ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
ARM: DRA7: hwmod_data: Add data for IPUs
ARM: DRA7: hwmod_data: Add data for DSPs
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 - arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 79 +++++++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 322 +++++++++++++++++++++++++++++ arch/arm/mach-omap2/pdata-quirks.c | 11 +- 4 files changed, 411 insertions(+), 3 deletions(-)
Signature · 1 line
2.13.1
PATCH 1/8 ARM: DRA7: hwmod data: Add MMU data for IPUs
A new MMU hwmod class and data structures are added for representing the MMUs within the IPU1 and IPU2 processor subsystems present on DRA7xx/AM57xx SoCs.
Note that the clock integration is slightly different between IPU1 and IPU2. IPU2 functional clock is sourced directly from dpll_core_h22x2_ck, while IPU1 has a mux clock for which one of the inputs is dpll_core_h22x2_ck. This mux clock is configured to be sourced from the dpll_core_h22x2_ck in turn, so that both IPU1 and IPU2 run at the same clock frequency. This is already addressed in commit 39879c7d963e ("ARM: dts: dra7xx-clocks:
Source IPU1 functional clock from CORE DPLL").
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 81 +++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +81 -0
@@ -1800,6 +1800,69 @@ static struct omap_hwmod dra7xx_mmc4_hwmod = { };/* +* 'mmu' class +* The memory management unit performs virtual to physical address translation +* for its requestors. +*/ + +static struct omap_hwmod_class_sysconfig dra7xx_mmu_sysc = { + .rev_offs =0x0000 , + .sysc_offs =0x0010 , + .syss_offs =0x0014 , + .sysc_flags = (SYSC_HAS_AUTOIDLE |SYSC_HAS_CLOCKACTIVITY | +SYSC_HAS_SIDLEMODE |SYSC_HAS_SOFTRESET | +SYSS_HAS_RESET_STATUS ), + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART ), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class dra7xx_mmu_hwmod_class = { + .name ="mmu" , + .sysc = &dra7xx_mmu_sysc, +}; + +/* IPU MMUs */ +static struct omap_hwmod_rst_info dra7xx_mmu_ipu_resets[] = { + { .name ="mmu_cache" , .rst_shift =2 }, +}; + +/* mmu ipu1 */ +static struct omap_hwmod dra7xx_mmu_ipu1_hwmod = { + .name ="mmu_ipu1" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="ipu1_clkdm" , + .rst_lines = dra7xx_mmu_ipu_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_ipu_resets), + .main_clk ="ipu1_gfclk_mux" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_IPU1_IPU1_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_IPU1_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_IPU1_IPU1_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; + +/* mmu ipu2 */ +static struct omap_hwmod dra7xx_mmu_ipu2_hwmod = { + .name ="mmu_ipu2" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="ipu2_clkdm" , + .rst_lines = dra7xx_mmu_ipu_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_ipu_resets), + .main_clk ="dpll_core_h22x2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_IPU2_IPU2_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_IPU2_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_IPU2_IPU2_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; + +/* * 'mpu' class * */
@@ -2901,6 +2964,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_cfg = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main_1 -> mmu_ipu1 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu1 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu_ipu1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* l3_main_1 -> mmu_ipu2 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu2 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu_ipu2_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_1 -> l4_per1 */ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_per1 = { .master = &dra7xx_l3_main_1_hwmod,
@@ -4010,6 +4089,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per1__mmc2, &dra7xx_l4_per1__mmc3, &dra7xx_l4_per1__mmc4, + &dra7xx_l3_main_1__mmu_ipu1, + &dra7xx_l3_main_1__mmu_ipu2, &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, &dra7xx_l4_cfg__ocp2scp3,
Signature · 1 line
2.13.1
PATCH 2/8 ARM: DRA7: hwmod data: Add MMU data for DSPs
In reply to Suman AnnaAdd the data structures for representing the MMUs within the DSP processor subsystems present in DRA7xx/AM57xx SoCs. The DRA7xx family of SoCs usually have one or two DSPs. The DRA74x/DRA76x family has two DSPs, while DRA72x/DRA71x has only a single DSP. Each DSP subsystem has two MMUs, one for the processor core and the other for the internal EDMA block. The hwmod data for the second DSP is only added for DRA74x/DRA76x family of SoCs.
Both these MMUs share a common reset line, the MMU on the EDMA port is expected to be mirror-programmed alongside the primary MMU. The reset data is added to both the MMUs to allow the omap_hwmod layer to skip the enabling and idling of these devices, as that would require the reset be released, which is outside the scope of the hwmod core code. The other PRCM data fields are also skipped for both the second MMUs, this will be handled as part of the primary MMU enabling sequence. The pdata quirks will also not be added for the second MMU as the OMAP IOMMU driver releases the reset once and is expected to program both the MMUs together.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 109 ++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +109 -0
@@ -1821,6 +1821,77 @@ static struct omap_hwmod_class dra7xx_mmu_hwmod_class = { .sysc = &dra7xx_mmu_sysc, }; +/* DSP MMUs */ +static struct omap_hwmod_rst_info dra7xx_mmu_dsp_resets[] = { + { .name ="mmu_cache" , .rst_shift =1 }, +}; + +/* mmu0 - dsp1 */ +static struct omap_hwmod dra7xx_mmu0_dsp1_hwmod = { + .name ="mmu0_dsp1" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="dsp1_clkdm" , + .rst_lines = dra7xx_mmu_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_DSP1_DSP1_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_DSP1_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_DSP1_DSP1_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; + +/* mmu1 - dsp1 */ +static struct omap_hwmod dra7xx_mmu1_dsp1_hwmod = { + .name ="mmu1_dsp1" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="dsp1_clkdm" , + .rst_lines = dra7xx_mmu_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .rstctrl_offs =DRA7XX_RM_DSP1_RSTCTRL_OFFSET , + }, + }, +}; + +/* mmu0 - dsp2 */ +static struct omap_hwmod dra7xx_mmu0_dsp2_hwmod = { + .name ="mmu0_dsp2" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="dsp2_clkdm" , + .rst_lines = dra7xx_mmu_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_DSP2_DSP2_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_DSP2_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_DSP2_DSP2_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; + +/* mmu1 - dsp2 */ +static struct omap_hwmod dra7xx_mmu1_dsp2_hwmod = { + .name ="mmu1_dsp2" , + .class = &dra7xx_mmu_hwmod_class, + .clkdm_name ="dsp2_clkdm" , + .rst_lines = dra7xx_mmu_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_mmu_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .rstctrl_offs =DRA7XX_RM_DSP2_RSTCTRL_OFFSET , + }, + }, +}; +/* IPU MMUs */ static struct omap_hwmod_rst_info dra7xx_mmu_ipu_resets[] = { { .name ="mmu_cache" , .rst_shift =2 },
@@ -2964,6 +3035,38 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_cfg = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main_1 -> mmu0_dsp1 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu0_dsp1 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu0_dsp1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* l3_main_1 -> mmu1_dsp1 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu1_dsp1 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu1_dsp1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* l3_main_1 -> mmu0_dsp2 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu0_dsp2 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu0_dsp2_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* l3_main_1 -> mmu1_dsp2 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu1_dsp2 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_mmu1_dsp2_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_1 -> mmu_ipu1 */ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mmu_ipu1 = { .master = &dra7xx_l3_main_1_hwmod,
@@ -4089,6 +4192,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per1__mmc2, &dra7xx_l4_per1__mmc3, &dra7xx_l4_per1__mmc4, + &dra7xx_l3_main_1__mmu0_dsp1, + &dra7xx_l3_main_1__mmu1_dsp1, &dra7xx_l3_main_1__mmu_ipu1, &dra7xx_l3_main_1__mmu_ipu2, &dra7xx_l4_cfg__mpu,
@@ -4153,11 +4258,15 @@ static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {/* SoC variant specific hwmod links */ static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[]__initdata = { &dra7xx_l4_per3__usb_otg_ss4, + &dra7xx_l3_main_1__mmu0_dsp2, + &dra7xx_l3_main_1__mmu1_dsp2,NULL , };static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[]__initdata = { &dra7xx_l4_per3__usb_otg_ss4, + &dra7xx_l3_main_1__mmu0_dsp2, + &dra7xx_l3_main_1__mmu1_dsp2,NULL , };
Signature · 1 line
2.13.1
PATCH 3/8 ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
In reply to Suman AnnaThe IOMMUs within the IPU processor subsystems in DRA7xx SoCs are very similar to those in OMAP4/OMAP5, so extend the OMAP4 iommu pdata quirks for these MMUs as well.
--- arch/arm/mach-omap2/pdata-quirks.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/pdata-quirks.c +6 -1
@@ -412,7 +412,8 @@ static void __init omap3_pandora_legacy_init(void) }#endif /* CONFIG_ARCH_OMAP3 */ -#if defined(CONFIG_ARCH_OMAP4 ) || defined(CONFIG_SOC_OMAP5 ) +#if defined(CONFIG_ARCH_OMAP4 ) || defined(CONFIG_SOC_OMAP5 ) || \ + defined(CONFIG_SOC_DRA7XX )static struct iommu_platform_data omap4_iommu_pdata = { .reset_name ="mmu_cache" , .assert_reset = omap_device_assert_hardreset,
@@ -588,6 +589,10 @@ static struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { &dra7_hsmmc_data_mmc2),OF_DEV_AUXDATA ("ti,dra7-hsmmc" ,0x480ad000 ,"480ad000.mmc" , &dra7_hsmmc_data_mmc3), +OF_DEV_AUXDATA ("ti,dra7-iommu" ,0x55082000 ,"55082000.mmu" , + &omap4_iommu_pdata), +OF_DEV_AUXDATA ("ti,dra7-iommu" ,0x58882000 ,"58882000.mmu" , + &omap4_iommu_pdata), #endif/* Common auxdata */ OF_DEV_AUXDATA("pinctrl-single", 0, NULL, &pcs_pdata),
Signature · 1 line
2.13.1
PATCH 4/8 ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
In reply to Suman AnnaThe DSP processor subsystem in DRA7xx SoCs has two MMUs, one for the processor port and another for an EDMA port. Both these MMUs share a common reset line, the MMU on the EDMA port will always be mirror-programmed alongside the primary MMU, with the reset handled once. The reset handling is the same as on equivalent DSP subsystems on OMAP4/OMAP5 SoCs, so extend the OMAP4 iommu pdata quirks for reset for the MMU associated with the processor port only.
Add these pdata quirks for both the DSP1 and DSP2 processor subsystems. Note that DSP2 subsystem is present only on the DRA74x/DRA76x SoC variants and not on DRA72x/DRA71x SoCs.
--- arch/arm/mach-omap2/pdata-quirks.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm/mach-omap2/pdata-quirks.c +4 -0
@@ -589,6 +589,10 @@ static struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { &dra7_hsmmc_data_mmc2),OF_DEV_AUXDATA ("ti,dra7-hsmmc" ,0x480ad000 ,"480ad000.mmc" , &dra7_hsmmc_data_mmc3), +OF_DEV_AUXDATA ("ti,dra7-dsp-iommu" ,0x40d01000 ,"40d01000.mmu" , + &omap4_iommu_pdata), +OF_DEV_AUXDATA ("ti,dra7-dsp-iommu" ,0x41501000 ,"41501000.mmu" , + &omap4_iommu_pdata),OF_DEV_AUXDATA ("ti,dra7-iommu" ,0x55082000 ,"55082000.mmu" , &omap4_iommu_pdata), OF_DEV_AUXDATA("ti,dra7-iommu", 0x58882000, "58882000.mmu",
Signature · 1 line
2.13.1
PATCH 5/8 ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
In reply to Suman AnnaThe .modulemode field is removed from both the IPU and DSP processor hwmods. This fixes a potential kernel crash during the shutdown sequence of any of these remoteproc devices, either during a normal teardown or during a recovery.
The DSP and IPU processor subsystems are represented by multiple hwmods, one for each of the MMUs present within the subsystem and one for the processor cores. The processor subsystem is clocked from a single clock source with separate reset lines for each of the processors and the MMUs. This clock and reset information is represented in separate hwmods to allow the management of these entities in different drivers operating on the corresponding platform devices. This doesn't fit quite well into the current omap_hwmod layer due to these inter-dependencies.
A remoteproc startup sequence involves enabling and programming of the MMUs, loading of the firmware into RAM mapped by the MMUs, and releasing the processors from reset. A shutdown sequence follows a reverse pattern with the processors put into reset first followed by the unmapping and disabling of the MMUs. Both the processors and the MMUs are present within a single clock domain and requires the domain be clocked and enabled until the last entity. The kernel crash can happen during the unmapping phase of the MMUs, as the hwmod layer disables the module during the omap_device_idle processing of the processor hwmod. This issue is fixed by not defining a modulemode for the IPU/DSP processors, which results in keeping the module in an activated state. The module is disabled properly during the omap_device_idle processing of the MMU hwmod while disabling the MMU.
--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 -- 1 file changed, 2 deletions(-)
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -2
@@ -550,7 +550,6 @@ static struct omap_hwmod omap44xx_dsp_hwmod = { .clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET, .rstctrl_offs = OMAP4_RM_TESLA_RSTCTRL_OFFSET, .context_offs = OMAP4_RM_TESLA_TESLA_CONTEXT_OFFSET, - .modulemode = MODULEMODE_HWCTRL, }, }, };
@@ -1561,7 +1560,6 @@ static struct omap_hwmod omap44xx_ipu_hwmod = { .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET, .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET, .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET, - .modulemode = MODULEMODE_HWCTRL, }, }, };
Signature · 1 line
2.13.1
Tony Lindgren
maintainerPATCH 5/8 ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
Quoted 12 lines · Suman Anna
A shutdown sequence follows a reverse pattern
with the processors put into reset first followed by the unmapping and disabling of the MMUs. Both the processors and the MMUs are present within a single clock domain and requires the domain be clocked and enabled until the last entity. The kernel crash can happen during the unmapping phase of the MMUs, as the hwmod layer disables the module during theomap_device_idleprocessing of the processor hwmod. This issue is fixed by not defining a modulemode for the IPU/DSP processors, which results in keeping the module in an activated state. The module is disabled properly during theomap_device_idleprocessing of the MMU hwmod while disabling the MMU.
I think a better way to fix this would be to make sure the module is enabled during the unmapping phase of the MMUs. If there is no driver left at that point to call pm_runtime_get() on the module, do it via pdata-quirks.c using struct iommu_platform_data?
If you can't add the enable/disable around existing assert_reset/ deassert_reset, you can add a new one.
Regards,
Tony
PATCH 5/8 ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
Hi Tony,
Quoted 14 lines · Tony Lindgren
Quoted 12 lines · Suman Anna
A shutdown sequence follows a reverse pattern
with the processors put into reset first followed by the unmapping and disabling of the MMUs. Both the processors and the MMUs are present within a single clock domain and requires the domain be clocked and enabled until the last entity. The kernel crash can happen during the unmapping phase of the MMUs, as the hwmod layer disables the module during theomap_device_idleprocessing of the processor hwmod. This issue is fixed by not defining a modulemode for the IPU/DSP processors, which results in keeping the module in an activated state. The module is disabled properly during theomap_device_idleprocessing of the MMU hwmod while disabling the MMU.
Quoted 4 lines
I think a better way to fix this would be to make sure the module is enabled during the unmapping phase of the MMUs. If there is no driver left at that point to call
pm_runtime_get()on the module, do it viapdata-quirks.cusing structiommu_platform_data?
The problem is because there is no reference counting on modulemode programming unlike clocks or omap_device pm_domain callbacks. The IOMMU driver already has an active pm_runtime_get() invoked earlier and invoking another wouldn't result in any change.
Quoted 2 lines
If you can't add the enable/disable around existing assert_reset/
deassert_reset, you can add a new one.
The remoteproc driver is only dealing with its resets and hwmod while the IOMMU driver is dealing with its dedicated reset. The PRCM registers though are a single set between the two.
regards
Suman
Tony Lindgren
maintainerPATCH 5/8 ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
Quoted 10 lines · Suman Anna
Quoted 4 lines · Tony Lindgren
I think a better way to fix this would be to make sure the module is enabled during the unmapping phase of the MMUs. If there is no driver left at that point to call
pm_runtime_get()on the module, do it viapdata-quirks.cusing structiommu_platform_data?The problem is because there is no reference counting on modulemode programming unlike clocks or
omap_devicepm_domaincallbacks. The IOMMU driver already has an activepm_runtime_get()invoked earlier and invoking another wouldn't result in any change.
Hmm iommu driver has pm_runtime_get() on which modules? Can you please point me to that code too so I can follow..
Or is there maybe a single module shared across multiple devices?
If so, we need a minimal module wrapper driver. You can do what we already do for musb on am335x in drivers/usb/musb/musb_am335x.c. A single module has two musb instances and a shared cppi41 dma instance. See also it's related entries in am33xx.dtsi.
Note that the clkctrl clocks are available now as clocks, so they could be directly enabled for testing. See omap4_tesla_clkctrl_regs and omap4_ducati_clkctrl_regs if that helps.
Quoted 3 lines
The remoteproc driver is only dealing with its resets and hwmod while the IOMMU driver is dealing with its dedicated reset. The PRCM registers though are a single set between the two.
Sorry but I'm having hard time following which driver claims which modules :)
Regards,
Tony
PATCH 5/8 ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
Hi Tony,
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Suman Anna
Quoted 4 lines · Tony Lindgren
I think a better way to fix this would be to make sure the module is enabled during the unmapping phase of the MMUs. If there is no driver left at that point to call
pm_runtime_get()on the module, do it viapdata-quirks.cusing structiommu_platform_data?
Quoted 7 lines
Quoted 4 lines
The problem is because there is no reference counting on modulemode programming unlike clocks or
omap_devicepm_domaincallbacks. The IOMMU driver already has an activepm_runtime_get()invoked earlier and invoking another wouldn't result in any change.Hmm iommu driver has
pm_runtime_get()on which modules? Can you please point me to that code too so I can follow..
The OMAP IOMMU driver deals with the MMU device only and uses both the omap_device_{assert/deassert}_hardreset and omap_device_{enable/idle} on the omap_device associated with the MMU device. The MMU register space has a SYSCONFIG register (also has softreset that only resets the MMU block) so we do have a hwmod associated with it to deal with its setting. Today, the reset API is invoked through pdata-quirks and the omap_device_{enable/idle} API through the pm_runtime in the IOMMU driver. Lookup iommu_enable() and iommu_disable() in drivers/iommu/omap-iommu.c
Quoted 1 line
Or is there maybe a single module shared across multiple devices?
Yeah kinda. The PRCM registers are just one set, with different bits in RSTCTRL and RSTST registers dealing with different reset lines. The API to deal with resets is still using the omap_device API and they are invoked using pdata-quirks. For OMAP remoteproc driver, we only have one pdata quirks defined, but the function we plug in invokes both the reset as well as the omap_device_enable/idle functions (not in mainline yet). See [1] for reference.
So, we have a unique hwmod/omap_device associated with each of the individual devices (IOMMU and the processor are represented as a device each).
Quoted 8 lines
If so, we need a minimal module wrapper driver. You can do what we already do for musb on am335x in
drivers/usb/musb/musb_am335x.c. A single module has two musb instances and a shared cppi41 dma instance. See also it's related entries inam33xx.dtsi.Note that the clkctrl clocks are available now as clocks, so they could be directly enabled for testing. See
omap4_tesla_clkctrl_regsandomap4_ducati_clkctrl_regsif that helps.
OK, looks like these are recent additions by Tero. It will still be a shared set between the MMU and remoteproc drivers, but let me look into how these get integrated. At this point, I don't want to be dealing with separate clk API in my driver.
Quoted 6 lines
Quoted 3 lines
The remoteproc driver is only dealing with its resets and hwmod while the IOMMU driver is dealing with its dedicated reset. The PRCM registers though are a single set between the two.
Sorry but I'm having hard time following which driver claims which modules :)
OMAP IOMMU driver claims and deals with the MMU device in each of the DSP and IPU subsystems. The OMAP remoteproc driver deals with the DSP or the Cortex-M3/M4 cores.
regards
Suman
PATCH 6/8 ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
In reply to Suman AnnaOMAP5, like OMAP4, also has an IPU and a DSP processor subsystems. The relevant hwmod classes and data structures are added for these devices.
Do note that these hwmod data strucutures do not have a .modulemode field as the devices are managed together with their corresponding MMUs. Each of the processor subsystem and its MMU are present within the same clock domain and requires the domain be clocked and enabled until the last entity is disabled. The module is disabled properly during the omap_device_idle processing of the MMU hwmod while disabling the MMU.
--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 79 ++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+)
arch/arm/mach-omap2/omap_hwmod_54xx_data.c +79 -0
@@ -335,6 +335,36 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { };/* +* 'dsp' class +* dsp sub-system +*/ + +static struct omap_hwmod_class omap54xx_dsp_hwmod_class = { + .name ="dsp" , +}; + +static struct omap_hwmod_rst_info omap54xx_dsp_resets[] = { + { .name ="dsp" , .rst_shift =0 }, +}; + +/* dsp */ +static struct omap_hwmod omap54xx_dsp_hwmod = { + .name ="dsp" , + .class = &omap54xx_dsp_hwmod_class, + .clkdm_name ="dsp_clkdm" , + .rst_lines = omap54xx_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (omap54xx_dsp_resets), + .main_clk ="dpll_iva_h11x2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET , + .rstctrl_offs =OMAP54XX_RM_DSP_RSTCTRL_OFFSET , + .context_offs =OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET , + }, + }, +}; + +/* * 'dss' class * display sub-system */
@@ -940,6 +970,37 @@ static struct omap_hwmod omap54xx_i2c5_hwmod = { };/* +* 'ipu' class +* image processor unit +*/ + +static struct omap_hwmod_class omap54xx_ipu_hwmod_class = { + .name ="ipu" , +}; + +static struct omap_hwmod_rst_info omap54xx_ipu_resets[] = { + { .name ="cpu0" , .rst_shift =0 }, + { .name ="cpu1" , .rst_shift =1 }, +}; + +/* ipu */ +static struct omap_hwmod omap54xx_ipu_hwmod = { + .name ="ipu" , + .class = &omap54xx_ipu_hwmod_class, + .clkdm_name ="ipu_clkdm" , + .rst_lines = omap54xx_ipu_resets, + .rst_lines_cnt =ARRAY_SIZE (omap54xx_ipu_resets), + .main_clk ="dpll_core_h22x2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =OMAP54XX_CM_IPU_IPU_CLKCTRL_OFFSET , + .rstctrl_offs =OMAP54XX_RM_IPU_RSTCTRL_OFFSET , + .context_offs =OMAP54XX_RM_IPU_IPU_CONTEXT_OFFSET , + }, + }, +}; + +/* * 'kbd' class * keyboard controller */
@@ -2135,6 +2196,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_1 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* dsp -> l3_main_1 */ +static struct omap_hwmod_ocp_if omap54xx_dsp__l3_main_1 = { + .master = &omap54xx_dsp_hwmod, + .slave = &omap54xx_l3_main_1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l4_cfg -> mmu_dsp */ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mmu_dsp = { .master = &omap54xx_l4_cfg_hwmod,
@@ -2167,6 +2236,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_2 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main_2 -> ipu */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__ipu = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_ipu_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_2 -> mmu_ipu */ static struct omap_hwmod_ocp_if omap54xx_l3_main_2__mmu_ipu = { .master = &omap54xx_l3_main_2_hwmod,
@@ -2766,7 +2843,9 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = { &omap54xx_l3_main_3__l3_instr, &omap54xx_l3_main_2__l3_main_1, &omap54xx_l4_cfg__l3_main_1, + &omap54xx_dsp__l3_main_1, &omap54xx_mpu__l3_main_1, + &omap54xx_l3_main_2__ipu, &omap54xx_l3_main_1__l3_main_2, &omap54xx_l4_cfg__l3_main_2, &omap54xx_l3_main_1__l3_main_3,
Signature · 1 line
2.13.1
Tony Lindgren
maintainerPATCH 6/8 ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
Quoted 11 lines · Suman Anna
OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems. The relevant hwmod classes and data structures are added for these devices.
Do note that these hwmod data strucutures do not have a .modulemode field as the devices are managed together with their corresponding MMUs. Each of the processor subsystem and its MMU are present within the same clock domain and requires the domain be clocked and enabled until the last entity is disabled. The module is disabled properly during the
omap_device_idleprocessing of the MMU hwmod while disabling the MMU.
I think we can make that issue go away, see below.
Quoted 11 lines
arch/arm/mach-omap2/omap_hwmod_54xx_data.c +8
-0@@ -335,6 +335,36 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { +/* dsp */ +static struct omap_hwmod omap54xx_dsp_hwmod = { + .name ="dsp" , + .class = &omap54xx_dsp_hwmod_class, + .clkdm_name ="dsp_clkdm" , + .rst_lines = omap54xx_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (omap54xx_dsp_resets), + .main_clk ="dpll_iva_h11x2_ck" ,
arch/arm/mach-omap2/omap_hwmod_54xx_data.c static struct omap_hwmod omap54xx_dmic_hwmod = { · line 352
Quoted 10 lines
arch/arm/mach-omap2/omap_hwmod_54xx_data.c +10
-0+ .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET, + .rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET, + .context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET, + }, + }, +}; + +/*
I don't think we should add a second instance for the DSP_CLKCTRL.
We already have mmu_dsp instance and I'm pretty sure this should be just one parent "ti,sysc-omap4" interconnect target module instance. Then the MMU and DSP can be children of that node. I think it's set the same way for all omap4 and later SoCs. So let's wait on this series until we have this verified.
Tehn for resets, in the long run we can add reset controller support to the ti-sysc driver and then the MMU driver can do the reset with device_reset(dev->parent). Also a separate resetctrl driver is needed that the ti-sysc driver can request.
But yeah sorry no immediate solution available for the reset part.
Regards,
Tony
PATCH 7/8 ARM: DRA7: hwmod_data: Add data for IPUs
In reply to Suman AnnaThe DRA7xx family of SoCs usually have two IPU remote processor subsystems. These subsystems are very similar to the respective processor subsystems on OMAP4/OMAP5 in terms of clock and reset integration. The relevant hwmod classes and data structures are added for IPU1 and IPU2 remoteproc devices that's present on almost all DRA7xx/AM57xx SoCs.
Do note that these hwmod data structures do not have a .modulemode field as the devices are managed together with their corresponding MMUs. Each of the processor subsystem and its MMU are present within the same clock domain and requires the domain be clocked and enabled until the last entity is disabled. The module is disabled properly during the omap_device_idle processing of the MMU hwmod while disabling the MMU.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 66 +++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +66 -0
@@ -1201,6 +1201,54 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = { };/* +* 'ipu' class +* image processor unit +*/ + +static struct omap_hwmod_class dra7xx_ipu_hwmod_class = { + .name ="ipu" , +}; + +static struct omap_hwmod_rst_info dra7xx_ipu_resets[] = { + { .name ="cpu0" , .rst_shift =0 }, + { .name ="cpu1" , .rst_shift =1 }, +}; + +/* ipu1 processor */ +static struct omap_hwmod dra7xx_ipu1_hwmod = { + .name ="ipu1" , + .class = &dra7xx_ipu_hwmod_class, + .clkdm_name ="ipu1_clkdm" , + .rst_lines = dra7xx_ipu_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_ipu_resets), + .main_clk ="ipu1_gfclk_mux" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_IPU1_IPU1_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_IPU1_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_IPU1_IPU1_CONTEXT_OFFSET , + }, + }, +}; + +/* ipu2 processor */ +static struct omap_hwmod dra7xx_ipu2_hwmod = { + .name ="ipu2" , + .class = &dra7xx_ipu_hwmod_class, + .clkdm_name ="ipu2_clkdm" , + .rst_lines = dra7xx_ipu_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_ipu_resets), + .main_clk ="dpll_core_h22x2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_IPU2_IPU2_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_IPU2_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_IPU2_IPU2_CONTEXT_OFFSET , + }, + }, +}; + +/* * 'mailbox' class * */
@@ -3492,6 +3540,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c5 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* ipu1 -> l3_main_1 */ +static struct omap_hwmod_ocp_if dra7xx_ipu1__l3_main_1 = { + .master = &dra7xx_ipu1_hwmod, + .slave = &dra7xx_l3_main_1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* ipu2 -> l3_main_1 */ +static struct omap_hwmod_ocp_if dra7xx_ipu2__l3_main_1 = { + .master = &dra7xx_ipu2_hwmod, + .slave = &dra7xx_l3_main_1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l4_cfg -> mailbox1 */ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__mailbox1 = { .master = &dra7xx_l4_cfg_hwmod,
@@ -4171,6 +4235,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per1__i2c3, &dra7xx_l4_per1__i2c4, &dra7xx_l4_per1__i2c5, + &dra7xx_ipu1__l3_main_1, + &dra7xx_ipu2__l3_main_1, &dra7xx_l4_cfg__mailbox1, &dra7xx_l4_per3__mailbox2, &dra7xx_l4_per3__mailbox3,
Signature · 1 line
2.13.1
PATCH 8/8 ARM: DRA7: hwmod_data: Add data for DSPs
In reply to Suman AnnaThe DRA7xx family of SoCs can have up to two identical DSP processor subsystems, with most of them having a single DSP processor subsystem. The second DSP is present only on DRA74x and DRA76x variants currently.
These subsystems are very similar to the respective processor subsystems on OMAP4/OMAP5 in terms of clock and reset integration. The relevant hwmod class and data structures are added for both the DSP remoteproc devices, with the data for DSP2 added only on DRA74x/DRA76x variants.
Do note that these hwmod data structures do not have a .modulemode field as the devices are managed together with their corresponding MMUs. Each of the processor subsystem and its MMU are present within the same clock domain and requires the domain be clocked and enabled until the last entity is disabled. The module is disabled properly during the omap_device_idle processing of the MMU hwmod while disabling the MMU.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 66 +++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +66 -0
@@ -555,6 +555,53 @@ static struct omap_hwmod dra7xx_tptc1_hwmod = { };/* +* 'dsp' class +* dsp sub-system +*/ + +static struct omap_hwmod_class dra7xx_dsp_hwmod_class = { + .name ="dsp" , +}; + +static struct omap_hwmod_rst_info dra7xx_dsp_resets[] = { + { .name ="dsp" , .rst_shift =0 }, +}; + +/* dsp1 processor */ +static struct omap_hwmod dra7xx_dsp1_hwmod = { + .name ="dsp1" , + .class = &dra7xx_dsp_hwmod_class, + .clkdm_name ="dsp1_clkdm" , + .rst_lines = dra7xx_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_DSP1_DSP1_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_DSP1_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_DSP1_DSP1_CONTEXT_OFFSET , + }, + }, +}; + +/* dsp2 processor */ +static struct omap_hwmod dra7xx_dsp2_hwmod = { + .name ="dsp2" , + .class = &dra7xx_dsp_hwmod_class, + .clkdm_name ="dsp2_clkdm" , + .rst_lines = dra7xx_dsp_resets, + .rst_lines_cnt =ARRAY_SIZE (dra7xx_dsp_resets), + .main_clk ="dpll_dsp_m2_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_DSP2_DSP2_CLKCTRL_OFFSET , + .rstctrl_offs =DRA7XX_RM_DSP2_RSTCTRL_OFFSET , + .context_offs =DRA7XX_RM_DSP2_DSP2_CONTEXT_OFFSET , + }, + }, +}; + +/* * 'dss' class * */
@@ -3266,6 +3313,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__tptc1 = { .user = OCP_USER_MPU, }; +/* dsp1 -> l3_main_1 */ +static struct omap_hwmod_ocp_if dra7xx_dsp1__l3_main_1 = { + .master = &dra7xx_dsp1_hwmod, + .slave = &dra7xx_l3_main_1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* dsp2 -> l3_main_1 */ +static struct omap_hwmod_ocp_if dra7xx_dsp2__l3_main_1 = { + .master = &dra7xx_dsp2_hwmod, + .slave = &dra7xx_l3_main_1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_1 -> dss */ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dss = { .master = &dra7xx_l3_main_1_hwmod,
@@ -4215,6 +4278,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l3_main_1__tptc1, &dra7xx_l3_main_1__dss, &dra7xx_l3_main_1__dispc, + &dra7xx_dsp1__l3_main_1, &dra7xx_l3_main_1__hdmi, &dra7xx_l3_main_1__aes1, &dra7xx_l3_main_1__aes2,
@@ -4326,6 +4390,7 @@ static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per3__usb_otg_ss4, &dra7xx_l3_main_1__mmu0_dsp2, &dra7xx_l3_main_1__mmu1_dsp2, + &dra7xx_dsp2__l3_main_1, NULL, };
@@ -4333,6 +4398,7 @@ static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per3__usb_otg_ss4, &dra7xx_l3_main_1__mmu0_dsp2, &dra7xx_l3_main_1__mmu1_dsp2, + &dra7xx_dsp2__l3_main_1, NULL, };
Signature · 1 line
2.13.1
cover Add hwmod data for IPU & DSP processors/MMUs
In reply to Suman AnnaTony,
Quoted 11 lines · Suman Anna
Hi Tony,
The following series adds the hwmod data and the corresponding pdata quirks for the various MMUs associated with the IPU and DSP processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already supported on mainline) and providing a baseline for adding the OMAP remoteproc driver. The hwmod data for the consumers of these MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs, with an update to the OMAP4 ones.
Quoted 6 lines
Patches are baselined on your current for-next branch with commit
a70cb93b6c2f("Merge branch 'omap-for-v4.14/dt-v3' into for-next").I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7, DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15) as well as the OMAP4 Panda and OMAP5 uEVM.
Ping on this series. Tero's clkctrl series changes are orthogonal to these changes.
regards
Suman
Quoted 20 lines
regards
SumanSuman Anna (8):
ARM: DRA7: hwmod data: Add MMU data for IPUs
ARM: DRA7: hwmod data: Add MMU data for DSPs
ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
ARM: OMAP4:hwmod_data: Remove modulemode from IPU/DSP hwmods
ARM: OMAP5:hwmod_data: Add data for IPU & DSP processors
ARM: DRA7:hwmod_data: Add data for IPUs
ARM: DRA7:hwmod_data: Add data for DSPsarch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 - arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 79 +++++++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 322 +++++++++++++++++++++++++++++ arch/arm/mach-omap2/pdata-quirks.c | 11 +- 4 files changed, 411 insertions(+), 3 deletions(-)
Tony Lindgren
maintainercover Add hwmod data for IPU & DSP processors/MMUs
Quoted 2 lines · Suman Anna
Ping on this series. Tero's clkctrl series changes are orthogonal to these changes.
With patch 5/8 you said earlier "It will still be a shared set between the MMU and remoteproc drivers, but let me look into how these get integrated." So was there any conclusion there?
Also, what's the deal with these omap4 changes that I commented on in 5/8?
Regards,
Tony
cover Add hwmod data for IPU & DSP processors/MMUs
Quoted 10 lines · Tony Lindgren
Quoted 2 lines · Suman Anna
Ping on this series. Tero's clkctrl series changes are orthogonal to these changes.
With patch 5/8 you said earlier "It will still be a shared set between the MMU and remoteproc drivers, but let me look into how these get integrated." So was there any conclusion there?
Also, what's the deal with these omap4 changes that I commented on in 5/8?
Tony,
So, looking at code, removing modulemode on hwmod does change the semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl will return 0) into the hwmod and will fall back. So, this should make it compatible to the existing code before adding the clkctrl dt nodes, and Patch 5 will be good to avoid the crash when disabling the processor nodes. That said, now that the modulemode is controlled by the ti-clkctrl code, I would expect to get the refcounting for free due to clk_enable() semantics if the same clkctrl clk is plugged under two nodes (MMU and processor) and I may not need to remove the modulemode. One of the main reasons for removing the modulemode is the lack of refcounting on modulemode in the original code.
In anycase, I need to retest this with all of required patches from Tero (current mainline does not yet have the clkctrl dt nodes).
Tero,
Do you have these patches rebased onto 4.14-rc1 (preferable if it is rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking from your github test branch (based on 4.13-rc3), but am running into some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.
regards
Suman
Tony Lindgren
maintainercover Add hwmod data for IPU & DSP processors/MMUs
Quoted 12 lines · Suman Anna
Quoted 10 lines · Tony Lindgren
Quoted 2 lines · Suman Anna
Ping on this series. Tero's clkctrl series changes are orthogonal to these changes.
With patch 5/8 you said earlier "It will still be a shared set between the MMU and remoteproc drivers, but let me look into how these get integrated." So was there any conclusion there?
Also, what's the deal with these omap4 changes that I commented on in 5/8?
Quoted 12 lines
Tony,
So, looking at code, removing modulemode on hwmod does change the semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrlwill return 0) into the hwmod and will fall back. So, this should make it compatible to the existing code before adding the clkctrl dt nodes, and Patch 5 will be good to avoid the crash when disabling the processor nodes. That said, now that the modulemode is controlled by the ti-clkctrl code, I would expect to get the refcounting for free due toclk_enable()semantics if the same clkctrl clk is plugged under two nodes (MMU and processor) and I may not need to remove the modulemode. One of the main reasons for removing the modulemode is the lack of refcounting on modulemode in the original code.
OK. Sounds like you can get the refcounting for free just by modifying the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:
dts: Use ti-sysc module driver for omap4 musb" in that series. You will need also the rest of the patches from that series naturally :)
That is as long as MMU and processor are both child devices in the same interconnect target module.
Quoted 2 lines
In anycase, I need to retest this with all of required patches from Tero (current mainline does not yet have the clkctrl dt nodes).
OK
Quoted 5 lines
Tero,
Do you have these patches rebased onto 4.14-rc1 (preferable if it is rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking from your github test branch (based on 4.13-rc3), but am running into some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.
Yeah I noticed that and emailed Tero about it. It seems to trigger with built-in musb and DEBUG_KERNEL disabled, not sure what triggers it. Only happens after the clkctrl nodes are added.
Regards,
Tony
cover Add hwmod data for IPU & DSP processors/MMUs
?
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Quoted 45 lines · Tony Lindgren
Quoted 12 lines · Suman Anna
Quoted 10 lines · Tony Lindgren
Quoted 2 lines · Suman Anna
Ping on this series. Tero's clkctrl series changes are orthogonal to these changes.
With patch 5/8 you said earlier "It will still be a shared set between the MMU and remoteproc drivers, but let me look into how these get integrated." So was there any conclusion there?
Also, what's the deal with these omap4 changes that I commented on in 5/8?
Quoted 12 lines
Tony,
So, looking at code, removing modulemode on hwmod does change the semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrlwill return 0) into the hwmod and will fall back. So, this should make it compatible to the existing code before adding the clkctrl dt nodes, and Patch 5 will be good to avoid the crash when disabling the processor nodes. That said, now that the modulemode is controlled by the ti-clkctrl code, I would expect to get the refcounting for free due toclk_enable()semantics if the same clkctrl clk is plugged under two nodes (MMU and processor) and I may not need to remove the modulemode. One of the main reasons for removing the modulemode is the lack of refcounting on modulemode in the original code.OK. Sounds like you can get the refcounting for free just by modifying the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:
dts: Use ti-sysc module driver for omap4 musb" in that series. You will need also the rest of the patches from that series naturally :)That is as long as MMU and processor are both child devices in the same interconnect target module.
Quoted 2 lines
In anycase, I need to retest this with all of required patches from Tero (current mainline does not yet have the clkctrl dt nodes).
OK
Quoted 5 lines
Tero,
Do you have these patches rebased onto 4.14-rc1 (preferable if it is rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking from your github test branch (based on 4.13-rc3), but am running into some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.
Quoted 3 lines
Yeah I noticed that and emailed Tero about it. It seems to trigger with built-in musb and
DEBUG_KERNELdisabled, not sure what triggers it. Only happens after the clkctrl nodes are added.
In my tree, you can find 4.14-rc1-clkctrl-cleanup branch. It can still be considered WIP, as I haven't posted it publicly and am working with some late quirks on it.
-Tero