OMAP1: mcbsp clocks

DISCUSSION Russell King - ARM Linux 5 participants 14 messages Jan 22, 2009 – Jan 24, 2009 2 messages not in the archive

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP1 support

lore

Share & tools

lore

Russell King - ARM Linux

author

2009-01-22 23:55 UTC #0 lore raw

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

Tony Lindgren

maintainer

2009-01-23 01:17 UTC #1 lore raw

Quoted 4 lines · 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:

Quoted 8 lines

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?

Quoted 3 lines

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?

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 3 lines

(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

Quoted 1 line

From da3e6559dbfb84e73b93e3bb6f923b3f1d98c487 Mon Sep 17 00:00:00 2001

From: Stanley.Miao <[email protected]>
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 <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap1/mcbsp.c +10 ~~-88~~

index ca7a0cc..575ba31 100644
@@ -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())

arch/arm/mach-omap2/mcbsp.c +25 ~~-120~~

229 lines not on this page · raw message

arch/arm/plat-omap/include/mach/mcbsp.h +4 -2

index eef873d..113c246 100644
@@ -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;

arch/arm/plat-omap/mcbsp.c +39 ~~-13~~

109 lines not on this page · raw message

Russell King - ARM Linux

author

2009-01-23 17:43 UTC #2 lore raw

Quoted 3 lines · Tony Lindgren

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.

Tony Lindgren

maintainer

2009-01-23 17:54 UTC #3 lore raw

Quoted 5 lines · Russell King - ARM Linux

Quoted 3 lines · Tony Lindgren
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.

Quoted 7 lines

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.

Quoted 4 lines

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

Hunter, Jon

2009-01-23 19:03 UTC #4 lore raw

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

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Tony Lindgren
Quoted 3 lines
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.

Quoted 4 lines

Quoted 2 lines
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.

Quoted 4 lines

Quoted 4 lines
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.

Quoted 3 lines

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

Tony Lindgren

maintainer

2009-01-23 19:17 UTC #5 lore raw

Quoted 13 lines · Hunter, Jon

Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Tony Lindgren
Quoted 3 lines
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.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
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!

Quoted 8 lines

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.
Quoted 3 lines
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.

Quoted 7 lines

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

Premi, Sanjeev

2009-01-23 19:26 UTC #6 lore raw

Quoted 63 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tony Lindgren
Sent: Saturday, January 24, 2009 12:47 AM
To: Hunter, Jon
Cc: Russell King - ARM Linux; [email protected]; Paul Walmsley; Stanley Miao
Subject: Re: OMAP1: mcbsp clocks
Quoted 3 lines · Hunter, Jon
Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
Quoted 1 line
* Russell King - ARM Linux <[email protected]>
[090123 09:43]:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines · Tony Lindgren
Quoted 1 line
Basically we currently cannot use virtual clocks
because of this
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
and the fact that the parent of the virtual clock may
not be known
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
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!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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

Quoted 13 lines

OMAP3525. The OMAP3530 == OMAP3430, I would recommend that you point people to the following product folder for documentation:
Quoted 1 line
http://focus.ti.com/docs/prod/folders/print/omap3530.html
Thanks, fixed now. Also removed some earlier dead link.
Quoted 1 line
The OMAP3525 has a reduced feature set...see the following
page for an overview of the OMAP35xx series:
Quoted 5 lines
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

Quoted 8 lines

Quoted 1 line
--
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alejandro Blanca G.

2009-01-23 20:02 UTC #8 lore raw

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. <[email protected]>
Date: Fri, Jan 23, 2009 at 1:59 PM
Subject: Re: OMAP1: mcbsp clocks
To: Tony Lindgren <[email protected]>
Cc: "Hunter, Jon" <[email protected]>, Russell King - ARM Linux <[email protected]>, "[email protected]" <[email protected]>, Paul Walmsley <[email protected]>, Stanley Miao <[email protected]>

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?

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

Cheers,

Alex B.

Quoted 54 lines · Tony Lindgren

Quoted 13 lines · Hunter, Jon
Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM:
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Tony Lindgren
Quoted 3 lines
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.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
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!
Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hunter, Jon

2009-01-23 21:30 UTC #9 lore raw

Alejandro Blanca G wrote on :

Quoted 3 lines

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 :-)

Quoted 10 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alejandro Blanca G.

2009-01-23 21:48 UTC #11 lore raw

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. <[email protected]>
Date: Fri, Jan 23, 2009 at 3:47 PM
Subject: Re: OMAP1: mcbsp clocks
To: "Hunter, Jon" <[email protected]>
Cc: "[email protected]" <[email protected]>

Hi Jon.

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.

Quoted 33 lines · Jon

Alejandro Blanca G wrote on :
Quoted 3 lines
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 :-)
Quoted 10 lines
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

Hunter, Jon

2009-01-23 22:54 UTC #12 lore raw

Alejandro Blanca G wrote on :

Quoted 5 lines

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.

Quoted 2 lines

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

Alejandro Blanca G.

2009-01-24 04:28 UTC #13 lore raw

Perfect then.

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

Best regards,

Alex B.

Quoted 24 lines · Jon

Alejandro Blanca G wrote on :
Quoted 5 lines
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.
Quoted 2 lines
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

Hunter, Jon

2009-01-23 17:18 UTC #14 lore raw

In reply to Russell King - ARM Linux

Russell King wrote on :

Quoted 8 lines

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

Quoted 8 lines

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

Russell King - ARM Linux

author

2009-01-23 17:31 UTC #15 lore raw

Quoted 2 lines · Jon

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