Re: [PATCH] v4l: vsp1: Add support for capture and output in HSV formats
Hi Laurent Thank you very much! On Wed, Sep 7, 2016 at 2:14 AM, Laurent Pinchart wrote: > Support both the HSV24 and HSV32 formats. From a hardware point of view > pretend the formats are RGB, the RPF and WPF will just pass the data > through without performing any processing. Signed-off-by: Ricardo Ribalda Delgado -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: vsp1: Add support for capture and output in HSV formats
Hi Laurent, On Wed, Sep 7, 2016 at 9:09 AM, Laurent Pinchart wrote: >> >> Signed-off-by: Ricardo Ribalda Delgado > > Do you mean Acked-by ? Acked-by: Ricardo Ribalda Delgado Ups, my bad > > Feel free to take the patch in your tree to get it merged along with the HSV > series. I do not really have a tree, I have a github account that is it. Let me ask Hans on the irc how to procede from here. I really appreciate your help! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] HSV formats
Hi Mauro, These patches add support for HSV. HSV formats are extremely useful for image segmentation. This set of patches makes v4l2 aware of this kind of formats. Vivid changes have been divided to ease the reviewing process. We are working on patches for Gstreamer and OpenCV that will make use of these formats. This pull request contains [PATCH v5 00/12] Add HSV format, plus the following chanes: -It has been rebased to media/master -Laurent patch to add support for vsp1 -Hans Ack-by -Documentation now make use of tabularcolumn (latex) This is my first pull request :) Please pull The following changes since commit 036bbb8213ecca49799217f30497dc0484178e53: [media] cobalt: update EDID (2016-09-06 16:46:39 -0300) are available in the git repository at: https://github.com/ribalda/linux.git vivid-hsv-v6 for you to fetch changes up to 1242d7e43b9053cd649ac5ec81aad8597e88ab46: [media] vsp1: Add support for capture and output in HSV formats (2016-09-07 10:41:52 +0200) Laurent Pinchart (1): [media] vsp1: Add support for capture and output in HSV formats Ricardo Ribalda Delgado (12): [media] videodev2.h Add HSV formats [media] Documentation: Add HSV format [media] Documentation: Add Ricardo Ribalda [media] vivid: Code refactor for color encoding [media] vivid: Add support for HSV formats [media] vivid: Rename variable [media] vivid: Introduce TPG_COLOR_ENC_LUMA [media] vivid: Fix YUV555 and YUV565 handling [media] vivid: Local optimization [media] videodev2.h Add HSV encoding [media] Documentation: Add HSV encodings [media] vivid: Add support for HSV encoding Documentation/media/uapi/v4l/hsv-formats.rst | 19 Documentation/media/uapi/v4l/pixfmt-002.rst| 12 +- Documentation/media/uapi/v4l/pixfmt-003.rst| 14 ++- Documentation/media/uapi/v4l/pixfmt-006.rst| 43 ++- Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 164 +++ Documentation/media/uapi/v4l/pixfmt.rst| 1 + Documentation/media/uapi/v4l/v4l2.rst | 9 ++ Documentation/media/videodev2.h.rst.exceptions | 4 + drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 411 --- drivers/media/platform/vivid/vivid-core.h | 3 +- drivers/media/platform/vivid/vivid-ctrls.c | 25 + drivers/media/platform/vivid/vivid-vid-cap.c | 17 ++- drivers/media/platform/vivid/vivid-vid-common.c| 68 ++- drivers/media/platform/vivid/vivid-vid-out.c | 1 + drivers/media/platform/vsp1/vsp1_pipe.c| 8 ++ drivers/media/platform/vsp1/vsp1_rwpf.c| 2 + drivers/media/platform/vsp1/vsp1_video.c | 5 + drivers/media/v4l2-core/v4l2-ioctl.c | 2 + include/media/v4l2-tpg.h | 24 +++- include/uapi/linux/videodev2.h | 36 +- 20 files changed, 685 insertions(+), 183 deletions(-) create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] HSV formats v2
Hi Mauro, These is the last PULL request rebased to your last master thanks to Laurent :) These patches add support for HSV. HSV formats are extremely useful for image segmentation. This set of patches makes v4l2 aware of this kind of formats. Vivid changes have been divided to ease the reviewing process. We are working on patches for Gstreamer and OpenCV that will make use of these formats. This pull request contains [PATCH v5 00/12] Add HSV format, plus the following chanes: -It has been rebased to media/master -Laurent patch to add support for vsp1 -Hans Ack-by -Documentation now make use of tabularcolumn (latex) Please pull: The following changes since commit 11a1e0ed7908f04c896e69d0eb65e478c12f8519: [media] dvb-usb: warn if return value for USB read/write routines is not checked (2016-10-14 12:52:31 -0300) are available in the git repository at: https://github.com/ribalda/linux.git vivid-hsv-v7 for you to fetch changes up to 7cb9d88402c4f674887af165e1425f1fd347583f: v4l: vsp1: Add support for capture and output in HSV formats (2016-10-17 23:20:10 +0200) Laurent Pinchart (1): v4l: vsp1: Add support for capture and output in HSV formats Ricardo Ribalda Delgado (12): videodev2.h Add HSV formats Documentation: Add HSV format Documentation: Add Ricardo Ribalda vivid: Code refactor for color encoding vivid: Add support for HSV formats vivid: Rename variable vivid: Introduce TPG_COLOR_ENC_LUMA vivid: Fix YUV555 and YUV565 handling vivid: Local optimization videodev2.h Add HSV encoding Documentation: Add HSV encodings vivid: Add support for HSV encoding Documentation/media/uapi/v4l/hsv-formats.rst | 19 + Documentation/media/uapi/v4l/pixfmt-002.rst| 5 + Documentation/media/uapi/v4l/pixfmt-003.rst| 5 + Documentation/media/uapi/v4l/pixfmt-006.rst| 31 +- Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 157 Documentation/media/uapi/v4l/pixfmt.rst| 1 + Documentation/media/uapi/v4l/v4l2.rst | 9 + Documentation/media/videodev2.h.rst.exceptions | 4 + drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 411 ++--- drivers/media/platform/vivid/vivid-core.h | 3 +- drivers/media/platform/vivid/vivid-ctrls.c | 25 ++ drivers/media/platform/vivid/vivid-vid-cap.c | 17 +- drivers/media/platform/vivid/vivid-vid-common.c| 68 ++-- drivers/media/platform/vivid/vivid-vid-out.c | 1 + drivers/media/platform/vsp1/vsp1_pipe.c| 8 + drivers/media/platform/vsp1/vsp1_rwpf.c| 2 + drivers/media/platform/vsp1/vsp1_video.c | 5 + drivers/media/v4l2-core/v4l2-ioctl.c | 2 + include/media/v4l2-tpg.h | 24 +- include/uapi/linux/videodev2.h | 36 +- 20 files changed, 653 insertions(+), 180 deletions(-) create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFP] Media Summit: Save/Restore controls from MTD
Industrial/Scientific sensors usually come with very extensive calibration information such as: per column gain, list of dead/pixels, temperature sensor offset... etc We are saving that information on an flash device that is located by the sensor. I would like some minutes (15 max) to show you how we are integrating that calibration flash with v4l2-ctrl. And if this feature is useful for someone else and upstream it. Thanks! -- Ricardo Ribalda
[PATCH] libv4l: Add support for BAYER10P format conversion
Add support for 10 bit packet Bayer formats:
-V4L2_PIX_FMT_SBGGR10P
-V4L2_PIX_FMT_SGBRG10P
-V4L2_PIX_FMT_SGRBG10P
-V4L2_PIX_FMT_SRGGB10P
These formats pack the 2 LSBs for every 4 pixels in an indeppendent
byte.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/bayer.c | 15 +++
lib/libv4lconvert/libv4lconvert-priv.h | 4 +++
lib/libv4lconvert/libv4lconvert.c | 35 ++
3 files changed, 54 insertions(+)
diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
index 4b70ddd9..d7d488f9 100644
--- a/lib/libv4lconvert/bayer.c
+++ b/lib/libv4lconvert/bayer.c
@@ -631,3 +631,18 @@ void v4lconvert_bayer_to_yuv420(const unsigned char
*bayer, unsigned char *yuv,
v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
!start_with_green, !blue_line);
}
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height)
+{
+ long i, len = width * height;
+ uint32_t *src, *dst;
+
+ src = (uint32_t *)bayer10p;
+ dst = (uint32_t *)bayer8;
+ for (i = 0; i < len ; i += 4) {
+ *dst = *src;
+ dst++;
+ src = (uint32_t *)(((uint8_t *)src) + 5);
+ }
+}
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 9a467e10..3020a39e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char *yuv,
int width, int height, const unsigned int stride, unsigned int
src_pixfmt, int yvu);
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height);
+
void v4lconvert_hm12_to_rgb24(const unsigned char *src,
unsigned char *dst, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index d666bd97..b3dbf5a0 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SRGGB8, 8, 8, 8, 0 },
{ V4L2_PIX_FMT_STV0680, 8, 8, 8, 1 },
{ V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
+ { V4L2_PIX_FMT_SBGGR10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SGBRG10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SGRBG10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SRGGB10P,10, 8, 8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
{ V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
@@ -687,6 +691,10 @@ static int v4lconvert_processing_needs_double_conversion(
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
case V4L2_PIX_FMT_STV0680:
return 0;
}
@@ -979,6 +987,33 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
/* Raw bayer formats */
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
+ if (src_size < ((width * height * 10)/8)) {
+ V4LCONVERT_ERR("short raw bayer10 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ switch (src_pix_fmt) {
+ case V4L2_PIX_FMT_SBGGR10P:
+ src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+ break;
+ case V4L2_PIX_FMT_SGBRG10P:
+ src_pix_fmt = V4L2_PIX_FMT_SGBRG8;
+ break;
+ case V4L2_PIX_FMT_SGRBG10P:
+ src_pix_fmt = V4L2_PIX_FMT_SGRBG8;
+ break;
+ case V4L2_PIX_FMT_SRGGB10P:
+ src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+ break;
+ }
+ v4lconvert_bayer10p_to_bayer8(src, src, width, height);
+ bytesperline = width;
+
+ /* Fall-through*/
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
--
2.18.0
ad5820: Sorry for the invalid v3
HI Sorry, I did not check the produced files before sending them with git send-email. It has been a long day. Please ignore v3 and use v4. I will write 100 times: I will check my patches before sending them to the mailing list Cheers -- Ricardo Ribalda
Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
HI
On Thu, Sep 20, 2018 at 11:13 PM Laurent Pinchart
wrote:
>
> Hi Sakari,
>
> On Thursday, 20 September 2018 23:56:59 EEST Sakari Ailus wrote:
> > On Thu, Sep 20, 2018 at 05:51:55PM +0900, Tomasz Figa wrote:
> > > On Wed, Aug 8, 2018 at 4:08 PM Ping-chung Chen wrote:
> > > [snip]
> > >
> > > > +
> > > > +/* Digital gain control */
> > > > +#define IMX208_REG_GR_DIGITAL_GAIN 0x020e
> > > > +#define IMX208_REG_R_DIGITAL_GAIN 0x0210
> > > > +#define IMX208_REG_B_DIGITAL_GAIN 0x0212
> > > > +#define IMX208_REG_GB_DIGITAL_GAIN 0x0214
> > > > +#define IMX208_DGTL_GAIN_MIN 0
> > > > +#define IMX208_DGTL_GAIN_MAX 4096
> > > > +#define IMX208_DGTL_GAIN_DEFAULT 0x100
> > > > +#define IMX208_DGTL_GAIN_STEP 1
> > > > +
> > >
> > > [snip]
> > >
> > > > +/* Initialize control handlers */
> > > > +static int imx208_init_controls(struct imx208 *imx208)
> > > > +{
> > >
> > > [snip]
> > >
> > > > + v4l2_ctrl_new_std(ctrl_hdlr, &imx208_ctrl_ops,
> > > > V4L2_CID_DIGITAL_GAIN, + IMX208_DGTL_GAIN_MIN,
> > > > IMX208_DGTL_GAIN_MAX, + IMX208_DGTL_GAIN_STEP,
> > > > + IMX208_DGTL_GAIN_DEFAULT);
> > >
> > > We have a problem here. The sensor supports only a discrete range of
> > > values here - {1, 2, 4, 8, 16} (multiplied by 256, since the value is
> > > fixed point). This makes it possible for the userspace to set values
> > > that are not allowed by the sensor specification and also leaves no
> > > way to enumerate the supported values.
> > >
> > > I can see two solutions here:
> > >
> > > 1) Define the control range from 0 to 4 and treat it as an exponent of
> > > 2, so that the value for the sensor becomes (1 << val) * 256.
> > > (Suggested by Sakari offline.)
> > >
> > > This approach has the problem of losing the original unit (and scale)
> > > of the value.
> >
> > I'd like to add that this is not a property of the proposed solution.
> >
> > Rather, the above needs to be accompanied by additional information
> > provided through VIDIOC_QUERY_EXT_CTRL, i.e. the unit, prefix as well as
> > other information such as whether the control is linear or exponential (as
> > in this case).
> >
> > > 2) Use an integer menu control, which reports only the supported
> > > discrete values - {1, 2, 4, 8, 16}.
> > >
> > > With this approach, userspace can enumerate the real gain values, but
> > > we would either need to introduce a new control (e.g.
> > > V4L2_CID_DIGITAL_GAIN_DISCRETE) or abuse the specification and
> > > register V4L2_CID_DIGITAL_GAIN as an integer menu.
> >
> > New controls in V4L2 are, for the most part, created when there's something
> > new to control. The documentation of some controls (similar to e.g. gain)
> > documents a unit as well as a prefix but that's the case only because
> > there's been no way to tell the unit or prefix otherwise in the API.
> >
> > An exception to this are EXPOSURE and EXPOSURE_ABSOLUTE. I'm not entirely
> > sure how they came to be though. An accident is a possibility as far as I
> > see.
>
> If I remember correctly I introduced the absolute variant for the UVC driver
> (even though git blame points to Brandon Philips). I don't really remember why
> though.
>
> > Controls that have a documented unit use that unit --- as long as that's
> > the unit used by the hardware. If it's not, it tends to be that another
> > unit is used but the user space has currently no way of knowing this. And
> > the digital gain control is no exception to this.
> >
> > So if we want to improve the user space's ability to be informed how the
> > control values reflect to device configuration, we do need to provide more
> > information to the user space. One way to do that would be through
> > VIDIOC_QUERY_EXT_CTRL. The IOCTL struct has plenty of reserved fields ---
> > just for purposes such as this one.
>
> I don't think we can come up with a good way to expose arbitrary mathematical
> formulas through an ioctl. In my opinion the question is how far we want to
> go, how precise we need to be.
>
> > > Any opinions or better ideas?
My 0.02 DKK. On a similar situation, where userspace was running a
close loop calibration:
We have implemented two extra control: eposure_next exposure_pre that
tell us which one is the next value. Perhaps we could embebed such
functionality in QUERY_EXT_CTRL.
Cheers
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
--
Ricardo Ribalda
Re: [PATCH] libv4l: Add support for BAYER10P format conversion
Hi Hans
On Fri, Sep 21, 2018 at 9:38 AM Hans de Goede wrote:
>
> Hi,
>
> On 20-09-18 22:04, Ricardo Ribalda Delgado wrote:
> > Add support for 10 bit packet Bayer formats:
> > -V4L2_PIX_FMT_SBGGR10P
> > -V4L2_PIX_FMT_SGBRG10P
> > -V4L2_PIX_FMT_SGRBG10P
> > -V4L2_PIX_FMT_SRGGB10P
> >
> > These formats pack the 2 LSBs for every 4 pixels in an indeppendent
> > byte.
> >
> > Signed-off-by: Ricardo Ribalda Delgado
> > ---
> > lib/libv4lconvert/bayer.c | 15 +++
> > lib/libv4lconvert/libv4lconvert-priv.h | 4 +++
> > lib/libv4lconvert/libv4lconvert.c | 35 ++
> > 3 files changed, 54 insertions(+)
> >
> > diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
> > index 4b70ddd9..d7d488f9 100644
> > --- a/lib/libv4lconvert/bayer.c
> > +++ b/lib/libv4lconvert/bayer.c
> > @@ -631,3 +631,18 @@ void v4lconvert_bayer_to_yuv420(const unsigned char
> > *bayer, unsigned char *yuv,
> > v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
> > !start_with_green, !blue_line);
> > }
> > +
> > +void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
> > + unsigned char *bayer8, int width, int height)
> > +{
> > + long i, len = width * height;
> > + uint32_t *src, *dst;
> > +
> > + src = (uint32_t *)bayer10p;
> > + dst = (uint32_t *)bayer8;
> > + for (i = 0; i < len ; i += 4) {
> > + *dst = *src;
> > + dst++;
> > + src = (uint32_t *)(((uint8_t *)src) + 5);
>
> This will lead to unaligned 32 bit integer accesses which will terminate
> the program with an illegal instruction on pretty much all architectures
> except for x86.
I see your point, but I am actually using this code on ARM64 with no issues.
I will change it.
>
> You will need to copy the 4 components 1 by 1 so that you only
> use byte accesses.
>
> Also you seem to simply be throwing away the extra 2 bits, although
> that will work I wonder if that is the best we can do?
Those are the LSB. If the user want the extra resolution has to use
the bayer mode.
>
> Regards,
>
> Hans
>
>
>
> > + }
> > +}
>
>
>
> > diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
> > b/lib/libv4lconvert/libv4lconvert-priv.h
> > index 9a467e10..3020a39e 100644
> > --- a/lib/libv4lconvert/libv4lconvert-priv.h
> > +++ b/lib/libv4lconvert/libv4lconvert-priv.h
> > @@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char
> > *bayer,
> > void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char
> > *yuv,
> > int width, int height, const unsigned int stride, unsigned
> > int src_pixfmt, int yvu);
> >
> > +
> > +void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
> > + unsigned char *bayer8, int width, int height);
> > +
> > void v4lconvert_hm12_to_rgb24(const unsigned char *src,
> > unsigned char *dst, int width, int height);
> >
> > diff --git a/lib/libv4lconvert/libv4lconvert.c
> > b/lib/libv4lconvert/libv4lconvert.c
> > index d666bd97..b3dbf5a0 100644
> > --- a/lib/libv4lconvert/libv4lconvert.c
> > +++ b/lib/libv4lconvert/libv4lconvert.c
> > @@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt
> > supported_src_pixfmts[] = {
> > { V4L2_PIX_FMT_SRGGB8, 8, 8, 8, 0 },
> > { V4L2_PIX_FMT_STV0680, 8, 8, 8, 1 },
> > { V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
> > + { V4L2_PIX_FMT_SBGGR10P,10, 8, 8, 1 },
> > + { V4L2_PIX_FMT_SGBRG10P,10, 8, 8, 1 },
> > + { V4L2_PIX_FMT_SGRBG10P,10, 8, 8, 1 },
> > + { V4L2_PIX_FMT_SRGGB10P,10, 8, 8, 1 },
> > /* compressed bayer */
> > { V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
> > { V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
> > @@ -687,6 +691,10 @@ static int
> > v4lconvert_processing_needs_double_conversion(
> > case V4L2_PIX_FMT_SGBRG8:
> > case V4L2_PIX_FMT_SGRBG8:
> > case V4L2_PIX_FMT_SRGGB8:
> > + case V4L2_PIX_FMT_SBGGR10P:
> > + case V4L2_PIX_FMT_SGBRG10P:
> > + case V4L2_PIX_FMT_SGRBG10P:
> > + case V4L2_PIX_FMT_SRGGB10P:
> > case V4L2_PIX_FMT_STV0680:
> > return 0;
> > }
>
[PATCH v2] libv4l: Add support for BAYER10P format conversion
Add support for 10 bit packet Bayer formats:
-V4L2_PIX_FMT_SBGGR10P
-V4L2_PIX_FMT_SGBRG10P
-V4L2_PIX_FMT_SGRBG10P
-V4L2_PIX_FMT_SRGGB10P
These formats pack the 2 LSBs for every 4 pixels in an indeppendent
byte.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/bayer.c | 21
lib/libv4lconvert/libv4lconvert-priv.h | 4 +++
lib/libv4lconvert/libv4lconvert.c | 35 ++
3 files changed, 60 insertions(+)
diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
index 4b70ddd9..11af6543 100644
--- a/lib/libv4lconvert/bayer.c
+++ b/lib/libv4lconvert/bayer.c
@@ -631,3 +631,24 @@ void v4lconvert_bayer_to_yuv420(const unsigned char
*bayer, unsigned char *yuv,
v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
!start_with_green, !blue_line);
}
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height)
+{
+ unsigned long i;
+ unsigned long len = width * height;
+
+ for (i = 0; i < len ; i += 4) {
+ /*
+* Do not use a second loop, hoping that
+* a clever compiler with understand the
+* pattern and will optimize it.
+*/
+ bayer8[0] = bayer10p[0];
+ bayer8[1] = bayer10p[1];
+ bayer8[2] = bayer10p[2];
+ bayer8[3] = bayer10p[3];
+ bayer10p += 5;
+ bayer8 += 4;
+ }
+}
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 9a467e10..3020a39e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char *yuv,
int width, int height, const unsigned int stride, unsigned int
src_pixfmt, int yvu);
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height);
+
void v4lconvert_hm12_to_rgb24(const unsigned char *src,
unsigned char *dst, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index d666bd97..b3dbf5a0 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SRGGB8, 8, 8, 8, 0 },
{ V4L2_PIX_FMT_STV0680, 8, 8, 8, 1 },
{ V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
+ { V4L2_PIX_FMT_SBGGR10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SGBRG10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SGRBG10P,10, 8, 8, 1 },
+ { V4L2_PIX_FMT_SRGGB10P,10, 8, 8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
{ V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
@@ -687,6 +691,10 @@ static int v4lconvert_processing_needs_double_conversion(
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
case V4L2_PIX_FMT_STV0680:
return 0;
}
@@ -979,6 +987,33 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
/* Raw bayer formats */
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
+ if (src_size < ((width * height * 10)/8)) {
+ V4LCONVERT_ERR("short raw bayer10 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ switch (src_pix_fmt) {
+ case V4L2_PIX_FMT_SBGGR10P:
+ src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+ break;
+ case V4L2_PIX_FMT_SGBRG10P:
+ src_pix_fmt = V4L2_PIX_FMT_SGBRG8;
+ break;
+ case V4L2_PIX_FMT_SGRBG10P:
+ src_pix_fmt = V4L2_PIX_FMT_SGRBG8;
+ break;
+ case V4L2_PIX_FMT_SRGGB10P:
+ src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+ break;
+ }
+ v4lconvert_bayer10p_to_bayer8(src, src, width, height);
+ bytesperline = width;
+
+ /* Fall-through*/
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
--
2.18.0
Power Management and lens-focus
Hello
I have started using the lens-focus property:
ad5820: dac@0c {
compatible = "adi,ad5820";
reg = <0x0c>;
VANA-supply = <&pm8994_l23>;
enable-gpios = <&msmgpio 26 GPIO_ACTIVE_HIGH>;
};
camera_rear@60 {
lens-focus = <&ad5820>;
};
I was testing my device using the following setup: qv4l2 grabbing
images and yavta changing the focus controls.
Unfortunately, this does not work (or does not work as I expected):
The ad5820 is powered off until it is open() (even during streamon),
so when yavta finished setting the control and closed the device the
focus was back to its original position :S.
Apparently, this has not been an issue before because usually there is
a close loop program constantly setting up the focus and not closing
the device.
Shouldn't we poweron the focus when the pipeline is running?
Regards!
--
Ricardo Ribalda
[PATCH] media: smiapp: Remove unused loop
The loop seemed to be made to calculate max, but max is not used in that
function.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/smiapp/smiapp-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 99f3b295ae3c..bccbf4c841d6 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -624,7 +624,7 @@ static int smiapp_init_late_controls(struct smiapp_sensor
*sensor)
{
unsigned long *valid_link_freqs = &sensor->valid_link_freqs[
sensor->csi_format->compressed - sensor->compressed_min_bpp];
- unsigned int max, i;
+ unsigned int i;
for (i = 0; i < ARRAY_SIZE(sensor->test_data); i++) {
int max_value = (1 << sensor->csi_format->width) - 1;
@@ -635,8 +635,6 @@ static int smiapp_init_late_controls(struct smiapp_sensor
*sensor)
0, max_value, 1, max_value);
}
- for (max = 0; sensor->hwcfg->op_sys_clock[max + 1]; max++);
-
sensor->link_freq = v4l2_ctrl_new_int_menu(
&sensor->src->ctrl_handler, &smiapp_ctrl_ops,
V4L2_CID_LINK_FREQ, __fls(*valid_link_freqs),
--
2.19.0
[PATCH v3 1/2] [media] imx214: device tree binding
Document bindings for imx214 camera sensor
Cc: devicet...@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
Changelog from v2:
Laurent Pinchart:
-Spell checks
-Remove frequency
-Identation
-Data lanes order
Thanks!
.../devicetree/bindings/media/i2c/imx214.txt | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx214.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/imx214.txt
b/Documentation/devicetree/bindings/media/i2c/imx214.txt
new file mode 100644
index ..bf3cac731eca
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx214.txt
@@ -0,0 +1,52 @@
+* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
+
+The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+an active array size of 4224H x 3200V. It is programmable through an I2C
+interface. The I2C address can be configured to to 0x1a or 0x10, depending on
+how the hardware is wired.
+Image data is sent through MIPI CSI-2, which is configured as 4 lanes
+at 1440 Mbps.
+
+
+Required Properties:
+- compatible: value should be "sony,imx214" for imx214 sensor
+- reg: I2C bus address of the device
+- enable-gpios: GPIO descriptor for the enable pin.
+- vdddo-supply: Chip digital IO regulator (1.8V).
+- vdda-supply: Chip analog regulator (2.7V).
+- vddd-supply: Chip digital core regulator (1.12V).
+- clocks = Reference to the xclk clock.
+- clock-names = Clock name, e.g. "xclk".
+- clock-frequency = Frequency of the xclk clock. (Currently the
+ driver only supports <2400>).
+
+Optional Properties:
+- flash-leds: See ../video-interfaces.txt
+- lens-focus: See ../video-interfaces.txt
+
+The imx274 device node should contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ camera_rear@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&mmcc CAMSS_MCLK0_CLK>;
+ clock-names = "xclk";
+ clock-frequency = <2400>;
+ port {
+ imx214_ep: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <48000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
2.19.0
Re: uvcvideo: IR camera lights only every second frame
Hi On Tue, Oct 30, 2018 at 4:49 PM Kieran Bingham wrote: > > Hi Jiri, > > On 30/10/2018 14:36, Jiri Slaby wrote: > > Hi, > > > > I have a Dell Lattitude 7280 with two webcams. The standard one works > > fine (/dev/video0). The other one is an IR camera (/dev/video1). The > > camera proper works fine and produces 340x374 frames. But there is an IR > > led supposed to light the object. The video is 30fps, but the LED seems > > to emit light only on half of the frames, i.e. on every second frame (15 > > fps). This makes the video blink a lot. The two consecutive frames look > > like: > > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0002.jpg > > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0003.jpg > > > > Do you have any ideas what to check/test? > > I have an HP Spectre with IR camera, and it also 'flashes' alternate frames. > > I assumed this was something to do with controlling the lighting for > face recognition some how. I think Kieran is right here. A very common way of detecting what is close to the camera is using NIR LEDs due to how directional they are. The algorithm is more or less: You have a camera with a NIR filter (the rbg camera) and a camera without. You alternate the NIR LEDs and substract both images. The results are the object on the front. You use that information to get what is in on the front of the RGB camera (unaffected by the NIR leds). Around 10 years ago we were using this approach for segmentation of body parts. It worked like a charm for getting biometrical parameters and detect gestures https://repositorio.uam.es/bitstream/handle/10486/664236/biometric_morales_LNCS_2009_ps.pdf?sequence=3&isAllowed=y Cheers! > > I'm fairly sure we don't control the 'IR flash' from the UVC. > > I wonder if there is a control parameter for the IR led in the > extension-units? > > -- > Regards > > Kieran > > > > > $ v4l2-ctl --all -d /dev/video2 > > Driver Info (not using libv4l2): > > Driver name : uvcvideo > > Card type : Integrated_Webcam_HD: Integrate > > Bus info : usb-:00:14.0-5 > > Driver version: 4.18.15 > > Capabilities : 0x84A1 > > Video Capture > > Metadata Capture > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x0421 > > Video Capture > > Streaming > > Extended Pix Format > > Priority: 2 > > Video input : 0 (Camera 11: ok) > > Format Video Capture: > > Width/Height : 340/374 > > Pixel Format : 'YUYV' > > Field : None > > Bytes per Line: 680 > > Size Image: 254320 > > Colorspace: sRGB > > Transfer Function : Default (maps to sRGB) > > YCbCr/HSV Encoding: Default (maps to ITU-R 601) > > Quantization : Default (maps to Limited Range) > > Flags : > > Crop Capability Video Capture: > > Bounds : Left 0, Top 0, Width 340, Height 374 > > Default : Left 0, Top 0, Width 340, Height 374 > > Pixel Aspect: 1/1 > > Selection: crop_default, Left 0, Top 0, Width 340, Height 374 > > Selection: crop_bounds, Left 0, Top 0, Width 340, Height 374 > > Streaming Parameters Video Capture: > > Capabilities : timeperframe > > Frames per second: 30.000 (30/1) > > Read buffers : 0 > > > > > > > > > > > > $ lsusb -vs 1:3 > > Bus 001 Device 003: ID 0bda:5691 Realtek Semiconductor Corp. > > Device Descriptor: > > bLength18 > > bDescriptorType 1 > > bcdUSB 2.00 > > bDeviceClass 239 Miscellaneous Device > > bDeviceSubClass 2 > > bDeviceProtocol 1 Interface Association > > bMaxPacketSize064 > > idVendor 0x0bda Realtek Semiconductor Corp. > > idProduct 0x5691 > > bcdDevice 60.12 > > iManufacturer 3 CNFGE16N5214300025C2 > > iProduct1 Integrated_Webcam_HD > > iSerial 2 0001 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 1041 > > bNumInterfaces 4 > > bConfigurationValue 1 > > iConfiguration 4 USB Camera > > bmAttributes 0x80 > > (Bus Powered) > > MaxPower 500mA > > ** UNRECOGNIZED: 28 ff 42 49 53 54 00 01 06 06 10 00 00 00 00 00 01 > > 07 f4 01 02 08 f4 01 03 09 f4 01 04 0a f4 01 05 0b f4 01 06 0c e8 03 > > Interface Association: > > bLength 8 > > bDescriptorType11 > > bFirstInterface 0 > > bInterfaceCount 2 > > bFunctionClass 14 Video > > bFunctionSubClass 3 Video Interface Collection > > bFunctionProtocol 0 > > iFunction
[PATCH v8 2/3] [media] imx214: Add imx214 camera sensor driver
Add a V4L2 sub-device driver for the Sony IMX214 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.
Tested on a DB820c alike board with Intrinsyc Open-Q 13MP camera.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Jacopo Mondi
---
Changelog from v7:
-remove unused define
Sakari Ailus (Thanks!):
parse_fwnode:
-Do not initialize ret
-goto done
-Do not call ctrl_handler_setup at probe
MAINTAINERS|8 +
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/imx214.c | 1116
4 files changed, 1137 insertions(+)
create mode 100644 drivers/media/i2c/imx214.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9989925f658d..2ae68894e700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13521,6 +13521,14 @@ S: Maintained
F: drivers/ssb/
F: include/linux/ssb/
+SONY IMX214 SENSOR DRIVER
+M: Ricardo Ribalda
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx214.c
+F: Documentation/devicetree/bindings/media/i2c/imx214.txt
+
SONY IMX258 SENSOR DRIVER
M: Sakari Ailus
L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index bfdb494686bf..d7e69ca0976c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -595,6 +595,18 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_IMX214
+ tristate "Sony IMX214 sensor support"
+ depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on V4L2_FWNODE
+ help
+ This is a Video4Linux2 sensor driver for the Sony
+ IMX214 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx214.
+
config VIDEO_IMX258
tristate "Sony IMX258 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index a94eb03d10d4..61305edc6165 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_VIDEO_I2C) += video-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
+obj-$(CONFIG_VIDEO_IMX214) += imx214.o
obj-$(CONFIG_VIDEO_IMX258) += imx258.o
obj-$(CONFIG_VIDEO_IMX274) += imx274.o
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
new file mode 100644
index ..46a2fdfbd049
--- /dev/null
+++ b/drivers/media/i2c/imx214.c
@@ -0,0 +1,1116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * imx214.c - imx214 sensor driver
+ *
+ * Copyright 2018 Qtechnology A/S
+ *
+ * Ricardo Ribalda
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX214_DEFAULT_CLK_FREQ2400
+#define IMX214_DEFAULT_LINK_FREQ 48000
+#define IMX214_DEFAULT_PIXEL_RATE ((IMX214_DEFAULT_LINK_FREQ * 8LL) / 10)
+#define IMX214_FPS 30
+#define IMX214_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
+
+static const char * const imx214_supply_name[] = {
+ "vdda",
+ "vddd",
+ "vdddo",
+};
+
+#define IMX214_NUM_SUPPLIES ARRAY_SIZE(imx214_supply_name)
+
+struct imx214 {
+ struct device *dev;
+ struct clk *xclk;
+ struct regmap *regmap;
+
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt fmt;
+ struct v4l2_rect crop;
+
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_ctrl *pixel_rate;
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *exposure;
+
+ struct regulator_bulk_data supplies[IMX214_NUM_SUPPLIES];
+
+ struct gpio_desc *enable_gpio;
+
+ struct mutex mutex;
+
+ bool streaming;
+};
+
+struct reg_8 {
+ u16 addr;
+ u8 val;
+};
+
+enum {
+ IMX214_TABLE_WAIT_MS = 0,
+ IMX214_TABLE_END,
+ IMX214_MAX_RETRIES,
+ IMX214_WAIT_MS
+};
+
+/*From imx214_mode_tbls.h*/
+static const struct reg_8 mode_4096x2304[] = {
+ {0x0114, 0x03},
+ {0x0220, 0x00},
+ {0x0221, 0x11},
+ {0x0222, 0x01},
+ {0x0340, 0x0C},
+ {0x0341, 0x7A},
+ {0x0342, 0x13},
+ {0x0343, 0x90},
+ {0x0344, 0x00},
+ {0x0345, 0x38},
+ {0x0346, 0x01},
+ {0x0347, 0x98},
+ {0x0348, 0x10},
+ {0x0349, 0x37},
+ {0x034A, 0x0A},
+ {0x034B, 0x97},
+ {0x0381, 0x01},
+ {0x0383, 0x01},
+ {0x0385, 0x01},
+ {0x0387, 0x01},
+ {0x0900, 0x00},
+ {0x0901, 0x00},
+ {0x0902, 0x00},
+ {0x3000, 0x35},
+ {0x3054, 0x01},
+ {0x305C, 0x11},
[PATCH v8 1/3] [media] imx214: device tree binding
From: Ricardo Ribalda
Document bindings for imx214 camera sensor
Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda Delgado
---
.../devicetree/bindings/media/i2c/imx214.txt | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx214.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/imx214.txt
b/Documentation/devicetree/bindings/media/i2c/imx214.txt
new file mode 100644
index ..421a019ab7f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx214.txt
@@ -0,0 +1,53 @@
+* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
+
+The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+an active array size of 4224H x 3200V. It is programmable through an I2C
+interface. The I2C address can be configured to 0x1a or 0x10, depending on
+how the hardware is wired.
+Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
+throughput of 1.2Gbps/lane.
+
+
+Required Properties:
+- compatible: value should be "sony,imx214" for imx214 sensor
+- reg: I2C bus address of the device
+- enable-gpios: GPIO descriptor for the enable pin.
+- vdddo-supply: Chip digital IO regulator (1.8V).
+- vdda-supply: Chip analog regulator (2.7V).
+- vddd-supply: Chip digital core regulator (1.12V).
+- clocks: Reference to the xclk clock.
+- clock-names: Shall be "xclk".
+
+Optional Properties:
+- flash-leds: See ../video-interfaces.txt
+- lens-focus: See ../video-interfaces.txt
+
+The imx214 device node shall contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Properties on endpoint:
+- data-lanes: check ../video-interfaces.txt
+- link-frequencies: check ../video-interfaces.txt
+- remote-endpoint: check ../video-interfaces.txt
+
+Example:
+
+ camera_rear@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&mmcc CAMSS_MCLK0_CLK>;
+ clock-names = "xclk";
+ port {
+ imx214_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <48000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
2.19.0
[PATCH v8 3/3] [media] imx214: Fix range for V4L2_CID_EXPOSURE
Going above 3184 changes the frame-rate of the sensor. Without this
patch there is no way to change the exposure without affecting the
frame-rate.
With the proper documentation we should be able the change the
frame-rate at wish, but until that happens we just cap what the sensor
can do.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/imx214.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index 46a2fdfbd049..0b99123161b8 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -1027,7 +1027,7 @@ static int imx214_probe(struct i2c_client *client)
*/
imx214->exposure = v4l2_ctrl_new_std(&imx214->ctrls, &imx214_ctrl_ops,
V4L2_CID_EXPOSURE,
-0, 0x, 1, 0x0c70);
+0, 3184, 1, 0x0c70);
ret = imx214->ctrls.error;
if (ret) {
--
2.19.0
[PATCH v9 1/3] [media] imx214: device tree binding
Document bindings for imx214 camera sensor
Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda Delgado
---
Changelog from v8:
Rob Herring:
-rename file
-Move address to reg
-rename name on example
-Patch author
Sakari Ailus:
-should->shall
.../bindings/media/i2c/sony,imx214.txt| 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
new file mode 100644
index ..2744773070c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
@@ -0,0 +1,53 @@
+* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
+
+The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+an active array size of 4224H x 3200V. It is programmable through an I2C
+interface.
+Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
+throughput of 1.2Gbps/lane.
+
+
+Required Properties:
+- compatible: Shall be "sony,imx214".
+- reg: I2C bus address of the device. Depending on how the sensor is wired,
+ it shall be <0x10> or <0x1a>;
+- enable-gpios: GPIO descriptor for the enable pin.
+- vdddo-supply: Chip digital IO regulator (1.8V).
+- vdda-supply: Chip analog regulator (2.7V).
+- vddd-supply: Chip digital core regulator (1.12V).
+- clocks: Reference to the xclk clock.
+- clock-names: Shall be "xclk".
+
+Optional Properties:
+- flash-leds: See ../video-interfaces.txt
+- lens-focus: See ../video-interfaces.txt
+
+The imx214 device node shall contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Properties on endpoint:
+- data-lanes: check ../video-interfaces.txt
+- link-frequencies: check ../video-interfaces.txt
+- remote-endpoint: check ../video-interfaces.txt
+
+Example:
+
+ camera-sensor@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&mmcc CAMSS_MCLK0_CLK>;
+ clock-names = "xclk";
+ port {
+ imx214_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <48000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
2.19.0
Re: [PATCH v9 1/3] [media] imx214: device tree binding
Hi Sakari
On Sat, Oct 6, 2018 at 12:02 AM Sakari Ailus wrote:
>
> Hi Ricardo,
>
> On Fri, Oct 05, 2018 at 11:57:50PM +0200, Ricardo Ribalda Delgado wrote:
> > Document bindings for imx214 camera sensor
> >
> > Cc: devicet...@vger.kernel.org
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Ricardo Ribalda Delgado
> > ---
> > Changelog from v8:
> >
> > Rob Herring:
> > -rename file
> > -Move address to reg
> > -rename name on example
> > -Patch author
> >
> > Sakari Ailus:
> > -should->shall
> >
> > .../bindings/media/i2c/sony,imx214.txt| 53 +++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
> > b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
> > new file mode 100644
> > index ..2744773070c5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
> > @@ -0,0 +1,53 @@
> > +* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
> > +
> > +The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor
> > with
> > +an active array size of 4224H x 3200V. It is programmable through an I2C
> > +interface.
> > +Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
> > +throughput of 1.2Gbps/lane.
> > +
> > +
> > +Required Properties:
> > +- compatible: Shall be "sony,imx214".
> > +- reg: I2C bus address of the device. Depending on how the sensor is wired,
> > + it shall be <0x10> or <0x1a>;
> > +- enable-gpios: GPIO descriptor for the enable pin.
> > +- vdddo-supply: Chip digital IO regulator (1.8V).
> > +- vdda-supply: Chip analog regulator (2.7V).
> > +- vddd-supply: Chip digital core regulator (1.12V).
> > +- clocks: Reference to the xclk clock.
> > +- clock-names: Shall be "xclk".
>
> It could be that this was already discussed earlier but I missed that ---
> clock frequency. Apologies for that. How does the driver know what to ask?
> If you expect assigned-clock-rate or such, then I think it should be
> explicitly said here.
It has becoming hard to follow, it is mainly my fault for sending 10 series :)
I think we discussed this here:
https://lkml.org/lkml/2018/10/2/1402
>
> You also have a single clock, so do you need clock-names?
Seems to be the de-facto standard Looking at:
grep xclk Documentation/devicetree/bindings/media/i2c/*
But the driver does not look for a specific name. I am going to remove the name.
>
> > +
> > +Optional Properties:
> > +- flash-leds: See ../video-interfaces.txt
> > +- lens-focus: See ../video-interfaces.txt
> > +
> > +The imx214 device node shall contain one 'port' child node with
> > +an 'endpoint' subnode. For further reading on port node refer to
> > +Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +
> > +Required Properties on endpoint:
> > +- data-lanes: check ../video-interfaces.txt
> > +- link-frequencies: check ../video-interfaces.txt
> > +- remote-endpoint: check ../video-interfaces.txt
> > +
> > +Example:
> > +
> > + camera-sensor@1a {
> > + compatible = "sony,imx214";
> > + reg = <0x1a>;
> > + vdddo-supply = <&pm8994_lvs1>;
> > + vddd-supply = <&camera_vddd_1v12>;
> > + vdda-supply = <&pm8994_l17>;
> > + lens-focus = <&ad5820>;
> > + enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
> > + clocks = <&mmcc CAMSS_MCLK0_CLK>;
> > + clock-names = "xclk";
> > + port {
> > + imx214_ep: endpoint {
> > + data-lanes = <1 2 3 4>;
> > + link-frequencies = /bits/ 64 <48000>;
> > + remote-endpoint = <&csiphy0_ep>;
> > + };
> > + };
> > + };
> > --
> > 2.19.0
> >
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi
--
Ricardo Ribalda
[PATCH v10 1/3] [media] imx214: device tree binding
Document bindings for imx214 camera sensor
Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda Delgado
---
Changelog from v10:
Sakari Ailus:
-remove clock name
.../bindings/media/i2c/sony,imx214.txt| 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
new file mode 100644
index ..8739ec871fb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
@@ -0,0 +1,51 @@
+* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
+
+The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+an active array size of 4224H x 3200V. It is programmable through an I2C
+interface.
+Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
+throughput of 1.2Gbps/lane.
+
+
+Required Properties:
+- compatible: Shall be "sony,imx214".
+- reg: I2C bus address of the device. Depending on how the sensor is wired,
+ it shall be <0x10> or <0x1a>;
+- enable-gpios: GPIO descriptor for the enable pin.
+- vdddo-supply: Chip digital IO regulator (1.8V).
+- vdda-supply: Chip analog regulator (2.7V).
+- vddd-supply: Chip digital core regulator (1.12V).
+- clocks: Reference to the xclk clock.
+
+Optional Properties:
+- flash-leds: See ../video-interfaces.txt
+- lens-focus: See ../video-interfaces.txt
+
+The imx214 device node shall contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Properties on endpoint:
+- data-lanes: check ../video-interfaces.txt
+- link-frequencies: check ../video-interfaces.txt
+- remote-endpoint: check ../video-interfaces.txt
+
+Example:
+
+ camera-sensor@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&mmcc CAMSS_MCLK0_CLK>;
+ port {
+ imx214_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <48000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
2.19.0
[PATCH v11 1/3] [media] imx214: device tree binding
Document bindings for imx214 camera sensor
Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda Delgado
---
Changelog from v10:
Sakari Ailus:
-Re-introduce clock-frequency property
.../bindings/media/i2c/sony,imx214.txt| 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
new file mode 100644
index ..f11f28a5fda4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
@@ -0,0 +1,53 @@
+* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
+
+The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+an active array size of 4224H x 3200V. It is programmable through an I2C
+interface.
+Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
+throughput of 1.2Gbps/lane.
+
+
+Required Properties:
+- compatible: Shall be "sony,imx214".
+- reg: I2C bus address of the device. Depending on how the sensor is wired,
+ it shall be <0x10> or <0x1a>;
+- enable-gpios: GPIO descriptor for the enable pin.
+- vdddo-supply: Chip digital IO regulator (1.8V).
+- vdda-supply: Chip analog regulator (2.7V).
+- vddd-supply: Chip digital core regulator (1.12V).
+- clocks: Reference to the xclk clock.
+- clock-frequency: Frequency of the xclk clock.
+
+Optional Properties:
+- flash-leds: See ../video-interfaces.txt
+- lens-focus: See ../video-interfaces.txt
+
+The imx214 device node shall contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Properties on endpoint:
+- data-lanes: check ../video-interfaces.txt
+- link-frequencies: check ../video-interfaces.txt
+- remote-endpoint: check ../video-interfaces.txt
+
+Example:
+
+ camera-sensor@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&mmcc CAMSS_MCLK0_CLK>;
+ clock-frequency = <2400>;
+ port {
+ imx214_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <48000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
2.19.0
[PATCH v11 2/3] [media] imx214: Add imx214 camera sensor driver
Add a V4L2 sub-device driver for the Sony IMX214 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.
Tested on a DB820c alike board with Intrinsyc Open-Q 13MP camera.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Jacopo Mondi
---
Changelog from v10:
-Fix checkpatch strict
MAINTAINERS|8 +
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/imx214.c | 1118
4 files changed, 1139 insertions(+)
create mode 100644 drivers/media/i2c/imx214.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9989925f658d..2ae68894e700 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13521,6 +13521,14 @@ S: Maintained
F: drivers/ssb/
F: include/linux/ssb/
+SONY IMX214 SENSOR DRIVER
+M: Ricardo Ribalda
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx214.c
+F: Documentation/devicetree/bindings/media/i2c/imx214.txt
+
SONY IMX258 SENSOR DRIVER
M: Sakari Ailus
L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index bfdb494686bf..d7e69ca0976c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -595,6 +595,18 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_IMX214
+ tristate "Sony IMX214 sensor support"
+ depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on V4L2_FWNODE
+ help
+ This is a Video4Linux2 sensor driver for the Sony
+ IMX214 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx214.
+
config VIDEO_IMX258
tristate "Sony IMX258 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index a94eb03d10d4..61305edc6165 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_VIDEO_I2C) += video-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
+obj-$(CONFIG_VIDEO_IMX214) += imx214.o
obj-$(CONFIG_VIDEO_IMX258) += imx258.o
obj-$(CONFIG_VIDEO_IMX274) += imx274.o
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
new file mode 100644
index ..fe01a13f13c5
--- /dev/null
+++ b/drivers/media/i2c/imx214.c
@@ -0,0 +1,1118 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * imx214.c - imx214 sensor driver
+ *
+ * Copyright 2018 Qtechnology A/S
+ *
+ * Ricardo Ribalda
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX214_DEFAULT_CLK_FREQ2400
+#define IMX214_DEFAULT_LINK_FREQ 48000
+#define IMX214_DEFAULT_PIXEL_RATE ((IMX214_DEFAULT_LINK_FREQ * 8LL) / 10)
+#define IMX214_FPS 30
+#define IMX214_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
+
+static const char * const imx214_supply_name[] = {
+ "vdda",
+ "vddd",
+ "vdddo",
+};
+
+#define IMX214_NUM_SUPPLIES ARRAY_SIZE(imx214_supply_name)
+
+struct imx214 {
+ struct device *dev;
+ struct clk *xclk;
+ struct regmap *regmap;
+
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt fmt;
+ struct v4l2_rect crop;
+
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_ctrl *pixel_rate;
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *exposure;
+
+ struct regulator_bulk_data supplies[IMX214_NUM_SUPPLIES];
+
+ struct gpio_desc *enable_gpio;
+
+ /*
+* Serialize control access, get/set format, get selection
+* and start streaming.
+*/
+ struct mutex mutex;
+
+ bool streaming;
+};
+
+struct reg_8 {
+ u16 addr;
+ u8 val;
+};
+
+enum {
+ IMX214_TABLE_WAIT_MS = 0,
+ IMX214_TABLE_END,
+ IMX214_MAX_RETRIES,
+ IMX214_WAIT_MS
+};
+
+/*From imx214_mode_tbls.h*/
+static const struct reg_8 mode_4096x2304[] = {
+ {0x0114, 0x03},
+ {0x0220, 0x00},
+ {0x0221, 0x11},
+ {0x0222, 0x01},
+ {0x0340, 0x0C},
+ {0x0341, 0x7A},
+ {0x0342, 0x13},
+ {0x0343, 0x90},
+ {0x0344, 0x00},
+ {0x0345, 0x38},
+ {0x0346, 0x01},
+ {0x0347, 0x98},
+ {0x0348, 0x10},
+ {0x0349, 0x37},
+ {0x034A, 0x0A},
+ {0x034B, 0x97},
+ {0x0381, 0x01},
+ {0x0383, 0x01},
+ {0x0385, 0x01},
+ {0x0387, 0x01},
+ {0x0900, 0x00},
+ {0x0901, 0x00},
+ {0x0902, 0x00},
+ {0x3000, 0x35},
+ {0x3054, 0x01},
+
[PATCH v11 3/3] [media] imx214: Fix range for V4L2_CID_EXPOSURE
Going above 3184 changes the frame-rate of the sensor. Without this
patch there is no way to change the exposure without affecting the
frame-rate.
With the proper documentation we should be able the change the
frame-rate at wish, but until that happens we just cap what the sensor
can do.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/imx214.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index fe01a13f13c5..284b9b49ebde 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -1029,7 +1029,7 @@ static int imx214_probe(struct i2c_client *client)
*/
imx214->exposure = v4l2_ctrl_new_std(&imx214->ctrls, &imx214_ctrl_ops,
V4L2_CID_EXPOSURE,
-0, 0x, 1, 0x0c70);
+0, 3184, 1, 0x0c70);
ret = imx214->ctrls.error;
if (ret) {
--
2.19.0
[PATCH] media: doc-rst: Fix broken references
Documentation and code was linking the old documentation at: http://v4l2spec.bytesex.org/spec/x1904.htm Signed-off-by: Ricardo Ribalda Delgado --- Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst | 2 +- drivers/media/platform/sh_vou.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst b/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst index e40ffea7708c..9b1e1c5a23f0 100644 --- a/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst +++ b/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst @@ -114,7 +114,7 @@ window: S_CROP -- -The API at http://v4l2spec.bytesex.org/spec/x1904.htm says: +The :ref:`V4L2 crop API ` says: "...specification does not define an origin or units. However by convention drivers should horizontally count unscaled samples relative to 0H." diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c index cee58b125548..5799aa4b9323 100644 --- a/drivers/media/platform/sh_vou.c +++ b/drivers/media/platform/sh_vou.c @@ -1007,7 +1007,7 @@ static int sh_vou_s_selection(struct file *file, void *fh, /* * No down-scaling. According to the API, current call has precedence: -* http://v4l2spec.bytesex.org/spec/x1904.htm#AEN1954 paragraph two. +* https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/crop.html#cropping-structures */ vou_adjust_input(&geo, vou_dev->std); -- 2.19.1
Re: [PATCH] media: imx214: don't de-reference a NULL pointer
Hi Mauro, Hi Hans Thanks for taking a look at this. On Wed, Dec 12, 2018 at 6:55 PM Hans Verkuil wrote: > > On 12/7/18 12:43 PM, Mauro Carvalho Chehab wrote: > > As warned by smatch: > > drivers/media/i2c/imx214.c:591 imx214_set_format() warn: variable > > dereferenced before check 'format' (see line 589) > > > > It turns that the code at imx214_set_format() has support for being > > called with the format being NULL. I've no idea why, as it is only > > called internally with the pointer set, and via subdev API (with > > should also set it). > > > > Also, the entire logic there depends on having format != NULL, so > > just remove the bogus broken support for a null format. I believe it is a relic for when I did not use imx214_entity_init_cfg. Sorry about that. > > > > Signed-off-by: Mauro Carvalho Chehab > > Reviewed-by: Hans Verkuil > Reviewed-by: Ricardo Ribalda Delgado Best Regards > Regards, > > Hans > > > --- > > drivers/media/i2c/imx214.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c > > index ec3d1b855f62..b046a26219a4 100644 > > --- a/drivers/media/i2c/imx214.c > > +++ b/drivers/media/i2c/imx214.c > > @@ -588,12 +588,10 @@ static int imx214_set_format(struct v4l2_subdev *sd, > > > > __crop = __imx214_get_pad_crop(imx214, cfg, format->pad, > > format->which); > > > > - if (format) > > - mode = v4l2_find_nearest_size(imx214_modes, > > - ARRAY_SIZE(imx214_modes), width, height, > > - format->format.width, format->format.height); > > - else > > - mode = &imx214_modes[0]; > > + mode = v4l2_find_nearest_size(imx214_modes, > > + ARRAY_SIZE(imx214_modes), width, height, > > + format->format.width, > > + format->format.height); > > > > __crop->width = mode->width; > > __crop->height = mode->height; > > > -- Ricardo Ribalda
[PATCH] libv4lconvert: Fix support for compressed bayer formats
10 bit packet Bayer format broke the support for the other
compressed bayer formats.
Due to the fallthrough of the compressed formats, 10b code will be
executed for every 10b format.
Fixes: c44b30096589 ("libv4l: Add support for BAYER10P format conversion")
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index b3dbf5a0..718e1d43 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -990,12 +990,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
case V4L2_PIX_FMT_SBGGR10P:
case V4L2_PIX_FMT_SGBRG10P:
case V4L2_PIX_FMT_SGRBG10P:
- case V4L2_PIX_FMT_SRGGB10P:
- if (src_size < ((width * height * 10)/8)) {
- V4LCONVERT_ERR("short raw bayer10 data frame\n");
- errno = EPIPE;
- result = -1;
- }
+ case V4L2_PIX_FMT_SRGGB10P: {
+
+ int b10format = 1;
+
switch (src_pix_fmt) {
case V4L2_PIX_FMT_SBGGR10P:
src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
@@ -1009,10 +1007,22 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
case V4L2_PIX_FMT_SRGGB10P:
src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
break;
+ default:
+ b10format = 0;
}
- v4lconvert_bayer10p_to_bayer8(src, src, width, height);
- bytesperline = width;
+ if (b10format) {
+ if (src_size < ((width * height * 10)/8)) {
+ V4LCONVERT_ERR
+ ("short raw bayer10 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ break;
+ }
+ v4lconvert_bayer10p_to_bayer8(src, src, width, height);
+ bytesperline = width;
+ }
+ }
/* Fall-through*/
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SGBRG8:
--
2.20.1
Re: [PATCH 2/2] libv4lconvert: add support for BAYER16
Hi Daniel,
On Wed, Feb 27, 2019 at 3:47 PM Daniel Gomez wrote:
>
> Add support for 16 bit Bayer formats:
> -V4L2_PIX_FMT_SBGGR16
> -V4L2_PIX_FMT_SGBRG16
> -V4L2_PIX_FMT_SGRBG16
> -V4L2_PIX_FMT_SRGGB16
>
> Tested using vivid included in linux v5.0-rc8.
>
> Signed-off-by: Daniel Gomez
Signed-off-by: Ricardo Ribalda
> ---
> lib/libv4lconvert/bayer.c | 9 ++
> lib/libv4lconvert/libv4lconvert-priv.h | 3 ++
> lib/libv4lconvert/libv4lconvert.c | 45 ++
> 3 files changed, 57 insertions(+)
>
> diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
> index 96d26cce..7748e68d 100644
> --- a/lib/libv4lconvert/bayer.c
> +++ b/lib/libv4lconvert/bayer.c
> @@ -662,3 +662,12 @@ void v4lconvert_bayer10p_to_bayer8(unsigned char
> *bayer10p,
> bayer8 += 4;
> }
> }
> +
> +void v4lconvert_bayer16_to_bayer8(unsigned char *bayer16,
> + unsigned char *bayer8, int width, int height)
> +{
> + int i;
> +
> + for (i = 0; i < width * height; i++)
> + bayer8[i] = bayer16[2*i+1];
> +}
> diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
> b/lib/libv4lconvert/libv4lconvert-priv.h
> index 44d2d32e..a8046ce2 100644
> --- a/lib/libv4lconvert/libv4lconvert-priv.h
> +++ b/lib/libv4lconvert/libv4lconvert-priv.h
> @@ -270,6 +270,9 @@ void v4lconvert_bayer10_to_bayer8(void *bayer10,
> void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
> unsigned char *bayer8, int width, int height);
>
> +void v4lconvert_bayer16_to_bayer8(unsigned char *bayer16,
> + unsigned char *bayer8, int width, int height);
> +
> void v4lconvert_hm12_to_rgb24(const unsigned char *src,
> unsigned char *dst, int width, int height);
>
> diff --git a/lib/libv4lconvert/libv4lconvert.c
> b/lib/libv4lconvert/libv4lconvert.c
> index a8cf856a..7dc409f2 100644
> --- a/lib/libv4lconvert/libv4lconvert.c
> +++ b/lib/libv4lconvert/libv4lconvert.c
> @@ -140,6 +140,10 @@ static const struct v4lconvert_pixfmt
> supported_src_pixfmts[] = {
> { V4L2_PIX_FMT_SGBRG10, 16, 8, 8, 1 },
> { V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
> { V4L2_PIX_FMT_SRGGB10, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SBGGR16, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SGBRG16, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SGRBG16, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SRGGB16, 16, 8, 8, 1 },
> /* compressed bayer */
> { V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
> { V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
> @@ -702,6 +706,10 @@ static int v4lconvert_processing_needs_double_conversion(
> case V4L2_PIX_FMT_SGBRG10:
> case V4L2_PIX_FMT_SGRBG10:
> case V4L2_PIX_FMT_SRGGB10:
> + case V4L2_PIX_FMT_SBGGR16:
> + case V4L2_PIX_FMT_SGBRG16:
> + case V4L2_PIX_FMT_SGRBG16:
> + case V4L2_PIX_FMT_SRGGB16:
> case V4L2_PIX_FMT_STV0680:
> return 0;
> }
> @@ -1052,6 +1060,43 @@ static int v4lconvert_convert_pixfmt(struct
> v4lconvert_data *data,
> }
> }
>
> + case V4L2_PIX_FMT_SBGGR16:
> + case V4L2_PIX_FMT_SGBRG16:
> + case V4L2_PIX_FMT_SGRBG16:
> + case V4L2_PIX_FMT_SRGGB16: {
> + int b16format = 1;
> +
> + switch (src_pix_fmt) {
> + case V4L2_PIX_FMT_SBGGR16:
> + src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
> + break;
> + case V4L2_PIX_FMT_SGBRG16:
> + src_pix_fmt = V4L2_PIX_FMT_SGBRG8;
> + break;
> + case V4L2_PIX_FMT_SGRBG16:
> + src_pix_fmt = V4L2_PIX_FMT_SGRBG8;
> + break;
> + case V4L2_PIX_FMT_SRGGB16:
> + src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
> + break;
> + default:
> + b16format = 0;
> + break;
> + }
> +
> + if (b16format) {
> + if (src_size < ((width * height * 2))) {
> + V4LCONVERT_ERR
> + ("short raw bayer16 data frame\n");
> + errno = EPIPE;
> + result = -1;
> + break;
> + }
> + v4lconvert_bayer16_to_bayer8(src, src, width, height);
> + bytesperline = width;
> + }
> + }
> +
> /* Fall-through*/
> case V4L2_PIX_FMT_SBGGR8:
> case V4L2_PIX_FMT_SGBRG8:
> --
> 2.20.1
>
--
Ricardo Ribalda
Re: [PATCH 1/2] libv4lconvert: add support for BAYER10
Hi Daniel,
Thanks for both patches
On Wed, Feb 27, 2019 at 3:47 PM Daniel Gomez wrote:
>
> Add support for 10 bit Bayer formats:
> -V4L2_PIX_FMT_SBGGR10
> -V4L2_PIX_FMT_SGBRG10
> -V4L2_PIX_FMT_SRGGB10
>
> Previous BAYER10 format declared (V4L2_PIX_FMT_SGRBG10) now is grouped
> with the new list without the need of tmp buffer.
>
> Update v4lconvert_10to8 function:
> - Renaming function name to keep naming convention with the
> other bayer10p conversion function:
> v4lconvert_10to8 -> v4lconvert_bayer10_to_bayer8
>
> Tested using vivid included in linux v5.0-rc8.
>
> Signed-off-by: Daniel Gomez
Signed-off-by: Ricardo Ribalda
> ---
> lib/libv4lconvert/bayer.c | 10
> lib/libv4lconvert/libv4lconvert-priv.h | 2 +
> lib/libv4lconvert/libv4lconvert.c | 65 +++---
> 3 files changed, 59 insertions(+), 18 deletions(-)
>
> diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
> index 11af6543..96d26cce 100644
> --- a/lib/libv4lconvert/bayer.c
> +++ b/lib/libv4lconvert/bayer.c
> @@ -632,6 +632,16 @@ void v4lconvert_bayer_to_yuv420(const unsigned char
> *bayer, unsigned char *yuv,
> !start_with_green, !blue_line);
> }
>
> +void v4lconvert_bayer10_to_bayer8(void *bayer10,
> + unsigned char *bayer8, int width, int height)
> +{
> + int i;
> + uint16_t *src = bayer10;
> +
> + for (i = 0; i < width * height; i++)
> + bayer8[i] = src[i] >> 2;
> +}
> +
> void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
> unsigned char *bayer8, int width, int height)
> {
> diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
> b/lib/libv4lconvert/libv4lconvert-priv.h
> index 3020a39e..44d2d32e 100644
> --- a/lib/libv4lconvert/libv4lconvert-priv.h
> +++ b/lib/libv4lconvert/libv4lconvert-priv.h
> @@ -264,6 +264,8 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
> void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char
> *yuv,
> int width, int height, const unsigned int stride, unsigned
> int src_pixfmt, int yvu);
>
> +void v4lconvert_bayer10_to_bayer8(void *bayer10,
> + unsigned char *bayer8, int width, int height);
>
> void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
> unsigned char *bayer8, int width, int height);
> diff --git a/lib/libv4lconvert/libv4lconvert.c
> b/lib/libv4lconvert/libv4lconvert.c
> index 6a4c66a8..a8cf856a 100644
> --- a/lib/libv4lconvert/libv4lconvert.c
> +++ b/lib/libv4lconvert/libv4lconvert.c
> @@ -132,11 +132,14 @@ static const struct v4lconvert_pixfmt
> supported_src_pixfmts[] = {
> { V4L2_PIX_FMT_SGRBG8, 8, 8, 8, 0 },
> { V4L2_PIX_FMT_SRGGB8, 8, 8, 8, 0 },
> { V4L2_PIX_FMT_STV0680, 8, 8, 8, 1 },
> - { V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
> { V4L2_PIX_FMT_SBGGR10P,10, 8, 8, 1 },
> { V4L2_PIX_FMT_SGBRG10P,10, 8, 8, 1 },
> { V4L2_PIX_FMT_SGRBG10P,10, 8, 8, 1 },
> { V4L2_PIX_FMT_SRGGB10P,10, 8, 8, 1 },
> + { V4L2_PIX_FMT_SBGGR10, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SGBRG10, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
> + { V4L2_PIX_FMT_SRGGB10, 16, 8, 8, 1 },
> /* compressed bayer */
> { V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
> { V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
> @@ -695,6 +698,10 @@ static int v4lconvert_processing_needs_double_conversion(
> case V4L2_PIX_FMT_SGBRG10P:
> case V4L2_PIX_FMT_SGRBG10P:
> case V4L2_PIX_FMT_SRGGB10P:
> + case V4L2_PIX_FMT_SBGGR10:
> + case V4L2_PIX_FMT_SGBRG10:
> + case V4L2_PIX_FMT_SGRBG10:
> + case V4L2_PIX_FMT_SRGGB10:
> case V4L2_PIX_FMT_STV0680:
> return 0;
> }
> @@ -722,16 +729,6 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
> return *buf;
> }
>
> -static void v4lconvert_10to8(void *_src, unsigned char *dst, int width, int
> height)
> -{
> - int i;
> - uint16_t *src = _src;
> -
> - for (i = 0; i < width * height; i++) {
> - dst[i] = src[i] >> 2;
> - }
> -}
> -
> int v4lconvert_oom_error(struct v4lconvert_data *data)
> {
> V4LCONVERT_ERR("could not allocate memory\n");
> @@ -907,8 +904,7 @@ static int v4lconvert_convert_pixfmt(struct
> v4lconvert_data *data,
> #endif
> case V4L2_PIX_FMT_SN9C2028:
> case V4L2_PIX_FMT_SQ905C:
> - case V4L2_PIX_FMT_STV0680:
> - case V4L2_PIX_FMT_SGRBG10: { /* Not compressed but needs some
> shuffling */
> + case V4L2_PIX_FMT_STV0680: { /* N
Re: [media-workshop] [ANN] Edinburgh Media Summit 2018 meeting report
Hi On Mon, Mar 11, 2019 at 1:29 PM Laurent Pinchart wrote: > > Hello, > > On Mon, Mar 11, 2019 at 01:23:58PM +0200, Sakari Ailus wrote: > > On Wed, Dec 12, 2018 at 05:30:02AM -0200, Mauro Carvalho Chehab wrote: > > > Em Sun, 18 Nov 2018 00:45:02 +0200 Sakari Ailus escreveu: > > > > > > > Hello everyone, > > > > > > Sorry for taking so long to review this. Was very busy those days. > > > > Likewise in my reply. Please see my comments below. Let me know if you're > > fine with the proposed changes. > > Same here, this is my long overdue reply. > > > > It follows my comments. > > > > > > > Here's the report on the Media Summit held on 25th October in Edinburgh. > > > > The report is followed by the stateless codec discussion two days > > > > earlier. > > > > > > > > Note: this is bcc'd to the meeting attendees plus a few others. I didn't > > > > use cc as the list servers tend to reject messages with too many > > > > recipients in cc / to headers. > > > > > > > > Most presenters used slides some of which are already available here > > > > (expect more in the near future): > > > > > > > > https://www.linuxtv.org/downloads/presentations/media_summit_2018/> > > > > > > > > The original announcement for the meeting is here: > > > > > > > > https://www.spinics.net/lists/linux-media/msg141095.html> > > > > > > > > The raw notes can be found here: > > > > > > > > http://www.retiisi.org.uk/~sailus/v4l2/notes/osseu18-media.html> > > > > > > > > > > > > Attendees > > > > - > > > > > > > > Brad Love > > > > Ezequiel Garcia > > > > Gustavo Padovan > > > > Hans Verkuil > > > > Helen Koike > > > > Hidenori Yamaji > > > > Ivan Kalinin > > > > Jacopo Mondi > > > > Kieran Bingham > > > > Laurent Pinchart > > > > Mauro Chebab > > > > Maxime Ripard > > > > Michael Grzeschik > > > > Michael Ira Krufky > > > > Niklas Söderlund > > > > Patrick Lai > > > > Paul Elder > > > > Peter Griffin > > > > Ralph Clark > > > > Ricardo Ribalda > > > > Sakari Ailus > > > > Sean Young > > > > Seung-Woo Kim > > > > Stefan Klug > > > > Vinod Koul > > > > > > > > > > > > CEC status - Hans Verkuil > > > > - > > > > > > > > Hans prensented an update on CEC status. Besides the slides, noteworthy > > > > information is maintained here: > > > > > > > > https://hverkuil.home.xs4all.nl/cec-status.txt> > > > > > > > > Slides: > > > > https://www.linuxtv.org/downloads/presentations/media_summit_2018/media-cec-status.pdf> > > > > > > It makes sense to add a quick summary of the main points to the meeting > > > report that was there at the slide deck, in order to make the report more > > > complete. > > > > Bullet points from the slide: > > > > - cec-gpio error injection support > > > > - tda998x (including BeagleBoard Bone support after gpiolib changes) > > > > - ChromeOS EC CEC > > > > - In progress: omap5/dra7xx/am57xx TI (waiting for DSS redesign to land) > > > > - In progress: SECO cec driver (for UDOO x86 boards, expected for 4.21) > > > > - DisplayPort CEC-Tunneling-over-AUX for i915, nouveau, amdgpu > > > > - MegaChips 2900 chipset based adapters seems to support this protocol very > > well > > > > - Continuing work on CEC utilities, esp. the compliance test: it is in > > continuous use at Cisco. > > > > > > > > > > rc-core status report - Sean Young > > > > -- > > > > > > > > (Contributed by Sean Young) > > > > > > Sorry, I didn't understand what you're meaning here. The status > > > report was made by Sean. No need to repeat it. > > > > Sean wrote the summary as well, the rest is written by me. > > > > > > In the last year all staging lirc drivers have been either removed > > > > or ported to rc-core. Decoding of the more obscure IR protocols and > > > > protocol variants can now be done with BPF, with support in both the > > > > kernel and ir-keytable (which is in v4l-utils). Generally we're in a > > > > good > > > > situation wrt IR support. > > > > > > > > There is some more ancient hardware (serial or usb-serial) that does not > > > > have support but not sure if anyone cares. kernel-doc is a little sparse > > > > and does not cover BPF IR decoding, so that needs improving. There was a > > > > discussion on enabling builds with CONFIG_RC_CORE=n. Sean suggested we > > > > could have rc_allocate_driver() return NULL and have the drivers deal > > > > with this gracefully, i.e. their probe functions should continue without > > > > IR. Mauro said there should be a per-driver config option (as is done > > > > for saa7134 for example). > > > > > > Please break each topic on different paragraphs, as it makes easier to > > > read and comment. > > > > > > > No conclusion was reached on this. > > > > > > No conclusion was reached on what? > > > > That probably raises more questions than it answers. I'll drop the line. > > > > > > Persistent storage of controls - Ricardo Ribalda > > > > >
[PATCH] libv4lconvert: Add support for V4L2_PIX_FMT_NV12
NV12 is a two-plane version YUV 4:2:0, where the U and V components
are subsampled 2x2.
Signed-off-by: Ricardo Ribalda Delgado
---
The code has ben tested with qv4l2 and vivid.
v4lconvert_nv12_to_yuv420 has not been tested!!, any suggestions for
how to do it?
Thanks!
lib/libv4lconvert/libv4lconvert-priv.h | 6 +++
lib/libv4lconvert/libv4lconvert.c | 19 +
lib/libv4lconvert/rgbyuv.c | 56 ++
3 files changed, 81 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index a8046ce2..c45b086e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -285,6 +285,12 @@ void v4lconvert_hm12_to_yuv420(const unsigned char *src,
void v4lconvert_hsv_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height, int bgr, int Xin, unsigned char hsv_enc);
+void v4lconvert_nv12_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr);
+
+void v4lconvert_nv12_to_yuv420(const unsigned char *src, unsigned char *dest,
+ int width, int height, int yvu);
+
void v4lconvert_rotate90(unsigned char *src, unsigned char *dest,
struct v4l2_format *fmt);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 78fb3432..2111d19f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -116,6 +116,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SN9C20X_I420,12, 6, 3, 1 },
{ V4L2_PIX_FMT_M420,12, 6, 3, 1 },
{ V4L2_PIX_FMT_HM12,12, 6, 3, 1 },
+ { V4L2_PIX_FMT_NV12,12, 6, 3, 1 },
{ V4L2_PIX_FMT_CPIA1,0, 6, 3, 1 },
/* JPEG and variants */
{ V4L2_PIX_FMT_MJPEG,0, 7, 7, 0 },
@@ -902,6 +903,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* NV12 formats */
+ case V4L2_PIX_FMT_NV12:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_nv12_to_rgb24(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_nv12_to_rgb24(src, dest, width, height, 1);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ v4lconvert_nv12_to_yuv420(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_nv12_to_yuv420(src, dest, width, height, 1);
+ break;
+ }
+ break;
+
/* compressed bayer formats */
case V4L2_PIX_FMT_SPCA561:
case V4L2_PIX_FMT_SN9C10X:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index 02c8cb5b..bfe3b15f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -845,3 +845,59 @@ void v4lconvert_hsv_to_rgb24(const unsigned char *src,
unsigned char *dest,
src += bppIN;
}
}
+
+void v4lconvert_nv12_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr)
+{
+ int i, j;
+ const unsigned char *ysrc = src;
+ const unsigned char *uvsrc = src + width * height;
+
+ for (i = 0; i < height; i++) {
+ for (j = 0; j < width; j ++) {
+ if (bgr) {
+ *dest++ = YUV2B(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2G(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2R(*ysrc, *uvsrc, *(uvsrc + 1));
+ } else {
+ *dest++ = YUV2R(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2G(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2B(*ysrc, *uvsrc, *(uvsrc + 1));
+ }
+ ysrc++;
+ if (j&1)
+ uvsrc += 2;
+ }
+
+ /* Rewind u and v for next line */
+ if (!(i&1))
+ uvsrc -= width;
+ }
+}
+
+void v4lconvert_nv12_to_yuv420(const unsigned char *src, unsigned char *dest,
+ int width, int height, int yvu)
+{
+ int i, j;
+ const unsigned char *ysrc = src;
+ const unsigned char *uvsrc = src + width * height;
+ unsigned char *ydst = dest;
+ unsigned char *udst, *vdst;
+
+ if (yvu) {
+ vdst = ydst + width * height;
+ udst = vdst + ((width / 2) * (height / 2));
Re: [PATCH] libv4lconvert: Add support for V4L2_PIX_FMT_NV12
Hi Hans
On Tue, Apr 16, 2019 at 6:00 PM Hans de Goede wrote:
>
> Hi Ricardo,
>
> On 16-04-19 14:02, Ricardo Ribalda Delgado wrote:
> > NV12 is a two-plane version YUV 4:2:0, where the U and V components
> > are subsampled 2x2.
> >
> > Signed-off-by: Ricardo Ribalda Delgado
>
> Your patch looks good to me, but it pushed the array-size of
> the supported_src_pixfmts array over 64 entries (right now it is
> exactly 64 entries big).
>
> Which breaks supported_src_formats as that is only 64 bits big:
Good catch. Thanks for detailed description. Will redo and send back
>
> struct v4lconvert_data {
> int fd;
> ...
> int64_t supported_src_formats; /* bitfield */
>
>
> See e.g. :
>
> for (j = 0; j < ARRAY_SIZE(supported_src_pixfmts); j++)
> if (fmt.pixelformat == supported_src_pixfmts[j].fmt)
> break;
>
> if (j < ARRAY_SIZE(supported_src_pixfmts)) {
> data->supported_src_formats |= 1ULL << j;
>
> I believe this is best fixed by a preparation patch which introduces the
> bit-ops from the kernel for this:
>
> include/asm-generic/bitops/non-atomic.h:
>
> static inline void __set_bit(int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
>
> *p |= mask;
> }
>
> static inline void __clear_bit(int nr, volatile unsigned long *addr)
> {
> unsigned long mask = BIT_MASK(nr);
> unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
>
> *p &= ~mask;
> }
>
> static inline int test_bit(int nr, const volatile unsigned long *addr)
> {
> return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
> }
>
> So you will have to change your patch into a 2 patch patch-set with
> the first patch introducing set_bit / clear_bit / test_bit helpers
> modelled after the kernel and changing the declaration of
> supported_src_formats to:
>
> unsigned long supported_src_formats[128 / BITS_PER_LONG];
>
> Thanks & Regards,
>
> Hans
>
>
>
>
>
>
>
>
>
> > ---
> > The code has ben tested with qv4l2 and vivid.
> > v4lconvert_nv12_to_yuv420 has not been tested!!, any suggestions for
> > how to do it?
> >
> > Thanks!
> > lib/libv4lconvert/libv4lconvert-priv.h | 6 +++
> > lib/libv4lconvert/libv4lconvert.c | 19 +
> > lib/libv4lconvert/rgbyuv.c | 56 ++
> > 3 files changed, 81 insertions(+)
> >
> > diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
> > b/lib/libv4lconvert/libv4lconvert-priv.h
> > index a8046ce2..c45b086e 100644
> > --- a/lib/libv4lconvert/libv4lconvert-priv.h
> > +++ b/lib/libv4lconvert/libv4lconvert-priv.h
> > @@ -285,6 +285,12 @@ void v4lconvert_hm12_to_yuv420(const unsigned char
> > *src,
> > void v4lconvert_hsv_to_rgb24(const unsigned char *src, unsigned char
> > *dest,
> > int width, int height, int bgr, int Xin, unsigned char
> > hsv_enc);
> >
> > +void v4lconvert_nv12_to_rgb24(const unsigned char *src, unsigned char
> > *dest,
> > + int width, int height, int bgr);
> > +
> > +void v4lconvert_nv12_to_yuv420(const unsigned char *src, unsigned char
> > *dest,
> > + int width, int height, int yvu);
> > +
> > void v4lconvert_rotate90(unsigned char *src, unsigned char *dest,
> > struct v4l2_format *fmt);
> >
> > diff --git a/lib/libv4lconvert/libv4lconvert.c
> > b/lib/libv4lconvert/libv4lconvert.c
> > index 78fb3432..2111d19f 100644
> > --- a/lib/libv4lconvert/libv4lconvert.c
> > +++ b/lib/libv4lconvert/libv4lconvert.c
> > @@ -116,6 +116,7 @@ static const struct v4lconvert_pixfmt
> > supported_src_pixfmts[] = {
> > { V4L2_PIX_FMT_SN9C20X_I420,12, 6, 3, 1 },
> > { V4L2_PIX_FMT_M420,12, 6, 3, 1 },
> > { V4L2_PIX_FMT_HM12,12, 6, 3, 1 },
> > + { V4L2_PIX_FMT_NV12,12, 6, 3, 1 },
> > { V4L2_PIX_FMT_CPIA1,0, 6, 3, 1 },
> > /* JPEG and variants */
> > { V4L2_PIX_FMT_MJPEG,0, 7, 7, 0 },
> > @@ -902,6 +903,24 @@ static int v4lconvert_convert_pixfmt(struct
> > v4lconvert_data *data,
> > }
> > break;
> >
> > +
[PATCH v2 2/2] libv4lconvert: Add support for V4L2_PIX_FMT_NV12
NV12 is a two-plane version YUV 4:2:0, where the U and V components
are subsampled 2x2.
Signed-off-by: Ricardo Ribalda Delgado
---
Changelog v2:
- None
The code has ben tested with qv4l2 and vivid.
v4lconvert_nv12_to_yuv420 has not been tested!!, any suggestions for
how to do it?
lib/libv4lconvert/libv4lconvert-priv.h | 6 +++
lib/libv4lconvert/libv4lconvert.c | 19 +
lib/libv4lconvert/rgbyuv.c | 56 ++
3 files changed, 81 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 5286a9b1..ce5970c9 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -286,6 +286,12 @@ void v4lconvert_hm12_to_yuv420(const unsigned char *src,
void v4lconvert_hsv_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height, int bgr, int Xin, unsigned char hsv_enc);
+void v4lconvert_nv12_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr);
+
+void v4lconvert_nv12_to_yuv420(const unsigned char *src, unsigned char *dest,
+ int width, int height, int yvu);
+
void v4lconvert_rotate90(unsigned char *src, unsigned char *dest,
struct v4l2_format *fmt);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 0607cc8b..665ee9ea 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -139,6 +139,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SN9C20X_I420,12, 6, 3, 1 },
{ V4L2_PIX_FMT_M420,12, 6, 3, 1 },
{ V4L2_PIX_FMT_HM12,12, 6, 3, 1 },
+ { V4L2_PIX_FMT_NV12,12, 6, 3, 1 },
{ V4L2_PIX_FMT_CPIA1,0, 6, 3, 1 },
/* JPEG and variants */
{ V4L2_PIX_FMT_MJPEG,0, 7, 7, 0 },
@@ -932,6 +933,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* NV12 formats */
+ case V4L2_PIX_FMT_NV12:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_nv12_to_rgb24(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_nv12_to_rgb24(src, dest, width, height, 1);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ v4lconvert_nv12_to_yuv420(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_nv12_to_yuv420(src, dest, width, height, 1);
+ break;
+ }
+ break;
+
/* compressed bayer formats */
case V4L2_PIX_FMT_SPCA561:
case V4L2_PIX_FMT_SN9C10X:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index 02c8cb5b..79bc0bdb 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -845,3 +845,59 @@ void v4lconvert_hsv_to_rgb24(const unsigned char *src,
unsigned char *dest,
src += bppIN;
}
}
+
+void v4lconvert_nv12_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr)
+{
+ int i, j;
+ const unsigned char *ysrc = src;
+ const unsigned char *uvsrc = src + width * height;
+
+ for (i = 0; i < height; i++) {
+ for (j = 0; j < width; j ++) {
+ if (bgr) {
+ *dest++ = YUV2B(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2G(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2R(*ysrc, *uvsrc, *(uvsrc + 1));
+ } else {
+ *dest++ = YUV2R(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2G(*ysrc, *uvsrc, *(uvsrc + 1));
+ *dest++ = YUV2B(*ysrc, *uvsrc, *(uvsrc + 1));
+ }
+ ysrc++;
+ if (j&1)
+ uvsrc += 2;
+ }
+
+ /* Rewind u and v for next line */
+ if (!(i&1))
+ uvsrc -= width;
+ }
+}
+
+void v4lconvert_nv12_to_yuv420(const unsigned char *src, unsigned char *dest,
+ int width, int height, int yvu)
+{
+ int i, j;
+ const unsigned char *ysrc = src;
+ const unsigned char *uvsrc = src + width * height;
+ unsigned char *ydst = dest;
+ unsigned char *udst, *vdst;
+
+ if (yvu) {
+ vdst = ydst + width * height;
+ udst = vdst + ((width / 2)
[PATCH v2 1/2] libv4lconvert: Port supported_src_formats to bit-ops
We have passed the barrier of 64 supported formats, therefore a int64_t
is not enough for holding the bitfield.
Instead use bit-ops ala kernel.
Signed-off-by: Ricardo Ribalda Delgado
Suggested-by: Hans de Goede
---
lib/libv4lconvert/libv4lconvert-priv.h | 3 +-
lib/libv4lconvert/libv4lconvert.c | 40 ++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index a8046ce2..5286a9b1 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -38,6 +38,7 @@
#include "tinyjpeg.h"
#define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0]))
+#define BITS_PER_LONG (8 * sizeof(long))
#define V4LCONVERT_ERROR_MSG_SIZE 256
#define V4LCONVERT_MAX_FRAMESIZES 256
@@ -55,7 +56,7 @@ struct v4lconvert_data {
int flags; /* bitfield */
int control_flags; /* bitfield */
unsigned int no_formats;
- int64_t supported_src_formats; /* bitfield */
+ unsigned long supported_src_formats[128 / BITS_PER_LONG];
char error_msg[V4LCONVERT_ERROR_MSG_SIZE];
struct jdec_private *tinyjpeg;
#ifdef HAVE_JPEG
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 78fb3432..0607cc8b 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -32,6 +32,29 @@
#include "libv4lsyscall-priv.h"
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
+#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
+
+static inline void __set_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p |= mask;
+}
+
+static inline void __clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p &= ~mask;
+}
+
+static inline int __test_bit(int nr, const volatile unsigned long *addr)
+{
+ return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
static void *dev_init(int fd)
{
@@ -231,7 +254,7 @@ struct v4lconvert_data *v4lconvert_create_with_dev_ops(int
fd, void *dev_ops_pri
break;
if (j < ARRAY_SIZE(supported_src_pixfmts)) {
- data->supported_src_formats |= 1ULL << j;
+ __set_bit(j, data->supported_src_formats);
v4lconvert_get_framesizes(data, fmt.pixelformat, j);
if (!supported_src_pixfmts[j].needs_conversion)
always_needs_conversion = 0;
@@ -316,8 +339,15 @@ int v4lconvert_supported_dst_format(unsigned int
pixelformat)
int v4lconvert_supported_dst_fmt_only(struct v4lconvert_data *data)
{
- return v4lcontrol_needs_conversion(data->control) &&
- data->supported_src_formats;
+ int i;
+
+ for (i = 0 ; i < ARRAY_SIZE(data->supported_src_formats); i++)
+ if (data->supported_src_formats[i])
+ break;
+ if (i == ARRAY_SIZE(data->supported_src_formats))
+ return 0;
+
+ return v4lcontrol_needs_conversion(data->control);
}
/* See libv4lconvert.h for description of in / out parameters */
@@ -334,7 +364,7 @@ int v4lconvert_enum_fmt(struct v4lconvert_data *data,
struct v4l2_fmtdesc *fmt)
for (i = 0; i < ARRAY_SIZE(supported_dst_pixfmts); i++)
if (v4lconvert_supported_dst_fmt_only(data) ||
- !(data->supported_src_formats & (1ULL << i))) {
+ !__test_bit(i, data->supported_src_formats)) {
faked_fmts[no_faked_fmts] =
supported_dst_pixfmts[i].fmt;
no_faked_fmts++;
}
@@ -490,7 +520,7 @@ static int v4lconvert_do_try_format(struct v4lconvert_data
*data,
for (i = 0; i < ARRAY_SIZE(supported_src_pixfmts); i++) {
/* is this format supported? */
- if (!(data->supported_src_formats & (1ULL << i)))
+ if (!__test_bit(i, data->supported_src_formats))
continue;
try_fmt = *dest_fmt;
--
2.20.1
[PATCH v3 7/7] imx214: Use v4l2_ctrl_new_area helper
Instead of creating manually the V4L2_CID_UNIT_CELL_SIZE control, lets
use the helper.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/imx214.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index cc0a013ba7da..625617d4c81a 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -942,26 +942,6 @@ static int __maybe_unused imx214_resume(struct device *dev)
return ret;
}
-static void unit_size_init(const struct v4l2_ctrl *ctrl, u32 idx,
-union v4l2_ctrl_ptr ptr)
-{
- ptr.p_area->width = 1120;
- ptr.p_area->height = 1120;
-}
-
-static const struct v4l2_ctrl_type_ops unit_size_ops = {
- .init = unit_size_init,
-};
-
-static struct v4l2_ctrl *new_unit_size_ctrl(struct v4l2_ctrl_handler *handler)
-{
- static struct v4l2_ctrl_config ctrl = {
- .id = V4L2_CID_UNIT_CELL_SIZE,
- .type_ops = &unit_size_ops,
- };
-
- return v4l2_ctrl_new_custom(handler, &ctrl, NULL);
-}
static int imx214_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -969,6 +949,10 @@ static int imx214_probe(struct i2c_client *client)
static const s64 link_freq[] = {
IMX214_DEFAULT_LINK_FREQ,
};
+ struct v4l2_area unit_size = {
+ .width = 1120,
+ .height = 1120,
+ };
int ret;
ret = imx214_parse_fwnode(dev);
@@ -1050,7 +1034,10 @@ static int imx214_probe(struct i2c_client *client)
V4L2_CID_EXPOSURE,
0, 3184, 1, 0x0c70);
- imx214->unit_size = new_unit_size_ctrl(&imx214->ctrls);
+ imx214->unit_size = v4l2_ctrl_new_area(&imx214->ctrls,
+ &imx214_ctrl_ops,
+ V4L2_CID_UNIT_CELL_SIZE,
+ &unit_size);
ret = imx214->ctrls.error;
if (ret) {
--
2.23.0.rc1
[PATCH v3 2/7] Documentation: media: Describe V4L2_CID_UNIT_CELL_SIZE
New control to pass to userspace the width/height of a pixel. Which is needed for calibration and lens selection. Signed-off-by: Ricardo Ribalda Delgado --- Documentation/media/uapi/v4l/ext-ctrls-image-source.rst | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/media/uapi/v4l/ext-ctrls-image-source.rst b/Documentation/media/uapi/v4l/ext-ctrls-image-source.rst index 2c3ab5796d76..6e728accf67b 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-image-source.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-image-source.rst @@ -55,3 +55,11 @@ Image Source Control IDs ``V4L2_CID_TEST_PATTERN_GREENB (integer)`` Test pattern green (next to blue) colour component. + +``V4L2_CID_UNIT_CELL_SIZE (struct)`` +This control returns the unit cell size in nanometres. The struct provides +the width and the height in separated fields to take into consideration +asymmetric pixels and/or hardware binning. +The unit cell consists of the whole area of the pixel, sensitive and +non-sensitive. +This control is required for automatic calibration sensors/cameras. -- 2.23.0.rc1
[PATCH v3 4/7] media: imx214: Add new control with V4L2_CID_UNIT_CELL_SIZE
According to the product brief, the unit cell size is 1120 nanometers^2.
https://www.sony-semicon.co.jp/products_en/IS/sensor1/img/products/ProductBrief_IMX214_20150428.pdf
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/imx214.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index 159a3a604f0e..cc0a013ba7da 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -47,6 +47,7 @@ struct imx214 {
struct v4l2_ctrl *pixel_rate;
struct v4l2_ctrl *link_freq;
struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *unit_size;
struct regulator_bulk_data supplies[IMX214_NUM_SUPPLIES];
@@ -941,6 +942,26 @@ static int __maybe_unused imx214_resume(struct device *dev)
return ret;
}
+static void unit_size_init(const struct v4l2_ctrl *ctrl, u32 idx,
+union v4l2_ctrl_ptr ptr)
+{
+ ptr.p_area->width = 1120;
+ ptr.p_area->height = 1120;
+}
+
+static const struct v4l2_ctrl_type_ops unit_size_ops = {
+ .init = unit_size_init,
+};
+
+static struct v4l2_ctrl *new_unit_size_ctrl(struct v4l2_ctrl_handler *handler)
+{
+ static struct v4l2_ctrl_config ctrl = {
+ .id = V4L2_CID_UNIT_CELL_SIZE,
+ .type_ops = &unit_size_ops,
+ };
+
+ return v4l2_ctrl_new_custom(handler, &ctrl, NULL);
+}
static int imx214_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -1029,6 +1050,8 @@ static int imx214_probe(struct i2c_client *client)
V4L2_CID_EXPOSURE,
0, 3184, 1, 0x0c70);
+ imx214->unit_size = new_unit_size_ctrl(&imx214->ctrls);
+
ret = imx214->ctrls.error;
if (ret) {
dev_err(&client->dev, "%s control init failed (%d)\n",
--
2.23.0.rc1
[PATCH v3 5/7] media: v4l2-core: Add new helper for area controls
Adding a V4L2_CID_UNIT_CELL_SIZE control requires a lot of boilerplate,
try to minimize it by adding a new helper.
Suggested-by: Philipp Zabel
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/v4l2-ctrls.c | 25 -
include/media/v4l2-ctrls.h | 16
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b3bf458df7f7..33e48f0aec1a 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2660,7 +2660,6 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(struct
v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_new_std_menu_items);
-/* Helper function for standard integer menu controls */
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, u8 _max, u8 _def, const s64 *qmenu_int)
@@ -2684,6 +2683,30 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct
v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_new_int_menu);
+static void area_init(const struct v4l2_ctrl *ctrl, u32 idx,
+ union v4l2_ctrl_ptr ptr)
+{
+ memcpy(ptr.p_area, ctrl->priv, sizeof(*ptr.p_area));
+}
+
+static const struct v4l2_ctrl_type_ops area_ops = {
+ .init = area_init,
+};
+
+struct v4l2_ctrl *v4l2_ctrl_new_area(struct v4l2_ctrl_handler *hdl,
+const struct v4l2_ctrl_ops *ops,
+u32 id, const struct v4l2_area *area)
+{
+ static struct v4l2_ctrl_config ctrl = {
+ .id = V4L2_CID_UNIT_CELL_SIZE,
+ .type_ops = &area_ops,
+ };
+
+ return v4l2_ctrl_new_custom(hdl, &ctrl, (void *)area);
+}
+EXPORT_SYMBOL(v4l2_ctrl_new_area);
+
+/* Helper function for standard integer menu controls */
/* Add the controls from another handler to our own. */
int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_handler *add,
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 9a3d11350e67..36f0712ea6dd 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -669,6 +669,22 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct
v4l2_ctrl_handler *hdl,
u32 id, u8 max, u8 def,
const s64 *qmenu_int);
+/**
+ * v4l2_ctrl_new_area() - Allocate and initialize a V4L2_CTRL_TYPE_AREA
control.
+ *
+ * @hdl: The control handler.
+ * @ops: The control ops.
+ * @id:The control ID.
+ * @area: The width and height of the area in a struct v4l2_area.
+ *
+ * If the &v4l2_ctrl struct could not be allocated then NULL is returned
+ * and @hdl->error is set to the error code (if it wasn't set already).
+ */
+
+struct v4l2_ctrl *v4l2_ctrl_new_area(struct v4l2_ctrl_handler *hdl,
+const struct v4l2_ctrl_ops *ops,
+u32 id, const struct v4l2_area *area);
+
/**
* typedef v4l2_ctrl_filter - Typedef to define the filter function to be
* used when adding a control handler.
--
2.23.0.rc1
[PATCH v3 6/7] Documentation: Document v4l2_ctrl_new area
Helper for creating area controls. Signed-off-by: Ricardo Ribalda Delgado --- Documentation/media/kapi/v4l2-controls.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/media/kapi/v4l2-controls.rst b/Documentation/media/kapi/v4l2-controls.rst index ebe2a55908be..656e9428f6a6 100644 --- a/Documentation/media/kapi/v4l2-controls.rst +++ b/Documentation/media/kapi/v4l2-controls.rst @@ -149,6 +149,15 @@ Integer menu controls with a driver specific menu can be added by calling const struct v4l2_ctrl_ops *ops, u32 id, s32 max, s32 def, const s64 *qmenu_int); +Area controls can be added by calling +:c:func:`v4l2_ctrl_new_area`: + +.. code-block:: c + + struct v4l2_ctrl *v4l2_ctrl_new_area(struct v4l2_ctrl_handler *hdl, + const struct v4l2_ctrl_ops *ops, + u32 id, const struct v4l2_area *area); + These functions are typically called right after the :c:func:`v4l2_ctrl_handler_init`: -- 2.23.0.rc1
[PATCH v3 3/7] Documentation: media: Document V4L2_CTRL_TYPE_AREA
A struct v4l2_area containing the width and the height of a rectangular area. Signed-off-by: Ricardo Ribalda Delgado Suggested-by: Hans Verkuil --- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst index a3d56ffbf4cc..c09d06ef2b08 100644 --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst @@ -443,6 +443,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_mpeg2_quantization`, containing MPEG-2 quantization matrices for stateless video decoders. +* - ``V4L2_CTRL_TYPE_AREA`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_area`, containing the width and the height +of a rectangular area. * - ``V4L2_CTRL_TYPE_H264_SPS`` - n/a - n/a -- 2.23.0.rc1
[PATCH v3 1/7] media: add V4L2_CID_UNIT_CELL_SIZE control
This control returns the unit cell size in nanometres. The struct provides
the width and the height in separated fields to take into consideration
asymmetric pixels and/or hardware binning.
This control is required for automatic calibration of sensors/cameras.
Signed-off-by: Ricardo Ribalda Delgado
---
v3:
-Put together all actions on ctrl_fill
-Move the control to IMAGE_SOURCE
drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++
include/media/v4l2-ctrls.h | 2 ++
include/uapi/linux/v4l2-controls.h | 1 +
include/uapi/linux/videodev2.h | 11 +++
4 files changed, 25 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 1d8f38824631..b3bf458df7f7 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -994,6 +994,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_FOCUS_RANGE: return "Auto Focus, Range";
case V4L2_CID_PAN_SPEED:return "Pan, Speed";
case V4L2_CID_TILT_SPEED: return "Tilt, Speed";
+ case V4L2_CID_UNIT_CELL_SIZE: return "Unit Cell Size";
/* FM Radio Modulator controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1375,6 +1376,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER:
*type = V4L2_CTRL_TYPE_VP8_FRAME_HEADER;
break;
+ case V4L2_CID_UNIT_CELL_SIZE:
+ *type = V4L2_CTRL_TYPE_AREA;
+ *flags |= V4L2_CTRL_FLAG_READ_ONLY;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -1723,6 +1728,9 @@ static int std_validate_compound(const struct v4l2_ctrl
*ctrl, u32 idx,
case V4L2_CTRL_TYPE_FWHT_PARAMS:
break;
+ case V4L2_CTRL_TYPE_AREA:
+ break;
+
case V4L2_CTRL_TYPE_H264_SPS:
case V4L2_CTRL_TYPE_H264_PPS:
case V4L2_CTRL_TYPE_H264_SCALING_MATRIX:
@@ -2421,6 +2429,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_VP8_FRAME_HEADER:
elem_size = sizeof(struct v4l2_ctrl_vp8_frame_header);
break;
+ case V4L2_CTRL_TYPE_AREA:
+ elem_size = sizeof(struct v4l2_area);
+ break;
default:
if (type < V4L2_CTRL_COMPOUND_TYPES)
elem_size = sizeof(s32);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 570ff4b0205a..9a3d11350e67 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -50,6 +50,7 @@ struct poll_table_struct;
* @p_h264_slice_params: Pointer to a struct v4l2_ctrl_h264_slice_params.
* @p_h264_decode_params: Pointer to a struct
v4l2_ctrl_h264_decode_params.
* @p_vp8_frame_header:Pointer to a VP8 frame header structure.
+ * @p_area:Pointer to an area.
* @p: Pointer to a compound value.
*/
union v4l2_ctrl_ptr {
@@ -68,6 +69,7 @@ union v4l2_ctrl_ptr {
struct v4l2_ctrl_h264_slice_params *p_h264_slice_params;
struct v4l2_ctrl_h264_decode_params *p_h264_decode_params;
struct v4l2_ctrl_vp8_frame_header *p_vp8_frame_header;
+ struct v4l2_area *p_area;
void *p;
};
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index a2669b79b294..5a7bedee2b0e 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1034,6 +1034,7 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_TEST_PATTERN_GREENR
(V4L2_CID_IMAGE_SOURCE_CLASS_BASE + 5)
#define V4L2_CID_TEST_PATTERN_BLUE
(V4L2_CID_IMAGE_SOURCE_CLASS_BASE + 6)
#define V4L2_CID_TEST_PATTERN_GREENB
(V4L2_CID_IMAGE_SOURCE_CLASS_BASE + 7)
+#define V4L2_CID_UNIT_CELL_SIZE
(V4L2_CID_IMAGE_SOURCE_CLASS_BASE + 8)
/* Image processing controls */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 530638dffd93..05cfc69d7ed6 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -422,6 +422,11 @@ struct v4l2_fract {
__u32 denominator;
};
+struct v4l2_area {
+ __u32 width;
+ __u32 height;
+};
+
/**
* struct v4l2_capability - Describes V4L2 device caps returned by
VIDIOC_QUERYCAP
*
@@ -1720,6 +1725,12 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_U8= 0x0100,
V4L2_CTRL_TYPE_U16 = 0x0101,
V4L2_CTRL_TYPE_U32 = 0x0102,
+ /*
+* V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS = 0x0103,
+* V4L2_CTRL_TYPE_MPEG2_QUANTIZATION = 0x0104,
+* V4L2_CTRL_TYPE_FWHT_PARAMS = 0x0105
Re: [PATCH v3 5/7] media: v4l2-core: Add new helper for area controls
On Fri, Aug 23, 2019 at 2:56 PM Philipp Zabel wrote:
>
> On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> > Adding a V4L2_CID_UNIT_CELL_SIZE control requires a lot of boilerplate,
> > try to minimize it by adding a new helper.
> >
> > Suggested-by: Philipp Zabel
> > Signed-off-by: Ricardo Ribalda Delgado
> > ---
> > drivers/media/v4l2-core/v4l2-ctrls.c | 25 -
> > include/media/v4l2-ctrls.h | 16
> > 2 files changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index b3bf458df7f7..33e48f0aec1a 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -2660,7 +2660,6 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(struct
> > v4l2_ctrl_handler *hdl,
> > }
> > EXPORT_SYMBOL(v4l2_ctrl_new_std_menu_items);
> >
> > -/* Helper function for standard integer menu controls */
>
> Why move this ...
>
> > struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
> > const struct v4l2_ctrl_ops *ops,
> > u32 id, u8 _max, u8 _def, const s64 *qmenu_int)
> > @@ -2684,6 +2683,30 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct
> > v4l2_ctrl_handler *hdl,
> > }
> > EXPORT_SYMBOL(v4l2_ctrl_new_int_menu);
> >
> > +static void area_init(const struct v4l2_ctrl *ctrl, u32 idx,
> > + union v4l2_ctrl_ptr ptr)
> > +{
> > + memcpy(ptr.p_area, ctrl->priv, sizeof(*ptr.p_area));
> > +}
> > +
> > +static const struct v4l2_ctrl_type_ops area_ops = {
> > + .init = area_init,
> > +};
> > +
> > +struct v4l2_ctrl *v4l2_ctrl_new_area(struct v4l2_ctrl_handler *hdl,
> > + const struct v4l2_ctrl_ops *ops,
> > + u32 id, const struct v4l2_area *area)
> > +{
> > + static struct v4l2_ctrl_config ctrl = {
> > + .id = V4L2_CID_UNIT_CELL_SIZE,
> > + .type_ops = &area_ops,
> > + };
> > +
> > + return v4l2_ctrl_new_custom(hdl, &ctrl, (void *)area);
> > +}
> > +EXPORT_SYMBOL(v4l2_ctrl_new_area);
> > +
> > +/* Helper function for standard integer menu controls */
>
> ... here?
Because I screwed up :). Let me fix that sorry.
I will push all your changes to:
https://github.com/ribalda/linux/tree/unit-size-v4
plus any other comment and then I will wait 2-3 days for resend
>
> Looks to me like this comment should stay attached to
> v4l2_ctrl_new_int_menu.
>
> regards
> Philipp
[PATCH] RFC: v4l2-ctrls: Inmplement v4l2_ctrl_new_std_compound()
Implement v4l2_ctrl_new_std_compound. This is just a discussion patch,
do not merge as is, and be gentle with the author ;P.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/i2c/imx214.c | 13 +++--
drivers/media/v4l2-core/v4l2-ctrls.c | 79 +---
include/media/v4l2-ctrls.h | 25 +
3 files changed, 81 insertions(+), 36 deletions(-)
diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index 625617d4c81a..e18fed9f31f1 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -953,6 +953,9 @@ static int imx214_probe(struct i2c_client *client)
.width = 1120,
.height = 1120,
};
+ union v4l2_ctrl_ptr p_def = {
+ .p_area = &unit_size,
+ };
int ret;
ret = imx214_parse_fwnode(dev);
@@ -1034,11 +1037,11 @@ static int imx214_probe(struct i2c_client *client)
V4L2_CID_EXPOSURE,
0, 3184, 1, 0x0c70);
- imx214->unit_size = v4l2_ctrl_new_area(&imx214->ctrls,
- &imx214_ctrl_ops,
- V4L2_CID_UNIT_CELL_SIZE,
- &unit_size);
-
+ imx214->unit_size = v4l2_ctrl_new_std_compound(&imx214->ctrls,
+ NULL,
+ V4L2_CID_UNIT_CELL_SIZE,
+ 0, 0x7ff, 1, 0,
+ p_def);
ret = imx214->ctrls.error;
if (ret) {
dev_err(&client->dev, "%s control init failed (%d)\n",
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3d2fa1868982..04813ba2262b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1555,6 +1555,10 @@ static void std_init_compound(const struct v4l2_ctrl
*ctrl, u32 idx,
p_mpeg2_slice_params->picture.picture_coding_type =
V4L2_MPEG2_PICTURE_CODING_TYPE_I;
break;
+ default:
+ if (ctrl->has_p_def)
+ memcpy(p, ctrl->p_def.p, ctrl->elem_size);
+ break;
}
}
@@ -2369,7 +2373,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
s64 min, s64 max, u64 step, s64 def,
const u32 dims[V4L2_CTRL_MAX_DIMS], u32 elem_size,
u32 flags, const char * const *qmenu,
- const s64 *qmenu_int, void *priv)
+ const s64 *qmenu_int, const union v4l2_ctrl_ptr p_def,
+ void *priv)
{
struct v4l2_ctrl *ctrl;
unsigned sz_extra;
@@ -2478,6 +2483,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
is_array)
sz_extra += 2 * tot_ctrl_size;
+ if (type >= V4L2_CTRL_COMPOUND_TYPES && p_def.p)
+ sz_extra += elem_size;
+
ctrl = kvzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);
if (ctrl == NULL) {
handler_set_err(hdl, -ENOMEM);
@@ -2521,6 +2529,13 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
ctrl->p_new.p = &ctrl->val;
ctrl->p_cur.p = &ctrl->cur.val;
}
+
+ if (type >= V4L2_CTRL_COMPOUND_TYPES && p_def.p) {
+ ctrl->p_def.p = ctrl->p_cur.p + tot_ctrl_size;
+ memcpy(ctrl->p_def.p, p_def.p, elem_size);
+ ctrl->has_p_def = true;
+ }
+
for (idx = 0; idx < elems; idx++) {
ctrl->type_ops->init(ctrl, idx, ctrl->p_cur);
ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
@@ -2550,6 +2565,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
s64 max = cfg->max;
u64 step = cfg->step;
s64 def = cfg->def;
+ const union v4l2_ctrl_ptr p_def = {};
if (name == NULL)
v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max, &step,
@@ -2572,7 +2588,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
type, min, max,
is_menu ? cfg->menu_skip_mask : step, def,
cfg->dims, cfg->elem_size,
- flags, qmenu, qmenu_int, priv);
+ flags, qmenu, qmenu_int, p_def, priv);
if (ctrl)
ctrl->is_private = cfg->is_private;
return ctrl;
@@ -2587,6 +2603,7 @@ struct v4l2_ctrl *v4l2_ctrl_new
Re: [PATCH] RFC: v4l2-ctrls: Inmplement v4l2_ctrl_new_std_compound()
Hi Hans
Is this something close to what you were having in mind? Right now it
sits on
https://github.com/ribalda/linux/commit/de21dbc2f57b58b22f5d73bc314dd8e59dff5c7d
but I will make it as the beginning of my patchset if you think that I
am on the right track.
Thanks!
On Tue, Sep 17, 2019 at 6:19 PM Ricardo Ribalda Delgado
wrote:
>
> Implement v4l2_ctrl_new_std_compound. This is just a discussion patch,
> do not merge as is, and be gentle with the author ;P.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/media/i2c/imx214.c | 13 +++--
> drivers/media/v4l2-core/v4l2-ctrls.c | 79 +---
> include/media/v4l2-ctrls.h | 25 +
> 3 files changed, 81 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
> index 625617d4c81a..e18fed9f31f1 100644
> --- a/drivers/media/i2c/imx214.c
> +++ b/drivers/media/i2c/imx214.c
> @@ -953,6 +953,9 @@ static int imx214_probe(struct i2c_client *client)
> .width = 1120,
> .height = 1120,
> };
> + union v4l2_ctrl_ptr p_def = {
> + .p_area = &unit_size,
> + };
> int ret;
>
> ret = imx214_parse_fwnode(dev);
> @@ -1034,11 +1037,11 @@ static int imx214_probe(struct i2c_client *client)
> V4L2_CID_EXPOSURE,
> 0, 3184, 1, 0x0c70);
>
> - imx214->unit_size = v4l2_ctrl_new_area(&imx214->ctrls,
> - &imx214_ctrl_ops,
> - V4L2_CID_UNIT_CELL_SIZE,
> - &unit_size);
> -
> + imx214->unit_size = v4l2_ctrl_new_std_compound(&imx214->ctrls,
> + NULL,
> +
> V4L2_CID_UNIT_CELL_SIZE,
> + 0, 0x7ff, 1, 0,
> + p_def);
> ret = imx214->ctrls.error;
> if (ret) {
> dev_err(&client->dev, "%s control init failed (%d)\n",
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 3d2fa1868982..04813ba2262b 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1555,6 +1555,10 @@ static void std_init_compound(const struct v4l2_ctrl
> *ctrl, u32 idx,
> p_mpeg2_slice_params->picture.picture_coding_type =
> V4L2_MPEG2_PICTURE_CODING_TYPE_I;
> break;
> + default:
> + if (ctrl->has_p_def)
> + memcpy(p, ctrl->p_def.p, ctrl->elem_size);
> + break;
> }
> }
>
> @@ -2369,7 +2373,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> s64 min, s64 max, u64 step, s64 def,
> const u32 dims[V4L2_CTRL_MAX_DIMS], u32 elem_size,
> u32 flags, const char * const *qmenu,
> - const s64 *qmenu_int, void *priv)
> + const s64 *qmenu_int, const union v4l2_ctrl_ptr p_def,
> + void *priv)
> {
> struct v4l2_ctrl *ctrl;
> unsigned sz_extra;
> @@ -2478,6 +2483,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> is_array)
> sz_extra += 2 * tot_ctrl_size;
>
> + if (type >= V4L2_CTRL_COMPOUND_TYPES && p_def.p)
> + sz_extra += elem_size;
> +
> ctrl = kvzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);
> if (ctrl == NULL) {
> handler_set_err(hdl, -ENOMEM);
> @@ -2521,6 +2529,13 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> ctrl->p_new.p = &ctrl->val;
> ctrl->p_cur.p = &ctrl->cur.val;
> }
> +
> + if (type >= V4L2_CTRL_COMPOUND_TYPES && p_def.p) {
> + ctrl->p_def.p = ctrl->p_cur.p + tot_ctrl_size;
> + memcpy(ctrl->p_def.p, p_def.p, elem_size);
> + ctrl->has_p_def = true;
> + }
> +
> for (idx = 0; idx < elems; idx++) {
> ctrl->type_ops->init(ctrl, idx, ctrl->p_cur);
> ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
> @@ -2550,6 +2565,7 @@ struct v4l2_ctrl *v4l2
Re: [PATCH] RFC: v4l2-ctrls: Inmplement v4l2_ctrl_new_std_compound()
Hello Hans
Thanks for your review! I will implement the changes and resend, just
one comment.
On Fri, Sep 20, 2019 at 12:07 PM Hans Verkuil wrote:
>
> On 9/17/19 6:21 PM, Ricardo Ribalda Delgado wrote:
> > Hi Hans
> >
> > Is this something close to what you were having in mind? Right now it
> > sits on
> > https://github.com/ribalda/linux/commit/de21dbc2f57b58b22f5d73bc314dd8e59dff5c7d
> > but I will make it as the beginning of my patchset if you think that I
> > am on the right track.
> >
> > Thanks!
> >
> > On Tue, Sep 17, 2019 at 6:19 PM Ricardo Ribalda Delgado
> > wrote:
> >>
> >> Implement v4l2_ctrl_new_std_compound. This is just a discussion patch,
> >> do not merge as is, and be gentle with the author ;P.
> >>
> >> Signed-off-by: Ricardo Ribalda Delgado
> >> ---
> >> drivers/media/i2c/imx214.c | 13 +++--
> >> drivers/media/v4l2-core/v4l2-ctrls.c | 79 +---
> >> include/media/v4l2-ctrls.h | 25 +
> >> 3 files changed, 81 insertions(+), 36 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
> >> index 625617d4c81a..e18fed9f31f1 100644
> >> --- a/drivers/media/i2c/imx214.c
> >> +++ b/drivers/media/i2c/imx214.c
> >> @@ -953,6 +953,9 @@ static int imx214_probe(struct i2c_client *client)
> >> .width = 1120,
> >> .height = 1120,
> >> };
> >> + union v4l2_ctrl_ptr p_def = {
> >> + .p_area = &unit_size,
> >> + };
> >> int ret;
> >>
> >> ret = imx214_parse_fwnode(dev);
> >> @@ -1034,11 +1037,11 @@ static int imx214_probe(struct i2c_client *client)
> >> V4L2_CID_EXPOSURE,
> >> 0, 3184, 1, 0x0c70);
> >>
> >> - imx214->unit_size = v4l2_ctrl_new_area(&imx214->ctrls,
> >> - &imx214_ctrl_ops,
> >> - V4L2_CID_UNIT_CELL_SIZE,
> >> - &unit_size);
> >> -
> >> + imx214->unit_size = v4l2_ctrl_new_std_compound(&imx214->ctrls,
> >> + NULL,
> >> +
> >> V4L2_CID_UNIT_CELL_SIZE,
> >> + 0, 0x7ff, 1, 0,
> >> + p_def);
> >> ret = imx214->ctrls.error;
> >> if (ret) {
> >> dev_err(&client->dev, "%s control init failed (%d)\n",
> >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> >> b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> index 3d2fa1868982..04813ba2262b 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> @@ -1555,6 +1555,10 @@ static void std_init_compound(const struct
> >> v4l2_ctrl *ctrl, u32 idx,
> >> p_mpeg2_slice_params->picture.picture_coding_type =
> >> V4L2_MPEG2_PICTURE_CODING_TYPE_I;
> >> break;
> >> + default:
> >> + if (ctrl->has_p_def)
> >> + memcpy(p, ctrl->p_def.p, ctrl->elem_size);
> >> + break;
>
> It makes more sense to do this at the beginning of this function:
>
> if (ctrl->p_def.p)
> memcpy(p, ctrl->p_def.p, ctrl->elem_size);
> else
> memset(p, 0, ctrl->elem_size);
>
> and then enter the switch.
>
> This avoids calling memset followed by a memcpy.
>
> >> }
> >> }
> >>
> >> @@ -2369,7 +2373,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> >> v4l2_ctrl_handler *hdl,
> >> s64 min, s64 max, u64 step, s64 def,
> >> const u32 dims[V4L2_CTRL_MAX_DIMS], u32 elem_size,
> >> u32 flags, const char * const *qmenu,
> >> - const s64 *qmenu_int, void *priv)
> >> + const s64 *qmenu_int, const union v4l2_ctrl_ptr
> >> p_def,
> >> + void *priv)
> >> {
> >> st
Re: [ANN] Media sessions in Lyon in October: codecs
HI Nicolas Sorry to hijack the thread. Do you know if anyone at AMD is working on making a v4l driver for the encoder? Or they want to continue with their mesa approach? Converting a mesa-vappi to v4l is something doable by the mortals? Just changing the API or is a complete rewrite of the code? Best regards! On Mon, Oct 7, 2019 at 2:05 AM Nicolas Dufresne wrote: > > Le jeudi 26 septembre 2019 à 19:21 +0900, Tomasz Figa a écrit : > > On Mon, Sep 23, 2019 at 11:13 PM Hans Verkuil wrote: > > > Hi all, > > > > > > Since we have three separate half-day sessions for different topics I > > > decided > > > to split the announcement for this in three emails as well, so these > > > things > > > can be discussed in separate threads. > > > > > > All sessions are in room Terreaux VIP Lounge - Level 0. > > > There is a maximum of 15 people. > > > > > > The first session deals with the codec API and is on Tuesday morning from > > > 8:30 (tentative, might change) to 12:00 (we have to vacate the room at > > > that > > > time). > > > > > > Confirmed attendees for this session: > > > > > > Boris Brezillon > > > Alexandre Courbot > > > Nicolas Dufresne > > > Tomasz Figa > > > Ezequiel Garcia > > > Daniel Gomez > > > Dafna Hirschfeld > > > Eugen Hristev > > > Paul Kocialkowski > > > Helen Koike > > > Michael Tretter > > > Hans Verkuil > > > > > > Tentative: > > > > > > Laurent Pinchart > > > Jacopo Mondi > > > > > > Jacopo, please confirm if you want to attend this session. I didn't find > > > an email with explicit confirmation, so it was probably done via irc. But > > > since > > > this session is getting close to capacity I would prefer to keep > > > attendance to > > > those are actually working with codecs (or will work with it in the near > > > future). > > > > > > If I missed someone, or you are on the list but won't attend after all, > > > then > > > please let me know. > > > > > > > > > > > > Agenda: > > > > > > - Status of any pending patches related to codec support. > > > > > > - Requirements of moving codec drivers out of staging. > > > > > > - Finalize the stateful encoder API. There are two pieces that need > > > to be defined: > > > > > > 1) Setting the frame rate so bitrate control can make sense, since > > >they need to know this information. This is also relevant for the > > >stateless codec (and this may have to change on a per-frame basis > > >for stateless codecs!). > > > > > >This can either be implemented via ENUM_FRAMEINTERVALS for the coded > > >pixelformats and S_PARM support, or we just add a new control for this. > > >E.g. V4L2_CID_MPEG_VIDEO_FRAME_INTERVAL (or perhaps FRAME_RATE). If we > > >go for a control, then we need to consider the unit. We can use a > > >fraction as well. See this series that puts in the foundation for that: > > >https://patchwork.linuxtv.org/cover/58857/ > > > > > >I am inclined to go with a control, since the semantics don't really > > >match ENUM_FRAMEINTERVALS/S_PARM. These ioctls still need to be > > > supported > > >for legacy drivers. Open question: some drivers (mediatek, hva, coda) > > >require S_PARM(OUTPUT), some (venus) allow both S_PARM(CAPTURE) and > > >S_PARM(OUTPUT). I am inclined to allow both since this is not a CAPTURE > > >vs OUTPUT thing, it is global to both queues. > > > > > > 2) Interactions between OUTPUT and CAPTURE formats. > > > > > >The main problem is what to do if the capture sizeimage is too small > > >for the OUTPUT resolution when streaming starts. > > > > > >Proposal: width and height of S_FMT(OUTPUT) are used to > > >calculate a minimum sizeimage (app may request more). This is > > >driver-specific. (Is it? Or is this codec-specific?) > > > > > >V4L2_FMT_FLAG_FIXED_RESOLUTION is always set for codec formats > > >for the encoder (i.e. we don't support mid-stream resolution > > >changes for now) and V4L2_EVENT_SOURCE_CHANGE is not > > >supported. See https://patchwork.linuxtv.org/patch/56478/ for > > >the patch adding this flag. > > > > > >Of course, if we start to support mid-stream resolution > > >changes (or other changes that require a source change event), > > >then this flag should be dropped by the encoder driver and > > >documentation on how to handle the source change event should > > >be documented in the encoder spec. I prefer to postpone this > > >until we have an encoder than can actually do mid-stream > > >resolution changes. > > > > > >If sizeimage of the OUTPUT is too small for the CAPTURE > > >resolution and V4L2_EVENT_SOURCE_CHANGE is not supported, > > >then the second STREAMON (either CAPTURE or OUTPUT) will > > >return -ENOMEM since there is not enough memory to do the > > >encode. > > > > > >If V4L2_FMT_FLAG_FIXED_RESOLUTION is set (i.e. that should > > >be the case for all current encoders), then any bitrate controls > > >will be
Re: [ANN] Media sessions in Lyon in October: codecs
HI Tomasz On Mon, Oct 7, 2019 at 11:43 AM Tomasz Figa wrote: > > Hi Ricardo, > > On Mon, Oct 7, 2019 at 6:22 PM Ricardo Ribalda Delgado > wrote: > > > > HI Nicolas > > > > Sorry to hijack the thread. Do you know if anyone at AMD is working on > > making a v4l driver for the encoder? Or they want to continue with > > their mesa approach? > > > > Converting a mesa-vappi to v4l is something doable by the mortals? > > Just changing the API or is a complete rewrite of the code? > > Do you know what kind of hardware that is? AMD VCE https://en.wikipedia.org/wiki/Video_Coding_Engine > > Is it a fully integrated smart encoder that manages everything > internally or a "simplified" one like Rockchip or Intel, which need a > lot of assistance from the software, like bitrate control and > bitstream assembly? For what I can read from the documentation it looks more like the intel, with plenty of knobs to play around, and support for custom motion estimation and all the other fancy stuff. > > Also, is the encoder an integral part of the GPU or a distinct block > that can operate independently of the GPU driver? While it should be > possible to chain a V4L2 driver of the AMDGPU DRM driver, the VAAPI > model is kind of established for encoders that are closely tied with > the GPU. My concern about vaapi is the complexity of the stack, to "simply" encode a video you need mesa and llvm. It would be nicer with a v4l2 m2m driver and gstreamer But i can see that it can get complicated if the vce shares resources with the other parts of the gpu. Thanks! > > Best regards, > Tomasz > > > > > Best regards! > > > > On Mon, Oct 7, 2019 at 2:05 AM Nicolas Dufresne > > wrote: > > > > > > Le jeudi 26 septembre 2019 à 19:21 +0900, Tomasz Figa a écrit : > > > > On Mon, Sep 23, 2019 at 11:13 PM Hans Verkuil > > > > wrote: > > > > > Hi all, > > > > > > > > > > Since we have three separate half-day sessions for different topics I > > > > > decided > > > > > to split the announcement for this in three emails as well, so these > > > > > things > > > > > can be discussed in separate threads. > > > > > > > > > > All sessions are in room Terreaux VIP Lounge - Level 0. > > > > > There is a maximum of 15 people. > > > > > > > > > > The first session deals with the codec API and is on Tuesday morning > > > > > from > > > > > 8:30 (tentative, might change) to 12:00 (we have to vacate the room > > > > > at that > > > > > time). > > > > > > > > > > Confirmed attendees for this session: > > > > > > > > > > Boris Brezillon > > > > > Alexandre Courbot > > > > > Nicolas Dufresne > > > > > Tomasz Figa > > > > > Ezequiel Garcia > > > > > Daniel Gomez > > > > > Dafna Hirschfeld > > > > > Eugen Hristev > > > > > Paul Kocialkowski > > > > > Helen Koike > > > > > Michael Tretter > > > > > Hans Verkuil > > > > > > > > > > Tentative: > > > > > > > > > > Laurent Pinchart > > > > > Jacopo Mondi > > > > > > > > > > Jacopo, please confirm if you want to attend this session. I didn't > > > > > find > > > > > an email with explicit confirmation, so it was probably done via irc. > > > > > But since > > > > > this session is getting close to capacity I would prefer to keep > > > > > attendance to > > > > > those are actually working with codecs (or will work with it in the > > > > > near future). > > > > > > > > > > If I missed someone, or you are on the list but won't attend after > > > > > all, then > > > > > please let me know. > > > > > > > > > > > > > > > > > > > > Agenda: > > > > > > > > > > - Status of any pending patches related to codec support. > > > > > > > > > > - Requirements of moving codec drivers out of staging. > > > > > > > > > > - Finalize the stateful encoder API. There are two pieces that need > > > > > to be defined: > > > > > > > > > > 1) Setting the frame rate so b
[PATCH 2/2] [media] vb2-memops: Use bool macros instead of 1
This is the prototype of the called function: int get_vaddr_frames(unsigned long start, unsigned int nr_pfns, bool write, bool force, struct frame_vector *vec); Signed-off-by: Ricardo Ribalda Delgado --- drivers/media/v4l2-core/videobuf2-memops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c index e4e4976c6849..3c3b517f1d1c 100644 --- a/drivers/media/v4l2-core/videobuf2-memops.c +++ b/drivers/media/v4l2-core/videobuf2-memops.c @@ -49,7 +49,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start, vec = frame_vector_create(nr); if (!vec) return ERR_PTR(-ENOMEM); - ret = get_vaddr_frames(start & PAGE_MASK, nr, write, 1, vec); + ret = get_vaddr_frames(start & PAGE_MASK, nr, write, true, vec); if (ret < 0) goto out_destroy; /* We accept only complete set of PFNs */ -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] vb2-memops: Fix over allocation of frame vectors
On page unaligned frames, create_framevec forces get_vaddr_frames to
allocate an extra page at the end of the buffer. Under some
circumstances, this leads to -EINVAL on VIDIOC_QBUF.
E.g:
We have vm_a that vm_area that goes from 0x1000 to 0x3000. And a
frame that goes from 0x1800 to 0x2800, i.e. 2 pages.
frame_vector_create will be called with the following params:
get_vaddr_frames(0x1800 , 2, write, 1, vec);
get_vaddr will allocate the first page after checking that the memory
0x1800-0x27ff is valid, but it will not allocate the second page because
the range 0x2800-0x37ff is out of the vm_a range. This results in
create_framevec returning -EFAULT
Error Trace:
[ 9083.793015] video0: VIDIOC_QBUF: 00:00:00. index=1,
type=vid-cap, flags=0x2002, field=any, sequence=0,
memory=userptr, bytesused=0, offset/userptr=0x7ff2b023ca80, length=5765760
[ 9083.793028] timecode=00:00:00 type=0, flags=0x,
frames=0, userbits=0x
[ 9083.793117] video0: VIDIOC_QBUF: error -22: 00:00:00.
index=2, type=vid-cap, flags=0x, field=any, sequence=0,
memory=userptr, bytesused=0, offset/userptr=0x7ff2b07bc500, length=5765760
Fixes: 21fb0cb7ec65 ("[media] vb2: Provide helpers for mapping virtual
addresses")
Reported-by: Albert Antony
Signed-off-by: Ricardo Ribalda Delgado
---
Maybe we should cc stable.
This error has not pop-out yet because userptr is usually called with memory
on the heap and malloc usually overallocate. This error has been a pain to
trace :).
Regards!
drivers/media/v4l2-core/videobuf2-memops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index dbec5923fcf0..e4e4976c6849 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -49,7 +49,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
vec = frame_vector_create(nr);
if (!vec)
return ERR_PTR(-ENOMEM);
- ret = get_vaddr_frames(start, nr, write, 1, vec);
+ ret = get_vaddr_frames(start & PAGE_MASK, nr, write, 1, vec);
if (ret < 0)
goto out_destroy;
/* We accept only complete set of PFNs */
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: vb2: Fix regression on poll() for RW mode
When using a device is read/write mode, vb2 does not handle properly the
first select/poll operation. It allways return POLLERR.
The reason for this is that when this code has been refactored, some of
the operations have changed their order, and now fileio emulator is not
started by poll, due to a previous check.
Reported-by: Dimitrios Katsaros
Cc: Junghak Sung
Cc: sta...@vger.kernel.org
Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-core.c | 8
drivers/media/v4l2-core/videobuf2-v4l2.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f496e0e..199c65dbe330 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct
file *file,
return POLLERR;
/*
+* For compatibility with vb1: if QBUF hasn't been called yet, then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+*/
+ if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
+ return POLLERR;
+
+ /*
* For output streams you can call write() as long as there are fewer
* buffers queued than there are buffers available.
*/
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f552124050..c9bad9ef2104 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
poll_wait(file, &fh->wait, wait);
}
- /*
-* For compatibility with vb1: if QBUF hasn't been called yet, then
-* return POLLERR as well. This only affects capture queues, output
-* queues will always initialize waiting_for_buffers to false.
-*/
- if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
- return POLLERR;
-
return res | vb2_core_poll(q, file, wait);
}
EXPORT_SYMBOL_GPL(vb2_poll);
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: vb2: Fix regression on poll() for RW mode
When using a device is read/write mode, vb2 does not handle properly the
first select/poll operation.
The reason for this, is that when this code has been refactored, some of
the operations have changed their order, and now fileio emulator is not
started.
The reintroduced check to the core is enabled by a quirk flag, that
avoids this check by other subsystems like DVB.
Reported-by: Dimitrios Katsaros
Cc: Junghak Sung
Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
Cc: sta...@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
v2: By Hans Verkuil and
Mauro Carvalho Chehab :
Add a quirk bit to enable this behaviour on the core.
drivers/media/v4l2-core/videobuf2-core.c | 9 +
drivers/media/v4l2-core/videobuf2-v4l2.c | 9 +
include/media/videobuf2-core.h | 4
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f496e0e..58eb9be13510 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2298,6 +2298,15 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct
file *file,
return POLLERR;
/*
+* For compatibility with vb1: if QBUF hasn't been called yet, then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+*/
+ if (q->quirk_poll_must_check_waiting_for_buffers &&
+ q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
+ return POLLERR;
+
+ /*
* For output streams you can call write() as long as there are fewer
* buffers queued than there are buffers available.
*/
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f552124050..3e649adf85ef 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -765,6 +765,7 @@ int vb2_queue_init(struct vb2_queue *q)
q->is_output = V4L2_TYPE_IS_OUTPUT(q->type);
q->copy_timestamp = (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK)
== V4L2_BUF_FLAG_TIMESTAMP_COPY;
+ q->quirk_poll_must_check_waiting_for_buffers = true;
return vb2_core_queue_init(q);
}
@@ -818,14 +819,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
poll_wait(file, &fh->wait, wait);
}
- /*
-* For compatibility with vb1: if QBUF hasn't been called yet, then
-* return POLLERR as well. This only affects capture queues, output
-* queues will always initialize waiting_for_buffers to false.
-*/
- if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
- return POLLERR;
-
return res | vb2_core_poll(q, file, wait);
}
EXPORT_SYMBOL_GPL(vb2_poll);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b6c2ba..3a1620946068 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -400,6 +400,9 @@ struct vb2_buf_ops {
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
* @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
+ * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF
+ * has not been called. This is a vb1 idiom that has been adopted
+ * also by vb2.
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -463,6 +466,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+ unsigned quirk_poll_must_check_waiting_for_buffers:1;
struct mutex*lock;
void*owner;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] media: vb2: Fix regression on poll() for RW mode
When using a device is read/write mode, vb2 does not handle properly the
first select/poll operation.
The reason for this, is that when this code has been refactored, some of
the operations have changed their order, and now fileio emulator is not
started.
The reintroduced check to the core is enabled by a quirk flag, that
avoids this check by other subsystems like DVB.
Reported-by: Dimitrios Katsaros
Cc: Junghak Sung
Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
Cc: sta...@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
v3: By Hans Verkuil
Reorder comment.
drivers/media/v4l2-core/videobuf2-core.c | 4
drivers/media/v4l2-core/videobuf2-v4l2.c | 15 +++
include/media/videobuf2-core.h | 4
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f496e0e..05ad744504ce 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2297,6 +2297,10 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct
file *file,
if (!vb2_is_streaming(q) || q->error)
return POLLERR;
+ if (q->quirk_poll_must_check_waiting_for_buffers &&
+ q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
+ return POLLERR;
+
/*
* For output streams you can call write() as long as there are fewer
* buffers queued than there are buffers available.
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f552124050..e46754b5610e 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -765,6 +765,13 @@ int vb2_queue_init(struct vb2_queue *q)
q->is_output = V4L2_TYPE_IS_OUTPUT(q->type);
q->copy_timestamp = (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK)
== V4L2_BUF_FLAG_TIMESTAMP_COPY;
+ /*
+* If this quirk is set and QBUF hasn't been called yet then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+* This quirk is set by V4L2 for backwards compatibility reasons.
+*/
+ q->quirk_poll_must_check_waiting_for_buffers = true;
return vb2_core_queue_init(q);
}
@@ -818,14 +825,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
poll_wait(file, &fh->wait, wait);
}
- /*
-* For compatibility with vb1: if QBUF hasn't been called yet, then
-* return POLLERR as well. This only affects capture queues, output
-* queues will always initialize waiting_for_buffers to false.
-*/
- if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
- return POLLERR;
-
return res | vb2_core_poll(q, file, wait);
}
EXPORT_SYMBOL_GPL(vb2_poll);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b6c2ba..3a1620946068 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -400,6 +400,9 @@ struct vb2_buf_ops {
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
* @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
+ * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF
+ * has not been called. This is a vb1 idiom that has been adopted
+ * also by vb2.
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -463,6 +466,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+ unsigned quirk_poll_must_check_waiting_for_buffers:1;
struct mutex*lock;
void*owner;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] media: vb2: Fix regression on poll() for RW mode
When using a device is read/write mode, vb2 does not handle properly the
first select/poll operation.
The reason for this, is that when this code has been refactored, some of
the operations have changed their order, and now fileio emulator is not
started.
The reintroduced check to the core is enabled by a quirk flag, that
avoids this check by other subsystems like DVB.
Reported-by: Dimitrios Katsaros
Cc: Junghak Sung
Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
Cc: sta...@vger.kernel.org
Signed-off-by: Ricardo Ribalda Delgado
---
v4: Reported by Hans
Rewrite comments
Thanks!
drivers/media/v4l2-core/videobuf2-core.c | 10 ++
drivers/media/v4l2-core/videobuf2-v4l2.c | 14 ++
include/media/videobuf2-core.h | 4
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f496e0e..6b3a81504a7a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2298,6 +2298,16 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct
file *file,
return POLLERR;
/*
+* If this quirk is set and QBUF hasn't been called yet then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+* This quirk is set by V4L2 for backwards compatibility reasons.
+*/
+ if (q->quirk_poll_must_check_waiting_for_buffers &&
+ q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
+ return POLLERR;
+
+ /*
* For output streams you can call write() as long as there are fewer
* buffers queued than there are buffers available.
*/
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f552124050..0b1b8c7b6ce5 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -765,6 +765,12 @@ int vb2_queue_init(struct vb2_queue *q)
q->is_output = V4L2_TYPE_IS_OUTPUT(q->type);
q->copy_timestamp = (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK)
== V4L2_BUF_FLAG_TIMESTAMP_COPY;
+ /*
+* For compatibility with vb1: if QBUF hasn't been called yet, then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+*/
+ q->quirk_poll_must_check_waiting_for_buffers = true;
return vb2_core_queue_init(q);
}
@@ -818,14 +824,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
poll_wait(file, &fh->wait, wait);
}
- /*
-* For compatibility with vb1: if QBUF hasn't been called yet, then
-* return POLLERR as well. This only affects capture queues, output
-* queues will always initialize waiting_for_buffers to false.
-*/
- if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
- return POLLERR;
-
return res | vb2_core_poll(q, file, wait);
}
EXPORT_SYMBOL_GPL(vb2_poll);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b6c2ba..3a1620946068 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -400,6 +400,9 @@ struct vb2_buf_ops {
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
* @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
+ * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF
+ * has not been called. This is a vb1 idiom that has been adopted
+ * also by vb2.
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -463,6 +466,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+ unsigned quirk_poll_must_check_waiting_for_buffers:1;
struct mutex*lock;
void*owner;
--
2.8.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l-ioctl: Fix typo on v4l_print_frmsizeenum
max_width and max_height are swap with step_width and step_height.
Signed-off-by: Ricardo Ribalda Delgado
---
Since that this bug has been here for ever. I do not know if we should
notify stable or not
I have also cut the lines to respect the 80 char limit
drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index b60a6b0841d1..79614992ee21 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -730,9 +730,12 @@ static void v4l_print_frmsizeenum(const void *arg, bool
write_only)
break;
case V4L2_FRMSIZE_TYPE_STEPWISE:
pr_cont(", min=%ux%u, max=%ux%u, step=%ux%u\n",
- p->stepwise.min_width, p->stepwise.min_height,
- p->stepwise.step_width, p->stepwise.step_height,
- p->stepwise.max_width, p->stepwise.max_height);
+ p->stepwise.min_width,
+ p->stepwise.min_height,
+ p->stepwise.max_width,
+ p->stepwise.max_height,
+ p->stepwise.step_width,
+ p->stepwise.step_height);
break;
case V4L2_FRMSIZE_TYPE_CONTINUOUS:
/* fall through */
--
2.14.1
[PATCH v2] v4l-ioctl: Fix typo on v4l_print_frmsizeenum
max_width and max_height are swap with step_width and step_height.
Signed-off-by: Ricardo Ribalda Delgado
---
Since that this bug has been here for ever. I do not know if we should
notify stable or not
I have also cut the lines to respect the 80 char limit
v2: Suggested by Laurent Pinchart
-Fix indentation
drivers/media/v4l2-core/v4l2-ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index b60a6b0841d1..0292f327467d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -730,9 +730,9 @@ static void v4l_print_frmsizeenum(const void *arg, bool
write_only)
break;
case V4L2_FRMSIZE_TYPE_STEPWISE:
pr_cont(", min=%ux%u, max=%ux%u, step=%ux%u\n",
- p->stepwise.min_width, p->stepwise.min_height,
- p->stepwise.step_width, p->stepwise.step_height,
- p->stepwise.max_width, p->stepwise.max_height);
+ p->stepwise.min_width, p->stepwise.min_height,
+ p->stepwise.max_width, p->stepwise.max_height,
+ p->stepwise.step_width, p->stepwise.step_height);
break;
case V4L2_FRMSIZE_TYPE_CONTINUOUS:
/* fall through */
--
2.14.1
[PATCH] media: v4l2-ctrl: Fix flags field on Control events
VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for
the control flags field.
This patch creates a new function user_flags(), that calculates the user
exported flags value (which is different than the kernel internal flags
structure). This function is then used by all the code that exports the
internal flags to userspace.
Reported-by: Dimitrios Katsaros
Signed-off-by: Ricardo Ribalda Delgado
---
Maybe we should cc stable on this one.
drivers/media/v4l2-core/v4l2-ctrls.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 4e53a8654690..751cf5746f90 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1227,6 +1227,16 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
}
EXPORT_SYMBOL(v4l2_ctrl_fill);
+static u32 user_flags(struct v4l2_ctrl *ctrl)
+{
+ u32 flags = ctrl->flags;
+
+ if (ctrl->is_ptr)
+ flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
+
+ return flags;
+}
+
static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32
changes)
{
memset(ev->reserved, 0, sizeof(ev->reserved));
@@ -1234,7 +1244,7 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
ev->id = ctrl->id;
ev->u.ctrl.changes = changes;
ev->u.ctrl.type = ctrl->type;
- ev->u.ctrl.flags = ctrl->flags;
+ ev->u.ctrl.flags = user_flags(ctrl);
if (ctrl->is_ptr)
ev->u.ctrl.value64 = 0;
else
@@ -2577,10 +2587,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl,
struct v4l2_query_ext_ctr
else
qc->id = ctrl->id;
strlcpy(qc->name, ctrl->name, sizeof(qc->name));
- qc->flags = ctrl->flags;
+ qc->flags = user_flags(ctrl);
qc->type = ctrl->type;
- if (ctrl->is_ptr)
- qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
qc->elem_size = ctrl->elem_size;
qc->elems = ctrl->elems;
qc->nr_of_dims = ctrl->nr_of_dims;
--
2.14.2
[PATCH v2] media: v4l2-ctrl: Fix flags field on Control events
VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for
the control flags field.
This patch creates a new function user_flags(), that calculates the user
exported flags value (which is different than the kernel internal flags
structure). This function is then used by all the code that exports the
internal flags to userspace.
Reported-by: Dimitrios Katsaros
Signed-off-by: Ricardo Ribalda Delgado
---
Attention: Maybe we want to cc stable.
v2: Suggested-by Hans Verkuil
-Define struct v4l2_ctrl as const
drivers/media/v4l2-core/v4l2-ctrls.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 4e53a8654690..c230bd5c6558 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1227,6 +1227,16 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
}
EXPORT_SYMBOL(v4l2_ctrl_fill);
+static u32 user_flags(const struct v4l2_ctrl *ctrl)
+{
+ u32 flags = ctrl->flags;
+
+ if (ctrl->is_ptr)
+ flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
+
+ return flags;
+}
+
static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32
changes)
{
memset(ev->reserved, 0, sizeof(ev->reserved));
@@ -1234,7 +1244,7 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
ev->id = ctrl->id;
ev->u.ctrl.changes = changes;
ev->u.ctrl.type = ctrl->type;
- ev->u.ctrl.flags = ctrl->flags;
+ ev->u.ctrl.flags = user_flags(ctrl);
if (ctrl->is_ptr)
ev->u.ctrl.value64 = 0;
else
@@ -2577,10 +2587,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl,
struct v4l2_query_ext_ctr
else
qc->id = ctrl->id;
strlcpy(qc->name, ctrl->name, sizeof(qc->name));
- qc->flags = ctrl->flags;
+ qc->flags = user_flags(ctrl);
qc->type = ctrl->type;
- if (ctrl->is_ptr)
- qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
qc->elem_size = ctrl->elem_size;
qc->elems = ctrl->elems;
qc->nr_of_dims = ctrl->nr_of_dims;
--
2.13.2
Re: [ANN] Call for topics for the media mini-summit on Friday Oct 27 in Prague
Hi Hans On Fri, Sep 1, 2017 at 11:46 AM, Hans Verkuil wrote: > > > Also, if you plan to attend, please let me know. It is open for all, but it is > nice if we know beforehand who we can expect. > I plan to attend. I do not have any specific topic right now, but as the date gets closer I might add something. See you in Prague. Thanks
[PATCH] v4l2_compliance: -EINVAL is expected when ret is not 0
Otherwise the driver can never return a register Signed-off-by: Ricardo Ribalda Delgado --- utils/v4l2-compliance/v4l2-test-debug.cpp |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/v4l2-compliance/v4l2-test-debug.cpp b/utils/v4l2-compliance/v4l2-test-debug.cpp index 90c5b90..fa42d2c 100644 --- a/utils/v4l2-compliance/v4l2-test-debug.cpp +++ b/utils/v4l2-compliance/v4l2-test-debug.cpp @@ -49,7 +49,7 @@ int testRegister(struct node *node) return ret; // Not allowed to call VIDIOC_DBG_G_REGISTER unless root fail_on_test(uid && ret != EPERM); - fail_on_test(uid == 0 && ret != EINVAL); + fail_on_test(uid == 0 && ret && ret != EINVAL); fail_on_test(uid == 0 && !ret && reg.size == 0); chip.match.type = V4L2_CHIP_MATCH_BRIDGE; chip.match.addr = 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about v4l2-compliance: cap->readbuffers
Hello I am developing a driver for a camera that supports read/write and mmap access to the buffers. When I am running the compliance test, I cannot pass it because of this test on v4l2-test-formats.cpp 904 if (!(node->caps & V4L2_CAP_READWRITE)) 905 fail_on_test(cap->readbuffers); 906 else if (node->caps & V4L2_CAP_STREAMING) 907 fail_on_test(!cap->readbuffers); What should be the value of cap-readbuffers for a driver such as mine, that supports cap_readwrite and cap_streaming? Or I cannot support both, although at least this drivers do the same? $ git grep CAP_READWRITE * | grep CAP_STREAMING pci/cx25821/cx25821-video.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; pci/cx88/cx88-video.c: cap->device_caps = V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; pci/saa7134/saa7134-video.c: cap->device_caps = V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; platform/marvell-ccic/mcam-core.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; platform/via-camera.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; usb/cx231xx/cx231xx-video.c: cap->device_caps = V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; usb/em28xx/em28xx-video.c: V4L2_CAP_READWRITE | V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; usb/stkwebcam/stk-webcam.c: | V4L2_CAP_READWRITE | V4L2_CAP_STREAMING; usb/tlg2300/pd-video.c: V4L2_CAP_STREAMING | V4L2_CAP_READWRITE; Thanks! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about v4l2-compliance: cap->readbuffers
Thanks for the explanation Hans!
I finaly manage to pass that one ;)
Just one more question. Why the compliance test checks if the DISABLED
flag is on on for qctrls?
http://git.linuxtv.org/v4l-utils.git/blob/3ae390e54a0ba627c9e74953081560192b996df4:/utils/v4l2-compliance/v4l2-test-controls.cpp#l137
137 if (fl & V4L2_CTRL_FLAG_DISABLED)
138 return fail("DISABLED flag set\n");
Apparently that has been added on:
http://git.linuxtv.org/v4l-utils.git/commit/0a4d4accea7266d7b5f54dea7ddf46cce8421fbb
But I have failed to find a reason
Thanks again!
On Tue, Jul 30, 2013 at 3:45 PM, Hans Verkuil wrote:
> On Tue 30 July 2013 15:12:57 Ricardo Ribalda Delgado wrote:
>> Hello
>>
>> I am developing a driver for a camera that supports read/write and
>> mmap access to the buffers.
>>
>> When I am running the compliance test, I cannot pass it because of
>> this test on v4l2-test-formats.cpp
>>
>> 904 if (!(node->caps & V4L2_CAP_READWRITE))
>> 905 fail_on_test(cap->readbuffers);
>> 906 else if (node->caps & V4L2_CAP_STREAMING)
>> 907 fail_on_test(!cap->readbuffers);
>>
>> What should be the value of cap-readbuffers for a driver such as mine,
>> that supports cap_readwrite and cap_streaming? Or I cannot support
>> both, although at least this drivers do the same?
>
> The readbuffers parameter is highly dubious. I generally set it in a driver
> to the lowest number of buffers the hardware allows (e.g. what VIDIOC_REQBUFS
> returns if you give it a buffer count of 1).
>
> In theory this value allows you to increase the number of buffers used
> by read() so you can have more frames pending. In practice the only driver
> using it is sn9c102, which is an obscure webcam that really should be folded
> into the gspca driver suite.
>
> I am really tempted to deprecate/obsolete readbuffers.
>
> Anyway, to squash this compliance error just set readbuffers to the lowest
> number of allowed buffers.
>
> Regards,
>
> Hans
>
>>
>>
>> $ git grep CAP_READWRITE * | grep CAP_STREAMING
>> pci/cx25821/cx25821-video.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
>> pci/cx88/cx88-video.c: cap->device_caps = V4L2_CAP_READWRITE |
>> V4L2_CAP_STREAMING;
>> pci/saa7134/saa7134-video.c: cap->device_caps = V4L2_CAP_READWRITE |
>> V4L2_CAP_STREAMING;
>> platform/marvell-ccic/mcam-core.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
>> platform/via-camera.c: V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
>> usb/cx231xx/cx231xx-video.c: cap->device_caps = V4L2_CAP_READWRITE |
>> V4L2_CAP_STREAMING;
>> usb/em28xx/em28xx-video.c: V4L2_CAP_READWRITE | V4L2_CAP_VIDEO_CAPTURE
>> | V4L2_CAP_STREAMING;
>> usb/stkwebcam/stk-webcam.c: | V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
>> usb/tlg2300/pd-video.c: V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
>>
>>
>> Thanks!
>>
>>
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about v4l2-compliance: cap->readbuffers
Hello
I have a camera that works on two modes: Mono and colour. On color
mode it has 3 gains, on mono mode it has 1 gain.
When the user sets the output to mono I disable the color controls
(and the other way around).
Also on color mode the hflip and vflip do not work, therefore I dont show them.
I could return -EINVAL, but I rather not show the controls to the user.
What would be the proper way to do this?
Thanks gain.
On Tue, Jul 30, 2013 at 5:29 PM, Hans Verkuil wrote:
> On Tue 30 July 2013 17:18:58 Ricardo Ribalda Delgado wrote:
>> Thanks for the explanation Hans!
>>
>> I finaly manage to pass that one ;)
>>
>> Just one more question. Why the compliance test checks if the DISABLED
>> flag is on on for qctrls?
>>
>> http://git.linuxtv.org/v4l-utils.git/blob/3ae390e54a0ba627c9e74953081560192b996df4:/utils/v4l2-compliance/v4l2-test-controls.cpp#l137
>>
>> 137 if (fl & V4L2_CTRL_FLAG_DISABLED)
>> 138 return fail("DISABLED flag set\n");
>>
>> Apparently that has been added on:
>> http://git.linuxtv.org/v4l-utils.git/commit/0a4d4accea7266d7b5f54dea7ddf46cce8421fbb
>>
>> But I have failed to find a reason
>
> It shouldn't be used anymore in drivers. With the control framework there is
> no longer any reason to use the DISABLED flag.
>
> If something has a valid use case for it, then I'd like to know what it is.
>
> Regards,
>
> Hans
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about v4l2-compliance: cap->readbuffers
Hello Hans
Thanks for the explanation. I have tried changing the controls to
inactive and the are shown disabled on the gui, just as you say, but
they are there :S. I personally liked better the previous behaviour,
when the controls where not shown at all. But it is just that, a
taste, if it is more correct showing them as inactive they will be
inactive :).
For a case where a option is only available at a specific format: I
was also disablig the control (now inactiving it), and returning
-EINVAL if the user tried to set the control on an incompatible
format. Apparently the v4l2-compilance dont like that either, is this
a false positive or I should behave differently?.
Thank you again!
On Tue, Jul 30, 2013 at 6:17 PM, Hans Verkuil wrote:
> Hi Ricardo,
>
> On 07/30/2013 05:46 PM, Ricardo Ribalda Delgado wrote:
>> Hello
>>
>> I have a camera that works on two modes: Mono and colour. On color
>> mode it has 3 gains, on mono mode it has 1 gain.
>>
>> When the user sets the output to mono I disable the color controls
>> (and the other way around).
>>
>> Also on color mode the hflip and vflip do not work, therefore I dont show
>> them.
>>
>> I could return -EINVAL, but I rather not show the controls to the user.
>>
>> What would be the proper way to do this?
>
> Use the INACTIVE flag, that's the way it is typically done. You can still set
> such controls, but the new value won't be active until you switch back to a
> mode where they do work.
>
> Using INACTIVE will show such controls as disabled in a GUI like qv4l2. I
> highly
> recommend using qv4l2 for testing this since it is the reference
> implementation
> of how GUIs should interpret control flags.
>
> Regards,
>
> Hans
>
>>
>>
>> Thanks gain.
>>
>>
>>
>>
>>
>> On Tue, Jul 30, 2013 at 5:29 PM, Hans Verkuil wrote:
>>> On Tue 30 July 2013 17:18:58 Ricardo Ribalda Delgado wrote:
>>>> Thanks for the explanation Hans!
>>>>
>>>> I finaly manage to pass that one ;)
>>>>
>>>> Just one more question. Why the compliance test checks if the DISABLED
>>>> flag is on on for qctrls?
>>>>
>>>> http://git.linuxtv.org/v4l-utils.git/blob/3ae390e54a0ba627c9e74953081560192b996df4:/utils/v4l2-compliance/v4l2-test-controls.cpp#l137
>>>>
>>>> 137 if (fl & V4L2_CTRL_FLAG_DISABLED)
>>>> 138 return fail("DISABLED flag set\n");
>>>>
>>>> Apparently that has been added on:
>>>> http://git.linuxtv.org/v4l-utils.git/commit/0a4d4accea7266d7b5f54dea7ddf46cce8421fbb
>>>>
>>>> But I have failed to find a reason
>>>
>>> It shouldn't be used anymore in drivers. With the control framework there is
>>> no longer any reason to use the DISABLED flag.
>>>
>>> If something has a valid use case for it, then I'd like to know what it is.
>>>
>>> Regards,
>>>
>>> Hans
>>
>>
>>
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libv4lconvert: Support for Y16 pixel format
This patch adds support for V4L2_PIX_FMT_Y16 format.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert.c | 19 +++
lib/libv4lconvert/rgbyuv.c| 30 ++
2 files changed, 49 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 60010f1..bc5e34f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
+ { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
}
+ case V4L2_PIX_FMT_Y16:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y16_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y16_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size < (width * height * 2)) {
+ V4LCONVERT_ERR("short y16 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y4:
case V4L2_PIX_FMT_Y6:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index d05abe9..bef034f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char *src,
unsigned char *dest,
}
}
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height >= 0) {
+ for (j = 0; j < width; j++) {
+ *dest++ = *src;
+ *dest++ = *src;
+ *dest++ = *src;
+ src+=2;
+ }
+ }
+}
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt)
+{
+ int x, y;
+
+ /* Y */
+ for (y = 0; y < src_fmt->fmt.pix.height; y++)
+ for (x = 0; x < src_fmt->fmt.pix.width; x++){
+ *dest++ = *src;
+ src+=2;
+ }
+
+ /* Clear U/V */
+ memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
2);
+}
+
void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] libv4lconvert: Support for RGB32 and BGR32 format
This patch adds support for V4L2_PIX_FMT_BGR32 and V4L2_PIX_FMT_BGR32
formats.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |5 ++-
lib/libv4lconvert/libv4lconvert.c | 58 +---
lib/libv4lconvert/rgbyuv.c | 66 ++--
3 files changed, 111 insertions(+), 18 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 6422fdd..2f411ea 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -108,7 +108,7 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
int v4lconvert_oom_error(struct v4lconvert_data *data);
void v4lconvert_rgb24_to_yuv420(const unsigned char *src, unsigned char *dest,
- const struct v4l2_format *src_fmt, int bgr, int yvu);
+ const struct v4l2_format *src_fmt, int bgr, int yvu, int rgb32);
void v4lconvert_yuv420_to_rgb24(const unsigned char *src, unsigned char *dst,
int width, int height, int yvu);
@@ -158,6 +158,9 @@ void v4lconvert_y16_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_rgb32_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index bc5e34f..a5ada5b 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -84,6 +84,8 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[]
= {
SUPPORTED_DST_PIXFMTS,
/* packed rgb formats */
{ V4L2_PIX_FMT_RGB565, 16, 4, 6, 0 },
+ { V4L2_PIX_FMT_BGR32, 32, 4, 6, 0 },
+ { V4L2_PIX_FMT_RGB32, 32, 4, 6, 0 },
/* yuv 4:2:2 formats */
{ V4L2_PIX_FMT_YUYV,16, 5, 4, 0 },
{ V4L2_PIX_FMT_YVYU,16, 5, 4, 0 },
@@ -981,10 +983,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(d, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1, 0);
break;
}
break;
@@ -1079,10 +1081,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1, 0);
break;
}
if (src_size < (width * height * 3)) {
@@ -1101,10 +1103,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
memcpy(dest, src, width * height * 3);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1, 0);
break;
}
if (src_size < (width * height * 3)) {
@@ -1114,6 +1116,50 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ case V4L2_PIX_FMT_RGB32:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 1);
+ break;
+ case V4L2_PIX_FMT_
[PATCH 0/2] Add support for V4L2_PIX_FMT_Y16, V4L2_PIX_FMT_RGB32 and V4L2_PIX_FMT_BGR32
This patch adds support for 3 new formats. Ricardo Ribalda Delgado (2): libv4lconvert: Support for Y16 pixel format libv4lconvert: Support for RGB32 and BGR32 format lib/libv4lconvert/libv4lconvert-priv.h | 11 +++- lib/libv4lconvert/libv4lconvert.c | 77 +++-- lib/libv4lconvert/rgbyuv.c | 96 3 files changed, 166 insertions(+), 18 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] libv4lconvert: Support for Y16 pixel format
This patch adds support for V4L2_PIX_FMT_Y16 format.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |6 ++
lib/libv4lconvert/libv4lconvert.c | 19 +++
lib/libv4lconvert/rgbyuv.c | 30 ++
3 files changed, 55 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index c37e220..6422fdd 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -152,6 +152,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 60010f1..bc5e34f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
+ { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
}
+ case V4L2_PIX_FMT_Y16:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y16_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y16_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size < (width * height * 2)) {
+ V4LCONVERT_ERR("short y16 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y4:
case V4L2_PIX_FMT_Y6:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index d05abe9..bef034f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char *src,
unsigned char *dest,
}
}
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height >= 0) {
+ for (j = 0; j < width; j++) {
+ *dest++ = *src;
+ *dest++ = *src;
+ *dest++ = *src;
+ src+=2;
+ }
+ }
+}
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt)
+{
+ int x, y;
+
+ /* Y */
+ for (y = 0; y < src_fmt->fmt.pix.height; y++)
+ for (x = 0; x < src_fmt->fmt.pix.width; x++){
+ *dest++ = *src;
+ src+=2;
+ }
+
+ /* Clear U/V */
+ memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
2);
+}
+
void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Hi Sakarius I think the whole point of the videobuf2 is sharing pages with the user space, so until vm_insert_page does not support high order pages we should split them. Unfortunately the mm is completely out of my topic, so I don't think that I could be very useful there. With my patch, in the worst case scenario, the image is split in as many blocks as today, but in a normal setup the ammount of blocks is 1 or two blocks in total!. Best regards. On Wed, Jul 31, 2013 at 8:37 AM, Sakari Ailus wrote: > Hi Jon and Sylwester, > > On Mon, Jul 29, 2013 at 09:16:44AM -0600, Jonathan Corbet wrote: >> On Mon, 29 Jul 2013 13:27:12 +0200 >> Marek Szyprowski wrote: >> >> > > You've gone to all this trouble to get a higher-order allocation so you'd >> > > have fewer segments, then you undo it all by splitting things apart into >> > > individual pages. Why? Clearly I'm missing something, this seems to >> > > defeat the purpose of the whole exercise? >> > >> > Individual zero-order pages are required to get them mapped to userspace in >> > mmap callback. >> >> Yeah, Ricardo explained that too. The right solution might be to fix that >> problem rather than work around it, but I can see why one might shy at that >> task! :) >> >> I do wonder, though, if an intermediate solution using huge pages might be >> the best approach? That would get the number of segments down pretty far, >> and using huge pages for buffers would reduce TLB pressure significantly >> if the CPU is working through the data at all. Meanwhile, inserting huge >> pages into the process's address space should work easily. Just a thought. > > My ack to that. > > And in the case of dma-buf the buffer doesn't need to be mapped to user > space. It'd be quite nice to be able to share higher order allocations even > if they couldn't be mapped to user space as such. > > Using 2 MiB pages would probably solve Ricardo's issue, but used alone > they'd waste lots of memory for small buffers. If small pages (in Ricardo's > case) were used when 2 MiB pages would be too big, e.g. 1 MiB buffer would > already have 256 pages in it. Perhaps it'd be useful to specify whether > large pages should be always preferred over smaller ones. > > -- > Kind regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table
Replace the private struct vb2_dma_sg_desc with the struct sg_table so
we can benefit from all the helping functions in lib/scatterlist.c for
things like allocating the sg or compacting the descriptor
marvel-ccic and solo6x10 drivers, that uses this api has been updated
Acked-by: Marek Szyprowski
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/platform/marvell-ccic/mcam-core.c| 14 +--
drivers/media/v4l2-core/videobuf2-dma-sg.c | 103
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 ++--
include/media/videobuf2-dma-sg.h | 10 +-
4 files changed, 63 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 64ab91e..0ac51bd 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1040,16 +1040,16 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
struct mcam_dma_desc *desc = mvb->dma_desc;
struct scatterlist *sg;
int i;
- mvb->dma_desc_nent = dma_map_sg(cam->dev, sgd->sglist, sgd->num_pages,
- DMA_FROM_DEVICE);
+ mvb->dma_desc_nent = dma_map_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
if (mvb->dma_desc_nent <= 0)
return -EIO; /* Not sure what's right here */
- for_each_sg(sgd->sglist, sg, mvb->dma_desc_nent, i) {
+ for_each_sg(sg_table->sgl, sg, mvb->dma_desc_nent, i) {
desc->dma_addr = sg_dma_address(sg);
desc->segment_len = sg_dma_len(sg);
desc++;
@@ -1060,9 +1060,11 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
static int mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
{
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
- dma_unmap_sg(cam->dev, sgd->sglist, sgd->num_pages, DMA_FROM_DEVICE);
+ if (sg_table)
+ dma_unmap_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
return 0;
}
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 4a7b59b..0328899 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -35,7 +35,9 @@ struct vb2_dma_sg_buf {
struct page **pages;
int write;
int offset;
- struct vb2_dma_sg_desc sg_desc;
+ struct sg_table sg_table;
+ size_t size;
+ unsigned intnum_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -46,7 +48,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
gfp_t gfp_flags)
{
unsigned int last_page = 0;
- int size = buf->sg_desc.size;
+ int size = buf->size;
while (size > 0) {
struct page *pages;
@@ -74,12 +76,8 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
}
split_page(pages, order);
- for (i = 0; i < (1<pages[last_page] = pages[i];
- sg_set_page(&buf->sg_desc.sglist[last_page],
- buf->pages[last_page], PAGE_SIZE, 0);
- last_page++;
- }
+ for (i = 0; i < (1<pages[last_page++] = pages[i];
size -= PAGE_SIZE << order;
}
@@ -91,6 +89,7 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
{
struct vb2_dma_sg_buf *buf;
int ret;
+ int num_pages;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -99,17 +98,11 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
buf->vaddr = NULL;
buf->write = 0;
buf->offset = 0;
- buf->sg_desc.size = size;
+ buf->size = size;
/* size is already page aligned */
- buf->sg_desc.num_pages = size >> PAGE_SHIFT;
-
- buf->sg_desc.sglist = vzalloc(buf->sg_desc.num_pages *
- sizeof(*buf->sg_desc.sglist));
- if (!buf->sg_desc.sglist)
-
[PATCH v3 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread
through houndreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages. In the worst case it will behave as before, but most
of the times it will reduce the number of dma segments
Acked-by: Marek Szyprowski
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 60 +++-
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..4a7b59b 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -42,10 +42,55 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ int size = buf->sg_desc.size;
+
+ while (size > 0) {
+ struct page *pages;
+ int order;
+ int i;
+
+ order = get_order(size);
+ /* Dont over allocate*/
+ if ((PAGE_SIZE << order) > size)
+ order--;
+
+ pages = NULL;
+ while (!pages) {
+ pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
+ __GFP_NOWARN | gfp_flags, order);
+ if (pages)
+ break;
+
+ if (order == 0) {
+ while (last_page--)
+ __free_page(buf->pages[last_page]);
+ return -ENOMEM;
+ }
+ order--;
+ }
+
+ split_page(pages, order);
+ for (i = 0; i < (1<pages[last_page] = pages[i];
+ sg_set_page(&buf->sg_desc.sglist[last_page],
+ buf->pages[last_page], PAGE_SIZE, 0);
+ last_page++;
+ }
+
+ size -= PAGE_SIZE << order;
+ }
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +114,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
if (!buf->pages)
goto fail_pages_array_alloc;
- for (i = 0; i < buf->sg_desc.num_pages; ++i) {
- buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf->pages[i])
- goto fail_pages_alloc;
- sg_set_page(&buf->sg_desc.sglist[i],
- buf->pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf->handler.refcount = &buf->refcount;
buf->handler.put = vb2_dma_sg_put;
@@ -89,8 +129,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i >= 0)
- __free_page(buf->pages[i]);
kfree(buf->pages);
fail_pages_array_alloc:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] videobuf2-dma-sg: Contiguos memory allocation
Allocate memory as contiguos as possible to support dma engines with limitated amount of sg-descriptors. Replace private structer vb2_dma_sg_desc with generic struct sg_table. PS: This series of patches is the evolution of my previous patch for vb2-dma-sg to allocate the memory as contiguos as possible. v3: Constains feedback from Andre Heider Andre: Fix error handling (--pages) was wrongly fixed v2: Contains feedback from Andre Heider and Sylwester Nawrocki Andre: Fix error handling (--pages) Sylwester: Squash p3 and p4 into p2 Ricardo Ribalda Delgado (2): videobuf2-dma-sg: Allocate pages as contiguous as possible videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table drivers/media/platform/marvell-ccic/mcam-core.c| 14 +- drivers/media/v4l2-core/videobuf2-dma-sg.c | 149 +++- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 +-- include/media/videobuf2-dma-sg.h | 10 +- 4 files changed, 105 insertions(+), 88 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Hi Andre,
Nice catch! thanks.
I have just uploaded a new version.
https://patchwork.linuxtv.org/patch/19502/
https://patchwork.linuxtv.org/patch/19503/
Thanks for your help
On Fri, Aug 2, 2013 at 10:46 AM, Andre Heider wrote:
> Hi Ricardo,
>
> sorry for the late answer, but the leak I mentioned in my first reply is
> still there, see below.
>
> On Fri, Jul 19, 2013 at 07:02:33PM +0200, Ricardo Ribalda Delgado wrote:
>> Most DMA engines have limitations regarding the number of DMA segments
>> (sg-buffers) that they can handle. Videobuffers can easily spread
>> through houndreds of pages.
>>
>> In the previous aproach, the pages were allocated individually, this
>> could led to the creation houndreds of dma segments (sg-buffers) that
>> could not be handled by some DMA engines.
>>
>> This patch tries to minimize the number of DMA segments by using
>> alloc_pages. In the worst case it will behave as before, but most
>> of the times it will reduce the number of dma segments
>>
>> Signed-off-by: Ricardo Ribalda Delgado
>> ---
>> drivers/media/v4l2-core/videobuf2-dma-sg.c | 60
>> +++-
>> 1 file changed, 49 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> index 16ae3dc..c053605 100644
>> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> @@ -42,10 +42,55 @@ struct vb2_dma_sg_buf {
>>
>> static void vb2_dma_sg_put(void *buf_priv);
>>
>> +static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
>> + gfp_t gfp_flags)
>> +{
>> + unsigned int last_page = 0;
>> + int size = buf->sg_desc.size;
>> +
>> + while (size > 0) {
>> + struct page *pages;
>> + int order;
>> + int i;
>> +
>> + order = get_order(size);
>> + /* Dont over allocate*/
>> + if ((PAGE_SIZE << order) > size)
>> + order--;
>> +
>> + pages = NULL;
>> + while (!pages) {
>> + pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
>> + __GFP_NOWARN | gfp_flags, order);
>> + if (pages)
>> + break;
>> +
>> + if (order == 0)
>> + while (last_page--) {
>> + __free_page(buf->pages[last_page]);
>> + return -ENOMEM;
>> + }
>
> The return statement doesn't make sense in the while() scope, that way you
> wouldn't need the loop at all.
>
> To prevent leaking pages of prior iterations (those with higher orders), pull
> the return out of there:
>
> while (last_page--)
> __free_page(buf->pages[last_page]);
> return -ENOMEM;
>
> Regards,
> Andre
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread
through hundreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages. In the worst case it will behave as before, but most
of the times it will reduce the number of dma segments
Acked-by: Marek Szyprowski
Reviewed-by: Andre Heider
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 60 +++-
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..4999c48 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -42,10 +42,55 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ int size = buf->sg_desc.size;
+
+ while (size > 0) {
+ struct page *pages;
+ int order;
+ int i;
+
+ order = get_order(size);
+ /* Dont over allocate*/
+ if ((PAGE_SIZE << order) > size)
+ order--;
+
+ pages = NULL;
+ while (!pages) {
+ pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
+ __GFP_NOWARN | gfp_flags, order);
+ if (pages)
+ break;
+
+ if (order == 0) {
+ while (last_page--)
+ __free_page(buf->pages[last_page]);
+ return -ENOMEM;
+ }
+ order--;
+ }
+
+ split_page(pages, order);
+ for (i = 0; i < (1 << order); i++) {
+ buf->pages[last_page] = &pages[i];
+ sg_set_page(&buf->sg_desc.sglist[last_page],
+ buf->pages[last_page], PAGE_SIZE, 0);
+ last_page++;
+ }
+
+ size -= PAGE_SIZE << order;
+ }
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +114,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
if (!buf->pages)
goto fail_pages_array_alloc;
- for (i = 0; i < buf->sg_desc.num_pages; ++i) {
- buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf->pages[i])
- goto fail_pages_alloc;
- sg_set_page(&buf->sg_desc.sglist[i],
- buf->pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf->handler.refcount = &buf->refcount;
buf->handler.put = vb2_dma_sg_put;
@@ -89,8 +129,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i >= 0)
- __free_page(buf->pages[i]);
kfree(buf->pages);
fail_pages_array_alloc:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table
Replace the private struct vb2_dma_sg_desc with the struct sg_table so
we can benefit from all the helping functions in lib/scatterlist.c for
things like allocating the sg or compacting the descriptor
marvel-ccic and solo6x10 drivers, that uses this api has been updated
Acked-by: Marek Szyprowski
Reviewed-by: Andre Heider
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/platform/marvell-ccic/mcam-core.c| 14 +--
drivers/media/v4l2-core/videobuf2-dma-sg.c | 103
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 ++--
include/media/videobuf2-dma-sg.h | 10 +-
4 files changed, 63 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 64ab91e..0ac51bd 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1040,16 +1040,16 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
struct mcam_dma_desc *desc = mvb->dma_desc;
struct scatterlist *sg;
int i;
- mvb->dma_desc_nent = dma_map_sg(cam->dev, sgd->sglist, sgd->num_pages,
- DMA_FROM_DEVICE);
+ mvb->dma_desc_nent = dma_map_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
if (mvb->dma_desc_nent <= 0)
return -EIO; /* Not sure what's right here */
- for_each_sg(sgd->sglist, sg, mvb->dma_desc_nent, i) {
+ for_each_sg(sg_table->sgl, sg, mvb->dma_desc_nent, i) {
desc->dma_addr = sg_dma_address(sg);
desc->segment_len = sg_dma_len(sg);
desc++;
@@ -1060,9 +1060,11 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
static int mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
{
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
- dma_unmap_sg(cam->dev, sgd->sglist, sgd->num_pages, DMA_FROM_DEVICE);
+ if (sg_table)
+ dma_unmap_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
return 0;
}
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 4999c48..2f86054 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -35,7 +35,9 @@ struct vb2_dma_sg_buf {
struct page **pages;
int write;
int offset;
- struct vb2_dma_sg_desc sg_desc;
+ struct sg_table sg_table;
+ size_t size;
+ unsigned intnum_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -46,7 +48,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
gfp_t gfp_flags)
{
unsigned int last_page = 0;
- int size = buf->sg_desc.size;
+ int size = buf->size;
while (size > 0) {
struct page *pages;
@@ -74,12 +76,8 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
}
split_page(pages, order);
- for (i = 0; i < (1 << order); i++) {
- buf->pages[last_page] = &pages[i];
- sg_set_page(&buf->sg_desc.sglist[last_page],
- buf->pages[last_page], PAGE_SIZE, 0);
- last_page++;
- }
+ for (i = 0; i < (1 << order); i++)
+ buf->pages[last_page++] = &pages[i];
size -= PAGE_SIZE << order;
}
@@ -91,6 +89,7 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
{
struct vb2_dma_sg_buf *buf;
int ret;
+ int num_pages;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -99,17 +98,11 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
buf->vaddr = NULL;
buf->write = 0;
buf->offset = 0;
- buf->sg_desc.size = size;
+ buf->size = size;
/* size is already page aligned */
- buf->sg_desc.num_pages = size >> PAGE_SHIFT;
-
- buf->sg_desc.sglist = vzalloc(bu
[PATCH v4 0/2] videobuf2-dma-sg: Contiguos memory allocation
Allocate memory as contiguos as possible to support dma engines with limitated amount of sg-descriptors. Replace private structer vb2_dma_sg_desc with generic struct sg_table. PS: This series of patches is the evolution of my previous patch for vb2-dma-sg to allocate the memory as contiguos as possible. v4: Constains feedback from Andre Heider Andre: spelling, spaces around << and &pages v3: Constains feedback from Andre Heider Andre: Fix error handling (--pages) was wrongly fixed v2: Contains feedback from Andre Heider and Sylwester Nawrocki Andre: Fix error handling (--pages) Sylwester: Squash p3 and p4 into p2 Ricardo Ribalda Delgado (2): videobuf2-dma-sg: Allocate pages as contiguous as possible videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table drivers/media/platform/marvell-ccic/mcam-core.c| 14 +- drivers/media/v4l2-core/videobuf2-dma-sg.c | 149 +++- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 +-- include/media/videobuf2-dma-sg.h | 10 +- 4 files changed, 105 insertions(+), 88 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Thanks, I have just send a new version.
Regards!
On Fri, Aug 2, 2013 at 3:47 PM, Andre Heider wrote:
> Hi Ricardo,
>
> I messed up one thing in my initial reply, sorry :(
>
> And two additional nitpicks, while we're at it.
>
> On Fri, Jul 19, 2013 at 07:02:33PM +0200, Ricardo Ribalda Delgado wrote:
>> Most DMA engines have limitations regarding the number of DMA segments
>> (sg-buffers) that they can handle. Videobuffers can easily spread
>> through houndreds of pages.
>>
>> In the previous aproach, the pages were allocated individually, this
>> could led to the creation houndreds of dma segments (sg-buffers) that
>> could not be handled by some DMA engines.
>
> s/houndreds/hundreds/
>
>>
>> This patch tries to minimize the number of DMA segments by using
>> alloc_pages. In the worst case it will behave as before, but most
>> of the times it will reduce the number of dma segments
>>
>> Signed-off-by: Ricardo Ribalda Delgado
>
> With those changes you can add:
>
> Reviewed-by: Andre Heider
>
>> ---
>> drivers/media/v4l2-core/videobuf2-dma-sg.c | 60
>> +++-
>> 1 file changed, 49 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> index 16ae3dc..c053605 100644
>> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>> @@ -42,10 +42,55 @@ struct vb2_dma_sg_buf {
>>
>> static void vb2_dma_sg_put(void *buf_priv);
>>
>> +static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
>> + gfp_t gfp_flags)
>> +{
>> + unsigned int last_page = 0;
>> + int size = buf->sg_desc.size;
>> +
>> + while (size > 0) {
>> + struct page *pages;
>> + int order;
>> + int i;
>> +
>> + order = get_order(size);
>> + /* Dont over allocate*/
>> + if ((PAGE_SIZE << order) > size)
>> + order--;
>> +
>> + pages = NULL;
>> + while (!pages) {
>> + pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
>> + __GFP_NOWARN | gfp_flags, order);
>> + if (pages)
>> + break;
>> +
>> + if (order == 0)
>> + while (last_page--) {
>> + __free_page(buf->pages[last_page]);
>> + return -ENOMEM;
>> + }
>> + order--;
>> + }
>> +
>> + split_page(pages, order);
>> + for (i = 0; i < (1<
> whitespace nit: "(1 << order)"
>
>> + buf->pages[last_page] = pages[i];
>
> My fault, it should read:
>
> buf->pages[last_page] = &pages[i];
>
>> + sg_set_page(&buf->sg_desc.sglist[last_page],
>> + buf->pages[last_page], PAGE_SIZE, 0);
>> + last_page++;
>> + }
>> +
>> + size -= PAGE_SIZE << order;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
>> gfp_flags)
>> {
>> struct vb2_dma_sg_buf *buf;
>> - int i;
>> + int ret;
>>
>> buf = kzalloc(sizeof *buf, GFP_KERNEL);
>> if (!buf)
>> @@ -69,14 +114,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
>> long size, gfp_t gfp_fla
>> if (!buf->pages)
>> goto fail_pages_array_alloc;
>>
>> - for (i = 0; i < buf->sg_desc.num_pages; ++i) {
>> - buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
>> -__GFP_NOWARN | gfp_flags);
>> - if (NULL == buf->pages[i])
>> - goto fail_pages_alloc;
>> - sg_set_page(&buf->sg_desc.sglist[i],
>> - buf->pages[i], PAGE_SIZE, 0);
>> - }
>> + ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
>> + if (ret)
>> + goto fail_pages_alloc;
>>
>> buf->handler.refcount = &buf->refcount;
>> buf->handler.put = vb2_dma_sg_put;
>> @@ -89,8 +129,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
>> long size, gfp_t gfp_fla
>> return buf;
>>
>> fail_pages_alloc:
>> - while (--i >= 0)
>> - __free_page(buf->pages[i]);
>> kfree(buf->pages);
>>
>> fail_pages_array_alloc:
>> --
>> 1.7.10.4
>>
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] libv4lconvert: Support for Y16 pixel format
This patch adds support for V4L2_PIX_FMT_Y16 format.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |6 ++
lib/libv4lconvert/libv4lconvert.c | 19 +++
lib/libv4lconvert/rgbyuv.c | 30 ++
3 files changed, 55 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index c37e220..6422fdd 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -152,6 +152,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 60010f1..bc5e34f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
+ { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
}
+ case V4L2_PIX_FMT_Y16:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y16_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y16_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size < (width * height * 2)) {
+ V4LCONVERT_ERR("short y16 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y4:
case V4L2_PIX_FMT_Y6:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index d05abe9..bef034f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char *src,
unsigned char *dest,
}
}
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height >= 0) {
+ for (j = 0; j < width; j++) {
+ *dest++ = *src;
+ *dest++ = *src;
+ *dest++ = *src;
+ src+=2;
+ }
+ }
+}
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt)
+{
+ int x, y;
+
+ /* Y */
+ for (y = 0; y < src_fmt->fmt.pix.height; y++)
+ for (x = 0; x < src_fmt->fmt.pix.width; x++){
+ *dest++ = *src;
+ src+=2;
+ }
+
+ /* Clear U/V */
+ memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
2);
+}
+
void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add support for V4L2_PIX_FMT_Y16, V4L2_PIX_FMT_RGB32 and V4L2_PIX_FMT_BGR32
This patch adds support for 3 new formats. v2: Includes feedback from Gregor Jasny Gregor: Replaces rbg32 flag with bytesperpixes Ricardo Ribalda Delgado (2): libv4lconvert: Support for Y16 pixel format libv4lconvert: Support for RGB32 and BGR32 format lib/libv4lconvert/libv4lconvert-priv.h | 11 - lib/libv4lconvert/libv4lconvert.c | 77 +--- lib/libv4lconvert/rgbyuv.c | 75 ++- 3 files changed, 145 insertions(+), 18 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] libv4lconvert: Support for RGB32 and BGR32 format
This patch adds support for V4L2_PIX_FMT_BGR32 and V4L2_PIX_FMT_BGR32
formats.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |5 ++-
lib/libv4lconvert/libv4lconvert.c | 58
lib/libv4lconvert/rgbyuv.c | 45 +++--
3 files changed, 90 insertions(+), 18 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 6422fdd..ac1391e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -108,7 +108,7 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
int v4lconvert_oom_error(struct v4lconvert_data *data);
void v4lconvert_rgb24_to_yuv420(const unsigned char *src, unsigned char *dest,
- const struct v4l2_format *src_fmt, int bgr, int yvu);
+ const struct v4l2_format *src_fmt, int bgr, int yvu, int bpp);
void v4lconvert_yuv420_to_rgb24(const unsigned char *src, unsigned char *dst,
int width, int height, int yvu);
@@ -158,6 +158,9 @@ void v4lconvert_y16_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_rgb32_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index bc5e34f..2aec99a 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -84,6 +84,8 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[]
= {
SUPPORTED_DST_PIXFMTS,
/* packed rgb formats */
{ V4L2_PIX_FMT_RGB565, 16, 4, 6, 0 },
+ { V4L2_PIX_FMT_BGR32, 32, 4, 6, 0 },
+ { V4L2_PIX_FMT_RGB32, 32, 4, 6, 0 },
/* yuv 4:2:2 formats */
{ V4L2_PIX_FMT_YUYV,16, 5, 4, 0 },
{ V4L2_PIX_FMT_YVYU,16, 5, 4, 0 },
@@ -981,10 +983,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(d, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0, 3);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1, 3);
break;
}
break;
@@ -1079,10 +1081,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0, 3);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1, 3);
break;
}
if (src_size < (width * height * 3)) {
@@ -1101,10 +1103,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
memcpy(dest, src, width * height * 3);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0, 3);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1, 3);
break;
}
if (src_size < (width * height * 3)) {
@@ -1114,6 +1116,50 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ case V4L2_PIX_FMT_RGB32:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 1);
+ break;
+ case V4L2_PIX_FMT_
Re: [PATCH 2/2] libv4lconvert: Support for RGB32 and BGR32 format
Hello Gregor Totally agree, I have just uploaded a new set. Thanks! On Sat, Aug 3, 2013 at 12:15 AM, Gregor Jasny wrote: > Hello, > > > On 8/1/13 3:04 PM, Ricardo Ribalda Delgado wrote: >> >> --- a/lib/libv4lconvert/libv4lconvert-priv.h >> +++ b/lib/libv4lconvert/libv4lconvert-priv.h >> @@ -108,7 +108,7 @@ unsigned char *v4lconvert_alloc_buffer(int needed, >> int v4lconvert_oom_error(struct v4lconvert_data *data); >> >> void v4lconvert_rgb24_to_yuv420(const unsigned char *src, unsigned char >> *dest, >> - const struct v4l2_format *src_fmt, int bgr, int yvu); >> + const struct v4l2_format *src_fmt, int bgr, int yvu, int >> rgb32); >> >> void v4lconvert_yuv420_to_rgb24(const unsigned char *src, unsigned char >> *dst, >> int width, int height, int yvu); > > >> @@ -47,9 +47,15 @@ void v4lconvert_rgb24_to_yuv420(const unsigned char >> *src, unsigned char *dest, >> RGB2Y(src[2], src[1], src[0], *dest++); >> else >> RGB2Y(src[0], src[1], src[2], *dest++); >> - src += 3; >> + if (rgb32) >> + src += 4; >> + else >> + src += 3; > > > Instead of passing a 0/1 flag here I would call this variable bits_per_pixel > or bpp and pass 3 or 4 here. This would reduce the if condition ugliness. > > Thanks, > Gregor > -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] libv4lconvert: Support for RGB32 and BGR32 format
Hello Gregor
Thanks for your comments. I have replied inline.
On Sat, Aug 3, 2013 at 6:42 PM, Gregor Jasny wrote:
> On 8/3/13 12:42 AM, Ricardo Ribalda Delgado wrote:
>>
>> + case V4L2_PIX_FMT_RGB32:
>> + switch (dest_pix_fmt) {
>> + case V4L2_PIX_FMT_RGB24:
>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>> height, 0);
>> + break;
>> + case V4L2_PIX_FMT_BGR24:
>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>> height, 1);
>> + break;
>> + case V4L2_PIX_FMT_YUV420:
>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0,
>> 4);
>> + break;
>> + case V4L2_PIX_FMT_YVU420:
>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1,
>> 4);
>> + break;
>> + }
>> + if (src_size < (width * height * 4)) {
>> + V4LCONVERT_ERR("short rgb32 data frame\n");
>> + errno = EPIPE;
>> + result = -1;
>> + }
>> + break;
>
>
> I have not looked at the whole function but shouldn't this sanity check
> happen before the actual work?
Yes, but it is how it is done in the whole library with all the
formats. Please grep for "short " on libv4lconvert.c
> Also aren't you applying the condition here
> also for rgb24_to_xxx which should have only three bpp?
>
I have modified the function rgb24_to_yuv420 to support other bytes per pixel.
>
>> + case V4L2_PIX_FMT_BGR32:
>> + switch (dest_pix_fmt) {
>> + case V4L2_PIX_FMT_RGB24:
>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>> height, 1);
>> + break;
>> + case V4L2_PIX_FMT_BGR24:
>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>> height, 0);
>> + break;
>> + case V4L2_PIX_FMT_YUV420:
>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0,
>> 4);
>> + break;
>> + case V4L2_PIX_FMT_YVU420:
>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1,
>> 4);
>> + break;
>> + }
>> + if (src_size < (width * height * 4)) {
>> + V4LCONVERT_ERR("short bgr32 data frame\n");
>> + errno = EPIPE;
>> + result = -1;
>> + }
>> + break;
>
>
> Same here. And also in the other patch.
>
>
Thanks again
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] libv4lconvert: Support for RGB32 and BGR32 format
ping?
On Sun, Aug 4, 2013 at 10:05 AM, Ricardo Ribalda Delgado
wrote:
> Hello Gregor
>
> Thanks for your comments. I have replied inline.
>
> On Sat, Aug 3, 2013 at 6:42 PM, Gregor Jasny wrote:
>> On 8/3/13 12:42 AM, Ricardo Ribalda Delgado wrote:
>>>
>>> + case V4L2_PIX_FMT_RGB32:
>>> + switch (dest_pix_fmt) {
>>> + case V4L2_PIX_FMT_RGB24:
>>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>>> height, 0);
>>> + break;
>>> + case V4L2_PIX_FMT_BGR24:
>>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>>> height, 1);
>>> + break;
>>> + case V4L2_PIX_FMT_YUV420:
>>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0,
>>> 4);
>>> + break;
>>> + case V4L2_PIX_FMT_YVU420:
>>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1,
>>> 4);
>>> + break;
>>> + }
>>> + if (src_size < (width * height * 4)) {
>>> + V4LCONVERT_ERR("short rgb32 data frame\n");
>>> + errno = EPIPE;
>>> + result = -1;
>>> + }
>>> + break;
>>
>>
>> I have not looked at the whole function but shouldn't this sanity check
>> happen before the actual work?
>
> Yes, but it is how it is done in the whole library with all the
> formats. Please grep for "short " on libv4lconvert.c
>
>> Also aren't you applying the condition here
>> also for rgb24_to_xxx which should have only three bpp?
>>
>
> I have modified the function rgb24_to_yuv420 to support other bytes per pixel.
>
>>
>>> + case V4L2_PIX_FMT_BGR32:
>>> + switch (dest_pix_fmt) {
>>> + case V4L2_PIX_FMT_RGB24:
>>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>>> height, 1);
>>> + break;
>>> + case V4L2_PIX_FMT_BGR24:
>>> + v4lconvert_rgb32_to_rgb24(src, dest, width,
>>> height, 0);
>>> + break;
>>> + case V4L2_PIX_FMT_YUV420:
>>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0,
>>> 4);
>>> + break;
>>> + case V4L2_PIX_FMT_YVU420:
>>> + v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1,
>>> 4);
>>> + break;
>>> + }
>>> + if (src_size < (width * height * 4)) {
>>> + V4LCONVERT_ERR("short bgr32 data frame\n");
>>> + errno = EPIPE;
>>> + result = -1;
>>> + }
>>> + break;
>>
>>
>> Same here. And also in the other patch.
>>
>>
>
> Thanks again
>
> --
> Ricardo Ribalda
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] libv4lconvert: Support for Y16 pixel format
ping?
On Sat, Aug 3, 2013 at 12:42 AM, Ricardo Ribalda Delgado
wrote:
> This patch adds support for V4L2_PIX_FMT_Y16 format.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> lib/libv4lconvert/libv4lconvert-priv.h |6 ++
> lib/libv4lconvert/libv4lconvert.c | 19 +++
> lib/libv4lconvert/rgbyuv.c | 30 ++
> 3 files changed, 55 insertions(+)
>
> diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
> b/lib/libv4lconvert/libv4lconvert-priv.h
> index c37e220..6422fdd 100644
> --- a/lib/libv4lconvert/libv4lconvert-priv.h
> +++ b/lib/libv4lconvert/libv4lconvert-priv.h
> @@ -152,6 +152,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
> unsigned char *dest,
> void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
> const struct v4l2_format *src_fmt);
>
> +void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
> + int width, int height);
> +
> +void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
> + const struct v4l2_format *src_fmt);
> +
> int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
> const unsigned char *src, unsigned char *dest, int width, int height);
>
> diff --git a/lib/libv4lconvert/libv4lconvert.c
> b/lib/libv4lconvert/libv4lconvert.c
> index 60010f1..bc5e34f 100644
> --- a/lib/libv4lconvert/libv4lconvert.c
> +++ b/lib/libv4lconvert/libv4lconvert.c
> @@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
> supported_src_pixfmts[] = {
> { V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
> { V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
> { V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
> + { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
> };
>
> static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
> @@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
> v4lconvert_data *data,
> break;
> }
>
> + case V4L2_PIX_FMT_Y16:
> + switch (dest_pix_fmt) {
> + case V4L2_PIX_FMT_RGB24:
> + case V4L2_PIX_FMT_BGR24:
> + v4lconvert_y16_to_rgb24(src, dest, width, height);
> + break;
> + case V4L2_PIX_FMT_YUV420:
> + case V4L2_PIX_FMT_YVU420:
> + v4lconvert_y16_to_yuv420(src, dest, fmt);
> + break;
> + }
> + if (src_size < (width * height * 2)) {
> + V4LCONVERT_ERR("short y16 data frame\n");
> + errno = EPIPE;
> + result = -1;
> + }
> + break;
> +
> case V4L2_PIX_FMT_GREY:
> case V4L2_PIX_FMT_Y4:
> case V4L2_PIX_FMT_Y6:
> diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
> index d05abe9..bef034f 100644
> --- a/lib/libv4lconvert/rgbyuv.c
> +++ b/lib/libv4lconvert/rgbyuv.c
> @@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char
> *src, unsigned char *dest,
> }
> }
>
> +void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
> + int width, int height)
> +{
> + int j;
> + while (--height >= 0) {
> + for (j = 0; j < width; j++) {
> + *dest++ = *src;
> + *dest++ = *src;
> + *dest++ = *src;
> + src+=2;
> + }
> + }
> +}
> +
> +void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
> + const struct v4l2_format *src_fmt)
> +{
> + int x, y;
> +
> + /* Y */
> + for (y = 0; y < src_fmt->fmt.pix.height; y++)
> + for (x = 0; x < src_fmt->fmt.pix.width; x++){
> + *dest++ = *src;
> + src+=2;
> + }
> +
> + /* Clear U/V */
> + memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
> 2);
> +}
> +
> void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
> int width, int height)
> {
> --
> 1.7.10.4
>
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] libv4lconvert: Support for Y16 pixel format
Hello Gregor I am using some cameras from qtec.com. In fact, I am developing the firmware for them :) qv4l2 has been very useful for testing. Thanks for your response. On Mon, Aug 12, 2013 at 9:39 PM, Gregor Jasny wrote: > On 8/9/13 6:04 PM, Ricardo Ribalda Delgado wrote: >> >> ping? > > > Thank you for your the updated series. > > Unfortunately I'm still partially busy with moving. I hoped the v4lconvert > maintainer Hans (de Goede) will ack these patches. If this series does not > get an ack by Sunday I'll double check and commit. > > What hardware did you use to test this? > > Thanks, > Gregor -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2-dev: Fix race condition on __video_register_device
When 2 devices are registered at the same time, in Part 2 both will get the same minor number, making Part6 crash, because it cannot create a create a device with a duplicated minor: [7.157648] [ cut here ] [7.157666] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xbd/0xe0() [7.157669] sysfs: cannot create duplicate filename '/dev/char/81:1' [7.157672] Modules linked in: qtec_xform(+) qt5023_video(+) videobuf2_vmalloc videobuf2_dma_sg videobuf2_memops videobuf2_core gpio_xilinx(+) qtec_white qtec_cmosis(+) qtec_pcie qt5023 [7.157694] CPU: 0 PID: 120 Comm: systemd-udevd Not tainted 3.10.0-qtec-standard #8 [7.157698] Hardware name: QTechnology QT5022/QT5022, BIOS PM_2.1.0.309 X64 05/23/2013 [7.157702] 0009 8801788358e8 8176c487 880178835928 [7.157707] 8106f6f0 880175759770 ffef 880175759930 [7.157712] 8801788359e8 880178bff000 880175759930 880178835988 [7.157718] Call Trace: [7.157728] [] dump_stack+0x19/0x1b [7.157735] [] warn_slowpath_common+0x70/0xa0 [7.157740] [] warn_slowpath_fmt+0x46/0x50 [7.157746] [] ? strlcat+0x65/0x90 [7.157750] [] sysfs_add_one+0xbd/0xe0 [7.157755] [] sysfs_do_create_link_sd+0xdb/0x200 [7.157760] [] sysfs_create_link+0x21/0x40 [7.157765] [] device_add+0x21b/0x6d0 [7.157772] [] ? pm_runtime_init+0xe5/0xf0 [7.157776] [] device_register+0x1e/0x30 [7.157782] [] __video_register_device+0x313/0x610 [7.157791] [] qtec_xform_probe+0x465/0x7a4 [qtec_xform] [7.157797] [] platform_drv_probe+0x43/0x80 [7.157802] [] ? driver_sysfs_add+0x7a/0xb0 [7.157807] [] driver_probe_device+0x8b/0x3a0 [7.157812] [] __driver_attach+0xab/0xb0 [7.157816] [] ? driver_probe_device+0x3a0/0x3a0 [7.157820] [] bus_for_each_dev+0x5d/0xa0 [7.157825] [] driver_attach+0x1e/0x20 [7.157829] [] bus_add_driver+0x10e/0x280 [7.157833] [] ? 0xa0098fff [7.157837] [] ? 0xa0098fff [7.157842] [] driver_register+0x77/0x170 [7.157848] [] ? __vunmap+0x9c/0x110 [7.157852] [] ? 0xa0098fff [7.157857] [] platform_driver_register+0x46/0x50 [7.157863] [] qtec_xform_plat_driver_init+0x10/0x12 [qtec_xform] [7.157869] [] do_one_initcall+0xea/0x1a0 [7.157875] [] load_module+0x1a91/0x2630 [7.157880] [] ? ddebug_proc_show+0xe0/0xe0 [7.157887] [] ? page_fault+0x22/0x30 [7.157892] [] SyS_init_module+0xea/0x140 [7.157898] [] tracesys+0xd0/0xd5 [7.157902] ---[ end trace 660cc3a65a4bf01b ]--- [7.157939] __video_register_device: device_register failed Signed-off-by: Ricardo Ribalda Delgado --- drivers/media/v4l2-core/v4l2-dev.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index 5923c5d..3f75f99 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -873,6 +873,7 @@ int __video_register_device(struct video_device *vdev, int type, int nr, /* Should not happen since we thought this minor was free */ WARN_ON(video_device[vdev->minor] != NULL); + video_device[vdev->minor] = vdev; vdev->index = get_index(vdev); mutex_unlock(&videodev_lock); @@ -936,9 +937,6 @@ int __video_register_device(struct video_device *vdev, int type, int nr, #endif /* Part 6: Activate this minor. The char device can now be used. */ set_bit(V4L2_FL_REGISTERED, &vdev->flags); - mutex_lock(&videodev_lock); - video_device[vdev->minor] = vdev; - mutex_unlock(&videodev_lock); return 0; @@ -946,6 +944,7 @@ cleanup: mutex_lock(&videodev_lock); if (vdev->cdev) cdev_del(vdev->cdev); + video_device[vdev->minor] = NULL; devnode_clear(vdev); mutex_unlock(&videodev_lock); /* Mark this video device as never having been registered. */ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] videobuf2: Fix vb2_write prototype
struct v4_file_operations defines the data param as
const char __user *data but on vb2 is defined as
char __user *data.
This patch fixes the warnings produced by this. ie:
drivers/qtec/qtec_xform.c:817:2: warning: initialization from
incompatible pointer type [enabled by default]
drivers/qtec/qtec_xform.c:817:2: warning: (near initialization for
‘qtec_xform_v4l_fops.write’) [enabled by default]
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-core.c |7 ---
include/media/videobuf2-core.h |4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 9fc4bab..b3f86c1 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2438,10 +2438,11 @@ size_t vb2_read(struct vb2_queue *q, char __user *data,
size_t count,
}
EXPORT_SYMBOL_GPL(vb2_read);
-size_t vb2_write(struct vb2_queue *q, char __user *data, size_t count,
+size_t vb2_write(struct vb2_queue *q, const char __user *data, size_t count,
loff_t *ppos, int nonblocking)
{
- return __vb2_perform_fileio(q, data, count, ppos, nonblocking, 0);
+ return __vb2_perform_fileio(q, (char __user *) data, count,
+ ppos, nonblocking, 0);
}
EXPORT_SYMBOL_GPL(vb2_write);
@@ -2595,7 +2596,7 @@ int vb2_fop_release(struct file *file)
}
EXPORT_SYMBOL_GPL(vb2_fop_release);
-ssize_t vb2_fop_write(struct file *file, char __user *buf,
+ssize_t vb2_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
struct video_device *vdev = video_devdata(file);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index d88a098..06ec850 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -388,7 +388,7 @@ unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table
*wait);
size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count,
loff_t *ppos, int nonblock);
-size_t vb2_write(struct vb2_queue *q, char __user *data, size_t count,
+size_t vb2_write(struct vb2_queue *q, const char __user *data, size_t count,
loff_t *ppos, int nonblock);
/**
@@ -488,7 +488,7 @@ int vb2_ioctl_expbuf(struct file *file, void *priv,
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma);
int vb2_fop_release(struct file *file);
-ssize_t vb2_fop_write(struct file *file, char __user *buf,
+ssize_t vb2_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos);
ssize_t vb2_fop_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC> multi-crop (was: Multiple Rectangle cropping)
Hello I am working porting a industrial camera driver to v4l. So far I have been able to describe most of the old functionality with v4l equivalents. The only thing that I am missing is multi cropping. The sensor (both a cmosis and a ccd chips) supports skipping lines from up to 8 regions. This increases the readout speed up to 50%, which is critical for the application. Unfortunately I have no way to describe multiple cropping areas in v4l. I am thinking about creating a new API/extending and old one for this. Any suggestion before I start? Have you faced also this problem? How did you solve it? I am planning to go to the Edinburgh mini summit, maybe we could add this to the agenda (if you consider that it is worth the time, of course) Thanks -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC> multi-crop (was: Multiple Rectangle cropping)
Hi Sylvester
Thanks for your response
Unfortunately, the v4l2_crop dont have any reserved field :(
struct v4l2_crop {
__u32 type; /* enum v4l2_buf_type */
struct v4l2_rectc;
};
And changing that ABI I dont think is an option.
What about a new call: G/S_READOUT .that uses a modified
v4l2_selection as you propose?
That call selects the readable areas from the sensor.
The new structure could be something like:
#define SELECTION_BITMAP 0x
#define SELECTION_RESET 0xfffe
#define SELECTION_MAX_AREAS 32
struct v4l2_selection {
__u32 type;
__u32 target;
__u32 flags;
union {
struct v4l2_rectr;
__u32 bitmap;
};
__u32 n;
__u32 reserved[8];
};
n chooses the readout area to choose, up to 32.
When n is == 0x the user wants to change the bitmap that
selects which areas are enabled.
When the bitmap is 0x0 all the sensor is read.
When the bitmap is 0x5 the readout area 0 and 2 are enabled.
When the bitmap is set to a value !=0, the driver checks if the
combination of readout areas is supported by the sensor/readout logic
and returns -EINVAL if not.
The g/s_crop API still works as usual.
Any comment on this? Of course the names should be better chosen, this
is just a declaration of intentions.
Cheers!
On Thu, Sep 5, 2013 at 11:44 PM, Sylwester Nawrocki
wrote:
> On 09/05/2013 11:10 PM, Ricardo Ribalda Delgado wrote:
>>
>> Hello
>
>
> Hi,
>
>
>> I am working porting a industrial camera driver to v4l. So far I have
>> been able to describe most of the old functionality with v4l
>> equivalents. The only thing that I am missing is multi cropping.
>>
>> The sensor (both a cmosis and a ccd chips) supports skipping lines
>> from up to 8 regions. This increases the readout speed up to 50%,
>> which is critical for the application.
>>
>> Unfortunately I have no way to describe multiple cropping areas in
>> v4l. I am thinking about creating a new API/extending and old one for
>> this.
>>
>> Any suggestion before I start? Have you faced also this problem? How
>> did you solve it?
>
>
> A similar issue has been raised during discussions on the camera auto
> focus rectangle selection API. While defining need selection targets [1]
> it was also proposed to convert one of the struct v4l2_selection reserved
> fields into an index field, which would indicate one rectangle of some
> set of rectangles supported by a driver. Then there could be a v4l2
> bitmask control to determine which rectangles are currently valid/in use.
>
> Would something like this be relevant to your problem ?
>
>
>> I am planning to go to the Edinburgh mini summit, maybe we could add
>> this to the agenda (if you consider that it is worth the time, of
>> course)
>
>
> It definitely sounds like a good topic to discuss at the mini summit,
> unless it gets resolved until then. ;-)
>
> [1] http://www.spinics.net/lists/linux-media/msg64499.html
>
> --
> Regards,
> Sylwester
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
videobuf2: V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_OUTPUT at the same time?
Hello! I am writing the driver for a device that can work as an input and as output at the same time. It is used for debugging of the video pipeline. Is it possible to have a vb2 queue that supports capture and out at the same time? After a fast look on the code it seems that the code flow is different depending of the type. if (V4L2_TYPE_IS_OUTPUT()) :( Also it seems that struct video device has only space for one vb2_queue, so I cant create a video device with two vbuf2 queues. So is there any way to have a video device with videobuf2 that supports caputer and output? Thanks! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC> multi-crop
Hello
Thanks for your comments
On Wed, Sep 11, 2013 at 12:05 AM, Sylwester Nawrocki
wrote:
> Hi All,
>
> On 09/10/2013 11:41 PM, Sakari Ailus wrote:
>>
>> Hi Ricardo,
>>
>> On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote:
>>>
>>> Hi Sylvester
>>>
>>> Thanks for your response
>>>
>>> Unfortunately, the v4l2_crop dont have any reserved field :(
>>
>>
>> Don't worry about v4lw_crop. we have selections now. :-)
>
>
> True, I belive no possibility of extending struct v4l2_crop was one of
> the reasons why the selections API has benn introduced. The selections
> API provides superset of functionality of the original cropping API and
> G/S_CROP/CROPCAP ioctls should be considered deprecated.
>
We should update the doc to tell the user that the crop api will be
superseded soon by the selection api.
>>> struct v4l2_crop {
>>> __u32 type; /* enum v4l2_buf_type */
>>> struct v4l2_rectc;
>>> };
>>>
>>> And changing that ABI I dont think is an option.
>>>
>>> What about a new call: G/S_READOUT .that uses a modified
>>> v4l2_selection as you propose?
>>
>>
>> Could this functionality be added to the ex$sting selection API, with a
>> possible extension in a for of a new field, say, "id" to tell which one is
>> being changed?
>
>
> +1, that was my idea as well.
>
This looks like the right way to do it. I only see an issue. Lets say
we have a hw that needs all the selection to have the same width.
The user creates selection 0, 1 and 2 with width 100. Now he wants
them to be 200 witdh.
He changes selection 0, but because the driver returns -EINVAL (or
resizes the selection to 100, to fit the old selections).
So the user cannot change the size anymore :(
>>> That call selects the readable areas from the sensor.
>>>
>>> The new structure could be something like:
>>>
>>> #define SELECTION_BITMAP 0x
>>> #define SELECTION_RESET 0xfffe
>>> #define SELECTION_MAX_AREAS 32
>>> struct v4l2_selection {
>>> __u32 type;
>>> __u32 target;
>>> __u32 flags;
>>> union {
>>> struct v4l2_rectr;
>>> __u32 bitmap;
>>> };
>>> __u32 n;
>>> __u32 reserved[8];
>>> };
>>>
>>> n chooses the readout area to choose, up to 32.
>>>
>>> When n is == 0x the user wants to change the bitmap that
>>> selects which areas are enabled.
>>>When the bitmap is 0x0 all the sensor is read.
>>>When the bitmap is 0x5 the readout area 0 and 2 are enabled.
>>>
>>> When the bitmap is set to a value !=0, the driver checks if the
>>> combination of readout areas is supported by the sensor/readout logic
>>> and returns -EINVAL if not.
>
>
> Would the supported combinations vary at run-time, depending on some
> configuration parameters. Or would it be rather fixed and known at device
> initialization time ?
>
The combinations vary at runtime, depending on the size and what the
user wants to readout.
>>> The g/s_crop API still works as usual.
>>>
>>> Any comment on this? Of course the names should be better chosen, this
>>> is just a declaration of intentions.
>>
>>
>> I think the functionality you're describing is highly peculiar. I have to
>> say that, as Sylwester noted, it bears resemblance to the AF windows so
>> the
>> solution could be same as well.
>>
>> I think earlier on (say perhaps a year and a half) ago it was proposed to
>> use bitmask controls with selections to tell which IDs are valid. What
>> would
>> you think about that?
>
>
> My feelings are that using a bitmask control to select sub-windows would
> be far more flexible than embedding the mask field in struct v4l2_selection.
> If there is more than 32 windows needed the control API could be extended,
> at least for up to 64-bit it seems not a big deal.
> And an "id" member of struct v4l2_selection would be generic and could be
> used for other purposes as well.
I agree here too.
>
>> It's also always possible to use private controls, too.
>
>
> --
> Regards,
> Sylwester
Thanks for your comments
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC> multi-crop (was: Multiple Rectangle cropping)
Hello Sakari On Wed, Sep 11, 2013 at 12:35 AM, Sakari Ailus wrote: > Hi Ricardo, > > On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote: >> Any comment on this? Of course the names should be better chosen, this >> is just a declaration of intentions. > > I forgot to ask one question: what's the behaviour of cropping on different > regions? Are the regions located on particular line or what? The purpose of this is to increase the framerate on high speed cameras. Lets say you are controlling the speed on a highway. You have a camera looking at the road. The fps will determine the accuracy of your meassurement. If you could skip the reservation between both lanes you could increase the fps. Also imaging a high speed ballistics camera. You have a reference plate on rows 1-10, and you are studing a sample on rows 400-500. You dont want to read rows 11-399, because you will reduce your framerate Finally If you have an scenario where you want to process a specific part of the image at 1mm per pixel and the rest at 10mm per pixel. > > Contrary to the case with AF rectaangles, I see fewer possibilities for > standardising the behaviour of multiple crop rectanges which decreases the > value of a generic interface: even if the interface is generic but you have > no idea what it'd actually do you wouldn't gain much. > > For this reason it might also make sense to use a private IOCTL (and not a > control) to support the functionality. Or private selections (which we don't > have yet). I like the idea of adding an id field to the selection api, and then a private control with a bitmask selection with selections are active. If we can agree on the value of this we could define a standard control. If not, we leave the door open to the drivers to define their own. Thanks for you feedback! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RFC: Support for multiple selections
A new id field is added to the struct selection. On devices that
supports multiple sections this id indicate which of the selection to
modify.
A new control V4L2_CID_SELECTION_BITMASK selects which of the selections
are used, if the control is set to zero the default rectangles are used.
This is needed in cases where the user has to change multiple selections
at the same time to get a valid combination.
On devices where the control V4L2_CID_SELECTION_BITMASK does not exist,
the id field is ignored
Signed-off-by: Ricardo Ribalda Delgado
---
Documentation/DocBook/media/v4l/controls.xml | 6 ++
drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 4 ++--
include/uapi/linux/v4l2-controls.h | 4 +++-
include/uapi/linux/videodev2.h | 5 -
5 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index c2fc9ec..a8c84bb 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -338,6 +338,12 @@ minimum value disables backlight compensation.
coefficients determined by
V4L2_CID_COLORFX_CBCR
control.
+
+
V4L2_CID_SELECTION_BITMASK
+ For drivers that support multiple selections. This
control
+ determine which selections are enabled. If it is set to zero
the default
+ crop and compose rectangle are used.
+
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index fccd08b..fa3bfc2 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -599,6 +599,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return "Min Number of Output
Buffers";
case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
case V4L2_CID_COLORFX_CBCR: return "Color Effects, CbCr";
+ case V4L2_CID_SELECTION_BITMASK:return "Selection Bitmask";
/* MPEG controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -957,6 +958,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DV_TX_RXSENSE:
case V4L2_CID_DV_TX_EDID_PRESENT:
case V4L2_CID_DV_RX_POWER_PRESENT:
+ case V4L2_CID_SELECTION_BITMASK:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e6b5e..ca177bb 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -573,9 +573,9 @@ static void v4l_print_selection(const void *arg, bool
write_only)
{
const struct v4l2_selection *p = arg;
- pr_cont("type=%s, target=%d, flags=0x%x, wxh=%dx%d, x,y=%d,%d\n",
+ pr_cont("type=%s, target=%d, flags=0x%x, id=%d,wxh=%dx%d, x,y=%d,%d\n",
prt_names(p->type, v4l2_type_names),
- p->target, p->flags,
+ p->target, p->flags, p->id,
p->r.width, p->r.height, p->r.left, p->r.top);
}
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index e90a88a..ca44338 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -138,8 +138,10 @@ enum v4l2_colorfx {
#define V4L2_CID_ALPHA_COMPONENT (V4L2_CID_BASE+41)
#define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
+#define V4L2_CID_SELECTION_BITMASK (V4L2_CID_BASE+43)
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+43)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
/* USER-class private control IDs */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 0e80472..4f68196 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -806,6 +806,8 @@ struct v4l2_crop {
* @target:Selection target, used to choose one of possible rectangles;
* defined in v4l2-common.h; V4L2_SEL_TGT_* .
* @flags: constraints flags, defined in v4l2-common.h; V4L2_SEL_FLAG_*.
+ * @id:Selection to change, for devices that supports multiple,
+ * set to zero otherwise.
* @r: coordinates of selection window
* @reserved: for future use, rounds structure size to 64 bytes, set to zero
*
@@ -818,7 +820,8 @@ struct v4l2_selection {
__u32 target;
__u32 flags;
struct v4l2_rect
Re: [PATCH] RFC: Support for multiple selections
Hi Hans
Thanks for your feedback
On Wed, Sep 11, 2013 at 11:04 AM, Hans Verkuil wrote:
> Hi Ricardo,
>
> On 09/11/2013 10:30 AM, Ricardo Ribalda Delgado wrote:
>> A new id field is added to the struct selection. On devices that
>> supports multiple sections this id indicate which of the selection to
>> modify.
>>
>> A new control V4L2_CID_SELECTION_BITMASK selects which of the selections
>> are used, if the control is set to zero the default rectangles are used.
>>
>> This is needed in cases where the user has to change multiple selections
>> at the same time to get a valid combination.
>>
>> On devices where the control V4L2_CID_SELECTION_BITMASK does not exist,
>> the id field is ignored
>
> This feels like a hack to me. A big problem I have with using a control here
> is that with a control you can't specify for which selection target it is.
>
I am not sure that I understand what you mean here.
If you set the control to 0x1 you are using selection 0, if you set
the control to 0x5, you are using selection 0 and 2.
> If you want to set multiple rectangles, why not just pass them directly? E.g.:
>
> struct v4l2_selection {
> __u32 type;
> __u32 target;
> __u32 flags;
> union {
> struct v4l2_rectr;
> struct v4l2_rect*pr;
> };
> __u32 rectangles;
> __u32 reserved[8];
> };
>
> If rectangles > 1, then pr is used.
>
The structure is passed in a ioctl and I dont think that it is a good
idea that you let the kernel get/set a memory address not encapsulated
in it. I can see that it could lead to security breaches if there is a
mistake on the handling.
> It's a bit more work to add this to the core code (VIDIOC_SUBDEV_G/S_SELECTION
> should probably be changed at the same time and you have to fix existing
> drivers
> to check/set the new rectangles field), but it scales much better.
Also, we would be broking the ABI. Rectangles is not a mandatory
field, and has a value != 0.
What we could do is leave the V4L2_CID_SELECTION_BITMASK out of the
api, but keep the id field on the structure, so the user can define a
private control to do whatever he needs with the id field, wekeep the
ABI compatibility and no big changes are needed.
Thaks!
>
> Regards,
>
> Hans
>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: Support for multiple selections
Hello Hans
On Wed, Sep 11, 2013 at 12:49 PM, Hans Verkuil wrote:
> Hi Ricardo,
>
> On 09/11/2013 11:34 AM, Ricardo Ribalda Delgado wrote:
>> Hi Hans
>>
>> Thanks for your feedback
>>
>> On Wed, Sep 11, 2013 at 11:04 AM, Hans Verkuil wrote:
>>> Hi Ricardo,
>>>
>>> On 09/11/2013 10:30 AM, Ricardo Ribalda Delgado wrote:
>>>> A new id field is added to the struct selection. On devices that
>>>> supports multiple sections this id indicate which of the selection to
>>>> modify.
>>>>
>>>> A new control V4L2_CID_SELECTION_BITMASK selects which of the selections
>>>> are used, if the control is set to zero the default rectangles are used.
>>>>
>>>> This is needed in cases where the user has to change multiple selections
>>>> at the same time to get a valid combination.
>>>>
>>>> On devices where the control V4L2_CID_SELECTION_BITMASK does not exist,
>>>> the id field is ignored
>>>
>>> This feels like a hack to me. A big problem I have with using a control here
>>> is that with a control you can't specify for which selection target it is.
>>>
>>
>> I am not sure that I understand what you mean here.
>>
>> If you set the control to 0x1 you are using selection 0, if you set
>> the control to 0x5, you are using selection 0 and 2.
>
> If you look here:
>
> http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-selection-targets
>
> you see that a selection has a 'target': i.e. does the selection define a crop
> rectangle, a compose rectange, a default crop rectangle, etc.
>
> You are extending the API to support multiple rectangles per target and using
> a control to select which rectangles are active (if I understand correctly).
> But that control does not (and cannot) specify for which target the rectangles
> should be activated.
I want to have N crop rectangles and N compose rectangles. Every crop
rectangle has associated one compose rectangle.
This will fit multiple purposes ie:
- swap two areas of an image,
- multiple readout zones
- different decimation per area
>
>>
>>
>>> If you want to set multiple rectangles, why not just pass them directly?
>>> E.g.:
>>>
>>> struct v4l2_selection {
>>> __u32 type;
>>> __u32 target;
>>> __u32 flags;
>>> union {
>>> struct v4l2_rectr;
>>> struct v4l2_rect*pr;
>>> };
>>> __u32 rectangles;
>>> __u32 reserved[8];
>>> };
>>>
>>> If rectangles > 1, then pr is used.
>>>
>>
>> The structure is passed in a ioctl and I dont think that it is a good
>> idea that you let the kernel get/set a memory address not encapsulated
>> in it. I can see that it could lead to security breaches if there is a
>> mistake on the handling.
>
> It's used in lots of places. It's OK, provided you check the memory carefully.
> See e.g. how VIDIOC_G/S_EXT_CTRLS is handled. Usually the memory checks are
> done
> in the v4l2 core and the driver doesn't need to take care of it.
>
I agree IFF the v4l2 core does the checks. One question raises me: how
does the user knows how big is the structure he has to allocate for
g_selection? Do we have to make a new ioctl g_n_selections?
>>> It's a bit more work to add this to the core code
>>> (VIDIOC_SUBDEV_G/S_SELECTION
>>> should probably be changed at the same time and you have to fix existing
>>> drivers
>>> to check/set the new rectangles field), but it scales much better.
>>
>> Also, we would be broking the ABI. Rectangles is not a mandatory
>> field, and has a value != 0.
>
> The spec clearly states that:
>
> "The flags and reserved fields of struct v4l2_selection are ignored and they
> must
> be filled with zeros."
>
> Any app not doing that is not obeying the API and hence it is an application
> bug.
>
> It's standard practice inside the V4L2 API to handle reserved fields in that
> way,
> as it provides a mechanism to extend the API safely in the future.
>
That is what I mean, the current programs are writing a 0 on that
field, but now they are required to write a 1, so the API is broken.
Maybe we should describe:
if rectangles is 0, the field r is used (legacy), otherwise the pr,
even for 1 (multi rectangle).
>>
>> What we could do is leave the V4L2_CID_SELECTION_BI
[PATCH] RFCv2: Support for multiple selections
Extend v4l2 selection API to support multiple selection areas, this way
sensors that support multiple readout areas can work with multiple areas
of insterest.
The struct v4l2_selection and v4l2_subdev_selection has been extented
with a new field rectangles. If it is value is different than zero the
pr array is used instead of the r field.
A new structure v4l2_ext_rect has been defined, containing 4 reserved
fields for future improvements, as suggested by Hans.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/v4l2-ioctl.c | 54 +++-
include/uapi/linux/v4l2-subdev.h | 10 +--
include/uapi/linux/videodev2.h | 15 --
3 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e6b5e..91d21a4 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -572,11 +572,22 @@ static void v4l_print_crop(const void *arg, bool
write_only)
static void v4l_print_selection(const void *arg, bool write_only)
{
const struct v4l2_selection *p = arg;
+ int i;
- pr_cont("type=%s, target=%d, flags=0x%x, wxh=%dx%d, x,y=%d,%d\n",
- prt_names(p->type, v4l2_type_names),
- p->target, p->flags,
- p->r.width, p->r.height, p->r.left, p->r.top);
+ if (p->rectangles==0)
+ pr_cont("type=%s, target=%d, flags=0x%x, wxh=%dx%d"
+ ", x,y=%d,%d\n",
+ prt_names(p->type, v4l2_type_names),
+ p->target, p->flags,
+ p->r.width, p->r.height, p->r.left, p->r.top);
+ else{
+ pr_cont("type=%s, target=%d, flags=0x%x\n",
+ prt_names(p->type, v4l2_type_names),
+ p->target, p->flags);
+ for (i=0; irectangles;i++)
+ pr_cont("rectangle %d: wxh=%dx%d, x,y=%d,%d\n",
+ i, p->r.width, p->r.height, p->r.left,
p->r.top);
+ }
}
static void v4l_print_jpegcompression(const void *arg, bool write_only)
@@ -1645,6 +1656,7 @@ static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
struct v4l2_crop *p = arg;
struct v4l2_selection s = {
.type = p->type,
+ .rectangles = 0,
};
int ret;
@@ -1673,6 +1685,7 @@ static int v4l_s_crop(const struct v4l2_ioctl_ops *ops,
struct v4l2_selection s = {
.type = p->type,
.r = p->c,
+ .rectangles = 0,
};
if (ops->vidioc_s_crop)
@@ -1692,7 +1705,10 @@ static int v4l_cropcap(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
struct v4l2_cropcap *p = arg;
- struct v4l2_selection s = { .type = p->type };
+ struct v4l2_selection s = {
+ .type = p->type,
+ .rectangles = 0,
+ };
int ret;
if (ops->vidioc_cropcap)
@@ -1726,6 +1742,30 @@ static int v4l_cropcap(const struct v4l2_ioctl_ops *ops,
return 0;
}
+static int v4l_s_selection(const struct v4l2_ioctl_ops *ops,
+ struct file *file, void *fh, void *arg)
+{
+ struct v4l2_selection *s = arg;
+
+ if (s->rectangles &&
+ !access_ok(VERIFY_READ, s->pr, s->rectangles * sizeof(*s->pr)))
+ return -EFAULT;
+
+ return ops->vidioc_s_selection(file, fh, s);
+}
+
+static int v4l_g_selection(const struct v4l2_ioctl_ops *ops,
+ struct file *file, void *fh, void *arg)
+{
+ struct v4l2_selection *s = arg;
+
+ if (s->rectangles &&
+ !access_ok(VERIFY_WRITE, s->pr, s->rectangles * sizeof(*s->pr)))
+ return -EFAULT;
+
+ return ops->vidioc_g_selection(file, fh, s);
+}
+
static int v4l_log_status(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
@@ -2018,8 +2058,8 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_CROPCAP, v4l_cropcap, v4l_print_cropcap,
INFO_FL_CLEAR(v4l2_cropcap, type)),
IOCTL_INFO_FNC(VIDIOC_G_CROP, v4l_g_crop, v4l_print_crop,
INFO_FL_CLEAR(v4l2_crop, type)),
IOCTL_INFO_FNC(VIDIOC_S_CROP, v4l_s_crop, v4l_print_crop, INFO_FL_PRIO),
- IOCTL_INFO_STD(VIDIOC_G_SELECTION, vidioc_g_selection,
v4l_print_selection, 0),
- IOCTL_INFO_STD(VIDIOC_S_SELECTION, vidioc_s_selection,
v4l_print_selection, INFO_FL_PRIO),
+ IOCTL_INFO_FNC(VIDIOC_G_SELECTION, v4l_g_selection,
v4l_print_selection, 0),
+ IOCTL_INFO_FNC(VIDIOC_S_SELECTION, v4l_s_selection,
v4l_p
Re: [PATCH] RFC: Support for multiple selections
Hi Hans
On Wed, Sep 11, 2013 at 3:02 PM, Hans Verkuil wrote:
> Hi Ricardo,
>
> On 09/11/2013 02:13 PM, Ricardo Ribalda Delgado wrote:
>> Hello Hans
>>
>> On Wed, Sep 11, 2013 at 12:49 PM, Hans Verkuil wrote:
>>> Hi Ricardo,
>>>
>>> On 09/11/2013 11:34 AM, Ricardo Ribalda Delgado wrote:
>>>> Hi Hans
>>>>
>>>> Thanks for your feedback
>>>>
>>>> On Wed, Sep 11, 2013 at 11:04 AM, Hans Verkuil wrote:
>>>>> Hi Ricardo,
>>>>>
>>>>> On 09/11/2013 10:30 AM, Ricardo Ribalda Delgado wrote:
>>>>>> A new id field is added to the struct selection. On devices that
>>>>>> supports multiple sections this id indicate which of the selection to
>>>>>> modify.
>>>>>>
>>>>>> A new control V4L2_CID_SELECTION_BITMASK selects which of the selections
>>>>>> are used, if the control is set to zero the default rectangles are used.
>>>>>>
>>>>>> This is needed in cases where the user has to change multiple selections
>>>>>> at the same time to get a valid combination.
>>>>>>
>>>>>> On devices where the control V4L2_CID_SELECTION_BITMASK does not exist,
>>>>>> the id field is ignored
>>>>>
>>>>> This feels like a hack to me. A big problem I have with using a control
>>>>> here
>>>>> is that with a control you can't specify for which selection target it is.
>>>>>
>>>>
>>>> I am not sure that I understand what you mean here.
>>>>
>>>> If you set the control to 0x1 you are using selection 0, if you set
>>>> the control to 0x5, you are using selection 0 and 2.
>>>
>>> If you look here:
>>>
>>> http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-selection-targets
>>>
>>> you see that a selection has a 'target': i.e. does the selection define a
>>> crop
>>> rectangle, a compose rectange, a default crop rectangle, etc.
>>>
>>> You are extending the API to support multiple rectangles per target and
>>> using
>>> a control to select which rectangles are active (if I understand correctly).
>>> But that control does not (and cannot) specify for which target the
>>> rectangles
>>> should be activated.
>>
>> I want to have N crop rectangles and N compose rectangles. Every crop
>> rectangle has associated one compose rectangle.
>>
>> This will fit multiple purposes ie:
>>
>> - swap two areas of an image,
>> - multiple readout zones
>> - different decimation per area
>>
>>
>>>
>>>>
>>>>
>>>>> If you want to set multiple rectangles, why not just pass them directly?
>>>>> E.g.:
>>>>>
>>>>> struct v4l2_selection {
>>>>> __u32 type;
>>>>> __u32 target;
>>>>> __u32 flags;
>>>>> union {
>>>>> struct v4l2_rectr;
>>>>> struct v4l2_rect*pr;
>>>>> };
>>>>> __u32 rectangles;
>>>>> __u32 reserved[8];
>>>>> };
>>>>>
>>>>> If rectangles > 1, then pr is used.
>>>>>
>>>>
>>>> The structure is passed in a ioctl and I dont think that it is a good
>>>> idea that you let the kernel get/set a memory address not encapsulated
>>>> in it. I can see that it could lead to security breaches if there is a
>>>> mistake on the handling.
>>>
>>> It's used in lots of places. It's OK, provided you check the memory
>>> carefully.
>>> See e.g. how VIDIOC_G/S_EXT_CTRLS is handled. Usually the memory checks are
>>> done
>>> in the v4l2 core and the driver doesn't need to take care of it.
>>>
>>
>> I agree IFF the v4l2 core does the checks. One question raises me: how
>> does the user knows how big is the structure he has to allocate for
>> g_selection? Do we have to make a new ioctl g_n_selections?
>
> I would suggest using the same method that is used by the extended control
> API for
> string controls: if rectangles is too small, then the driver sets the field
> to the
> total number of rectangles and
[PATCH] v4l2: Support for multiple selections
From: Ricardo Ribalda
Extend v4l2 selection API to support multiple selection areas, this way
sensors that support multiple readout areas can work with multiple areas
of insterest.
The struct v4l2_selection and v4l2_subdev_selection has been extented
with a new field rectangles. If it is value is different than zero the
pr array is used instead of the r field.
A new structure v4l2_ext_rect has been defined, containing 4 reserved
fields for future improvements, as suggested by Hans.
A new function in v4l2-comon (v4l2_selection_flat_struct) is in charge
of converting a pr pointer with one item to a flatten struct. This
function is used in all the old drivers that dont support multiple
selections.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/platform/exynos-gsc/gsc-m2m.c | 6 +++
drivers/media/platform/exynos4-is/fimc-capture.c | 6 +++
drivers/media/platform/exynos4-is/fimc-lite.c| 6 +++
drivers/media/platform/s3c-camif/camif-capture.c | 6 +++
drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 ++
drivers/media/platform/s5p-tv/mixer_video.c | 6 +++
drivers/media/platform/soc_camera/soc_camera.c | 6 +++
drivers/media/v4l2-core/v4l2-common.c| 13 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 54 +---
include/media/v4l2-common.h | 2 +
include/uapi/linux/v4l2-subdev.h | 10 -
include/uapi/linux/videodev2.h | 15 ++-
12 files changed, 122 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 40a73f7..599a907 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -452,6 +452,9 @@ static int gsc_m2m_g_selection(struct file *file, void *fh,
(s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE))
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
frame = ctx_get_frame(ctx, s->type);
if (IS_ERR(frame))
return PTR_ERR(frame);
@@ -495,6 +498,9 @@ static int gsc_m2m_s_selection(struct file *file, void *fh,
(s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE))
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
ret = gsc_try_crop(ctx, &cr);
if (ret)
return ret;
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..357ac81 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -1283,6 +1283,9 @@ static int fimc_cap_g_selection(struct file *file, void
*fh,
if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
switch (s->target) {
case V4L2_SEL_TGT_COMPOSE_DEFAULT:
case V4L2_SEL_TGT_COMPOSE_BOUNDS:
@@ -1333,6 +1336,9 @@ static int fimc_cap_s_selection(struct file *file, void
*fh,
if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
if (s->target == V4L2_SEL_TGT_COMPOSE)
f = &ctx->d_frame;
else if (s->target == V4L2_SEL_TGT_CROP)
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 08fbfed..b895318 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -915,6 +915,9 @@ static int fimc_lite_g_selection(struct file *file, void
*fh,
if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
switch (sel->target) {
case V4L2_SEL_TGT_COMPOSE_BOUNDS:
case V4L2_SEL_TGT_COMPOSE_DEFAULT:
@@ -944,6 +947,9 @@ static int fimc_lite_s_selection(struct file *file, void
*fh,
sel->target != V4L2_SEL_TGT_COMPOSE)
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+ return -EINVAL;
+
fimc_lite_try_compose(fimc, &rect);
if ((sel->flags & V4L2_SEL_FLAG_LE) &&
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index 40b298a..951dce4 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1016,6 +1016,9 @@ static int s3c_camif_g_selection(struct file *file, void
*priv,
if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
+ if (v4l2_selection_flat_struct(s))
+
Patchwork is down or only for me?
Hello I have sent a patch and it does not appear on patchwork, it is also slower than usual. Also a patch from David Jedelsky is not there. Regards! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork is down or only for me?
I was looking to this one: https://patchwork.linuxtv.org/project/linux-media/list/ Where the latest patch is https://patchwork.linuxtv.org/patch/20090/ On Mon, Sep 16, 2013 at 4:58 PM, Antti Palosaari wrote: > On 09/16/2013 05:48 PM, Ricardo Ribalda Delgado wrote: >> >> Hello >> >> I have sent a patch and it does not appear on patchwork, it is also >> slower than usual. >> >> Also a patch from David Jedelsky is not there. > > > At least for now both seems to be there: > https://patchwork.kernel.org/project/linux-media/list/ > > regards > Antti > > -- > http://palosaari.fi/ -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork is down or only for me?
Yes, it is working fine. Thanks! On Mon, Sep 16, 2013 at 9:04 PM, Johannes Stezenbach wrote: > On Mon, Sep 16, 2013 at 05:01:36PM +0200, Ricardo Ribalda Delgado wrote: >> I was looking to this one: >> https://patchwork.linuxtv.org/project/linux-media/list/ >> >> Where the latest patch is https://patchwork.linuxtv.org/patch/20090/ >> >> On Mon, Sep 16, 2013 at 4:58 PM, Antti Palosaari wrote: >> > On 09/16/2013 05:48 PM, Ricardo Ribalda Delgado wrote: >> >> >> >> Hello >> >> >> >> I have sent a patch and it does not appear on patchwork, it is also >> >> slower than usual. >> >> >> >> Also a patch from David Jedelsky is not there. >> > >> > >> > At least for now both seems to be there: >> > https://patchwork.kernel.org/project/linux-media/list/ > > Should be fixed now. > > Johannes -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: Support for multiple selections
Hello Hans
As allways thank you very much for your comments.
On Mon, Sep 30, 2013 at 12:21 PM, Hans Verkuil wrote:
> Hi Ricardo,
>
> Sorry for the delayed review, but I'm finally catching up with my backlog.
>
> I've got a number of comments regarding this patch. I'm ignoring the platform
> driver patches for now until the core support is correct.
>
> On 09/16/2013 02:54 PM, Ricardo Ribalda Delgado wrote:
>> From: Ricardo Ribalda
>>
>> Extend v4l2 selection API to support multiple selection areas, this way
>> sensors that support multiple readout areas can work with multiple areas
>> of insterest.
>>
>> The struct v4l2_selection and v4l2_subdev_selection has been extented
>> with a new field rectangles. If it is value is different than zero the
>> pr array is used instead of the r field.
>>
>> A new structure v4l2_ext_rect has been defined, containing 4 reserved
>> fields for future improvements, as suggested by Hans.
>>
>> A new function in v4l2-comon (v4l2_selection_flat_struct) is in charge
>> of converting a pr pointer with one item to a flatten struct. This
>> function is used in all the old drivers that dont support multiple
>> selections.
>>
>> Signed-off-by: Ricardo Ribalda Delgado
>> ---
>> drivers/media/platform/exynos-gsc/gsc-m2m.c | 6 +++
>> drivers/media/platform/exynos4-is/fimc-capture.c | 6 +++
>> drivers/media/platform/exynos4-is/fimc-lite.c| 6 +++
>> drivers/media/platform/s3c-camif/camif-capture.c | 6 +++
>> drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 ++
>> drivers/media/platform/s5p-tv/mixer_video.c | 6 +++
>> drivers/media/platform/soc_camera/soc_camera.c | 6 +++
>> drivers/media/v4l2-core/v4l2-common.c| 13 ++
>> drivers/media/v4l2-core/v4l2-ioctl.c | 54
>> +---
>> include/media/v4l2-common.h | 2 +
>> include/uapi/linux/v4l2-subdev.h | 10 -
>> include/uapi/linux/videodev2.h | 15 ++-
>> 12 files changed, 122 insertions(+), 11 deletions(-)
>>
>
>
>
>> diff --git a/drivers/media/v4l2-core/v4l2-common.c
>> b/drivers/media/v4l2-core/v4l2-common.c
>> index a95e5e2..cd20567 100644
>> --- a/drivers/media/v4l2-core/v4l2-common.c
>> +++ b/drivers/media/v4l2-core/v4l2-common.c
>> @@ -886,3 +886,16 @@ void v4l2_get_timestamp(struct timeval *tv)
>> tv->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>> }
>> EXPORT_SYMBOL_GPL(v4l2_get_timestamp);
>> +
>> +int v4l2_selection_flat_struct(struct v4l2_selection *s)
>> +{
>> + if (s->rectangles == 0)
>> + return 0;
>> +
>> + if (s->rectangles != 1)
>> + return -EINVAL;
>> +
>> + s->r = s->pr[0].r;
>
> This would overwrite the pr pointer. Not a good idea.
That was exactly the point. The helper function convert the
multi_selection, ext_rect to the legacy struct. This way the drivers
needed almost no modification, just a call to the helper at the
beginning of the handler.
Otherwise we need your get_rect helper, and then a set_rect helper at
every exit.
If you think this is the way, then lets do it. Right now there are not
too many drivers that supports selection, so it is right time to make
such a decisions.
>
> I would make a helper function like this:
>
> int v4l2_selection_get_rect(struct v4l2_selection *s, struct v4l2_ext_rect *r)
> {
> if (s->rectangles > 1)
> return -EINVAL;
> if (s->rectangles == 1) {
> *r = s->pr[0];
> return 0;
> }
> if (s->r.width < 0 || s->r.height < 0)
> return -EINVAL;
> r->left = s->r.left;
> r->top = s->r.top;
> r->width = s->r.width;
> r->height = s->r.height;
> memset(r->reserved, 0, sizeof(r->reserved));
> return 0;
> }
>
> See also my proposed v4l2_ext_rect definition below.
>
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_selection_flat_struct);
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 68e6b5e..fe92f6b 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -572,11 +572,22 @@ static void v4l_print_crop(const void *arg, bool
>> write_only)
>> static void v4l_print_selection(const void *arg, bool write_only)
>> {
>> const struct v4l2_selection *p = arg;
>> + int i;
