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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
