Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-27 Thread Lee Jones 
On Fri, 23 Aug 2013, Linus Walleij wrote:

> On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij  
> wrote:
> 
> > It is not true at all that all HREFs have the STUIB mounted.
> 
> Hm I'm confused here...
> 
> arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff
> so forget about the misplaced comments.
> 
> For *all* HREF boards. As it is included from both
> [ste-]hrefprev60.dts and [ste-]hrefv60plus.dts
> 
> However it is only really mounted on some of the HREFs,
> and the following stays valid:
> 
> > This detection needs to stay for now, unless we go and define
> > in the device tree which UIB is mounted, which would be unfortunate
> > as we can very well auto-detect it, and that makes it easier for
> > a user to just swap the UIB and test the other toch screen
> > (for example).
> 
> So it would be really nice to keep this autodetection.
> 
> What would be nice if we could mark all the STUIB as
> "disabled" in the device trees, and then augment the device tree
> at boot depending on if we find something at 0x44 as in this
> test:
> 
> > -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
> > -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
> > -   I2C_SMBUS_QUICK, NULL);
> 
> And then mark these as "okay" in the DT.
> 
> That's pretty high-tech but I bet we can pull it off (and set
> a good example).

Well, this stuff is possible, but it doesn't really have anything to
do with this patch-set. We can reuse 'some' of this code, but we'd need
to think of a new way to represent it. That coupled with the fact that
the Device Tree boot doesn't use any of this stuff yet leads to
believe we can keep this removal patch in the set and re-introduce the
key parts when we've had a chat about the new implementation.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-27 Thread Lee Jones 
On Fri, 23 Aug 2013, Linus Walleij wrote:

 On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij linus.wall...@linaro.org 
 wrote:
 
  It is not true at all that all HREFs have the STUIB mounted.
 
 Hm I'm confused here...
 
 arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff
 so forget about the misplaced comments.
 
 For *all* HREF boards. As it is included from both
 [ste-]hrefprev60.dts and [ste-]hrefv60plus.dts
 
 However it is only really mounted on some of the HREFs,
 and the following stays valid:
 
  This detection needs to stay for now, unless we go and define
  in the device tree which UIB is mounted, which would be unfortunate
  as we can very well auto-detect it, and that makes it easier for
  a user to just swap the UIB and test the other toch screen
  (for example).
 
 So it would be really nice to keep this autodetection.
 
 What would be nice if we could mark all the STUIB as
 disabled in the device trees, and then augment the device tree
 at boot depending on if we find something at 0x44 as in this
 test:
 
  -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
  -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
  -   I2C_SMBUS_QUICK, NULL);
 
 And then mark these as okay in the DT.
 
 That's pretty high-tech but I bet we can pull it off (and set
 a good example).

Well, this stuff is possible, but it doesn't really have anything to
do with this patch-set. We can reuse 'some' of this code, but we'd need
to think of a new way to represent it. That coupled with the fact that
the Device Tree boot doesn't use any of this stuff yet leads to
believe we can keep this removal patch in the set and re-introduce the
key parts when we've had a chat about the new implementation.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Linus Walleij 
On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij  wrote:

> It is not true at all that all HREFs have the STUIB mounted.

Hm I'm confused here...

arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff
so forget about the misplaced comments.

For *all* HREF boards. As it is included from both
[ste-]hrefprev60.dts and [ste-]hrefv60plus.dts

However it is only really mounted on some of the HREFs,
and the following stays valid:

> This detection needs to stay for now, unless we go and define
> in the device tree which UIB is mounted, which would be unfortunate
> as we can very well auto-detect it, and that makes it easier for
> a user to just swap the UIB and test the other toch screen
> (for example).

So it would be really nice to keep this autodetection.

What would be nice if we could mark all the STUIB as
"disabled" in the device trees, and then augment the device tree
at boot depending on if we find something at 0x44 as in this
test:

> -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
> -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
> -   I2C_SMBUS_QUICK, NULL);

And then mark these as "okay" in the DT.

That's pretty high-tech but I bet we can pull it off (and set
a good example).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Linus Walleij 
On Fri, Aug 23, 2013 at 2:23 PM, Lee Jones  wrote:

> It's time to remove all ATAG support from ux500 and rely solely on
> Device Tree booting. This patch is part of that endeavour.
>
> Signed-off-by: Lee Jones 

This needs some more afterthought.

> -   i2c0 = i2c_get_adapter(0);
> -   if (!i2c0) {
> -   __mop500_uib_init(_uibs[STUIB],
> -   "fallback, could not get i2c0");
> -   return -ENODEV;
> -   }
> -
> -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
> -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
> -   I2C_SMBUS_QUICK, NULL);
> -   i2c_put_adapter(i2c0);
> -
> -   if (ret == 0)
> -   uib = _uibs[U8500UIB];
> -   else
> -   uib = _uibs[STUIB];
> -
> -   __mop500_uib_init(uib, "detected");
> +   __mop500_uib_init(_uibs[STUIB], "detected");

It is not true at all that all HREFs have the STUIB mounted.

This detection needs to stay for now, unless we go and define
in the device tree which UIB is mounted, which would be unfortunate
as we can very well auto-detect it, and that makes it easier for
a user to just swap the UIB and test the other toch screen
(for example).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Lee Jones 
It's time to remove all ATAG support from ux500 and rely solely on
Device Tree booting. This patch is part of that endeavour.

Signed-off-by: Lee Jones 
---
 arch/arm/mach-ux500/Makefile|  1 -
 arch/arm/mach-ux500/board-mop500-u8500uib.c | 14 --
 arch/arm/mach-ux500/board-mop500-uib.c  | 30 +
 arch/arm/mach-ux500/board-mop500.h  |  1 -
 4 files changed, 1 insertion(+), 45 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/board-mop500-u8500uib.c

diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index cac22ba..8634a3fa 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_UX500_SOC_DB8500)+= cpu-db8500.o 
devices-db8500.o
 obj-$(CONFIG_MACH_MOP500)  += board-mop500.o board-mop500-sdi.o \
board-mop500-regulators.o \
board-mop500-uib.o board-mop500-stuib.o \
-   board-mop500-u8500uib.o \
board-mop500-pins.o \
board-mop500-audio.o
 obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
diff --git a/arch/arm/mach-ux500/board-mop500-u8500uib.c 
b/arch/arm/mach-ux500/board-mop500-u8500uib.c
deleted file mode 100644
index 43c9ff1..000
--- a/arch/arm/mach-ux500/board-mop500-u8500uib.c
+++ /dev/null
@@ -1,14 +0,0 @@
-/*
- * Copyright (C) ST-Ericsson SA 2010
- *
- * Board data for the U8500 UIB, also known as the New UIB
- * License terms: GNU General Public License (GPL), version 2
- */
-#include 
-#include 
-
-#include "board-mop500.h"
-
-void __init mop500_u8500uib_init(void)
-{
-}
diff --git a/arch/arm/mach-ux500/board-mop500-uib.c 
b/arch/arm/mach-ux500/board-mop500-uib.c
index bdaa422..0e94f1d 100644
--- a/arch/arm/mach-ux500/board-mop500-uib.c
+++ b/arch/arm/mach-ux500/board-mop500-uib.c
@@ -16,7 +16,6 @@
 
 enum mop500_uib {
STUIB,
-   U8500UIB,
 };
 
 struct uib {
@@ -31,11 +30,6 @@ static struct uib __initdata mop500_uibs[] = {
.option = "stuib",
.init   = mop500_stuib_init,
},
-   [U8500UIB] = {
-   .name   = "U8500-UIB",
-   .option = "u8500uib",
-   .init   = mop500_u8500uib_init,
-   },
 };
 
 static struct uib *mop500_uib;
@@ -93,14 +87,9 @@ static void __init __mop500_uib_init(struct uib *uib, const 
char *why)
uib->init();
 }
 
-/*
- * Detect the UIB attached based on the presence or absence of i2c devices.
- */
 int __init mop500_uib_init(void)
 {
struct uib *uib = mop500_uib;
-   struct i2c_adapter *i2c0;
-   int ret;
 
if (!cpu_is_u8500_family())
return -ENODEV;
@@ -110,24 +99,7 @@ int __init mop500_uib_init(void)
return 0;
}
 
-   i2c0 = i2c_get_adapter(0);
-   if (!i2c0) {
-   __mop500_uib_init(_uibs[STUIB],
-   "fallback, could not get i2c0");
-   return -ENODEV;
-   }
-
-   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
-   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
-   I2C_SMBUS_QUICK, NULL);
-   i2c_put_adapter(i2c0);
-
-   if (ret == 0)
-   uib = _uibs[U8500UIB];
-   else
-   uib = _uibs[STUIB];
-
-   __mop500_uib_init(uib, "detected");
+   __mop500_uib_init(_uibs[STUIB], "detected");
 
return 0;
 }
diff --git a/arch/arm/mach-ux500/board-mop500.h 
b/arch/arm/mach-ux500/board-mop500.h
index cf6b304..223639b 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -89,7 +89,6 @@ extern struct msp_i2s_platform_data msp2_platform_data;
 extern struct msp_i2s_platform_data msp3_platform_data;
 extern struct pl022_ssp_controller ssp0_plat;
 
-void __init mop500_u8500uib_init(void);
 void __init mop500_stuib_init(void);
 void __init mop500_pinmaps_init(void);
 void __init snowball_pinmaps_init(void);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Lee Jones 
It's time to remove all ATAG support from ux500 and rely solely on
Device Tree booting. This patch is part of that endeavour.

Signed-off-by: Lee Jones lee.jo...@linaro.org
---
 arch/arm/mach-ux500/Makefile|  1 -
 arch/arm/mach-ux500/board-mop500-u8500uib.c | 14 --
 arch/arm/mach-ux500/board-mop500-uib.c  | 30 +
 arch/arm/mach-ux500/board-mop500.h  |  1 -
 4 files changed, 1 insertion(+), 45 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/board-mop500-u8500uib.c

diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index cac22ba..8634a3fa 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_UX500_SOC_DB8500)+= cpu-db8500.o 
devices-db8500.o
 obj-$(CONFIG_MACH_MOP500)  += board-mop500.o board-mop500-sdi.o \
board-mop500-regulators.o \
board-mop500-uib.o board-mop500-stuib.o \
-   board-mop500-u8500uib.o \
board-mop500-pins.o \
board-mop500-audio.o
 obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
diff --git a/arch/arm/mach-ux500/board-mop500-u8500uib.c 
b/arch/arm/mach-ux500/board-mop500-u8500uib.c
deleted file mode 100644
index 43c9ff1..000
--- a/arch/arm/mach-ux500/board-mop500-u8500uib.c
+++ /dev/null
@@ -1,14 +0,0 @@
-/*
- * Copyright (C) ST-Ericsson SA 2010
- *
- * Board data for the U8500 UIB, also known as the New UIB
- * License terms: GNU General Public License (GPL), version 2
- */
-#include linux/kernel.h
-#include linux/init.h
-
-#include board-mop500.h
-
-void __init mop500_u8500uib_init(void)
-{
-}
diff --git a/arch/arm/mach-ux500/board-mop500-uib.c 
b/arch/arm/mach-ux500/board-mop500-uib.c
index bdaa422..0e94f1d 100644
--- a/arch/arm/mach-ux500/board-mop500-uib.c
+++ b/arch/arm/mach-ux500/board-mop500-uib.c
@@ -16,7 +16,6 @@
 
 enum mop500_uib {
STUIB,
-   U8500UIB,
 };
 
 struct uib {
@@ -31,11 +30,6 @@ static struct uib __initdata mop500_uibs[] = {
.option = stuib,
.init   = mop500_stuib_init,
},
-   [U8500UIB] = {
-   .name   = U8500-UIB,
-   .option = u8500uib,
-   .init   = mop500_u8500uib_init,
-   },
 };
 
 static struct uib *mop500_uib;
@@ -93,14 +87,9 @@ static void __init __mop500_uib_init(struct uib *uib, const 
char *why)
uib-init();
 }
 
-/*
- * Detect the UIB attached based on the presence or absence of i2c devices.
- */
 int __init mop500_uib_init(void)
 {
struct uib *uib = mop500_uib;
-   struct i2c_adapter *i2c0;
-   int ret;
 
if (!cpu_is_u8500_family())
return -ENODEV;
@@ -110,24 +99,7 @@ int __init mop500_uib_init(void)
return 0;
}
 
-   i2c0 = i2c_get_adapter(0);
-   if (!i2c0) {
-   __mop500_uib_init(mop500_uibs[STUIB],
-   fallback, could not get i2c0);
-   return -ENODEV;
-   }
-
-   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
-   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
-   I2C_SMBUS_QUICK, NULL);
-   i2c_put_adapter(i2c0);
-
-   if (ret == 0)
-   uib = mop500_uibs[U8500UIB];
-   else
-   uib = mop500_uibs[STUIB];
-
-   __mop500_uib_init(uib, detected);
+   __mop500_uib_init(mop500_uibs[STUIB], detected);
 
return 0;
 }
diff --git a/arch/arm/mach-ux500/board-mop500.h 
b/arch/arm/mach-ux500/board-mop500.h
index cf6b304..223639b 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -89,7 +89,6 @@ extern struct msp_i2s_platform_data msp2_platform_data;
 extern struct msp_i2s_platform_data msp3_platform_data;
 extern struct pl022_ssp_controller ssp0_plat;
 
-void __init mop500_u8500uib_init(void);
 void __init mop500_stuib_init(void);
 void __init mop500_pinmaps_init(void);
 void __init snowball_pinmaps_init(void);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Linus Walleij 
On Fri, Aug 23, 2013 at 2:23 PM, Lee Jones lee.jo...@linaro.org wrote:

 It's time to remove all ATAG support from ux500 and rely solely on
 Device Tree booting. This patch is part of that endeavour.

 Signed-off-by: Lee Jones lee.jo...@linaro.org

This needs some more afterthought.

 -   i2c0 = i2c_get_adapter(0);
 -   if (!i2c0) {
 -   __mop500_uib_init(mop500_uibs[STUIB],
 -   fallback, could not get i2c0);
 -   return -ENODEV;
 -   }
 -
 -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
 -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
 -   I2C_SMBUS_QUICK, NULL);
 -   i2c_put_adapter(i2c0);
 -
 -   if (ret == 0)
 -   uib = mop500_uibs[U8500UIB];
 -   else
 -   uib = mop500_uibs[STUIB];
 -
 -   __mop500_uib_init(uib, detected);
 +   __mop500_uib_init(mop500_uibs[STUIB], detected);

It is not true at all that all HREFs have the STUIB mounted.

This detection needs to stay for now, unless we go and define
in the device tree which UIB is mounted, which would be unfortunate
as we can very well auto-detect it, and that makes it easier for
a user to just swap the UIB and test the other toch screen
(for example).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

2013-08-23 Thread Linus Walleij 
On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij linus.wall...@linaro.org wrote:

 It is not true at all that all HREFs have the STUIB mounted.

Hm I'm confused here...

arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff
so forget about the misplaced comments.

For *all* HREF boards. As it is included from both
[ste-]hrefprev60.dts and [ste-]hrefv60plus.dts

However it is only really mounted on some of the HREFs,
and the following stays valid:

 This detection needs to stay for now, unless we go and define
 in the device tree which UIB is mounted, which would be unfortunate
 as we can very well auto-detect it, and that makes it easier for
 a user to just swap the UIB and test the other toch screen
 (for example).

So it would be really nice to keep this autodetection.

What would be nice if we could mark all the STUIB as
disabled in the device trees, and then augment the device tree
at boot depending on if we find something at 0x44 as in this
test:

 -   /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
 -   ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
 -   I2C_SMBUS_QUICK, NULL);

And then mark these as okay in the DT.

That's pretty high-tech but I bet we can pull it off (and set
a good example).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/