OMAP1: mcbsp clocks

OMAP1: mcbsp clocks

[Russell King - ARM Linux]

A question about OMAP1 mcbsp clocks.  From what I understand from the
OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two
clocks:

1. interface clock switchable between DSPPER_CK and DSPXOR_CK.
2. a function clock which could be DSPXOR_CK (mcbsp3), and
   CK_DPLL1OUT or MCBS1_CLKS (mcbsp1).

However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3
unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK.  As far as
I can see, DSP_CK (for the DSP processor) and API_CK (for system dma)
have nothing to do with mcbsp1,3.

So, the question is why is it this way, and what would be the effect
of correcting this so that both of these mcbsp units are associated
with their proper interface and function clocks?

On a related note, mcbsp2 has its own interface and function clocks,
both tied to ARMPER_CK, which it doesn't even claim.  Again - why
not?

And on that note, can someone explain to me the weird way idle stuff
is handled?  It seems that idle modes are only controlled in one
situation:

1. a clock has CLOCK_NO_IDLE_PARENT set
2. the parent has CLOCK_IDLE_CONTROL set

In other words, to invoke the idle state of a clock, it's _child_ needs
to be manipulated - manipulating the clock itself, even if it has
CLOCK_IDLE_CONTROL, has no effect on the idle states.  Why is this?

(There's also a bunch of clocks which have CLOCK_IDLE_CONTROL set
but which don't have any children, making the idle state for those
clocks effectively unreachable - bug?)

Re: OMAP1: mcbsp clocks

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090122 15:57]:
> A question about OMAP1 mcbsp clocks.  From what I understand from the
> OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two
> clocks:
> 
> 1. interface clock switchable between DSPPER_CK and DSPXOR_CK.
> 2. a function clock which could be DSPXOR_CK (mcbsp3), and
>    CK_DPLL1OUT or MCBS1_CLKS (mcbsp1).
>
> However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3
> unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK.  As far as
> I can see, DSP_CK (for the DSP processor) and API_CK (for system dma)
> have nothing to do with mcbsp1,3.

Well the omap1_mcbsp_request() does the dsp external peripheral reset,
so that explains the dsp_ck. The mcbsp can be used without any dsp
code, so that's why the reset is still in the mcbsp.

Don't know where the api_ck comes from, but it's there also in the
earlier code. Maybe it's just a left over from some experimental hacked
code to try to get the DMA working for audio?

> So, the question is why is it this way, and what would be the effect
> of correcting this so that both of these mcbsp units are associated
> with their proper interface and function clocks?

Worth a try, I think osk5912 uses mcbsp1. Anybody got a omap1 board
that uses mcbsp3?

> On a related note, mcbsp2 has its own interface and function clocks,
> both tied to ARMPER_CK, which it doesn't even claim.  Again - why
> not?

Well some clocks need to be enabled always to get things going..
See omap1_clk_init(), it enables armper_ck.

> And on that note, can someone explain to me the weird way idle stuff
> is handled?  It seems that idle modes are only controlled in one
> situation:
> 
> 1. a clock has CLOCK_NO_IDLE_PARENT set
> 2. the parent has CLOCK_IDLE_CONTROL set
> 
> In other words, to invoke the idle state of a clock, it's _child_ needs
> to be manipulated - manipulating the clock itself, even if it has
> CLOCK_IDLE_CONTROL, has no effect on the idle states.  Why is this?

I think this was because we never got the hardware idling working
properly. Some clocks need to keep their parents running with
CLOCK_NO_IDLE_PARENT whenever in use.

> (There's also a bunch of clocks which have CLOCK_IDLE_CONTROL set
> but which don't have any children, making the idle state for those
> clocks effectively unreachable - bug?)

Or unnecessary if the parent gets turned off when no users?

BTW, the spinlock recursion fix from Stanley Miao below should be
applied before tweaking mcbsp.c.

Basically we currently cannot use virtual clocks because of this
and the fact that the parent of the virtual clock may not be known
as pointed out by Paul Walmsley.

Regards,

Tony

[-- Attachment #2: mcbsp-spinlock-recursion.patch --]
[-- Type: text/x-diff, Size: 16031 bytes --]

>From da3e6559dbfb84e73b93e3bb6f923b3f1d98c487 Mon Sep 17 00:00:00 2001
From: Stanley.Miao <stanley.miao@windriver.com>
Date: Thu, 15 Jan 2009 17:33:26 +0200
Subject: [PATCH] OMAP: Fix McBSP spin_lock deadlock

A spin_lock deadlock will occur when omap_mcbsp_request() is invoked.

omap_mcbsp_request()
\- clk_enable(mcbsp->clk)         [takes and holds clockfw_lock]
    \- omap2_clk_enable()
       \- _omap2_clk_enable()
           \- omap_mcbsp_clk_enable()
              \- clk_enable(child clock)   [tries for clockfw_lock again]

mcbsp_clk is a virtual clock and it comprises several child clocks. when
enable mcbsp_clk in omap_mcbsp_request(), the enable function of mcbsp_clk
will enable its child clocks, then the deadlock occurs.

The solution is to remove the virtual clock and enable these child clocks in
omap_mcbsp_request() directly.

Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index ca7a0cc..575ba31 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -28,81 +28,8 @@
 #define DPS_RSTCT2_PER_EN	(1 << 0)
 #define DSP_RSTCT2_WD_PER_EN	(1 << 1)
 
-struct mcbsp_internal_clk {
-	struct clk clk;
-	struct clk **childs;
-	int n_childs;
-};
-
 #if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
-{
-	const char *clk_names[] = { "dsp_ck", "api_ck", "dspxor_ck" };
-	int i;
-
-	mclk->n_childs = ARRAY_SIZE(clk_names);
-	mclk->childs = kzalloc(mclk->n_childs * sizeof(struct clk *),
-				GFP_KERNEL);
-
-	for (i = 0; i < mclk->n_childs; i++) {
-		/* We fake a platform device to get correct device id */
-		struct platform_device pdev;
-
-		pdev.dev.bus = &platform_bus_type;
-		pdev.id = mclk->clk.id;
-		mclk->childs[i] = clk_get(&pdev.dev, clk_names[i]);
-		if (IS_ERR(mclk->childs[i]))
-			printk(KERN_ERR "Could not get clock %s (%d).\n",
-				clk_names[i], mclk->clk.id);
-	}
-}
-
-static int omap_mcbsp_clk_enable(struct clk *clk)
-{
-	struct mcbsp_internal_clk *mclk = container_of(clk,
-					struct mcbsp_internal_clk, clk);
-	int i;
-
-	for (i = 0; i < mclk->n_childs; i++)
-		clk_enable(mclk->childs[i]);
-	return 0;
-}
-
-static void omap_mcbsp_clk_disable(struct clk *clk)
-{
-	struct mcbsp_internal_clk *mclk = container_of(clk,
-					struct mcbsp_internal_clk, clk);
-	int i;
-
-	for (i = 0; i < mclk->n_childs; i++)
-		clk_disable(mclk->childs[i]);
-}
-
-static struct mcbsp_internal_clk omap_mcbsp_clks[] = {
-	{
-		.clk = {
-			.name 		= "mcbsp_clk",
-			.id		= 1,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-	{
-		.clk = {
-			.name 		= "mcbsp_clk",
-			.id		= 3,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-};
-
-#define omap_mcbsp_clks_size	ARRAY_SIZE(omap_mcbsp_clks)
-#else
-#define omap_mcbsp_clks_size	0
-static struct mcbsp_internal_clk __initdata *omap_mcbsp_clks;
-static inline void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
-{ }
+const char *clk_names[] = { "dsp_ck", "api_ck", "dspxor_ck" };
 #endif
 
 static void omap1_mcbsp_request(unsigned int id)
@@ -167,8 +94,9 @@ static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_McBSP1RX,
 		.tx_irq		= INT_McBSP1TX,
 		.ops		= &omap1_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
-		},
+		.clk_names	= clk_names,
+		.num_clks	= 3,
+	},
 	{
 		.phys_base	= OMAP1510_MCBSP2_BASE,
 		.dma_rx_sync	= OMAP_DMA_MCBSP2_RX,
@@ -184,7 +112,8 @@ static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_McBSP3RX,
 		.tx_irq		= INT_McBSP3TX,
 		.ops		= &omap1_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 3,
 	},
 };
 #define OMAP15XX_MCBSP_PDATA_SZ		ARRAY_SIZE(omap15xx_mcbsp_pdata)
@@ -202,7 +131,8 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_McBSP1RX,
 		.tx_irq		= INT_McBSP1TX,
 		.ops		= &omap1_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 3,
 	},
 	{
 		.phys_base	= OMAP1610_MCBSP2_BASE,
@@ -219,7 +149,8 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_McBSP3RX,
 		.tx_irq		= INT_McBSP3TX,
 		.ops		= &omap1_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 3,
 	},
 };
 #define OMAP16XX_MCBSP_PDATA_SZ		ARRAY_SIZE(omap16xx_mcbsp_pdata)
@@ -230,15 +161,6 @@ static struct omap_mcbsp_platform_data omap16xx_mcbsp_pdata[] = {
 
 int __init omap1_mcbsp_init(void)
 {
-	int i;
-
-	for (i = 0; i < omap_mcbsp_clks_size; i++) {
-		if (cpu_is_omap15xx() || cpu_is_omap16xx()) {
-			omap_mcbsp_clk_init(&omap_mcbsp_clks[i]);
-			clk_register(&omap_mcbsp_clks[i].clk);
-		}
-	}
-
 	if (cpu_is_omap730())
 		omap_mcbsp_count = OMAP730_MCBSP_PDATA_SZ;
 	if (cpu_is_omap15xx())
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index e20023c..a9e631f 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -24,106 +24,7 @@
 #include <mach/cpu.h>
 #include <mach/mcbsp.h>
 
-struct mcbsp_internal_clk {
-	struct clk clk;
-	struct clk **childs;
-	int n_childs;
-};
-
-#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-static void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
-{
-	const char *clk_names[] = { "mcbsp_ick", "mcbsp_fck" };
-	int i;
-
-	mclk->n_childs = ARRAY_SIZE(clk_names);
-	mclk->childs = kzalloc(mclk->n_childs * sizeof(struct clk *),
-				GFP_KERNEL);
-
-	for (i = 0; i < mclk->n_childs; i++) {
-		/* We fake a platform device to get correct device id */
-		struct platform_device pdev;
-
-		pdev.dev.bus = &platform_bus_type;
-		pdev.id = mclk->clk.id;
-		mclk->childs[i] = clk_get(&pdev.dev, clk_names[i]);
-		if (IS_ERR(mclk->childs[i]))
-			printk(KERN_ERR "Could not get clock %s (%d).\n",
-				clk_names[i], mclk->clk.id);
-	}
-}
-
-static int omap_mcbsp_clk_enable(struct clk *clk)
-{
-	struct mcbsp_internal_clk *mclk = container_of(clk,
-					struct mcbsp_internal_clk, clk);
-	int i;
-
-	for (i = 0; i < mclk->n_childs; i++)
-		clk_enable(mclk->childs[i]);
-	return 0;
-}
-
-static void omap_mcbsp_clk_disable(struct clk *clk)
-{
-	struct mcbsp_internal_clk *mclk = container_of(clk,
-					struct mcbsp_internal_clk, clk);
-	int i;
-
-	for (i = 0; i < mclk->n_childs; i++)
-		clk_disable(mclk->childs[i]);
-}
-
-static struct mcbsp_internal_clk omap_mcbsp_clks[] = {
-	{
-		.clk = {
-			.name 		= "mcbsp_clk",
-			.id		= 1,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-	{
-		.clk = {
-			.name 		= "mcbsp_clk",
-			.id		= 2,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-	{
-		.clk = {
-			.name		= "mcbsp_clk",
-			.id		= 3,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-	{
-		.clk = {
-			.name		= "mcbsp_clk",
-			.id		= 4,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-	{
-		.clk = {
-			.name		= "mcbsp_clk",
-			.id		= 5,
-			.enable		= omap_mcbsp_clk_enable,
-			.disable	= omap_mcbsp_clk_disable,
-		},
-	},
-};
-
-#define omap_mcbsp_clks_size	ARRAY_SIZE(omap_mcbsp_clks)
-#else
-#define omap_mcbsp_clks_size	0
-static struct mcbsp_internal_clk __initdata *omap_mcbsp_clks;
-static inline void omap_mcbsp_clk_init(struct clk *clk)
-{ }
-#endif
+const char *clk_names[] = { "mcbsp_ick", "mcbsp_fck" };
 
 static void omap2_mcbsp2_mux_setup(void)
 {
@@ -156,7 +57,8 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP1_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP1_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP24XX_MCBSP2_BASE,
@@ -165,7 +67,8 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP2_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP2_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 };
 #define OMAP2420_MCBSP_PDATA_SZ		ARRAY_SIZE(omap2420_mcbsp_pdata)
@@ -183,7 +86,8 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP1_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP1_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP24XX_MCBSP2_BASE,
@@ -192,7 +96,8 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP2_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP2_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP2430_MCBSP3_BASE,
@@ -201,7 +106,8 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP3_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP3_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP2430_MCBSP4_BASE,
@@ -210,7 +116,8 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP4_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP4_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP2430_MCBSP5_BASE,
@@ -219,7 +126,8 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP5_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP5_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 };
 #define OMAP2430_MCBSP_PDATA_SZ		ARRAY_SIZE(omap2430_mcbsp_pdata)
@@ -237,7 +145,8 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP1_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP1_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP34XX_MCBSP2_BASE,
@@ -246,7 +155,8 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP2_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP2_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP34XX_MCBSP3_BASE,
@@ -255,7 +165,8 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP3_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP3_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP34XX_MCBSP4_BASE,
@@ -264,7 +175,8 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP4_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP4_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 	{
 		.phys_base	= OMAP34XX_MCBSP5_BASE,
@@ -273,7 +185,8 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 		.rx_irq		= INT_24XX_MCBSP5_IRQ_RX,
 		.tx_irq		= INT_24XX_MCBSP5_IRQ_TX,
 		.ops		= &omap2_mcbsp_ops,
-		.clk_name	= "mcbsp_clk",
+		.clk_names	= clk_names,
+		.num_clks	= 2,
 	},
 };
 #define OMAP34XX_MCBSP_PDATA_SZ		ARRAY_SIZE(omap34xx_mcbsp_pdata)
@@ -284,14 +197,6 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
 
 static int __init omap2_mcbsp_init(void)
 {
-	int i;
-
-	for (i = 0; i < omap_mcbsp_clks_size; i++) {
-		/* Once we call clk_get inside init, we do not register it */
-		omap_mcbsp_clk_init(&omap_mcbsp_clks[i]);
-		clk_register(&omap_mcbsp_clks[i].clk);
-	}
-
 	if (cpu_is_omap2420())
 		omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
 	if (cpu_is_omap2430())
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h
index eef873d..113c246 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -344,7 +344,8 @@ struct omap_mcbsp_platform_data {
 	u8 dma_rx_sync, dma_tx_sync;
 	u16 rx_irq, tx_irq;
 	struct omap_mcbsp_ops *ops;
-	char const *clk_name;
+	char const **clk_names;
+	int num_clks;
 };
 
 struct omap_mcbsp {
@@ -376,7 +377,8 @@ struct omap_mcbsp {
 	/* Protect the field .free, while checking if the mcbsp is in use */
 	spinlock_t lock;
 	struct omap_mcbsp_platform_data *pdata;
-	struct clk *clk;
+	struct clk **clks;
+	int num_clks;
 };
 extern struct omap_mcbsp **mcbsp_ptr;
 extern int omap_mcbsp_count;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index f2401a8..e5842e3 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -214,6 +214,7 @@ EXPORT_SYMBOL(omap_mcbsp_set_io_type);
 int omap_mcbsp_request(unsigned int id)
 {
 	struct omap_mcbsp *mcbsp;
+	int i;
 	int err;
 
 	if (!omap_mcbsp_check_valid_id(id)) {
@@ -225,7 +226,8 @@ int omap_mcbsp_request(unsigned int id)
 	if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->request)
 		mcbsp->pdata->ops->request(id);
 
-	clk_enable(mcbsp->clk);
+	for (i = 0; i < mcbsp->num_clks; i++)
+		clk_enable(mcbsp->clks[i]);
 
 	spin_lock(&mcbsp->lock);
 	if (!mcbsp->free) {
@@ -276,6 +278,7 @@ EXPORT_SYMBOL(omap_mcbsp_request);
 void omap_mcbsp_free(unsigned int id)
 {
 	struct omap_mcbsp *mcbsp;
+	int i;
 
 	if (!omap_mcbsp_check_valid_id(id)) {
 		printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
@@ -286,7 +289,8 @@ void omap_mcbsp_free(unsigned int id)
 	if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->free)
 		mcbsp->pdata->ops->free(id);
 
-	clk_disable(mcbsp->clk);
+	for (i = mcbsp->num_clks - 1; i >= 0; i--)
+		clk_disable(mcbsp->clks[i]);
 
 	spin_lock(&mcbsp->lock);
 	if (mcbsp->free) {
@@ -872,6 +876,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
 	struct omap_mcbsp_platform_data *pdata = pdev->dev.platform_data;
 	struct omap_mcbsp *mcbsp;
 	int id = pdev->id - 1;
+	int i;
 	int ret = 0;
 
 	if (!pdata) {
@@ -916,14 +921,25 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
 	mcbsp->dma_rx_sync = pdata->dma_rx_sync;
 	mcbsp->dma_tx_sync = pdata->dma_tx_sync;
 
-	if (pdata->clk_name)
-		mcbsp->clk = clk_get(&pdev->dev, pdata->clk_name);
-	if (IS_ERR(mcbsp->clk)) {
-		dev_err(&pdev->dev,
-			"Invalid clock configuration for McBSP%d.\n",
-			mcbsp->id);
-		ret = PTR_ERR(mcbsp->clk);
-		goto err_clk;
+	if (pdata->num_clks) {
+		mcbsp->num_clks = pdata->num_clks;
+		mcbsp->clks = kzalloc(mcbsp->num_clks * sizeof(struct clk *),
+					GFP_KERNEL);
+		if (!mcbsp->clks) {
+			ret = -ENOMEM;
+			goto exit;
+		}
+		for (i = 0; i < mcbsp->num_clks; i++) {
+			mcbsp->clks[i] = clk_get(&pdev->dev, pdata->clk_names[i]);
+			if (IS_ERR(mcbsp->clks[i])) {
+				dev_err(&pdev->dev,
+					"Invalid %s configuration for McBSP%d.\n",
+					pdata->clk_names[i], mcbsp->id);
+				ret = PTR_ERR(mcbsp->clks[i]);
+				goto err_clk;
+			}
+		}
+
 	}
 
 	mcbsp->pdata = pdata;
@@ -932,6 +948,9 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
 	return 0;
 
 err_clk:
+	while (i--)
+		clk_put(mcbsp->clks[i]);
+	kfree(mcbsp->clks);
 	iounmap(mcbsp->io_base);
 err_ioremap:
 	mcbsp->free = 0;
@@ -942,6 +961,7 @@ exit:
 static int __devexit omap_mcbsp_remove(struct platform_device *pdev)
 {
 	struct omap_mcbsp *mcbsp = platform_get_drvdata(pdev);
+	int i;
 
 	platform_set_drvdata(pdev, NULL);
 	if (mcbsp) {
@@ -950,12 +970,18 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev)
 				mcbsp->pdata->ops->free)
 			mcbsp->pdata->ops->free(mcbsp->id);
 
-		clk_disable(mcbsp->clk);
-		clk_put(mcbsp->clk);
+		for (i = mcbsp->num_clks - 1; i >= 0; i--) {
+			clk_disable(mcbsp->clks[i]);
+			clk_put(mcbsp->clks[i]);
+		}
 
 		iounmap(mcbsp->io_base);
 
-		mcbsp->clk = NULL;
+		if (mcbsp->num_clks) {
+			kfree(mcbsp->clks);
+			mcbsp->clks = NULL;
+			mcbsp->num_clks = 0;
+		}
 		mcbsp->free = 0;
 		mcbsp->dev = NULL;
 	}

Re: OMAP1: mcbsp clocks

[Russell King - ARM Linux]

On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> Basically we currently cannot use virtual clocks because of this
> and the fact that the parent of the virtual clock may not be known
> as pointed out by Paul Walmsley.

One other thing I'd like to confirm is how the kernel treats the OMAP5912.
OMAP5912 is interesting to me at the moment because it seems that all
the information on it is freely available.  I don't know about the
others.

However, it would be useful to know how the kernel treats this - iow,
which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610.

Of course, if someone knows (or can send me, maybe Richard W?) where
there's a similar document to spru751a for the clock architecture for
these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be
most useful.

Re: OMAP1: mcbsp clocks

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090123 09:43]:
> On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> > Basically we currently cannot use virtual clocks because of this
> > and the fact that the parent of the virtual clock may not be known
> > as pointed out by Paul Walmsley.
> 
> One other thing I'd like to confirm is how the kernel treats the OMAP5912.
> OMAP5912 is interesting to me at the moment because it seems that all
> the information on it is freely available.  I don't know about the
> others.
> 
> However, it would be useful to know how the kernel treats this - iow,
> which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610.

5912 = 1611b = 16xx. Then 1710 is quite similar.

> Of course, if someone knows (or can send me, maybe Richard W?) where
> there's a similar document to spru751a for the clock architecture for
> these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be
> most useful.

I have some links on my webpage to the docs:

http://www.muru.com/linux/omap/

Still no public docs for 24xx :(

Tony

RE: OMAP1: mcbsp clocks

[Hunter, Jon]

Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090123 09:43]:
>> On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
>>> Basically we currently cannot use virtual clocks because of this
>>> and the fact that the parent of the virtual clock may not be known
>>> as pointed out by Paul Walmsley.
>>
>> One other thing I'd like to confirm is how the kernel treats the
>> OMAP5912. OMAP5912 is interesting to me at the moment because it
>> seems that all the information on it is freely available.  I don't
>> know about the others.
>>
>> However, it would be useful to know how the kernel treats this - iow,
>> which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610.
>
> 5912 = 1611b = 16xx. Then 1710 is quite similar.

Right, the OMAP5912 started off life as the 1611, but 1611 involved into the 1621. So really 5912 = 1621. There are a couple differences between the 1610 and 1621, one of the main being the size of the internal RAM.

>> Of course, if someone knows (or can send me, maybe Richard W?) where
>> there's a similar document to spru751a for the clock architecture for
>> these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be
>> most useful.

Unfortunately, most of the original devices have NDA restrictions which is a royal pain in the neck especially for people in the open-source community who would like to develop with these. I am sure this infuriates many. Please don't shoot the messenger!

I am disappointed it is still that way for some of these parts. The good news is that for OMAP3 we appear to be getting our act together here.

> I have some links on my webpage to the docs:
>
> http://www.muru.com/linux/omap/

Tony, I see you have a link on your website to the OMAP3525. The OMAP3530 == OMAP3430, I would recommend that you point people to the following product folder for documentation:
http://focus.ti.com/docs/prod/folders/print/omap3530.html

The OMAP3525 has a reduced feature set...see the following page for an overview of the OMAP35xx series:
http://wiki.omap.com/index.php?title=OMAP3_Overview

Cheers
Jon

Re: OMAP1: mcbsp clocks

[Tony Lindgren]

* Hunter, Jon <jon-hunter@ti.com> [090123 11:03]:
> Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
> 
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090123 09:43]:
> >> On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> >>> Basically we currently cannot use virtual clocks because of this
> >>> and the fact that the parent of the virtual clock may not be known
> >>> as pointed out by Paul Walmsley.
> >>
> >> One other thing I'd like to confirm is how the kernel treats the
> >> OMAP5912. OMAP5912 is interesting to me at the moment because it
> >> seems that all the information on it is freely available.  I don't
> >> know about the others.
> >>
> >> However, it would be useful to know how the kernel treats this - iow,
> >> which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610.
> >
> > 5912 = 1611b = 16xx. Then 1710 is quite similar.
> 
> Right, the OMAP5912 started off life as the 1611, but 1611 involved into the 1621. So really 5912 = 1621. There are a couple differences between the 1610 and 1621, one of the main being the size of the internal RAM.

Thanks for setting that straight. And looks like we have cpu_is_omap1621()
macro in the kernel.

> >> Of course, if someone knows (or can send me, maybe Richard W?) where
> >> there's a similar document to spru751a for the clock architecture for
> >> these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be
> >> most useful.
> 
> Unfortunately, most of the original devices have NDA restrictions which is a royal pain in the neck especially for people in the open-source community who would like to develop with these. I am sure this infuriates many. Please don't shoot the messenger!
> 
> I am disappointed it is still that way for some of these parts. The good news is that for OMAP3 we appear to be getting our act together here.
> 
> > I have some links on my webpage to the docs:
> >
> > http://www.muru.com/linux/omap/
> 
> Tony, I see you have a link on your website to the OMAP3525. The OMAP3530 == OMAP3430, I would recommend that you point people to the following product folder for documentation:
> http://focus.ti.com/docs/prod/folders/print/omap3530.html

Thanks, fixed now. Also removed some earlier dead link.

> The OMAP3525 has a reduced feature set...see the following page for an overview of the OMAP35xx series:
> http://wiki.omap.com/index.php?title=OMAP3_Overview
> 
> Cheers
> Jon
> 
> 

RE: OMAP1: mcbsp clocks

[Premi, Sanjeev]

 

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Saturday, January 24, 2009 12:47 AM
> To: Hunter, Jon
> Cc: Russell King - ARM Linux; linux-omap@vger.kernel.org; 
> Paul Walmsley; Stanley Miao
> Subject: Re: OMAP1: mcbsp clocks
> 
> * Hunter, Jon <jon-hunter@ti.com> [090123 11:03]:
> > Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
> > 
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> 
> [090123 09:43]:
> > >> On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> > >>> Basically we currently cannot use virtual clocks 
> because of this 
> > >>> and the fact that the parent of the virtual clock may 
> not be known 
> > >>> as pointed out by Paul Walmsley.
> > >>
> > >> One other thing I'd like to confirm is how the kernel treats the 
> > >> OMAP5912. OMAP5912 is interesting to me at the moment because it 
> > >> seems that all the information on it is freely 
> available.  I don't 
> > >> know about the others.
> > >>
> > >> However, it would be useful to know how the kernel treats this - 
> > >> iow, which of the four categories for OMAP1 SoCs - 310, 
> 730, 1510, 1610.
> > >
> > > 5912 = 1611b = 16xx. Then 1710 is quite similar.
> > 
> > Right, the OMAP5912 started off life as the 1611, but 1611 
> involved into the 1621. So really 5912 = 1621. There are a 
> couple differences between the 1610 and 1621, one of the main 
> being the size of the internal RAM.
> 
> Thanks for setting that straight. And looks like we have 
> cpu_is_omap1621() macro in the kernel.
> 
> > >> Of course, if someone knows (or can send me, maybe Richard W?) 
> > >> where there's a similar document to spru751a for the clock 
> > >> architecture for these other CPUs (and OMAP2420, OMAP2430, 
> > >> OMAP3430, etc) it would be most useful.
> > 
> > Unfortunately, most of the original devices have NDA 
> restrictions which is a royal pain in the neck especially for 
> people in the open-source community who would like to develop 
> with these. I am sure this infuriates many. Please don't 
> shoot the messenger!
> > 
> > I am disappointed it is still that way for some of these 
> parts. The good news is that for OMAP3 we appear to be 
> getting our act together here.
> > 
> > > I have some links on my webpage to the docs:
> > >
> > > http://www.muru.com/linux/omap/
> > 
> > Tony, I see you have a link on your website to the 
> OMAP3525. The OMAP3530 == OMAP3430, I would recommend that 
> you point people to the following product folder for documentation:
> > http://focus.ti.com/docs/prod/folders/print/omap3530.html
> 
> Thanks, fixed now. Also removed some earlier dead link.
> 
> > The OMAP3525 has a reduced feature set...see the following 
> page for an overview of the OMAP35xx series:
> > http://wiki.omap.com/index.php?title=OMAP3_Overview
> > 
> > Cheers
> > Jon
> > 

Tony,

I haven't heard any specific comments since Kevin's okay for the OMAP35x patchset. Is it on your 'push' list?

Best regards,
Sanjeev
> > 
> --
> 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
> 
> 

Fwd: OMAP1: mcbsp clocks

[Alejandro Blanca G.]

Resent as plain text since that's what the linux-omap mail server accepts.

Sorry for the double post (to those who got 2 copies).

-----------

Hi everyone.

First, I'm relatively new to the list and I'm still catching up with
the etiquette to follow.
So, if I break it somehow, please do let me know. It's not my
intention to do so.

Now, I know that the OMAP16xx line of processors is composed (as far
as I know) by the following:

* 1610
* 1611
* 1621
* 1623

Does anybody know about the differences between them and / or about a
document explaining them?

The reason I'm looking for this information is because I've a 1611 SDP
that I'd like to use to boot Linux and some other OSes, but don't know
much about it (compared to the later OMAP families). I would like to
be aware of the differences between them so that I can better select
the versions of the software I'd like to use (in order to avoid
incompatibilities).

Your help will be really appreciated. Thanks in advance for your time.

Cheers,

Alex B.

---------- Forwarded message ----------
From: Alejandro Blanca G. <alex.blanca@gmail.com>
Date: Fri, Jan 23, 2009 at 1:59 PM
Subject: Re: OMAP1: mcbsp clocks
To: Tony Lindgren <tony@atomide.com>
Cc: "Hunter, Jon" <jon-hunter@ti.com>, Russell King - ARM Linux
<linux@arm.linux.org.uk>, "linux-omap@vger.kernel.org"
<linux-omap@vger.kernel.org>, Paul Walmsley <paul@pwsan.com>, Stanley
Miao <stanley.miao@windriver.com>


Hi everyone.

First, I'm relatively new to the list and I'm still catching up with
the etiquette to follow.
So, if I break it somehow, please do let me know. It's not my
intention to do so.

Now, I know that the OMAP16xx line of processors is composed (as far
as I know) by the following:

* 1610
* 1611
* 1621
* 1623

Does anybody know about the differences between them and / or about a
document explaining them?

The reason I'm looking for this information is because I've a 1611 SDP
that I'd like to use to boot Linux and some other OSes, but don't know
much about it (compared to the later OMAP families). I would like to
be aware of the differences between them so that I can better select
the versions of the software I'd like to use (in order to avoid
incompatibilities).

Your help will be really appreciated. Thanks in advance for your time.

Cheers,

Alex B.

On Fri, Jan 23, 2009 at 1:17 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> * Hunter, Jon <jon-hunter@ti.com> [090123 11:03]:
> > Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
> >
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090123 09:43]:
> > >> On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> > >>> Basically we currently cannot use virtual clocks because of this
> > >>> and the fact that the parent of the virtual clock may not be known
> > >>> as pointed out by Paul Walmsley.
> > >>
> > >> One other thing I'd like to confirm is how the kernel treats the
> > >> OMAP5912. OMAP5912 is interesting to me at the moment because it
> > >> seems that all the information on it is freely available.  I don't
> > >> know about the others.
> > >>
> > >> However, it would be useful to know how the kernel treats this - iow,
> > >> which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610.
> > >
> > > 5912 = 1611b = 16xx. Then 1710 is quite similar.
> >
> > Right, the OMAP5912 started off life as the 1611, but 1611 involved into the 1621. So really 5912 = 1621. There are a couple differences between the 1610 and 1621, one of the main being the size of the internal RAM.
>
> Thanks for setting that straight. And looks like we have cpu_is_omap1621()
> macro in the kernel.
>
> > >> Of course, if someone knows (or can send me, maybe Richard W?) where
> > >> there's a similar document to spru751a for the clock architecture for
> > >> these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be
> > >> most useful.
> >
> > Unfortunately, most of the original devices have NDA restrictions which is a royal pain in the neck especially for people in the open-source community who would like to develop with these. I am sure this infuriates many. Please don't shoot the messenger!
> >
> > I am disappointed it is still that way for some of these parts. The good news is that for OMAP3 we appear to be getting our act together here.
> >
> > > I have some links on my webpage to the docs:
> > >
> > > http://www.muru.com/linux/omap/
> >
> > Tony, I see you have a link on your website to the OMAP3525. The OMAP3530 == OMAP3430, I would recommend that you point people to the following product folder for documentation:
> > http://focus.ti.com/docs/prod/folders/print/omap3530.html
>
> Thanks, fixed now. Also removed some earlier dead link.
>
> > The OMAP3525 has a reduced feature set...see the following page for an overview of the OMAP35xx series:
> > http://wiki.omap.com/index.php?title=OMAP3_Overview
> >
> > Cheers
> > Jon
> >
> >
> --
> 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: OMAP1: mcbsp clocks

[Hunter, Jon]

Alejandro Blanca G wrote on :

> First, I'm relatively new to the list and I'm still catching up with
> the etiquette to follow. So, if I break it somehow, please do let me
> know. It's not my intention to do so.

No problem, but you may wish to post under a new subject, although I guess we did go off the main topic :-)

> Now, I know that the OMAP16xx line of processors is composed (as far
> as I know) by the following:
>
> * 1610
> * 1611
> * 1621
> * 1623
>
> Does anybody know about the differences between them and / or about a
> document explaining them?

This is testing my memory now, but here is the way I recall it...

OMAP1610 was the original device and to be honest all these devices have the same peripheral features.

The OMAP1610 only has 16KB of internal RAM where as the other 3 (1611, 1621, 1623) all have 250KB of internal RAM.

The OMAP1611 was rev'ed and a few improvements were made. Now from the user point of view not too many changes were made (ie. no new peripherals that I recall) but there were some new registers added in some modules. The OMAP1611 became the OMAP1621 after it was revised. So if you have a OMAP1611 this was the original device.

The OMAP1623 is simply a OMAP1621 with stacked DDR memory.

Hope this helps.

Jon

Re: OMAP1: mcbsp clocks

[Alejandro Blanca G.]

Hi Jon.

So, if I understood correctly, the internal RAM you're talking about
is the one coming with the OMAP itself. Additionally, you could count
on the RAM coming with the board and the internal caches available,
right? Or are you using the term "internal RAM" to refer to the L1 /
L2 caches (if any)?

Regarding peripheral support, then this means that the driver support
should be basically the same among revisions, right?

Thanks for your reply. It has been really helpful.

Best regards,

Alex B.

---------- Forwarded message ----------
From: Alejandro Blanca G. <alex.blanca@gmail.com>
Date: Fri, Jan 23, 2009 at 3:47 PM
Subject: Re: OMAP1: mcbsp clocks
To: "Hunter, Jon" <jon-hunter@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>


Hi Jon.

So, if I understood correctly, the internal RAM you're talking about
is the one coming with the OMAP itself. Additionally, you could count
on the RAM coming with the board and the internal caches available,
right? Or are you using the term "internal RAM" to refer to the L1 /
L2 caches (if any)?

Regarding peripheral support, then this means that the driver support
should be basically the same among revisions, right?

Thanks for your reply. It has been really helpful.

Best regards,

Alex B.

On Fri, Jan 23, 2009 at 3:29 PM, Hunter, Jon <jon-hunter@ti.com> wrote:
>
> Alejandro Blanca G wrote on :
>
> > First, I'm relatively new to the list and I'm still catching up with
> > the etiquette to follow. So, if I break it somehow, please do let me
> > know. It's not my intention to do so.
>
> No problem, but you may wish to post under a new subject, although I guess we did go off the main topic :-)
>
> > Now, I know that the OMAP16xx line of processors is composed (as far
> > as I know) by the following:
> >
> > * 1610
> > * 1611
> > * 1621
> > * 1623
> >
> > Does anybody know about the differences between them and / or about a
> > document explaining them?
>
> This is testing my memory now, but here is the way I recall it...
>
> OMAP1610 was the original device and to be honest all these devices have the same peripheral features.
>
> The OMAP1610 only has 16KB of internal RAM where as the other 3 (1611, 1621, 1623) all have 250KB of internal RAM.
>
> The OMAP1611 was rev'ed and a few improvements were made. Now from the user point of view not too many changes were made (ie. no new peripherals that I recall) but there were some new registers added in some modules. The OMAP1611 became the OMAP1621 after it was revised. So if you have a OMAP1611 this was the original device.
>
> The OMAP1623 is simply a OMAP1621 with stacked DDR memory.
>
> Hope this helps.
>
> Jon

RE: OMAP1: mcbsp clocks

[Hunter, Jon]

Alejandro Blanca G wrote on :

> So, if I understood correctly, the internal RAM you're talking about
> is the one coming with the OMAP itself. Additionally, you could count
> on the RAM coming with the board and the internal caches available,
> right? Or are you using the term "internal RAM" to refer to the L1 /
> L2 caches (if any)?

Yes, the internal RAM being the SRAM inside the OMAP. The SRAM is accessible by the ARM and DSP cores. This is should not be confused with the ARM or DSP caches, these are separate.

> Regarding peripheral support, then this means that the driver support
> should be basically the same among revisions, right?

Yes they will be pretty much the same. Actually, here is what I recommend...

The initial OMAP5912 devices were in fact OMAP1611 and the production version is a OMAP1621. If you refer to the OMAP5912 documentation on the below webpage, you will see in some documents that it states "not available on XOMAP5912 or POMAP5912" in certain areas. The XOMAP5912 and POMAP5912 are indeed OMAP1611 devices. So if OMAP1611 is what you have then anything that says "not available on XOMAP5912 or POMAP5912" will also be not available on the OMAP1611.

You will find some examples of this in the OMAP5912 Subsystem User Guide:
http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=325&abstractName=spru749b

All OMAP5912 documentation can be found here: http://focus.ti.com/docs/prod/folders/print/omap5912.html

Jon

Re: OMAP1: mcbsp clocks

[Alejandro Blanca G.]

Perfect then.

Thanks a lot for the info. It's been really helpful.

Best regards,

Alex B.

On Fri, Jan 23, 2009 at 4:54 PM, Hunter, Jon <jon-hunter@ti.com> wrote:
> Alejandro Blanca G wrote on :
>
>> So, if I understood correctly, the internal RAM you're talking about
>> is the one coming with the OMAP itself. Additionally, you could count
>> on the RAM coming with the board and the internal caches available,
>> right? Or are you using the term "internal RAM" to refer to the L1 /
>> L2 caches (if any)?
>
> Yes, the internal RAM being the SRAM inside the OMAP. The SRAM is accessible by the ARM and DSP cores. This is should not be confused with the ARM or DSP caches, these are separate.
>
>> Regarding peripheral support, then this means that the driver support
>> should be basically the same among revisions, right?
>
> Yes they will be pretty much the same. Actually, here is what I recommend...
>
> The initial OMAP5912 devices were in fact OMAP1611 and the production version is a OMAP1621. If you refer to the OMAP5912 documentation on the below webpage, you will see in some documents that it states "not available on XOMAP5912 or POMAP5912" in certain areas. The XOMAP5912 and POMAP5912 are indeed OMAP1611 devices. So if OMAP1611 is what you have then anything that says "not available on XOMAP5912 or POMAP5912" will also be not available on the OMAP1611.
>
> You will find some examples of this in the OMAP5912 Subsystem User Guide:
> http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=325&abstractName=spru749b
>
> All OMAP5912 documentation can be found here: http://focus.ti.com/docs/prod/folders/print/omap5912.html
>
> Jon
>

RE: OMAP1: mcbsp clocks

[Hunter, Jon]

Russell King wrote on :

> A question about OMAP1 mcbsp clocks.  From what I understand from the
> OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two
> clocks:
>
> 1. interface clock switchable between DSPPER_CK and DSPXOR_CK.
> 2. a function clock which could be DSPXOR_CK (mcbsp3), and
>    CK_DPLL1OUT or MCBS1_CLKS (mcbsp1).
>
> However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3
> unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK.  As far as
> I can see, DSP_CK (for the DSP processor) and API_CK (for system dma)
> have nothing to do with mcbsp1,3.
>
> So, the question is why is it this way, and what would be the effect
> of correcting this so that both of these mcbsp units are associated
> with their proper interface and function clocks?

On the OMAP1 architecture there are peripherals that are located on the ARM peripheral bus and peripherals that are located on the DSP bus. The McBSP1 and McBSP3 are located on the DSP peripheral bus and McBSP2 is located on the ARM peripheral bus. The ARM has access to some of the DSP peripherals via the MPUI (aka API - the name was changed to avoid confusion with sofware term). The API or 'ARM Peripheral Interface' (if I recall the abbreviation correctly) is really just the ARM's internal interface to peripherals on the DSP's bus. However, in order for the ARM to access peripherals via the MPUI, the MPUI clock (API_CK) must be enabled. This is the difference between McBSP2 and McBSP1/3.

So for McBSP1/3 you definitely need to have the MPUI clock enabled. On OMAP2/3 devices the internal bus architecture was change significantly so you don't have as many crazy dependencies.

Hope this helps.

Cheers
Jon

Re: OMAP1: mcbsp clocks

[Russell King - ARM Linux]

On Fri, Jan 23, 2009 at 11:18:37AM -0600, Hunter, Jon wrote:
>...
> So for McBSP1/3 you definitely need to have the MPUI clock enabled.

Thanks - that certainly explains why some of these things are happening
which is most useful.  However, the approach I've taken is to keep things
in a similar method to how they were before - which in this case means
that the code still enables the MPUI and DSP clocks for McBSP1,3, but
does it differently.

While I can test out my changes on the LDP, I'm using qemu to test in an
OMAP1510 environment - not that I attach _too_ much worth to that test.
I'm well aware that qemu is no subsitute for the real hardware, and so
will shortly be asking for people to boot test these changes.

However, I suspect mainline might not be advanced enough to even test
out the audio on an OSK board... we'll cross that bridge when we come to
it.