linux-kernel - [PATCH 0/2] drm/panel: Add support for Innolux LS075AT011

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200819101206.633253-1-lkundrak@v3.sk>
Date:   Wed, 19 Aug 2020 12:12:04 +0200
From:   Lubomir Rintel <lkundrak@...sk>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Sam Ravnborg <sam@...nborg.org>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] drm/panel: Add support for Innolux LS075AT011

Hi,

Please take a look at the patches chanied to this message and consider
applying them. They add description of the display panel found on OLPC
laptops to the simple panel driver.

There is no datasheet for the hardware and thus the timings were
determined on a best effort basis. The clock range is gotten from the
data sheet of the display controller [1] and the other timings are what
OLPC laptops actually use. The panel seems to cope with different sync
timings, but I'm not sure wherher there's any value in attempting to
figure out what range is actually permissible.

I could not figure out the right definitions for the connector and the
bus format. I'm not sure how necessary they are, but at least the
drm-panel driver insists on connector type being defined so I picked
LVDS because that seems to be used for internal laptop screens.

The signalling is not actually differential. It uses TTL levels with
data sampled on rising and falling clock edges; sort of like this (taken
from [1], P.20):

          __
    FSTH /  \_______________________________________
          ____      ____      ____      ____      __
    FCLK /    \____/    \____/    \____/    \____/
                  ____ ____ ____ ____ ____ ____ ____
    FD00 ........X____X____X____X____X____X____X____
                  ____ ____ ____ ____ ____ ____ ____
    FD01 ........X____X____X____X____X____X____X____
                  ____ ____ ____ ____ ____ ____ ____
    FD10 ........X____X____X____X____X____X____X____
                  ____ ____ ____ ____ ____ ____ ____
    FD11 ........X____X____X____X____X____X____X____
                  ____ ____ ____ ____ ____ ____ ____
    FD20 ........X____X____X____X____X____X____X____
                  ____ ____ ____ ____ ____ ____ ____
    FD21 ........X____X____X____X____X____X____X____
                   |    |    |    |
                   data 1    data 2   ...
                   (2x6bit)  (2x6bit)

I believe the data just carries brightness because each pixel on the
panel has a fixed color; with the red, green and blue pixels organized
in a pattern [2]. (The HX8837 that drives the color does the conversion
from RGB).

Tested on an OLPC XO-1.75 laptop. XO-1 and XO-1.5 use the same hardware,
but their display controllers are not supported by DRM at the moment.

[1] http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
[2] http://wiki.laptop.org/go/Display

Thank you!
Lubo