Hi Tomi,
Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 06/11/17 16:04, H. Nikolaus Schaller wrote:
Hi, some time after upgrading to 4.14-rc* I tried to boot the OpenPandora. It turned out that the display panel has a bug - it only shows black/blue colors instead of RGB.
Some tests revealed that something happened between 4.13.0 and 4.14-rc1. Here are screen photos:
4.13.0: http://download.goldelico.com/letux-kernel/files/thumb_DSC00812_1024.jpeg 4.14-rc1: http://download.goldelico.com/letux-kernel/files/thumb_DSC00813_1024.jpeg
But only for the OpenPandora. For the GTA04 it works.
Well, the GTA04 is using a different panel "toppoly,td028ttec1" and driver instead of "omapdss,tpo,td043mtea1". [BTW: there seems to be some mixup of "compatible" schemes].
Omapdss boot-time code will prepend the compatibles with "omapdss,". The point is that the DTS is generic, but we'll still end up matching with the omapdss specific drivers. It's a temporary hack, and gets dropped as soon as we can use the common DRM panel model.
So which one is the "future proof"?
compatible = "toppoly,td028ttec1"
or
compatible = "omapdss,tpo,td043mtea1"
Somehow, both seem to work (up to 4.13.x) on different devices.
Anyways, "toppoly" should be "tpo" according to Documentation/devicetree/bindings/vendor-prefixes.txt I'll add this to the patches we will need...
And there is also another difference between both: the Pandora 600MHz uses an OMAP3530 while the GTA04 uses a DM3730.
So something has become incompatible with *some* DPI panel drivers.
After more than a week of bisecting in parallel to important other tasks (it takes ca. 30-60 minutes for each run to add local patches, compile, install, boot, check results - just to find some "[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000"), I ended up with a specific result:
iMac:master hns$ git bisect bad d178e034d5653edfbd16d0c71eeeed467e33c96f is the first bad commit commit d178e034d5653edfbd16d0c71eeeed467e33c96f Author: Laurent Pinchart laurent.pinchart@ideasonboard.com Date: Sat Aug 5 01:44:12 2017 +0300
drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
The FEAT_DPI_USES_VDDS_DSI feature is specific to the DPI, move it from the omap_dss_features structure to the dpi code.
Well, the patch is simple enough... For some reason, the soc_device_match(dpi_soc_devices) call there doesn't match Pandora.
Ah, I see.
If VDDS_DSI isn't enabled it garbles the panel RGB signals. That would explain a lot. It is still funny why it only affects the Red and Green channel, but that may have to do something with the pad drivers inside the chip. Maybe those for Blue are powered differently...
I don't have a device up and running now, but I think the "family" string that it tries to match can also be seen somewhere under /proc, so you could perhaps find it and see if it actually is OMAP3530, which should be matched by the code.
Or I add a printk() to watch what it tries to find. That should be a quite simple test.
BR and thanks, Nikolaus