| Message ID | 20240527131849.1678877-1-niklas.soderlund+renesas@ragnatech.se (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Kieran Bingham |
| Headers | show |
| Series | dt-bindings: media: renesas,vin: Add binding for V4M | expand |
On Mon, May 27, 2024 at 03:18:49PM +0200, Niklas Söderlund wrote: > Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. Which is different from the other devices how? Should be with the driver: https://lore.kernel.org/all/20240527132429.1683547-1-niklas.soderlund+renesas@ragnatech.se/ Thanks, Conor. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > 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 > > reg: > maxItems: 1 > -- > 2.45.1 >
Hi Conor, Thanks for your feedback. On 2024-05-27 17:37:21 +0100, Conor Dooley wrote: > On Mon, May 27, 2024 at 03:18:49PM +0200, Niklas Söderlund wrote: > > Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. > > Which is different from the other devices how? Compared to the other Gen4 SoC supported it only supports D-PHY. I will add this to next version, thanks for spotting it. > Should be with the driver: > https://lore.kernel.org/all/20240527132429.1683547-1-niklas.soderlund+renesas@ragnatech.se/ As I mentioned in the other thread about the ISPCS bindings, I intentionally posted the bindings separately to allow parallel upstreaming of driver and DT users. Is it really a bad idea to do it this way? For other work I have done that involves more complex DT changes then adding a compatible, such as adding a new device or adding more properties to cover more features only available in a later version of a device. I always post the DT parts first as this can spur discussions about the design and only after they are agreed upon do I post the driver parts that make use of them. Seems like this would consume less review resources as the bindings can be agreed upon first, before anyone have to spend time reviewing a driver that might need to be redesigned as the bindings could be improved. > > Thanks, > Conor. > > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > --- > > 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 > > > > reg: > > maxItems: 1 > > -- > > 2.45.1 > >
On Mon, May 27, 2024 at 08:03:12PM +0200, Niklas Söderlund wrote: > On 2024-05-27 17:37:21 +0100, Conor Dooley wrote: > > Should be with the driver: > > https://lore.kernel.org/all/20240527132429.1683547-1-niklas.soderlund+renesas@ragnatech.se/ > > As I mentioned in the other thread about the ISPCS bindings, I > intentionally posted the bindings separately to allow parallel > upstreaming of driver and DT users. > > Is it really a bad idea to do it this way? For other work I have done > that involves more complex DT changes then adding a compatible, such as > adding a new device or adding more properties to cover more features > only available in a later version of a device. I always post the DT > parts first as this can spur discussions about the design and only after > they are agreed upon do I post the driver parts that make use of them. > > Seems like this would consume less review resources as the bindings can > be agreed upon first, before anyone have to spend time reviewing a > driver that might need to be redesigned as the bindings could be > improved. I would always rather have the driver implemented rather than just discuss some idealised bindings. The first place I go when I have concerns or confusion about how a binding is intended to be used is the driver - so it doesn't make my time reviewing something easier, that's for sure. Additionally, having a software implementation can make it obvious where mistakes may be in a complex binding or notice things that were omitted. Getting a binding merged early in that case can easily become a hinderance..
On 27/05/2024 20:03, Niklas Söderlund wrote: > Hi Conor, > > Thanks for your feedback. > > On 2024-05-27 17:37:21 +0100, Conor Dooley wrote: >> On Mon, May 27, 2024 at 03:18:49PM +0200, Niklas Söderlund wrote: >>> Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. >> >> Which is different from the other devices how? > > Compared to the other Gen4 SoC supported it only supports D-PHY. I will > add this to next version, thanks for spotting it. > >> Should be with the driver: >> https://lore.kernel.org/all/20240527132429.1683547-1-niklas.soderlund+renesas@ragnatech.se/ > > As I mentioned in the other thread about the ISPCS bindings, I > intentionally posted the bindings separately to allow parallel > upstreaming of driver and DT users. > > Is it really a bad idea to do it this way? For other work I have done > that involves more complex DT changes then adding a compatible, such as > adding a new device or adding more properties to cover more features > only available in a later version of a device. I always post the DT > parts first as this can spur discussions about the design and only after > they are agreed upon do I post the driver parts that make use of them. Binding goes via driver subsystem, so how exactly do you achieve parallelism here comparing to expected way of submitting (driver+binding)? Best regards, Krzysztof
On Mon, May 27, 2024 at 3:19 PM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
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 reg: maxItems: 1
Document support for the VIN module in the Renesas V4M (r8a779h0) SoC. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- Documentation/devicetree/bindings/media/renesas,vin.yaml | 1 + 1 file changed, 1 insertion(+)