dt-bindings: media: renesas,isp: Add binding for V4M

Message ID 20240527131945.1679661-1-niklas.soderlund+renesas@ragnatech.se (mailing list archive)
State New
Headers
Series dt-bindings: media: renesas,isp: Add binding for V4M |

Commit Message

Niklas Söderlund May 27, 2024, 1:19 p.m. UTC
  Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
 Documentation/devicetree/bindings/media/renesas,isp.yaml | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Conor Dooley May 27, 2024, 4:36 p.m. UTC | #1
On Mon, May 27, 2024 at 03:19:45PM +0200, Niklas Söderlund wrote:
> Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

Should be with:
https://lore.kernel.org/all/20240527132513.1684232-1-niklas.soderlund+renesas@ragnatech.se/

No mention of why this can't just fall back to an existing device here
or in the driver. Why not?

> ---
>  Documentation/devicetree/bindings/media/renesas,isp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> index 33650a1ea034..d335d5595429 100644
> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> @@ -22,6 +22,7 @@ properties:
>        - enum:
>            - renesas,r8a779a0-isp # V3U
>            - renesas,r8a779g0-isp # V4H
> +          - renesas,r8a779h0-isp # V4M
>    reg:
>      maxItems: 1
>  
> -- 
> 2.45.1
>
  
Niklas Söderlund May 27, 2024, 5:54 p.m. UTC | #2
Hi Conor,

Thanks for your feedback.

On 2024-05-27 17:36:23 +0100, Conor Dooley wrote:
> On Mon, May 27, 2024 at 03:19:45PM +0200, Niklas Söderlund wrote:
> > Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
> > 
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> 
> Should be with:
> https://lore.kernel.org/all/20240527132513.1684232-1-niklas.soderlund+renesas@ragnatech.se/

I posted the bindings separate from the driver with the intention that 
once they are accepted I can upstream the driver and the DT for the 
device using it in parallel. The V4L2 subsystem is at times overloaded 
and in the past waiting for both driver and binding to be accepted as a 
whole unit have delayed entablement of SoC features unneeded for one or 
more releases.

> 
> No mention of why this can't just fall back to an existing device here
> or in the driver. Why not?

For better or worse that is how all Renesas devices are handled, one new 
device compatible for each device. This have worked well as each device 
usually have a quirk or extra future that is enabled later.

> 
> > ---
> >  Documentation/devicetree/bindings/media/renesas,isp.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> > index 33650a1ea034..d335d5595429 100644
> > --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
> > +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> > @@ -22,6 +22,7 @@ properties:
> >        - enum:
> >            - renesas,r8a779a0-isp # V3U
> >            - renesas,r8a779g0-isp # V4H
> > +          - renesas,r8a779h0-isp # V4M
> >    reg:
> >      maxItems: 1
> >  
> > -- 
> > 2.45.1
> >
  
Conor Dooley May 27, 2024, 6:07 p.m. UTC | #3
On Mon, May 27, 2024 at 07:54:02PM +0200, Niklas Söderlund wrote:
> Hi Conor,
> 
> Thanks for your feedback.
> 
> On 2024-05-27 17:36:23 +0100, Conor Dooley wrote:
> > On Mon, May 27, 2024 at 03:19:45PM +0200, Niklas Söderlund wrote:
> > > Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > 
> > Should be with:
> > https://lore.kernel.org/all/20240527132513.1684232-1-niklas.soderlund+renesas@ragnatech.se/
> 
> I posted the bindings separate from the driver with the intention that 
> once they are accepted I can upstream the driver and the DT for the 
> device using it in parallel. The V4L2 subsystem is at times overloaded 
> and in the past waiting for both driver and binding to be accepted as a 
> whole unit have delayed entablement of SoC features unneeded for one or 
> more releases.

I don't really understand this argument at all. If you land the binding
but not the driver changes, you're still waiting for the driver to get
the feature functional. My understanding is that Geert takes dts patches
when bindings are applied by the subsystems, rather than wait until they
circle back to his tree a release later - so that isn't the issue either.

All it seems like you're doing to me is making my "job" reviewing
bindings harder, because I have to search on lore for your driver
patches.

> > No mention of why this can't just fall back to an existing device here
> > or in the driver. Why not?
> 
> For better or worse that is how all Renesas devices are handled, one new 
> device compatible for each device. This have worked well as each device 
> usually have a quirk or extra future that is enabled later.

If you're worried about the media subsystem being too busy to pick up
patches with driver support, you know what's a way you can have the
driver functional without a code change?

/spoiler You guessed it, fallback compatibles!
  
Geert Uytterhoeven June 4, 2024, 7:38 a.m. UTC | #4
Hi Niklas,

On Mon, May 27, 2024 at 3:20 PM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> @@ -22,6 +22,7 @@ properties:
>        - enum:
>            - renesas,r8a779a0-isp # V3U
>            - renesas,r8a779g0-isp # V4H
> +          - renesas,r8a779h0-isp # V4M
>    reg:
>      maxItems: 1

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

BTW, this binding only describes a single register block, while the
ISP seems to have two: CS and CORE (the second one is optional, as it
does not exist for the second instance of R-Car V4M)?

Gr{oetje,eeting}s,

                        Geert
  
Niklas Söderlund June 4, 2024, 9:18 a.m. UTC | #5
Hi Geert,

Thanks for your review.

On 2024-06-04 09:38:04 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Mon, May 27, 2024 at 3:20 PM Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> 
> Thanks for your patch!
> 
> > --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
> > +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
> > @@ -22,6 +22,7 @@ properties:
> >        - enum:
> >            - renesas,r8a779a0-isp # V3U
> >            - renesas,r8a779g0-isp # V4H
> > +          - renesas,r8a779h0-isp # V4M
> >    reg:
> >      maxItems: 1
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> BTW, this binding only describes a single register block, while the
> ISP seems to have two: CS and CORE (the second one is optional, as it
> does not exist for the second instance of R-Car V4M)?

Yes. The R-Car ISP have two different functions, CSI-2 Channel Selection 
(CS) and a more traditional ISP block to do cool stuff to image data 
(core).  We only have documentation for the CS, and only that which is 
needed to setup CSI-2 reception and forward data to a capture engine 
(VIN), so this is all the rcar-isp driver deals with.

For the interested, difference between generations,

On Gen3 the capture pipeline is $source -> rcar-csi2 -> rcar-vin. The 
CSI-2 channel selection is done from registers on the VIN master 
instances but effect other VIN instances, this is one reason the 
rcar-vin driver is so ugly as each VIN instance is not self contained.  
While the CSI-2 VC/DT filtering is done in the rcar-csi2 driver.

On Gen4 the capture pipeline is $source -> rcar-csi2 -> rcar-isp -> 
rcar-vin. And both the channel selection and VC/DT filtering is done in 
the rcar-isp. IMHO this is slightly better design then on Gen3 but 
created yet another ugliness in the pipeline as now Gen{1,2}, Gen3 and 
Gen4 are all supported by the same set of drivers but the same function 
is served by different IP blocks depending on which generation, this 
makes for somewhat ugly driver code.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
  

Patch

diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml
index 33650a1ea034..d335d5595429 100644
--- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
@@ -22,6 +22,7 @@  properties:
       - enum:
           - renesas,r8a779a0-isp # V3U
           - renesas,r8a779g0-isp # V4H
+          - renesas,r8a779h0-isp # V4M
   reg:
     maxItems: 1