Describe why we can't simply probe the peripheral unit ID to make the decision about what register map to use
Cc: [email protected] Signed-off-by: Andy Green <[email protected]> --- drivers/i2c/busses/i2c-omap.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b605ff3..d6500ec 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1032,6 +1032,17 @@ omap_i2c_probe(struct platform_device *pdev) else dev->reg_shift = 2; + dev->regs = (u8 *)reg_map; + + /* + * this is a bit tricky, implementation on 4430 has the active + * part of its ID register moved to +4 instead of +0 as + * previously. So, we can't probe just using the ID register + * Complicating matters the older implementation using the + * simpler register set on 3530 also reports its revision as + * 0x40, same as the 4430 newer implementation. + */ + if (cpu_is_omap44xx()) dev->regs = (u8 *) omap4_reg_map; else -- 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
