| Message ID | 20230815182431.18409-8-laurent.pinchart@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: i2c: imx219: Miscellaneous cleanups and improvements | expand |
Hi Laurent Thanks for the patch On Tue, 15 Aug 2023 at 19:24, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > While the ycbcr_enc field doesn't apply to raw formats, leaving it > uninitialized makes the driver behave in a less deterministic way. Fix > it by picking the default value for the colorspace. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > drivers/media/i2c/imx219.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c > index 8c61b748d9a5..976014ed7711 100644 > --- a/drivers/media/i2c/imx219.c > +++ b/drivers/media/i2c/imx219.c > @@ -499,6 +499,7 @@ static void imx219_update_pad_format(struct imx219 *imx219, > fmt->height = mode->height; > fmt->field = V4L2_FIELD_NONE; > fmt->colorspace = V4L2_COLORSPACE_RAW; > + fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace); > fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE; > fmt->xfer_func = V4L2_XFER_FUNC_NONE; In [1] for imx290 you requested that I change from using the V4L2_MAP_xxx_DEFAULT macros to hardcode them, and now you're mixing and matching the two in the same driver. Could we have some consistency please? Personally I don't mind which is used, but mixing and matching within a driver feels wrong. (If there is a genuine desire for V4L2_MAP_xxx_DEFAULT or hardcoding in sensor drivers, it'd be nice if it was documented to avoid additional review cycles). Also just noting that you seem not to be using get_maintainers for your patches as I appear not to have been included. Dave [1] https://patchwork.linuxtv.org/project/linux-media/patch/20230131192016.3476937-3-dave.stevenson@raspberrypi.com/#144299 > } > -- > Regards, > > Laurent Pinchart >
Hi Dave, (CC'ing Hans Verkuil). On Thu, Aug 17, 2023 at 12:00:10PM +0100, Dave Stevenson wrote: > On Tue, 15 Aug 2023 at 19:24, Laurent Pinchart wrote: > > > > While the ycbcr_enc field doesn't apply to raw formats, leaving it > > uninitialized makes the driver behave in a less deterministic way. Fix > > it by picking the default value for the colorspace. > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > --- > > drivers/media/i2c/imx219.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c > > index 8c61b748d9a5..976014ed7711 100644 > > --- a/drivers/media/i2c/imx219.c > > +++ b/drivers/media/i2c/imx219.c > > @@ -499,6 +499,7 @@ static void imx219_update_pad_format(struct imx219 *imx219, > > fmt->height = mode->height; > > fmt->field = V4L2_FIELD_NONE; > > fmt->colorspace = V4L2_COLORSPACE_RAW; > > + fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace); > > fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE; > > fmt->xfer_func = V4L2_XFER_FUNC_NONE; > > In [1] for imx290 you requested that I change from using the > V4L2_MAP_xxx_DEFAULT macros to hardcode them, and now you're mixing > and matching the two in the same driver. > Could we have some consistency please? Personally I don't mind which > is used, but mixing and matching within a driver feels wrong. > (If there is a genuine desire for V4L2_MAP_xxx_DEFAULT or hardcoding > in sensor drivers, it'd be nice if it was documented to avoid > additional review cycles). Absolutely, sorry about this. I'll fix it in v2 and use V4L2_MAP_YCBCR_ENC_601. Hans, should we add a V4L2_YCBCR_ENC_NONE for non-YUV formats ? > Also just noting that you seem not to be using get_maintainers for > your patches as I appear not to have been included. I'm not sure how that happened, as I use get_maintainer.pl. I probably made a mistake somewhere. Sorry about that. I was actually looking forward to your review of the series :-) > [1] https://patchwork.linuxtv.org/project/linux-media/patch/20230131192016.3476937-3-dave.stevenson@raspberrypi.com/#144299 > > > }
Hi Dave, On Thu, Aug 17, 2023 at 02:59:25PM +0300, Laurent Pinchart wrote: > Hi Dave, > > (CC'ing Hans Verkuil). > > On Thu, Aug 17, 2023 at 12:00:10PM +0100, Dave Stevenson wrote: > > On Tue, 15 Aug 2023 at 19:24, Laurent Pinchart wrote: > > > > > > While the ycbcr_enc field doesn't apply to raw formats, leaving it > > > uninitialized makes the driver behave in a less deterministic way. Fix > > > it by picking the default value for the colorspace. > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > --- > > > drivers/media/i2c/imx219.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c > > > index 8c61b748d9a5..976014ed7711 100644 > > > --- a/drivers/media/i2c/imx219.c > > > +++ b/drivers/media/i2c/imx219.c > > > @@ -499,6 +499,7 @@ static void imx219_update_pad_format(struct imx219 *imx219, > > > fmt->height = mode->height; > > > fmt->field = V4L2_FIELD_NONE; > > > fmt->colorspace = V4L2_COLORSPACE_RAW; > > > + fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace); > > > fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE; > > > fmt->xfer_func = V4L2_XFER_FUNC_NONE; > > > > In [1] for imx290 you requested that I change from using the > > V4L2_MAP_xxx_DEFAULT macros to hardcode them, and now you're mixing > > and matching the two in the same driver. > > Could we have some consistency please? Personally I don't mind which > > is used, but mixing and matching within a driver feels wrong. > > (If there is a genuine desire for V4L2_MAP_xxx_DEFAULT or hardcoding > > in sensor drivers, it'd be nice if it was documented to avoid > > additional review cycles). > > Absolutely, sorry about this. I'll fix it in v2 and use > V4L2_MAP_YCBCR_ENC_601. > > Hans, should we add a V4L2_YCBCR_ENC_NONE for non-YUV formats ? > > > Also just noting that you seem not to be using get_maintainers for > > your patches as I appear not to have been included. > > I'm not sure how that happened, as I use get_maintainer.pl. I probably > made a mistake somewhere. Sorry about that. I was actually looking > forward to your review of the series :-) Actually, you were on CC, so I'm not sure why you haven't received the series. > > [1] https://patchwork.linuxtv.org/project/linux-media/patch/20230131192016.3476937-3-dave.stevenson@raspberrypi.com/#144299 > > > > > }
diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c index 8c61b748d9a5..976014ed7711 100644 --- a/drivers/media/i2c/imx219.c +++ b/drivers/media/i2c/imx219.c @@ -499,6 +499,7 @@ static void imx219_update_pad_format(struct imx219 *imx219, fmt->height = mode->height; fmt->field = V4L2_FIELD_NONE; fmt->colorspace = V4L2_COLORSPACE_RAW; + fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace); fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE; fmt->xfer_func = V4L2_XFER_FUNC_NONE; }
While the ycbcr_enc field doesn't apply to raw formats, leaving it uninitialized makes the driver behave in a less deterministic way. Fix it by picking the default value for the colorspace. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- drivers/media/i2c/imx219.c | 1 + 1 file changed, 1 insertion(+)