linux-kernel - RE: [PATCH v9 4/5] documentation: media: add documentation for Toshiba Visconti Video Input Interface driver

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] [day] [month] [year] [list]

Date: Mon, 22 Apr 2024 06:45:20 +0000
From: <yuji2.ishikawa@...hiba.co.jp>
To: <sakari.ailus@....fi>
CC: <hverkuil@...all.nl>, <laurent.pinchart@...asonboard.com>,
        <mchehab@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <nobuhiro1.iwamatsu@...hiba.co.jp>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v9 4/5] documentation: media: add documentation for
 Toshiba Visconti Video Input Interface driver

Hello Sakari,

> -----Original Message-----
> From: Sakari Ailus <sakari.ailus@....fi>
> Sent: Friday, February 2, 2024 3:50 PM
> To: ishikawa yuji(石川 悠司 ○ＲＤＣ□ＡＩＴＣ○ＥＡ開)
> <yuji2.ishikawa@...hiba.co.jp>
> Cc: hverkuil@...all.nl; laurent.pinchart@...asonboard.com;
> mchehab@...nel.org; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org;
> conor+dt@...nel.org; iwamatsu nobuhiro(岩松 信洋 ○ＤＩＴＣ□ＤＩＴ○Ｏ
> ＳＴ) <nobuhiro1.iwamatsu@...hiba.co.jp>; linux-media@...r.kernel.org;
> devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v9 4/5] documentation: media: add documentation for
> Toshiba Visconti Video Input Interface driver
> 
> Hi Yuji,
> 
> On Mon, Dec 04, 2023 at 04:32:40AM +0000, yuji2.ishikawa@...hiba.co.jp
> wrote:
> > > > +Vendor specific v4l2 controls
> > > > +=============================
> > > > +
> > > > +.. _V4L2_CID_VISCONTI_VIIF_MAIN_SET_RAWPACK_MODE:
> > > > +
> > > > +V4L2_CID_VISCONTI_VIIF_MAIN_SET_RAWPACK_MODE
> > > > +--------------------------------------------
> > > > +
> > > > +This control sets the format to pack multiple RAW pixel values into a
> word.
> > > > +
> > > > +This control accepts a __u32 value defined as `enum
> viif_rawpack_mode`.
> > > > +
> > > > +This control should be set before ioctl(S_FMT) and should not be
> > > > +changed
> > > after that.
> > >
> > > Why do you need this? Doesn't the V4L2 pixelformat already
> > > explicitly define the format, including packing?
> > >
> >
> > This control value affects the unpacker between CSI2 receiver and ISP.
> > The rawpack mode is an option to receive from Wide-Dynamic-Range image
> > sensors, whose output bit width is larger than standard format (RAW20,
> > RAW24). For example, some WDR image sensors split 20 bit value into
> > upper/lower 10bit values, then put them into consective pixels to make
> > a double-width RAW10 format image.
> 
> Do you have a sensor that really does this? Which one is it?

Our HW specialist has indicated that the VIIF HDR input expects some SONY HDR sensors as its source.

Because the VIIF was developed prior to the official release of RAW20 and RAW24 formats in the MIPI CSI2 specification,
its HDR RAW input feature is controlled by a vendor specific "rawpack" register.
Also, the proprietary software stack has "rawpack" flag.
The expected bitstream formats associated with "rawpack" align with the official RAW20 and RAW24 formats.

I now understand that rawpack flag is not used for non-standard pixel formats.
I'll remove rawpack flag in the v10 patch of the driver. 
HDR RAW input feature should be controlled by V4L2 pixelformat or media bus format.
However, RAW20, RAW24 support will be dropped in the v10 patch because modified part is not fully tested.

> 
> >
> > This option is only related to the interpretation of CSI2 input data.
> > Therefore, I think V4L2 pixel format (for resulting image) is not
> > related to it. The media bus format seems more relevant, but there is
> > no corresponding definition to this case.
> 
> --
> Regards,
> 
> Sakari Ailus

Regards,

Yuji Ishikawa