On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding <thierry.reding@xxxxxxxxx> 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
