From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasily Khoruzhick Subject: Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel Date: Mon, 4 Feb 2019 12:26:57 -0800 Message-ID: References: <20190203185501.8958-1-anarsoul@gmail.com> <20190203185501.8958-9-anarsoul@gmail.com> <20190204074350.GC16448@ulmo> <20190204082353.GE19087@ulmo> <20190204165637.GA30876@ulmo> Reply-To: anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Rob Herring Cc: Thierry Reding , David Airlie , Daniel Vetter , Mark Rutland , Maxime Ripard , Chen-Yu Tsai , Archit Taneja , Andrzej Hajda , Laurent Pinchart , Icenowy Zheng , Sean Paul , dri-devel , devicetree , arm-linux , linux-sunxi List-Id: dri-devel@lists.freedesktop.org On Mon, Feb 4, 2019 at 12:23 PM Rob Herring 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