Hi,
On Fri, Mar 19, 2010 at 10:25:18AM -0500, Nishanth Menon wrote:
> Now, based on your proposal as I understand,
> struct omap2_data {
> blah_o21
> blah_o22
> };
>
> struct omap3_data {
> blah_o31
> blah_o32
> blah_o33
> }
>
> struct omap4_data {
> blah_o41
> blah_o42
> blah_o31
> blah_o32
> }
>
> and so on (remember we may have shared or similar data between various
> SOCs at times)
>
> redundancy, maintenance are the problems i see other than ability to
> have a module which uses blah_o31 to be generic and not know the
> difference between struct omap3_data and omap4_data
> the resultant module code will look like:
> if (cpu_is_omap3430()) {
> my_blaho31 = ((struct omap3_data *) get_opp_data(opp))->blah_o31;
> } else if cpu_is...() {
> ..
> }
ok, I get your point.
> now in the approach I took,
> you could have:
> struct sr_ntarget_type{
> unsigned long nTarget;
> something else if needed
> }
>
> And in SR driver, the module doesnot need to care which silicon it is
> running on.. it just does opp_get_data(opp,"sr_ntarget") and gets the
> correct data for that silicon on that OPP. It is much simpler and
> similar to the manner implemented in many other frameworks such as clock
> etc..
the thing is that ideally it would simply:
opp_get_data(opp);
and that should be done so that it fits all possibilities, but if it's
that different per-SoC, then I guess there's nothing to do.
--
balbi
--
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
