> -----Original Message----- > From: Conor Dooley <conor@xxxxxxxxxx> > Sent: Friday, March 29, 2024 8:47 AM > To: Klymenko, Anatoliy <Anatoliy.Klymenko@xxxxxxx> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>; Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx>; Maarten Lankhorst > <maarten.lankhorst@xxxxxxxxxxxxxxx>; Maxime Ripard > <mripard@xxxxxxxxxx>; Thomas Zimmermann <tzimmermann@xxxxxxx>; > David Airlie <airlied@xxxxxxxxx>; Daniel Vetter <daniel@xxxxxxxx>; Simek, > Michal <michal.simek@xxxxxxx>; Andrzej Hajda > <andrzej.hajda@xxxxxxxxx>; Neil Armstrong <neil.armstrong@xxxxxxxxxx>; > Robert Foss <rfoss@xxxxxxxxxx>; Jonas Karlman <jonas@xxxxxxxxx>; Jernej > Skrabec <jernej.skrabec@xxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; > Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley > <conor+dt@xxxxxxxxxx>; Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>; > Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > media@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings > > On Fri, Mar 29, 2024 at 12:38:33AM +0000, Klymenko, Anatoliy wrote: > > Thank you for the feedback. > > > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > > > Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings > > > On 22/03/2024 20:12, Klymenko, Anatoliy wrote: > > > >> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > > > >> On 21/03/2024 21:43, Anatoliy Klymenko wrote: > > > >>> diff --git a/include/dt-bindings/media/media-bus-format.h > > > >>> b/include/dt- > > > >> bindings/media/media-bus-format.h > > > >>> new file mode 100644 > > > >>> index 000000000000..60fc6e11dabc > > > >>> --- /dev/null > > > >>> +++ b/include/dt-bindings/media/media-bus-format.h > > > >>> @@ -0,0 +1,177 @@ > > > >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */ > > > >>> +/* > > > >>> + * Media Bus API header > > > >>> + * > > > >>> + * Copyright (C) 2009, Guennadi Liakhovetski > > > >>> +<g.liakhovetski@xxxxxx> > > > >>> + * > > > >>> + * This program is free software; you can redistribute it and/or > > > >>> +modify > > > >>> + * it under the terms of the GNU General Public License version 2 > > > >>> +as > > > >>> + * published by the Free Software Foundation. > > > >> > > > >> That's not true. Your SPDX tells something entirely different. > > > >> > > > > > > > > Thank you - I'll see how to fix it. > > > > > > > >> Anyway, you did not explain why you need to copy anything anywhere. > > > >> > > > >> Specifically, random hex values *are not bindings*. > > > >> > > > > > > > > The same media bus format values are being used by the reference > > > > driver in patch #9. And, as far as I know, we cannot use headers from > > > > Linux API headers directly (at least I > > > > > > I don't understand what does it mean. You can use in your driver > whatever > > > headers you wish, I don't care about them. > > > > > > > > > noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance). > > > What would be the best approach to reusing the same defines on DT and > > > driver sides from your point of view? Symlink maybe? > > > > > > > > > > Wrap your messages to match mailing list discussion style. There are no > > > defines used in DT. If there are, show me them in *THIS* or other > > > *upstreamed* (being upstreamed) patchset. > > > > > > > Sorry, I didn't explain properly what I'm trying to achieve. I need to > > create a DT node property that represents video signal format, one of > > MEDIA_BUS_FMT_* from include/uapi/linux/media-bus-format.h. It would > be > > nice to reuse the same symbolic values in the device tree. What is the > > best approach here? Should I create a separate header in > > include/dt-bindings with the same or similar (to avoid multiple > > definition errors) defines, or is it better to create a symlink to > > media-bus-format.h like include/dt-bindings/linux-event-codes.h? > > Isn't there already a property for this, described in > Documentation/devicetree/bindings/media/xilinx/video.txt > ? Those properties are very similar, indeed but not exactly the same. The one you noticed maps Xilinx video data format on AXI4-Stream transport that covers color space and chroma subsampling only. The rest of the signal attributes are either conventional or left out. MEDIA_BUS_FMT_* collection is more specific and embeds additional information about video signals, like bits per component and component ordering.