[RFC 00/16] Armada DRM support for OLPC XO-1.75 laptop

[Daniel Vetter]

On Wed, Dec 19, 2018 at 9:40 AM Lubomir Rintel <lkundrak at v3.sk> wrote:
>
> Hi,
>
> here are patches that make the Armada DRM work on an OLPC XO-1.75.
> They build on patches previously submitted by Russel King (included here for
> completeness as well).
>
> They certainly need some more love, but I'm not able to improve them until
> I get to understand some things first. I'm posting a couple of questions
> below in hope someone is kind enough to help me deal with my confusion.
>
> The display pipeline on the laptop looks like this:
>
>   Armada LCDC
>   -----------
>       |
>       v
>
>   Himax HX8837 "DCON"
>   -------------------
>   RGB input from LCDC
>   Controlled via I2C
>   Backlight control
>   Can slow down the panel refresh rate to save power
>   Optional dithering for color mode, "swizzling"
>   Has DRAM attached, can freeze a single frame in it
>   Doc: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
>       |
>       v
>
>   Innolux LS075AT011 Panel
>   ------------------------
>   7.5", 1200x900
>   No datasheet.
>   http://wiki.laptop.org/go/Display
>   Can opreate in two modes:
>
>    R G B
>    G B R ...   or   "e-book" daylight readable
>    B R G            reflexive B&W
>      .
>      :
>
> Here's what's not clear to me:
>
> 1.) Is the Himax chip an encoder here?

Since it's an external IP probably better to model it as a bridge.

> 2.) What's the use of an encoder anyways? If a panel was connected directly
>     do the RGB output from the LCDC, would we have to fake one? Is that the
>     point of things like i.MX driver's drivers/gpu/drm/imx/parallel-display.c?

encoder is the thing between crtc and connector. It's exposed to
userspace (which is a uapi design accident, but can't change that),
hence why it's required and some drivers have dummy ones.

The real usage is purely internally for the atomic helpers. Most
callbacks in the encoder should be optional, so a dummy encoder should
be a lot thinner than your imx example. The imx example should be
using the panel-bridge I think, which would take care of most of the
boilerplate (but panel-bridge didn't exist back then I guess).

> 3.) My patch set currently contains the driver for the Himax that is
>     modelled after tda998x. That one implements an encoder. Similar drivers
>     seem to add a bridge too, but it's not entirely clear to me what a bridge
>     is good for?

tda998x predates bridges, which is why there's still some
encoder_helper usage in there. It's become a proper bridge driver now
I think (but some drivers still use the old interface). All new
transcoder chip drivers should be bridges. Did you look at the
kerneldoc for bridges? If those aren't clear we need to fix them.

> 4.) How shall I expose the fancy functionality of the Himax to the userspace?
>     Notably, the freeze frame. The OLPC laptops with the stock firmware like
>     to suspend the SoC very aggressively to save power (in 20 seconds of
>     inactivity or so). If the display is open (it can also be turned around
>     for a tablet or e-book mode), it makes sense to freeze the picture and
>     keep the panel on, if the laptop is closed, we want to turn it off.
>     Should the behavior be exposed via sysfs (as it is with the current OLPC
>     kernels), or a DRM property? Would it require libdrm support?

I've accidentally seen how that's implemented for fbdev in the older
olpc drivers, and that's definitely _not_ how we want to support this.
Essentially what you have here is a fancy self-refresh panel. That's
already fully supported by DRM uapi, so I'd say first implement that.
Once we have that we can figure out a special property that tells the
driver to not shut down the screen on suspend, but just go into
self-refresh. Implementing the self-refresh stuff in DRM will be the
big pile of work (since that's something which goes beyond the generic
drm_bridge interface).


>   Himax HX8837 "DCON"
>   -------------------
>   RGB input from LCDC
>   Controlled via I2C

These two shouldn't be a problem.

>   Backlight control

We already have backlight interfaces

>   Can slow down the panel refresh rate to save power

Just expose this as modes with different vrefresh (and do that
modeswitch without doing a full modeset). Bonus if you do it
automatically, which can be done with the self-refresh infrastructure.

>   Optional dithering for color mode, "swizzling"

Not exactly clear, but I'm assuming the bus_format stuff on bridges
should help with this.

>   Has DRAM attached, can freeze a single frame in it

Classic self-refresh support. Noralf Tronnes has done great work here
past year to improve the infrastructure and let drivers implement this
with less typing. Also look at the recent work by vmwgfx folks.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch