Re: hwmod: multi-omap: disabling smartreflex on AM3517

["Cousson, Benoit" <b-cousson@ti.com>]

On 2/21/2011 4:41 PM, Premi, Sanjeev wrote:

[...]

>> The comment is already there BTW, so you just have to replace that by some
>> real code:-)
>
> [sp] I have already added real code, but the problem lies here:
>       On same file (few lines up) omap_chip.oc is assigned value of
>       CHIP_IS_OMAP3430. CHIP_IS_AM3517 now needs to be added to all
>       places where CHIP_IS_OMAP3430ES3_1 is chosen.
>
>       All this to support a chip that differs in 4 peripherals and IVA.
>       ... and this is what I was planning to minimize.

This is what we've being using for some time to handle small diff 
between ES.

>       Leaving aside AM3517; we have AM3703 - same as OMAP3630 but without
>       IVA and SGX. Here obviously hwmods for either of IVA, SGX shouldn't
>       be initialized. Isn't it?
>
>       Creating CHIP_IS_ ... here would be an overkill. Thoughts?

It depends how many variant you plan to do :-) We still have some room 
for 18 more variants / chip.

You can still create a new CHIP_IS, and add a alias 
CHIP_IS_OMAP36XX_COMMON = CHIP_IS_OMAP3630 | CHIP_IS_AM3703 and then 
replace all the existing entry with that alias.

If we want to avoid using these defines, you will have potentially to 
add a feature entry in every hwmod / clock / power domain entry that 
already uses the omap_chip today.
And then during the init we can filter on both the chip revision and 
chip features.
The drawback is that we are going to waste at least 300 x 32 bits to 
store that :-)
Whereas with the extra CHIP_IS_, it is just a couple of defines... no 
memory impact.

In between, you can consider a hwmod class to feature mapping, in order 
to know what hwmod class will be excluded if the feature is not there 
during the iteration.

I think I still prefer the first solution.

Regards,
Benoit