| Message ID | 1344243146-6598-1-git-send-email-linus.walleij@stericsson.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 06, 2012 at 10:52:26AM +0200, Linus Walleij wrote: > Commit: > 98582d9562b4bea6b0eb6e2bfafcd3fab3b60ccb > "ARM: ux500: Remove unused i2c platform_data initialisation code" > > Deleted platform data intialization code that was used, > not unused as indicated in the commit. The boot log (without > devicetree) now looks like this: The aforementioned commit was part of a patch-set. One of its affiliates moved this code into the Nomadik I2C driver; however, it was contested because Device Tree support was also added and the maintainer thought the properties introduced could be consolidated with other I2C driver's DT properties. I don't think anyone has taken up the consolidation work and for that reason it hasn't gone in. I think moving this stuff into the driver is the right thing to do. Instead, I'll split out the configuration and DT enablement from the patch and resubmit. Sound good to you?
On 08/06/2012 11:51 AM, Lee Jones wrote: > On Mon, Aug 06, 2012 at 10:52:26AM +0200, Linus Walleij wrote: >> Commit: >> 98582d9562b4bea6b0eb6e2bfafcd3fab3b60ccb >> "ARM: ux500: Remove unused i2c platform_data initialisation code" >> >> Deleted platform data intialization code that was used, >> not unused as indicated in the commit. The boot log (without >> devicetree) now looks like this: > The aforementioned commit was part of a patch-set. One of its affiliates > moved this code into the Nomadik I2C driver; however, it was contested > because Device Tree support was also added and the maintainer thought > the properties introduced could be consolidated with other I2C driver's > DT properties. I don't think anyone has taken up the consolidation work > and for that reason it hasn't gone in. Too bad it had to turn into a regression though :-P > I think moving this stuff into the driver is the right thing to do. > Instead, I'll split out the configuration and DT enablement from the > patch and resubmit. > > Sound good to you? Either way works with me, but the patch sent out need to be rebased and sent to Wolfram. Either he applies that to the I2C tree or I apply this to the ux500 tree. So it's for Wolfram to decide. Yours, Linus Walleij
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c index 8674a89..dbb9946 100644 --- a/arch/arm/mach-ux500/board-mop500.c +++ b/arch/arm/mach-ux500/board-mop500.c @@ -327,12 +327,43 @@ static struct i2c_board_info __initdata mop500_i2c2_devices[] = { }, }; +#define U8500_I2C_CONTROLLER(id, _slsu, _tft, _rft, clk, t_out, _sm) \ +static struct nmk_i2c_controller u8500_i2c##id##_data = { \ + /* \ + * slave data setup time, which is \ + * 250 ns,100ns,10ns which is 14,6,2 \ + * respectively for a 48 Mhz \ + * i2c clock \ + */ \ + .slsu = _slsu, \ + /* Tx FIFO threshold */ \ + .tft = _tft, \ + /* Rx FIFO threshold */ \ + .rft = _rft, \ + /* std. mode operation */ \ + .clk_freq = clk, \ + /* Slave response timeout(ms) */\ + .timeout = t_out, \ + .sm = _sm, \ +} + +/* + * The board uses 4 i2c controllers, initialize all of + * them with slave data setup time of 250 ns, + * Tx & Rx FIFO threshold values as 1 resp. 8 and fast + * mode of operation + */ +U8500_I2C_CONTROLLER(0, 0xe, 1, 8, 400000, 200, I2C_FREQ_MODE_FAST); +U8500_I2C_CONTROLLER(1, 0xe, 1, 8, 400000, 200, I2C_FREQ_MODE_FAST); +U8500_I2C_CONTROLLER(2, 0xe, 1, 8, 400000, 200, I2C_FREQ_MODE_FAST); +U8500_I2C_CONTROLLER(3, 0xe, 1, 8, 400000, 200, I2C_FREQ_MODE_FAST); + static void __init mop500_i2c_init(struct device *parent) { - db8500_add_i2c0(parent, NULL); - db8500_add_i2c1(parent, NULL); - db8500_add_i2c2(parent, NULL); - db8500_add_i2c3(parent, NULL); + db8500_add_i2c0(parent, &u8500_i2c0_data); + db8500_add_i2c1(parent, &u8500_i2c1_data); + db8500_add_i2c2(parent, &u8500_i2c2_data); + db8500_add_i2c3(parent, &u8500_i2c3_data); } static struct gpio_keys_button mop500_gpio_keys[] = {