Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.
>
> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.
>
> This all sounds like a Pandora's box to me.

OK, just give me an option that will work on this platform with a
single software image (keep in mind that u-boot aka "firmware" is part
of this image) and that is acceptable for upstream and I'll try to
implement it.

> Thierry