Request for OMAPDSS testing

Request for OMAPDSS testing

[Tomi Valkeinen]

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

Hi guys,

I've made some big changes on the omapdss device model, which involves
converting all the panel drivers. I've got only a bunch of boards, so I
hope some of you can perhaps do some minimal tests on some other boards.

I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.

The code can be found from the below git branch. It's based on 3.10-rc1.

git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model

All you need to do to get things working is to enable the new panel
drivers from kernel config, under Device drivers/Graphics support/OMAP2+
Display Subsystem support/OMAP Display Device Drivers/

Thanks in advance!

 Tomi


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

Re: Request for OMAPDSS testing

[Igor Grinberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tomi,

On 06/04/13 10:40, Tomi Valkeinen wrote:
> Hi guys,
> 
> I've made some big changes on the omapdss device model, which involves
> converting all the panel drivers. I've got only a bunch of boards, so I
> hope some of you can perhaps do some minimal tests on some other boards.
> 
> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
> 
> The code can be found from the below git branch. It's based on 3.10-rc1.
> 
> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
> 
> All you need to do to get things working is to enable the new panel
> drivers from kernel config, under Device drivers/Graphics support/OMAP2+
> Display Subsystem support/OMAP Display Device Drivers/

Thanks for the patches.
I still had no chance to look into them.
Hopefully, I will be able to do some tests on the next week.


- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRsHK8AAoJEBDE8YO64EfaSj8P/ilqGfiSYkZG/ZM4hwv+MFt+
0DllzT8zyHIPZVW7vzP2kCeBymZztpjrEYLkqnnXnv255EcYkAoDEPViHqv0L1h6
dQXSmMOsz9pgYANeDVhNG+PoP0DaBKWihZ7GVZ5MCROW+vSWLRpCIp8fIl7N+EGu
XzFkMSCApuKxFMDOcLppSXAQLdFDcjAeUIiMsYOdnjeNtOy1iXb4metqZ/Ckm7lM
KGP7H5eoHacrDwFZtmy7Glo4L+JEKzCkMfBr1tnMR5uTBDOzQAHDx0EP9mJ7Pjug
gSADHCMa63cCFkXaLKtptBOF8Lgb165XBhs3yRVY/WKm15l815tHQ8rOpWoiaSkx
LR65zuNsYTjMlaLNjJjVtpTb38+v/+IgMZzb7ALJJxsnSYDIXIx2qJkpVy7DVawK
G0Z1xO6xzaxjua0PFv0QWcH7ayI9HKsFr346e2Wk5gNvHTJzQfXN8P/CuMmgeU3o
KNCl+zMQ45bq4U9DfxlNjaswnWiY2GHaN3N8zjgVJCBXEHK7TJ4PSGhzpC262BwL
jKFxebzIPEMJDq1fBu5OQiHx8lyUw+fu0Z64O0x/O2fwYep2/bP3pWUcloLKVK1y
WmUcsl2P7lScchhqNHPYABEDiQDzT+ghp4nX5/WCRdy7qXskO1WPkrZjQaIKBFsX
zwx9ysTRKOYxn0ESCsPw
=QlvU
-----END PGP SIGNATURE-----

Re: Request for OMAPDSS testing

[Aaro Koskinen]

Hi,

On Tue, Jun 04, 2013 at 10:40:37AM +0300, Tomi Valkeinen wrote:
> I've made some big changes on the omapdss device model, which involves
> converting all the panel drivers. I've got only a bunch of boards, so I
> hope some of you can perhaps do some minimal tests on some other boards.
> 
> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
> 
> The code can be found from the below git branch. It's based on 3.10-rc1.
> 
> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
> 
> All you need to do to get things working is to enable the new panel
> drivers from kernel config, under Device drivers/Graphics support/OMAP2+
> Display Subsystem support/OMAP Display Device Drivers/

I tested Nokia N900 by pulling your tree and doing the following .config
changes:

	# CONFIG_PANEL_ACX565AKM is not set

	CONFIG_PANEL_SONY_ACX565AKM=y

The frame buffer console seems to work OK.

A.

Re: Request for OMAPDSS testing

[Tomi Valkeinen]

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

On 06/06/13 23:43, Aaro Koskinen wrote:
> Hi,
> 
> On Tue, Jun 04, 2013 at 10:40:37AM +0300, Tomi Valkeinen wrote:
>> I've made some big changes on the omapdss device model, which involves
>> converting all the panel drivers. I've got only a bunch of boards, so I
>> hope some of you can perhaps do some minimal tests on some other boards.
>>
>> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
>>
>> The code can be found from the below git branch. It's based on 3.10-rc1.
>>
>> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
>>
>> All you need to do to get things working is to enable the new panel
>> drivers from kernel config, under Device drivers/Graphics support/OMAP2+
>> Display Subsystem support/OMAP Display Device Drivers/
> 
> I tested Nokia N900 by pulling your tree and doing the following .config
> changes:
> 
> 	# CONFIG_PANEL_ACX565AKM is not set
> 
> 	CONFIG_PANEL_SONY_ACX565AKM=y
> 
> The frame buffer console seems to work OK.

Excellent, thanks!

 Tomi



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

Re: Request for OMAPDSS testing

[Grazvydas Ignotas]

Hello,

On Tue, Jun 4, 2013 at 10:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> I've made some big changes on the omapdss device model, which involves
> converting all the panel drivers. I've got only a bunch of boards, so I
> hope some of you can perhaps do some minimal tests on some other boards.

Doesn't work on pandora (legacy boardfile boot):

[    1.418823] OMAP DSS rev 2.0
[    1.447448] omapfb omapfb: no displays
[    1.454101] omapfb omapfb: failed to setup omapfb
[    1.459106] platform omapfb: Driver omapfb requests probe deferral
...
[    2.156860] panel-tpo-td043mtea1 spi1.1: failed to get LCD VCC regulator
[    2.164093] spi spi1.1: Driver panel-tpo-td043mtea1 requests probe deferral
...

Needs this small patch:

--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -335,7 +338,7 @@ static struct regulator_consumer_supply
pandora_vdds_supplies[] = {
 };

 static struct regulator_consumer_supply pandora_vcc_lcd_supply[] = {
-       REGULATOR_SUPPLY("vcc", "display0"),
+       REGULATOR_SUPPLY("vcc", "spi1.1"),
 };

 static struct regulator_consumer_supply pandora_usb_phy_supply[] = {

With that it shows Tux and fb console fine, so with above hunk:
Tested-by: Grazvydas Ignotas <notasas@gmail.com>


--
Gražvydas
--
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: Request for OMAPDSS testing

[Tomi Valkeinen]

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

On 09/06/13 17:28, Grazvydas Ignotas wrote:
> Hello,
> 
> On Tue, Jun 4, 2013 at 10:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> I've made some big changes on the omapdss device model, which involves
>> converting all the panel drivers. I've got only a bunch of boards, so I
>> hope some of you can perhaps do some minimal tests on some other boards.
> 
> Doesn't work on pandora (legacy boardfile boot):
> 
> [    1.418823] OMAP DSS rev 2.0
> [    1.447448] omapfb omapfb: no displays
> [    1.454101] omapfb omapfb: failed to setup omapfb
> [    1.459106] platform omapfb: Driver omapfb requests probe deferral
> ...
> [    2.156860] panel-tpo-td043mtea1 spi1.1: failed to get LCD VCC regulator
> [    2.164093] spi spi1.1: Driver panel-tpo-td043mtea1 requests probe deferral
> ...
> 
> Needs this small patch:
> 
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -335,7 +338,7 @@ static struct regulator_consumer_supply
> pandora_vdds_supplies[] = {
>  };
> 
>  static struct regulator_consumer_supply pandora_vcc_lcd_supply[] = {
> -       REGULATOR_SUPPLY("vcc", "display0"),
> +       REGULATOR_SUPPLY("vcc", "spi1.1"),
>  };
> 
>  static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
> 
> With that it shows Tux and fb console fine, so with above hunk:
> Tested-by: Grazvydas Ignotas <notasas@gmail.com>

Thanks, I've added the fix.

 Tomi



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

Re: Request for OMAPDSS testing

[Igor Grinberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tomi,

On 06/04/13 10:40, Tomi Valkeinen wrote:
> Hi guys,
> 
> I've made some big changes on the omapdss device model, which involves
> converting all the panel drivers. I've got only a bunch of boards, so I
> hope some of you can perhaps do some minimal tests on some other boards.
> 
> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
> 
> The code can be found from the below git branch. It's based on 3.10-rc1.
> 
> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model

Works on cm-t3730.
Tested with tdo24m LCD and DVI.

Although one thing is missing from the tfp410 driver is
the PD GPIO polarity. I had to adjust it locally to get the DVI working.
The original polarity was high = disabled, low = enabled.


- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRuep6AAoJEBDE8YO64EfaXsIP/19xfE9BlqtswMRgr3uOEaJf
gnh9JcwMebMWiCFcyCw96EP7C/oW6GmVdyGDLnZmjJ9ZqA1al0I4Lia1LDJDNxtZ
EDLIAaY1Wf4JN0wcVVAy1o4jHiYu6jpLLME3JNXGU6HwUgrSEcXOBd62veIjHcE3
f1p3HvGvfXJxU0/7JCohpRteTIqXjmG9BxBcyAnes0lhBozOwIOO0uLtiH+XeSJe
Sn907bkdFk6qG8m+FSQWyJZMKLGZuE0nNOQ2obMeXk6nvj8TnO9x4W51I5DnsfgT
ZnCtcnuC3RGLo1YmUBFSBDLsd9VZgD3K2c/ysfpwM9Os2XvImGbUkX6ToJ4iMr0T
Ika2ljsMCbObbqQGiSbEM7JiOOc5QL6AB4b+uwD8VEDd4JwzkaMugBSYn8B38y5u
PxCFWMihZGlyWVHS+qwON+cS59Y1xj0b7pvQRlar+ufQDk/gQBPNbJFnzIaU8B3D
6qx9TL7QmPJ172+dVIbcWLMMLLwa5ityajIaETgmQw6GMNLyUghf50I6k8rRHnzc
JA3UFkeYGplYfVPHpWM2fNvSDin9yTELbGty0QzszlUWRHqpmXlyEYk/VMShWE8h
LNKv+FZ1VwNFD3PmZINVB4IWflT9X/52hgrrACxBVAPG7xhahGA+XV6e10zc1cPd
7dnQIlL7OugAAWC5ttaw
=sLEz
-----END PGP SIGNATURE-----

Re: Request for OMAPDSS testing

[Tomi Valkeinen]

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

On 13/06/13 18:51, Igor Grinberg wrote:
> Hi Tomi,
> 
> On 06/04/13 10:40, Tomi Valkeinen wrote:
>> Hi guys,
> 
>> I've made some big changes on the omapdss device model, which involves
>> converting all the panel drivers. I've got only a bunch of boards, so I
>> hope some of you can perhaps do some minimal tests on some other boards.
> 
>> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
> 
>> The code can be found from the below git branch. It's based on 3.10-rc1.
> 
>> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
> 
> Works on cm-t3730.
> Tested with tdo24m LCD and DVI.

Thanks!

> Although one thing is missing from the tfp410 driver is
> the PD GPIO polarity. I had to adjust it locally to get the DVI working.
> The original polarity was high = disabled, low = enabled.

Hmm, but this is missing from the old driver also, isn't it? At least
with a quick glance the old and new tfp410 drivers do the same thing
with the PD gpio.

 Tomi


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

Re: Request for OMAPDSS testing

[Igor Grinberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 06/13/13 19:01, Tomi Valkeinen wrote:
> On 13/06/13 18:51, Igor Grinberg wrote:
>> Hi Tomi,
>>
>> On 06/04/13 10:40, Tomi Valkeinen wrote:
>>> Hi guys,
>>
>>> I've made some big changes on the omapdss device model, which involves
>>> converting all the panel drivers. I've got only a bunch of boards, so I
>>> hope some of you can perhaps do some minimal tests on some other boards.
>>
>>> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
>>
>>> The code can be found from the below git branch. It's based on 3.10-rc1.
>>
>>> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
>>
>> Works on cm-t3730.
>> Tested with tdo24m LCD and DVI.
> 
> Thanks!
> 
>> Although one thing is missing from the tfp410 driver is
>> the PD GPIO polarity. I had to adjust it locally to get the DVI working.
>> The original polarity was high = disabled, low = enabled.
> 
> Hmm, but this is missing from the old driver also, isn't it? At least
> with a quick glance the old and new tfp410 drivers do the same thing
> with the PD gpio.

Well, we were driving the PD GPIO from the board file...


- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRva9qAAoJEBDE8YO64EfayBcP/iE1iVjdcYgf6SCw7IyrXHpC
CUEroVpfQiLP8MwJ/ZNuGWwsFWbrD+Q8j5vSLJapjn1QPD3VEH830FXfWNzxxvhD
ZWk5C3rsXy9q7FWonHixpbdPQnEptCBKkHqgpVPuLTaywC2h2jUxZoVLmBhbSoBo
TQG210CxxE18qK+ztolxScA4ZlYwOAUPSNNJ2zE9UGI2n/8UrW9y0PJLluM2cAOd
odlEuDNGmVmkbPsnRTI52r8IqhprrWC7S+5J1rsprJylgrudQXW0cSKJ7wi2bxy4
JWJd3C+pD7ocyRp76pm/kXD6NSAgrhqqHnbXK82DDlJvewAUOlF23iOIiXnsEDIY
Uui4EvGVrzQl0Pe8eIxRIZzhJ2n7ryZ7360w0xiKc++X3s34kJ/mATlQi8Sm4Ve/
gbIqJRirdsvTDbxSwUOTX14qJvkZBvPA6Os1qSXmLsF7/DDUf3OreWL7JksKuxlI
1sGtvS7Y7IP7Wyr4PcEC6cb8Dy6GLT0o5GZWSC/VIPwHl+MlZMsMz4sp9AbuDrjQ
TsoBmPpGi2/1i9+aCIeTzzgK9dZ320PlEYClXXvWOlG9YRqD01PIfhm4YfbCw0Dc
/wr5mjTxkCvtcYY2uSbW0+xlBFNwPFinRGw+tXv5q/6xjh27BNmyVNLlvGawcKgc
NrkwMGcNV0txD8TFhnEh
=IxQT
-----END PGP SIGNATURE-----

Re: Request for OMAPDSS testing

[Tomi Valkeinen]

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

On 16/06/13 15:28, Igor Grinberg wrote:

>>> Although one thing is missing from the tfp410 driver is
>>> the PD GPIO polarity. I had to adjust it locally to get the DVI working.
>>> The original polarity was high = disabled, low = enabled.
> 
>> Hmm, but this is missing from the old driver also, isn't it? At least
>> with a quick glance the old and new tfp410 drivers do the same thing
>> with the PD gpio.
> 
> Well, we were driving the PD GPIO from the board file...

Ah, I see. That was inverted PD handling was removed in 3.5, by accident
as far as I see. So DVI on cm-t35 has been broken since?

I wonder how that should be fixed... The tfp410 driver handles it
correctly, as the PD gpio is active low (i.e. high == tfp410 enabled),
so having it inverted is a board specific thing. Do you know what is the
reason to have it inverted?

There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be
used, as I don't see anyone setting that flag... And supporting that
would mean, in principle, that every driver should support inverting the
gpio with every gpio they have.

 Tomi


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

Re: Request for OMAPDSS testing

[Igor Grinberg]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 06/17/13 10:08, Tomi Valkeinen wrote:
> On 16/06/13 15:28, Igor Grinberg wrote:
> 
>>>> Although one thing is missing from the tfp410 driver is
>>>> the PD GPIO polarity. I had to adjust it locally to get the DVI working.
>>>> The original polarity was high = disabled, low = enabled.
>>
>>> Hmm, but this is missing from the old driver also, isn't it? At least
>>> with a quick glance the old and new tfp410 drivers do the same thing
>>> with the PD gpio.
>>
>> Well, we were driving the PD GPIO from the board file...
> 
> Ah, I see. That was inverted PD handling was removed in 3.5, by accident
> as far as I see. So DVI on cm-t35 has been broken since?

Well, we have applied the below patches since then (the patches are against 3.7),
but haven't had time to send it upstream...

> 
> I wonder how that should be fixed... The tfp410 driver handles it
> correctly, as the PD gpio is active low (i.e. high == tfp410 enabled),
> so having it inverted is a board specific thing. Do you know what is the
> reason to have it inverted?

Yes, the reason for this is the sb-t35 (the baseboard) which has the TFP410
in 3.3V domain, but the cm-t3530/3730 are in 1.8V domain.
This means that the line must be shifted.
Now for some reason hardware guys used an inverter as the level shifter
instead of a simple buffer. So now it is shifted and inverted...

> 
> There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be
> used, as I don't see anyone setting that flag... And supporting that
> would mean, in principle, that every driver should support inverting the
> gpio with every gpio they have.

Might be worth to consider adding this functionality to the GPIOLIB?
Meanwhile, I think the simplest way would be to add a boolean
like OF_GPIO_ACTIVE_LOW, as we have hardware that needs it.

If you think the patches are conceptually fine,
I can rebase them on top of your tree with the new drivers and
submit properly.

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBAgAGBQJRvstaAAoJEBDE8YO64EfatIMQAJbAO7rkQNTlTwL4qkANZV7h
v1msnUbjuiGr5hb34UX07b3lBoIXkI9Uqt6rC25vbIDZPW8EaKmMwLle87aXpAVI
QsA8wujQx7p1S9oLjVSdu1AZeQZv4vHBZPU5R/xlOGocbs2TgJ1/Pn4eYVKDHW9Q
Sv3wHwiZgkwOT+7nAe7mAmuLsWl62rxF94Psw4imC9M35wpxat9hXWaIJPu6WwRS
DdaySlfxasG9aMg/CMCxf8Cjcmk4cKjJ8vRVhmW0J1ISuUofSfxiL6K611bTjaqb
oCO8qTxThLebTlvW6LrVZ8Etcr4HAp2zG6o0ZZmdYxMROJ9feMhJgZ7dIwUSOlK5
OSwAyfGsG1m4EqnfokgRx6Eg+ur2VirqZ6NcXEt5ljHHfnu4VeY/glHpSnfuwsN8
e27tSlJXv15EXEcASFqaujDUzV7qPYYcLYy5Wssjg9V/RTZoT3kHhouNnE5/doP+
d7qC/nheG6O3iT2cT4OMcnBi9nywaOR7ogMgauGZjDCB9pLrvTe4iBJFgfa2CkC3
QlB8lD8+tUXC6kGhlYv9RaZy/MP8CQWAYCel0k4vbjAB/KvY0KNHMpwmTzfGALhB
LI2/swhSpE6+0q3M3tylds15HQCmNSmO/1AVRdvgrJQXZbGz8PBCuxH7QqInS/ob
JXjx9lUaw9tRsVQKcqPp
=5nPt
-----END PGP SIGNATURE-----

[-- Attachment #2: 0001-OMAPDSS-TFP410-support-edge-select-pin-strap.patch --]
[-- Type: text/x-patch, Size: 2446 bytes --]

>From 4eaa3d23ba484370c6b709ff21ca764a47033f34 Mon Sep 17 00:00:00 2001
From: Dmitry Lifshitz <lifshitz@compulab.co.il>
Date: Wed, 9 Jan 2013 14:04:08 +0200
Subject: [PATCH] OMAPDSS: TFP410: support edge select pin strap

Pin 9 (EDGE/HTPLG) of tfp410 DVI transmitter is used (when I2C is
disabled) to control the data sampling on the rising or falling
edge of the pixel clock.

OMAP DSS timings for tfp410 should be adjusted according to
the chip pin strap to avoid various visual artifacts in the DVI output.

Enhance the tfp410 driver platform data with the flag to modify
default tfp410 timing settings according to the chip pin strap.

Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
 drivers/video/omap2/displays/panel-tfp410.c |    8 ++++++++
 include/video/omap-panel-tfp410.h           |    3 +++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index e611ebd..77ce139 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -115,6 +115,14 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
 		ddata->pd_gpio = pdata->power_down_gpio;
 		ddata->invert_pd_gpio = pdata->invert_pd_gpio;
 		i2c_bus_num = pdata->i2c_bus_num;
+
+		/*
+		 * If the data latch occur on the rising edge of the pixel
+		 * clock, then the data strobe should be on the falling edge.
+		 */
+		if (pdata->latch_on_rising_edge)
+			dssdev->panel.timings.data_pclk_edge =
+					OMAPDSS_DRIVE_SIG_FALLING_EDGE;
 	} else {
 		ddata->pd_gpio = -EINVAL;
 		i2c_bus_num = -1;
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
index cd1061e..f5424aa 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -27,11 +27,14 @@ struct omap_dss_device;
  * @i2c_bus_num: i2c bus id for the panel
  * @power_down_gpio: gpio number for PD pin (or -EINVAL if not available)
  * @invert_pd_gpio: invert PD pin logic level (0 - is a power on state)
+ * @latch_on_rising_edge : select the edge (0 - falling, 1 - rising) of the input clock
+ *                         when the primary latch occur.
  */
 struct tfp410_platform_data {
 	int i2c_bus_num;
 	int power_down_gpio;
 	bool invert_pd_gpio;
+	bool latch_on_rising_edge;
 };
 
 #endif /* __OMAP_PANEL_TFP410_H */
-- 
1.7.3.4


[-- Attachment #3: 0001-OMAPDSS-TFP410-use-EINVAL-for-invalid-PD-GPIO.patch --]
[-- Type: text/x-patch, Size: 4433 bytes --]

>From ed3da0d17f659889a1cc020e53cd0e4d2950dbae Mon Sep 17 00:00:00 2001
From: Dmitry Lifshitz <lifshitz@compulab.co.il>
Date: Wed, 26 Dec 2012 10:08:55 +0200
Subject: [PATCH 1/2] OMAPDSS: TFP410: use -EINVAL for invalid PD GPIO

power_down_gpio field of tfp410_platform_data structure
can have -1 value in case power down GPIO is not available.
Although the gpiolib does not define strictly which negative number
should be used to specify invalid GPIO, we should follow the common
practice and use -EINVAL.

This patch changes platform data comments and the driver to
work with -EINVAL and propagates the change through the relevant board
files.

Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
 arch/arm/mach-omap2/board-3430sdp.c         |    2 +-
 arch/arm/mach-omap2/board-am3517evm.c       |    2 +-
 arch/arm/mach-omap2/board-devkit8000.c      |    2 +-
 arch/arm/mach-omap2/board-omap3beagle.c     |    2 +-
 arch/arm/mach-omap2/board-overo.c           |    2 +-
 drivers/video/omap2/displays/panel-tfp410.c |    2 +-
 include/video/omap-panel-tfp410.h           |    2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 09e1790..f33a6e4 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -156,7 +156,7 @@ static struct omap_dss_device sdp3430_lcd_device = {
 };
 
 static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
+	.power_down_gpio	= -EINVAL,
 	.i2c_bus_num		= -1,
 };
 
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 370c54d..6aa182f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -207,7 +207,7 @@ static struct omap_dss_device am3517_evm_tv_device = {
 };
 
 static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
+	.power_down_gpio	= -EINVAL,
 	.i2c_bus_num		= -1,
 };
 
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 6f04f0f..e655b07 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -138,7 +138,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
 };
 
 static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
+	.power_down_gpio	= -EINVAL,
 	.i2c_bus_num		= 1,
 };
 
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index d41ab98..2aef549 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -194,7 +194,7 @@ static struct mtd_partition omap3beagle_nand_partitions[] = {
 
 static struct tfp410_platform_data dvi_panel = {
 	.i2c_bus_num = 3,
-	.power_down_gpio = -1,
+	.power_down_gpio = -EINVAL,
 };
 
 static struct omap_dss_device beagle_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index b700685..73e8349 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -167,7 +167,7 @@ static void __init overo_display_init(void)
 
 static struct tfp410_platform_data dvi_panel = {
 	.i2c_bus_num		= 3,
-	.power_down_gpio	= -1,
+	.power_down_gpio	= -EINVAL,
 };
 
 static struct omap_dss_device overo_dvi_device = {
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 383811c..2ddb7e1 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -114,7 +114,7 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
 		ddata->pd_gpio = pdata->power_down_gpio;
 		i2c_bus_num = pdata->i2c_bus_num;
 	} else {
-		ddata->pd_gpio = -1;
+		ddata->pd_gpio = -EINVAL;
 		i2c_bus_num = -1;
 	}
 
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
index aef35e4..4431c37 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -25,7 +25,7 @@ struct omap_dss_device;
 /**
  * struct tfp410_platform_data - panel driver configuration data
  * @i2c_bus_num: i2c bus id for the panel
- * @power_down_gpio: gpio number for PD pin (or -1 if not available)
+ * @power_down_gpio: gpio number for PD pin (or -EINVAL if not available)
  */
 struct tfp410_platform_data {
 	int i2c_bus_num;
-- 
1.7.3.4


[-- Attachment #4: 0002-OMAPDSS-TFP410-support-inverted-power-down-GPIO.patch --]
[-- Type: text/x-patch, Size: 2575 bytes --]

>From ee916068b7874fe4cd8614466afeb60a401505d1 Mon Sep 17 00:00:00 2001
From: Dmitry Lifshitz <lifshitz@compulab.co.il>
Date: Wed, 26 Dec 2012 11:30:29 +0200
Subject: [PATCH 2/2] OMAPDSS: TFP410: support inverted power down GPIO

tfp410 chip integration on a specific board may require inverted
logic of the power down GPIO.
Enhance tfp410 driver platform data with flag to invert power down GPIO
logic level.

Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
 drivers/video/omap2/displays/panel-tfp410.c |    6 ++++--
 include/video/omap-panel-tfp410.h           |    2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 2ddb7e1..e611ebd 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -53,6 +53,7 @@ struct panel_drv_data {
 	struct mutex lock;
 
 	int pd_gpio;
+	bool invert_pd_gpio;
 
 	struct i2c_adapter *i2c_adapter;
 };
@@ -73,7 +74,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
 		goto err0;
 
 	if (gpio_is_valid(ddata->pd_gpio))
-		gpio_set_value_cansleep(ddata->pd_gpio, 1);
+		gpio_set_value_cansleep(ddata->pd_gpio, !ddata->invert_pd_gpio);
 
 	return 0;
 err0:
@@ -88,7 +89,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
 		return;
 
 	if (gpio_is_valid(ddata->pd_gpio))
-		gpio_set_value_cansleep(ddata->pd_gpio, 0);
+		gpio_set_value_cansleep(ddata->pd_gpio, ddata->invert_pd_gpio);
 
 	omapdss_dpi_display_disable(dssdev);
 }
@@ -112,6 +113,7 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
 		struct tfp410_platform_data *pdata = dssdev->data;
 
 		ddata->pd_gpio = pdata->power_down_gpio;
+		ddata->invert_pd_gpio = pdata->invert_pd_gpio;
 		i2c_bus_num = pdata->i2c_bus_num;
 	} else {
 		ddata->pd_gpio = -EINVAL;
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
index 4431c37..cd1061e 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -26,10 +26,12 @@ struct omap_dss_device;
  * struct tfp410_platform_data - panel driver configuration data
  * @i2c_bus_num: i2c bus id for the panel
  * @power_down_gpio: gpio number for PD pin (or -EINVAL if not available)
+ * @invert_pd_gpio: invert PD pin logic level (0 - is a power on state)
  */
 struct tfp410_platform_data {
 	int i2c_bus_num;
 	int power_down_gpio;
+	bool invert_pd_gpio;
 };
 
 #endif /* __OMAP_PANEL_TFP410_H */
-- 
1.7.3.4


[-- Attachment #5: 0001-OMAPDSS-TFP410-support-edge-select-pin-strap.patch.sig --]
[-- Type: application/pgp-signature, Size: 543 bytes --]

[-- Attachment #6: 0001-OMAPDSS-TFP410-use-EINVAL-for-invalid-PD-GPIO.patch.sig --]
[-- Type: application/pgp-signature, Size: 543 bytes --]

[-- Attachment #7: 0002-OMAPDSS-TFP410-support-inverted-power-down-GPIO.patch.sig --]
[-- Type: application/pgp-signature, Size: 543 bytes --]

Re: Request for OMAPDSS testing

[Tomi Valkeinen]

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

On 17/06/13 11:40, Igor Grinberg wrote:

> Yes, the reason for this is the sb-t35 (the baseboard) which has the TFP410
> in 3.3V domain, but the cm-t3530/3730 are in 1.8V domain.
> This means that the line must be shifted.
> Now for some reason hardware guys used an inverter as the level shifter
> instead of a simple buffer. So now it is shifted and inverted...

Sigh =).

>> There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be
>> used, as I don't see anyone setting that flag... And supporting that
>> would mean, in principle, that every driver should support inverting the
>> gpio with every gpio they have.
> 
> Might be worth to consider adding this functionality to the GPIOLIB?
> Meanwhile, I think the simplest way would be to add a boolean
> like OF_GPIO_ACTIVE_LOW, as we have hardware that needs it.
> 
> If you think the patches are conceptually fine,
> I can rebase them on top of your tree with the new drivers and
> submit properly.

Yes, the patches look conceptually fine. I don't like it that the TFP410
driver has to have extra functionality to handle board oddities, but
then again, it's just a few lines of code and I don't have any better
idea how to solve it. A gpiochip driver that handles the inversion
sounds a bit overkill...

The 3.11 kernel will have two versions of tfp410 driver, the old one and
the one using the new dss device model. If possible, I'd like to have
the modifications only for the new one.

 Tomi


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