On Thu, Dec 09, 2021 at 05:36:04AM -0600, Adam Ford wrote: > On Thu, Dec 9, 2021 at 4:26 AM Ezequiel Garcia > <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Hi, > > > > Thanks for the patch. > > > > On Wed, Dec 08, 2021 at 04:50:23PM -0600, Adam Ford wrote: > > > The G1 and G2 are separate decoder blocks that are enabled by the > > > vpu-blk-ctrl power-domain controller, which now has a proper driver. > > > Update the bindings to support separate nodes for the G1 and G2 > > > decoders using the proper driver or the older unified node with > > > the legacy controls. > > > > > > To be compatible with older DT the driver, mark certain items as > > > deprecated and retain the backwards compatible example. > > > > > > Signed-off-by: Adam Ford <aford173@xxxxxxxxx> > > > --- > > > .../bindings/media/nxp,imx8mq-vpu.yaml | 83 ++++++++++++++----- > > > 1 file changed, 64 insertions(+), 19 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml > > > index 762be3f96ce9..eeb7bd6281f9 100644 > > > --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml > > > +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml > > > @@ -15,29 +15,39 @@ description: > > > > > > properties: > > > compatible: > > > - const: nxp,imx8mq-vpu > > > + oneOf: > > > + - const: nxp,imx8mq-vpu > > > + deprecated: true > > > + - const: nxp,imx8mq-vpu-g1 > > > + - const: nxp,imx8mq-vpu-g2 > > > > > > reg: > > > + minItems: 1 > > > maxItems: 3 > > > > Is it really useful to keep the deprecated binding nxp,imx8mq-vpu > > as something supported by the binding file? > > Since I was told that the driver needed to be backwards compatible, i > wanted to make sure that any attempts to build the old device tree > would not fail I'm not convinced changing the binding at all is correct. 'The driver structure is changing and I want the binding to align with it' is not a reason. Are G1 and G2 actually separate, independent blocks where we could have 1 or both of them? And what about other platforms using this block? Even if the driver handles the old binding, a new dtb with an old kernel is broken. It's up to the platform to care or not, but you have to highlight that. > > In other words, can we drop the deprecated binding from this file, > > while keeping the support in the driver for legacy device-trees? > > I was trying to represent both the old driver binding and the new one > at the same time. I thought that's what I was told to do. I don't care so much if we have a schema for old binding. I'd rather have warnings if the binding has not been updated. Eventually I want to be able to test for compatibility by testing DTs with different schema versions. We've got to get to 0 warnings first though... Rob
