linux-kernel - Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdaUuWUHZgT0b64hMNZm3oy=7rece3H0p5VVe4d8jpFRaw@mail.gmail.com>
Date:   Fri, 7 Sep 2018 09:10:27 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Stefan Agner <stefan@...er.ch>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Dave Airlie <airlied@...ux.ie>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        NXP Linux Team <linux-imx@....com>,
        Archit Taneja <architt@...eaurora.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Gustavo Padovan <gustavo@...ovan.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        sean@...rly.run, Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        max.krummenacher@...adex.com,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings

On Thu, Sep 6, 2018 at 10:25 PM Stefan Agner <stefan@...er.ch> wrote:

> Ok, I read a bit up on the history of bridge timing, especially:
> https://www.spinics.net/lists/dri-devel/msg155618.html
>
> IMHO, this got overengineered. For displays we do not need all that
> setup/sample delay timing information, and much longer cables are in
> use. So why is all that needed for bridges?

I also avoided the overhead of creating this abstraction initially.

But after doing it I have this Stockholm syndrome that I start
liking what Laurent told me to do.

> For Linus case, the THS8134(A/B) data sheet I found (revised March 2010)
> clearly states:
> Clock input. A rising edge on CLK latches RPr0-7, GY0-7, BPb0-7.
>
> So we need to drive on negative edge, hence DRM_BUS_FLAG_PIXDATA_NEGEDGE
> should be used, which makes the pl111 driver setting TIM2_IPC:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0121d/index.html

That is easy to say, but if I just set that up in code, even with a good
comment it is hard for the next reader to understand what is going
on. The central question will be, why does PL111 need to do this
but not R-Car though they are using the same bridge?

So this elaborate model gives a better transfer of abstract concepts
to whoever needs to touch that code next. The code is not just
logic, but also our map of the world and the documentation of our
problem space.

Donald Knuth has this idea about literate programming which even
turns the documentation/implementation process around. We are
not there, not even remotely, but IMO the more complex the problem.
the more we need to convey our thinking, not just our solution.

Yours,
Linus Walleij