[PATCH 0/5] Prepare making omap3 device tree only and convert LDP

[PATCH 0/5] Prepare making omap3 device tree only and convert LDP

[Tony Lindgren]

Hi all,

Here are few patches to deal with the mix of legacy platform data
and device tree that we still need to do at least until DSS has
device tree bindings. These patches should allow the remaining
omap3 boards to be made device tree only so we can remove the
board-*.c files.

I've also converted the old LDP board to be device tree only as that
has the typical TWL GPIO controlled LCD panel setup, and made sure
the basic things work.

These patches are against mainline tree commit 10d0c9705, and also
needs the recently posted patches from following:

[PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window
[PATCH 00/11] Make omap24xx booting device tree based for v3.14 merge window

I've also pushed all the related patches to a temporary branch
omap-for-v3.14/tmp-testing-dt in the linux-omap git tree.

Regards,

Tony


Tony Lindgren (5):
  mfd: twl-core: Fix passing of platform data in the device tree case
  ARM: OMAP2+: Add support for legacy auxdata for twl
  ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to
    use it
  ARM: dts: Add basic support for omap3 LDP zoom1 labrador
  ARM: OMAP2+: Remove legacy booting support for LDP

 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/omap3-ldp.dts    | 231 ++++++++++++++++++++
 arch/arm/mach-omap2/Kconfig        |   6 -
 arch/arm/mach-omap2/Makefile       |   1 -
 arch/arm/mach-omap2/board-ldp.c    | 425 -------------------------------------
 arch/arm/mach-omap2/common.h       |   1 +
 arch/arm/mach-omap2/dss-common.c   |  67 ++++++
 arch/arm/mach-omap2/dss-common.h   |   1 +
 arch/arm/mach-omap2/omap_device.c  |   2 +
 arch/arm/mach-omap2/pdata-quirks.c |  31 +++
 drivers/mfd/twl-core.c             |  15 +-
 11 files changed, 346 insertions(+), 435 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-ldp.dts
 delete mode 100644 arch/arm/mach-omap2/board-ldp.c

-- 
1.8.1.1

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Tony Lindgren]

Since we still need to rely on a mix of device tree initialized
drivers and legacy platform data initialize drivers, let's fix
the passing of platform data to twl4030-gpio.

As the twl4030 GPIO is initialized by twl-core.c, we need to register
the auxdata for twl4030 GPIO in twl-core.c.

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks
OK to you as I have other patches that depend on this.

---
 drivers/mfd/twl-core.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 29473c2..d5b3dd8 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client)
 	return 0;
 }
 
+static struct of_dev_auxdata twl_auxdata_lookup[] = {
+	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
+	{ /* sentinel */ },
+};
+
 /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
 static int
 twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
 		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
 	}
 
-	if (node)
-		status = of_platform_populate(node, NULL, NULL, &client->dev);
-	else
+	if (node) {
+		if (pdata)
+			twl_auxdata_lookup[0].platform_data = pdata->gpio;
+		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
+					      &client->dev);
+	} else {
 		status = add_children(pdata, irq_base, id->driver_data);
+	}
 
 fail:
 	if (status < 0)
-- 
1.8.1.1

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

> Since we still need to rely on a mix of device tree initialized
> drivers and legacy platform data initialize drivers, let's fix
> the passing of platform data to twl4030-gpio.
> 
> As the twl4030 GPIO is initialized by twl-core.c, we need to register
> the auxdata for twl4030 GPIO in twl-core.c.
> 
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks
> OK to you as I have other patches that depend on this.
> 
> ---
>  drivers/mfd/twl-core.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 29473c2..d5b3dd8 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client)
>  	return 0;
>  }
>  
> +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> +	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> +	{ /* sentinel */ },
> +};
> +
>  /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
>  static int
>  twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>  		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
>  	}
>  
> -	if (node)
> -		status = of_platform_populate(node, NULL, NULL, &client->dev);
> -	else
> +	if (node) {
> +		if (pdata)
> +			twl_auxdata_lookup[0].platform_data = pdata->gpio;
> +		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
> +					      &client->dev);
> +	} else {
>  		status = add_children(pdata, irq_base, id->driver_data);

Why doesn't the TWL driver use the MFD framework for this stuff?

> +	}
>  
>  fail:
>  	if (status < 0)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Felipe Balbi]

Hi,

On Mon, Nov 18, 2013 at 10:29:07AM +0000, Lee Jones wrote:
> > Since we still need to rely on a mix of device tree initialized
> > drivers and legacy platform data initialize drivers, let's fix
> > the passing of platform data to twl4030-gpio.
> > 
> > As the twl4030 GPIO is initialized by twl-core.c, we need to register
> > the auxdata for twl4030 GPIO in twl-core.c.
> > 
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > 
> > Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks
> > OK to you as I have other patches that depend on this.
> > 
> > ---
> >  drivers/mfd/twl-core.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> > index 29473c2..d5b3dd8 100644
> > --- a/drivers/mfd/twl-core.c
> > +++ b/drivers/mfd/twl-core.c
> > @@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client)
> >  	return 0;
> >  }
> >  
> > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > +	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > +	{ /* sentinel */ },
> > +};
> > +
> >  /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
> >  static int
> >  twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> >  		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> >  	}
> >  
> > -	if (node)
> > -		status = of_platform_populate(node, NULL, NULL, &client->dev);
> > -	else
> > +	if (node) {
> > +		if (pdata)
> > +			twl_auxdata_lookup[0].platform_data = pdata->gpio;
> > +		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
> > +					      &client->dev);
> > +	} else {
> >  		status = add_children(pdata, irq_base, id->driver_data);
> 
> Why doesn't the TWL driver use the MFD framework for this stuff?

that's reminiscent from years ago and, surely, needs to be fixed. Should
we gate $subject for that, though ? This has been in tree for quite a
few years already and Tony's patch is still a step forward, since most
omap3 platforms would break on DT-only without it.

There are quite a few folks who could volunteer to fixing that after
Tony's patch is in (me included, although there could be better choices
hehe).

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/c09d0cfa/attachment.sig>

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

> > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > +	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > +	{ /* sentinel */ },
> > > +};
> > > +
> > >  /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
> > >  static int
> > >  twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > >  		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> > >  	}
> > >  
> > > -	if (node)
> > > -		status = of_platform_populate(node, NULL, NULL, &client->dev);
> > > -	else
> > > +	if (node) {
> > > +		if (pdata)
> > > +			twl_auxdata_lookup[0].platform_data = pdata->gpio;
> > > +		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
> > > +					      &client->dev);
> > > +	} else {
> > >  		status = add_children(pdata, irq_base, id->driver_data);
> > 
> > Why doesn't the TWL driver use the MFD framework for this stuff?
> 
> that's reminiscent from years ago and, surely, needs to be fixed. Should
> we gate $subject for that, though ? This has been in tree for quite a
> few years already and Tony's patch is still a step forward, since most
> omap3 platforms would break on DT-only without it.

I didn't say that I would reject the patch. I was just surprised to
see so much hand-rolling, as the MFD core code does much of it
automatically. This is the first time I've taken a look at this and it
seems to be quite the relic.

> There are quite a few folks who could volunteer to fixing that after
> Tony's patch is in (me included, although there could be better choices
> hehe).

Well it's not doing any harm. I'll make a note to fix it myself if a)
no one has done so already and b) I manage to find some spare
time. The latter issue is less likely to be resolved. :)

Are you Acking this patch by the way?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Tony Lindgren]

* Lee Jones <lee.jones@linaro.org> [131118 09:47]:
> > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > > +	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > > +	{ /* sentinel */ },
> > > > +};
> > > > +
> > > >  /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
> > > >  static int
> > > >  twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > > >  		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> > > >  	}
> > > >  
> > > > -	if (node)
> > > > -		status = of_platform_populate(node, NULL, NULL, &client->dev);
> > > > -	else
> > > > +	if (node) {
> > > > +		if (pdata)
> > > > +			twl_auxdata_lookup[0].platform_data = pdata->gpio;
> > > > +		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
> > > > +					      &client->dev);
> > > > +	} else {
> > > >  		status = add_children(pdata, irq_base, id->driver_data);
> > > 
> > > Why doesn't the TWL driver use the MFD framework for this stuff?
> > 
> > that's reminiscent from years ago and, surely, needs to be fixed. Should
> > we gate $subject for that, though ? This has been in tree for quite a
> > few years already and Tony's patch is still a step forward, since most
> > omap3 platforms would break on DT-only without it.
> 
> I didn't say that I would reject the patch. I was just surprised to
> see so much hand-rolling, as the MFD core code does much of it
> automatically. This is the first time I've taken a look at this and it
> seems to be quite the relic.

Yeah it seems something from the early days of MFD code. Then grepping for
add_children shows that drivers/mfd/dm355evm_msp.c is doing it too, which
should also be fixed while at it.
 
> > There are quite a few folks who could volunteer to fixing that after
> > Tony's patch is in (me included, although there could be better choices
> > hehe).
> 
> Well it's not doing any harm. I'll make a note to fix it myself if a)
> no one has done so already and b) I manage to find some spare
> time. The latter issue is less likely to be resolved. :)

Sounds like Felipe has already picked it up for future work :)
 
> Are you Acking this patch by the way?

If this looks acceptable to you guys, I'd like to merge this via my fixes
branch this week with your acks if that works for you. That way I can base
my omap legacy platform data removal patches on my fixes branch while keep
things working for the drivers. Alternatively I can naturally base my
legacy data removal on -rc2 too if this gets merged to mainline by then 
via the MFD tree.

Regards,

Tony

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

> > Are you Acking this patch by the way?
> 
> If this looks acceptable to you guys, I'd like to merge this via my fixes
> branch this week with your acks if that works for you. That way I can base
> my omap legacy platform data removal patches on my fixes branch while keep
> things working for the drivers. Alternatively I can naturally base my
> legacy data removal on -rc2 too if this gets merged to mainline by then 
> via the MFD tree.

I can either send it up for the -rcs, or I can create an immutable
branch for you to pull from. That way the patch can do in via ARM-SoC
and MFD and we can let Git sort it out.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Tony Lindgren]

* Lee Jones <lee.jones@linaro.org> [131118 11:10]:
> > > Are you Acking this patch by the way?
> > 
> > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > branch this week with your acks if that works for you. That way I can base
> > my omap legacy platform data removal patches on my fixes branch while keep
> > things working for the drivers. Alternatively I can naturally base my
> > legacy data removal on -rc2 too if this gets merged to mainline by then 
> > via the MFD tree.
> 
> I can either send it up for the -rcs, or I can create an immutable
> branch for you to pull from. That way the patch can do in via ARM-SoC
> and MFD and we can let Git sort it out.

OK great, I'd prefer an immutable branch that I can merge in too. Then
you can bundle it with other MFD fixes for the -rc series and send it
in when it suits you :)

Regards,

Tony

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

On Mon, 18 Nov 2013, Tony Lindgren wrote:

> * Lee Jones <lee.jones@linaro.org> [131118 11:10]:
> > > > Are you Acking this patch by the way?
> > > 
> > > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > > branch this week with your acks if that works for you. That way I can base
> > > my omap legacy platform data removal patches on my fixes branch while keep
> > > things working for the drivers. Alternatively I can naturally base my
> > > legacy data removal on -rc2 too if this gets merged to mainline by then 
> > > via the MFD tree.
> > 
> > I can either send it up for the -rcs, or I can create an immutable
> > branch for you to pull from. That way the patch can do in via ARM-SoC
> > and MFD and we can let Git sort it out.
> 
> OK great, I'd prefer an immutable branch that I can merge in too. Then
> you can bundle it with other MFD fixes for the -rc series and send it
> in when it suits you :)

That's fine. It's 19:30 here now and I still have a shed load of
debugging to do, so I'll deal with this tomorrow if it's all the same
to you?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Tony Lindgren]

* Lee Jones <lee.jones@linaro.org> [131118 11:29]:
> On Mon, 18 Nov 2013, Tony Lindgren wrote:
> 
> > * Lee Jones <lee.jones@linaro.org> [131118 11:10]:
> > > > > Are you Acking this patch by the way?
> > > > 
> > > > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > > > branch this week with your acks if that works for you. That way I can base
> > > > my omap legacy platform data removal patches on my fixes branch while keep
> > > > things working for the drivers. Alternatively I can naturally base my
> > > > legacy data removal on -rc2 too if this gets merged to mainline by then 
> > > > via the MFD tree.
> > > 
> > > I can either send it up for the -rcs, or I can create an immutable
> > > branch for you to pull from. That way the patch can do in via ARM-SoC
> > > and MFD and we can let Git sort it out.
> > 
> > OK great, I'd prefer an immutable branch that I can merge in too. Then
> > you can bundle it with other MFD fixes for the -rc series and send it
> > in when it suits you :)
> 
> That's fine. It's 19:30 here now and I still have a shed load of
> debugging to do, so I'll deal with this tomorrow if it's all the same
> to you?

Yeah sure I can wait few days no problem.

Thanks,

Tony

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

On Mon, 18 Nov 2013, Tony Lindgren wrote:

> * Lee Jones <lee.jones@linaro.org> [131118 11:10]:
> > > > Are you Acking this patch by the way?
> > > 
> > > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > > branch this week with your acks if that works for you. That way I can base
> > > my omap legacy platform data removal patches on my fixes branch while keep
> > > things working for the drivers. Alternatively I can naturally base my
> > > legacy data removal on -rc2 too if this gets merged to mainline by then 
> > > via the MFD tree.
> > 
> > I can either send it up for the -rcs, or I can create an immutable
> > branch for you to pull from. That way the patch can do in via ARM-SoC
> > and MFD and we can let Git sort it out.
> 
> OK great, I'd prefer an immutable branch that I can merge in too. Then
> you can bundle it with other MFD fixes for the -rc series and send it
> in when it suits you :)

https://git.linaro.org/gitweb?p=people/ljones/mfd.git;a=shortlog;h=refs/heads/for-mfd-fixes

Here Tony, you can take this one.

I will simply apply my other fixes on top of it.

The issue is, I will most likely have to rebase it on top of -rc1 prior
to sending a request to Linus, so in that regard it's not exactly
immutable.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Lee Jones]

> Here Tony, you can take this one.
> 
> I will simply apply my other fixes on top of it.
> 
> The issue is, I will most likely have to rebase it on top of -rc1 prior
> to sending a request to Linus, so in that regard it's not exactly
> immutable.
> 

Ignore the above. This is what you want:

The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52:

  Linux 3.12 (2013-11-03 15:41:51 -0800)

are available in the git repository at:

  git://git.linaro.org/people/ljones/mfd.git tags/ib-tony

for you to fetch changes up to f984370913d3ba5d13806cc8ac6fc26f8ebd1694:

  mfd: twl-core: Fix passing of platform data in the device tree case (2013-11-21 10:42:36 +0000)

----------------------------------------------------------------
warning: refname 'ib-tony' is ambiguous.
Immutable branch for Tony Lindgren

----------------------------------------------------------------
Tony Lindgren (1):
      mfd: twl-core: Fix passing of platform data in the device tree case

 drivers/mfd/twl-core.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Tony Lindgren]

* Lee Jones <lee.jones@linaro.org> [131121 03:10]:
> > Here Tony, you can take this one.
> > 
> > I will simply apply my other fixes on top of it.
> > 
> > The issue is, I will most likely have to rebase it on top of -rc1 prior
> > to sending a request to Linus, so in that regard it's not exactly
> > immutable.
> > 
> 
> Ignore the above. This is what you want:

Thanks, I'll use that commit in my omap-for-v3.14/board-removal branch.

Regards,

Tony
 
> The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52:
> 
>   Linux 3.12 (2013-11-03 15:41:51 -0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/ljones/mfd.git tags/ib-tony
> 
> for you to fetch changes up to f984370913d3ba5d13806cc8ac6fc26f8ebd1694:
> 
>   mfd: twl-core: Fix passing of platform data in the device tree case (2013-11-21 10:42:36 +0000)
> 
> ----------------------------------------------------------------
> warning: refname 'ib-tony' is ambiguous.
> Immutable branch for Tony Lindgren
> 
> ----------------------------------------------------------------
> Tony Lindgren (1):
>       mfd: twl-core: Fix passing of platform data in the device tree case
> 
>  drivers/mfd/twl-core.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case

[Felipe Balbi]

Hi,

On Mon, Nov 18, 2013 at 05:46:38PM +0000, Lee Jones wrote:
> > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > > +	OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > > +	{ /* sentinel */ },
> > > > +};
> > > > +
> > > >  /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
> > > >  static int
> > > >  twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > > > @@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > > >  		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
> > > >  	}
> > > >  
> > > > -	if (node)
> > > > -		status = of_platform_populate(node, NULL, NULL, &client->dev);
> > > > -	else
> > > > +	if (node) {
> > > > +		if (pdata)
> > > > +			twl_auxdata_lookup[0].platform_data = pdata->gpio;
> > > > +		status = of_platform_populate(node, NULL, twl_auxdata_lookup,
> > > > +					      &client->dev);
> > > > +	} else {
> > > >  		status = add_children(pdata, irq_base, id->driver_data);
> > > 
> > > Why doesn't the TWL driver use the MFD framework for this stuff?
> > 
> > that's reminiscent from years ago and, surely, needs to be fixed. Should
> > we gate $subject for that, though ? This has been in tree for quite a
> > few years already and Tony's patch is still a step forward, since most
> > omap3 platforms would break on DT-only without it.
> 
> I didn't say that I would reject the patch. I was just surprised to
> see so much hand-rolling, as the MFD core code does much of it
> automatically. This is the first time I've taken a look at this and it
> seems to be quite the relic.

alright, thanks for confirming.

> > There are quite a few folks who could volunteer to fixing that after
> > Tony's patch is in (me included, although there could be better choices
> > hehe).
> 
> Well it's not doing any harm. I'll make a note to fix it myself if a)
> no one has done so already and b) I manage to find some spare
> time. The latter issue is less likely to be resolved. :)
> 
> Are you Acking this patch by the way?

sure:

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/db765769/attachment-0001.sig>

[PATCH 2/5] ARM: OMAP2+: Add support for legacy auxdata for twl

[Tony Lindgren]

As we currently need to support a mix of legacy platform data and
device tree intialized data, let's make sure things keep working
for the TWL GPIOs.

Mostly the issue is caused by the fact that DSS does not yet have
device tree bindings, so we need to rely on the TWL GPIO callback
for setting up things like LCD backlight for some boards.

As of_platform_populate() for the TWL GPIO is called by twl-core
after the I2C bus has been initialized, we cannot pass the auxdata
table from the board init code to twl-core like we used to with
just legacy platform data.

So let's use the omap_device bus hook to patch in the platform
data for TWL GPIO until we have sorted out the issues with the
TWL GPIOs and device tree bindings.

The other option was be to initialize twl core using legacy
platform data, which seems like a step backwards as we're moving
to device tree only initialization.  And we really don't want to
add custom configuration functions to the TWL GPIO driver either
for this.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/common.h       |  1 +
 arch/arm/mach-omap2/omap_device.c  |  2 ++
 arch/arm/mach-omap2/pdata-quirks.c | 16 ++++++++++++++++
 3 files changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644fe..d0f3308 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,6 +293,7 @@ static inline void omap4_cpu_resume(void)
 #endif
 
 void pdata_quirks_init(struct of_device_id *);
+void omap_auxdata_legacy_init(struct device *dev);
 void omap_pcs_legacy_init(int irq, void (*rearm)(void));
 
 struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 53f0735..828f538 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -36,6 +36,7 @@
 #include <linux/of.h>
 #include <linux/notifier.h>
 
+#include "common.h"
 #include "soc.h"
 #include "omap_device.h"
 #include "omap_hwmod.h"
@@ -200,6 +201,7 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
+		omap_auxdata_legacy_init(dev);
 		/* fall through */
 	default:
 		od = to_omap_device(pdev);
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index e7e9984..f2fc072 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -27,6 +27,7 @@ struct pdata_init {
 };
 
 struct of_dev_auxdata omap_auxdata_lookup[];
+static struct twl4030_gpio_platform_data twl_gpio_auxdata;
 
 /*
  * Create alias for USB host PHY clock.
@@ -137,6 +138,21 @@ void omap_pcs_legacy_init(int irq, void (*rearm)(void))
 }
 
 /*
+ * GPIOs for TWL are initialized by the I2C bus and need custom
+ * handing until DSS has device tree bindings.
+ */
+void omap_auxdata_legacy_init(struct device *dev)
+{
+	if (dev->platform_data)
+		return;
+
+	if (strcmp("twl4030-gpio", dev_name(dev)))
+		return;
+
+	dev->platform_data = &twl_gpio_auxdata;
+}
+
+/*
  * Few boards still need auxdata populated before we populate
  * the dev entries in of_platform_populate().
  */
-- 
1.8.1.1

[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it

[Tony Lindgren]

In order to make the remaining omap3 boards usable with device
tree, we need to initialize the DPI based displays using pdata
until we have the DSS bindings in place.

At least board-am3517evm.c, board-cm-t35.c, board-devkit8000.c,
board-ldp.c and board-overo.c all use fairly similar DPI setup,
so let's add generic code for it. And let's make omap3 LDP to
use it and also initialize the ads7846 until we have a binding
for it.

Note that at least LDP needs the TWL bug fix posted as
"gpio: twl4030: Fix regression for twl gpio output" for the
LCD backlight to power.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/dss-common.c   | 67 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/dss-common.h   |  1 +
 arch/arm/mach-omap2/pdata-quirks.c | 15 +++++++++
 3 files changed, 83 insertions(+)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 365bfd3..86e98c5 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -257,3 +257,70 @@ void __init omap3_igep2_display_init_of(void)
 	platform_device_register(&omap3_igep2_tfp410_device);
 	platform_device_register(&omap3_igep2_dvi_connector_device);
 }
+
+/* Systems with DPI LCD */
+
+static struct panel_dpi_platform_data dpi_lcd = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+	.enable_gpio		= -1,
+	.backlight_gpio		= -1,
+};
+
+static struct platform_device dpi_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &dpi_lcd,
+};
+
+static struct omap_dss_board_info dpi_dss_data = {
+	.default_display_name = "lcd",
+};
+
+static void dpi_display_init(void)
+{
+	platform_device_register(&dpi_lcd_device);
+	omap_display_init(&dpi_dss_data);
+}
+
+/* DPI on omap3 LDP */
+
+static const struct display_timing ldp_lcd_videomode = {
+	.pixelclock	= { 0, 5400000, 0 },
+
+	.hactive = { 0, 240, 0 },
+	.hfront_porch = { 0, 3, 0 },
+	.hback_porch = { 0, 39, 0 },
+	.hsync_len = { 0, 3, 0 },
+
+	.vactive = { 0, 320, 0 },
+	.vfront_porch = { 0, 2, 0 },
+	.vback_porch = { 0, 7, 0 },
+	.vsync_len = { 0, 1, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+void __init omap3_ldp_display_init_of(int gpio_bl, int gpio_en)
+{
+	int r;
+
+	static struct gpio gpios[] = {
+		{ 55, GPIOF_OUT_INIT_HIGH, "LCD RESET" },
+		{ 56, GPIOF_OUT_INIT_HIGH, "LCD QVGA" },
+	};
+
+	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+	if (r) {
+		pr_err("Cannot request LCD GPIOs, error %d\n", r);
+		return;
+	}
+
+	dpi_lcd.data_lines = 18;
+	dpi_lcd.display_timing = &ldp_lcd_videomode;
+	dpi_lcd.enable_gpio = gpio_en;
+	dpi_lcd.backlight_gpio = gpio_bl;
+
+	dpi_display_init();
+}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index a9becf0..bc9921c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -9,5 +9,6 @@
 void __init omap4_panda_display_init_of(void);
 void __init omap_4430sdp_display_init_of(void);
 void __init omap3_igep2_display_init_of(void);
+void omap3_ldp_display_init_of(int gpio_bl, int gpio_en);
 
 #endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index f2fc072..97f200f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -100,6 +100,20 @@ static void __init omap3_evm_legacy_init(void)
 	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
 }
 
+/* Pass enable and backlight GPIO to DSS code */
+int __init ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
+{
+	omap3_ldp_display_init_of(gpio + 7, gpio + 15);
+	omap_ads7846_init(1, 54, 310, NULL);
+
+	return 0;
+}
+
+static void __init omap3_ldp_legacy_init(void)
+{
+	twl_gpio_auxdata.setup = ldp_twl_gpio_setup;
+}
+
 static void __init omap3_zoom_legacy_init(void)
 {
 	legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
@@ -190,6 +204,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
 	{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
 	{ "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
 	{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
+	{ "ti,omap3-ldp", omap3_ldp_legacy_init, },
 	{ "ti,omap3-zoom3", omap3_zoom_legacy_init, },
 #endif
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.8.1.1

[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it

[Tomi Valkeinen]

On 2013-11-16 02:36, Tony Lindgren wrote:
> In order to make the remaining omap3 boards usable with device
> tree, we need to initialize the DPI based displays using pdata
> until we have the DSS bindings in place.
> 
> At least board-am3517evm.c, board-cm-t35.c, board-devkit8000.c,
> board-ldp.c and board-overo.c all use fairly similar DPI setup,
> so let's add generic code for it. And let's make omap3 LDP to
> use it and also initialize the ads7846 until we have a binding
> for it.
> 
> Note that at least LDP needs the TWL bug fix posted as
> "gpio: twl4030: Fix regression for twl gpio output" for the
> LCD backlight to power.

Looks fine to me.

Is it possible to keep this, and other similar DSS patches, in a
separate branch, that could be dropped if needed? I'm kind of hoping I
would get the DSS DT finished for the next merge window (but I've said
that before, so...).

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/c02ffb77/attachment.sig>

[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131118 05:07]:
> On 2013-11-16 02:36, Tony Lindgren wrote:
> > In order to make the remaining omap3 boards usable with device
> > tree, we need to initialize the DPI based displays using pdata
> > until we have the DSS bindings in place.
> > 
> > At least board-am3517evm.c, board-cm-t35.c, board-devkit8000.c,
> > board-ldp.c and board-overo.c all use fairly similar DPI setup,
> > so let's add generic code for it. And let's make omap3 LDP to
> > use it and also initialize the ads7846 until we have a binding
> > for it.
> > 
> > Note that at least LDP needs the TWL bug fix posted as
> > "gpio: twl4030: Fix regression for twl gpio output" for the
> > LCD backlight to power.
> 
> Looks fine to me.
> 
> Is it possible to keep this, and other similar DSS patches, in a
> separate branch, that could be dropped if needed? I'm kind of hoping I
> would get the DSS DT finished for the next merge window (but I've said
> that before, so...).

OK let's keep the DSS pdata quirks separate for now. How about we set
-rc3 as a deadline for deciding which way to go for the DSS DT bindings
for v3.14?

BTW, Russell posted some interesting comments on LAKML this weekend
on binding together driver components if that helps.

Regards,

Tony

[PATCH 4/5] ARM: dts: Add basic support for omap3 LDP zoom1 labrador

[Tony Lindgren]

Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
and GPIO keys work.

For twl4030-keypad we're still missing the binding, but
support for that should be trivial to add once the driver
has been updated.

MUSB I'm pretty sure I got got to enumerate once, but I
suspect the battery charging somehow disrupts it and it's
not enumerating in general for some reason.

Patches are welcome to improve things if people are
still using this board.

For reference, here's some more info on this old board:
http://www.openomap.org/wiki/tiki-index.php?page=HardwareInfo

Cc: devicetree at vger.kernel.org
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/Makefile      |   1 +
 arch/arm/boot/dts/omap3-ldp.dts | 231 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 232 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-ldp.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index de37094..fc37bca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -183,6 +183,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-beagle-xm.dtb \
 	omap3-evm.dtb \
 	omap3-evm-37xx.dtb \
+	omap3-ldp.dtb \
 	omap3-n900.dtb \
 	omap3-n9.dtb \
 	omap3-n950.dtb \
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
new file mode 100644
index 0000000..ddce0d8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "omap34xx.dtsi"
+#include "omap-gpmc-smsc911x.dtsi"
+
+/ {
+	model = "TI OMAP3430 LDP (Zoom1 Labrador)";
+	compatible = "ti,omap3-ldp", "ti,omap3";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x8000000>; /* 128 MB */
+	};
+
+	cpus {
+		cpu at 0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpio_key_pins>;
+
+		key_enter {
+			label = "enter";
+			gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* gpio101 */
+			linux,code = <0x0107001c>; /* KEY_ENTER */
+			gpio-key,wakeup;
+		};
+
+		key_f1 {
+			label = "f1";
+			gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* gpio102 */
+			linux,code = <0x0303003b>; /* KEY_F1 */
+			gpio-key,wakeup;
+		};
+
+		key_f2 {
+			label = "f2";
+			gpios = <&gpio4 7 GPIO_ACTIVE_LOW>; /* gpio103 */
+			linux,code = <0x0403003c>; /* KEY_F2 */
+			gpio-key,wakeup;
+		};
+
+		key_f3 {
+			label = "f3";
+			gpios = <&gpio4 8 GPIO_ACTIVE_LOW>; /* gpio104 */
+			linux,code = <0x0503003d>; /* KEY_F3 */
+			gpio-key,wakeup;
+		};
+
+		key_f4 {
+			label = "f4";
+			gpios = <&gpio4 9 GPIO_ACTIVE_LOW>; /* gpio105 */
+			linux,code = <0x0704003e>; /* KEY_F4 */
+			gpio-key,wakeup;
+		};
+
+		key_left {
+			label = "left";
+			gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* gpio106 */
+			linux,code = <0x04070069>; /* KEY_LEFT */
+			gpio-key,wakeup;
+		};
+
+		key_right {
+			label = "right";
+			gpios = <&gpio4 11 GPIO_ACTIVE_LOW>; /* gpio107 */
+			linux,code = <0x0507006a>; /* KEY_RIGHT */
+			gpio-key,wakeup;
+		};
+
+		key_up {
+			label = "up";
+			gpios = <&gpio4 12 GPIO_ACTIVE_LOW>; /* gpio108 */
+			linux,code = <0x06070067>; /* KEY_UP */
+			gpio-key,wakeup;
+		};
+
+		key_down {
+			label = "down";
+			gpios = <&gpio4 13 GPIO_ACTIVE_LOW>; /* gpio109 */
+			linux,code = <0x0707006c>; /* KEY_DOWN */
+			gpio-key,wakeup;
+		};
+	};
+};
+
+&gpmc {
+	ranges = <0 0 0x00000000 0x01000000>,
+		 <1 0 0x08000000 0x01000000>;
+
+	nand at 0,0 {
+		linux,mtd-name= "micron,nand";
+		reg = <0 0 0>;
+		nand-bus-width = <16>;
+		ti,nand-ecc-opt = "bch8";
+
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <44>;
+		gpmc,cs-wr-off-ns = <44>;
+		gpmc,adv-on-ns = <6>;
+		gpmc,adv-rd-off-ns = <34>;
+		gpmc,adv-wr-off-ns = <44>;
+		gpmc,we-off-ns = <40>;
+		gpmc,oe-off-ns = <54>;
+		gpmc,access-ns = <64>;
+		gpmc,rd-cycle-ns = <82>;
+		gpmc,wr-cycle-ns = <82>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		partition at 0 {
+			label = "X-Loader";
+			reg = <0 0x80000>;
+		};
+		partition at 80000 {
+			label = "U-Boot";
+			reg = <0x80000 0x140000>;
+		};
+		partition at 1c0000 {
+			label = "Environment";
+			reg = <0x1c0000 0x40000>;
+		};
+		partition at 200000 {
+			label = "Kernel";
+			reg = <0x200000 0x1e00000>;
+		};
+		partition at 2000000 {
+			label = "Filesystem";
+			reg = <0x2000000 0xe000000>;
+		};
+	};
+
+	ethernet at gpmc {
+		interrupt-parent = <&gpio5>;
+		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
+		reg = <1 0 0xff>;
+	};
+};
+
+&i2c1 {
+	clock-frequency = <2600000>;
+
+	twl: twl at 48 {
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-parent = <&intc>;
+	};
+};
+
+#include "twl4030.dtsi"
+#include "twl4030_omap3.dtsi"
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+};
+
+&mmc1 {
+	vmmc-supply = <&vmmc1>;
+	bus-width = <4>;
+};
+
+&omap3_pmx_core {
+	gpio_key_pins: pinmux_gpio_key_pins {
+		pinctrl-single,pins = <
+			0xea (PIN_INPUT | MUX_MODE4)	/* cam_d2.gpio_101 */
+			0xec (PIN_INPUT | MUX_MODE4)	/* cam_d3.gpio_102 */
+			0xee (PIN_INPUT | MUX_MODE4)	/* cam_d4.gpio_103 */
+			0xf0 (PIN_INPUT | MUX_MODE4)	/* cam_d5.gpio_104 */
+			0xf2 (PIN_INPUT | MUX_MODE4)	/* cam_d6.gpio_105 */
+			0xf4 (PIN_INPUT | MUX_MODE4)	/* cam_d7.gpio_106 */
+			0xf6 (PIN_INPUT | MUX_MODE4)	/* cam_d8.gpio_107 */
+			0xf8 (PIN_INPUT | MUX_MODE4)	/* cam_d9.gpio_108 */
+			0xfa (PIN_INPUT | MUX_MODE4)	/* cam_d10.gpio_109 */
+		>;
+	};
+
+	musb_pins: pinmux_musb_pins {
+		pinctrl-single,pins = <
+			0x172 (PIN_INPUT | MUX_MODE0)	/* hsusb0_clk.hsusb0_clk */
+			0x17a (PIN_INPUT | MUX_MODE0)	/* hsusb0_data0.hsusb0_data0 */
+			0x17c (PIN_INPUT | MUX_MODE0)	/* hsusb0_data1.hsusb0_data1 */
+			0x17e (PIN_INPUT | MUX_MODE0)	/* hsusb0_data2.hsusb0_data2 */
+			0x180 (PIN_INPUT | MUX_MODE0)	/* hsusb0_data3.hsusb0_data3 */
+			0x182 (PIN_INPUT | MUX_MODE0)	/* hsusb0_data4.hsusb0_data4 */
+			0x184 (PIN_INPUT | MUX_MODE0)	/* hsusb0_data5.hsusb0_data5 */
+			0x186 (PIN_INPUT | MUX_MODE0)	/* hsusb0_data6.hsusb0_data6 */
+			0x188 (PIN_INPUT | MUX_MODE0)	/* hsusb0_data7.hsusb0_data7 */
+			0x176 (PIN_INPUT | MUX_MODE0)	/* hsusb0_dir.hsusb0_dir */
+			0x178 (PIN_INPUT | MUX_MODE0)	/* hsusb0_nxt.hsusb0_nxt */
+			0x174 (PIN_OUTPUT | MUX_MODE0)	/* hsusb0_stp.hsusb0_stp */
+		>;
+	};
+};
+
+&usb_otg_hs {
+	pinctrl-names = "default";
+	pinctrl-0 = <&musb_pins>;
+	interface-type = <0>;
+	usb-phy = <&usb2_phy>;
+	mode = <3>;
+	power = <50>;
+};
+
+&vaux1 {
+	/* Needed for ads7846 */
+        regulator-name = "vcc";
+};
+
+&vpll2 {
+       /* Needed for DSS */
+       regulator-name = "vdds_dsi";
+};
-- 
1.8.1.1

[PATCH 4/5] ARM: dts: Add basic support for omap3 LDP zoom1 labrador

[Sebastian Reichel]

On Fri, Nov 15, 2013 at 04:36:06PM -0800, Tony Lindgren wrote:
> Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
> and GPIO keys work.
> 
> For twl4030-keypad we're still missing the binding, but
> support for that should be trivial to add once the driver
> has been updated.

DT bindings for twl4030-keypad are being worked on:

https://lkml.org/lkml/2013/11/8/463

> MUSB I'm pretty sure I got got to enumerate once, but I
> suspect the battery charging somehow disrupts it and it's
> not enumerating in general for some reason.

Try to add this:

&usb_otg_hs {
	phys = <&usb2_phy>;
	phy-names = "usb2-phy";
};

Those were introduced by the new generic PHY framework, see
for example: https://lkml.org/lkml/2013/9/27/37

> [...]

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131116/c6bc0b72/attachment.sig>

[PATCH 4/5] ARM: dts: Add basic support for omap3 LDP zoom1 labrador

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [131116 00:05]:
> On Fri, Nov 15, 2013 at 04:36:06PM -0800, Tony Lindgren wrote:
> > Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
> > and GPIO keys work.
> > 
> > For twl4030-keypad we're still missing the binding, but
> > support for that should be trivial to add once the driver
> > has been updated.
> 
> DT bindings for twl4030-keypad are being worked on:
> 
> https://lkml.org/lkml/2013/11/8/463
> 
> > MUSB I'm pretty sure I got got to enumerate once, but I
> > suspect the battery charging somehow disrupts it and it's
> > not enumerating in general for some reason.
> 
> Try to add this:
> 
> &usb_otg_hs {
> 	phys = <&usb2_phy>;
> 	phy-names = "usb2-phy";
> };
> 
> Those were introduced by the new generic PHY framework, see
> for example: https://lkml.org/lkml/2013/9/27/37

Thanks yeah those should be added. No luck with those either
though, I do have MUSB working fine on the 37xx-evm with the
same image.

I seem to get twl4030_usb interrupts on cable insert and remove,
then enabling debugging I see the following:

connect
HW_CONDITIONS 0xe0/224; link 3

disconnect
HW_CONDITIONS 0x60/96; link 4

Regards,

Tony

[PATCH 5/5] ARM: OMAP2+: Remove legacy booting support for LDP

[Tony Lindgren]

We can now boot with appended device tree with pretty much
the same functionality. So let's remove the legacy board
file as we want to make mach-omap2 device tree only.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/Kconfig     |   6 -
 arch/arm/mach-omap2/Makefile    |   1 -
 arch/arm/mach-omap2/board-ldp.c | 425 ----------------------------------------
 3 files changed, 432 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-ldp.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4191ae0..0f7952d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -204,12 +204,6 @@ config MACH_DEVKIT8000
 	default y
 	select OMAP_PACKAGE_CUS
 
-config MACH_OMAP_LDP
-	bool "OMAP3 LDP board"
-	depends on ARCH_OMAP3
-	default y
-	select OMAP_PACKAGE_CBB
-
 config MACH_OMAP3530_LV_SOM
 	bool "OMAP3 Logic 3530 LV SOM board"
 	depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 83b147e..6a280f8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -237,7 +237,6 @@ obj-$(CONFIG_SOC_OMAP2420)		+= msdi.o
 obj-$(CONFIG_MACH_OMAP_GENERIC)		+= board-generic.o pdata-quirks.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)		+= board-omap3beagle.o
 obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o
-obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o
 obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o
 obj-$(CONFIG_MACH_OMAP3_TORPEDO)        += board-omap3logic.o
 obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
deleted file mode 100644
index 4ec8d82..0000000
--- a/arch/arm/mach-omap2/board-ldp.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-ldp.c
- *
- * Copyright (C) 2008 Texas Instruments Inc.
- * Nishant Kamat <nskamat@ti.com>
- *
- * Modified from mach-omap2/board-3430sdp.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/gpio.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/delay.h>
-#include <linux/input.h>
-#include <linux/input/matrix_keypad.h>
-#include <linux/gpio_keys.h>
-#include <linux/workqueue.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/spi/spi.h>
-#include <linux/regulator/fixed.h>
-#include <linux/regulator/machine.h>
-#include <linux/i2c/twl.h>
-#include <linux/io.h>
-#include <linux/smsc911x.h>
-#include <linux/mmc/host.h>
-#include <linux/usb/phy.h>
-#include <linux/platform_data/spi-omap2-mcspi.h>
-
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include "common.h"
-#include "gpmc.h"
-#include "gpmc-smsc911x.h"
-
-#include <video/omapdss.h>
-#include <video/omap-panel-data.h>
-
-#include "board-flash.h"
-#include "mux.h"
-#include "hsmmc.h"
-#include "control.h"
-#include "common-board-devices.h"
-
-#define LDP_SMSC911X_CS		1
-#define LDP_SMSC911X_GPIO	152
-#define DEBUG_BASE		0x08000000
-#define LDP_ETHR_START		DEBUG_BASE
-
-static uint32_t board_keymap[] = {
-	KEY(0, 0, KEY_1),
-	KEY(1, 0, KEY_2),
-	KEY(2, 0, KEY_3),
-	KEY(0, 1, KEY_4),
-	KEY(1, 1, KEY_5),
-	KEY(2, 1, KEY_6),
-	KEY(3, 1, KEY_F5),
-	KEY(0, 2, KEY_7),
-	KEY(1, 2, KEY_8),
-	KEY(2, 2, KEY_9),
-	KEY(3, 2, KEY_F6),
-	KEY(0, 3, KEY_F7),
-	KEY(1, 3, KEY_0),
-	KEY(2, 3, KEY_F8),
-	PERSISTENT_KEY(4, 5),
-	KEY(4, 4, KEY_VOLUMEUP),
-	KEY(5, 5, KEY_VOLUMEDOWN),
-	0
-};
-
-static struct matrix_keymap_data board_map_data = {
-	.keymap			= board_keymap,
-	.keymap_size		= ARRAY_SIZE(board_keymap),
-};
-
-static struct twl4030_keypad_data ldp_kp_twl4030_data = {
-	.keymap_data	= &board_map_data,
-	.rows		= 6,
-	.cols		= 6,
-	.rep		= 1,
-};
-
-static struct gpio_keys_button ldp_gpio_keys_buttons[] = {
-	[0] = {
-		.code			= KEY_ENTER,
-		.gpio			= 101,
-		.desc			= "enter sw",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[1] = {
-		.code			= KEY_F1,
-		.gpio			= 102,
-		.desc			= "func 1",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[2] = {
-		.code			= KEY_F2,
-		.gpio			= 103,
-		.desc			= "func 2",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[3] = {
-		.code			= KEY_F3,
-		.gpio			= 104,
-		.desc			= "func 3",
-		.active_low		= 1,
-		.debounce_interval 	= 30,
-	},
-	[4] = {
-		.code			= KEY_F4,
-		.gpio			= 105,
-		.desc			= "func 4",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[5] = {
-		.code			= KEY_LEFT,
-		.gpio			= 106,
-		.desc			= "left sw",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[6] = {
-		.code			= KEY_RIGHT,
-		.gpio			= 107,
-		.desc			= "right sw",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[7] = {
-		.code			= KEY_UP,
-		.gpio			= 108,
-		.desc			= "up sw",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-	[8] = {
-		.code			= KEY_DOWN,
-		.gpio			= 109,
-		.desc			= "down sw",
-		.active_low		= 1,
-		.debounce_interval	= 30,
-	},
-};
-
-static struct gpio_keys_platform_data ldp_gpio_keys = {
-	.buttons		= ldp_gpio_keys_buttons,
-	.nbuttons		= ARRAY_SIZE(ldp_gpio_keys_buttons),
-	.rep			= 1,
-};
-
-static struct platform_device ldp_gpio_keys_device = {
-	.name		= "gpio-keys",
-	.id		= -1,
-	.dev		= {
-		.platform_data	= &ldp_gpio_keys,
-	},
-};
-
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
-	.cs             = LDP_SMSC911X_CS,
-	.gpio_irq       = LDP_SMSC911X_GPIO,
-	.gpio_reset     = -EINVAL,
-	.flags		= SMSC911X_USE_32BIT,
-};
-
-static inline void __init ldp_init_smsc911x(void)
-{
-	gpmc_smsc911x_init(&smsc911x_cfg);
-}
-
-/* LCD */
-
-#define LCD_PANEL_RESET_GPIO		55
-#define LCD_PANEL_QVGA_GPIO		56
-
-static const struct display_timing ldp_lcd_videomode = {
-	.pixelclock	= { 0, 5400000, 0 },
-
-	.hactive = { 0, 240, 0 },
-	.hfront_porch = { 0, 3, 0 },
-	.hback_porch = { 0, 39, 0 },
-	.hsync_len = { 0, 3, 0 },
-
-	.vactive = { 0, 320, 0 },
-	.vfront_porch = { 0, 2, 0 },
-	.vback_porch = { 0, 7, 0 },
-	.vsync_len = { 0, 1, 0 },
-
-	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
-		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
-};
-
-static struct panel_dpi_platform_data ldp_lcd_pdata = {
-	.name                   = "lcd",
-	.source                 = "dpi.0",
-
-	.data_lines		= 18,
-
-	.display_timing		= &ldp_lcd_videomode,
-
-	.enable_gpio		= -1,	/* filled in code */
-	.backlight_gpio		= -1,	/* filled in code */
-};
-
-static struct platform_device ldp_lcd_device = {
-	.name                   = "panel-dpi",
-	.id                     = 0,
-	.dev.platform_data      = &ldp_lcd_pdata,
-};
-
-static struct omap_dss_board_info ldp_dss_data = {
-	.default_display_name = "lcd",
-};
-
-static void __init ldp_display_init(void)
-{
-	int r;
-
-	static struct gpio gpios[] __initdata = {
-		{LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
-		{LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
-	};
-
-	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
-	if (r) {
-		pr_err("Cannot request LCD GPIOs, error %d\n", r);
-		return;
-	}
-
-	omap_display_init(&ldp_dss_data);
-}
-
-static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
-{
-	/* LCD enable GPIO */
-	ldp_lcd_pdata.enable_gpio = gpio + 7;
-
-	/* Backlight enable GPIO */
-	ldp_lcd_pdata.backlight_gpio = gpio + 15;
-
-	return 0;
-}
-
-static struct twl4030_gpio_platform_data ldp_gpio_data = {
-	.setup		= ldp_twl_gpio_setup,
-};
-
-static struct regulator_consumer_supply ldp_vmmc1_supply[] = {
-	REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
-};
-
-/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
-static struct regulator_init_data ldp_vmmc1 = {
-	.constraints = {
-		.min_uV			= 1850000,
-		.max_uV			= 3150000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(ldp_vmmc1_supply),
-	.consumer_supplies	= ldp_vmmc1_supply,
-};
-
-/* ads7846 on SPI */
-static struct regulator_consumer_supply ldp_vaux1_supplies[] = {
-	REGULATOR_SUPPLY("vcc", "spi1.0"),
-};
-
-/* VAUX1 */
-static struct regulator_init_data ldp_vaux1 = {
-	.constraints = {
-		.min_uV			= 3000000,
-		.max_uV			= 3000000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies		= ARRAY_SIZE(ldp_vaux1_supplies),
-	.consumer_supplies		= ldp_vaux1_supplies,
-};
-
-static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss_dpi.0"),
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"),
-};
-
-static struct regulator_init_data ldp_vpll2 = {
-	.constraints = {
-		.name			= "VDVI",
-		.min_uV			= 1800000,
-		.max_uV			= 1800000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(ldp_vpll2_supplies),
-	.consumer_supplies	= ldp_vpll2_supplies,
-};
-
-static struct twl4030_platform_data ldp_twldata = {
-	/* platform_data for children goes here */
-	.vmmc1		= &ldp_vmmc1,
-	.vaux1		= &ldp_vaux1,
-	.vpll2		= &ldp_vpll2,
-	.gpio		= &ldp_gpio_data,
-	.keypad		= &ldp_kp_twl4030_data,
-};
-
-static int __init omap_i2c_init(void)
-{
-	omap3_pmic_get_config(&ldp_twldata,
-			  TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_MADC, 0);
-	omap3_pmic_init("twl4030", &ldp_twldata);
-	omap_register_i2c_bus(2, 400, NULL, 0);
-	omap_register_i2c_bus(3, 400, NULL, 0);
-	return 0;
-}
-
-static struct omap2_hsmmc_info mmc[] __initdata = {
-	{
-		.mmc		= 1,
-		.caps		= MMC_CAP_4_BIT_DATA,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-	},
-	{}	/* Terminator */
-};
-
-static struct platform_device *ldp_devices[] __initdata = {
-	&ldp_gpio_keys_device,
-	&ldp_lcd_device,
-};
-
-#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
-	{ .reg_offset = OMAP_MUX_TERMINATOR },
-};
-#endif
-
-static struct mtd_partition ldp_nand_partitions[] = {
-	/* All the partition sizes are listed in terms of NAND block size */
-	{
-		.name		= "X-Loader-NAND",
-		.offset		= 0,
-		.size		= 4 * (64 * 2048),	/* 512KB, 0x80000 */
-		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
-	},
-	{
-		.name		= "U-Boot-NAND",
-		.offset		= MTDPART_OFS_APPEND,	/* Offset = 0x80000 */
-		.size		= 10 * (64 * 2048),	/* 1.25MB, 0x140000 */
-		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
-	},
-	{
-		.name		= "Boot Env-NAND",
-		.offset		= MTDPART_OFS_APPEND,   /* Offset = 0x1c0000 */
-		.size		= 2 * (64 * 2048),	/* 256KB, 0x40000 */
-	},
-	{
-		.name		= "Kernel-NAND",
-		.offset		= MTDPART_OFS_APPEND,	/* Offset = 0x0200000*/
-		.size		= 240 * (64 * 2048),	/* 30M, 0x1E00000 */
-	},
-	{
-		.name		= "File System - NAND",
-		.offset		= MTDPART_OFS_APPEND,	/* Offset = 0x2000000 */
-		.size		= MTDPART_SIZ_FULL,	/* 96MB, 0x6000000 */
-	},
-
-};
-
-static struct regulator_consumer_supply dummy_supplies[] = {
-	REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
-	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
-};
-
-static void __init omap_ldp_init(void)
-{
-	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
-	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
-	ldp_init_smsc911x();
-	omap_i2c_init();
-	platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
-	omap_ads7846_init(1, 54, 310, NULL);
-	omap_serial_init();
-	omap_sdrc_init(NULL, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
-	usb_musb_init(NULL);
-	board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions),
-			0, 0, nand_default_timings);
-
-	omap_hsmmc_init(mmc);
-	ldp_display_init();
-}
-
-MACHINE_START(OMAP_LDP, "OMAP LDP board")
-	.atag_offset	= 0x100,
-	.reserve	= omap_reserve,
-	.map_io		= omap3_map_io,
-	.init_early	= omap3430_init_early,
-	.init_irq	= omap3_init_irq,
-	.handle_irq	= omap3_intc_handle_irq,
-	.init_machine	= omap_ldp_init,
-	.init_late	= omap3430_init_late,
-	.init_time	= omap3_sync32k_timer_init,
-	.restart	= omap3xxx_restart,
-MACHINE_END
-- 
1.8.1.1

N900 board code in 3.14

[Tony Lindgren]

* Sebastian Reichel <sre@debian.org> [131116 04:06]:
> Hi Tony,
> 
> On Fri, Nov 15, 2013 at 04:36:02PM -0800, Tony Lindgren wrote:
> > Here are few patches to deal with the mix of legacy platform data
> > and device tree that we still need to do at least until DSS has
> > device tree bindings. These patches should allow the remaining
> > omap3 boards to be made device tree only so we can remove the
> > board-*.c files.
> 
> Do you plan to remove the Nokia N900 board code in 3.14, too?

Probably not completely, we should still keep the pieces that are
needed to initialize things in legacy mode. Then those can be dealt
with using the auxdata hooks in pdata-quirks.c.

But we do want to boot everything in in DT mode for mach-omap2 for
v3.14 as that leaves out huge amounts of old duplicate code.
 
> I see two big issues with that:
>  a) Using DT boot the display is currently not working.

OK

>  b) I could not get the 32GB eMMC working. For me the chip is not found
>     and I don't know how to debug it.

OK the eMMC issue might be related to the control module PBIAS
register support missing. If so, that should be fixable with the
auxdata until we have a minimal control module device driver to
deal with the PBIAS and expose those features as regulators to
the omap-hsmmc driver.
 
> There are two reasons for broken display:
> 
> 1. omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT) fails.
>    This can be fixed by simply not calling it in DT mode. DT data
>    contains pinmux information for this from 3.13 onwards [0].

OK yeah makes sense. The pins should be set up using pinctrl-single
for DT.

> 2. The spi panel driver is not probed.
> 
> I have a local hack to probe the panel driver via DT. I changed the
> display node to look as follows:
> 
> &mcspi1 {
>     /* ... tsc2005 ... */
> 
>     mipid at 2 {
>         compatible = "sony,acx565akm";
>         spi-max-frequency = <6000000>;
>         reg = <2>;
>         vdds_sdi-supply = <&vaux1>;
>         label = "lcd";
>         reset-gpio = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
>         ti,sdi-datapairs = <2>;
>         ti,dss-source = "sdi.0";
>         pinctrl-names = "default";
>         pinctrl-0 = <&display_pins>;
>     };
> };
> 
> Then I changed the acx565akm panel driver to get data from DT
> and the DSS to get SDI regulator from the panel. This is
> obviously not the way to got, so I wonder how to proceed.
> omapdss DT seems not to be ready for the next kernel releases.
> 
> My suggestion would be:
>  1. Find a better workaround for omapdss to acquire the SDI
>     regulator. My current hack is obviously not acceptable.
>  2. Load the panel driver via DT as seen above and reference
>     the omapdss interface with something like the above
>     "ti,dss-source".

To me it seems that we should be able to add minimal panel entries to DT
if we stick to existing standard bindings. Then the timings etc can be
set up based on the compatible flag. So I would leave out the properties
for ti,sdi-datapairs and ti,dss-source for now, and just set those in
the driver based on the sony,acx565akm compatible flag. Or maybe it should
be sony,acx565akm-n900 if there's some board specific configuration info.
 
> This is obviously not a stable DT interface, but that's also the case if
> everything is done via platform quirks: An old DT file without any display
> stuff in it would not work with a newer kernel without the quirks.

Right, naturally we cannot support missing properties in the old DT files.
But the standard properties are stable, so those should be OK to use.
But let's see what Tomi says, he may have some good ideas :)

Regards,

Tony
 
> [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1e6f51646f2bed16826fd8e4fc1b5f4188d086e

N900 board code in 3.14

[Sebastian Reichel]

On Sat, Nov 16, 2013 at 06:12:26AM -0800, Tony Lindgren wrote:
> [...]
> >  b) I could not get the 32GB eMMC working. For me the chip is not found
> >     and I don't know how to debug it.
> 
> OK the eMMC issue might be related to the control module PBIAS
> register support missing. If so, that should be fixable with the
> auxdata until we have a minimal control module device driver to
> deal with the PBIAS and expose those features as regulators to
> the omap-hsmmc driver.

I wasn't aware, that PBIAS register support is missing for DT
boot. The existing board code uses a 2.8-3.0V regulator for mmc1,
so missing PBIAS is probably the problem.

> > [...]
> > 
> > My suggestion would be:
> >  1. Find a better workaround for omapdss to acquire the SDI
> >     regulator. My current hack is obviously not acceptable.
> >  2. Load the panel driver via DT as seen above and reference
> >     the omapdss interface with something like the above
> >     "ti,dss-source".
> 
> To me it seems that we should be able to add minimal panel entries to DT
> if we stick to existing standard bindings. Then the timings etc can be
> set up based on the compatible flag. So I would leave out the properties
> for ti,sdi-datapairs and ti,dss-source for now, and just set those in
> the driver based on the sony,acx565akm compatible flag. Or maybe it should
> be sony,acx565akm-n900 if there's some board specific configuration info.

So we add reset-gpio and label to the DT data (they are panel
specific and independent of omapdss) and just hardcode "dsi.0"
with 2 data lanes into the driver? That sounds fine for me.

If neither Tomi nor anybody else has better ideas I will cook a
patch for that. I'm not sure how to setup the vdds_sdi regulator for
omapdss, though. Is there an example for a legacy driver using a DT
regulator available?

> [...]

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131116/a814c255/attachment.sig>

N900 board code in 3.14

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [131116 07:51]:
> On Sat, Nov 16, 2013 at 06:12:26AM -0800, Tony Lindgren wrote:
> > [...]
> > >  b) I could not get the 32GB eMMC working. For me the chip is not found
> > >     and I don't know how to debug it.
> > 
> > OK the eMMC issue might be related to the control module PBIAS
> > register support missing. If so, that should be fixable with the
> > auxdata until we have a minimal control module device driver to
> > deal with the PBIAS and expose those features as regulators to
> > the omap-hsmmc driver.
> 
> I wasn't aware, that PBIAS register support is missing for DT
> boot. The existing board code uses a 2.8-3.0V regulator for mmc1,
> so missing PBIAS is probably the problem.

Right, sorry I was confused, looks like we don't need to worry about
that. And looks like Balaji just posted patches for the PBIAS support.

Also, I just posted a patch to fix the eMMC that you may want to
try out.
 
> > > [...]
> > > 
> > > My suggestion would be:
> > >  1. Find a better workaround for omapdss to acquire the SDI
> > >     regulator. My current hack is obviously not acceptable.
> > >  2. Load the panel driver via DT as seen above and reference
> > >     the omapdss interface with something like the above
> > >     "ti,dss-source".
> > 
> > To me it seems that we should be able to add minimal panel entries to DT
> > if we stick to existing standard bindings. Then the timings etc can be
> > set up based on the compatible flag. So I would leave out the properties
> > for ti,sdi-datapairs and ti,dss-source for now, and just set those in
> > the driver based on the sony,acx565akm compatible flag. Or maybe it should
> > be sony,acx565akm-n900 if there's some board specific configuration info.
> 
> So we add reset-gpio and label to the DT data (they are panel
> specific and independent of omapdss) and just hardcode "dsi.0"
> with 2 data lanes into the driver? That sounds fine for me.
> 
> If neither Tomi nor anybody else has better ideas I will cook a
> patch for that. I'm not sure how to setup the vdds_sdi regulator for
> omapdss, though. Is there an example for a legacy driver using a DT
> regulator available?

Not that I know of :) But I guess only the panel driver would need to
parse the compatible flag and the rest of the DSS could still be
initialize the legacy way if needed.

Regards,

Tony

N900 board code in 3.14

[Sebastian Reichel]

Hi Tony,

On Thu, Nov 21, 2013 at 10:58:45AM -0800, Tony Lindgren wrote:
> Also, I just posted a patch to fix the eMMC that you may want to
> try out.

Let's move eMMC diskussion to that patch :)

> > > > [...]
> > > > 
> > > > My suggestion would be:
> > > >  1. Find a better workaround for omapdss to acquire the SDI
> > > >     regulator. My current hack is obviously not acceptable.
> > > >  2. Load the panel driver via DT as seen above and reference
> > > >     the omapdss interface with something like the above
> > > >     "ti,dss-source".
> > > 
> > > To me it seems that we should be able to add minimal panel entries to DT
> > > if we stick to existing standard bindings. Then the timings etc can be
> > > set up based on the compatible flag. So I would leave out the properties
> > > for ti,sdi-datapairs and ti,dss-source for now, and just set those in
> > > the driver based on the sony,acx565akm compatible flag. Or maybe it should
> > > be sony,acx565akm-n900 if there's some board specific configuration info.
> > 
> > So we add reset-gpio and label to the DT data (they are panel
> > specific and independent of omapdss) and just hardcode "dsi.0"
> > with 2 data lanes into the driver? That sounds fine for me.
> > 
> > If neither Tomi nor anybody else has better ideas I will cook a
> > patch for that. I'm not sure how to setup the vdds_sdi regulator for
> > omapdss, though. Is there an example for a legacy driver using a DT
> > regulator available?
> 
> Not that I know of :)

Javier Martinez Canillas patch did what I was thinking of in [0].
My suggestion would be to add something like this pseudocode to
omapdss:

if(board_is_n900_dt()) {
    vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "V28");
}

The problem is, that we do not want to name the regulator
"vdds_dsi", since it's not used exclusivly for omapdss.

In the future it can get the regulator via phandle of course.

> But I guess only the panel driver would need to parse the
> compatible flag and the rest of the DSS could still be initialize
> the legacy way if needed.

Yes, except of the regulator. I will try to get this working
tomorrow.

[0] http://www.spinics.net/lists/arm-kernel/msg286896.html

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131122/7be710c1/attachment.sig>

N900 board code in 3.14

[Javier Martinez Canillas]

On Fri, Nov 22, 2013 at 12:51 AM, Sebastian Reichel <sre@ring0.de> wrote:
> Hi Tony,
>
> On Thu, Nov 21, 2013 at 10:58:45AM -0800, Tony Lindgren wrote:
>> Also, I just posted a patch to fix the eMMC that you may want to
>> try out.
>
> Let's move eMMC diskussion to that patch :)
>
>> > > > [...]
>> > > >
>> > > > My suggestion would be:
>> > > >  1. Find a better workaround for omapdss to acquire the SDI
>> > > >     regulator. My current hack is obviously not acceptable.
>> > > >  2. Load the panel driver via DT as seen above and reference
>> > > >     the omapdss interface with something like the above
>> > > >     "ti,dss-source".
>> > >
>> > > To me it seems that we should be able to add minimal panel entries to DT
>> > > if we stick to existing standard bindings. Then the timings etc can be
>> > > set up based on the compatible flag. So I would leave out the properties
>> > > for ti,sdi-datapairs and ti,dss-source for now, and just set those in
>> > > the driver based on the sony,acx565akm compatible flag. Or maybe it should
>> > > be sony,acx565akm-n900 if there's some board specific configuration info.
>> >
>> > So we add reset-gpio and label to the DT data (they are panel
>> > specific and independent of omapdss) and just hardcode "dsi.0"
>> > with 2 data lanes into the driver? That sounds fine for me.
>> >
>> > If neither Tomi nor anybody else has better ideas I will cook a
>> > patch for that. I'm not sure how to setup the vdds_sdi regulator for
>> > omapdss, though. Is there an example for a legacy driver using a DT
>> > regulator available?
>>
>> Not that I know of :)
>
> Javier Martinez Canillas patch did what I was thinking of in [0].

I dropped that patch from my series and posted a v2 that just name the
VPLL2 regulator as vdds_dsi [1]. That way will be safer for Tony and
Benoit to take this series as a fix for the -rc cycle since the
changes are contained within IGEP boards DTS.

> My suggestion would be to add something like this pseudocode to
> omapdss:
>
> if(board_is_n900_dt()) {
>     vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "V28");
> }
>
> The problem is, that we do not want to name the regulator
> "vdds_dsi", since it's not used exclusivly for omapdss.
>
> In the future it can get the regulator via phandle of course.
>

For what is worth I think that your suggestion is a good workaround.
Please just add a comment specifying that it is a hack and that we
have to get rid of these once the DSS DT bindings land on mainline and
we can use a phandle to get the regulator.

>> But I guess only the panel driver would need to parse the
>> compatible flag and the rest of the DSS could still be initialize
>> the legacy way if needed.
>
> Yes, except of the regulator. I will try to get this working
> tomorrow.
>
> [0] http://www.spinics.net/lists/arm-kernel/msg286896.html
>
> -- Sebastian

[1]: http://www.spinics.net/lists/arm-kernel/msg287703.html

Best regards,
Javier

N900 board code in 3.14

[Sebastian Reichel]

Hi,

On Fri, Nov 22, 2013 at 11:41:27AM +0100, Javier Martinez Canillas wrote:
> I dropped that patch from my series and posted a v2 that just name the
> VPLL2 regulator as vdds_dsi [1]. That way will be safer for Tony and
> Benoit to take this series as a fix for the -rc cycle since the
> changes are contained within IGEP boards DTS.

I know, but the patch serves as example for me :)

> > My suggestion would be to add something like this pseudocode to
> > omapdss:
> >
> > if(board_is_n900_dt()) {
> >     vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "V28");
> > }
> >
> > The problem is, that we do not want to name the regulator
> > "vdds_dsi", since it's not used exclusivly for omapdss.
> >
> > In the future it can get the regulator via phandle of course.
> 
> For what is worth I think that your suggestion is a good workaround.
> Please just add a comment specifying that it is a hack and that we
> have to get rid of these once the DSS DT bindings land on mainline and
> we can use a phandle to get the regulator.

I just sent a patchset, that adds DT panel support for N900.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131123/c3c30061/attachment.sig>