Re: omapdrm: Pandora Blues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux