On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh+dt@xxxxxxxxxx> 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
