From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Steve Longerbeam <slongerbeam@gmail.com>
Cc: linux-media@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Rui Miguel Silva <rmfrfs@gmail.com>
Subject: Re: [PATCH v7 04/11] media: imx: utils: Handle Bayer format lookup through a selection flag
Date: Tue, 21 Apr 2020 13:12:44 +0200 [thread overview]
Message-ID: <20200421131244.763f82df@coco.lan> (raw)
In-Reply-To: <20200406163905.24475-5-slongerbeam@gmail.com>
Em Mon, 6 Apr 2020 09:38:58 -0700
Steve Longerbeam <slongerbeam@gmail.com> escreveu:
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> The format lookup (and enumeration) functions take a boolean flag to
> tell if Bayer formats should be considered. This leads to hard to read
> lines such as
>
> return enum_format(fourcc, NULL, index, cs_sel, true, false);
>
> where the boolean parameters can easily be mixed. To make the code
> clearer, add a CS_SEL_BAYER flag that can be passed through the
> codespace_sel parameter of the lookup functions to replace the bool
> parameter.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> [Instead of declaring CS_SEL_ANY as a bitfield containing only
> CS_SEL_YUV | CS_SEL_RGB, declare CS_SEL_ANY as all of the above
> (YUV, RGB, BAYER). A new enum is declared for the YUV | RGB selection
> as CS_SEL_YUV_RGB, and that is used by sub-devices that don't support
> BAYER and only allow selecting and enumerating YUV or RGB encodings.
> CS_SEL_ANY is now only used by the CSI sub-devices and the attached
> capture interfaces, since only those devices support BAYER formats.]
I'm assuming that the comments like the above on this patchset means
that the Steve changed a patch from Laurent. The right markup
(as stated at Documentation/process/submitting-patches.rst) is:
Signed-off-by: Random J Developer <random@developer.example.org>
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
e. g. the above should be, instead:
[slongerbeam@gmail.com: Instead of....]
Let's please stick with the standard meta-tag.
PS.: I'm also fixing other similar patterns on this patchset.
Regards,
Mauro
Thanks,
Mauro
next prev parent reply other threads:[~2020-04-21 11:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 16:38 [PATCH v7 00/11] media: imx: Miscellaneous format-related cleanups Steve Longerbeam
2020-04-06 16:38 ` [PATCH v7 01/11] media: imx: utils: fix and simplify pixel format enumeration Steve Longerbeam
2020-04-09 15:38 ` Fabio Estevam
2020-04-14 21:00 ` Steve Longerbeam
2020-04-14 21:20 ` [PATCH v7.1 " Steve Longerbeam
2020-04-06 16:38 ` [PATCH v7 02/11] media: imx: utils: fix media bus " Steve Longerbeam
2020-04-14 21:23 ` [PATCH v7.1 " Steve Longerbeam
2020-04-06 16:38 ` [PATCH v7 03/11] media: imx: utils: Inline init_mbus_colorimetry() in its caller Steve Longerbeam
2020-04-06 16:38 ` [PATCH v7 04/11] media: imx: utils: Handle Bayer format lookup through a selection flag Steve Longerbeam
2020-04-21 11:12 ` Mauro Carvalho Chehab [this message]
2020-04-06 16:38 ` [PATCH v7 05/11] media: imx: Fix some pixel format selections Steve Longerbeam
2020-04-06 17:13 ` Laurent Pinchart
2020-04-06 16:39 ` [PATCH v7 06/11] media: imx: utils: Rename pixel format selection enumeration Steve Longerbeam
2020-04-06 16:39 ` [PATCH v7 07/11] media: imx: utils: Introduce PIXFMT_SEL_IPU Steve Longerbeam
2020-04-06 16:39 ` [PATCH v7 08/11] media: imx: utils: Make imx_media_pixfmt handle variable number of codes Steve Longerbeam
2020-04-06 16:39 ` [PATCH v7 09/11] media: imx: utils: Split find|enum_format into fourcc and mbus functions Steve Longerbeam
2020-04-06 16:39 ` [PATCH v7 10/11] media: imx: utils: Rename format lookup and enumeration functions Steve Longerbeam
2020-04-06 16:39 ` [PATCH v7 11/11] media: imx: utils: Constify some mbus and ipu_image arguments Steve Longerbeam
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=20200421131244.763f82df@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rmfrfs@gmail.com \
--cc=slongerbeam@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.