On 9/27/2010 7:36 PM, Tony Lindgren wrote:
* Cousson, Benoit<b-cousson@xxxxxx> [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.
Thanks, but that should be fine for moment. I think I should have the
updated version before the end of the week.
Just one clarification, I don't think we have to use two different
macros in that case. The names are already unique across partition
today, so we can use only macro like for previous OMAP.
I'm just glad I don't have to re-write these 231 entries per ES manually :-)
I'll give it a try, and keep you inform if I have any un-expected issue
with that approach.
Thanks,
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
