> -----Original Message----- > From: DebBarma, Tarun Kanti > Sent: Monday, October 11, 2010 12:38 PM > To: Cousson, Benoit > Cc: Kevin Hilman; G, Manjunath Kondaiah; > linux-omap@xxxxxxxxxxxxxxx; Shilimkar, Santosh; Paul > Walmsley; Tony Lindgren; Basak, Partha > Subject: RE: [PATCHv3 8/17] dmtimer: register mappings moved > to hwmod database > > Benoit and Manju, [...] > > > > > > You do not really need that to reduce the CPU check in the code. > > > In that case, only the IP version should be stored in the > dev_attr. > > > Based on that IP version, you know exactly what register map you > > > have to handle. For the moment you just have 2 layouts to > handle + > > > the extra register for the 1ms timers. > > > > > > Also, I'm not sure that you have to handle each register > separately > > > considering that you have one offset to handle for the functional > > > register. > > > The change in sysconfig and interrupt register are all standard > > > mapping that stick to TI highlander standard. > > > Meaning, as soon as an IP is a v2 (highlander version) all these > > > registers will be at the same place... at least in theory :-) > > > > > > Here are the deltas between the legacy and the new one: > > > > > > [OMAP_TIMER_ID_REG] 0x00, > > > [OMAP_TIMER_OCP_CFG_REG] 0x10, same > > > [OMAP_TIMER_SYS_STAT_REG] 0x14, (not used anymore) > > > > > > You should not care about these ones, because hwmod will > handle them. > > > > > > [OMAP_TIMER_STAT_REG] 0x28, +10 > > > [OMAP_TIMER_INT_EN_REG] 0x2c, +10 > > > [OMAP_TIMER_INT_CLR_REG] 0x30, (new) > > > > > > These ones are standard registers > > > > > > [OMAP_TIMER_WAKEUP_EN_REG] 0x34, +14 > > > [OMAP_TIMER_CTRL_REG] 0x38, +14 > > > [OMAP_TIMER_COUNTER_REG] 0x3c, +14 > > > [OMAP_TIMER_LOAD_REG] 0x40, +14 > > > [OMAP_TIMER_TRIGGER_REG] 0x44, +14 > > > [OMAP_TIMER_WRITE_PEND_REG] 0x48, +14 > > > [OMAP_TIMER_MATCH_REG] 0x4c, +14 > > > [OMAP_TIMER_CAPTURE_REG] 0x50, +14 > > > [OMAP_TIMER_IF_CTRL_REG] 0x54, +14 > > > [OMAP_TIMER_CAPTURE2_REG] 0x58, +14 > > > > > > You can probably handle that with only 2 offsets instead > of having > > > one address per registers. > > > > > To keep aligned with other driver implementations, I would like to > > follow > > this: > > > > 1) move the table in mach-omap1/2 since > > 2) remove entries which are handled by hwmod. > > However, I am not sure if there is any issue in keeping > them in the table. > Hmm... I have second thought on this implementation and I > need your inputs. > If I go with the above implementation then I would end up > having duplicate tables for mach-omap1 and mach-omap2. I have > looked at the I2C implementation and would like to follow > this implementation where they have two tables in plat: > One for OMAP1/2/3 and second for OMAP4. 1. register offset tables are in i2c-omap.c under drivers/i2c/busses and not in plat. 2. i2c is different type of driver where register offsets are required only in i2c-omap.c and not in plat. If you don't require register offsets in mach-omapx or other places then it doesnot matter where you define these tables. Otherwise, it has to be in mach-omap2 since it should feed omap_device_build so that, offsets can be accessed at other places. -Manjunath-- 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
