How do I get slimbus hwmod information?
Currently omap_hwmod_44xx_data.c has slimbus1/slimbus2 included in the list of excluded IPs.
Is it possible to get a version of omap_hwmod_44xx_data.c generated with slimbus1/2 included?
I want this as I am currently working on a driver for the slimbus modules, based on the SLIMbus RFC patch posted last year.
I am concerned that I do not understand how the pieces for such a driver should be put together: should such a driver be built from the ground up with hwmod interfaces, or should they be added in as the driver stabilizes?
Thanks.
-m
cc Benoît
Hi
sorry for the delay, just caught this during a list sweep. The maintainer of the OMAP4 hwmod data is Benoît, so I'd suggest cc'ing him for OMAP4 hwmod data requests.
Quoted 5 lines · Marc Butler
Currently
omap_hwmod_44xx_data.chas slimbus1/slimbus2 included in the list of excluded IPs.Is it possible to get a version of
omap_hwmod_44xx_data.cgenerated with slimbus1/2 included?
A good starting point is included below.
Quoted 2 lines
I want this as I am currently working on a driver for the slimbus modules, based on the SLIMbus RFC patch posted last year.
That sounds really great!
Quoted 4 lines
I am concerned that I do not understand how the pieces for such a driver should be put together: should such a driver be built from the ground up with hwmod interfaces, or should they be added in as the driver stabilizes?
The driver shouldn't have any hwmod code in it. Any omap_device/omap_hwmod code that's needed should go into an appropriate file in arch/arm/mach-omap2. The device resource metadata will flow through the existing Linux resource system. Also, currently we are using the pm_runtime*() calls as the way to interface with the omap_hwmod/omap_device enable/idle code, so your driver should be written using those.
- Paul
outputs/omap4430/2.0/omap_hwmod_44xx_data.c +179 -2
@@ -711,8 +711,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {* prm * scrm * sl2if -* slimbus1 -* slimbus2 * usb_host_fs * usb_host_hs * usb_phy_cm
@@ -4066,6 +4064,181 @@ static struct omap_hwmod omap44xx_mpu_hwmod = { };/* +* 'slimbus' class +* bidirectional, multi-drop, multi-channel two-line serial interface between +* the device and external components +*/ + +static struct omap_hwmod_class_sysconfig omap44xx_slimbus_sysc = { + .rev_offs =0x0000 , + .sysc_offs =0x0010 , + .sysc_flags = (SYSC_HAS_RESET_STATUS |SYSC_HAS_SIDLEMODE | +SYSC_HAS_SOFTRESET ), + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +SIDLE_SMART_WKUP ), + .sysc_fields = &omap_hwmod_sysc_type2, +}; + +static struct omap_hwmod_class omap44xx_slimbus_hwmod_class = { + .name ="slimbus" , + .sysc = &omap44xx_slimbus_sysc, +}; + +/* slimbus1 */ +static struct omap_hwmod omap44xx_slimbus1_hwmod; +static struct omap_hwmod_irq_info omap44xx_slimbus1_irqs[] = { + { .irq =97 +OMAP44XX_IRQ_GIC_START }, + { .irq =-1 } +}; + +static struct omap_hwmod_dma_info omap44xx_slimbus1_sdma_reqs[] = { + { .name ="tx0" , .dma_req =84 +OMAP44XX_DMA_REQ_START }, + { .name ="tx1" , .dma_req =85 +OMAP44XX_DMA_REQ_START }, + { .name ="tx2" , .dma_req =86 +OMAP44XX_DMA_REQ_START }, + { .name ="tx3" , .dma_req =87 +OMAP44XX_DMA_REQ_START }, + { .name ="rx0" , .dma_req =88 +OMAP44XX_DMA_REQ_START }, + { .name ="rx1" , .dma_req =89 +OMAP44XX_DMA_REQ_START }, + { .name ="rx2" , .dma_req =90 +OMAP44XX_DMA_REQ_START }, + { .name ="rx3" , .dma_req =91 +OMAP44XX_DMA_REQ_START }, + { .dma_req =-1 } +}; + +static struct omap_hwmod_addr_space omap44xx_slimbus1_addrs[] = { + { + .pa_start =0x4012c000 , + .pa_end =0x4012c3ff , + .flags =ADDR_TYPE_RT + }, + { } +}; + +/* l4_abe -> slimbus1 */ +static struct omap_hwmod_ocp_if omap44xx_l4_abe__slimbus1 = { + .master = &omap44xx_l4_abe_hwmod, + .slave = &omap44xx_slimbus1_hwmod, + .clk ="ocp_abe_iclk" , + .addr = omap44xx_slimbus1_addrs, + .user =OCP_USER_MPU , +}; + +static struct omap_hwmod_addr_space omap44xx_slimbus1_dma_addrs[] = { + { + .pa_start =0x4902c000 , + .pa_end =0x4902c3ff , + .flags =ADDR_TYPE_RT + }, + { } +}; + +/* l4_abe -> slimbus1 (dma) */ +static struct omap_hwmod_ocp_if omap44xx_l4_abe__slimbus1_dma = { + .master = &omap44xx_l4_abe_hwmod, + .slave = &omap44xx_slimbus1_hwmod, + .clk ="ocp_abe_iclk" , + .addr = omap44xx_slimbus1_dma_addrs, + .user =OCP_USER_SDMA , +}; + +/* slimbus1 slave ports */ +static struct omap_hwmod_ocp_if *omap44xx_slimbus1_slaves[] = { + &omap44xx_l4_abe__slimbus1, + &omap44xx_l4_abe__slimbus1_dma, +}; + +static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = { + { .role ="fclk_1" , .clk ="slimbus1_fclk_1" }, + { .role ="fclk_0" , .clk ="slimbus1_fclk_0" }, + { .role ="fclk_2" , .clk ="slimbus1_fclk_2" }, + { .role ="slimbus_clk" , .clk ="slimbus1_slimbus_clk" }, +}; + +static struct omap_hwmod omap44xx_slimbus1_hwmod = { + .name ="slimbus1" , + .class = &omap44xx_slimbus_hwmod_class, + .clkdm_name ="abe_clkdm" , + .mpu_irqs = omap44xx_slimbus1_irqs, + .sdma_reqs = omap44xx_slimbus1_sdma_reqs, + .prcm = { + .omap4 = { + .clkctrl_offs =OMAP4_CM1_ABE_SLIMBUS_CLKCTRL_OFFSET , + .context_offs =OMAP4_RM_ABE_SLIMBUS_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, + .opt_clks = slimbus1_opt_clks, + .opt_clks_cnt =ARRAY_SIZE (slimbus1_opt_clks), + .slaves = omap44xx_slimbus1_slaves, + .slaves_cnt =ARRAY_SIZE (omap44xx_slimbus1_slaves), +}; + +/* slimbus2 */ +static struct omap_hwmod omap44xx_slimbus2_hwmod; +static struct omap_hwmod_irq_info omap44xx_slimbus2_irqs[] = { + { .irq =98 +OMAP44XX_IRQ_GIC_START }, + { .irq =-1 } +}; + +static struct omap_hwmod_dma_info omap44xx_slimbus2_sdma_reqs[] = { + { .name ="tx0" , .dma_req =92 +OMAP44XX_DMA_REQ_START }, + { .name ="tx1" , .dma_req =93 +OMAP44XX_DMA_REQ_START }, + { .name ="tx2" , .dma_req =94 +OMAP44XX_DMA_REQ_START }, + { .name ="tx3" , .dma_req =95 +OMAP44XX_DMA_REQ_START }, + { .name ="rx0" , .dma_req =96 +OMAP44XX_DMA_REQ_START }, + { .name ="rx1" , .dma_req =97 +OMAP44XX_DMA_REQ_START }, + { .name ="rx2" , .dma_req =98 +OMAP44XX_DMA_REQ_START }, + { .name ="rx3" , .dma_req =99 +OMAP44XX_DMA_REQ_START }, + { .dma_req =-1 } +}; + +static struct omap_hwmod_addr_space omap44xx_slimbus2_addrs[] = { + { + .pa_start =0x48076000 , + .pa_end =0x480763ff , + .flags =ADDR_TYPE_RT + }, + { } +}; + +/* l4_per -> slimbus2 */ +static struct omap_hwmod_ocp_if omap44xx_l4_per__slimbus2 = { + .master = &omap44xx_l4_per_hwmod, + .slave = &omap44xx_slimbus2_hwmod, + .clk ="l4_div_ck" , + .addr = omap44xx_slimbus2_addrs, + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* slimbus2 slave ports */ +static struct omap_hwmod_ocp_if *omap44xx_slimbus2_slaves[] = { + &omap44xx_l4_per__slimbus2, +}; + +static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = { + { .role ="fclk_1" , .clk ="slimbus2_fclk_1" }, + { .role ="fclk_0" , .clk ="slimbus2_fclk_0" }, + { .role ="slimbus_clk" , .clk ="slimbus2_slimbus_clk" }, +}; + +static struct omap_hwmod omap44xx_slimbus2_hwmod = { + .name ="slimbus2" , + .class = &omap44xx_slimbus_hwmod_class, + .clkdm_name ="l4_per_clkdm" , + .mpu_irqs = omap44xx_slimbus2_irqs, + .sdma_reqs = omap44xx_slimbus2_sdma_reqs, + .prcm = { + .omap4 = { + .clkctrl_offs =OMAP4_CM_L4PER_SLIMBUS2_CLKCTRL_OFFSET , + .context_offs =OMAP4_RM_L4PER_SLIMBUS2_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, + .opt_clks = slimbus2_opt_clks, + .opt_clks_cnt =ARRAY_SIZE (slimbus2_opt_clks), + .slaves = omap44xx_slimbus2_slaves, + .slaves_cnt =ARRAY_SIZE (omap44xx_slimbus2_slaves), +}; + +/* * 'smartreflex' class * smartreflex module (monitor silicon performance and outputs a measure of * performance error)
@@ -5504,6 +5677,10 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {/* mpu class */ &omap44xx_mpu_hwmod, +/* slimbus class */ + &omap44xx_slimbus1_hwmod, + &omap44xx_slimbus2_hwmod, +/* smartreflex class */ &omap44xx_smartreflex_core_hwmod, &omap44xx_smartreflex_iva_hwmod,
Quoted 3 lines · Paul Walmsley
sorry for the delay, just caught this during a list sweep. The maintainer of the OMAP4 hwmod data is Benoît, so I'd suggest cc'ing him for OMAP4 hwmod data requests.
No worries and thanks for the reply.
Quoted 8 lines · Marc Butler
Quoted 5 lines
Currently
omap_hwmod_44xx_data.chas slimbus1/slimbus2 included in the list of excluded IPs.Is it possible to get a version of
omap_hwmod_44xx_data.cgenerated with slimbus1/2 included?A good starting point is included below.
Thank you.
Quoted 5 lines
Quoted 4 lines
I am concerned that I do not understand how the pieces for such a driver should be put together: should such a driver be built from the ground up with hwmod interfaces, or should they be added in as the driver stabilizes?
Quoted 7 lines
The driver shouldn't have any hwmod code in it. Any omap_device/omap_hwmod code that's needed should go into an appropriate file in
arch/arm/mach-omap2. The device resource metadata will flow through the existing Linux resource system. Also, currently we are using the pm_runtime*() calls as the way to interface with the omap_hwmod/omap_device enable/idle code, so your driver should be written using those.
I believe I came to the conclusion that I need the hwmod support, inorder to build out the platform_* infrastructure the driver needs, to query/configure resources. The driver itself does not call hwmod directly.
A colleague is looking into this, and we are unclear what should be done in the case where you can choose alternate muxing of the pins? For instance slimbus2 module can be routed two distinct pads. Should this be handled in an appropriate board_*.c?
-m
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
cc Peter, Liam, Kevin, Mike
Quoted 10 lines · Marc Butler
Quoted 7 lines · Paul Walmsley
The driver shouldn't have any hwmod code in it. Any omap_device/omap_hwmod code that's needed should go into an appropriate file in
arch/arm/mach-omap2. The device resource metadata will flow through the existing Linux resource system. Also, currently we are using the pm_runtime*() calls as the way to interface with the omap_hwmod/omap_device enable/idle code, so your driver should be written using those.
Quoted 4 lines
I believe I came to the conclusion that I need the hwmod support, inorder to build out the platform_* infrastructure the driver needs, to query/configure resources. The driver itself does not call hwmod directly.
That sounds right. The other thing that the omap_device/hwmod infrastructure is good for is device reset and power management. Device reset probably won't need any driver modifications; the driver can just start under the assumption that everything has been reset to the POR values documented in the TRM. In terms of power management, your driver should use the pm_runtime*() functions to play nicely with the rest of the system :-) pm_runtime*() will call into omap_device*() which will call into omap_hwmod*() to ensure that clocks and other PM infrastructure are appropriately disabled, enabled, etc.
Quoted 4 lines
A colleague is looking into this, and we are unclear what should be done in the case where you can choose alternate muxing of the pins? For instance slimbus2 module can be routed two distinct pads. Should this be handled in an appropriate board_*.c?
Yes. N.B., AFAIK Tony Lindgren isn't taking any more board_*.c patches for mainline - the goal is to move all of that stuff to DT eventually. So if you're interested in submitting to mainline (which I hope you are :-) ) you might want to writethe driver to be able to use either platform_data or DT data for configuration. This might involve working on DT bindings; it might be worth including Liam Girdwood <[email protected]> and Peter Ujfalusi <[email protected]> on those discussions. They would also know if someone inside TI may have already written Slimbus drivers that haven't yet made it to mainline, but which may have wound up in some Android-related tree.
One other brief note is that there are some very interesting power management options that may be possible in the audio path that we may not have full support for in the PM infrastructure layers. Stuff like DPLL chaining and IP blocks with externally-driven functional clocks. I believe Mike Turquette <[email protected]> may have explored this area a bit, although perhaps not specifically with Slimbus. If there is any interaction of these features with Slimbus (which there may not be), I'd suggest pushing support for those features off to a second phase, and we should probably have a group discussion about how to handle those cases cleanly :-)
- Paul
Paul,
Sorry it has taken so long reply. Unavoidable and sudden interruption.
Quoted 9 lines · Paul Walmsley
Quoted 7 lines · Marc Butler
Quoted 1 line · Paul Walmsley
The driver shouldn't have any hwmod code in it. Any
I believe I came to the conclusion that I need the hwmod support, inorder to build out the platform_* infrastructure the driver needs, to query/configure resources. The driver itself does not call hwmod directly.
Quoted 9 lines
That sounds right. The other thing that the omap_device/hwmod infrastructure is good for is device reset and power management. Device reset probably won't need any driver modifications; the driver can just start under the assumption that everything has been reset to the POR values documented in the TRM. In terms of power management, your driver should use the pm_runtime*() functions to play nicely with the rest of the system :-) pm_runtime*() will call into omap_device*() which will call into omap_hwmod*() to ensure that clocks and other PM infrastructure are appropriately disabled, enabled, etc.
I'm delaying all but the simplest power management for the time being. The complexity is staggering, without even considering interaction the ABE, etc. I'm new to OMAP and need to stay in the wading pool for the time being, lest I drown. :)
Quoted 10 lines
Yes. N.B., AFAIK Tony Lindgren isn't taking any more board_*.c patches for mainline - the goal is to move all of that stuff to DT eventually. So if you're interested in submitting to mainline (which I hope you are :-) ) you might want to writethe driver to be able to use either
platform_dataor DT data for configuration. This might involve working on DT bindings; it might be worth including Liam Girdwood <[email protected]> and Peter Ujfalusi <[email protected]> on those discussions. They would also know if someone inside TI may have already written Slimbus drivers that haven't yet made it to mainline, but which may have wound up in some Android-related tree.
Based on your suggestion, we are looking at DT, however we may also need hwmod support for older trees. There is no mention of Slimbus in any of the Android trees, so far AFIAK. Thanks for the contacts. This is definitely intended to be submitted to the mainline. There is however a huge amount of work to be done. :)
Quoted 10 lines
One other brief note is that there are some very interesting power management options that may be possible in the audio path that we may not have full support for in the PM infrastructure layers. Stuff like DPLL chaining and IP blocks with externally-driven functional clocks. I believe Mike Turquette <[email protected]> may have explored this area a bit, although perhaps not specifically with Slimbus. If there is any interaction of these features with Slimbus (which there may not be), I'd suggest pushing support for those features off to a second phase, and we should probably have a group discussion about how to handle those cases cleanly :-)
As mentioned earlier, I am deferring all but the simplest PM this without ignoring it outright.