linux-kernel - Re: [PATCH v5 04/13] media: atmel: atmel-isc: implement media controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Feb 2022 14:59:19 +0000
From:   <Eugen.Hristev@...rochip.com>
To:     <linux-media@...r.kernel.org>, <jacopo@...ndi.org>,
        <hverkuil-cisco@...all.nl>, <Nicolas.Ferre@...rochip.com>
CC:     <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <Claudiu.Beznea@...rochip.com>
Subject: Re: [PATCH v5 04/13] media: atmel: atmel-isc: implement media
 controller

On 2/17/22 3:56 PM, Eugen Hristev wrote:
> Implement the support for media-controller.
> This means that the capabilities of the driver have changed and now
> it also advertises the IO_MC .
> The driver will register it's media device, and add the video entity to this
> media device. The subdevices are registered to the same media device.
> The ISC will have a base entity which is auto-detected as atmel_isc_base.
> It will also register a subdevice that allows cropping of the incoming frame
> to the maximum frame size supported by the ISC.
> The ISC will create a link between the subdevice that is asynchronously
> registered and the atmel_isc_scaler entity.
> Then, the atmel_isc_scaler and atmel_isc_base are connected through another
> link.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev@...rochip.com>
> ---


Hello Jacopo,

I will add to this patch a little update about how the scaler is seen 
now by the media-ctl :

for imx219 sensor, which generates 3280x2464:


- entity 1: atmel_isc_scaler (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev0
         pad0: Sink
                 [fmt:SRGGB10_1X10/3280x2464 field:none colorspace:srgb
                  crop.bounds:(0,0)/3280x2464
                  crop:(0,0)/3264x2464]
                 <- "csi2dc":1 [ENABLED,IMMUTABLE]
         pad1: Source
                 [fmt:SRGGB10_1X10/3264x2464 field:none colorspace:srgb]
                 -> "atmel_isc_common":0 [ENABLED,IMMUTABLE]


The source pad of the scaler looks good now.

For the imx274 which I am using (and it generates 3840x2160 ):

- entity 1: atmel_isc_scaler (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev0
         pad0: Sink
                 [fmt:SRGGB10_1X10/3840x2160 field:none colorspace:srgb
                  crop.bounds:(0,0)/3840x2160
                  crop:(0,0)/3264x2160]
                 <- "csi2dc":1 [ENABLED,IMMUTABLE]
         pad1: Source
                 [fmt:SRGGB10_1X10/3264x2160 field:none colorspace:srgb]
                 -> "atmel_isc_common":0 [ENABLED,IMMUTABLE]

So in both cases, each line is cropped down to 3264 as the maximum width.

If we select a lower frame size, the scaler will automatically update 
the source pad to reflect this, e.g.:


- entity 1: atmel_isc_scaler (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev0
         pad0: Sink
                 [fmt:SRGGB10_1X10/1920x1080 field:none colorspace:srgb
                  crop.bounds:(0,0)/1920x1080
                  crop:(0,0)/1920x1080]
                 <- "csi2dc":1 [ENABLED,IMMUTABLE]
         pad1: Source
                 [fmt:SRGGB10_1X10/1920x1080 field:none colorspace:srgb]
                 -> "atmel_isc_common":0 [ENABLED,IMMUTABLE]


does it look good now ?

Thanks for checking this out !
Eugen