On 11/11/2010 5:53 PM, Tony Lindgren wrote:
* Cousson, Benoit<b-cous...@ti.com> [101020 13:43]:
On 10/20/2010 1:06 AM, Tony Lindgren wrote:
* Benoit Cousson<b-cous...@ti.com> [101019 15:14]:
It takes into account your proposal to store partition
information in a partition structure instead of inside every pad entries.
The mechanism relies on the uniqueness of the pad name in each partition to
find the correct partition during iteration.
OK, using the offset defines won't be unique necessarily..
They should. The defines are all based on pad names that are all
unique. Assuming HW folks didn't messed up the spec...
Just for the record to avoid confusion.. What I meant is the
offset values from the partition base are not unique even
if the define names are unique:
/* ctrl_module_pad_core registers offset */
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD0_OFFSET 0x0040
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD1_OFFSET 0x0042
#define OMAP4_CTRL_MODULE_PAD_GPMC_AD2_OFFSET 0x0044
...
/* ctrl_module_pad_wkup registers offset */
#define OMAP4_CTRL_MODULE_PAD_SIM_IO_OFFSET 0x0040
#define OMAP4_CTRL_MODULE_PAD_SIM_CLK_OFFSET 0x0042
#define OMAP4_CTRL_MODULE_PAD_SIM_RESET_OFFSET 0x0044
...
So now we have to use either a unique pad name, or a combination of
partition + offset.
Yes. Hence the need for the omap_mux_get you've just done in order to
access the low level API.
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
