Thread (40 messages) 40 messages, 5 authors, 2012-11-06
STALE4995d

[PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

From: tony@atomide.com (Tony Lindgren)
Date: 2012-07-10 08:18:52
Also in: linux-omap

* Hiremath, Vaibhav [off-list ref] [120709 23:30]:
On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote:
quoted
* Vaibhav Hiremath [off-list ref] [120709 01:55]:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
 #define CK_443X		(1 << 11)
 #define CK_TI816X	(1 << 12)
 #define CK_446X		(1 << 13)
+#define CK_54XX		(1 << 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_XXXX defines are now running out of the u16 cpu_mask.

They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.

Below (untested) is what could be done in the short term.

I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?

Paul got any better ideas?
...
This also will not scale up in the future and will end up again in the same 
situation.
Right that's why we want to get rid of it.
 
Just a quick thought, may work here,

I looked at the usage of cpu_mask and rates.flag and I believe we can 
restrict both to given SoC, something like,

OMAP34XX ->
          ES1
          ES2PLUS
          36XX
          AM35XX
          ...

OMAP4 ->
          443X
          446X

AM33XX ->
          AM335X
          TI816X
          TI814X
          ...

XYZ...  ->
          ...


The proposal would be,

To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits -

Lower 16 bits => describe SoC it is applicable to
Upper 16 bit => describes silicon versions or families
No thanks.. We don't want to make it 32 bit and bloat all the compiled in
clock even further. 

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help