Re: [PATCH] dt-bindings: media: renesas,isp: Add binding for V4M

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

 



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@xxxxxxxxxxxx> wrote:
> > Document support for the ISP module in the Renesas V4M (r8a779h0) SoC.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> 
> 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@xxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxx
> 
> 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

-- 
Kind Regards,
Niklas Söderlund




[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