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

On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote:

* Hiremath, Vaibhav [off-list ref] [120709 23:30]:

quoted

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?

...

quoted

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.
 

quoted

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. 

In that case, how about just get rid of cpu_mask completely and trust the 
data passed by clock-tree for clksel dividers?
Let clock-tree data handle this, even if in some cases we end up in 
duplicating data for some clocks??

Thanks,
Vaibhav