Skip to contentSkip to conversation

Tegra i2c board changes + defconfig update

PATCH Superseded Olof Johansson 5 participants 17 messages Mar 7, 2011

Subsystems (3)
Arm (32-bit) Arm sub-architectures Tegra architecture support

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Olof Johansson

author
#0 lore raw

cover Tegra i2c board changes + defconfig update

Hi,

Here is a short series of i2c patches to configure the i2c-tegra driver for the boards in the tree, and to register some of the devices.

It also includes a defconfig update that enables the new drivers, enables TRIMSLICE by default since the pcie fix makes it possible and also turns on a few more config options that are useful (i.e. EFI partition tables and some common board devices).

Since these patches rely on drivers that will be merged during the upcoming window, this is my plan:

* Check them into boards-for-next together with Stephen W's
other late-merge board patches in a day or two
* Ask sfr to add said branch to linux-next (towards the end of list of trees)
* Sit on them until merge window is open and base tegra, i2c and asoc have all been merged
* Rebase to current upstream when said trees are in, let it sit for 1 day for a linux-next cycle for sanity-check
* Send pull request

-Olof

author
#1 lore raw

PATCH 1/3 ARM: tegra: seaboard: register i2c devices

Register the base i2c devices on seaboard. A few more are pending, but it's a start.

Signed-off-by Olof Johansson <[email protected]>
---
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    1 +
 arch/arm/mach-tegra/board-seaboard.c        |   83 +++++++++++++++++++++++++++
 2 files changed, 84 insertions(+), 0 deletions(-)
arch/arm/mach-tegra/board-seaboard-pinmux.c +1 -0
index 7e96d49..d84d1dd 100644
@@ -166,6 +166,7 @@ static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TEGRA_GPIO_SD2_POWER,		.enable = true },
 	{ .gpio = TEGRA_GPIO_LIDSWITCH,		.enable = true },
 	{ .gpio = TEGRA_GPIO_POWERKEY,		.enable = true },
+	{ .gpio = TEGRA_GPIO_ISL29018_IRQ, 	.enable = true },
 };
 
 void __init seaboard_pinmux_init(void)
arch/arm/mach-tegra/board-seaboard.c +83 -0

122 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#2 lore raw

PATCH 1/3 ARM: tegra: seaboard: register i2c devices

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 16 lines

Register the base i2c devices on seaboard. A few more are pending, but it's a start.

Signed-off-by Olof Johansson <[email protected]>
---
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    1 +
 arch/arm/mach-tegra/board-seaboard.c        |   83
+++++++++++++++++++++++++++
 2 files changed, 84 insertions(+), 0 deletions(-)
arch/arm/mach- renamed from arch/arm/mach-tegra/board-seaboard-pinmux.c +0 -0

tegra/board-seaboard-pinmux.c
index 7e96d49..d84d1dd 100644

arch/arm/mach-tegra/board-seaboard-pinmux.c static struct tegra_gpio_table gpio_table[] = { · line 169

Quoted 4 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +1 -0
@@ -166,6 +166,7 @@ static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TEGRA_GPIO_SD2_POWER,		.enable = true },
 	{ .gpio = TEGRA_GPIO_LIDSWITCH,		.enable = true },
 	{ .gpio = TEGRA_GPIO_POWERKEY,		.enable = true },
+	{ .gpio = TEGRA_GPIO_ISL29018_IRQ, 	.enable = true },

The indentation between fields looks different there.

Quoted 66 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +0 -0
 };
 
 void __init seaboard_pinmux_init(void)
arch/arm/mach- renamed from arch/arm/mach-tegra/board-seaboard.c +0 -0

tegra/board-seaboard.c
index eb28dbd..afc972f 100644

arch/arm/mach-tegra/board-seaboard.c +19 -0
@@ -18,9 +18,12 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/serial_8250.h>
+#include <linux/i2c.h>
+#include <linux/i2c-tegra.h>
 #include <linux/delay.h>
 #include <linux/input.h>
 #include <linux/io.h>
+#include <linux/gpio.h>
 #include <linux/gpio_keys.h>
 
 #include <mach/iomap.h>

@@ -63,6 +66,22 @@ static __initdata struct tegra_clk_init_table
 seaboard_clk_init_table[] = {
 	{ NULL,		NULL,		0,		0},
 };
 
+static struct tegra_i2c_platform_data seaboard_i2c1_platform_data = {
+	.bus_clk_rate	= 400000.
+};
+
+static struct tegra_i2c_platform_data seaboard_i2c2_platform_data = {
+	.bus_clk_rate	= 400000,
+};
+
+static struct tegra_i2c_platform_data seaboard_i2c3_platform_data = {
+	.bus_clk_rate	= 400000,
+};
+
+static struct tegra_i2c_platform_data seaboard_dvc_platform_data = {
+	.bus_clk_rate	= 400000,
+};
+
 static struct gpio_keys_button seaboard_gpio_keys_buttons[] = {
 	{
arch/arm/mach-tegra/board-seaboard.c +16 -0
 		.code		= SW_LID,

@@ -124,6 +143,64 @@ static struct platform_device *seaboard_devices[]
 __initdata = {
 	&seaboard_gpio_keys_device,
 };
 
+static struct i2c_board_info __initdata isl29018_device = {
+	I2C_BOARD_INFO("isl29018", 0x44),
+	.irq = TEGRA_GPIO_TO_IRQ(TEGRA_GPIO_ISL29018_IRQ),
+};
+
+static struct i2c_board_info __initdata adt7461_device = {
+	I2C_BOARD_INFO("adt7461", 0x4c),
+};
+
+static void __init common_i2c_init(void)
+{
+	tegra_i2c_device1.dev.platform_data = &seaboard_i2c1_platform_data;
+	tegra_i2c_device2.dev.platform_data = &seaboard_i2c2_platform_data;
+	tegra_i2c_device3.dev.platform_data = &seaboard_i2c3_platform_data;
+	tegra_i2c_device4.dev.platform_data = &seaboard_dvc_platform_data;
+

arch/arm/mach-tegra/board-seaboard.c static struct platform_device *seaboard_devices[] · line 172

Quoted 10 lines
arch/arm/mach-tegra/board-seaboard.c +10 -0
+	platform_device_register(&tegra_i2c_device1);
+	platform_device_register(&tegra_i2c_device2);
+	platform_device_register(&tegra_i2c_device3);
+	platform_device_register(&tegra_i2c_device4);
+}
+
+static void __init seaboard_i2c_init(void)
+{
+	gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+	gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);

Hmm. For some reason I thought drivers did this themselves, or IRQ registration did this for them. However, I looked and that's not true. I think I was remembering snd_soc_jack_add_gpios instead.

So, this code looks fine, but I guess equivalent calls are missing for the WM8903 IRQ in my patches?

arch/arm/mach-tegra/board-seaboard.c static struct platform_device *seaboard_devices[] __initdata = { · line 181

Quoted 9 lines
arch/arm/mach-tegra/board-seaboard.c +9 -0
+	i2c_register_board_info(0, &isl29018_device, 1);
+
+	i2c_register_board_info(4, &adt7461_device, 1);
+
+	common_i2c_init();
+}
+
+static void __init kaen_i2c_init(void)
+{

{seaboard,kaen,wario}_i2c_init seem identical. Should this be a single shared function, and only the board-specific bits in the non-common functions? Also, see below.

Quoted 35 lines
arch/arm/mach-tegra/board-seaboard.c +24 -0
+	gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+	gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);
+
+	i2c_register_board_info(0, &isl29018_device, 1);
+
+	i2c_register_board_info(4, &adt7461_device, 1);
+
+	common_i2c_init();
+}
+
+static void __init wario_i2c_init(void)
+{
+	gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+	gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);
+
+	i2c_register_board_info(0, &isl29018_device, 1);
+
+	i2c_register_board_info(4, &adt7461_device, 1);
+
+	common_i2c_init();
+}
+
 static void __init __tegra_seaboard_init(void)
 {
 	seaboard_pinmux_init();

@@ -145,6 +222,8 @@ static void __init tegra_seaboard_init(void)
 	debug_uart_platform_data[0].irq = INT_UARTD;
 
 	__tegra_seaboard_init();
+
+	seaboard_i2c_init();
 }
 
 static void __init tegra_kaen_init(void)

arch/arm/mach-tegra/board-seaboard.c static void __init tegra_kaen_init(void) · line 236

Quoted 3 lines
arch/arm/mach-tegra/board-seaboard.c +0 -0
@@ -155,6 +234,8 @@ static void __init tegra_kaen_init(void)
 	debug_uart_platform_data[0].irq = INT_UARTB;
 
 	__tegra_seaboard_init();

__tegra_seaboard_init calls seaboard_i2c_init.

arch/arm/mach-tegra/board-seaboard.c static void __init tegra_kaen_init(void) · line 238

Quoted 2 lines
arch/arm/mach-tegra/board-seaboard.c +2 -0
+
+	kaen_i2c_init();

kaen_i2c_init is the same as seaboard_i2c_init.

So, all the registration happens twice?

Quoted 13 lines
arch/arm/mach-tegra/board-seaboard.c +2 -1
 }
 
 static void __init tegra_wario_init(void)

@@ -165,6 +246,8 @@ static void __init tegra_wario_init(void)
 	debug_uart_platform_data[0].irq = INT_UARTB;
 
 	__tegra_seaboard_init();
+
+	wario_i2c_init();
 }
 
--

1.7.0.4

Signature · 1 line
nvpublic
author
#3 lore raw

PATCH 1/3 ARM: tegra: seaboard: register i2c devices

[oops, missed reply-all]

Hi,

Quoted 11 lines · Stephen Warren

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 10 lines

Register the base i2c devices on seaboard. A few more are pending, but it's a start.

Signed-off-by Olof Johansson <[email protected]>

---
?arch/arm/mach-tegra/board-seaboard-pinmux.c | ? ?1 + ?arch/arm/mach-tegra/board-seaboard.c ? ? ? ?| ? 83
+++++++++++++++++++++++++++
?2 files changed, 84 insertions(+), 0 deletions(-)

Quoted 12 lines

arch/arm/mach-tegra/board-seaboard-pinmux.c static struct tegra_gpio_table gpio_table[] = { · line 169

Quoted 10 lines
arch/arm/mach- renamed from arch/arm/mach-tegra/board-seaboard-pinmux.c +0 -0

tegra/board-seaboard-pinmux.c
index 7e96d49..d84d1dd 100644

arch/arm/mach-tegra/board-seaboard-pinmux.c +1 -0
@@ -166,6 +166,7 @@ static struct tegra_gpio_table gpio_table[] = {
 ? ? ? { .gpio = TEGRA_GPIO_SD2_POWER, ? ? ? ? .enable = true },
 ? ? ? { .gpio = TEGRA_GPIO_LIDSWITCH, ? ? ? ? .enable = true },
 ? ? ? { .gpio = TEGRA_GPIO_POWERKEY, ? ? ? ? ?.enable = true },
+ ? ? { .gpio = TEGRA_GPIO_ISL29018_IRQ, ? ? ?.enable = true },

The indentation between fields looks different there.

No, shouldn't be? I just checked the code, it uses the same whitespace (tabs/spaces).
[...]

[...]

Quoted 11 lines

arch/arm/mach-tegra/board-seaboard-pinmux.c static struct tegra_gpio_table gpio_table[] = {

Quoted 4 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +4 -0
+static void __init seaboard_i2c_init(void)
+{
+ ? ? gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+ ? ? gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);

Hmm. For some reason I thought drivers did this themselves, or IRQ registration did this for them. However, I looked and that's not true. I think I was remembering snd_soc_jack_add_gpios instead.

So, this code looks fine, but I guess equivalent calls are missing for the WM8903 IRQ in my patches?

Yeah, probably.

Quoted 5 lines
Quoted 5 lines

+ ? ? i2c_register_board_info(0, &isl29018_device, 1);

arch/arm/mach-tegra/board-seaboard-pinmux.c +4 -0
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
Quoted 8 lines

arch/arm/mach-tegra/board-seaboard-pinmux.c

Quoted 4 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +4 -0
+}
+
+static void __init kaen_i2c_init(void)
+{

{seaboard,kaen,wario}_i2c_init seem identical. Should this be a single shared function, and only the board-specific bits in the non-common functions? Also, see below.

They are now -- they weren't when all i2c devices were registered. I can re-join them and split them when devices are re-introduced later.

Quoted 34 lines
Quoted 34 lines

+ ? ? gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+ ? ? gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);

arch/arm/mach-tegra/board-seaboard-pinmux.c +20 -0
+
+ ? ? i2c_register_board_info(0, &isl29018_device, 1);
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
+}
+
+static void __init wario_i2c_init(void)
+{
+ ? ? gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+ ? ? gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);
+
+ ? ? i2c_register_board_info(0, &isl29018_device, 1);
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
+}
+

?static void __init __tegra_seaboard_init(void)
?{
? ? ? seaboard_pinmux_init();

arch/arm/mach-tegra/board-seaboard-pinmux.c +2 -0
@@ -145,6 +222,8 @@ static void __init tegra_seaboard_init(void)
 ? ? ? debug_uart_platform_data[0].irq = INT_UARTD;
 
 ? ? ? __tegra_seaboard_init();
+
+ ? ? seaboard_i2c_init();
 ?}
Quoted 7 lines

arch/arm/mach-tegra/board-seaboard-pinmux.c static void __init tegra_kaen_init(void) · line 236

Quoted 5 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +0 -0
 ?static void __init tegra_kaen_init(void)

@@ -155,6 +234,8 @@ static void __init tegra_kaen_init(void)
 ? ? ? debug_uart_platform_data[0].irq = INT_UARTB;
 
 ? ? ? __tegra_seaboard_init();

__tegra_seaboard_init calls seaboard_i2c_init.

It shouldn't be (note __tegra* vs tegra*). Maybe I should rename __tegra_seaboard_init to something less alike.

Quoted 7 lines

arch/arm/mach-tegra/board-seaboard-pinmux.c static void __init tegra_kaen_init(void) · line 238

Quoted 3 lines
arch/arm/mach-tegra/board-seaboard-pinmux.c +2 -0
+
+ ? ? kaen_i2c_init();

kaen_i2c_init is the same as seaboard_i2c_init.

So, all the registration happens twice?

Shouldn't be. The code I am looking at doesn't, so please check your side again?

-Olof

#4 lore raw

PATCH 1/3 ARM: tegra: seaboard: register i2c devices

Olof Johansson wrote at Monday, March 07, 2011 12:30 PM:

Quoted 30 lines

[oops, missed reply-all]

Hi,

Quoted 10 lines · Stephen Warren

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 9 lines

Register the base i2c devices on seaboard. A few more are pending, but it's a start.

Signed-off-by Olof Johansson <[email protected]>

---
?arch/arm/mach-tegra/board-seaboard-pinmux.c | ? ?1 + ?arch/arm/mach-tegra/board-seaboard.c ? ? ? ?| ? 83
+++++++++++++++++++++++++++
?2 files changed, 84 insertions(+), 0 deletions(-)

...

Quoted 5 lines
Quoted 5 lines

+ ? ? i2c_register_board_info(0, &isl29018_device, 1);

arch/arm/mach-tegra/board-seaboard.c +4 -0
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
Quoted 8 lines

arch/arm/mach-tegra/board-seaboard.c static struct platform_device *seaboard_devices[] __initdata = { · line 181

Quoted 4 lines
arch/arm/mach-tegra/board-seaboard.c +4 -0
+}
+
+static void __init kaen_i2c_init(void)
+{

{seaboard,kaen,wario}_i2c_init seem identical. Should this be a single shared function, and only the board-specific bits in the non-common functions? Also, see below.

Quoted 2 lines

They are now -- they weren't when all i2c devices were registered. I can re-join them and split them when devices are re-introduced later.

Perhaps move the common code into common_i2c_init, then put only the differences in ${boardname}_i2c_init(), which would currently be empty except to call the common function?

Quoted 37 lines
Quoted 37 lines
Quoted 37 lines

+ ? ? gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+ ? ? gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);

arch/arm/mach-tegra/board-seaboard.c +20 -0
+
+ ? ? i2c_register_board_info(0, &isl29018_device, 1);
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
+}
+
+static void __init wario_i2c_init(void)
+{
+ ? ? gpio_request(TEGRA_GPIO_ISL29018_IRQ, "isl29018");
+ ? ? gpio_direction_input(TEGRA_GPIO_ISL29018_IRQ);
+
+ ? ? i2c_register_board_info(0, &isl29018_device, 1);
+
+ ? ? i2c_register_board_info(4, &adt7461_device, 1);
+
+ ? ? common_i2c_init();
+}
+

?static void __init __tegra_seaboard_init(void)
?{
? ? ? seaboard_pinmux_init();

(quoted diff) +2 -0
@@ -145,6 +222,8 @@ static void __init tegra_seaboard_init(void)
 ? ? ? debug_uart_platform_data[0].irq = INT_UARTD;
 
 ? ? ? __tegra_seaboard_init();
+
+ ? ? seaboard_i2c_init();
 ?}
 
 ?static void __init tegra_kaen_init(void)

@@ -155,6 +234,8 @@ static void __init tegra_kaen_init(void)
 ? ? ? debug_uart_platform_data[0].irq = INT_UARTB;
Quoted 6 lines
Quoted 3 lines

Review static void __init tegra_kaen_init(void) · line 236

Quoted 1 line
(quoted diff) +0 -0
 ? ? ? __tegra_seaboard_init();

__tegra_seaboard_init calls seaboard_i2c_init.

It shouldn't be (note __tegra* vs tegra*). Maybe I should rename __tegra_seaboard_init to something less alike.

Oh right. I double-checked that, but made the same reading mistake both times; the __ version appeared right above the diff, so I must have skipped reading the @@ line.

Quoted 10 lines
Quoted 7 lines

Review static void __init tegra_kaen_init(void) · line 238

Quoted 3 lines
(quoted diff) +2 -0
+
+ ? ? kaen_i2c_init();

kaen_i2c_init is the same as seaboard_i2c_init.

So, all the registration happens twice?

Shouldn't be. The code I am looking at doesn't, so please check your side again?

Yes, it looks functionally OK when read correctly.

If you want, I can ack this, but perhaps reworking the code duplication and making that __tegra_seaboard_init rename would make sense; common_seaboard_init or common_board_init?

Signature · 1 line
nvpublic
author
#5 lore raw

PATCH 1/3 ARM: tegra: seaboard: register i2c devices

Hi,

Quoted 6 lines · Stephen Warren
Quoted 2 lines

They are now -- they weren't when all i2c devices were registered. I can re-join them and split them when devices are re-introduced later.

Perhaps move the common code into common_i2c_init, then put only the differences in ${boardname}_i2c_init(), which would currently be empty except to call the common function?

I'll split up again when the need arises, i.e. when the differentiating drivers are introduced for now, I just made a common seaboard_i2c_init that's called from the common init function, i.e. undid the per-board split.

-Olof

author
#6 lore raw

PATCH 2/3 ARM: tegra: harmony: register i2c devices

In reply to Olof Johansson

Register the base i2c busses on harmony. Devices coming at a later date, but this allows for hand-probing of some of them at least.

Signed-off-by Olof Johansson <[email protected]>
---
 arch/arm/mach-tegra/board-harmony.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)
arch/arm/mach-tegra/board-harmony.c +32 -0
index 38c2ab8..d46268d 100644
@@ -24,6 +24,8 @@
 #include <linux/pda_power.h>
 #include <linux/io.h>
 #include <linux/gpio.h>
+#include <linux/i2c.h>
+#include <linux/i2c-tegra.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>

@@ -78,6 +80,35 @@ static struct platform_device harmony_audio_device = {
 	},
 };
 
+static struct tegra_i2c_platform_data harmony_i2c1_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_i2c2_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_i2c3_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_dvc_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static void harmony_i2c_init(void)
+{
+	tegra_i2c_device1.dev.platform_data = &harmony_i2c1_platform_data;
+	tegra_i2c_device2.dev.platform_data = &harmony_i2c2_platform_data;
+	tegra_i2c_device3.dev.platform_data = &harmony_i2c3_platform_data;
+	tegra_i2c_device4.dev.platform_data = &harmony_dvc_platform_data;
+
+	platform_device_register(&tegra_i2c_device1);
+	platform_device_register(&tegra_i2c_device2);
+	platform_device_register(&tegra_i2c_device3);
+	platform_device_register(&tegra_i2c_device4);
+}
+
 static struct platform_device *harmony_devices[] __initdata = {
 	&debug_uart,
 	&tegra_sdhci_device1,

@@ -140,6 +171,7 @@ static void __init tegra_harmony_init(void)
 	tegra_sdhci_device4.dev.platform_data = &sdhci_pdata4;
 
 	platform_add_devices(harmony_devices, ARRAY_SIZE(harmony_devices));
+	harmony_i2c_init();
 }
 
 MACHINE_START(HARMONY, "harmony")
Signature · 1 line
1.7.0.4
#7 lore raw

PATCH 2/3 ARM: tegra: harmony: register i2c devices

Hello.

Quoted 12 lines · Olof Johansson

Register the base i2c busses on harmony. Devices coming at a later date, but this allows for hand-probing of some of them at least.

Signed-off-by Olof Johansson<[email protected]>
---
  arch/arm/mach-tegra/board-harmony.c |   32 ++++++++++++++++++++++++++++++++
  1 files changed, 32 insertions(+), 0 deletions(-)
arch/arm/mach-tegra/board-harmony.c +0 -0
index 38c2ab8..d46268d 100644

[...]

Quoted 9 lines
arch/arm/mach-tegra/board-harmony.c +5 -0
@@ -78,6 +80,35 @@ static struct platform_device harmony_audio_device = {
  	},
  };
 
+static struct tegra_i2c_platform_data harmony_i2c1_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_i2c2_platform_data = {

arch/arm/mach-tegra/board-harmony.c static struct platform_device harmony_audio_device = { · line 97

Quoted 10 lines
arch/arm/mach-tegra/board-harmony.c +10 -0
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_i2c3_platform_data = {
+	.bus_clk_rate   = 400000,
+};
+
+static struct tegra_i2c_platform_data harmony_dvc_platform_data = {
+	.bus_clk_rate   = 400000,
+};

Why not share the paltform data between devices if it's the same anyway?

WBR, Sergei

#8 lore raw

PATCH 2/3 ARM: tegra: harmony: register i2c devices

In reply to Olof Johansson

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 4 lines

Register the base i2c busses on harmony. Devices coming at a later date, but this allows for hand-probing of some of them at least.

Signed-off-by Olof Johansson <[email protected]>

This looks OK to me.

Addressing Sergei's comments:

Quoted 5 lines

arch/arm/mach-tegra/board-harmony.c static struct platform_device harmony_audio_device = { · line 97

Quoted 3 lines
arch/arm/mach-tegra/board-harmony.c +3 -0
+static struct tegra_i2c_platform_data harmony_dvc_platform_data = {
+	.bus_clk_rate   = 400000,
+};

Why not share the paltform data between devices if it's the same anyway?

Right now, the upstream tegra_i2c_platform_data has fewer fields than some changes that I imagine are coming down the pipe from ChromeOS. i.e. the content of those 3 platform data will probably be different in the future. For this reason, it seems reasonable to keep them separate from the start. But, unifying them for now and separating in a future patch would be fine by me too.

Acked-by Stephen Warren <[email protected]>
Signature · 1 line
nvpublic
author
#9 lore raw

PATCH 3/3 ARM: tegra: enable new drivers in defconfig

In reply to Olof Johansson

Enable new platforms and tegra drivers in tegra_defconfig. Also enable some of the common devices several platforms, and GUID partition tables to make it possible to boot a tegra_defconfig kernel with a ChromiumOS filesystem.

Signed-off-by Olof Johansson <[email protected]>
---
 arch/arm/configs/tegra_defconfig |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)
arch/arm/configs/tegra_defconfig +15 -1
index 7a9267e..766e7e8 100644
@@ -21,6 +21,9 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_TEGRA=y
 CONFIG_MACH_HARMONY=y
+CONFIG_MACH_KAEN=y
+CONFIG_MACH_TRIMSLICE=y
+CONFIG_MACH_WARIO=y
 CONFIG_TEGRA_DEBUG_UARTD=y
 CONFIG_ARM_ERRATA_742230=y
 CONFIG_NO_HZ=y

@@ -78,12 +81,21 @@ CONFIG_SERIAL_8250_CONSOLE=y
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
-# CONFIG_HWMON is not set
+# CONFIG_I2C_COMPAT is not set
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_TEGRA=y
+CONFIG_SENSORS_LM90=y
 # CONFIG_MFD_SUPPORT is not set
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_STAGING=y
+# CONFIG_STAGING_EXCLUDE_BUILD is not set
+CONFIG_IIO=y
+CONFIG_SENSORS_ISL29018=y
+CONFIG_SENSORS_AK8975=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y

@@ -95,6 +107,8 @@ CONFIG_EXT3_FS_SECURITY=y
 # CONFIG_DNOTIFY is not set
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_EFI_PARTITION=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
Signature · 1 line
1.7.0.4
#10 lore raw

PATCH 3/3 ARM: tegra: enable new drivers in defconfig

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 8 lines

Enable new platforms and tegra drivers in tegra_defconfig. Also enable some of the common devices several platforms, and GUID partition tables to make it possible to boot a tegra_defconfig kernel with a ChromiumOS filesystem.

Signed-off-by Olof Johansson <[email protected]>

...

arch/arm/configs/tegra_defconfig CONFIG_SERIAL_8250_CONSOLE=y · line 87

Quoted 8 lines
arch/arm/configs/tegra_defconfig +4 -1
@@ -78,12 +81,21 @@ CONFIG_SERIAL_8250_CONSOLE=y
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
-# CONFIG_HWMON is not set
+# CONFIG_I2C_COMPAT is not set
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_TEGRA=y
+CONFIG_SENSORS_LM90=y

I'm not sure why the LM90 is needed?

Signature · 1 line
nvpublic
author
#11 lore raw

PATCH 3/3 ARM: tegra: enable new drivers in defconfig

Quoted 6 lines · Stephen Warren

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 5 lines

Enable new platforms and tegra drivers in tegra_defconfig. Also enable some of the common devices several platforms, and GUID partition tables to make it possible to boot a tegra_defconfig kernel with a ChromiumOS filesystem.

Quoted 13 lines

arch/arm/configs/tegra_defconfig CONFIG_SERIAL_8250_CONSOLE=y · line 87

Quoted 11 lines
Signed-off-by Olof Johansson <[email protected]>

...

(quoted diff) +0 -0
@@ -78,12 +81,21 @@ CONFIG_SERIAL_8250_CONSOLE=y

?# CONFIG_LEGACY_PTYS is not set
?# CONFIG_HW_RANDOM is not set
?CONFIG_I2C=y

arch/arm/configs/tegra_defconfig +4 -1
-# CONFIG_HWMON is not set
+# CONFIG_I2C_COMPAT is not set
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_TEGRA=y
+CONFIG_SENSORS_LM90=y

I'm not sure why the LM90 is needed?

LM90 == adt7461 temp sensor, registered and used on seaboard.

-Olof

#12 lore raw

PATCH 3/3 ARM: tegra: enable new drivers in defconfig

Olof Johansson wrote at Monday, March 07, 2011 12:19 PM:

Quoted 21 lines · Stephen Warren
Quoted 6 lines

Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:

Quoted 5 lines

Enable new platforms and tegra drivers in tegra_defconfig. Also enable some of the common devices several platforms, and GUID partition tables to make it possible to boot a tegra_defconfig kernel with a ChromiumOS filesystem.

Quoted 13 lines

arch/arm/configs/tegra_defconfig CONFIG_SERIAL_8250_CONSOLE=y · line 87

Quoted 11 lines
Signed-off-by Olof Johansson <[email protected]>

...

(quoted diff) +0 -0
@@ -78,12 +81,21 @@ CONFIG_SERIAL_8250_CONSOLE=y

?# CONFIG_LEGACY_PTYS is not set
?# CONFIG_HW_RANDOM is not set
?CONFIG_I2C=y

arch/arm/configs/tegra_defconfig +4 -1
-# CONFIG_HWMON is not set
+# CONFIG_I2C_COMPAT is not set
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_TEGRA=y
+CONFIG_SENSORS_LM90=y

I'm not sure why the LM90 is needed?

Quoted 1 line

LM90 == adt7461 temp sensor, registered and used on seaboard.

Ah, it's a compatible device. In that case,

Acked-by Stephen Warren <[email protected]>
Signature · 1 line
nvpublic
#13 lore raw

cover Tegra i2c board changes + defconfig update

In reply to Olof Johansson
Quoted 23 lines · Olof Johansson

Hi,

Here is a short series of i2c patches to configure the i2c-tegra driver for the boards in the tree, and to register some of the devices.

It also includes a defconfig update that enables the new drivers, enables TRIMSLICE by default since the pcie fix makes it possible and also turns on a few more config options that are useful (i.e. EFI partition tables and some common board devices).

Since these patches rely on drivers that will be merged during the upcoming window, this is my plan:

* Check them into boards-for-next together with Stephen W's ?other late-merge board patches in a day or two
* Ask sfr to add said branch to linux-next (towards the end of list of trees)
* Sit on them until merge window is open and base tegra, i2c and asoc have ?all been merged
* Rebase to current upstream when said trees are in, let it sit for 1 ?day for a linux-next cycle for sanity-check
* Send pull request

Quoted 1 line

-Olof

Do we need two branches in linux-next? I think we should just push all of this to Tegra's for-next branch, and keep a for-linus branch that points to the last change that will build without merging with linux-next. There shouldn't be any conflicts with linux-next, and there is no need for linux-next to build after merging some of its branches.

#14 lore raw

cover Tegra i2c board changes + defconfig update

Quoted 3 lines · Colin Cross

linux-next. There shouldn't be any conflicts with linux-next, and there is no need for linux-next to build after merging some of its branches.

-next gets built after each merge so the tree does need to merge without the trees that get merged later on.

#15 lore raw

cover Tegra i2c board changes + defconfig update

Quoted 8 lines · Mark Brown
Quoted 3 lines · Colin Cross

linux-next. ?There shouldn't be any conflicts with linux-next, and there is no need for linux-next to build after merging some of its branches.

-next gets built after each merge so the tree does need to merge without the trees that get merged later on.

Ok, we can make sure Tegra is merged after i2c and asoc, in which case it should build fine.

author
#16 lore raw

cover Tegra i2c board changes + defconfig update

Quoted 8 lines · Colin Cross
Quoted 6 lines · Mark Brown
Quoted 3 lines · Colin Cross

linux-next. ?There shouldn't be any conflicts with linux-next, and there is no need for linux-next to build after merging some of its branches.

Quoted 5 lines
Quoted 2 lines

-next gets built after each merge so the tree does need to merge without the trees that get merged later on.

Ok, we can make sure Tegra is merged after i2c and asoc, in which case it should build fine.

Main drawback is that the tegra main for-next branch doesn't build on its own then. Not a big deal, especially not this close to the merge window, IMHO.

I'll send a new pull request picking up the recently posted patches then. I'm actually OK with the paz00 patches going in .39 myself, since they don't impact any of the existing code, so nothing can regress because of them.

New pull request in a bit.

-Olof