How do I get slimbus hwmod information?

How do I get slimbus hwmod information?

[Marc Butler]

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

Re: How do I get slimbus hwmod information?

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7923 bytes --]

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.

On Wed, 4 Jan 2012, Marc Butler wrote:

> 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? 

A good starting point is included below.

> 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!

> 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


diff --git a/outputs/omap4430/2.0/omap_hwmod_44xx_data.c b/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
index 308e620..3d8b0cb 100644
--- a/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
+++ b/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
@@ -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,

Re: How do I get slimbus hwmod information?

[Marc Butler]

On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote:
> 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.

> On Wed, 4 Jan 2012, Marc Butler wrote:
> > 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? 
> 
> A good starting point is included below.

Thank you.

> > 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.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How do I get slimbus hwmod information?

[Paul Walmsley]

cc Peter, Liam, Kevin, Mike

On Mon, 30 Jan 2012, Marc Butler wrote:

> On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote:
> 
> > 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.

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.

> 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 <lrg@ti.com> and 
Peter Ujfalusi <peter.ujfalusi@ti.com> 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 <mturquette@ti.com> 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

Re: How do I get slimbus hwmod information?

[Marc Butler]

Paul,

Sorry it has taken so long reply. Unavoidable and sudden interruption.

On Mon, Jan 30, 2012 at 02:43:34PM -0700, Paul Walmsley wrote:
> On Mon, 30 Jan 2012, Marc Butler wrote:
> > On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote:
> > > 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.
> 
> 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. :)

> 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 <lrg@ti.com> and 
> Peter Ujfalusi <peter.ujfalusi@ti.com> 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. :)

> 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 <mturquette@ti.com> 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.