Hi Tomi, > Am 06.11.2017 um 17:00 schrieb Tomi Valkeinen <tomi.valkeinen@xxxxxx>: > > 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@xxxxxxxxxxxxxxxx> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
