hi, please send text mails and break your lines at 80 characters! On Tue, Jul 21, 2009 at 10:45:04AM +0530, Shilimkar, Santosh wrote: > Here is summary of Major difference between Triton(TWL4030) and > Phoenix(TWL6030_ chips are: > -GPIO, Keypad is not present in Phoenix > -I2C Chips addresses of modules like RTC, BCI, ADC, USB, PMC Master/Slave > have changed. Base address of these module register is also changed. > -PIH and SIH, module interrupt status registers will be replaced by PIH > (INT_STS_A, INT_STS_B and INT_STS_C) and module interrupt status registers > -MADC to GPADC in Phoenix, 17 channels supported > GPADC in Phoenix supports Realtime, Asynchronous SW request. > -RTC register offsets have changed. Addition/removal of LDO/SMPS Voltage > Regulators all of this can be addressed without ifdeferry around the code. Just add proper abstraction via platform_data, and that 'features' you see in twl4030-core.c > 2. Usage of compile time macros like "CONFIG_TWL4030" and CONFIG_TWL6030" > should be avoided and you think it would break multi-omap. > > If we just go by definition " Multi-OMAP" is for different OMAP IC's. TWL4030 > and TWL6030 are external companion IC's to OMAP. what will happen if you build on kernel image for booting omap3 and omap4 ??? > Any ways, these compile time switches can be avoided if we make runtime > provision for these TWL IC's like. > "is_twl4030(), is_twl6030" etc like "cpu_is_24xx(),cpu_is_44xx()" etc. or you just use the 'features' in the twl4030-core.c and based on that pass a flag to the children notifying it's triton/gaia/reno/phoenix. > Obviously this asks to make the driver register map (which is different in > case of TWL6030 w.r.t TWL4030) to be held in some arrays and select the > appropriate one run-time. But it's doable if it helps. I'd say that's better than ifdeferry. > The patch series was made under _assumption_ that either TWL4030 or TWL6030 > would be used. I am not sure whether there will boards where both will > co-exist. not in the same board, but think of building one kernel image for both omap3 and omap4. Nobody will do that in real life for real products, but it's really useful when it goes about testing code on several boards. You don't have to spend time building several different kernel images, you build only one that boots on all. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
