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

[Linus Walleij]

On Thu, Sep 6, 2018 at 10:25 PM Stefan Agner <stefan@xxxxxxxx> 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