[PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01

[PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01

[Tony Lindgren]

Hi all,

Here are few patches to add devicetree support for panel ls037v7dw01
that's found on many omap3 boards. They seem to be often mis-configured
as various panel dpi entries, but really should be move to use panel
ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
ldp, omap3 evm and few other development boards.

Regards,

Tony

Tony Lindgren (4):
  OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
  OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
  OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
  ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
    ldp

 .../bindings/panel/sharp,ls037v7dw01.txt           |  53 +++++++
 .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi |  82 ++++++++++
 arch/arm/boot/dts/omap3-evm-37xx.dts               |  50 ++++++
 arch/arm/boot/dts/omap3-evm-common.dtsi            |  47 ++++++
 arch/arm/boot/dts/omap3-ldp.dts                    |  31 +++-
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 176 ++++++++++++++-------
 drivers/video/fbdev/omap2/dss/dss.c                |   5 +-
 7 files changed, 379 insertions(+), 65 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
 create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi

-- 
1.8.1.1

[PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

Otherwise we can get often errors like the following and the
display won't come on:

omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled

There are some earlier references to this issue:

http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html

It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
 	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
 };
 
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
 static const struct dss_features omap3630_dss_feats __initconst = {
-	.fck_div_max		=	32,
-	.dss_fck_multiplier	=	1,
+	.fck_div_max		=	16,
+	.dss_fck_multiplier	=	2,
 	.parent_clk_name	=	"dpll4_ck",
 	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
 };
-- 
1.8.1.1

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140429 16:53]:
> Otherwise we can get often errors like the following and the
> display won't come on:
> 
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> the output with video overlays disabled
> 
> There are some earlier references to this issue:
> 
> http://www.spinics.net/lists/linux-omap/msg59511.html
> http://www.spinics.net/lists/linux-omap/msg59724.html
> 
> It seems that it's safe to set the lower values even for 3630.
> If we can confirm that 3630 works with the higher values
> reliably we can add further detection.

BTW, I'm also seeing this warning on 3730-evm it may be related:

[    3.523101] ------------[ cut here ]------------
[    3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
[    3.538360] clk rate mismatch: 108000000 != 115200000
[    3.543518] Modules linked in:
[    3.546966] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G        W     3.15.0-rc3-00015-gaa296fa-dirty #391
[    3.557159] Workqueue: deferwq deferred_probe_work_func
[    3.562774] [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
[    3.571014] [<c001191c>] (show_stack) from [<c05660b4>] (dump_stack+0x80/0x9c)
[    3.578704] [<c05660b4>] (dump_stack) from [<c003f558>] (warn_slowpath_common+0x68/0x8c)
[    3.587249] [<c003f558>] (warn_slowpath_common) from [<c003f610>] (warn_slowpath_fmt+0x30/0x40)
[    3.596496] [<c003f610>] (warn_slowpath_fmt) from [<c03129f0>] (dss_set_fck_rate+0x6c/0x8c)
[    3.605407] [<c03129f0>] (dss_set_fck_rate) from [<c0323728>] (dpi_display_enable+0x23c/0x2e4)
[    3.614562] [<c0323728>] (dpi_display_enable) from [<c03323a8>] (sharp_ls_enable+0x58/0xc4)
[    3.623474] [<c03323a8>] (sharp_ls_enable) from [<c0335ee0>] (omapfb_probe+0x548/0x848)
[    3.631988] [<c0335ee0>] (omapfb_probe) from [<c0378cfc>] (platform_drv_probe+0x18/0x48)
[    3.640594] [<c0378cfc>] (platform_drv_probe) from [<c0377938>] (driver_probe_device+0x110/0x22c)
[    3.650024] [<c0377938>] (driver_probe_device) from [<c0376038>] (bus_for_each_drv+0x44/0x8c)
[    3.659088] [<c0376038>] (bus_for_each_drv) from [<c03777f0>] (device_attach+0x74/0x8c)
[    3.667541] [<c03777f0>] (device_attach) from [<c0376ecc>] (bus_probe_device+0x88/0xb0)
[    3.676025] [<c0376ecc>] (bus_probe_device) from [<c03772d0>] (deferred_probe_work_func+0x64/0x94)
[    3.685546] [<c03772d0>] (deferred_probe_work_func) from [<c0057220>] (process_one_work+0x1b4/0x4bc)
[    3.695251] [<c0057220>] (process_one_work) from [<c0057908>] (worker_thread+0x11c/0x398)
[    3.704620] [<c0057908>] (worker_thread) from [<c005df10>] (kthread+0xc8/0xe4)
[    3.712280] [<c005df10>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
[    3.719909] ---[ end trace 1c9526c1a2975498 ]---

 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..ad6561f 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
>  	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
>  };
>  
> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
>  static const struct dss_features omap3630_dss_feats __initconst = {
> -	.fck_div_max		=	32,
> -	.dss_fck_multiplier	=	1,
> +	.fck_div_max		=	16,
> +	.dss_fck_multiplier	=	2,
>  	.parent_clk_name	=	"dpll4_ck",
>  	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
>  };
> -- 
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On 09/05/14 02:20, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
> 
> BTW, I'm also seeing this warning on 3730-evm it may be related:
> 
> [    3.523101] ------------[ cut here ]------------
> [    3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
> [    3.538360] clk rate mismatch: 108000000 != 115200000
> [    3.543518] Modules linked in:

Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
framework calculates the clock rate differently than the dss. Or do we
have different clock.dts files used for 3730 and 3630?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]:
> On 09/05/14 02:20, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140429 16:53]:
> >> Otherwise we can get often errors like the following and the
> >> display won't come on:
> >>
> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> >> the output with video overlays disabled
> >>
> >> There are some earlier references to this issue:
> >>
> >> http://www.spinics.net/lists/linux-omap/msg59511.html
> >> http://www.spinics.net/lists/linux-omap/msg59724.html
> >>
> >> It seems that it's safe to set the lower values even for 3630.
> >> If we can confirm that 3630 works with the higher values
> >> reliably we can add further detection.
> > 
> > BTW, I'm also seeing this warning on 3730-evm it may be related:
> > 
> > [    3.523101] ------------[ cut here ]------------
> > [    3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
> > [    3.538360] clk rate mismatch: 108000000 != 115200000
> > [    3.543518] Modules linked in:
> 
> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
> framework calculates the clock rate differently than the dss. Or do we
> have different clock.dts files used for 3730 and 3630?

OK pasted to the other email in this thread.

Tony

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On 09/05/14 17:37, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]:
>> On 09/05/14 02:20, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>>>> Otherwise we can get often errors like the following and the
>>>> display won't come on:
>>>>
>>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>>>> the output with video overlays disabled
>>>>
>>>> There are some earlier references to this issue:
>>>>
>>>> http://www.spinics.net/lists/linux-omap/msg59511.html
>>>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>>>
>>>> It seems that it's safe to set the lower values even for 3630.
>>>> If we can confirm that 3630 works with the higher values
>>>> reliably we can add further detection.
>>>
>>> BTW, I'm also seeing this warning on 3730-evm it may be related:
>>>
>>> [    3.523101] ------------[ cut here ]------------
>>> [    3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
>>> [    3.538360] clk rate mismatch: 108000000 != 115200000
>>> [    3.543518] Modules linked in:
>>
>> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
>> framework calculates the clock rate differently than the dss. Or do we
>> have different clock.dts files used for 3730 and 3630?
> 
> OK pasted to the other email in this thread.

I mean the debugs for clock framework. The above warning means that the
clock framework says the clock rate is X, but the dss had calculated
that it should be Y. So there's a difference how the clock framework
calculates the rate and how the dss calculates it.

And yes, dss shouldn't calculate it. But I don't know how to get good
pixel clocks if we didn't.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

On 30/04/14 02:52, Tony Lindgren wrote:
> Otherwise we can get often errors like the following and the
> display won't come on:
> 
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> the output with video overlays disabled
> 
> There are some earlier references to this issue:
> 
> http://www.spinics.net/lists/linux-omap/msg59511.html
> http://www.spinics.net/lists/linux-omap/msg59724.html

Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?

What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.

> It seems that it's safe to set the lower values even for 3630.
> If we can confirm that 3630 works with the higher values
> reliably we can add further detection.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..ad6561f 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
>  	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
>  };
>  
> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
>  static const struct dss_features omap3630_dss_feats __initconst = {
> -	.fck_div_max		=	32,
> -	.dss_fck_multiplier	=	1,
> +	.fck_div_max		=	16,
> +	.dss_fck_multiplier	=	2,

These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > Otherwise we can get often errors like the following and the
> > display won't come on:
> > 
> > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> > omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> > the output with video overlays disabled
> > 
> > There are some earlier references to this issue:
> > 
> > http://www.spinics.net/lists/linux-omap/msg59511.html
> > http://www.spinics.net/lists/linux-omap/msg59724.html
> 
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?

Without this patch:
# cat /sys/kernel/debug/omapdss/clk 
[   24.833831] DSS: dss_runtime_get
[   24.837554] DSS: dss_runtime_put
[   24.840972] DISPC: dispc_runtime_get
[   24.844757] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 57600000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck             57600000        
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck             57600000        lck div 1
pck             19200000        pck div 3


With this patch:
# cat /sys/kernel/debug/omapdss/clk 
[   34.580688] DSS: dss_runtime_get
[   34.584197] DSS: dss_runtime_put
[   34.587768] DISPC: dispc_runtime_get
[   34.591552] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 108000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck             108000000       
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck             108000000       lck div 1
pck             18000000        pck div 6
 
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.

This is just the 3730-evm with the Sharp VGA panel mentioned in
this series.
 
> > It seems that it's safe to set the lower values even for 3630.
> > If we can confirm that 3630 works with the higher values
> > reliably we can add further detection.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> > index d55266c..ad6561f 100644
> > --- a/drivers/video/fbdev/omap2/dss/dss.c
> > +++ b/drivers/video/fbdev/omap2/dss/dss.c
> > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> >  	.dpi_select_source	=	&dss_dpi_select_source_omap2_omap3,
> >  };
> >  
> > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> >  static const struct dss_features omap3630_dss_feats __initconst = {
> > -	.fck_div_max		=	32,
> > -	.dss_fck_multiplier	=	1,
> > +	.fck_div_max		=	16,
> > +	.dss_fck_multiplier	=	2,
> 
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
> 
>  Tomi
> 
> 

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

On 09/05/14 17:37, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]:
>> On 30/04/14 02:52, Tony Lindgren wrote:
>>> Otherwise we can get often errors like the following and the
>>> display won't come on:
>>>
>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>>> the output with video overlays disabled
>>>
>>> There are some earlier references to this issue:
>>>
>>> http://www.spinics.net/lists/linux-omap/msg59511.html
>>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>
>> Those don't sound like the same issue, but it's hard to say. What kind
>> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
>> without this patch?
> 
> Without this patch:
> # cat /sys/kernel/debug/omapdss/clk 
> [   24.833831] DSS: dss_runtime_get
> [   24.837554] DSS: dss_runtime_put
> [   24.840972] DISPC: dispc_runtime_get
> [   24.844757] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 57600000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck             57600000        
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck             57600000        lck div 1
> pck             19200000        pck div 3
> 
> 
> With this patch:
> # cat /sys/kernel/debug/omapdss/clk 
> [   34.580688] DSS: dss_runtime_get
> [   34.584197] DSS: dss_runtime_put
> [   34.587768] DISPC: dispc_runtime_get
> [   34.591552] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 108000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck             108000000       
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck             108000000       lck div 1
> pck             18000000        pck div 6
>  
>> What resolution do you have? If it's a very high resolution (say, DVI
>> output to a monitor), it could just be an issue of
>> not-enough-memory-bandwidth.
> 
> This is just the 3730-evm with the Sharp VGA panel mentioned in
> this series.

Hmm, well, those both look fine. The fck is well below the maximum,
which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
with this patch, but that should affect the GFX overlay.

So you're just booting, and there are no applications that use the
framebuffer? And there is no rotation or such configured?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
> On 09/05/14 17:37, Tony Lindgren wrote:
> > 
> > This is just the 3730-evm with the Sharp VGA panel mentioned in
> > this series.
> 
> Hmm, well, those both look fine. The fck is well below the maximum,
> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
> with this patch, but that should affect the GFX overlay.
> 
> So you're just booting, and there are no applications that use the
> framebuffer? And there is no rotation or such configured?

Right. The rotation is set to 3 though.

Tony

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On 12/05/14 17:39, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
>> On 09/05/14 17:37, Tony Lindgren wrote:
>>>
>>> This is just the 3730-evm with the Sharp VGA panel mentioned in
>>> this series.
>>
>> Hmm, well, those both look fine. The fck is well below the maximum,
>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
>> with this patch, but that should affect the GFX overlay.
>>
>> So you're just booting, and there are no applications that use the
>> framebuffer? And there is no rotation or such configured?
> 
> Right. The rotation is set to 3 though.

Hmm, that's probably the issue then. VRFB rotation is very heavy on the
memory bandwidth, and is generally a very easy way to get sync lost errors.

My opinion is that VRFB should only be used when you know your system
will handle it fine with the clock rates and bandwidth usage you have
for your use cases.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]:
> On 12/05/14 17:39, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
> >> On 09/05/14 17:37, Tony Lindgren wrote:
> >>>
> >>> This is just the 3730-evm with the Sharp VGA panel mentioned in
> >>> this series.
> >>
> >> Hmm, well, those both look fine. The fck is well below the maximum,
> >> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
> >> with this patch, but that should affect the GFX overlay.
> >>
> >> So you're just booting, and there are no applications that use the
> >> framebuffer? And there is no rotation or such configured?
> > 
> > Right. The rotation is set to 3 though.
> 
> Hmm, that's probably the issue then. VRFB rotation is very heavy on the
> memory bandwidth, and is generally a very easy way to get sync lost errors.

I found another case without rotation where the error always triggers.
By forcing 3730-evm LCD panel to QVGA mode it always seems to happen
even without rotation.

Without this patch with errors and no image:

# cat /sys/kernel/debug/omapdss/clk 
[   55.185729] DSS: dss_runtime_get
[   55.189422] DSS: dss_runtime_put
[   55.192810] DISPC: dispc_runtime_get
[   55.196685] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 27000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck             27000000        
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck             27000000        lck div 1
pck             5400000         pck div 5

With this patch without errors and penguin showing:

# cat /sys/kernel/debug/omapdss/clk
[   19.905792] DSS: dss_runtime_get
[   19.909545] DSS: dss_runtime_put
[   19.912933] DISPC: dispc_runtime_get
[   19.916778] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 108000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck             108000000       
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck             108000000       lck div 1
pck             5400000         pck div 20

In this case the errors are different too:

DISPC: channel 0 xres 240 yres 320
DISPC: pck 5400000
DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7
DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0
DISPC: hsync 18947Hz, vsync 57Hz
DISPC: lck = 27000000 (1)
DISPC: pck = 5400000 (5)
APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW 
APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST 
DISPC: dispc_runtime_get
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

Regarding rotation, it does look like that with VGA mode enabling
rotation makes the error trigger quite often on 3730.
 
> will handle it fine with the clock rates and bandwidth usage you have
> for your use cases.

I don't think it's all because of rotation. And rotating my head
makes my neck hurt!

Regards,

Tony

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 4221 bytes --]

On 13/05/14 18:26, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]:
>> On 12/05/14 17:39, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
>>>> On 09/05/14 17:37, Tony Lindgren wrote:
>>>>>
>>>>> This is just the 3730-evm with the Sharp VGA panel mentioned in
>>>>> this series.
>>>>
>>>> Hmm, well, those both look fine. The fck is well below the maximum,
>>>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
>>>> with this patch, but that should affect the GFX overlay.
>>>>
>>>> So you're just booting, and there are no applications that use the
>>>> framebuffer? And there is no rotation or such configured?
>>>
>>> Right. The rotation is set to 3 though.
>>
>> Hmm, that's probably the issue then. VRFB rotation is very heavy on the
>> memory bandwidth, and is generally a very easy way to get sync lost errors.
> 
> I found another case without rotation where the error always triggers.
> By forcing 3730-evm LCD panel to QVGA mode it always seems to happen
> even without rotation.
> 
> Without this patch with errors and no image:
> 
> # cat /sys/kernel/debug/omapdss/clk 
> [   55.185729] DSS: dss_runtime_get
> [   55.189422] DSS: dss_runtime_put
> [   55.192810] DISPC: dispc_runtime_get
> [   55.196685] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 27000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck             27000000        
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck             27000000        lck div 1
> pck             5400000         pck div 5
> 
> With this patch without errors and penguin showing:
> 
> # cat /sys/kernel/debug/omapdss/clk
> [   19.905792] DSS: dss_runtime_get
> [   19.909545] DSS: dss_runtime_put
> [   19.912933] DISPC: dispc_runtime_get
> [   19.916778] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 108000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck             108000000       
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck             108000000       lck div 1
> pck             5400000         pck div 20
> 
> In this case the errors are different too:
> 
> DISPC: channel 0 xres 240 yres 320
> DISPC: pck 5400000
> DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7
> DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0
> DISPC: hsync 18947Hz, vsync 57Hz
> DISPC: lck = 27000000 (1)
> DISPC: pck = 5400000 (5)
> APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW 
> APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST 
> DISPC: dispc_runtime_get
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

I'm quite out of ideas... The pixel clock is so low that underflow
shouldn't really happen. I was trying to find 3730 documentation that
would describe the PRCM's multipliers and dividers for DSS (i.e. the
ones you change in this patch), but I didn't find anything.

Maybe the DSS clock's fixed multiplier has been changed for 3730. But in
that case our .dts files related to the clocks are wrong too. The clock
nodes related to this are dpll4_m4x2_mul_ck, which is corresponds to the
"dss_fck_multiplier" value in omapdss, and dpll4_m4_ck, which
corresponds to the "fck_div_max" value.

One thing to try out is, without this patch, change
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to force the dss func clock higher.
With QVGA mode, you could try, say, value of 19, which should make sure
the fck is at least 19 times higher than pck.

> Regarding rotation, it does look like that with VGA mode enabling
> rotation makes the error trigger quite often on 3730.
>  
>> will handle it fine with the clock rates and bandwidth usage you have
>> for your use cases.
> 
> I don't think it's all because of rotation. And rotating my head

No, probably not. The pixel clocks are so low that the rotation should
work fine. Except if there's something wrong the the VRFB or the memory
bus, which make the VRFB rotation not work even with low pixel clocks.

> makes my neck hurt!

You need to learn to hold the device a bit differently!

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Andreas Müller]

On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 30/04/14 02:52, Tony Lindgren wrote:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>
resend - my client had HTML enabled...

FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
still the reboot problem on old 600MHz OMAP 3530. Applying this patch
solved the issues. For other versions I had no chance to reproduce the
original wakup issue mentioned in old thread

[1] http://marc.info/?l=linux-omap&m\x136250904607413&w=2

Andreas
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?
>
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.
>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
>>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
>> index d55266c..ad6561f 100644
>> --- a/drivers/video/fbdev/omap2/dss/dss.c
>> +++ b/drivers/video/fbdev/omap2/dss/dss.c
>> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
>>       .dpi_select_source      =       &dss_dpi_select_source_omap2_omap3,
>>  };
>>
>> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
>>  static const struct dss_features omap3630_dss_feats __initconst = {
>> -     .fck_div_max            =       32,
>> -     .dss_fck_multiplier     =       1,
>> +     .fck_div_max            =       16,
>> +     .dss_fck_multiplier     =       2,
>
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
>
>  Tomi
>
>

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 30/04/14 02:52, Tony Lindgren wrote:
> >> Otherwise we can get often errors like the following and the
> >> display won't come on:
> >>
> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> >> the output with video overlays disabled
> >>
> >> There are some earlier references to this issue:
> >>
> >> http://www.spinics.net/lists/linux-omap/msg59511.html
> >> http://www.spinics.net/lists/linux-omap/msg59724.html
> >
> resend - my client had HTML enabled...
> 
> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
> still the reboot problem on old 600MHz OMAP 3530. Applying this patch
> solved the issues. For other versions I had no chance to reproduce the
> original wakup issue mentioned in old thread

Sorry I'm a bit confused now. Is the reboot issue a separate issue
related to the twl4030 generic scripts for 3530?

And then this patch fixes dm3730 wake-up (from suspend?) issues?

Or do we have some other bug where we wrongly hit omap3630_dss_feats
on 3530 somehow?

Regards,

Tony
 
> [1] http://marc.info/?l=linux-omap&m\x136250904607413&w=2
> 
> Andreas
> > Those don't sound like the same issue, but it's hard to say. What kind
> > of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> > without this patch?
> >
> > What resolution do you have? If it's a very high resolution (say, DVI
> > output to a monitor), it could just be an issue of
> > not-enough-memory-bandwidth.
> >
> >> It seems that it's safe to set the lower values even for 3630.
> >> If we can confirm that 3630 works with the higher values
> >> reliably we can add further detection.
> >>
> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> >> ---
> >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> >> index d55266c..ad6561f 100644
> >> --- a/drivers/video/fbdev/omap2/dss/dss.c
> >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> >> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> >>       .dpi_select_source      =       &dss_dpi_select_source_omap2_omap3,
> >>  };
> >>
> >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> >>  static const struct dss_features omap3630_dss_feats __initconst = {
> >> -     .fck_div_max            =       32,
> >> -     .dss_fck_multiplier     =       1,
> >> +     .fck_div_max            =       16,
> >> +     .dss_fck_multiplier     =       2,
> >
> > These values tell about the clock hardware, they are not settings that
> > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> > and a divider with maximum value of 16.
> >
> >  Tomi
> >
> >

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Andreas Müller]

On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
>> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On 30/04/14 02:52, Tony Lindgren wrote:
>> >> Otherwise we can get often errors like the following and the
>> >> display won't come on:
>> >>
>> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> >> the output with video overlays disabled
>> >>
>> >> There are some earlier references to this issue:
>> >>
>> >> http://www.spinics.net/lists/linux-omap/msg59511.html
>> >> http://www.spinics.net/lists/linux-omap/msg59724.html
>> >
>> resend - my client had HTML enabled...
>>
>> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
>> still the reboot problem on old 600MHz OMAP 3530. Applying this patch
>> solved the issues. For other versions I had no chance to reproduce the
>> original wakup issue mentioned in old thread
>
> Sorry I'm a bit confused now. Is the reboot issue a separate issue
> related to the twl4030 generic scripts for 3530?
>
> And then this patch fixes dm3730 wake-up (from suspend?) issues?
>
> Or do we have some other bug where we wrongly hit omap3630_dss_feats
> on 3530 somehow?
(What I think) I have done: Have 3.14.3 still booting with legacy
board init (please don't kill me for that). Without applying your
patch old OMAP3530 crashed at every reboot with SYNCH_LOST.

After applying your patch reboot works fine.

Looking into id-code makes me wonder what changes on 36xx-features do
to 35xx devices (treated as 34xx - right?). The only way that this
happens is for unknown hawkeye fallthough. I suggest you simply forget
my note and I will find out what really 'fixed' dss reboot problem.

Andreas

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

[Tony Lindgren]

* Andreas Müller <schnitzeltony@googlemail.com> [140512 01:20]:
> On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
> >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> > On 30/04/14 02:52, Tony Lindgren wrote:
> >> >> Otherwise we can get often errors like the following and the
> >> >> display won't come on:
> >> >>
> >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> >> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> >> >> the output with video overlays disabled
> >> >>
> >> >> There are some earlier references to this issue:
> >> >>
> >> >> http://www.spinics.net/lists/linux-omap/msg59511.html
> >> >> http://www.spinics.net/lists/linux-omap/msg59724.html
> >> >
> >> resend - my client had HTML enabled...
> >>
> >> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
> >> still the reboot problem on old 600MHz OMAP 3530. Applying this patch
> >> solved the issues. For other versions I had no chance to reproduce the
> >> original wakup issue mentioned in old thread
> >
> > Sorry I'm a bit confused now. Is the reboot issue a separate issue
> > related to the twl4030 generic scripts for 3530?
> >
> > And then this patch fixes dm3730 wake-up (from suspend?) issues?
> >
> > Or do we have some other bug where we wrongly hit omap3630_dss_feats
> > on 3530 somehow?
> (What I think) I have done: Have 3.14.3 still booting with legacy
> board init (please don't kill me for that). Without applying your
> patch old OMAP3530 crashed at every reboot with SYNCH_LOST.
> 
> After applying your patch reboot works fine.
> 
> Looking into id-code makes me wonder what changes on 36xx-features do
> to 35xx devices (treated as 34xx - right?). The only way that this
> happens is for unknown hawkeye fallthough. I suggest you simply forget
> my note and I will find out what really 'fixed' dss reboot problem.

Yeah 35xx should be treated as 34xx so sounds like there might be
some detection problem if this patch does something for your board.

Regards,

Tony

[PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

[Tony Lindgren]

Using gpiod will make it easier to add device tree support
for this panel in the following patches.

Note that all the GPIOs for this panel are optional, any
of the the GPIOs could be configured with external pulls
instead of GPIOs, so let's not error out if GPIOs are not
found to make the panel more generic.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 92 +++++++++-------------
 1 file changed, 38 insertions(+), 54 deletions(-)

diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index b2f710b..de8473a 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -26,11 +26,11 @@ struct panel_drv_data {
 
 	struct omap_video_timings videomode;
 
-	int resb_gpio;
-	int ini_gpio;
-	int mo_gpio;
-	int lr_gpio;
-	int ud_gpio;
+	struct gpio_desc *resb_gpio;	/* low = reset active min 20 us */
+	struct gpio_desc *ini_gpio;	/* high = power on */
+	struct gpio_desc *mo_gpio;	/* low = 480x640, high = 240x320 */
+	struct gpio_desc *lr_gpio;	/* high = conventional horizontal scanning */
+	struct gpio_desc *ud_gpio;	/* high = conventional vertical scanning */
 };
 
 static const struct omap_video_timings sharp_ls_timings = {
@@ -105,11 +105,11 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	/* wait couple of vsyncs until enabling the LCD */
 	msleep(50);
 
-	if (gpio_is_valid(ddata->resb_gpio))
-		gpio_set_value_cansleep(ddata->resb_gpio, 1);
+	if (!IS_ERR(ddata->resb_gpio))
+		gpiod_set_value_cansleep(ddata->resb_gpio, 1);
 
-	if (gpio_is_valid(ddata->ini_gpio))
-		gpio_set_value_cansleep(ddata->ini_gpio, 1);
+	if (!IS_ERR(ddata->ini_gpio))
+		gpiod_set_value_cansleep(ddata->ini_gpio, 1);
 
 	dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
@@ -124,11 +124,11 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
 	if (!omapdss_device_is_enabled(dssdev))
 		return;
 
-	if (gpio_is_valid(ddata->ini_gpio))
-		gpio_set_value_cansleep(ddata->ini_gpio, 0);
+	if (!IS_ERR(ddata->ini_gpio))
+		gpiod_set_value_cansleep(ddata->ini_gpio, 0);
 
-	if (gpio_is_valid(ddata->resb_gpio))
-		gpio_set_value_cansleep(ddata->resb_gpio, 0);
+	if (!IS_ERR(ddata->resb_gpio))
+		gpiod_set_value_cansleep(ddata->resb_gpio, 0);
 
 	/* wait at least 5 vsyncs after disabling the LCD */
 
@@ -182,6 +182,21 @@ static struct omap_dss_driver sharp_ls_ops = {
 	.get_resolution	= omapdss_default_get_resolution,
 };
 
+static struct gpio_desc *
+sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+		  char *desc)
+{
+	int r;
+
+	r = devm_gpio_request_one(dev, gpio, flags, desc);
+	if (r) {
+		dev_err(dev, "no %s gpio\n", desc);
+		return ERR_PTR(r);
+	}
+
+	return gpio_to_desc(gpio);
+}
+
 static int sharp_ls_probe_pdata(struct platform_device *pdev)
 {
 	const struct panel_sharp_ls037v7dw01_platform_data *pdata;
@@ -204,11 +219,16 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	dssdev = &ddata->dssdev;
 	dssdev->name = pdata->name;
 
-	ddata->resb_gpio = pdata->resb_gpio;
-	ddata->ini_gpio = pdata->ini_gpio;
-	ddata->mo_gpio = pdata->mo_gpio;
-	ddata->lr_gpio = pdata->lr_gpio;
-	ddata->ud_gpio = pdata->ud_gpio;
+	ddata->mo_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->mo_gpio,
+					   GPIOF_OUT_INIT_LOW, "lcd MO");
+	ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+					   GPIOF_OUT_INIT_HIGH, "lcd LR");
+	ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+					   GPIOF_OUT_INIT_HIGH, "lcd UD");
+	ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+					     GPIOF_OUT_INIT_LOW, "lcd RESB");
+	ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+					    GPIOF_OUT_INIT_LOW, "lcd INI");
 
 	return 0;
 }
@@ -233,41 +253,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	if (gpio_is_valid(ddata->mo_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->mo_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd MO");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->lr_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->lr_gpio,
-				GPIOF_OUT_INIT_HIGH, "lcd LR");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->ud_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->ud_gpio,
-				GPIOF_OUT_INIT_HIGH, "lcd UD");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->resb_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->resb_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd RESB");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->ini_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->ini_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd INI");
-		if (r)
-			goto err_gpio;
-	}
-
 	ddata->videomode = sharp_ls_timings;
 
 	dssdev = &ddata->dssdev;
@@ -287,7 +272,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
 	return 0;
 
 err_reg:
-err_gpio:
 	omap_dss_put_device(ddata->in);
 	return r;
 }
-- 
1.8.1.1

Re: [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On 30/04/14 02:52, Tony Lindgren wrote:
> Using gpiod will make it easier to add device tree support
> for this panel in the following patches.
> 
> Note that all the GPIOs for this panel are optional, any
> of the the GPIOs could be configured with external pulls
> instead of GPIOs, so let's not error out if GPIOs are not
> found to make the panel more generic.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 92 +++++++++-------------
>  1 file changed, 38 insertions(+), 54 deletions(-)

<snip>

> +static struct gpio_desc *
> +sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
> +		  char *desc)
> +{
> +	int r;
> +
> +	r = devm_gpio_request_one(dev, gpio, flags, desc);
> +	if (r) {
> +		dev_err(dev, "no %s gpio\n", desc);

As it's fine to not have a gpio, I guess this error print should be removed.

Also, if the error is EPROBE_DEFER, the driver should fail and return
that. The same goes for the DT version in the next patch.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 01:15]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > +static struct gpio_desc *
> > +sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
> > +		  char *desc)
> > +{
> > +	int r;
> > +
> > +	r = devm_gpio_request_one(dev, gpio, flags, desc);
> > +	if (r) {
> > +		dev_err(dev, "no %s gpio\n", desc);
> 
> As it's fine to not have a gpio, I guess this error print should be removed.

OK I made it a dev_dbg, it may help somebody while
configuring the panel.
 
> Also, if the error is EPROBE_DEFER, the driver should fail and return
> that. The same goes for the DT version in the next patch.

Good catch. It's a bit unfortunate that all drivers have to
sprinkle EPROBE_DEFER handling all over the place, that issue
is really caused by a missing resource management layer at
the bus level :(

Below is the updated patch, please feel free to pick if OK.

Regards,

Tony

8<---------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:20 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

Using gpiod will make it easier to add device tree support
for this panel in the following patches.

Note that all the GPIOs for this panel are optional, any
of the the GPIOs could be configured with external pulls
instead of GPIOs, so let's not error out if GPIOs are not
found to make the panel more generic.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -26,11 +26,11 @@ struct panel_drv_data {
 
 	struct omap_video_timings videomode;
 
-	int resb_gpio;
-	int ini_gpio;
-	int mo_gpio;
-	int lr_gpio;
-	int ud_gpio;
+	struct gpio_desc *resb_gpio;	/* low = reset active min 20 us */
+	struct gpio_desc *ini_gpio;	/* high = power on */
+	struct gpio_desc *mo_gpio;	/* low = 480x640, high = 240x320 */
+	struct gpio_desc *lr_gpio;	/* high = conventional horizontal scanning */
+	struct gpio_desc *ud_gpio;	/* high = conventional vertical scanning */
 };
 
 static const struct omap_video_timings sharp_ls_timings = {
@@ -105,11 +105,11 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	/* wait couple of vsyncs until enabling the LCD */
 	msleep(50);
 
-	if (gpio_is_valid(ddata->resb_gpio))
-		gpio_set_value_cansleep(ddata->resb_gpio, 1);
+	if (!IS_ERR(ddata->resb_gpio))
+		gpiod_set_value_cansleep(ddata->resb_gpio, 1);
 
-	if (gpio_is_valid(ddata->ini_gpio))
-		gpio_set_value_cansleep(ddata->ini_gpio, 1);
+	if (!IS_ERR(ddata->ini_gpio))
+		gpiod_set_value_cansleep(ddata->ini_gpio, 1);
 
 	dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
@@ -124,11 +124,11 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
 	if (!omapdss_device_is_enabled(dssdev))
 		return;
 
-	if (gpio_is_valid(ddata->ini_gpio))
-		gpio_set_value_cansleep(ddata->ini_gpio, 0);
+	if (!IS_ERR(ddata->ini_gpio))
+		gpiod_set_value_cansleep(ddata->ini_gpio, 0);
 
-	if (gpio_is_valid(ddata->resb_gpio))
-		gpio_set_value_cansleep(ddata->resb_gpio, 0);
+	if (!IS_ERR(ddata->resb_gpio))
+		gpiod_set_value_cansleep(ddata->resb_gpio, 0);
 
 	/* wait at least 5 vsyncs after disabling the LCD */
 
@@ -182,6 +182,21 @@ static struct omap_dss_driver sharp_ls_ops = {
 	.get_resolution	= omapdss_default_get_resolution,
 };
 
+static struct gpio_desc *
+sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+		  char *desc)
+{
+	int r;
+
+	r = devm_gpio_request_one(dev, gpio, flags, desc);
+	if (r) {
+		dev_dbg(dev, "no %s gpio\n", desc);
+		return ERR_PTR(r);
+	}
+
+	return gpio_to_desc(gpio);
+}
+
 static int sharp_ls_probe_pdata(struct platform_device *pdev)
 {
 	const struct panel_sharp_ls037v7dw01_platform_data *pdata;
@@ -204,11 +219,26 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	dssdev = &ddata->dssdev;
 	dssdev->name = pdata->name;
 
-	ddata->resb_gpio = pdata->resb_gpio;
-	ddata->ini_gpio = pdata->ini_gpio;
-	ddata->mo_gpio = pdata->mo_gpio;
-	ddata->lr_gpio = pdata->lr_gpio;
-	ddata->ud_gpio = pdata->ud_gpio;
+	ddata->mo_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->mo_gpio,
+					   GPIOF_OUT_INIT_LOW, "lcd MO");
+	if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+					   GPIOF_OUT_INIT_HIGH, "lcd LR");
+	if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+					   GPIOF_OUT_INIT_HIGH, "lcd UD");
+	if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+					     GPIOF_OUT_INIT_LOW, "lcd RESB");
+	if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+	ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+					    GPIOF_OUT_INIT_LOW, "lcd INI");
+	if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
 
 	return 0;
 }
@@ -233,41 +263,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	if (gpio_is_valid(ddata->mo_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->mo_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd MO");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->lr_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->lr_gpio,
-				GPIOF_OUT_INIT_HIGH, "lcd LR");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->ud_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->ud_gpio,
-				GPIOF_OUT_INIT_HIGH, "lcd UD");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->resb_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->resb_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd RESB");
-		if (r)
-			goto err_gpio;
-	}
-
-	if (gpio_is_valid(ddata->ini_gpio)) {
-		r = devm_gpio_request_one(&pdev->dev, ddata->ini_gpio,
-				GPIOF_OUT_INIT_LOW, "lcd INI");
-		if (r)
-			goto err_gpio;
-	}
-
 	ddata->videomode = sharp_ls_timings;
 
 	dssdev = &ddata->dssdev;
@@ -287,7 +282,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
 	return 0;
 
 err_reg:
-err_gpio:
 	omap_dss_put_device(ddata->in);
 	return r;
 }

[PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 .../bindings/panel/sharp,ls037v7dw01.txt           | 53 ++++++++++++++
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 84 ++++++++++++++++++++--
 2 files changed, 133 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt

diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
new file mode 100644
index 0000000..7f6f5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,53 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- reset-gpios: a GPIO spec for the optional reset pin
+- enable-gpios: a GPIO array for the optional configuration GPIOs
+  ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example when connected to a omap2+ based device:
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		power-supply = <&lcd_3v3>;
+		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+		enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+				&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
+				&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
+				&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+
+		panel-timing {
+			clock-frequency = <19200000>;
+			hback-porch = <28>;
+			hactive = <480>;
+			hfront-porch = <1>;
+			hsync-len = <2>;
+			vback-porch = <1>;
+			vactive = <640>;
+			vfront-porch = <1>;
+			vsync-len = <1>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index de8473a..3a04fb0 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,19 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
+#include <video/of_display_timing.h>
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
 
 struct panel_drv_data {
 	struct omap_dss_device dssdev;
 	struct omap_dss_device *in;
+	struct regulator *vcc;
 
 	int data_lines;
 
@@ -95,7 +99,8 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	if (omapdss_device_is_enabled(dssdev))
 		return 0;
 
-	in->ops.dpi->set_data_lines(in, ddata->data_lines);
+	if (ddata->data_lines)
+		in->ops.dpi->set_data_lines(in, ddata->data_lines);
 	in->ops.dpi->set_timings(in, &ddata->videomode);
 
 	r = in->ops.dpi->enable(in);
@@ -230,6 +235,67 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
 					    GPIOF_OUT_INIT_LOW, "lcd INI");
 
+	ddata->videomode = sharp_ls_timings;
+
+	return 0;
+}
+
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+	struct gpio_desc *gpio;
+
+	gpio = devm_gpiod_get_index(dev, desc, index);
+	if (!IS_ERR(gpio))
+		gpiod_direction_output(gpio, val);
+
+	return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct display_timing timing;
+	struct videomode vm;
+	int r;
+
+	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+	if (IS_ERR(ddata->vcc)) {
+		dev_err(&pdev->dev, "failed to get regulator\n");
+		return PTR_ERR(ddata->vcc);
+	}
+
+	r = regulator_enable(ddata->vcc);
+	if (r != 0) {
+		dev_err(&pdev->dev, "failed to enable regulator\n");
+		return r;
+	}
+
+	ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");	/* lcd RESB */
+	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");	/* lcd MO */
+	ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "enable");	/* lcd LR */
+	ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "enable");	/* lcd UD */
+	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");	/* lcd INI */
+
+	r = of_get_display_timing(node, "panel-timing", &timing);
+	if (r) {
+		dev_err(&pdev->dev, "failed to get video timing\n");
+		return r;
+	}
+
+	videomode_from_timing(&timing, &vm);
+	videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+	in = omapdss_of_find_source_for_first_ep(node);
+	if (IS_ERR(in)) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return PTR_ERR(in);
+	}
+
+	ddata->in = in;
+
 	return 0;
 }
 
@@ -249,12 +315,14 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		r = sharp_ls_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = sharp_ls_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
 
-	ddata->videomode = sharp_ls_timings;
-
 	dssdev = &ddata->dssdev;
 	dssdev->dev = &pdev->dev;
 	dssdev->driver = &sharp_ls_ops;
@@ -292,12 +360,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id sharp_ls_of_match[] = {
+	{ .compatible = "sharp,ls037v7dw01", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
 static struct platform_driver sharp_ls_driver = {
 	.probe = sharp_ls_probe,
 	.remove = __exit_p(sharp_ls_remove),
 	.driver = {
 		.name = "panel-sharp-ls037v7dw01",
 		.owner = THIS_MODULE,
+		.of_match_table = sharp_ls_of_match,
 	},
 };
 
-- 
1.8.1.1

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On 30/04/14 02:52, Tony Lindgren wrote:
> We can pass the GPIO configuration for ls037v7dw01 in a standard
> gpios property.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  .../bindings/panel/sharp,ls037v7dw01.txt           | 53 ++++++++++++++
>  .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 84 ++++++++++++++++++++--
>  2 files changed, 133 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> new file mode 100644
> index 0000000..7f6f5e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> @@ -0,0 +1,53 @@
> +SHARP LS037V7DW01 TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls037v7dw01"
> +
> +Optional properties:
> +- reset-gpios: a GPIO spec for the optional reset pin
> +- enable-gpios: a GPIO array for the optional configuration GPIOs
> +  ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> +
> +This panel can have zero to five GPIOs to configure
> +to change configuration between QVGA and VGA mode
> +and the scan direction. As these pins can be also
> +configured with external pulls, all the GPIOs are
> +considered optional with holes in the array.
> +
> +Example when connected to a omap2+ based device:
> +
> +	lcd0: display {
> +		compatible = "sharp,ls037v7dw01";
> +		power-supply = <&lcd_3v3>;
> +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> +		enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
> +				&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
> +				&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
> +				&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */

Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
have anything to do with enabling the panel. Why not just have one
'gpios' array with all the gpios, as they are quite a mixed bunch?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 01:13]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > We can pass the GPIO configuration for ls037v7dw01 in a standard
> > gpios property.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  .../bindings/panel/sharp,ls037v7dw01.txt           | 53 ++++++++++++++
> >  .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 84 ++++++++++++++++++++--
> >  2 files changed, 133 insertions(+), 4 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > new file mode 100644
> > index 0000000..7f6f5e1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > @@ -0,0 +1,53 @@
> > +SHARP LS037V7DW01 TFT-LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "sharp,ls037v7dw01"
> > +
> > +Optional properties:
> > +- reset-gpios: a GPIO spec for the optional reset pin
> > +- enable-gpios: a GPIO array for the optional configuration GPIOs
> > +  ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> > +
> > +This binding is compatible with the simple-panel binding, which is specified
> > +in simple-panel.txt in this directory.
> > +
> > +This panel can have zero to five GPIOs to configure
> > +to change configuration between QVGA and VGA mode
> > +and the scan direction. As these pins can be also
> > +configured with external pulls, all the GPIOs are
> > +considered optional with holes in the array.
> > +
> > +Example when connected to a omap2+ based device:
> > +
> > +	lcd0: display {
> > +		compatible = "sharp,ls037v7dw01";
> > +		power-supply = <&lcd_3v3>;
> > +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> > +		enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
> > +				&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
> > +				&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
> > +				&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
> 
> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> have anything to do with enabling the panel. Why not just have one
> 'gpios' array with all the gpios, as they are quite a mixed bunch?

Yeah that's what I had initially, but reading simple-panel.txt noticed
there are some standardized GPIOs for reset and enable.

How about we set up one reset-gpios, one enable-gpios and an array of
three unlabelled GPIOs?

Or if we want to add something generic, we could add new mode-gpios
property that other panels might be able to use too?

BTW, I'm also personally fine with all five gpios showing in a single
gpios property, I'm not too exited about naming anything in DT..

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On 07/05/14 18:03, Tony Lindgren wrote:

>>> +	lcd0: display {
>>> +		compatible = "sharp,ls037v7dw01";
>>> +		power-supply = <&lcd_3v3>;
>>> +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
>>> +		enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
>>> +				&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
>>> +				&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
>>> +				&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
>>
>> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
>> have anything to do with enabling the panel. Why not just have one
>> 'gpios' array with all the gpios, as they are quite a mixed bunch?
> 
> Yeah that's what I had initially, but reading simple-panel.txt noticed
> there are some standardized GPIOs for reset and enable.

I'm not sure if it's worth to try to make it compatible with
simple-panel. simple-panel bindings do not work with omapdss anyway, and
simple-panel doesn't have the support for input ports/endpoints.

Can the panel be used with only one gpio (I guess that would be INI or
RESB)? If not, simple-panel doesn't work.

> How about we set up one reset-gpios, one enable-gpios and an array of
> three unlabelled GPIOs?
> 
> Or if we want to add something generic, we could add new mode-gpios
> property that other panels might be able to use too?
> 
> BTW, I'm also personally fine with all five gpios showing in a single
> gpios property, I'm not too exited about naming anything in DT..

I don't have a strong opinion here. I don't have much experience with
DT, especially with making bindings compatible with other ones.

I'd just forget the simple-panel, and have single gpio array.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> On 07/05/14 18:03, Tony Lindgren wrote:
> 
> >>> +	lcd0: display {
> >>> +		compatible = "sharp,ls037v7dw01";
> >>> +		power-supply = <&lcd_3v3>;
> >>> +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> >>> +		enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
> >>> +				&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
> >>> +				&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
> >>> +				&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
> >>
> >> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> >> have anything to do with enabling the panel. Why not just have one
> >> 'gpios' array with all the gpios, as they are quite a mixed bunch?
> > 
> > Yeah that's what I had initially, but reading simple-panel.txt noticed
> > there are some standardized GPIOs for reset and enable.
> 
> I'm not sure if it's worth to try to make it compatible with
> simple-panel. simple-panel bindings do not work with omapdss anyway, and
> simple-panel doesn't have the support for input ports/endpoints.
> 
> Can the panel be used with only one gpio (I guess that would be INI or
> RESB)? If not, simple-panel doesn't work.

I guess in theory yes.
 
> > How about we set up one reset-gpios, one enable-gpios and an array of
> > three unlabelled GPIOs?
> > 
> > Or if we want to add something generic, we could add new mode-gpios
> > property that other panels might be able to use too?
> > 
> > BTW, I'm also personally fine with all five gpios showing in a single
> > gpios property, I'm not too exited about naming anything in DT..
> 
> I don't have a strong opinion here. I don't have much experience with
> DT, especially with making bindings compatible with other ones.
> 
> I'd just forget the simple-panel, and have single gpio array.

Well if it's a don't care flag for both of us, let's try to use
the existing standard for simple-panel.txt and add mode-gpios
property. I'll post a patch for that.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140507 11:00]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> > On 07/05/14 18:03, Tony Lindgren wrote:
> > > 
> > > BTW, I'm also personally fine with all five gpios showing in a single
> > > gpios property, I'm not too exited about naming anything in DT..
> > 
> > I don't have a strong opinion here. I don't have much experience with
> > DT, especially with making bindings compatible with other ones.
> > 
> > I'd just forget the simple-panel, and have single gpio array.
> 
> Well if it's a don't care flag for both of us, let's try to use
> the existing standard for simple-panel.txt and add mode-gpios
> property. I'll post a patch for that.

Here's an updated version using enable-gpios, reset-gpios and
mode-gpios. So it follows simple-panel.txt and adds mode-gpios
that's currently specific to this panel only.

Also updated for -EPROBE_DEFER handling, tested that by changing
one of the GPIOs to be a twl4030 GPIO.

Regards,

Tony

8<------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,56 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- enable-gpios: a GPIO spec for the optional enable pin
+  this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+  this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO 
+  ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example when connected to a omap2+ based device:
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		power-supply = <&lcd_3v3>;
+		enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+		mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+			      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+			      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+
+		panel-timing {
+			clock-frequency = <19200000>;
+			hback-porch = <28>;
+			hactive = <480>;
+			hfront-porch = <1>;
+			hsync-len = <2>;
+			vback-porch = <1>;
+			vactive = <640>;
+			vfront-porch = <1>;
+			vsync-len = <1>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,19 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
+#include <video/of_display_timing.h>
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
 
 struct panel_drv_data {
 	struct omap_dss_device dssdev;
 	struct omap_dss_device *in;
+	struct regulator *vcc;
 
 	int data_lines;
 
@@ -95,7 +99,8 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	if (omapdss_device_is_enabled(dssdev))
 		return 0;
 
-	in->ops.dpi->set_data_lines(in, ddata->data_lines);
+	if (ddata->data_lines)
+		in->ops.dpi->set_data_lines(in, ddata->data_lines);
 	in->ops.dpi->set_timings(in, &ddata->videomode);
 
 	r = in->ops.dpi->enable(in);
@@ -240,6 +245,88 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 
+	ddata->videomode = sharp_ls_timings;
+
+	return 0;
+}
+
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+	struct gpio_desc *gpio;
+
+	gpio = devm_gpiod_get_index(dev, desc, index);
+	if (IS_ERR(gpio))
+		return gpio;
+
+	gpiod_direction_output(gpio, val);
+
+	return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct display_timing timing;
+	struct videomode vm;
+	int r;
+
+	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+	if (IS_ERR(ddata->vcc)) {
+		dev_err(&pdev->dev, "failed to get regulator\n");
+		return PTR_ERR(ddata->vcc);
+	}
+
+	r = regulator_enable(ddata->vcc);
+	if (r != 0) {
+		dev_err(&pdev->dev, "failed to enable regulator\n");
+		return r;
+	}
+
+	/* lcd INI */
+	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");
+	if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd RESB */
+	ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");
+	if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd MO */
+	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "mode");
+	if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd LR */
+	ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+	if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd UD */
+	ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+	if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	r = of_get_display_timing(node, "panel-timing", &timing);
+	if (r) {
+		dev_err(&pdev->dev, "failed to get video timing\n");
+		return r;
+	}
+
+	videomode_from_timing(&timing, &vm);
+	videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+	in = omapdss_of_find_source_for_first_ep(node);
+	if (IS_ERR(in)) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return PTR_ERR(in);
+	}
+
+	ddata->in = in;
+
 	return 0;
 }
 
@@ -259,12 +346,14 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		r = sharp_ls_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = sharp_ls_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
 
-	ddata->videomode = sharp_ls_timings;
-
 	dssdev = &ddata->dssdev;
 	dssdev->dev = &pdev->dev;
 	dssdev->driver = &sharp_ls_ops;
@@ -302,12 +391,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id sharp_ls_of_match[] = {
+	{ .compatible = "sharp,ls037v7dw01", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
 static struct platform_driver sharp_ls_driver = {
 	.probe = sharp_ls_probe,
 	.remove = __exit_p(sharp_ls_remove),
 	.driver = {
 		.name = "panel-sharp-ls037v7dw01",
 		.owner = THIS_MODULE,
+		.of_match_table = sharp_ls_of_match,
 	},
 };
 

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]

On 09/05/14 02:33, Tony Lindgren wrote:

> We can pass the GPIO configuration for ls037v7dw01 in a standard
> gpios property.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> @@ -0,0 +1,56 @@
> +SHARP LS037V7DW01 TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls037v7dw01"
> +
> +Optional properties:
> +- enable-gpios: a GPIO spec for the optional enable pin
> +  this pin is the INI pin as specified in the LS037V7DW01.pdf file.
> +- reset-gpios: a GPIO spec for the optional reset pin
> +  this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
> +- mode-gpios: a GPIO 
> +  ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

The video port data is required also. See for example
Documentation/devicetree/bindings/video/panel-dsi-cm.txt or
Documentation/devicetree/bindings/video/hdmi-connector.txt.

Also, all the bindings I've made are in
Documentation/devicetree/bindings/video/, and I'd rather keep the video
bindings OMAP uses in the same place.

> +This panel can have zero to five GPIOs to configure
> +to change configuration between QVGA and VGA mode
> +and the scan direction. As these pins can be also
> +configured with external pulls, all the GPIOs are
> +considered optional with holes in the array.
> +
> +Example when connected to a omap2+ based device:
> +
> +	lcd0: display {
> +		compatible = "sharp,ls037v7dw01";
> +		power-supply = <&lcd_3v3>;
> +		enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
> +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> +		mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
> +			      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
> +			      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
> +
> +		panel-timing {
> +			clock-frequency = <19200000>;
> +			hback-porch = <28>;
> +			hactive = <480>;
> +			hfront-porch = <1>;
> +			hsync-len = <2>;
> +			vback-porch = <1>;
> +			vactive = <640>;
> +			vfront-porch = <1>;
> +			vsync-len = <1>;
> +			hsync-active = <0>;
> +			vsync-active = <0>;
> +			de-active = <1>;
> +			pixelclk-active = <1>;
> +		};

I don't think we should define panel-timing here. We know it's
sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
would extend the driver to support both resolution modes, it needs to
support two different timings, so the above doesn't work in that case
either.

Although if the MO gpio is not controlled by the driver, we should tell
the driver whether that gpio is high or low.

> +static int sharp_ls_probe_of(struct platform_device *pdev)
> +{
> +	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> +	struct device_node *node = pdev->dev.of_node;
> +	struct omap_dss_device *in;
> +	struct display_timing timing;
> +	struct videomode vm;
> +	int r;
> +
> +	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
> +	if (IS_ERR(ddata->vcc)) {
> +		dev_err(&pdev->dev, "failed to get regulator\n");
> +		return PTR_ERR(ddata->vcc);
> +	}
> +
> +	r = regulator_enable(ddata->vcc);
> +	if (r != 0) {
> +		dev_err(&pdev->dev, "failed to enable regulator\n");
> +		return r;
> +	}

The regulator should be enabled when the panel is enabled, not at probe
time.

> +static const struct of_device_id sharp_ls_of_match[] = {
> +	{ .compatible = "sharp,ls037v7dw01", },

At the moment our display drivers are OMAP specific, and for that reason
we should prefix the compatible strings with "omapdss,". For example,
drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:

	{ .compatible = "omapdss,panel-dsi-cm", },

But we should still have the right compatible string in the .dts, so we
convert the compatible name in arch/arm/mach-omap2/display.c, with
'dss_compat_conv_list' array, to which this panel's name should be added.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:24]:
> On 09/05/14 02:33, Tony Lindgren wrote:
> > +Example when connected to a omap2+ based device:
> > +
> > +	lcd0: display {
> > +		compatible = "sharp,ls037v7dw01";
> > +		power-supply = <&lcd_3v3>;
> > +		enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
> > +		reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> > +		mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
> > +			      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
> > +			      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
> > +
> > +		panel-timing {
> > +			clock-frequency = <19200000>;
> > +			hback-porch = <28>;
> > +			hactive = <480>;
> > +			hfront-porch = <1>;
> > +			hsync-len = <2>;
> > +			vback-porch = <1>;
> > +			vactive = <640>;
> > +			vfront-porch = <1>;
> > +			vsync-len = <1>;
> > +			hsync-active = <0>;
> > +			vsync-active = <0>;
> > +			de-active = <1>;
> > +			pixelclk-active = <1>;
> > +		};
> 
> I don't think we should define panel-timing here. We know it's
> sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
> would extend the driver to support both resolution modes, it needs to
> support two different timings, so the above doesn't work in that case
> either.

OK. It seems we can have at least two different timings for this panel,
the VGA timing above and the QVGA timings that LDP uses that are listed
in the .dts changes.
 
> Although if the MO gpio is not controlled by the driver, we should tell
> the driver whether that gpio is high or low.

What do you have in mind for telling that? We should also tell the
orientation of the panel:

EVM	VGA	omapfb.rotate=3
LDP	QVGA	omapfb.rotate=0

Do you have something in mind for that?
 
> At the moment our display drivers are OMAP specific, and for that reason
> we should prefix the compatible strings with "omapdss,". For example,
> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
> 
> 	{ .compatible = "omapdss,panel-dsi-cm", },
> 
> But we should still have the right compatible string in the .dts, so we
> convert the compatible name in arch/arm/mach-omap2/display.c, with
> 'dss_compat_conv_list' array, to which this panel's name should be added.

Oh so what do you want to have in the .dts file then?

Regards,

Tony 

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

On 09/05/14 18:55, Tony Lindgren wrote:

>> Although if the MO gpio is not controlled by the driver, we should tell
>> the driver whether that gpio is high or low.
> 
> What do you have in mind for telling that? We should also tell the
> orientation of the panel:
> 
> EVM	VGA	omapfb.rotate=3
> LDP	QVGA	omapfb.rotate=0
> 
> Do you have something in mind for that?

Hmm, right. I guess all we can do is have boolean flags in the .dts for
MO, LR and UD, which tells if the respective pins are hard-wires high or
low. And say in the documentation that you must either have a proper
GPIO, or use the flag, but not both.

The panel mounting orientation is a different matter. But I think it is
also something we should specify in the .dts. However, we don't have any
SW support to handle it, and it's a bit unclear to me how it should be
handled, so I think that has to be left for later.

>> At the moment our display drivers are OMAP specific, and for that reason
>> we should prefix the compatible strings with "omapdss,". For example,
>> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
>>
>> 	{ .compatible = "omapdss,panel-dsi-cm", },
>>
>> But we should still have the right compatible string in the .dts, so we
>> convert the compatible name in arch/arm/mach-omap2/display.c, with
>> 'dss_compat_conv_list' array, to which this panel's name should be added.
> 
> Oh so what do you want to have in the .dts file then?

The .dts should have the proper names. The idea of this hackery is that
in the .dts we can have the proper compatible string. So in the .dts, we
have, say:

"sony,panel-foobar"

Then, at boot time, omap's platform code changes that to:

"omapdss,sony,panel-foobar".

And our (omap specific) panel-foobar driver use that
"omapdss,sony,panel-foobar" string.

This way some other platform could do the same, and have their platform
specific drivers handle the panel.

At some point in the future we hopefully will have common panel drivers,
and at that point we can remove that hackery. The .dts files will
already be correct.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Javier Martinez Canillas]

Hello Tomi,

On Mon, May 12, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 09/05/14 18:55, Tony Lindgren wrote:
>
>>> Although if the MO gpio is not controlled by the driver, we should tell
>>> the driver whether that gpio is high or low.
>>
>> What do you have in mind for telling that? We should also tell the
>> orientation of the panel:
>>
>> EVM   VGA     omapfb.rotate=3
>> LDP   QVGA    omapfb.rotate=0
>>
>> Do you have something in mind for that?
>
> Hmm, right. I guess all we can do is have boolean flags in the .dts for
> MO, LR and UD, which tells if the respective pins are hard-wires high or
> low. And say in the documentation that you must either have a proper
> GPIO, or use the flag, but not both.
>
> The panel mounting orientation is a different matter. But I think it is
> also something we should specify in the .dts. However, we don't have any
> SW support to handle it, and it's a bit unclear to me how it should be
> handled, so I think that has to be left for later.
>
>>> At the moment our display drivers are OMAP specific, and for that reason
>>> we should prefix the compatible strings with "omapdss,". For example,
>>> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
>>>
>>>      { .compatible = "omapdss,panel-dsi-cm", },
>>>
>>> But we should still have the right compatible string in the .dts, so we
>>> convert the compatible name in arch/arm/mach-omap2/display.c, with
>>> 'dss_compat_conv_list' array, to which this panel's name should be added.
>>
>> Oh so what do you want to have in the .dts file then?
>
> The .dts should have the proper names. The idea of this hackery is that
> in the .dts we can have the proper compatible string. So in the .dts, we
> have, say:
>
> "sony,panel-foobar"
>
> Then, at boot time, omap's platform code changes that to:
>
> "omapdss,sony,panel-foobar".
>
> And our (omap specific) panel-foobar driver use that
> "omapdss,sony,panel-foobar" string.
>
> This way some other platform could do the same, and have their platform
> specific drivers handle the panel.
>
> At some point in the future we hopefully will have common panel drivers,
> and at that point we can remove that hackery. The .dts files will
> already be correct.
>

Maybe we can remove this hackery by relying on the fact that a
compatible string can have a set of values that goes from more
specific to more general. So you can have something like:

compatible = "sony,panel-foobar", "omapdss,panel-foobar"

So right now only "omapdss,panel-foobar" will be matched and later
when we have common panel drivers then that driver could handle the
"sony,panel-foobar" compatible string.

Other platforms could do something similar and have

compatible = "sony,panel-foobar", "baz,panel-foobar"

That way you won't break DT backward compatible but still not require
hacks on arch/arm/mach-omap2/display.c.

We do the same for OMAP boards, we now have the following compatible string:

compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";

There isn't a struct machine_desc that matches "isee,omap3-igep0020"
but later if we find that we need some board specific initialization
we could add one without breaking existing DTS. In fact it used to be
a single machine_desc that matched "ti,omap3" for both omap36xx and
omap34xx but later when some DT clocks changes were introduced we
needed to split both SoC families.

>  Tomi
>
>

Best regards,
Javier

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

On 12/05/14 12:34, Javier Martinez Canillas wrote:

> Maybe we can remove this hackery by relying on the fact that a
> compatible string can have a set of values that goes from more
> specific to more general. So you can have something like:
> 
> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
> 
> So right now only "omapdss,panel-foobar" will be matched and later
> when we have common panel drivers then that driver could handle the
> "sony,panel-foobar" compatible string.
> 
> Other platforms could do something similar and have
> 
> compatible = "sony,panel-foobar", "baz,panel-foobar"
> 
> That way you won't break DT backward compatible but still not require
> hacks on arch/arm/mach-omap2/display.c.
> 
> We do the same for OMAP boards, we now have the following compatible string:
> 
> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
> 
> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> but later if we find that we need some board specific initialization
> we could add one without breaking existing DTS. In fact it used to be
> a single machine_desc that matched "ti,omap3" for both omap36xx and
> omap34xx but later when some DT clocks changes were introduced we
> needed to split both SoC families.

I think that's a different thing. "isee,omap3-igep0020" is a proper
compatible string, if the board is "isee,...".  No matter what software
you run, that's correct and fine.

The omapdss case is different, there the "omapdss" points to a sw thing,
it does not describe the hardware. It's only needed as we don't have
proper sw drivers for the devices.

That said, I think what you describe would work. But I would rather keep
the .dts files clean and correct, and keep that hacks hidden inside the
kernel.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Javier Martinez Canillas]

Hello Tomi,

On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/05/14 12:34, Javier Martinez Canillas wrote:
>
>> Maybe we can remove this hackery by relying on the fact that a
>> compatible string can have a set of values that goes from more
>> specific to more general. So you can have something like:
>>
>> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
>>
>> So right now only "omapdss,panel-foobar" will be matched and later
>> when we have common panel drivers then that driver could handle the
>> "sony,panel-foobar" compatible string.
>>
>> Other platforms could do something similar and have
>>
>> compatible = "sony,panel-foobar", "baz,panel-foobar"
>>
>> That way you won't break DT backward compatible but still not require
>> hacks on arch/arm/mach-omap2/display.c.
>>
>> We do the same for OMAP boards, we now have the following compatible string:
>>
>> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>>
>> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
>> but later if we find that we need some board specific initialization
>> we could add one without breaking existing DTS. In fact it used to be
>> a single machine_desc that matched "ti,omap3" for both omap36xx and
>> omap34xx but later when some DT clocks changes were introduced we
>> needed to split both SoC families.
>
> I think that's a different thing. "isee,omap3-igep0020" is a proper
> compatible string, if the board is "isee,...".  No matter what software
> you run, that's correct and fine.
>
> The omapdss case is different, there the "omapdss" points to a sw thing,
> it does not describe the hardware. It's only needed as we don't have
> proper sw drivers for the devices.
>
> That said, I think what you describe would work. But I would rather keep
> the .dts files clean and correct, and keep that hacks hidden inside the
> kernel.
>

Thanks for the explanation. Since DT are meant to describe hardware
and not software I agree with you that we shouldn't leak an
implementation detail to the DeviceTrees.

And after all fortunately we don't have a stable API in the kernel
like the one that is enforced in the DT so we can fix it later ;-)

>  Tomi
>
>

Bets regards,
Javier

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140512 03:01]:
> Hello Tomi,
> 
> On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 12/05/14 12:34, Javier Martinez Canillas wrote:
> >
> >> Maybe we can remove this hackery by relying on the fact that a
> >> compatible string can have a set of values that goes from more
> >> specific to more general. So you can have something like:
> >>
> >> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
> >>
> >> So right now only "omapdss,panel-foobar" will be matched and later
> >> when we have common panel drivers then that driver could handle the
> >> "sony,panel-foobar" compatible string.
> >>
> >> Other platforms could do something similar and have
> >>
> >> compatible = "sony,panel-foobar", "baz,panel-foobar"
> >>
> >> That way you won't break DT backward compatible but still not require
> >> hacks on arch/arm/mach-omap2/display.c.
> >>
> >> We do the same for OMAP boards, we now have the following compatible string:
> >>
> >> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
> >>
> >> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> >> but later if we find that we need some board specific initialization
> >> we could add one without breaking existing DTS. In fact it used to be
> >> a single machine_desc that matched "ti,omap3" for both omap36xx and
> >> omap34xx but later when some DT clocks changes were introduced we
> >> needed to split both SoC families.
> >
> > I think that's a different thing. "isee,omap3-igep0020" is a proper
> > compatible string, if the board is "isee,...".  No matter what software
> > you run, that's correct and fine.
> >
> > The omapdss case is different, there the "omapdss" points to a sw thing,
> > it does not describe the hardware. It's only needed as we don't have
> > proper sw drivers for the devices.
> >
> > That said, I think what you describe would work. But I would rather keep
> > the .dts files clean and correct, and keep that hacks hidden inside the
> > kernel.
> >
> 
> Thanks for the explanation. Since DT are meant to describe hardware
> and not software I agree with you that we shouldn't leak an
> implementation detail to the DeviceTrees.
> 
> And after all fortunately we don't have a stable API in the kernel
> like the one that is enforced in the DT so we can fix it later ;-)

This remapping of compatible flags sounds smelly to me, please discuss
it first with the device tree people.

I think we're better off just using the compatible properties limited
to the simple-panel.txt for now and actually describe the real
hardware. The fact that the panel is connected to DSS should be possible
to find out based on the phandles.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

On 12/05/14 17:26, Tony Lindgren wrote:

>>> The omapdss case is different, there the "omapdss" points to a sw thing,
>>> it does not describe the hardware. It's only needed as we don't have
>>> proper sw drivers for the devices.
>>>
>>> That said, I think what you describe would work. But I would rather keep
>>> the .dts files clean and correct, and keep that hacks hidden inside the
>>> kernel.
>>>
>>
>> Thanks for the explanation. Since DT are meant to describe hardware
>> and not software I agree with you that we shouldn't leak an
>> implementation detail to the DeviceTrees.
>>
>> And after all fortunately we don't have a stable API in the kernel
>> like the one that is enforced in the DT so we can fix it later ;-)
> 
> This remapping of compatible flags sounds smelly to me, please discuss
> it first with the device tree people.

It's already in v3.15.

I agree it's smelly, but it smelly only inside the kernel, not visible
anywhere, and we can remove it when we have common panel drivers,
without any modifications to .dts files.

> I think we're better off just using the compatible properties limited
> to the simple-panel.txt for now and actually describe the real
> hardware. The fact that the panel is connected to DSS should be possible
> to find out based on the phandles.

I'm not sure what you mean. We do describe only the real hardware. The
compatible string in the .dts file is "sharp,ls037v7dw01".

Prepending the "omapdss" to the compatible string is required for the
device/driver matching to work, because we can't use the
"sharp,ls037v7dw01" compatible string in our omap specific panel driver.

I'm not sure what it would give us to try to be compatible with
simple-panel.txt. The simple-panel bindings won't probably be compatible
with the future common display drivers in any case, as the simple-panel
binding is just too limited and doesn't describe the hardware fully.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:55]:
> On 12/05/14 17:26, Tony Lindgren wrote:
> 
> >>> The omapdss case is different, there the "omapdss" points to a sw thing,
> >>> it does not describe the hardware. It's only needed as we don't have
> >>> proper sw drivers for the devices.
> >>>
> >>> That said, I think what you describe would work. But I would rather keep
> >>> the .dts files clean and correct, and keep that hacks hidden inside the
> >>> kernel.
> >>>
> >>
> >> Thanks for the explanation. Since DT are meant to describe hardware
> >> and not software I agree with you that we shouldn't leak an
> >> implementation detail to the DeviceTrees.
> >>
> >> And after all fortunately we don't have a stable API in the kernel
> >> like the one that is enforced in the DT so we can fix it later ;-)
> > 
> > This remapping of compatible flags sounds smelly to me, please discuss
> > it first with the device tree people.
> 
> It's already in v3.15.

Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
even acked it :( Looks like there's also the custom mux hacks. And
custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
_any_ new crap into arch/arm/mach-omap2/display.c.

So please consider this a huge eternal NAK to add any more crap to
arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
the soc_is_am43xx() you have in linux next. No more adding 
of_find_compatible_node() beyond ti,omap5-dss you have in linux next.

And no more new panel remapping in this file as soon as you have found
a better solution. Preferrably by v3.17 merge window. This file just
needs to disappear. Yuk.

> I agree it's smelly, but it smelly only inside the kernel, not visible
> anywhere, and we can remove it when we have common panel drivers,
> without any modifications to .dts files.
> 
> > I think we're better off just using the compatible properties limited
> > to the simple-panel.txt for now and actually describe the real
> > hardware. The fact that the panel is connected to DSS should be possible
> > to find out based on the phandles.
> 
> I'm not sure what you mean. We do describe only the real hardware. The
> compatible string in the .dts file is "sharp,ls037v7dw01".
> 
> Prepending the "omapdss" to the compatible string is required for the
> device/driver matching to work, because we can't use the
> "sharp,ls037v7dw01" compatible string in our omap specific panel driver.
> 
> I'm not sure what it would give us to try to be compatible with
> simple-panel.txt. The simple-panel bindings won't probably be compatible
> with the future common display drivers in any case, as the simple-panel
> binding is just too limited and doesn't describe the hardware fully.

Hmm what else does a panel need where the existing binding cannot be
extended? 

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3806 bytes --]

On 12/05/14 18:51, Tony Lindgren wrote:

>> It's already in v3.15.
> 
> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
> even acked it :( Looks like there's also the custom mux hacks. And
> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add

The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
omap_display_init stuff can be removed when the DT conversion has been done.

For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
discussed) I still have no solution, but I haven't spent time on it. I
have dropped the omap5 dsi muxing from the latest series for that reason.

dispc_disable_outputs and omap_dss_reset are needed because omap_device
doesn't handle resetting DSS properly, as special steps need to be done
for that. omap_dss_reset is called from the hwmod/omap_device code, so I
don't think this code can be anywhere else.

For the omap_display_get_version() I have no good solution. Making
separate .dts versions for all the needed OMAP ES versions seems like a
huge hassle to me, but that is one solution.

I think that would mean having separate .dtsi files for omapdss for
omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
having separate omapxxxx.dtsi files for all of those, and then separate
board .dts files for the ES versions used on each board.

Or is there some sane way to define such things in dts?

> _any_ new crap into arch/arm/mach-omap2/display.c.
> 
> So please consider this a huge eternal NAK to add any more crap to
> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
> the soc_is_am43xx() you have in linux next. No more adding 
> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
> 
> And no more new panel remapping in this file as soon as you have found
> a better solution. Preferrably by v3.17 merge window. This file just
> needs to disappear. Yuk.

Do you object to the compatible string remapping as such, or just that
it's in arch/arm/mach-omap2?

I guess nothing prevents me from moving it to drivers/, and having some
early-ish initcall doing the job.

If the remapping as such is horrible, I'm all ears for better ideas. I
spent quite a lot of time on it, and that's the best I could come up with.

It's rather simple prefixing of the compatible strings for selected
devices. The purpose of that is to have proper data in the .dts files
(which I think is very important) with the cost of having some rather
simple internal hacks in the kernel, which can be removed immediately
when we have a common display driver framework.

>> I'm not sure what it would give us to try to be compatible with
>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>> with the future common display drivers in any case, as the simple-panel
>> binding is just too limited and doesn't describe the hardware fully.
> 
> Hmm what else does a panel need where the existing binding cannot be
> extended? 

The existing simple-panel binding doesn't describe the connections of
the panel, i.e. its video input. I guess it can be extended, but I don't
see what the benefit is of trying to create new panel bindings
compatible with the simple-panel bindings. As I see, the simple-panel
bindings work only with very limited use cases, where the drivers make
assumptions. Simple panel bindings cannot be used with omapdss, nor can
it be used with the future common display framework.

But I'm not really familiar with using extending current bindings, and
making new bindings compatible with old ones. Can you explain why it'd
be good to have the sharp panel bindings compatible with simple-panel?
In what kind of scenario would it be used?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Javier Martinez Canillas]

On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/05/14 18:51, Tony Lindgren wrote:
>
>>> It's already in v3.15.
>>
>> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
>> even acked it :( Looks like there's also the custom mux hacks. And
>> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
>
> The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
> omap_display_init stuff can be removed when the DT conversion has been done.
>
> For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
> discussed) I still have no solution, but I haven't spent time on it. I
> have dropped the omap5 dsi muxing from the latest series for that reason.
>
> dispc_disable_outputs and omap_dss_reset are needed because omap_device
> doesn't handle resetting DSS properly, as special steps need to be done
> for that. omap_dss_reset is called from the hwmod/omap_device code, so I
> don't think this code can be anywhere else.
>
> For the omap_display_get_version() I have no good solution. Making
> separate .dts versions for all the needed OMAP ES versions seems like a
> huge hassle to me, but that is one solution.
>
> I think that would mean having separate .dtsi files for omapdss for
> omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
> having separate omapxxxx.dtsi files for all of those, and then separate
> board .dts files for the ES versions used on each board.
>
> Or is there some sane way to define such things in dts?
>

Unfortunately there isn't.

I have a similar problem with the IGEP boards since there are just too
many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs
OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi
chip, etc).

Since dts are supposed to describe the hardware, each revision with a
slighter variation forces to have a different dts. My solution was to
not try to have a dts for every single variation in mainline but only
one for the most common revision and that could be used as a reference
to modify and ship on each device. Unfortunately that is not possible
to you since each DSS IP block is used by many boards.

>> _any_ new crap into arch/arm/mach-omap2/display.c.
>>
>> So please consider this a huge eternal NAK to add any more crap to
>> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
>> the soc_is_am43xx() you have in linux next. No more adding
>> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
>>
>> And no more new panel remapping in this file as soon as you have found
>> a better solution. Preferrably by v3.17 merge window. This file just
>> needs to disappear. Yuk.
>
> Do you object to the compatible string remapping as such, or just that
> it's in arch/arm/mach-omap2?
>
> I guess nothing prevents me from moving it to drivers/, and having some
> early-ish initcall doing the job.
>
> If the remapping as such is horrible, I'm all ears for better ideas. I
> spent quite a lot of time on it, and that's the best I could come up with.
>
> It's rather simple prefixing of the compatible strings for selected
> devices. The purpose of that is to have proper data in the .dts files
> (which I think is very important) with the cost of having some rather
> simple internal hacks in the kernel, which can be removed immediately
> when we have a common display driver framework.
>

Even though the compatible trick that I said before could be an
alternative, it has the problem that does not describes the hardware
as you said. The restriction of the DT being a stable API and get it
right from the beginning forces us to make these kind of technical
decisions.

So, since we can change the kernel later but not the DTS, I agree with
you that the remapping is the least bad of our options.

>>> I'm not sure what it would give us to try to be compatible with
>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>>> with the future common display drivers in any case, as the simple-panel
>>> binding is just too limited and doesn't describe the hardware fully.
>>
>> Hmm what else does a panel need where the existing binding cannot be
>> extended?
>
> The existing simple-panel binding doesn't describe the connections of
> the panel, i.e. its video input. I guess it can be extended, but I don't
> see what the benefit is of trying to create new panel bindings
> compatible with the simple-panel bindings. As I see, the simple-panel
> bindings work only with very limited use cases, where the drivers make
> assumptions. Simple panel bindings cannot be used with omapdss, nor can
> it be used with the future common display framework.
>
> But I'm not really familiar with using extending current bindings, and
> making new bindings compatible with old ones. Can you explain why it'd
> be good to have the sharp panel bindings compatible with simple-panel?
> In what kind of scenario would it be used?
>
>  Tomi
>
>

Best regards,
Javier

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140513 04:40]:
> On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 12/05/14 18:51, Tony Lindgren wrote:
> >
> >>> It's already in v3.15.
> >>
> >> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
> >> even acked it :( Looks like there's also the custom mux hacks. And
> >> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
> >
> > The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
> > omap_display_init stuff can be removed when the DT conversion has been done.

Yes great that helps :)

> > For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
> > discussed) I still have no solution, but I haven't spent time on it. I
> > have dropped the omap5 dsi muxing from the latest series for that reason.

OK

> > dispc_disable_outputs and omap_dss_reset are needed because omap_device
> > doesn't handle resetting DSS properly, as special steps need to be done
> > for that. omap_dss_reset is called from the hwmod/omap_device code, so I
> > don't think this code can be anywhere else.

OK that we should be able to do with drivers/reset eventually. The reset
and idle of drivers is also needed for unused devices too, so we can't
have drivers do it in those cases.

> > For the omap_display_get_version() I have no good solution. Making
> > separate .dts versions for all the needed OMAP ES versions seems like a
> > huge hassle to me, but that is one solution.
> >
> > I think that would mean having separate .dtsi files for omapdss for
> > omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
> > having separate omapxxxx.dtsi files for all of those, and then separate
> > board .dts files for the ES versions used on each board.
> >
> > Or is there some sane way to define such things in dts?
> >
> 
> Unfortunately there isn't.
> 
> I have a similar problem with the IGEP boards since there are just too
> many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs
> OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi
> chip, etc).
> 
> Since dts are supposed to describe the hardware, each revision with a
> slighter variation forces to have a different dts. My solution was to
> not try to have a dts for every single variation in mainline but only
> one for the most common revision and that could be used as a reference
> to modify and ship on each device. Unfortunately that is not possible
> to you since each DSS IP block is used by many boards.

Well ideally the revision info for a device would come from device
revision registers rather using the SoC revision. In the DSS case when
the SoC revision is needed by a device it maybe it can be deciphered
from a combination of compatible flag and the clock rate for example?

But yeah I agree we still need revision detection in the kernel
rather than try to create separate .dtsi files for sub-revisions.
 
> >> _any_ new crap into arch/arm/mach-omap2/display.c.
> >>
> >> So please consider this a huge eternal NAK to add any more crap to
> >> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
> >> the soc_is_am43xx() you have in linux next. No more adding
> >> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
> >>
> >> And no more new panel remapping in this file as soon as you have found
> >> a better solution. Preferrably by v3.17 merge window. This file just
> >> needs to disappear. Yuk.
> >
> > Do you object to the compatible string remapping as such, or just that
> > it's in arch/arm/mach-omap2?

It's something I'd rather not have under mach-omap2 as that means that
I may need to deal with it too to some extent. And I don't think we
need to do such remapping, we should be able to use the panel compatible
strings as they are just fine. It should be possible to figure out from
the device tree properties what controller the panel belongs to. Or
for now, use the panel registration to figure out what display controller
it belongs to.

> > I guess nothing prevents me from moving it to drivers/, and having some
> > early-ish initcall doing the job.

/me likes this idea if you need it at all. Stuff like this tends to stay
and spread, so I'd rather not do the remapping of compatible strings at
all.

> > If the remapping as such is horrible, I'm all ears for better ideas. I
> > spent quite a lot of time on it, and that's the best I could come up with.
> >
> > It's rather simple prefixing of the compatible strings for selected
> > devices. The purpose of that is to have proper data in the .dts files
> > (which I think is very important) with the cost of having some rather
> > simple internal hacks in the kernel, which can be removed immediately
> > when we have a common display driver framework.
> >
> 
> Even though the compatible trick that I said before could be an
> alternative, it has the problem that does not describes the hardware
> as you said. The restriction of the DT being a stable API and get it
> right from the beginning forces us to make these kind of technical
> decisions.
> 
> So, since we can change the kernel later but not the DTS, I agree with
> you that the remapping is the least bad of our options.

Yes the binding for the panel should just describe the panel so it can be
used with whatever display controller. But we do have quite a few buses
probing devices. How about set up the panel probing the same way?

For the panels on display controller, just do the usual
for_each_child_of_node(pdev->dev.of_node, child) and probe them?

It seems the remapping of compatible strings is not needed in this
as we're only picking up panels that are children of the display
controller.
 
> >>> I'm not sure what it would give us to try to be compatible with
> >>> simple-panel.txt. The simple-panel bindings won't probably be compatible
> >>> with the future common display drivers in any case, as the simple-panel
> >>> binding is just too limited and doesn't describe the hardware fully.
> >>
> >> Hmm what else does a panel need where the existing binding cannot be
> >> extended?
> >
> > The existing simple-panel binding doesn't describe the connections of
> > the panel, i.e. its video input. I guess it can be extended, but I don't
> > see what the benefit is of trying to create new panel bindings
> > compatible with the simple-panel bindings. As I see, the simple-panel
> > bindings work only with very limited use cases, where the drivers make
> > assumptions. Simple panel bindings cannot be used with omapdss, nor can
> > it be used with the future common display framework.

Well it seems at least the reset and enable pin standard from that
binding can be kept.

> > But I'm not really familiar with using extending current bindings, and
> > making new bindings compatible with old ones. Can you explain why it'd
> > be good to have the sharp panel bindings compatible with simple-panel?
> > In what kind of scenario would it be used?

Ideally the panel binding just describes the panel and it should not
matter which display controller it is a child of.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]

On 13/05/14 18:25, Tony Lindgren wrote:

> Well ideally the revision info for a device would come from device
> revision registers rather using the SoC revision. In the DSS case when
> the SoC revision is needed by a device it maybe it can be deciphered
> from a combination of compatible flag and the clock rate for example?

I've been trying that. The HW guys didn't bother to update the DSS
revision registers, so they are useless. And, for example, the OMAP3 ES
difference is only about bitfield widths in two registers.

I tried writing "too long" value to the register on the earlier ES
version, hoping that the extra bits would be kept at zero, but that
wasn't the case. So I just don't see a way to detect this from the DSS's
point of view.

>>> Do you object to the compatible string remapping as such, or just that
>>> it's in arch/arm/mach-omap2?
> 
> It's something I'd rather not have under mach-omap2 as that means that
> I may need to deal with it too to some extent. And I don't think we
> need to do such remapping, we should be able to use the panel compatible
> strings as they are just fine. It should be possible to figure out from
> the device tree properties what controller the panel belongs to. Or
> for now, use the panel registration to figure out what display controller
> it belongs to.
> 
>>> I guess nothing prevents me from moving it to drivers/, and having some
>>> early-ish initcall doing the job.
> 
> /me likes this idea if you need it at all. Stuff like this tends to stay
> and spread, so I'd rather not do the remapping of compatible strings at
> all.

Yep. I'll look to this. Thinking about it now, it kind of makes more
sense to have it in the omapdss's directory.

>> So, since we can change the kernel later but not the DTS, I agree with
>> you that the remapping is the least bad of our options.
> 
> Yes the binding for the panel should just describe the panel so it can be
> used with whatever display controller. But we do have quite a few buses
> probing devices. How about set up the panel probing the same way?

> For the panels on display controller, just do the usual
> for_each_child_of_node(pdev->dev.of_node, child) and probe them?
>
> It seems the remapping of compatible strings is not needed in this
> as we're only picking up panels that are children of the display
> controller.

The panels (or display encoders) are not (usually) children of the
display controller. They are children of their respective control bus.
Say, an i2c panel is a child of i2c bus. If there's no control bus, like
is the case with the sharp panel, it's a platform device.

The video paths of the panels and encoders are connected using the v4l2
style ports/endpoints. We can use those to see what display controller a
panel is connected to, but only after the panel driver has already
probed. We don't have control for the actual probing, as that happens
with whatever the control bus is for the display component.

>>>>> I'm not sure what it would give us to try to be compatible with
>>>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>>>>> with the future common display drivers in any case, as the simple-panel
>>>>> binding is just too limited and doesn't describe the hardware fully.
>>>>
>>>> Hmm what else does a panel need where the existing binding cannot be
>>>> extended?
>>>
>>> The existing simple-panel binding doesn't describe the connections of
>>> the panel, i.e. its video input. I guess it can be extended, but I don't
>>> see what the benefit is of trying to create new panel bindings
>>> compatible with the simple-panel bindings. As I see, the simple-panel
>>> bindings work only with very limited use cases, where the drivers make
>>> assumptions. Simple panel bindings cannot be used with omapdss, nor can
>>> it be used with the future common display framework.
> 
> Well it seems at least the reset and enable pin standard from that
> binding can be kept.

Only enable gpio there. But even that's vague. Do you turn on the power
before or after setting the enable gpio? How long delay should be
between the power and the gpio? Different panels have different rules
for the power-up.

>>> But I'm not really familiar with using extending current bindings, and
>>> making new bindings compatible with old ones. Can you explain why it'd
>>> be good to have the sharp panel bindings compatible with simple-panel?
>>> In what kind of scenario would it be used?
> 
> Ideally the panel binding just describes the panel and it should not
> matter which display controller it is a child of.

Yes, but that means the panel bindings need to have enough information
so that all display controllers can use it. Simple-panel bindings do not
have enough information. The simple-panel bindings do not have
information about the video bus input, and it doesn't even have
information about the resolution or bitdepth of the panel.

So I'm still asking, if we create sharp bindings that use the same
properties as the simple-panel bindings, and define that sharp panel is
compatible with simple-panel, what kind of scenario in practice would it
be used in?

Would the scenario be some other OS, that doesn't have a driver for the
sharp panel, but has a driver for the simple-panel? That would only work
if the sharp panel hardware is setup so that only the enable gpio is
needed, so that quite a narrow definition of "compatible".

Or is there some other scenario in which it could be used?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140513 23:20]:
> On 13/05/14 18:25, Tony Lindgren wrote:
> 
> > Well ideally the revision info for a device would come from device
> > revision registers rather using the SoC revision. In the DSS case when
> > the SoC revision is needed by a device it maybe it can be deciphered
> > from a combination of compatible flag and the clock rate for example?
> 
> I've been trying that. The HW guys didn't bother to update the DSS
> revision registers, so they are useless. And, for example, the OMAP3 ES
> difference is only about bitfield widths in two registers.
> 
> I tried writing "too long" value to the register on the earlier ES
> version, hoping that the extra bits would be kept at zero, but that
> wasn't the case. So I just don't see a way to detect this from the DSS's
> point of view.
> 
> >>> Do you object to the compatible string remapping as such, or just that
> >>> it's in arch/arm/mach-omap2?
> > 
> > It's something I'd rather not have under mach-omap2 as that means that
> > I may need to deal with it too to some extent. And I don't think we
> > need to do such remapping, we should be able to use the panel compatible
> > strings as they are just fine. It should be possible to figure out from
> > the device tree properties what controller the panel belongs to. Or
> > for now, use the panel registration to figure out what display controller
> > it belongs to.
> > 
> >>> I guess nothing prevents me from moving it to drivers/, and having some
> >>> early-ish initcall doing the job.
> > 
> > /me likes this idea if you need it at all. Stuff like this tends to stay
> > and spread, so I'd rather not do the remapping of compatible strings at
> > all.
> 
> Yep. I'll look to this. Thinking about it now, it kind of makes more
> sense to have it in the omapdss's directory.

OK thanks.
 
> >> So, since we can change the kernel later but not the DTS, I agree with
> >> you that the remapping is the least bad of our options.
> > 
> > Yes the binding for the panel should just describe the panel so it can be
> > used with whatever display controller. But we do have quite a few buses
> > probing devices. How about set up the panel probing the same way?
> 
> > For the panels on display controller, just do the usual
> > for_each_child_of_node(pdev->dev.of_node, child) and probe them?
> >
> > It seems the remapping of compatible strings is not needed in this
> > as we're only picking up panels that are children of the display
> > controller.
> 
> The panels (or display encoders) are not (usually) children of the
> display controller. They are children of their respective control bus.
> Say, an i2c panel is a child of i2c bus. If there's no control bus, like
> is the case with the sharp panel, it's a platform device.

OK
 
> The video paths of the panels and encoders are connected using the v4l2
> style ports/endpoints. We can use those to see what display controller a
> panel is connected to, but only after the panel driver has already
> probed. We don't have control for the actual probing, as that happens
> with whatever the control bus is for the display component.

OK. So with generic panels, you can just let the panels probe with
the right compatible flag then and let the ports/endpoints registration
to figure out if the panel is usable for the display controller in
question.

> >>>>> I'm not sure what it would give us to try to be compatible with
> >>>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
> >>>>> with the future common display drivers in any case, as the simple-panel
> >>>>> binding is just too limited and doesn't describe the hardware fully.
> >>>>
> >>>> Hmm what else does a panel need where the existing binding cannot be
> >>>> extended?
> >>>
> >>> The existing simple-panel binding doesn't describe the connections of
> >>> the panel, i.e. its video input. I guess it can be extended, but I don't
> >>> see what the benefit is of trying to create new panel bindings
> >>> compatible with the simple-panel bindings. As I see, the simple-panel
> >>> bindings work only with very limited use cases, where the drivers make
> >>> assumptions. Simple panel bindings cannot be used with omapdss, nor can
> >>> it be used with the future common display framework.
> > 
> > Well it seems at least the reset and enable pin standard from that
> > binding can be kept.
> 
> Only enable gpio there. But even that's vague. Do you turn on the power
> before or after setting the enable gpio? How long delay should be
> between the power and the gpio? Different panels have different rules
> for the power-up.

Sure, it's a complex problem. But for the enable gpio..

Maybe the enable GPIO should be treated as a regulator? That would allow
specifying first the source regulator startup delay, and then the
panel has it's own startup delay.
 
> >>> But I'm not really familiar with using extending current bindings, and
> >>> making new bindings compatible with old ones. Can you explain why it'd
> >>> be good to have the sharp panel bindings compatible with simple-panel?
> >>> In what kind of scenario would it be used?
> > 
> > Ideally the panel binding just describes the panel and it should not
> > matter which display controller it is a child of.
> 
> Yes, but that means the panel bindings need to have enough information
> so that all display controllers can use it. Simple-panel bindings do not
> have enough information. The simple-panel bindings do not have
> information about the video bus input, and it doesn't even have
> information about the resolution or bitdepth of the panel.

Some of that you can hide into the panel driver based on the compatible
flag. So why not already do something like this in the .dts files
instead of the remapping:

compatible = "sharp,ls037v7dw01-omap-dss", "sharp,ls037v7dw01"; 

And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
would only claim to be compatible with "sharp,ls037v7dw01-omap-dss".

Then when the common panel framework is available, you can stop
parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need
to be changed and it's fine to keep "sharp,ls037v7dw01-omap-dss"
in the .dts files.
 
> So I'm still asking, if we create sharp bindings that use the same
> properties as the simple-panel bindings, and define that sharp panel is
> compatible with simple-panel, what kind of scenario in practice would it
> be used in?

Well with the above example, just by dss with "sharp,ls037v7dw01-omap-dss"
until some other SoC notices it can use the GPIO parts of the panel
code at least :)
 
> Would the scenario be some other OS, that doesn't have a driver for the
> sharp panel, but has a driver for the simple-panel? That would only work
> if the sharp panel hardware is setup so that only the enable gpio is
> needed, so that quite a narrow definition of "compatible".

That's where we can use the compatible flags and just avoid parsing
the generic compatible flag unless some common framework is available.
 
> Or is there some other scenario in which it could be used?

I guess other OS or other SoC with a different display controller
but the same panel.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 5274 bytes --]

On 14/05/14 19:02, Tony Lindgren wrote:

>> The video paths of the panels and encoders are connected using the v4l2
>> style ports/endpoints. We can use those to see what display controller a
>> panel is connected to, but only after the panel driver has already
>> probed. We don't have control for the actual probing, as that happens
>> with whatever the control bus is for the display component.
> 
> OK. So with generic panels, you can just let the panels probe with
> the right compatible flag then and let the ports/endpoints registration
> to figure out if the panel is usable for the display controller in
> question.

I'm not sure what you mean here.

Do you mean with the future common display framework? There's no need to
figure out anything there, as supposedly the .dts has been written
correctly and the panel and the display controller work together.

If you mean with the current kernel, there's still nothing to figure
out. We can have only single driver with a particular compatible string.
And as our current drivers are omap specific, it makes sense to have
their compatible string be something omap-ish. And if the .dts file
connects the display controller and the panel, then they must be usable
together.

>>> Well it seems at least the reset and enable pin standard from that
>>> binding can be kept.
>>
>> Only enable gpio there. But even that's vague. Do you turn on the power
>> before or after setting the enable gpio? How long delay should be
>> between the power and the gpio? Different panels have different rules
>> for the power-up.
> 
> Sure, it's a complex problem. But for the enable gpio..
> 
> Maybe the enable GPIO should be treated as a regulator? That would allow
> specifying first the source regulator startup delay, and then the
> panel has it's own startup delay.

Well... I don't know. Sounds rather hacky to me. We have the option to
have a specific driver for this panel, and that driver can handle all
the delays and power-up sequences just right in a clean manner.

>>>>> But I'm not really familiar with using extending current bindings, and
>>>>> making new bindings compatible with old ones. Can you explain why it'd
>>>>> be good to have the sharp panel bindings compatible with simple-panel?
>>>>> In what kind of scenario would it be used?
>>>
>>> Ideally the panel binding just describes the panel and it should not
>>> matter which display controller it is a child of.
>>
>> Yes, but that means the panel bindings need to have enough information
>> so that all display controllers can use it. Simple-panel bindings do not
>> have enough information. The simple-panel bindings do not have
>> information about the video bus input, and it doesn't even have
>> information about the resolution or bitdepth of the panel.
> 
> Some of that you can hide into the panel driver based on the compatible
> flag. So why not already do something like this in the .dts files
> instead of the remapping:
> 
> compatible = "sharp,ls037v7dw01-omap-dss", "sharp,ls037v7dw01"; 
> 
> And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
> would only claim to be compatible with "sharp,ls037v7dw01-omap-dss".
> 
> Then when the common panel framework is available, you can stop
> parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need
> to be changed and it's fine to keep "sharp,ls037v7dw01-omap-dss"
> in the .dts files.

Hmm, I don't see how this relates to the simple-panel bindings.

But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
alternative for the compatible-string conversion we do now. I guess it's
a matter of taste, but I rather hide it inside the kernel, in an
internal omapdss file, than pollute the .dts files with those compatible
strings.

>> So I'm still asking, if we create sharp bindings that use the same
>> properties as the simple-panel bindings, and define that sharp panel is
>> compatible with simple-panel, what kind of scenario in practice would it
>> be used in?
> 
> Well with the above example, just by dss with "sharp,ls037v7dw01-omap-dss"
> until some other SoC notices it can use the GPIO parts of the panel
> code at least :)
>  
>> Would the scenario be some other OS, that doesn't have a driver for the
>> sharp panel, but has a driver for the simple-panel? That would only work
>> if the sharp panel hardware is setup so that only the enable gpio is
>> needed, so that quite a narrow definition of "compatible".
> 
> That's where we can use the compatible flags and just avoid parsing
> the generic compatible flag unless some common framework is available.

Hmm, sorry, I don't follow. My question was about the simple-panel
bindings, not common display framework.

You were saying that the sharp bindings should be compatible with
simple-panel bindings. I'm still trying to understand what benefit does
that give us.

As I see it, the sharp panel could be used with the simple-panel
bindings only in certain special case, where all the mode pins and the
reset are hardwired in the board hardware, and they are hardwired in a
certain state (all hardwired low, probably), which matches what the
simple-panel driver expects.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 02:24]:
> On 14/05/14 19:02, Tony Lindgren wrote:
> 
> >> The video paths of the panels and encoders are connected using the v4l2
> >> style ports/endpoints. We can use those to see what display controller a
> >> panel is connected to, but only after the panel driver has already
> >> probed. We don't have control for the actual probing, as that happens
> >> with whatever the control bus is for the display component.
> > 
> > OK. So with generic panels, you can just let the panels probe with
> > the right compatible flag then and let the ports/endpoints registration
> > to figure out if the panel is usable for the display controller in
> > question.
> 
> I'm not sure what you mean here.
> 
> Do you mean with the future common display framework? There's no need to
> figure out anything there, as supposedly the .dts has been written
> correctly and the panel and the display controller work together.

OK. Yes I meant for future use.
 
> If you mean with the current kernel, there's still nothing to figure
> out. We can have only single driver with a particular compatible string.
> And as our current drivers are omap specific, it makes sense to have
> their compatible string be something omap-ish. And if the .dts file
> connects the display controller and the panel, then they must be usable
> together.

Yup.
 
> >>> Well it seems at least the reset and enable pin standard from that
> >>> binding can be kept.
> >>
> >> Only enable gpio there. But even that's vague. Do you turn on the power
> >> before or after setting the enable gpio? How long delay should be
> >> between the power and the gpio? Different panels have different rules
> >> for the power-up.
> > 
> > Sure, it's a complex problem. But for the enable gpio..
> > 
> > Maybe the enable GPIO should be treated as a regulator? That would allow
> > specifying first the source regulator startup delay, and then the
> > panel has it's own startup delay.
> 
> Well... I don't know. Sounds rather hacky to me. We have the option to
> have a specific driver for this panel, and that driver can handle all
> the delays and power-up sequences just right in a clean manner.

I guess we could have a generic startup-latency property for the GPIOs.
 
> >>>>> But I'm not really familiar with using extending current bindings, and
> >>>>> making new bindings compatible with old ones. Can you explain why it'd
> >>>>> be good to have the sharp panel bindings compatible with simple-panel?
> >>>>> In what kind of scenario would it be used?
> >>>
> >>> Ideally the panel binding just describes the panel and it should not
> >>> matter which display controller it is a child of.
> >>
> >> Yes, but that means the panel bindings need to have enough information
> >> so that all display controllers can use it. Simple-panel bindings do not
> >> have enough information. The simple-panel bindings do not have
> >> information about the video bus input, and it doesn't even have
> >> information about the resolution or bitdepth of the panel.
> > 
> > Some of that you can hide into the panel driver based on the compatible
> > flag. So why not already do something like this in the .dts files
> > instead of the remapping:
> > 
> > compatible = "sharp,ls037v7dw01-omap-dss", "sharp,ls037v7dw01"; 
> > 
> > And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
> > would only claim to be compatible with "sharp,ls037v7dw01-omap-dss".
> > 
> > Then when the common panel framework is available, you can stop
> > parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need
> > to be changed and it's fine to keep "sharp,ls037v7dw01-omap-dss"
> > in the .dts files.
> 
> Hmm, I don't see how this relates to the simple-panel bindings.
> 
> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> alternative for the compatible-string conversion we do now. I guess it's
> a matter of taste, but I rather hide it inside the kernel, in an
> internal omapdss file, than pollute the .dts files with those compatible
> strings.

Well it avoid you parsing through all the nodes during booting
and leaves out the function to do remapping. And removes the need
for maintaining a custom display mapping table. I'd say that's a
pretty good list of advantages right there :)
 
> >> So I'm still asking, if we create sharp bindings that use the same
> >> properties as the simple-panel bindings, and define that sharp panel is
> >> compatible with simple-panel, what kind of scenario in practice would it
> >> be used in?
> > 
> > Well with the above example, just by dss with "sharp,ls037v7dw01-omap-dss"
> > until some other SoC notices it can use the GPIO parts of the panel
> > code at least :)
> >  
> >> Would the scenario be some other OS, that doesn't have a driver for the
> >> sharp panel, but has a driver for the simple-panel? That would only work
> >> if the sharp panel hardware is setup so that only the enable gpio is
> >> needed, so that quite a narrow definition of "compatible".
> > 
> > That's where we can use the compatible flags and just avoid parsing
> > the generic compatible flag unless some common framework is available.
> 
> Hmm, sorry, I don't follow. My question was about the simple-panel
> bindings, not common display framework.
> 
> You were saying that the sharp bindings should be compatible with
> simple-panel bindings. I'm still trying to understand what benefit does
> that give us.

Oh sorry, for that part I don't really have an opinion. If you think
the simple-panel binding is not going to be usable in the long
run, then I'm fine with whatever binding you display guys come up
with and prefer to use.
 
> As I see it, the sharp panel could be used with the simple-panel
> bindings only in certain special case, where all the mode pins and the
> reset are hardwired in the board hardware, and they are hardwired in a
> certain state (all hardwired low, probably), which matches what the
> simple-panel driver expects.

OK. Maybe take a stab at updating the binding for this as I don't
know what you want to do with it?

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On 15/05/14 21:21, Tony Lindgren wrote:

>> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
>> alternative for the compatible-string conversion we do now. I guess it's
>> a matter of taste, but I rather hide it inside the kernel, in an
>> internal omapdss file, than pollute the .dts files with those compatible
>> strings.
> 
> Well it avoid you parsing through all the nodes during booting
> and leaves out the function to do remapping. And removes the need
> for maintaining a custom display mapping table. I'd say that's a
> pretty good list of advantages right there :)

Yep... I don't know. Maybe I'm being too careful about doing wrong
things with .dts. I just like it more if any hacks are in kernel code,
which I can remove without anyone noticing.

Anyway, we already have board.dts files using the non-omapified
compatible strings in the mainline, so if I would now add the omapified
compatible strings to .dts files, those old board.dts files would break.

So I guess the choice has already been made.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> On 15/05/14 21:21, Tony Lindgren wrote:
> 
> >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> >> alternative for the compatible-string conversion we do now. I guess it's
> >> a matter of taste, but I rather hide it inside the kernel, in an
> >> internal omapdss file, than pollute the .dts files with those compatible
> >> strings.
> > 
> > Well it avoid you parsing through all the nodes during booting
> > and leaves out the function to do remapping. And removes the need
> > for maintaining a custom display mapping table. I'd say that's a
> > pretty good list of advantages right there :)
> 
> Yep... I don't know. Maybe I'm being too careful about doing wrong
> things with .dts. I just like it more if any hacks are in kernel code,
> which I can remove without anyone noticing.
> 
> Anyway, we already have board.dts files using the non-omapified
> compatible strings in the mainline, so if I would now add the omapified
> compatible strings to .dts files, those old board.dts files would break.
> 
> So I guess the choice has already been made.

I really think you should remove this misuse of device tree code ASAP.
It's better to fix it up now than carry the hack for next two years
and keep on adding to it.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > On 15/05/14 21:21, Tony Lindgren wrote:
> > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > >> alternative for the compatible-string conversion we do now. I guess it's
> > >> a matter of taste, but I rather hide it inside the kernel, in an
> > >> internal omapdss file, than pollute the .dts files with those compatible
> > >> strings.
> > > 
> > > Well it avoid you parsing through all the nodes during booting
> > > and leaves out the function to do remapping. And removes the need
> > > for maintaining a custom display mapping table. I'd say that's a
> > > pretty good list of advantages right there :)
> > 
> > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > things with .dts. I just like it more if any hacks are in kernel code,
> > which I can remove without anyone noticing.
> > 
> > Anyway, we already have board.dts files using the non-omapified
> > compatible strings in the mainline, so if I would now add the omapified
> > compatible strings to .dts files, those old board.dts files would break.
> > 
> > So I guess the choice has already been made.
> 
> I really think you should remove this misuse of device tree code ASAP.
> It's better to fix it up now than carry the hack for next two years
> and keep on adding to it.

IMHO appending -omap-dss to a random device is an even bigger hack,
since its adding lots of bloat to the API. Let's assume there is
another OS using DT for ARM, but has no proper API for SPI
controllers and it introduces your hack to SPI devices. That would
mean each SPI device has -omap-spi appended (or -exynos-spi,
-foo-spi, ...). At least I would blame them for creating a huge
unmaintainable mess.

I think Tomi's workaround is a much better hack, since it keeps the
API clean. If the code simply prefixes "omapdss," to all
"child"-devices of omapdss it can be left mostly untouched, too.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > >> strings.
> > > > 
> > > > Well it avoid you parsing through all the nodes during booting
> > > > and leaves out the function to do remapping. And removes the need
> > > > for maintaining a custom display mapping table. I'd say that's a
> > > > pretty good list of advantages right there :)
> > > 
> > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > things with .dts. I just like it more if any hacks are in kernel code,
> > > which I can remove without anyone noticing.
> > > 
> > > Anyway, we already have board.dts files using the non-omapified
> > > compatible strings in the mainline, so if I would now add the omapified
> > > compatible strings to .dts files, those old board.dts files would break.
> > > 
> > > So I guess the choice has already been made.
> > 
> > I really think you should remove this misuse of device tree code ASAP.
> > It's better to fix it up now than carry the hack for next two years
> > and keep on adding to it.
> 
> IMHO appending -omap-dss to a random device is an even bigger hack,
> since its adding lots of bloat to the API. Let's assume there is
> another OS using DT for ARM, but has no proper API for SPI
> controllers and it introduces your hack to SPI devices. That would
> mean each SPI device has -omap-spi appended (or -exynos-spi,
> -foo-spi, ...). At least I would blame them for creating a huge
> unmaintainable mess.

I think you're misunderstanding. I do not want the naming to
be Linux specific. The naming should naturally be as hardware
specific as possible. In this case something like:

compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";

Or we should probably use:

compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";

As dpi here reflects the hardware it's connected to. The dss
is probably a Linux name.

Not use what you're after with the SPI example though, but sounds
like that's something different.

> I think Tomi's workaround is a much better hack, since it keeps the
> API clean. If the code simply prefixes "omapdss," to all
> "child"-devices of omapdss it can be left mostly untouched, too.

AFAIK that remapping not needed at all. All that is already
available with the compatible flags.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140516 11:02]:
> * Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> > On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > > >> strings.
> > > > > 
> > > > > Well it avoid you parsing through all the nodes during booting
> > > > > and leaves out the function to do remapping. And removes the need
> > > > > for maintaining a custom display mapping table. I'd say that's a
> > > > > pretty good list of advantages right there :)
> > > > 
> > > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > > things with .dts. I just like it more if any hacks are in kernel code,
> > > > which I can remove without anyone noticing.
> > > > 
> > > > Anyway, we already have board.dts files using the non-omapified
> > > > compatible strings in the mainline, so if I would now add the omapified
> > > > compatible strings to .dts files, those old board.dts files would break.
> > > > 
> > > > So I guess the choice has already been made.
> > > 
> > > I really think you should remove this misuse of device tree code ASAP.
> > > It's better to fix it up now than carry the hack for next two years
> > > and keep on adding to it.
> > 
> > IMHO appending -omap-dss to a random device is an even bigger hack,
> > since its adding lots of bloat to the API. Let's assume there is
> > another OS using DT for ARM, but has no proper API for SPI
> > controllers and it introduces your hack to SPI devices. That would
> > mean each SPI device has -omap-spi appended (or -exynos-spi,
> > -foo-spi, ...). At least I would blame them for creating a huge
> > unmaintainable mess.
> 
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
> 
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
> 
> Or we should probably use:
> 
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
> 
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.
> 
> Not use what you're after with the SPI example though, but sounds
> like that's something different.
> 
> > I think Tomi's workaround is a much better hack, since it keeps the
> > API clean. If the code simply prefixes "omapdss," to all
> > "child"-devices of omapdss it can be left mostly untouched, too.
> 
> AFAIK that remapping not needed at all. All that is already
> available with the compatible flags.

And alternatively we can also just use the sharp,ls037v7dw01
in the panel driver(s). We can have the panels bail out in driver
probe based on of_machine_is_compatible if nothing else is available.

Also, currently the remapping code also probably keeps prepending
more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
it would be quite silly for each display controller to have to do
their own remapping for shared panels?

If we still still despite all these reasons decide to go with
the remapping of the compatible strings, it should really be a
Linux generic (or drivers/video generic function), not implemented
for each display controller.

Cheers,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]

On 17/05/14 00:39, Tony Lindgren wrote:

>> AFAIK that remapping not needed at all. All that is already
>> available with the compatible flags.
> 
> And alternatively we can also just use the sharp,ls037v7dw01
> in the panel driver(s). We can have the panels bail out in driver
> probe based on of_machine_is_compatible if nothing else is available.

I don't think that would work. Then we could have two panel drivers,
both loaded into the kernel and both having the same driver name and the
same compatible-string.

I'm not sure if it's even possible to load both of those drivers at the
same time, but if it was, and the first one would get probe() called for
a device, and the driver would return an error, I'm quite sure the
driver framework won't continue trying with the other driver, as the
first driver already matched for the device.

> Also, currently the remapping code also probably keeps prepending
> more and more omapdss,omapdss,omapdss,... on each kexec reboot? And

I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
match for "omapdss,ti,tfp410".

> it would be quite silly for each display controller to have to do
> their own remapping for shared panels?

It would, but wouldn't it be just as silly (well, even more silly in my
opinion) to have each display controller require driver specific
compatible strings for the panels used?

Until we have a common display framework, we need _some_ way to handle
this problem. Either we mess up the .dts files as you suggest, or we
have a driver internal hack.

> If we still still despite all these reasons decide to go with
> the remapping of the compatible strings, it should really be a
> Linux generic (or drivers/video generic function), not implemented
> for each display controller.

Well, I sure hope nobody else has to implement similar thing.

The reason why we have this code, and others do not, is mainly that
omapdss is maybe the first driver to implement the display components
properly, both in the SW side and in the .dts side, and that I wanted
omapdss to behave correctly even if there are other display
subsystems/panels compiled into the same kernel.

To open that up a bit, traditionally other display driver architectures
have not had drivers for each display "entity", like the panels. So you
would really just have the display subsystem in the .dts, and some raw
data there (panel timings) to get the panel running.

Now, with omapdss, we have separate drivers for each display entity.
Unfortunately those drivers are all tied to the omapdss driver's API
(and cannot thus be used on anything else than OMAP), as there's not yet
a driver framework for display entities (DRM is a bit different thing,
in my opinion).

Everything with that was simple with platform data, as the omap board
files created the panel devices, and there were no name clashing
problems with other platforms.

With DT that changed, as the bindings are common, and thus the
compatible strings are common also. But we still have omapdss specific
panel drivers. This is the reason we do the compatible-string conversion
hack. As soon as we can create platform agnostic panel drivers, we can
remove the hack.

And, I want to remind, it's an omapdss internal hack (after the patch I
sent), not visible to anyone else. The .dts files, the arch/arm files,
they are all not touched. So I don't quite understand why you see it as
such a bad thing. It's ugly, sure, but what harm does it do (except some
maintainer burden, for me)?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:49]:
> On 17/05/14 00:39, Tony Lindgren wrote:
> 
> >> AFAIK that remapping not needed at all. All that is already
> >> available with the compatible flags.
> > 
> > And alternatively we can also just use the sharp,ls037v7dw01
> > in the panel driver(s). We can have the panels bail out in driver
> > probe based on of_machine_is_compatible if nothing else is available.
> 
> I don't think that would work. Then we could have two panel drivers,
> both loaded into the kernel and both having the same driver name and the
> same compatible-string.
> 
> I'm not sure if it's even possible to load both of those drivers at the
> same time, but if it was, and the first one would get probe() called for
> a device, and the driver would return an error, I'm quite sure the
> driver framework won't continue trying with the other driver, as the
> first driver already matched for the device.

No need to load multiple drivers at this point. That's why I'm saying
you can bail out on the undesired display controller probes using
of_machine_is_compatible test. It's not that uncommon for drivers to do:

$ git grep of_machine_is_compatible drivers/ | wc -l
116
 
> > Also, currently the remapping code also probably keeps prepending
> > more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
> 
> I don't think so. The code looks for, say, "ti,tfp410", and it wouldn't
> match for "omapdss,ti,tfp410".

OK
 
> > it would be quite silly for each display controller to have to do
> > their own remapping for shared panels?
> 
> It would, but wouldn't it be just as silly (well, even more silly in my
> opinion) to have each display controller require driver specific
> compatible strings for the panels used?

Not driver specific, but hardware package specific. That's being done
all the time. For example, compatible strings like "nvidia,tegra124",
"ti,omap5" describe a package of an ARM core and various devices.

But by using of_machine_is_compatible in the display drivers, you
can use the right compatible flags from the start if you want to go
that way.

> Until we have a common display framework, we need _some_ way to handle
> this problem. Either we mess up the .dts files as you suggest, or we
> have a driver internal hack.

It seems that there's no need to mess up the .dts files here by
using the of_machine_is_compatible check in the drivers.
 
> > If we still still despite all these reasons decide to go with
> > the remapping of the compatible strings, it should really be a
> > Linux generic (or drivers/video generic function), not implemented
> > for each display controller.
> 
> Well, I sure hope nobody else has to implement similar thing.

Suuuure.. I've heard that about 20 times before and guess what
happenened? Things never got fixed until some poor maintainer
had to start fixing it all over the place about three years later.
 
> The reason why we have this code, and others do not, is mainly that
> omapdss is maybe the first driver to implement the display components
> properly, both in the SW side and in the .dts side, and that I wanted
> omapdss to behave correctly even if there are other display
> subsystems/panels compiled into the same kernel.
> 
> To open that up a bit, traditionally other display driver architectures
> have not had drivers for each display "entity", like the panels. So you
> would really just have the display subsystem in the .dts, and some raw
> data there (panel timings) to get the panel running.

Right, I believe that is the way to go, no doubt about it.
 
> Now, with omapdss, we have separate drivers for each display entity.
> Unfortunately those drivers are all tied to the omapdss driver's API
> (and cannot thus be used on anything else than OMAP), as there's not yet
> a driver framework for display entities (DRM is a bit different thing,
> in my opinion).
> 
> Everything with that was simple with platform data, as the omap board
> files created the panel devices, and there were no name clashing
> problems with other platforms.
> 
> With DT that changed, as the bindings are common, and thus the
> compatible strings are common also. But we still have omapdss specific
> panel drivers. This is the reason we do the compatible-string conversion
> hack. As soon as we can create platform agnostic panel drivers, we can
> remove the hack.
> 
> And, I want to remind, it's an omapdss internal hack (after the patch I
> sent), not visible to anyone else. The .dts files, the arch/arm files,
> they are all not touched. So I don't quite understand why you see it as
> such a bad thing. It's ugly, sure, but what harm does it do (except some
> maintainer burden, for me)?

Here's a list of things that bothers me:

1. Searching through the dtb from a driver instead of relying on the
   driver probe mechanism for the components in question. If the parsing
   of the dtb needs to be done it should be done in a Linux generic way
   from some framework instead.

2. Having to do this all early before we even have any debug console
   available. We are trying to move everything to happen later on to avoid
   all the issues related to initializing things early.

3. Having to maintain a database in kernel of display mappings separately
   in addition to the .dts files.

4. Having this hack limited to device tree based booting while we are
   trying to unify the functions for drivers to use to get their
   resources.

5. Seeing the possibility of this spreading to other drivers.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Arnd Bergmann]

On Monday 19 May 2014 08:57:33 Tony Lindgren wrote:
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:
> 
> $ git grep of_machine_is_compatible drivers/ | wc -l
> 116

I think this is widely seen as bad style, and most of the examples are
testing for Power Mac specific workarounds for stuff that Apple didn't
put in DT elsewhere.

	Arnd

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 5571 bytes --]

On 19/05/14 18:57, Tony Lindgren wrote:

>> I'm not sure if it's even possible to load both of those drivers at the
>> same time, but if it was, and the first one would get probe() called for
>> a device, and the driver would return an error, I'm quite sure the
>> driver framework won't continue trying with the other driver, as the
>> first driver already matched for the device.
> 
> No need to load multiple drivers at this point. That's why I'm saying
> you can bail out on the undesired display controller probes using
> of_machine_is_compatible test. It's not that uncommon for drivers to do:

Hmm, I don't follow. If both, say, omap and exynos have a panel driver
for the same sharp panel, both need a driver for it (presuming exynos
has a proper display component driver system, which may not be true).

Both drivers would be loaded at boot time for the probe to be even to be
possible. Even if the other one bails out from a device probe using
of_machine_is_compatible, afaik the driver framework will stop probing
at that point, as that driver reports being compatible with the device
in question.

...

Ah, ok, now I see. I think you mean module init, not probe? For some
reason I was just thinking about the probe stage.

Maybe that would work. I need to test tomorrow.

>>> it would be quite silly for each display controller to have to do
>>> their own remapping for shared panels?
>>
>> It would, but wouldn't it be just as silly (well, even more silly in my
>> opinion) to have each display controller require driver specific
>> compatible strings for the panels used?
> 
> Not driver specific, but hardware package specific. That's being done
> all the time. For example, compatible strings like "nvidia,tegra124",
> "ti,omap5" describe a package of an ARM core and various devices.

It feels to me rather wrong if I'd specify the compatible string for an
external piece of hardware based on the SoC it's connected to.

> But by using of_machine_is_compatible in the display drivers, you
> can use the right compatible flags from the start if you want to go
> that way.

Yes, with that we could have right compatible flags in the .dts.

>> Well, I sure hope nobody else has to implement similar thing.
> 
> Suuuure.. I've heard that about 20 times before and guess what
> happenened? Things never got fixed until some poor maintainer
> had to start fixing it all over the place about three years later.

The poor maintainer here being me =). And it's still a case of
pick-your-poison. We need to hack around the issue, in some form or
another. So in any case the poor maintainer has to fix it at some point
in the future.

But all this is fixed when we have a common display framework. And
that's something that is really badly needed in some form or another,
the sooner the better.

So the "fix" here is not just some internal thing that could be left at
that and forgotten.

>> To open that up a bit, traditionally other display driver architectures
>> have not had drivers for each display "entity", like the panels. So you
>> would really just have the display subsystem in the .dts, and some raw
>> data there (panel timings) to get the panel running.
> 
> Right, I believe that is the way to go, no doubt about it.

No, that's exactly _not_ the way to go =). We need proper drivers for
display components, instead of trying to avoid that and embed panel data
into the display controller's data.

> Here's a list of things that bothers me:
> 
> 1. Searching through the dtb from a driver instead of relying on the
>    driver probe mechanism for the components in question. If the parsing
>    of the dtb needs to be done it should be done in a Linux generic way
>    from some framework instead.

The reason I haven't made the conversion code available for others to
use is that there are no other users at the moment. And I hope there
will be no other user until we get the common display framework. If
there is, we'll need to move the code to a generic place.

> 2. Having to do this all early before we even have any debug console
>    available. We are trying to move everything to happen later on to avoid
>    all the issues related to initializing things early.

It worked fine for me when doing it as subsys_init level. Why do you say
it'd be early, before debug console?

All the drivers with converted compatible strings are normal drivers, so
afaik things work fine if we just convert the strings before the module
init level.

> 3. Having to maintain a database in kernel of display mappings separately
>    in addition to the .dts files.

Yes, that's slightly annoying. Not really a big burden, though, as it's
quite rare to get a new encoder or panel driver.

> 4. Having this hack limited to device tree based booting while we are
>    trying to unify the functions for drivers to use to get their
>    resources.

I don't understand this one. With non-DT boot we don't have the issue at
all, there's no need for hacks.

> 5. Seeing the possibility of this spreading to other drivers.

Well, until we have a common display framework, one of the hacky options
we've discussed will spread to other drivers if they need to have their
own drivers for the same hardware devices.

Which is not nice, but not something we can escape. And using the
of_machine_is_compatible or having the compatible strings in .dts
appended with "dss" or such doesn't change that, it just changes which
hack may spread.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 11:58]:
> On 19/05/14 18:57, Tony Lindgren wrote:
> 
> >> I'm not sure if it's even possible to load both of those drivers at the
> >> same time, but if it was, and the first one would get probe() called for
> >> a device, and the driver would return an error, I'm quite sure the
> >> driver framework won't continue trying with the other driver, as the
> >> first driver already matched for the device.
> > 
> > No need to load multiple drivers at this point. That's why I'm saying
> > you can bail out on the undesired display controller probes using
> > of_machine_is_compatible test. It's not that uncommon for drivers to do:
> 
> Hmm, I don't follow. If both, say, omap and exynos have a panel driver
> for the same sharp panel, both need a driver for it (presuming exynos
> has a proper display component driver system, which may not be true).
> 
> Both drivers would be loaded at boot time for the probe to be even to be
> possible. Even if the other one bails out from a device probe using
> of_machine_is_compatible, afaik the driver framework will stop probing
> at that point, as that driver reports being compatible with the device
> in question.
> 
> ...
> 
> Ah, ok, now I see. I think you mean module init, not probe? For some
> reason I was just thinking about the probe stage.
> 
> Maybe that would work. I need to test tomorrow.

Ah right probe is too late as the match has been made already by then :)
 
> >>> it would be quite silly for each display controller to have to do
> >>> their own remapping for shared panels?
> >>
> >> It would, but wouldn't it be just as silly (well, even more silly in my
> >> opinion) to have each display controller require driver specific
> >> compatible strings for the panels used?
> > 
> > Not driver specific, but hardware package specific. That's being done
> > all the time. For example, compatible strings like "nvidia,tegra124",
> > "ti,omap5" describe a package of an ARM core and various devices.
> 
> It feels to me rather wrong if I'd specify the compatible string for an
> external piece of hardware based on the SoC it's connected to.
> 
> > But by using of_machine_is_compatible in the display drivers, you
> > can use the right compatible flags from the start if you want to go
> > that way.
> 
> Yes, with that we could have right compatible flags in the .dts.
> 
> >> Well, I sure hope nobody else has to implement similar thing.
> > 
> > Suuuure.. I've heard that about 20 times before and guess what
> > happenened? Things never got fixed until some poor maintainer
> > had to start fixing it all over the place about three years later.
> 
> The poor maintainer here being me =). And it's still a case of
> pick-your-poison. We need to hack around the issue, in some form or
> another. So in any case the poor maintainer has to fix it at some point
> in the future.

Yeah I agree none of the options so far have been very nice.
 
> But all this is fixed when we have a common display framework. And
> that's something that is really badly needed in some form or another,
> the sooner the better.
> 
> So the "fix" here is not just some internal thing that could be left at
> that and forgotten.

Yes..
 
> >> To open that up a bit, traditionally other display driver architectures
> >> have not had drivers for each display "entity", like the panels. So you
> >> would really just have the display subsystem in the .dts, and some raw
> >> data there (panel timings) to get the panel running.
> > 
> > Right, I believe that is the way to go, no doubt about it.
> 
> No, that's exactly _not_ the way to go =). We need proper drivers for
> display components, instead of trying to avoid that and embed panel data
> into the display controller's data.

Right, sorry I misread it :)
 
> > Here's a list of things that bothers me:
> > 
> > 1. Searching through the dtb from a driver instead of relying on the
> >    driver probe mechanism for the components in question. If the parsing
> >    of the dtb needs to be done it should be done in a Linux generic way
> >    from some framework instead.
> 
> The reason I haven't made the conversion code available for others to
> use is that there are no other users at the moment. And I hope there
> will be no other user until we get the common display framework. If
> there is, we'll need to move the code to a generic place.
> 
> > 2. Having to do this all early before we even have any debug console
> >    available. We are trying to move everything to happen later on to avoid
> >    all the issues related to initializing things early.
> 
> It worked fine for me when doing it as subsys_init level. Why do you say
> it'd be early, before debug console?

The debug console should not be needed for debugging drivers.. Just
the serial console. This is because it's hard for users to produce
decent error information when the system does not boot if DEBUG_LL
and earlyprintk need to be enabled.
 
> All the drivers with converted compatible strings are normal drivers, so
> afaik things work fine if we just convert the strings before the module
> init level.

Yes that seems like the right place to do the workarounds.
 
> > 3. Having to maintain a database in kernel of display mappings separately
> >    in addition to the .dts files.
> 
> Yes, that's slightly annoying. Not really a big burden, though, as it's
> quite rare to get a new encoder or panel driver.
> 
> > 4. Having this hack limited to device tree based booting while we are
> >    trying to unify the functions for drivers to use to get their
> >    resources.
> 
> I don't understand this one. With non-DT boot we don't have the issue at
> all, there's no need for hacks.

Hmm can't we still have multiarch booting happening with the same
panel name being used by two different display drivers?
 
> > 5. Seeing the possibility of this spreading to other drivers.
> 
> Well, until we have a common display framework, one of the hacky options
> we've discussed will spread to other drivers if they need to have their
> own drivers for the same hardware devices.
> 
> Which is not nice, but not something we can escape. And using the
> of_machine_is_compatible or having the compatible strings in .dts
> appended with "dss" or such doesn't change that, it just changes which
> hack may spread.

Yes I agree they are all hacks, but your version seems to carry some
extra early init baggage with it as I noted above :)

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

On 19/05/14 22:51, Tony Lindgren wrote:

>>> 4. Having this hack limited to device tree based booting while we are
>>>    trying to unify the functions for drivers to use to get their
>>>    resources.
>>
>> I don't understand this one. With non-DT boot we don't have the issue at
>> all, there's no need for hacks.
> 
> Hmm can't we still have multiarch booting happening with the same
> panel name being used by two different display drivers?

Yes, but in that case the driver names are internal to kernel. You can
append "omapdss" or such to the driver name, and have that name used in
the board file and in the driver. It's not visible outside the kernel,
and when there's a common display framework, it can be changed without
anyone knowing.

With DT we have the old, stable .dts files that need to be supported...

>>> 5. Seeing the possibility of this spreading to other drivers.
>>
>> Well, until we have a common display framework, one of the hacky options
>> we've discussed will spread to other drivers if they need to have their
>> own drivers for the same hardware devices.
>>
>> Which is not nice, but not something we can escape. And using the
>> of_machine_is_compatible or having the compatible strings in .dts
>> appended with "dss" or such doesn't change that, it just changes which
>> hack may spread.
> 
> Yes I agree they are all hacks, but your version seems to carry some
> extra early init baggage with it as I noted above :)

True, but it doesn't feel very big baggage to me. We can bail out
immediately if the machine is not omap, so for non-omap's the effect
should be negligible.

For omap there is some extra stuff being done. I don't really know heavy
it is, performance wise, but the operation itself is quite small.

I'll try and see how the other options work, which are:

- Bailing out from module_init in each display driver. The reason I
don't like this (although I haven't tried it) is that all the display
drivers need the modification, and because I need to catch the
module_init, I cannot use the helpers like module_platform_driver(), so
it adds multiple lines to every driver.

- Traveling the video graph, starting from omapdss. This one is possibly
better performance-wise than my original version, as we only need to
search for the omapdss node and can then follow the links. But the code
will be more complex.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi,

On Wed, May 21, 2014 at 04:05:56PM +0300, Tomi Valkeinen wrote:
> I'll try and see how the other options work, which are:
> 
> - Bailing out from module_init in each display driver. The reason I
> don't like this (although I haven't tried it) is that all the display
> drivers need the modification, and because I need to catch the
> module_init, I cannot use the helpers like module_platform_driver(), so
> it adds multiple lines to every driver.

You could create your own omapdss_driver() define for that.
This can be replaced more simply once no longer needed and
creates less bloat.

I see one more disadvantage for this approach:

assumed situation (some future 3.16+x kernel):
 * The kernel has an common display framework (CDF)
 * The kernel has an panel driver using CDF
 * There also exists omapdss driver for the same panel
 * omapdss does not (yet) adopt CDF
 * CDF and omapdss are enabled in .config
 * Kernel is booted from an OMAP system

This would result in both drivers being loaded using the same
DT compatible string. The same scenario works using the rewriting
method, since the common display framework would only see the
rewritten compatible string.

Of course this scenario only happens when omapdss is not adopted
to the common display framework from the start on.

> - Traveling the video graph, starting from omapdss. This one is possibly
> better performance-wise than my original version, as we only need to
> search for the omapdss node and can then follow the links. But the code
> will be more complex.

I think the main advantage is the missing lookup table/whitelist,
which adds redundancy. Not having it has some advantages:

* new drivers don't need to touch any existing files (making
  rebasing etc. easier)
* table can get out of sync (though that shouldn't happen anyway,
  since the binding is supposed to be stable)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Hi,

On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
> > 3. Having to maintain a database in kernel of display mappings separately
> >    in addition to the .dts files.
> 
> Yes, that's slightly annoying. Not really a big burden, though, as it's
> quite rare to get a new encoder or panel driver.

I wonder if the "omapdss," prefix could be added to *all* remote
endpoints seen by omapdss. Pseudocode:

for each port in dss {
    for each endpoint in port {
        panel = get_phandle(endpoint, "remote-endpoint");

        /* only add prefix if it's not already there (kexec) */
        if (panel.compatible != "omapdss,.*")
            panel.compatible = "omapdss," + panel.compatible;
    }
}

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On 20/05/14 07:57, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, May 19, 2014 at 09:57:18PM +0300, Tomi Valkeinen wrote:
>>> 3. Having to maintain a database in kernel of display mappings separately
>>>    in addition to the .dts files.
>>
>> Yes, that's slightly annoying. Not really a big burden, though, as it's
>> quite rare to get a new encoder or panel driver.
> 
> I wonder if the "omapdss," prefix could be added to *all* remote
> endpoints seen by omapdss. Pseudocode:
> 
> for each port in dss {
>     for each endpoint in port {
>         panel = get_phandle(endpoint, "remote-endpoint");
> 
>         /* only add prefix if it's not already there (kexec) */
>         if (panel.compatible != "omapdss,.*")
>             panel.compatible = "omapdss," + panel.compatible;
>     }
> }

Hmm, yes, I think that would work. It would remove the need for the
database, but the code would be slightly more complex as we'd need to
travel through the graph, not just the nodes that are directly connected
to omapdss. I need to try this approach also.

 Tomi

Ps. Sorry for misspelling your name, twice. If I recall right, I even
checked if your name is written with an 'a' or an 'e', but somehow still
managed to get it wrong.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On 16/05/14 21:01, Tony Lindgren wrote:

>> IMHO appending -omap-dss to a random device is an even bigger hack,
>> since its adding lots of bloat to the API. Let's assume there is
>> another OS using DT for ARM, but has no proper API for SPI
>> controllers and it introduces your hack to SPI devices. That would
>> mean each SPI device has -omap-spi appended (or -exynos-spi,
>> -foo-spi, ...). At least I would blame them for creating a huge
>> unmaintainable mess.
> 
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
> 
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
> 
> Or we should probably use:
> 
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
> 
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.

Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
wouldn't really be a good extension, as what we want is an omapdss
driver specific compatible string. So I think "-omapdss" is the best
extension if that method is used.

But I don't think that's really the point. The point is that the panel's
compatible string should be "sharp,ls037v7dw01", nothing else.

All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
only made for Linux SW reasons. So I would say they are Linux specific
SW names, even if the words themselves are also HW terms.

> Not use what you're after with the SPI example though, but sounds
> like that's something different.

I think Sebastien's example is just like the issue here.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140519 02:22]:
> On 16/05/14 21:01, Tony Lindgren wrote:
> 
> >> IMHO appending -omap-dss to a random device is an even bigger hack,
> >> since its adding lots of bloat to the API. Let's assume there is
> >> another OS using DT for ARM, but has no proper API for SPI
> >> controllers and it introduces your hack to SPI devices. That would
> >> mean each SPI device has -omap-spi appended (or -exynos-spi,
> >> -foo-spi, ...). At least I would blame them for creating a huge
> >> unmaintainable mess.
> > 
> > I think you're misunderstanding. I do not want the naming to
> > be Linux specific. The naming should naturally be as hardware
> > specific as possible. In this case something like:
> > 
> > compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
> > 
> > Or we should probably use:
> > 
> > compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
> > 
> > As dpi here reflects the hardware it's connected to. The dss
> > is probably a Linux name.
> 
> Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
> wouldn't really be a good extension, as what we want is an omapdss
> driver specific compatible string. So I think "-omapdss" is the best
> extension if that method is used.
> 
> But I don't think that's really the point. The point is that the panel's
> compatible string should be "sharp,ls037v7dw01", nothing else.
> 
> All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
> only made for Linux SW reasons. So I would say they are Linux specific
> SW names, even if the words themselves are also HW terms.

If you really want to use only "sharp,ls037v7dw01" as the compatible
string, then you can still do that and bail out from the undesired
drivers by using of_machine_is_compatible check.

In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
 
> > Not use what you're after with the SPI example though, but sounds
> > like that's something different.
> 
> I think Sebastien's example is just like the issue here.

Hmm is there some existing example in the kernel like that?

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On 19/05/14 19:04, Tony Lindgren wrote:

> In many cases however we do have multiple compatible strings that
> describe how the device is wired. See drivers/tty/serial/of_serial.c
> for example. It has "ns16550" but then it also has additional
> "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".

All those sound like SoC components. In that case it sounds fine to have
the device compatible contain the SoC name. We're talking here about
external, detachable devices.

>>> Not use what you're after with the SPI example though, but sounds
>>> like that's something different.
>>
>> I think Sebastien's example is just like the issue here.
> 
> Hmm is there some existing example in the kernel like that?

No, Sebastien's example was just a hypothetical case. Here, using your
way of having SoC specific data in the .dts, we would have
"sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
sensor we'd have, say, "synaptics,xyz123-omap-spi".

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
> On 19/05/14 19:04, Tony Lindgren wrote:
> 
> > In many cases however we do have multiple compatible strings that
> > describe how the device is wired. See drivers/tty/serial/of_serial.c
> > for example. It has "ns16550" but then it also has additional
> > "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
> 
> All those sound like SoC components. In that case it sounds fine to have
> the device compatible contain the SoC name. We're talking here about
> external, detachable devices.
>
> >>> Not use what you're after with the SPI example though, but sounds
> >>> like that's something different.
> >>
> >> I think Sebastien's example is just like the issue here.
> > 
> > Hmm is there some existing example in the kernel like that?
> 
> No, Sebastien's example was just a hypothetical case. Here, using your
> way of having SoC specific data in the .dts, we would have
> "sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
> sensor we'd have, say, "synaptics,xyz123-omap-spi".

Yes, that's what I wanted to say :)

My name is spelled Sebastian, though. Sebastien is the French
variant as far as i know.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Sebastian Reichel <sre@kernel.org> [140519 22:13]:
> On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
> > On 19/05/14 19:04, Tony Lindgren wrote:
> > 
> > > In many cases however we do have multiple compatible strings that
> > > describe how the device is wired. See drivers/tty/serial/of_serial.c
> > > for example. It has "ns16550" but then it also has additional
> > > "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
> > 
> > All those sound like SoC components. In that case it sounds fine to have
> > the device compatible contain the SoC name. We're talking here about
> > external, detachable devices.

Yes I agree it's also hackish. But playing with the compatible flags
avoids adding other custom workarounds.

> > >>> Not use what you're after with the SPI example though, but sounds
> > >>> like that's something different.
> > >>
> > >> I think Sebastien's example is just like the issue here.
> > > 
> > > Hmm is there some existing example in the kernel like that?
> > 
> > No, Sebastien's example was just a hypothetical case. Here, using your
> > way of having SoC specific data in the .dts, we would have
> > "sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
> > sensor we'd have, say, "synaptics,xyz123-omap-spi".
> 
> Yes, that's what I wanted to say :)

Hmm I think we need to add few things to the hypothetical SPI case
to get it even close to the panel example. Like assume that no SPI bus
exists, and that potentially multiple different Synaptics drivers are
trying to share the same compatible flag for a non-existing generic
binding.. I think then it's getting close to the panel example :)

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

On Mon, May 19, 2014 at 10:48:52PM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [140519 22:13]:
> > On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:
> > > On 19/05/14 19:04, Tony Lindgren wrote:
> > > 
> > > > In many cases however we do have multiple compatible strings that
> > > > describe how the device is wired. See drivers/tty/serial/of_serial.c
> > > > for example. It has "ns16550" but then it also has additional
> > > > "nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
> > > 
> > > All those sound like SoC components. In that case it sounds fine to have
> > > the device compatible contain the SoC name. We're talking here about
> > > external, detachable devices.
> 
> Yes I agree it's also hackish. But playing with the compatible flags
> avoids adding other custom workarounds.
> 
> > > >>> Not use what you're after with the SPI example though, but sounds
> > > >>> like that's something different.
> > > >>
> > > >> I think Sebastien's example is just like the issue here.
> > > > 
> > > > Hmm is there some existing example in the kernel like that?
> > > 
> > > No, Sebastien's example was just a hypothetical case. Here, using your
> > > way of having SoC specific data in the .dts, we would have
> > > "sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
> > > sensor we'd have, say, "synaptics,xyz123-omap-spi".
> > 
> > Yes, that's what I wanted to say :)
> 
> Hmm I think we need to add few things to the hypothetical SPI case
> to get it even close to the panel example. Like assume that no SPI bus
> exists, [...]

The important thing is not, that there is an SPI bus (hardware), but
that there is a common SPI client framework (software). That's one
of the problem's I see with the modified compatible value.

Basically I see the following problem with the appended -omapdss in
the compatible string:

 * You can read the -omapdss as "to be used with omapdss driver". In
   this case the compatible string is just needed for driver loading,
   which is frowned upon DT binding maintainers AFAIK.
 * Alternatively one can read it as "connected to omapdss". In this
   case we add unneeded redundancy to the DT. This does not belong
   into a compatible string, since its encoded in the DT hierarchy.

And btw. Tomi's rewrite hack basically works exactly like this, just
without adding the redundancy explicitly into the DT. Instead of
prefixing the comaptible string he could also add a -omapdss sufix.
That's basically a proof, that the suffix adds useless redudancy.

> [...] and that potentially multiple different Synaptics drivers are
> trying to share the same compatible flag for a non-existing generic
> binding.

If there was no common SPI client framework you would need two
different SPI client drivers for two different SPI host controllers.

Obviously its a bad idea to have no SPI framework, but that's not
important for the example (except that there should obviously be a
common panel framework) :)

> I think then it's getting close to the panel example :)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 7924 bytes --]

On 09/05/14 02:33, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140507 11:00]:
>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
>>> On 07/05/14 18:03, Tony Lindgren wrote:
>>>>
>>>> BTW, I'm also personally fine with all five gpios showing in a single
>>>> gpios property, I'm not too exited about naming anything in DT..
>>>
>>> I don't have a strong opinion here. I don't have much experience with
>>> DT, especially with making bindings compatible with other ones.
>>>
>>> I'd just forget the simple-panel, and have single gpio array.
>>
>> Well if it's a don't care flag for both of us, let's try to use
>> the existing standard for simple-panel.txt and add mode-gpios
>> property. I'll post a patch for that.
> 
> Here's an updated version using enable-gpios, reset-gpios and
> mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> that's currently specific to this panel only.
> 
> Also updated for -EPROBE_DEFER handling, tested that by changing
> one of the GPIOs to be a twl4030 GPIO.

To speed things up a bit, I made the changes I suggested. Compile tested
only.


From f8360778e8bc96096cbb1793a18a8c240376ca09 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

Add device tree support for sharp-ls037v7dw01 panel.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 .../bindings/video/sharp,ls037v7dw01.txt           | 44 ++++++++++
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 95 +++++++++++++++++++++-
 2 files changed, 136 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt

diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index 000000000000..2a60fd9a2607
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===================================
+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+  this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+  this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+  ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+	compatible = "sharp,ls037v7dw01";
+	power-supply = <&lcd_3v3>;
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+
+	port {
+		lcd_in: endpoint {
+			remote-endpoint = <&dpi_out>;
+		};
+	};
+};
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 8adde628ad38..91eeb2ec93a8 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
 
 struct panel_drv_data {
 	struct omap_dss_device dssdev;
 	struct omap_dss_device *in;
+	struct regulator *vcc;
 
 	int data_lines;
 
@@ -95,12 +98,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	if (omapdss_device_is_enabled(dssdev))
 		return 0;
 
-	in->ops.dpi->set_data_lines(in, ddata->data_lines);
+	if (ddata->data_lines)
+		in->ops.dpi->set_data_lines(in, ddata->data_lines);
 	in->ops.dpi->set_timings(in, &ddata->videomode);
 
+	if (ddata->vcc) {
+		r = regulator_enable(ddata->vcc);
+		if (r != 0)
+			return r;
+	}
+
 	r = in->ops.dpi->enable(in);
-	if (r)
+	if (r) {
+		regulator_disable(ddata->vcc);
 		return r;
+	}
 
 	/* wait couple of vsyncs until enabling the LCD */
 	msleep(50);
@@ -136,6 +148,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
 
 	in->ops.dpi->disable(in);
 
+	if (ddata->vcc)
+		regulator_disable(ddata->vcc);
+
 	dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
 }
 
@@ -243,6 +258,68 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+	struct gpio_desc *gpio;
+
+	gpio = devm_gpiod_get_index(dev, desc, index);
+	if (IS_ERR(gpio))
+		return gpio;
+
+	gpiod_direction_output(gpio, val);
+
+	return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+
+	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+	if (IS_ERR(ddata->vcc)) {
+		dev_err(&pdev->dev, "failed to get regulator\n");
+		return PTR_ERR(ddata->vcc);
+	}
+
+	/* lcd INI */
+	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");
+	if (PTR_ERR(ddata->ini_gpio) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd RESB */
+	ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");
+	if (PTR_ERR(ddata->resb_gpio) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd MO */
+	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "mode");
+	if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd LR */
+	ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+	if (PTR_ERR(ddata->lr_gpio) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd UD */
+	ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+	if (PTR_ERR(ddata->ud_gpio) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	in = omapdss_of_find_source_for_first_ep(node);
+	if (IS_ERR(in)) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return PTR_ERR(in);
+	}
+
+	ddata->in = in;
+
+	return 0;
+}
+
 static int sharp_ls_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -259,6 +336,10 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		r = sharp_ls_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = sharp_ls_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -302,12 +383,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id sharp_ls_of_match[] = {
+	{ .compatible = "omapdss,sharp,ls037v7dw01", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
 static struct platform_driver sharp_ls_driver = {
 	.probe = sharp_ls_probe,
 	.remove = __exit_p(sharp_ls_remove),
 	.driver = {
 		.name = "panel-sharp-ls037v7dw01",
 		.owner = THIS_MODULE,
+		.of_match_table = sharp_ls_of_match,
 	},
 };
 
-- 
1.9.1



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:31]:
> On 09/05/14 02:33, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140507 11:00]:
> >> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> >>> On 07/05/14 18:03, Tony Lindgren wrote:
> >>>>
> >>>> BTW, I'm also personally fine with all five gpios showing in a single
> >>>> gpios property, I'm not too exited about naming anything in DT..
> >>>
> >>> I don't have a strong opinion here. I don't have much experience with
> >>> DT, especially with making bindings compatible with other ones.
> >>>
> >>> I'd just forget the simple-panel, and have single gpio array.
> >>
> >> Well if it's a don't care flag for both of us, let's try to use
> >> the existing standard for simple-panel.txt and add mode-gpios
> >> property. I'll post a patch for that.
> > 
> > Here's an updated version using enable-gpios, reset-gpios and
> > mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> > that's currently specific to this panel only.
> > 
> > Also updated for -EPROBE_DEFER handling, tested that by changing
> > one of the GPIOs to be a twl4030 GPIO.
> 
> To speed things up a bit, I made the changes I suggested. Compile tested
> only.

OK thanks did not get the penguin with it so need to look at it a bit
more.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140509 08:31]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:31]:
> > On 09/05/14 02:33, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [140507 11:00]:
> > >> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> > >>> On 07/05/14 18:03, Tony Lindgren wrote:
> > >>>>
> > >>>> BTW, I'm also personally fine with all five gpios showing in a single
> > >>>> gpios property, I'm not too exited about naming anything in DT..
> > >>>
> > >>> I don't have a strong opinion here. I don't have much experience with
> > >>> DT, especially with making bindings compatible with other ones.
> > >>>
> > >>> I'd just forget the simple-panel, and have single gpio array.
> > >>
> > >> Well if it's a don't care flag for both of us, let's try to use
> > >> the existing standard for simple-panel.txt and add mode-gpios
> > >> property. I'll post a patch for that.
> > > 
> > > Here's an updated version using enable-gpios, reset-gpios and
> > > mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> > > that's currently specific to this panel only.
> > > 
> > > Also updated for -EPROBE_DEFER handling, tested that by changing
> > > one of the GPIOs to be a twl4030 GPIO.
> > 
> > To speed things up a bit, I made the changes I suggested. Compile tested
> > only.
> 
> OK thanks did not get the penguin with it so need to look at it a bit
> more.

Here's this patch updated again for QVGA and VGA support and to use
your panel remapping. I've also made sure the blanking works properly
on evm-37xx and ldp.

Regards,

Tony

8< --------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

Add device tree support for sharp-ls037v7dw01 panel.

Note that this patch is using the remapping of the compatible
flag as implemented by Tomi (that I do not like), but seems
like that's currently needed to avoid redoing the panel
bindings later on. And for the record, that has been agreed
to be a temporary measure until the generic display bindings
can be used by DSS.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+=================+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+  this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+  this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+  ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+	compatible = "sharp,ls037v7dw01";
+	power-supply = <&lcd_3v3>;
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+
+	port {
+		lcd_in: endpoint {
+			remote-endpoint = <&dpi_out>;
+		};
+	};
+};
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -562,6 +562,7 @@ static const char * const dss_compat_conv_list[] __initconst = {
 	"hdmi-connector",
 	"panel-dpi",
 	"panel-dsi-cm",
+	"sharp,ls037v7dw01",
 	"sony,acx565akm",
 	"svideo-connector",
 	"ti,tfp410",
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
 
 struct panel_drv_data {
 	struct omap_dss_device dssdev;
 	struct omap_dss_device *in;
+	struct regulator *vcc;
 
 	int data_lines;
 
@@ -31,9 +34,33 @@ struct panel_drv_data {
 	struct gpio_desc *mo_gpio;	/* low = 480x640, high = 240x320 */
 	struct gpio_desc *lr_gpio;	/* high = conventional horizontal scanning */
 	struct gpio_desc *ud_gpio;	/* high = conventional vertical scanning */
+
+#define SHARP_LS_QVGA	(1 << 0)
+	u32 flags;
+};
+
+static const struct omap_video_timings sharp_ls_qvga_timings = {
+	.x_res = 240,
+	.y_res = 320,
+
+	.pixelclock	= 5400000,
+
+	.hsw		= 3,
+	.hfp		= 3,
+	.hbp		= 39,
+
+	.vsw		= 1,
+	.vfp		= 2,
+	.vbp		= 7,
+
+	.vsync_level	= OMAPDSS_SIG_ACTIVE_LOW,
+	.hsync_level	= OMAPDSS_SIG_ACTIVE_LOW,
+	.data_pclk_edge	= OMAPDSS_DRIVE_SIG_RISING_EDGE,
+	.de_level	= OMAPDSS_SIG_ACTIVE_HIGH,
+	.sync_pclk_edge	= OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
 };
 
-static const struct omap_video_timings sharp_ls_timings = {
+static const struct omap_video_timings sharp_ls_vga_timings = {
 	.x_res = 480,
 	.y_res = 640,
 
@@ -95,12 +122,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
 	if (omapdss_device_is_enabled(dssdev))
 		return 0;
 
-	in->ops.dpi->set_data_lines(in, ddata->data_lines);
+	if (ddata->data_lines)
+		in->ops.dpi->set_data_lines(in, ddata->data_lines);
 	in->ops.dpi->set_timings(in, &ddata->videomode);
 
+	if (ddata->vcc) {
+		r = regulator_enable(ddata->vcc);
+		if (r != 0)
+			return r;
+	}
+
 	r = in->ops.dpi->enable(in);
-	if (r)
+	if (r) {
+		regulator_disable(ddata->vcc);
 		return r;
+	}
 
 	/* wait couple of vsyncs until enabling the LCD */
 	msleep(50);
@@ -136,6 +172,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
 
 	in->ops.dpi->disable(in);
 
+	if (ddata->vcc)
+		regulator_disable(ddata->vcc);
+
 	dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
 }
 
@@ -243,6 +282,72 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+	struct gpio_desc *gpio;
+
+	gpio = devm_gpiod_get_index(dev, desc, index);
+	if (IS_ERR(gpio))
+		return gpio;
+
+	gpiod_direction_output(gpio, val);
+
+	return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+
+	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+	if (IS_ERR(ddata->vcc)) {
+		dev_err(&pdev->dev, "failed to get regulator\n");
+		return PTR_ERR(ddata->vcc);
+	}
+
+	/* lcd INI */
+	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
+	if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd RESB */
+	ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "reset");
+	if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd MO */
+	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
+	if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	if (!IS_ERR(ddata->mo_gpio))
+		if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
+			ddata->flags |= SHARP_LS_QVGA;
+
+	/* lcd LR */
+	ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+	if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	/* lcd UD */
+	ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+	if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
+	in = omapdss_of_find_source_for_first_ep(node);
+	if (IS_ERR(in)) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return PTR_ERR(in);
+	}
+
+	ddata->in = in;
+
+	return 0;
+}
+
 static int sharp_ls_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -259,11 +364,18 @@ static int sharp_ls_probe(struct platform_device *pdev)
 		r = sharp_ls_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = sharp_ls_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
 
-	ddata->videomode = sharp_ls_timings;
+	if (ddata->flags & SHARP_LS_QVGA)
+		ddata->videomode = sharp_ls_qvga_timings;
+	else
+		ddata->videomode = sharp_ls_vga_timings;
 
 	dssdev = &ddata->dssdev;
 	dssdev->dev = &pdev->dev;
@@ -302,12 +414,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id sharp_ls_of_match[] = {
+	{ .compatible = "omapdss,sharp,ls037v7dw01", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
 static struct platform_driver sharp_ls_driver = {
 	.probe = sharp_ls_probe,
 	.remove = __exit_p(sharp_ls_remove),
 	.driver = {
 		.name = "panel-sharp-ls037v7dw01",
 		.owner = THIS_MODULE,
+		.of_match_table = sharp_ls_of_match,
 	},
 };
 

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On 14/05/14 00:26, Tony Lindgren wrote:

> +	/* lcd MO */
> +	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> +	if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
> +		return -EPROBE_DEFER;
> +
> +	if (!IS_ERR(ddata->mo_gpio))
> +		if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> +			ddata->flags |= SHARP_LS_QVGA;

Shouldn't there be an explicit flag in the DT data for this? If the
panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
have MO gpio, right? So something like:


mode-gpios = <0					/* high, lcd MO */
	      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
	      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */

vga-mode;	/* MO hardwired high */



Btw, the gpio.txt has each gpio inside <>:

chipsel-gpios = <&gpio1 12 0>,
		 <&gpio1 13 0>,
		 <0>, /* holes are permitted, means no GPIO 2 */
		 <&gpio2 2>;

Is that equivalent to having all gpios inside <>?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 01:42]:
> On 14/05/14 00:26, Tony Lindgren wrote:
> 
> > +	/* lcd MO */
> > +	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> > +	if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
> > +		return -EPROBE_DEFER;
> > +
> > +	if (!IS_ERR(ddata->mo_gpio))
> > +		if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> > +			ddata->flags |= SHARP_LS_QVGA;
> 
> Shouldn't there be an explicit flag in the DT data for this? If the
> panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
> have MO gpio, right? So something like:
> 
> 
> mode-gpios = <0					/* high, lcd MO */
> 	      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
> 	      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
> 
> vga-mode;	/* MO hardwired high */
 
Yeah holes there are just fine. I figured let's keep the custom
vga-mode property out of the way until we actually run into a panel
that's not using a GPIO for mode.

So far it seems that mode GPIO is there for the panels I've seen,
just the scan direction pins seem to be hard wired on LDP. But
then again, maybe I'm still having trouble locating all the
GPIOs in the LDP schematics.
 
> Btw, the gpio.txt has each gpio inside <>:
> 
> chipsel-gpios = <&gpio1 12 0>,
> 		 <&gpio1 13 0>,
> 		 <0>, /* holes are permitted, means no GPIO 2 */
> 		 <&gpio2 2>;
> 
> Is that equivalent to having all gpios inside <>?

Yeah, just less <> braces. The number of elements for each
entry is what matters and that's known by the GPIO parsing
code.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

On 15/05/14 21:25, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 01:42]:
>> On 14/05/14 00:26, Tony Lindgren wrote:
>>
>>> +	/* lcd MO */
>>> +	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
>>> +	if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
>>> +		return -EPROBE_DEFER;
>>> +
>>> +	if (!IS_ERR(ddata->mo_gpio))
>>> +		if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
>>> +			ddata->flags |= SHARP_LS_QVGA;
>>
>> Shouldn't there be an explicit flag in the DT data for this? If the
>> panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
>> have MO gpio, right? So something like:
>>
>>
>> mode-gpios = <0					/* high, lcd MO */
>> 	      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
>> 	      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
>>
>> vga-mode;	/* MO hardwired high */
>  
> Yeah holes there are just fine. I figured let's keep the custom
> vga-mode property out of the way until we actually run into a panel
> that's not using a GPIO for mode.

Ok, I'm fine with that, but in that case I think we have to use all the
panels in the same mode, i.e. the driver either sets the MO gpio always
low and uses VGA mode, or sets the MO always high and uses QVGA mode.

In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to
change the mode, even if it really should be ACTIVE_HIGH. But if you do
that, and we later add the support to the panel driver to manage the MO
gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then
the panel won't work as the driver uses wrong polarity for the pin.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:51]:
> On 15/05/14 21:25, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 01:42]:
> >> On 14/05/14 00:26, Tony Lindgren wrote:
> >>
> >>> +	/* lcd MO */
> >>> +	ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> >>> +	if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
> >>> +		return -EPROBE_DEFER;
> >>> +
> >>> +	if (!IS_ERR(ddata->mo_gpio))
> >>> +		if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> >>> +			ddata->flags |= SHARP_LS_QVGA;
> >>
> >> Shouldn't there be an explicit flag in the DT data for this? If the
> >> panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
> >> have MO gpio, right? So something like:
> >>
> >>
> >> mode-gpios = <0					/* high, lcd MO */
> >> 	      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
> >> 	      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
> >>
> >> vga-mode;	/* MO hardwired high */
> >  
> > Yeah holes there are just fine. I figured let's keep the custom
> > vga-mode property out of the way until we actually run into a panel
> > that's not using a GPIO for mode.
> 
> Ok, I'm fine with that, but in that case I think we have to use all the
> panels in the same mode, i.e. the driver either sets the MO gpio always
> low and uses VGA mode, or sets the MO always high and uses QVGA mode.

OK let's default to VGA mode for now.
 
> In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to
> change the mode, even if it really should be ACTIVE_HIGH. But if you do
> that, and we later add the support to the panel driver to manage the MO
> gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then
> the panel won't work as the driver uses wrong polarity for the pin.

Getting the configured value seemed to work just fine with
gpiod_get_raw_value_cansleep(ddata->mo_gpio). But yeah I agree the
lack and confusion between polarity and desired default value for
a GPIO is is sucky. The ACTIVE_HIGH probably should mean polarity. 

I don't know if there's an easy solution to that short of adding a
new GPIO binding that contains both the polarity and the desired
default value.

Regards,

Tony

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On 14/05/14 00:26, Tony Lindgren wrote:

> +static int sharp_ls_probe_of(struct platform_device *pdev)
> +{
> +	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> +	struct device_node *node = pdev->dev.of_node;
> +	struct omap_dss_device *in;
> +
> +	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
> +	if (IS_ERR(ddata->vcc)) {
> +		dev_err(&pdev->dev, "failed to get regulator\n");
> +		return PTR_ERR(ddata->vcc);
> +	}
> +
> +	/* lcd INI */
> +	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
> +	if (PTR_ERR(ddata->ini_gpio) == -EPROBE_DEFER)
> +		return -EPROBE_DEFER;

Hmm, the GPIOs are optional, but shouldn't we react somehow to real
errors? I guess we should do something like:

ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
if (IS_ERR(ddata->ini_gpio) {
	int err = PTR_ERR(ddata->ini_gpio);
	if (err == -EPROBE_DEFER || err != -ENOENT)
		return err;
}

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 06:08]:
> On 14/05/14 00:26, Tony Lindgren wrote:
> 
> > +static int sharp_ls_probe_of(struct platform_device *pdev)
> > +{
> > +	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> > +	struct device_node *node = pdev->dev.of_node;
> > +	struct omap_dss_device *in;
> > +
> > +	ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
> > +	if (IS_ERR(ddata->vcc)) {
> > +		dev_err(&pdev->dev, "failed to get regulator\n");
> > +		return PTR_ERR(ddata->vcc);
> > +	}
> > +
> > +	/* lcd INI */
> > +	ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
> > +	if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
> > +		return -EPROBE_DEFER;
> 
> Hmm, the GPIOs are optional, but shouldn't we react somehow to real
> errors? I guess we should do something like:
> 
> ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
> if (IS_ERR(ddata->ini_gpio) {
> 	int err = PTR_ERR(ddata->ini_gpio);
> 	if (err = -EPROBE_DEFER || err != -ENOENT)
> 		return err;
> }

Yeah that makes sense to me.

Regards,

Tony

[PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
 arch/arm/boot/dts/omap3-evm-37xx.dts               | 50 +++++++++++++
 arch/arm/boot/dts/omap3-evm-common.dtsi            | 47 +++++++++++++
 arch/arm/boot/dts/omap3-ldp.dts                    | 31 ++++++--
 4 files changed, 205 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi

diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+		regulator-always-on;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+		panel-timing {
+			clock-frequency = <5400000>;
+			hback-porch = <39>;
+			hactive = <240>;
+			hfront-porch = <3>;
+			hsync-len = <3>;
+			vback-porch = <7>;
+			vactive = <320>;
+			vfront-porch = <2>;
+			vsync-len = <1>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	vdds_dsi-supply = <&vpll2>;
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -61,6 +66,48 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+			&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
+			&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
+			&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+
+	panel-timing {
+		clock-frequency = <19200000>;
+		hback-porch = <28>;
+		hactive = <480>;
+		hfront-porch = <1>;
+		hsync-len = <2>;
+		vback-porch = <1>;
+		vactive = <640>;
+		vfront-porch = <1>;
+		vsync-len = <1>;
+		hsync-active = <0>;
+		vsync-active = <0>;
+		de-active = <1>;
+		pixelclk-active = <1>;
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..50fdac9 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,7 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +174,31 @@
 	clock-frequency = <400000>;
 };
 
+&lcd_3v3 {
+	gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+	enable-active-high;
+};
+
+&lcd0 {
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	gpios = <&gpio2 24 GPIO_ACTIVE_LOW	/* gpio56, lcd MO */
+		 0				/* lcd LR */
+		 0				/* lcd UD */
+		 0>;				/* lcd INI */
+};
+
+&backlight0 {
+	gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};
-- 
1.8.1.1

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Joachim Eastwood]

On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> as various panel dpi entries for whatever legacy reasons. For device
> tree based support, let's just configure these properly for panel
> ls037v7dw01 instead of panel dpi.
>
> This patch creates a common file for panel ls037v7dw01, and makes
> boards ldp and omap3-evm to use it. The panel for ldp is configured
> in the qvga mode and omap3-evm panel in vga mode.
>
> The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> controller for the omaps, so let's add a basic configuration for
> the touchscreen also using the default values.
>
> Note that we can now remove the regulator-name = "vdds_dsi"
> entry for ldp, that's no longer needed as we have the entry
> for vdds_dsi-supply = <&vpll2>.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
>  arch/arm/boot/dts/omap3-evm-37xx.dts               | 50 +++++++++++++
>  arch/arm/boot/dts/omap3-evm-common.dtsi            | 47 +++++++++++++
>  arch/arm/boot/dts/omap3-ldp.dts                    | 31 ++++++--
>  4 files changed, 205 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi

> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> index 0abe986..50fdac9 100644
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -164,6 +164,7 @@
>
>  #include "twl4030.dtsi"
>  #include "twl4030_omap3.dtsi"
> +#include "omap-panel-sharp-ls037v7dw01.dtsi"
>
>  &i2c2 {
>         clock-frequency = <400000>;
> @@ -173,6 +174,31 @@
>         clock-frequency = <400000>;
>  };
>
> +&lcd_3v3 {
> +       gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> +       enable-active-high;
> +};
> +
> +&lcd0 {
> +       reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;     /* gpio55, lcd RESB */
> +       gpios = <&gpio2 24 GPIO_ACTIVE_LOW      /* gpio56, lcd MO */

enable-gpios ?

> +                0                              /* lcd LR */
> +                0                              /* lcd UD */
> +                0>;                            /* lcd INI */
> +};

regards
Joachim Eastwood

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> > as various panel dpi entries for whatever legacy reasons. For device
> > tree based support, let's just configure these properly for panel
> > ls037v7dw01 instead of panel dpi.
> >
> > This patch creates a common file for panel ls037v7dw01, and makes
> > boards ldp and omap3-evm to use it. The panel for ldp is configured
> > in the qvga mode and omap3-evm panel in vga mode.
> >
> > The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> > controller for the omaps, so let's add a basic configuration for
> > the touchscreen also using the default values.
> >
> > Note that we can now remove the regulator-name = "vdds_dsi"
> > entry for ldp, that's no longer needed as we have the entry
> > for vdds_dsi-supply = <&vpll2>.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> >  arch/arm/boot/dts/omap3-evm-37xx.dts               | 50 +++++++++++++
> >  arch/arm/boot/dts/omap3-evm-common.dtsi            | 47 +++++++++++++
> >  arch/arm/boot/dts/omap3-ldp.dts                    | 31 ++++++--
> >  4 files changed, 205 insertions(+), 5 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> 
> > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > index 0abe986..50fdac9 100644
> > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > @@ -164,6 +164,7 @@
> >
> >  #include "twl4030.dtsi"
> >  #include "twl4030_omap3.dtsi"
> > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> >
> >  &i2c2 {
> >         clock-frequency = <400000>;
> > @@ -173,6 +174,31 @@
> >         clock-frequency = <400000>;
> >  };
> >
> > +&lcd_3v3 {
> > +       gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > +       enable-active-high;
> > +};
> > +
> > +&lcd0 {
> > +       reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;     /* gpio55, lcd RESB */
> > +       gpios = <&gpio2 24 GPIO_ACTIVE_LOW      /* gpio56, lcd MO */
> 
> enable-gpios ?

Oops yes, changed from gpios to enable-gpios while reading the panel
binding doc, probably forgot to commit the change, will update.

Tony

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140430 10:48]:
> * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> > > as various panel dpi entries for whatever legacy reasons. For device
> > > tree based support, let's just configure these properly for panel
> > > ls037v7dw01 instead of panel dpi.
> > >
> > > This patch creates a common file for panel ls037v7dw01, and makes
> > > boards ldp and omap3-evm to use it. The panel for ldp is configured
> > > in the qvga mode and omap3-evm panel in vga mode.
> > >
> > > The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> > > controller for the omaps, so let's add a basic configuration for
> > > the touchscreen also using the default values.
> > >
> > > Note that we can now remove the regulator-name = "vdds_dsi"
> > > entry for ldp, that's no longer needed as we have the entry
> > > for vdds_dsi-supply = <&vpll2>.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > >  .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > >  arch/arm/boot/dts/omap3-evm-37xx.dts               | 50 +++++++++++++
> > >  arch/arm/boot/dts/omap3-evm-common.dtsi            | 47 +++++++++++++
> > >  arch/arm/boot/dts/omap3-ldp.dts                    | 31 ++++++--
> > >  4 files changed, 205 insertions(+), 5 deletions(-)
> > >  create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> > 
> > > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > > index 0abe986..50fdac9 100644
> > > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > > @@ -164,6 +164,7 @@
> > >
> > >  #include "twl4030.dtsi"
> > >  #include "twl4030_omap3.dtsi"
> > > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> > >
> > >  &i2c2 {
> > >         clock-frequency = <400000>;
> > > @@ -173,6 +174,31 @@
> > >         clock-frequency = <400000>;
> > >  };
> > >
> > > +&lcd_3v3 {
> > > +       gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > > +       enable-active-high;
> > > +};
> > > +
> > > +&lcd0 {
> > > +       reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;     /* gpio55, lcd RESB */
> > > +       gpios = <&gpio2 24 GPIO_ACTIVE_LOW      /* gpio56, lcd MO */
> > 
> > enable-gpios ?
> 
> Oops yes, changed from gpios to enable-gpios while reading the panel
> binding doc, probably forgot to commit the change, will update.

Here's an updated version of this one.

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+		regulator-always-on;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+		panel-timing {
+			clock-frequency = <5400000>;
+			hback-porch = <39>;
+			hactive = <240>;
+			hfront-porch = <3>;
+			hsync-len = <3>;
+			vback-porch = <7>;
+			vactive = <320>;
+			vfront-porch = <2>;
+			vsync-len = <1>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	vdds_dsi-supply = <&vpll2>;
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -61,6 +66,48 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+			&gpio1 2 GPIO_ACTIVE_HIGH	/* gpio2, lcd LR */
+			&gpio1 3 GPIO_ACTIVE_HIGH	/* gpio3, lcd UD */
+			&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+
+	panel-timing {
+		clock-frequency = <19200000>;
+		hback-porch = <28>;
+		hactive = <480>;
+		hfront-porch = <1>;
+		hsync-len = <2>;
+		vback-porch = <1>;
+		vactive = <640>;
+		vfront-porch = <1>;
+		vsync-len = <1>;
+		hsync-active = <0>;
+		vsync-active = <0>;
+		de-active = <1>;
+		pixelclk-active = <1>;
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..01b0808 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +178,27 @@
 	clock-frequency = <400000>;
 };
 
+&lcd_3v3 {
+	gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+	enable-active-high;
+};
+
+&lcd0 {
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	enable-gpios = <&gpio2 24 GPIO_ACTIVE_LOW	/* gpio56, lcd MO */
+			0				/* lcd LR */
+			0				/* lcd UD */
+			0>;				/* lcd INI */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140505 11:40]:
> * Tony Lindgren <tony@atomide.com> [140430 10:48]:
> > * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > > +       reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;     /* gpio55, lcd RESB */
> > > > +       gpios = <&gpio2 24 GPIO_ACTIVE_LOW      /* gpio56, lcd MO */
> > > 
> > > enable-gpios ?
> > 
> > Oops yes, changed from gpios to enable-gpios while reading the panel
> > binding doc, probably forgot to commit the change, will update.
> 
> Here's an updated version of this one.

One more update for the use of enable-gpios, reset-gpios and
mode-gpios to follow the binding described in simple-panel.txt.

Tomi feel free to pick this one up too, I'd assume you prefer
to do an immutable branch for the .dts changes that we both
can merge in as needed.

Regards,

Tony

8<-------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+		regulator-always-on;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+		panel-timing {
+			clock-frequency = <5400000>;
+			hback-porch = <39>;
+			hactive = <240>;
+			hfront-porch = <3>;
+			hsync-len = <3>;
+			vback-porch = <7>;
+			vactive = <320>;
+			vfront-porch = <2>;
+			vsync-len = <1>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	vdds_dsi-supply = <&vpll2>;
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -61,6 +66,48 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH	/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+
+	panel-timing {
+		clock-frequency = <19200000>;
+		hback-porch = <28>;
+		hactive = <480>;
+		hfront-porch = <1>;
+		hsync-len = <2>;
+		vback-porch = <1>;
+		vactive = <640>;
+		vfront-porch = <1>;
+		vsync-len = <1>;
+		hsync-active = <0>;
+		vsync-active = <0>;
+		de-active = <1>;
+		pixelclk-active = <1>;
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +178,24 @@
 	clock-frequency = <400000>;
 };
 
+&lcd_3v3 {
+	gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+	enable-active-high;
+};
+
+&lcd0 {
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	mode-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;	/* gpio56, lcd MO */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +270,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On 09/05/14 02:36, Tony Lindgren wrote:

> --- /dev/null
> +++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> @@ -0,0 +1,82 @@
> +/*
> + * Common file for omap dpi panels with QVGA and reset pins
> + *
> + * Note that the board specifc DTS file needs to specify
> + * at minimum the GPIO enable-gpios for display, and
> + * gpios for gpio-backlight.
> + */

This looks very board specific to me... The regulator and the use of
mcspi1 depend on the board, so this file can't be used on just any omap
board with the same panel. And this can (probably) only be used on
boards with a single display. Do those boards have tv-out?

So I have nothing against having common files, but shouldn't this be
named something more specific? If the boards involved are TI's OMAP3
development boards, maybe this should be something like...
omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.

> +/ {
> +	aliases {
> +		display0 = &lcd0;
> +	};
> +
> +	backlight0: backlight {
> +		compatible = "gpio-backlight";
> +	};
> +
> +	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
> +	lcd_3v3: regulator-lcd-3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "lcd_3v3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		startup-delay-us = <70000>;
> +		regulator-always-on;

Why always-on?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:08]:
> On 09/05/14 02:36, Tony Lindgren wrote:
> 
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * Common file for omap dpi panels with QVGA and reset pins
> > + *
> > + * Note that the board specifc DTS file needs to specify
> > + * at minimum the GPIO enable-gpios for display, and
> > + * gpios for gpio-backlight.
> > + */
> 
> This looks very board specific to me... The regulator and the use of
> mcspi1 depend on the board, so this file can't be used on just any omap
> board with the same panel. And this can (probably) only be used on
> boards with a single display. Do those boards have tv-out?

Yes there's also TV out and DVI on omap3-evm, LDP just has DVI.

It seems that all omap3 boards using this are pretty much wired
the same way.
 
> So I have nothing against having common files, but shouldn't this be
> named something more specific? If the boards involved are TI's OMAP3
> development boards, maybe this should be something like...
> omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.

Yeah let's use omap3-panel-sharp-ls037v7dw01.dtsi. Looking at the
legacy board files that should cover quite a few of them.

I guess it might also work on 2430sdp, but let's assume omap3
for now.
 
> > +/ {
> > +	aliases {
> > +		display0 = &lcd0;
> > +	};
> > +
> > +	backlight0: backlight {
> > +		compatible = "gpio-backlight";
> > +	};
> > +
> > +	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
> > +	lcd_3v3: regulator-lcd-3v3 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "lcd_3v3";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		startup-delay-us = <70000>;
> > +		regulator-always-on;
> 
> Why always-on?

Oops, yeah that should not be there. The GPIO is board specific.

Regards,

Tony

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140509 08:38]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:08]:
> > On 09/05/14 02:36, Tony Lindgren wrote:
> > Why always-on?
> 
> Oops, yeah that should not be there. The GPIO is board specific.

Oops, on ldp the regulator is always on tps61130rsa enabled by
twl4030 regen. Here's the updated patch with ldp support fixed
for the GPIOs tested with blank and bl_power.

Regards,

Tony

8< ------------------
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 8 May 2014 17:55:32 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_LOW>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -61,6 +66,32 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_LOW		/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +178,25 @@
 	clock-frequency = <400000>;
 };
 
+/* tps61130rsa enabled by twl4030 regen */
+&lcd_3v3 {
+	regulator-always-on;
+};
+
+&lcd0 {
+	enable-gpios = <&twl_gpio 15 GPIO_ACTIVE_HIGH>;	/* lcd INI */
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	mode-gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>;	/* gpio56, lcd MO */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -251,8 +275,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+		default-on;
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	vdds_dsi-supply = <&vpll2>;
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On 14/05/14 00:32, Tony Lindgren wrote:

> +&lcd0 {
> +	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
> +	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
> +	/*
> +	 * The LCD is sideways, so we want the VGA mode instead of
> +	 * QVGA mode. Probably also want to have omapfb.rotate=3
> +	 * in the kernel cmdline until there's a binding for that.
> +	 */
> +	mode-gpios = <&gpio5 26 GPIO_ACTIVE_LOW		/* gpio154, lcd MO */
> +		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
> +		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */

I don't think that is correct. The panel bindings should define what the
first mode-gpio means. Looking at the panel spec, I think the definition
should be "enable QVGA mode". And in the board's dts above, the
GPIO_ACTIVE_x should tell which is one is correct polarity for QVGA
mode. Which is GPIO_ACTIVE_HIGH here.

If we want to tell the panel driver to use QVGA mode, we should do that
explicitly with a flag, not by hacking the GPIO polarities. It's the
panel driver's job to set the GPIO.

So in the previous mail I suggested the 'vga-mode' flag, but I think we
need actually two flags for each GPIO: one that's used to tell the
driver which mode we want, which is used if the panel driver has control
for the GPIO, and the other that tells which is the hardwired setting.

Then again, the two cases are exclusive, so maybe a single flag per mode
pin is ok. So, for the MO pin, we could have 'qvga-mode' flag in the
.dts, which means:

"If there is MO gpio, set MO high. If there's no MO gpio, presume MO pin
is pulled up"

Of course, one could argue that, in case MO is controlled with GPIO, the
'qvga-mode' flag is about SW level configuration, not hardware...

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On 14/05/14 00:32, Tony Lindgren wrote:

> +&dss {
> +	status = "ok";
> +	vdds_dsi-supply = <&vpll2>;
> +	port {
> +		dpi_out: endpoint {
> +			remote-endpoint = <&lcd_in>;
> +			data-lines = <18>;
> +		};
> +	};
> +};

I just noticed the vdds_dsi-supply there. While the driver currently
uses that if available, I think it should be removed, and done the same
way Florian did with his overo patches:

/* Needed to power the DPI pins */
&vpll2 {
	regulator-always-on;
};

That supply is not DSS's supply, but it's used to power up the pins. If
the pins were used as GPIOs, that power should be enabled.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 05:45]:
> On 14/05/14 00:32, Tony Lindgren wrote:
> 
> > +&dss {
> > +	status = "ok";
> > +	vdds_dsi-supply = <&vpll2>;
> > +	port {
> > +		dpi_out: endpoint {
> > +			remote-endpoint = <&lcd_in>;
> > +			data-lines = <18>;
> > +		};
> > +	};
> > +};
> 
> I just noticed the vdds_dsi-supply there. While the driver currently
> uses that if available, I think it should be removed, and done the same
> way Florian did with his overo patches:
> 
> /* Needed to power the DPI pins */
> &vpll2 {
> 	regulator-always-on;
> };
> 
> That supply is not DSS's supply, but it's used to power up the pins. If
> the pins were used as GPIOs, that power should be enabled.

OK thanks for catching it.

Regards,

Tony

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140521 07:51]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 05:45]:
> > On 14/05/14 00:32, Tony Lindgren wrote:
> > 
> > > +&dss {
> > > +	status = "ok";
> > > +	vdds_dsi-supply = <&vpll2>;
> > > +	port {
> > > +		dpi_out: endpoint {
> > > +			remote-endpoint = <&lcd_in>;
> > > +			data-lines = <18>;
> > > +		};
> > > +	};
> > > +};
> > 
> > I just noticed the vdds_dsi-supply there. While the driver currently
> > uses that if available, I think it should be removed, and done the same
> > way Florian did with his overo patches:
> > 
> > /* Needed to power the DPI pins */
> > &vpll2 {
> > 	regulator-always-on;
> > };
> > 
> > That supply is not DSS's supply, but it's used to power up the pins. If
> > the pins were used as GPIOs, that power should be enabled.
> 
> OK thanks for catching it.

In case you did not yet do it, here's this patch updated for you. I'm
assuming you'll apply this to your panel dts branch. Let me know when the
dependencies are in linux next and I'll test it one more time. The omap
changes finally hit linux next as of today, so I'm only doing fixes
and minimal changes for now.

Regards,

Tony

8< ----------------------
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 27 May 2014 11:31:02 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_LOW>;
+};
 
 &twl {
 	twl_power: power {
@@ -68,6 +73,32 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_LOW		/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +178,25 @@
 	clock-frequency = <400000>;
 };
 
+/* tps61130rsa enabled by twl4030 regen */
+&lcd_3v3 {
+	regulator-always-on;
+};
+
+&lcd0 {
+	enable-gpios = <&twl_gpio 15 GPIO_ACTIVE_HIGH>;	/* lcd INI */
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	mode-gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>;	/* gpio56, lcd MO */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -251,8 +275,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+		default-on;
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140527 14:00]:
> * Tony Lindgren <tony@atomide.com> [140521 07:51]:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 05:45]:
> > > On 14/05/14 00:32, Tony Lindgren wrote:
> > > 
> > > > +&dss {
> > > > +	status = "ok";
> > > > +	vdds_dsi-supply = <&vpll2>;
> > > > +	port {
> > > > +		dpi_out: endpoint {
> > > > +			remote-endpoint = <&lcd_in>;
> > > > +			data-lines = <18>;
> > > > +		};
> > > > +	};
> > > > +};
> > > 
> > > I just noticed the vdds_dsi-supply there. While the driver currently
> > > uses that if available, I think it should be removed, and done the same
> > > way Florian did with his overo patches:
> > > 
> > > /* Needed to power the DPI pins */
> > > &vpll2 {
> > > 	regulator-always-on;
> > > };
> > > 
> > > That supply is not DSS's supply, but it's used to power up the pins. If
> > > the pins were used as GPIOs, that power should be enabled.
> > 
> > OK thanks for catching it.
> 
> In case you did not yet do it, here's this patch updated for you. I'm
> assuming you'll apply this to your panel dts branch. Let me know when the
> dependencies are in linux next and I'll test it one more time. The omap
> changes finally hit linux next as of today, so I'm only doing fixes
> and minimal changes for now.

Sorry here's the patch one more time with the regulator-always-on added.

FYI, I'm getting this with current linux next:

omapfb omapfb: failed to allocate framebuffer
omapfb omapfb: failed to allocate fbmem
omapfb omapfb: failed to setup omapfb
omapfb: probe of omapfb failed with error -12

Regards,

Tony

8< ---------------------
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 27 May 2014 11:31:02 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.

Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&dss_dpi_pins1
+		&dss_dpi_pins2
+	>;
+};
+
 &omap3_pmx_core {
+	dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
+			OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync */
+			OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync */
+			OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* dss_acbias.dss_acbias */
+
+			OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 */
+			OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 */
+			OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 */
+			OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 */
+			OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* dss_data10.dss_data10 */
+			OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* dss_data11.dss_data11 */
+			OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* dss_data12.dss_data12 */
+			OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* dss_data13.dss_data13 */
+			OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* dss_data14.dss_data14 */
+			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* dss_data15.dss_data15 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* dss_data16.dss_data16 */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* dss_data17.dss_data17 */
+
+			OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* dss_data18.dss_data0 */
+			OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* dss_data19.dss_data1 */
+			OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* dss_data20.dss_data2 */
+			OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* dss_data21.dss_data3 */
+			OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* dss_data22.dss_data4 */
+			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
+		>;
+	};
+
 	mmc1_pins: pinmux_mmc1_pins {
 		pinctrl-single,pins = <
 			0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
 	};
 };
 
+&omap3_pmx_wkup {
+	dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+		pinctrl-single,pins = <
+			0x0a (PIN_OUTPUT | MUX_MODE3)   /* sys_boot0.dss_data18 */
+			0x0c (PIN_OUTPUT | MUX_MODE3)   /* sys_boot1.dss_data19 */
+			0x10 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot3.dss_data20 */
+			0x12 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot4.dss_data21 */
+			0x14 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot5.dss_data22 */
+			0x16 (PIN_OUTPUT | MUX_MODE3)   /* sys_boot6.dss_data23 */
+		>;
+	};
+};
+
 &mmc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 18 GPIO_ACTIVE_LOW>;
+};
 
 &twl {
 	twl_power: power {
@@ -68,6 +73,32 @@
 	};
 };
 
+&lcd_3v3 {
+	gpio = <&gpio5 25 GPIO_ACTIVE_LOW>;	/* gpio153 */
+	enable-active-low;
+};
+
+&lcd0 {
+	enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;	/* gpio152, lcd INI */
+	reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd RESB */
+	/*
+	 * The LCD is sideways, so we want the VGA mode instead of
+	 * QVGA mode. Probably also want to have omapfb.rotate=3
+	 * in the kernel cmdline until there's a binding for that.
+	 */
+	mode-gpios = <&gpio5 26 GPIO_ACTIVE_LOW		/* gpio154, lcd MO */
+		      &gpio1 2 GPIO_ACTIVE_HIGH		/* gpio2, lcd LR */
+		      &gpio1 3 GPIO_ACTIVE_HIGH>;	/* gpio3, lcd UD */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio6>;
+		interrupts = <15 0>;		/* gpio175 */
+		pendown-gpio = <&gpio6 15 0>;
+	};
+};
+
 &mmc1 {
 	vmmc-supply = <&vmmc1>;
 	vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
 
 #include "twl4030.dtsi"
 #include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+	gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
 
 &i2c2 {
 	clock-frequency = <400000>;
@@ -173,6 +178,25 @@
 	clock-frequency = <400000>;
 };
 
+/* tps61130rsa enabled by twl4030 regen */
+&lcd_3v3 {
+	regulator-always-on;
+};
+
+&lcd0 {
+	enable-gpios = <&twl_gpio 15 GPIO_ACTIVE_HIGH>;	/* lcd INI */
+	reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;	/* gpio55, lcd RESB */
+	mode-gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>;	/* gpio56, lcd MO */
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 0>;		/* gpio54 */
+		pendown-gpio = <&gpio2 22 0>;
+	};
+};
+
 &mmc1 {
 	/* See 35xx errata 2.1.1.128 in SPRZ278F */
 	compatible = "ti,omap3-pre-es3-hsmmc";
@@ -251,8 +275,3 @@
 	/* Needed for ads7846 */
         regulator-name = "vcc";
 };
-
-&vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
-};
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	backlight0: backlight {
+		compatible = "gpio-backlight";
+		default-on;
+	};
+
+	/* 3.3V GPIO controlled regulator for LCD_ENVDD */
+	lcd_3v3: regulator-lcd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "lcd_3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <70000>;
+	};
+
+	lcd0: display {
+		compatible = "sharp,ls037v7dw01";
+		label = "lcd";
+		power-supply = <&lcd_3v3>;
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&dss {
+	status = "ok";
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
+};
+
+&mcspi1 {
+	tsc2046@0 {
+		reg = <0>;			/* CS0 */
+		compatible = "ti,tsc2046";
+		spi-max-frequency = <1000000>;
+		vcc-supply = <&lcd_3v3>;
+		ti,x-min = /bits/ 16 <0>;
+		ti,x-max = /bits/ 16 <8000>;
+		ti,y-min = /bits/ 16 <0>;
+		ti,y-max = /bits/ 16 <4800>;
+		ti,x-plate-ohms = /bits/ 16 <40>;
+		ti,pressure-max = /bits/ 16 <255>;
+		ti,swap-xy;
+		linux,wakeup;
+	};
+};
+
+/* Needed to power the DPI pins */
+&vpll2 {
+	regulator-always-on;
+};
+

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 352 bytes --]

On 28/05/14 00:14, Tony Lindgren wrote:

> FYI, I'm getting this with current linux next:
> 
> omapfb omapfb: failed to allocate framebuffer
> omapfb omapfb: failed to allocate fbmem
> omapfb omapfb: failed to setup omapfb
> omapfb: probe of omapfb failed with error -12

You need the attached patch to fix linux-next's dma alloc.

 Tomi


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-mm-compaction-properly-signal-and-act-upon-lock-and-.patch --]
[-- Type: text/x-patch; name="0001-mm-compaction-properly-signal-and-act-upon-lock-and-.patch", Size: 1155 bytes --]

From 88275fcdf6e7545e66fe35b822a41c9c017656f2 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Fri, 23 May 2014 10:18:56 +0200
Subject: [PATCH] 
 mm-compaction-properly-signal-and-act-upon-lock-and-need_sched-contention-fix2

Step 1: Change function name and comment between v1 and v2 so that the return
        value signals the opposite thing.
Step 2: Change the call sites to reflect the opposite return value.
Step 3: ???
Step 4: Make a complete fool of yourself.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 mm/compaction.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index a525cd47a9d5..51750197db11 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -237,13 +237,13 @@ static inline bool compact_should_abort(struct compact_control *cc)
 	if (need_resched()) {
 		if (cc->mode == MIGRATE_ASYNC) {
 			cc->contended = true;
-			return false;
+			return true;
 		}
 
 		cond_resched();
 	}
 
-	return true;
+	return false;
 }
 
 /* Returns true if the page is within a block suitable for migration to */
-- 
1.9.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On 27/05/14 23:59, Tony Lindgren wrote:

> In case you did not yet do it, here's this patch updated for you. I'm
> assuming you'll apply this to your panel dts branch. Let me know when the
> dependencies are in linux next and I'll test it one more time. The omap
> changes finally hit linux next as of today, so I'm only doing fixes
> and minimal changes for now.

I haven't pushed the dts changes to linux-next as the base branch was
missing. Now that it's there, I have pushed the DSS dts changes also.

You can do a manual merge if you want to try before linux-next is updated:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140429 16:53]:
> Hi all,
> 
> Here are few patches to add devicetree support for panel ls037v7dw01
> that's found on many omap3 boards. They seem to be often mis-configured
> as various panel dpi entries, but really should be move to use panel
> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
> ldp, omap3 evm and few other development boards.

Tomi, assuming no more comments, do you want to pick up the first
three patches of this series? I can queue the .dts changes or you
can also set up a separate .dts changes branch for DSS that I can
merge in too.

Tony
 
> Regards,
> 
> Tony
> 
> Tony Lindgren (4):
>   OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
>   OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
>   OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
>   ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
>     ldp
> 
>  .../bindings/panel/sharp,ls037v7dw01.txt           |  53 +++++++
>  .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi |  82 ++++++++++
>  arch/arm/boot/dts/omap3-evm-37xx.dts               |  50 ++++++
>  arch/arm/boot/dts/omap3-evm-common.dtsi            |  47 ++++++
>  arch/arm/boot/dts/omap3-ldp.dts                    |  31 +++-
>  .../omap2/displays-new/panel-sharp-ls037v7dw01.c   | 176 ++++++++++++++-------
>  drivers/video/fbdev/omap2/dss/dss.c                |   5 +-
>  7 files changed, 379 insertions(+), 65 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
>  create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> 
> -- 
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On 05/05/14 21:41, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Hi all,
>>
>> Here are few patches to add devicetree support for panel ls037v7dw01
>> that's found on many omap3 boards. They seem to be often mis-configured
>> as various panel dpi entries, but really should be move to use panel
>> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
>> ldp, omap3 evm and few other development boards.
> 
> Tomi, assuming no more comments, do you want to pick up the first
> three patches of this series? I can queue the .dts changes or you
> can also set up a separate .dts changes branch for DSS that I can
> merge in too.

If it's all the same to you, I'd like to collect all display related
arch/arm/ patches into my tree, and I'll send you a merge request when
it's stable.

I already have OMAP5 and AM43xx stuff there.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 02:34]:
> On 05/05/14 21:41, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140429 16:53]:
> >> Hi all,
> >>
> >> Here are few patches to add devicetree support for panel ls037v7dw01
> >> that's found on many omap3 boards. They seem to be often mis-configured
> >> as various panel dpi entries, but really should be move to use panel
> >> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
> >> ldp, omap3 evm and few other development boards.
> > 
> > Tomi, assuming no more comments, do you want to pick up the first
> > three patches of this series? I can queue the .dts changes or you
> > can also set up a separate .dts changes branch for DSS that I can
> > merge in too.
> 
> If it's all the same to you, I'd like to collect all display related
> arch/arm/ patches into my tree, and I'll send you a merge request when
> it's stable.
> 
> I already have OMAP5 and AM43xx stuff there.

Yes that works well for me.

Tony