On Thu, Sep 08, 2022 at 08:42:35PM -0500, Rob Herring wrote: > On Wed, Sep 07, 2022 at 08:35:13AM -0500, Chris Morgan wrote: > > On Wed, Sep 07, 2022 at 02:53:56PM +0200, Krzysztof Kozlowski wrote: > > > On 06/09/2022 20:52, Chris Morgan wrote: > > > > From: Chris Morgan <macromorgan@xxxxxxxxxxx> > > > > > > > > Add documentation for the NewVision NV3051D panel bindings. > > > > Note that for the two expected consumers of this panel binding > > > > the underlying LCD model is unknown. > > > > > > > > Signed-off-by: Chris Morgan <macromorgan@xxxxxxxxxxx> > > > > --- > > > > .../display/panel/newvision,nv3051d.yaml | 48 +++++++++++++++++++ > > > > 1 file changed, 48 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > > new file mode 100644 > > > > index 000000000000..016168d8d7b2 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > > @@ -0,0 +1,48 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fpanel%2Fnewvision%2Cnv3051d.yaml%23&data=05%7C01%7C%7Cab7f68ce677846b1638508da920493a4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637982845610791935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6XxrzD1zkl8SYQqV9nkH1WzKfdcy6doNfzan8r228W0%3D&reserved=0 > > > > > > You need to document vendor prefix... but the filename does not match > > > compatible. > > > > Okay, will do that. This is a tricky one because while I know the panel > > controller IC (a NewVision NV3051D) I don't actually know the LCD panel > > itself, the vendor is somewhat tight lipped. I do know the product it > > goes into, so that's why I did what I did with the compatible strings. > > If that's not correct I guess let me know. I did see for other drivers > > (such as the NewVision NV3052C) the driver was written for the IC > > and the panel name was listed differently, hence what I was going for > > here. > > I think most cases like this targeting a specific LCD driver IC, there's > a driver IC compatible as a fallback. > > (TBC, 'driver' here is not Linux driver, but the h/w chip.) > > Rob So in this case would my compatible string in the devicetree need to be something like "anbernic,rg353-panel", "newvision,nv3051d" then? And the module itself have the compatible string of "newvision,nv3051d"? My fear is that I write this as a newvision,nv3051d kernel module and then later on there comes a new panel using the nv3051d that wants to use this too. Again keeping things confusing I have no LCD panel part number from the manufacturer for this, and I cannot see anything on the panel itself denoting what LCD it is. Thank you for your help. Just wrapping up getting some of my favorite devices supported in mainline. :-)
