Re: [PATCH v2 1/2] dt-bindings: media: renesas,vin: Add binding for V4M

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 10, 2024 at 06:59:35PM +0200, Niklas Söderlund wrote:
> Hi Conor,
> 
> Thanks for your feedback.
> 
> On 2024-06-10 17:03:49 +0100, Conor Dooley wrote:
> > On Mon, Jun 10, 2024 at 01:31:23PM +0200, Niklas Söderlund wrote:
> > > Document support for the VIN module in the Renesas V4M (r8a779h0) SoC.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > > ---
> > >  Documentation/devicetree/bindings/media/renesas,vin.yaml | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
> > > index 5539d0f8e74d..168cb02f8abe 100644
> > > --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
> > > +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
> > > @@ -54,6 +54,7 @@ properties:
> > >                - renesas,vin-r8a77995 # R-Car D3
> > >                - renesas,vin-r8a779a0 # R-Car V3U
> > >                - renesas,vin-r8a779g0 # R-Car V4H
> > > +              - renesas,vin-r8a779h0 # R-Car V4M
> > 
> > Your driver patch suggests that this is compatible with the g variant.
> 
> Currently it is. But that not always be true, I tried to outline this in 
> to cover letter.

To be honest, I don't usually read cover letters when reviewing bindings.
Information about why things are/are not compatible should be in a
commit itself.

>     The V4M capture pipeline is similar to the other Gen4 SoC supported
>     upstream already V4H. Currently all futures supported for VIN on V4M are
>     also supported by V4H and the driver code can be shared. But as done for
>     other R-Car IP bindings a new dedicated binding for V4M is created.
>     This have proved prudent in the past where quirks are found even within
>     the same generation as more advance use-cases are enabled.

I don't understand how this precludes using the g variant as a fallback
compatible. I'm not suggesting that you don't add a specific one for the
h variant.

Thanks,
Conor.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux