On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh...@kernel.org> wrote:

> > 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'd like something more specific than 'simple-panel' that at least
> implies it has EDID and whatever else we think it should imply.
>
> Looking into this a bit more, why don't we just do a connector here?
> eDP has a standard connector (with power). It's just like other
> connectors, but with power and no hotplug. If someone does their own
> interface, then they should do their own connector or panel binding.

Where do we put backlight in this case?

> > 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.
>
> We'll simply reject anything that should be implied by compatible. And
> now we can enforce with schema that DTs aren't populated with
> fallbacks alone. Of course, we can't make anyone pass all schema
> checks before shipping a dtb.
>
> Rob

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to