From: Olof Johansson <hidden> Date: 2011-03-07 08:26:36
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
From: Olof Johansson <hidden> Date: 2011-03-07 08:26:37
Register the base i2c devices on seaboard. A few more are pending,
but it's a start.
Signed-off-by: Olof Johansson <redacted>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 1 +
arch/arm/mach-tegra/board-seaboard.c | 83 +++++++++++++++++++++++++++
2 files changed, 84 insertions(+), 0 deletions(-)
From: Olof Johansson <hidden> Date: 2011-03-07 08:26:38
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 <redacted>
---
arch/arm/mach-tegra/board-harmony.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
From: Olof Johansson <hidden> Date: 2011-03-07 08:26:39
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 <redacted>
---
arch/arm/configs/tegra_defconfig | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
@@ -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
From: Stephen Warren <hidden> Date: 2011-03-07 17:24:00
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted hunk
Register the base i2c devices on seaboard. A few more are pending,
but it's a start.
Signed-off-by: Olof Johansson <redacted>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 1 +
arch/arm/mach-tegra/board-seaboard.c | 83
+++++++++++++++++++++++++++
2 files changed, 84 insertions(+), 0 deletions(-)
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?
{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.
From: Stephen Warren <hidden> Date: 2011-03-07 17:29:26
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
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 <redacted>
This looks OK to me.
Addressing Sergei's comments:
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 <redacted>
--
nvpublic
From: Stephen Warren <hidden> Date: 2011-03-07 17:34:38
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted hunk
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 <redacted>
...
@@ -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
From: Olof Johansson <hidden> Date: 2011-03-07 19:18:50
On Mon, Mar 7, 2011 at 9:34 AM, Stephen Warren [off-list ref] wrote:
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted
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 <redacted>
...
@@ -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?
LM90 == adt7461 temp sensor, registered and used on seaboard.
-Olof
From: Stephen Warren <hidden> Date: 2011-03-07 19:24:56
Olof Johansson wrote at Monday, March 07, 2011 12:19 PM:
On Mon, Mar 7, 2011 at 9:34 AM, Stephen Warren [off-list ref] wrote:
quoted
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted
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 <redacted>
...
@@ -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?
LM90 == adt7461 temp sensor, registered and used on seaboard.
Ah, it's a compatible device. In that case,
Acked-by: Stephen Warren <redacted>
--
nvpublic
From: Olof Johansson <hidden> Date: 2011-03-07 19:29:53
[oops, missed reply-all]
Hi,
On Mon, Mar 7, 2011 at 9:24 AM, Stephen Warren [off-list ref] wrote:
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted
Register the base i2c devices on seaboard. A few more are pending,
but it's a start.
Signed-off-by: Olof Johansson <redacted>
---
?arch/arm/mach-tegra/board-seaboard-pinmux.c | ? ?1 +
?arch/arm/mach-tegra/board-seaboard.c ? ? ? ?| ? 83
+++++++++++++++++++++++++++
?2 files changed, 84 insertions(+), 0 deletions(-)
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?
{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.
From: Stephen Warren <hidden> Date: 2011-03-07 19:39:31
Olof Johansson wrote at Monday, March 07, 2011 12:30 PM:
[oops, missed reply-all]
Hi,
On Mon, Mar 7, 2011 at 9:24 AM, Stephen Warren [off-list ref] wrote:
quoted
Olof Johansson wrote at Monday, March 07, 2011 1:27 AM:
quoted
Register the base i2c devices on seaboard. A few more are pending,
but it's a start.
Signed-off-by: Olof Johansson <redacted>
---
?arch/arm/mach-tegra/board-seaboard-pinmux.c | ? ?1 +
?arch/arm/mach-tegra/board-seaboard.c ? ? ? ?| ? 83
+++++++++++++++++++++++++++
?2 files changed, 84 insertions(+), 0 deletions(-)
{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.
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?
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
quoted
+
+ ? ? 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?
--
nvpublic
From: Colin Cross <hidden> Date: 2011-03-07 19:59:02
On Mon, Mar 7, 2011 at 12:26 AM, Olof Johansson [off-list ref] wrote:
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
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.
From: Olof Johansson <hidden> Date: 2011-03-07 23:13:49
On Mon, Mar 7, 2011 at 12:07 PM, Colin Cross [off-list ref] wrote:
On Mon, Mar 7, 2011 at 12:04 PM, Mark Brown
[off-list ref] wrote:
quoted
On Mon, Mar 07, 2011 at 11:59:02AM -0800, Colin Cross wrote:
quoted
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.
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
From: Olof Johansson <hidden> Date: 2011-03-07 23:26:17
Hi,
On Mon, Mar 7, 2011 at 11:39 AM, Stephen Warren [off-list ref] wrote:
quoted
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