Hi, On Wed, 2018-12-19 at 10:13 +0100, Daniel Vetter wrote: > On Wed, Dec 19, 2018 at 9:40 AM Lubomir Rintel <lkundrak@xxxxx> 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. I'm wondering if you can share some more specific pointers? Grepping for "self-refresh" yields references to the eDP self refresh, but that seems not relevant as that one depends on hardware to decide when to enter the self-refresh mode. Perhaps I was not looking at the right place (I searched git and patchwork), but I was not able to find work that would seem relevant. > Cheers, Daniel Thank you, Lubo _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
