* Cousson, Benoit <[email protected]> [100927 10:15]:
>
> OK for that one, that will save the extra id to store the partition
> in each static data, but then you will still have to store it during
> the init?
For mux.c internal data, we can have an array of struct omap_mux_partition
that contains the mux array for that partition:
struct omap_mux_partition {
void __iomem *base; /* Partition virt base */
struct omap_mux *mux; /* Partition specific mux array */
};
> >...
> >For omap2 and 3, we just call omap_mux_init once with the mux_pbase
> >as we currently already do. Then for omap4, we call omap_mux_init for
> >each partition.
> >
> >We also need to change omap_mux_read/write to allow specifying the
> >partition base address:
>
> Then you need somehow a partition information from somewhere.
> I don't see how we can avoid the id at that point? We can store the
> base address instead, but then every mux entries will have it.
That should only need to be stored once for each partition in the
struct omap_mux_partition?
> The caller of the omap_mux_read still have to figure out what base
> address it has to use.
> That move the issue to the upper layer, but we still need that.
For the mux.c internal code, we can search through the array
of struct omap_mux_partition and the mux entries in each partition
for signal name or GPIO number.
> >All the other mux interface functions can stay the same, we just need
> >to modify the mux.c code to look for signal names or GPIO number in
> >each registered partition.
>
> OK, now I think I understand your point... Please ignore the
> previous comments :-)
>
> You will guess the partition by trying each array at a time, and the
> first one will win.
>
> That seems pretty good in fact.
>
> I just have to do it now...
OK cool, let me know if I can help with something.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
