Hello, On Monday, 6 November 2017 19:52:53 EET H. Nikolaus Schaller wrote: > 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. Sorry for having broken the Pandora :( I believe I incorrectly matched on .family instead of .machine. Could you try the following patch ? I've only compile-tested it as I don't have access to any OMAP3 board using the DPI output right now. >From a2df9cde5b854cbb19a88b9dac9337d515dda713 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> Date: Tue, 7 Nov 2017 08:23:54 +0200 Subject: [PATCH] drm: omapdrm: Fix DPI on platforms using the DSI VDDS Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") replaced usage of platform data version with SoC matching to configure DPI VDDS. The SoC match entries were incorrect, they should have matched on the machine name instead of the SoC family. Fix it. Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code") Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> --- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c index daf286fc8a40..ca1e3b489540 100644 --- a/drivers/gpu/drm/omapdrm/dss/dpi.c +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll) } static const struct soc_device_attribute dpi_soc_devices[] = { - { .family = "OMAP3[456]*" }, - { .family = "[AD]M37*" }, + { .machine = "OMAP3[456]*" }, + { .machine = "[AD]M37*" }, { /* sentinel */ } }; -- Regards, Laurent Pinchart -- 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
