From: Shuah Khan <skhan@linuxfoundation.org>
To: "Helen Koike" <helen.koike@collabora.com>,
"Nícolas F. R. A. Prado" <nfraprado@protonmail.com>,
linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
linux-kernel@vger.kernel.org, lkcamp@lists.libreplanetbr.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2 3/3] media: vimc: deb: Add support for {RGB,BGR,GBR}888 bus formats on source pad
Date: Mon, 30 Mar 2020 13:46:21 -0600 [thread overview]
Message-ID: <daccd8d8-8132-9aef-0a19-5804c562a843@linuxfoundation.org> (raw)
In-Reply-To: <ae9fdf85-7129-e1ad-a377-bda0808545c1@collabora.com>
On 3/30/20 1:43 PM, Helen Koike wrote:
> Hello,
>
> On 3/26/20 7:06 PM, Shuah Khan wrote:
>> On 3/26/20 3:47 PM, Nícolas F. R. A. Prado wrote:
>>> Add support for RGB888_*, BGR888_* and GBR888_* media bus formats on
>>> the source pad of debayer subdevices.
>>>
>>> Co-developed-by: Vitor Massaru Iha <vitor@massaru.org>
>>> Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
>>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
>>> ---
>>>
>>> Changes in v2:
>>> - Change commit message to reflect v2 changes
>>> - Rename variables
>>> - Fix array formatting
>>> - Add vimc_deb_is_src_code_valid function
>>> - Add other BGR888 and RGB888 formats to debayer source pad supported
>>> formats
>>>
>>> drivers/media/platform/vimc/vimc-debayer.c | 61 +++++++++++++++++-----
>>> 1 file changed, 49 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/vimc/vimc-debayer.c b/drivers/media/platform/vimc/vimc-debayer.c
>>> index baf6bf9f65b5..33a9bea770bc 100644
>>> --- a/drivers/media/platform/vimc/vimc-debayer.c
>>> +++ b/drivers/media/platform/vimc/vimc-debayer.c
>>> @@ -51,6 +51,19 @@ static const struct v4l2_mbus_framefmt sink_fmt_default = {
>>> .colorspace = V4L2_COLORSPACE_DEFAULT,
>>> };
>>> +static const u32 vimc_deb_src_mbus_codes[] = {
>>> + MEDIA_BUS_FMT_GBR888_1X24,
>>> + MEDIA_BUS_FMT_BGR888_1X24,
>>> + MEDIA_BUS_FMT_BGR888_3X8,
>>> + MEDIA_BUS_FMT_RGB888_1X24,
>>> + MEDIA_BUS_FMT_RGB888_2X12_BE,
>>> + MEDIA_BUS_FMT_RGB888_2X12_LE,
>>> + MEDIA_BUS_FMT_RGB888_3X8,
>>> + MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
>>> + MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
>>> + MEDIA_BUS_FMT_RGB888_1X32_PADHI,
>>> +};
>>> +
>>> static const struct vimc_deb_pix_map vimc_deb_pix_map_list[] = {
>>> {
>>> .code = MEDIA_BUS_FMT_SBGGR8_1X8,
>>> @@ -125,6 +138,17 @@ static const struct vimc_deb_pix_map *vimc_deb_pix_map_by_code(u32 code)
>>> return NULL;
>>> }
>>> +static int vimc_deb_is_src_code_invalid(u32 code)
>>> +{
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(vimc_deb_src_mbus_codes); i++)
>>> + if (vimc_deb_src_mbus_codes[i] == code)
>>> + return 0;
>>> +
>>> + return -EINVAL;
>>> +}
>
> The naming is a bit confusing, since it checks if it is invalid, but returns a negative number if so.
>
> How about renaming to vimc_deb_src_code_is_valid ?
>
>>> +
>>> static int vimc_deb_init_cfg(struct v4l2_subdev *sd,
>>> struct v4l2_subdev_pad_config *cfg)
>>> {
>>> @@ -148,14 +172,11 @@ static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
>>> struct v4l2_subdev_pad_config *cfg,
>>> struct v4l2_subdev_mbus_code_enum *code)
>>> {
>>> - /* We only support one format for source pads */
>>> if (VIMC_IS_SRC(code->pad)) {
>>> - struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
>>> -
>>> - if (code->index)
>>> + if (code->index >= ARRAY_SIZE(vimc_deb_src_mbus_codes))
>>> return -EINVAL;
>>> - code->code = vdeb->src_code;
>>> + code->code = vimc_deb_src_mbus_codes[code->index];
>>> } else {
>>> if (code->index >= ARRAY_SIZE(vimc_deb_pix_map_list))
>>> return -EINVAL;
>>> @@ -170,8 +191,6 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
>>> struct v4l2_subdev_pad_config *cfg,
>>> struct v4l2_subdev_frame_size_enum *fse)
>>> {
>>> - struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
>>> -
>>> if (fse->index)
>>> return -EINVAL;
>>> @@ -181,7 +200,7 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
>>> if (!vpix)
>>> return -EINVAL;
>>> - } else if (fse->code != vdeb->src_code) {
>>> + } else if (vimc_deb_is_src_code_invalid(fse->code)) {
>>> return -EINVAL;
>>> }
>>> @@ -237,6 +256,7 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
>>> {
>>> struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
>>> struct v4l2_mbus_framefmt *sink_fmt;
>>> + u32 *src_code;
>>> if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
>>> /* Do not change the format while stream is on */
>>> @@ -244,8 +264,10 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
>>> return -EBUSY;
>>> sink_fmt = &vdeb->sink_fmt;
>>> + src_code = &vdeb->src_code;
>>> } else {
>>> sink_fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
>>> + src_code = &v4l2_subdev_get_try_format(sd, cfg, 1)->code;
>>> }
>>> /*
>>> @@ -253,9 +275,14 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
>>> * it is propagated from the sink
>>> */
>>> if (VIMC_IS_SRC(fmt->pad)) {
>>> + u32 code = fmt->format.code;
>>> +
>>> fmt->format = *sink_fmt;
>>> - /* TODO: Add support for other formats */
>>> - fmt->format.code = vdeb->src_code;
>>> +
>>> + if (!vimc_deb_is_src_code_invalid(code))
>>> + *src_code = code;
>>> +
>>> + fmt->format.code = *src_code;
>>> } else {
>>> /* Set the new format in the sink pad */
>>> vimc_deb_adjust_sink_fmt(&fmt->format);
>>> @@ -291,11 +318,21 @@ static void vimc_deb_set_rgb_mbus_fmt_rgb888_1x24(struct vimc_deb_device *vdeb,
>>> unsigned int col,
>>> unsigned int rgb[3])
>>
>> Change this to pass a pointer and size.
>
> Hi Shuah,
>
> Modifying vimc_deb_set_rgb_mbus_fmt_rgb888_1x24() is not part of this patch, or do you mean another part of the code?
>
I know it isn't part of this patch. However, this could use improvment
and pass pointer and size.
Can be handled as a separate patch.
thanks,
-- Shuah
next prev parent reply other threads:[~2020-03-30 19:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 21:47 [PATCH v2 0/3] media: vimc: Add support for {RGB,BGR,GBR}888 bus formats on debayer source pad Nícolas F. R. A. Prado
2020-03-26 21:47 ` [PATCH v2 1/3] media: vimc: Support multiple media bus codes for each pixelformat Nícolas F. R. A. Prado
2020-03-30 19:36 ` Helen Koike
2020-04-20 20:36 ` Nícolas F. R. A. Prado
2020-04-20 20:50 ` Helen Koike
2020-03-26 21:47 ` [PATCH v2 2/3] media: vimc: Add missing {RGB,BGR,GBR}888 media bus codes Nícolas F. R. A. Prado
2020-03-26 21:56 ` Shuah Khan
2020-03-30 19:37 ` Helen Koike
2020-03-26 21:47 ` [PATCH v2 3/3] media: vimc: deb: Add support for {RGB,BGR,GBR}888 bus formats on source pad Nícolas F. R. A. Prado
2020-03-26 22:06 ` Shuah Khan
2020-03-30 19:43 ` Helen Koike
2020-03-30 19:46 ` Shuah Khan [this message]
2020-04-20 21:01 ` Nícolas F. R. A. Prado
2020-04-20 21:04 ` Helen Koike
2020-04-27 22:12 ` Nícolas F. R. A. Prado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daccd8d8-8132-9aef-0a19-5804c562a843@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=helen.koike@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lkcamp@lists.libreplanetbr.org \
--cc=mchehab@kernel.org \
--cc=nfraprado@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).