linux-kernel - Re: [PATCH v2] media: ov8856: Fix Bayer format dependance on mode

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]

Message-ID: <CAAFQd5BVSNGDV7ZkiVpZwbfTfRLJmNvopMQFnQno+CDs+bo3Gg@mail.gmail.com>
Date:   Fri, 8 Jan 2021 18:49:07 +0900
From:   Tomasz Figa <tfiga@...gle.com>
To:     Robert Foss <robert.foss@...aro.org>
Cc:     Dongchun Zhu <dongchun.zhu@...iatek.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Bingbu Cao <bingbu.cao@...ux.intel.com>
Subject: Re: [PATCH v2] media: ov8856: Fix Bayer format dependance on mode

Hi Robert,

On Thu, Jan 7, 2021 at 11:21 PM Robert Foss <robert.foss@...aro.org> wrote:
>
> The Bayer GRBG10 mode used for earlier modes 3280x2460 and
> 1640x1232 isn't the mode output by the sensor for the
> 3264x2448 and 1632x1224 modes.
>
> Switch from MEDIA_BUS_FMT_SGRBG10_1X10 to MEDIA_BUS_FMT_SBGGR10_1X10
> for 3264x2448 & 1632x1224 modes.
>
> Signed-off-by: Robert Foss <robert.foss@...aro.org>
> ---
>
> Changes since v1:
>  - Sakari: Added mode information to ov8856_mode struct
>  - Sakari: enum_mbus_code updated
>
>  drivers/media/i2c/ov8856.c | 24 ++++++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
> index 2f4ceaa80593..7cd83564585c 100644
> --- a/drivers/media/i2c/ov8856.c
> +++ b/drivers/media/i2c/ov8856.c
> @@ -126,6 +126,9 @@ struct ov8856_mode {
>
>         /* Sensor register settings for this resolution */
>         const struct ov8856_reg_list reg_list;
> +
> +       /* MEDIA_BUS_FMT for this mode */
> +       u32 code;
>  };
>
>  static const struct ov8856_reg mipi_data_rate_720mbps[] = {
> @@ -942,6 +945,11 @@ static const char * const ov8856_test_pattern_menu[] = {
>         "Bottom-Top Darker Color Bar"
>  };
>
> +static const u32 ov8856_formats[] = {
> +       MEDIA_BUS_FMT_SBGGR10_1X10,
> +       MEDIA_BUS_FMT_SGRBG10_1X10,
> +};
> +
>  static const s64 link_freq_menu_items[] = {
>         OV8856_LINK_FREQ_360MHZ,
>         OV8856_LINK_FREQ_180MHZ
> @@ -974,6 +982,7 @@ static const struct ov8856_mode supported_modes[] = {
>                         .regs = mode_3280x2464_regs,
>                 },
>                 .link_freq_index = OV8856_LINK_FREQ_720MBPS,
> +               .code = MEDIA_BUS_FMT_SGRBG10_1X10,
>         },
>         {
>                 .width = 3264,
> @@ -986,6 +995,7 @@ static const struct ov8856_mode supported_modes[] = {
>                         .regs = mode_3264x2448_regs,
>                 },
>                 .link_freq_index = OV8856_LINK_FREQ_720MBPS,
> +               .code = MEDIA_BUS_FMT_SBGGR10_1X10,
>         },
>         {
>                 .width = 1640,
> @@ -998,6 +1008,7 @@ static const struct ov8856_mode supported_modes[] = {
>                         .regs = mode_1640x1232_regs,
>                 },
>                 .link_freq_index = OV8856_LINK_FREQ_360MBPS,
> +               .code = MEDIA_BUS_FMT_SGRBG10_1X10,
>         },
>         {
>                 .width = 1632,
> @@ -1010,6 +1021,7 @@ static const struct ov8856_mode supported_modes[] = {
>                         .regs = mode_1632x1224_regs,
>                 },
>                 .link_freq_index = OV8856_LINK_FREQ_360MBPS,
> +               .code = MEDIA_BUS_FMT_SBGGR10_1X10,
>         }
>  };
>
> @@ -1281,8 +1293,8 @@ static void ov8856_update_pad_format(const struct ov8856_mode *mode,
>  {
>         fmt->width = mode->width;
>         fmt->height = mode->height;
> -       fmt->code = MEDIA_BUS_FMT_SGRBG10_1X10;
>         fmt->field = V4L2_FIELD_NONE;
> +       fmt->code = mode->code;
>  }
>
>  static int ov8856_start_streaming(struct ov8856 *ov8856)
> @@ -1519,11 +1531,10 @@ static int ov8856_enum_mbus_code(struct v4l2_subdev *sd,
>                                  struct v4l2_subdev_pad_config *cfg,
>                                  struct v4l2_subdev_mbus_code_enum *code)
>  {
> -       /* Only one bayer order GRBG is supported */
> -       if (code->index > 0)
> +       if (code->index >= ARRAY_SIZE(ov8856_formats))
>                 return -EINVAL;
>
> -       code->code = MEDIA_BUS_FMT_SGRBG10_1X10;
> +       code->code = ov8856_formats[code->index];
>
>         return 0;
>  }
> @@ -1532,10 +1543,11 @@ static int ov8856_enum_frame_size(struct v4l2_subdev *sd,
>                                   struct v4l2_subdev_pad_config *cfg,
>                                   struct v4l2_subdev_frame_size_enum *fse)
>  {
> -       if (fse->index >= ARRAY_SIZE(supported_modes))
> +       if ((fse->code != ov8856_formats[0]) &&
> +           (fse->code != ov8856_formats[1]))

Shouldn't this be validated against the current mode? I guess it's the
question about which part of the state takes precedence - the mbus
code or the frame size.

Best regards,
Tomasz