Re: Logitech C270 webcam floods the log
Hi Jean, On Wed, Oct 23, 2019 at 03:18:59PM +0200, Jean Delvare wrote: > Hi all, > > When my Logitech C270 webcam is plugged in, my kernel log gets filled > with this message: > > usb 3-4.1: reset high-speed USB device number 4 using xhci_hcd > > every 5 seconds. I have the same problem on 3 different Intel-based > computers (different generations), using 2 different webcams, same > brand "same model". > > Is Logitech doing crappy hardware these days, or are we doing something > wrong? Is there any way to know the reason that triggers the reset? Is this before or after the uvcvideo driver gets involved ? One easy way to check is to move the uvcvideo.ko module out of the way so that it doesn't get loaded automatically (or just blacklist it in /etc/modprobe.d/) and then plug the camera. > I would be more than happy to provide any relevant debugging > information if anyone is able to make it stop. As it stands, I must > plug my webcam before using it and unplug it as soon as I'm done, which > isn't exactly convenient. -- Regards, Laurent Pinchart
Re: V4L2 runs out of memory when OMAP3 ISP parallel pixel clock is high
Hi Adam,
On Sun, Oct 20, 2019 at 09:45:25AM -0500, Adam Ford wrote:
> I am running a DM3730 connected to an mt9p031 sensor, and the ISP is
> running in 8-bit parallel mode.
>
> I have the sensor endpoint configured as:
>
> mt9p031_out: endpoint {
> input-clock-frequency = <2400>;
> pixel-clock-frequency = <7200>;
> remote-endpoint = <&ccdc_ep>;
> };
>
> I was looking through the datasheet, and it appears as if the pixel
> clock frequency can go up to 96MHz, so I tried to increase the
> pixel-clock-frequency to 96MHz, but v4l2 seems to get an out of memory
> error.
>
> libv4l2: error turning on stream: No space left on device
> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
> to allocate required memory.
> Additional debug info:
> gstv4l2src.c(658): gst_v4l2src_decide_allocation ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Buffer pool activation failed
> Execution ended after 0:00:00.019073486
The error code may be misleading. ENOSPC is used here to report that the
maximum CCDC bandwidth has been exceeded, not that the driver is running
out of memory.
The check is performed in isp_video_check_external_subdevs(), and the
maximum CCDC bandwidth is calculated by omap3isp_ccdc_max_rate():
/*
* TRM says that for parallel sensors the maximum data rate
* should be 90% form L3/2 clock, otherwise just L3/2.
*/
if (ccdc->input == CCDC_INPUT_PARALLEL)
rate = pipe->l3_ick / 2 * 9 / 10;
else
rate = pipe->l3_ick / 2;
Could you point me to the part of the OMAP3 datasheet that you think
allows for 96 MHz ?
> Through trial and error, I was able to get push the sensor's
> pixel-clock-frequency to work at 90MHz, but no higher. I have also
> tried experimenting with the input clock frequency without success.
>
> If I can get the clock to run at 96MHz, which the ISP and sensor
> documentation appears to permit, I am hoping to be able to achieve a
> little higher frame rate.
>
> Is there something I need to do to allocate more memory to V4L2 or is
> there some other limitation causing the out of memory at higher pixel
> clock frequencies?
--
Regards,
Laurent Pinchart
Re: OMAP3 ISP v4l2 inconsistency on DM3730
Hi Hans,
On Sun, Oct 20, 2019 at 07:26:20PM +0200, Hans Verkuil wrote:
> On 10/20/19 7:35 AM, Laurent Pinchart wrote:
> > On Sat, Oct 19, 2019 at 11:14:03AM -0500, Adam Ford wrote:
> >> On Fri, Oct 18, 2019 at 4:17 PM Sakari Ailus wrote:
> >>> On Fri, Oct 18, 2019 at 04:10:23PM -0500, Adam Ford wrote:
> >>>> On Fri, Oct 18, 2019 at 4:00 PM Sakari Ailus wrote:
> >>>>> On Fri, Oct 18, 2019 at 02:38:57PM -0500, Adam Ford wrote:
> >>>>>> I have a DM3730 with a parallel mt9p031 sensor attached. I am trying
> >>>>>> to troubleshoot some issues with streaming video with G-streamer, but
> >>>>>> I I think the issue is in how the ISP driver reports the video info.
> >>>>>>
> >>>>>> I have the pipeline to grab from the resizer:
> >>>>>>
> >>>>>> media-ctl -v -V '"mt9p031 1-0048":0 [SGRBG8 1280x720
> >>>>>> (664,541)/1280x720], "OMAP3 ISP CCDC":2 [SGRBG8 1280x720], "OMAP3 ISP
> >>>>>> preview":1 [UYVY 1280x720], "OMAP3 ISP resizer":1 [UYVY 480x272]'
> >>>>>>
> >>>>>> This make /dev/video6 the output of the resizer and shows the format
> >>>>>> and resolution of the output of the resizer as:
> >>>>>>
> >>>>>> Setting up format UYVY8_1X16 480x272 on pad OMAP3 ISP resizer/1
> >>>>>> Format set: UYVY8_1X16 480x272
> >>>>>>
> >>>>>> I used 480x272 because it's the resolution of my LCD, and I was hoping
> >>>>>> the resizer would be able to scale this so the ARM would not need to
> >>>>>> do the work, and it appears to not have any issues with this
> >>>>>> resolution.
> >>>>>>
> >>>>>> However, if I query the video format, I don't get UYVY:
> >>>>>>
> >>>>>> # v4l2-ctl -d6 --list-formats-ext
> >>>>>> ioctl: VIDIOC_ENUM_FMT
> >>>>>> Type: Video Capture
> >>>>>>
> >>>>>> [0]: 'RGB3' (RGB3, emulated)
> >>>>>> [1]: 'BGR3' (BGR3, emulated)
> >>>>>> [2]: 'YU12' (YU12, emulated)
> >>>>>> [3]: 'YV12' (YV12, emulated)
> >>>>>>
> >>>>>> This becomes an issue when I attempt to stream video from my camera to
> >>>>>> anything, include fake sink:
> >>>>>>
> >>>>>> gst-launch-1.0 -v v4l2src device=/dev/video6 ! fakesink
> >>>>>> Tried to capture in RGB3, but device returned format UYVY
> >>>>>>
> >>>>>> So for some reason, when queried, it reports different values than
> >>>>>> UYVY, but when attempting to set the video capture to the listed
> >>>>>> formats, it returns an error.
> >>>>>>
> >>>>>> gst-launch-1.0 -v v4l2src device=/dev/video6 ! video/x-raw,
> >>>>>> format=UYVY ! fakesink
> >>>>>
> >>>>> I don't have any experience on v4l2src recently but I can comment on the
> >>>>> omap3isp driver.
> >>>>>
> >>>>> In general, the format the omap3isp may produce on a given video node
> >>>>> depends on the format of data which the block associated with the video
> >>>>> node is fed with.
> >>>>>
> >>>>> For instance, in case of the raw Bayer formats, the pixel order does not
> >>>>> change, and thus the pixel order remains all the way from the sensor to
> >>>>> the
> >>>>> video node.
> >>>>
> >>>> From what I can tell, it looks like the output of the resizer is only
> >>>> capable of two formats,
> >>>> from ispresizer.c:
> >>>>
> >>>> /* resizer pixel formats */
> >>>> static const unsigned int resizer_formats[] = {
> >>>> MEDIA_BUS_FMT_UYVY8_1X16,
> >>>> MEDIA_BUS_FMT_YUYV8_1X16,
> >>>> };
> >>>>
> >>>> Also:
> >>>>
> >>>> * resizer_try_format - Handle try format by pad subdev method
> >>>> * @res : ISP resizer device
> >>>> * @
Re: [ANN v2] Media sessions in Lyon in October: libcamera
Hi Hans, Thank you for handling the announcement. On Thu, Oct 17, 2019 at 01:16:20PM +0200, Hans Verkuil wrote: > (Just updated the attendee list for this meeting, no other changes) > > 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 second session deals with libcamera and is on Wednesday morning > from 9:00 to 13:00. > > Attendees for this session: > > Nicolas Dufresne > Tomasz Figa > Ezequiel Garcia > Dafna Hirschfeld > Eugen Hristev > Jacopo Mondi > Laurent Pinchart > Niklas Söderlund > Dave Stevenson > Hans Verkuil > > That's 10 people. > > Planning to use libcamera, but willing to give up their seat if needed: > > Daniel Gomez > Helen Koike > > Just interested: > > Boris Brezillon > Alexandre Courbot > > If I missed someone, or you are on the list but won't attend after all, then > please let me know. > > Attendees: it is probably useful if you let us know whether you have to > join this meeting because you plan to use libcamera, or if you are 'just > interested'. After the libcamera presentation on Tuesday afternoon we > should know how many of the 'just interested' list can join. > > Agenda: > > TBD by Laurent. The two main items we would like to discuss are: API review -- Following Jacopo's talk on Tuesday that will kickstart the public API review, we would like to receive feedback from all attendees on the libcamera APIs. This includes the public API towards applications and the API toward the Image Processing Algorithms (IPA, also known as 3A). The internal APIs between libcamera components and helpers, as well as the Android camera HAL implementation, can also be discussed given interest from the audience if time permits. The libcamera API is documented in the source code using doxygen. A nightly build of the documentation can be found at https://www.libcamera.org/api-html/. Please note that the built documentation covers all libcamera classes, making it a bit difficult to tell the public API apart from the internal APIs. We will try to address this problem this week. Use cases sharing - The libcamera project aims at supporting a wide range of use cases, even if we need to limit the scope of the first release. Our experience with camera support in Linux systems give us a good but still restricted view of the uses, and we would like to discuss additional use cases with the audience. If you have camera-related needs, from simple to crazy, we want to hear about them. Please all feel free to propose other topics that you would find of interest. We will finalise the agenda this week. -- Regards, Laurent Pinchart
Re: OMAP3 ISP v4l2 inconsistency on DM3730
ault (maps to Full Range) > >>>> Flags : > >>>> # > >>>> > >>>> This shows me the UYVY format, but upon a follow-up query, it does not > >>>> appear to retain the pixel format of UYVY. > >>>> > >>>> v4l2-ctl -d /dev/video6 --list-formats-ext > >>>> ioctl: VIDIOC_ENUM_FMT > >>>> Type: Video Capture > >>>> > >>>> [0]: 'RGB3' (RGB3, emulated) > >>>> [1]: 'BGR3' (BGR3, emulated) > >>>> [2]: 'YU12' (YU12, emulated) > >>>> [3]: 'YV12' (YV12, emulated) > >>>> # > >>>> > >>>> If I use ffmpeg to stream video, I the video codec there recognizes it > >>>> as uyvy and I can convert it to RGB to display on my LCD, but it has > >>>> limited framerate, and it seems to me like this should be do-able in > >>>> G-Streamer with v4l2src. > >>>> > >>>> # ffmpeg -an -re -i /dev/video6 -f v4l2 -vcodec rawvideo -pix_fmt bgra > >>>> -f fbdev /dev/fb0 > >>>> > >>>> Input #0, video4linux2,v4l2, from '/dev/video6': > >>>> Duration: N/A, start: 908.826490, bitrate: N/A > >>>> Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, > >>>> 480x272, 17.42 tbr, 1000k tbn, 1000k tbc > >>>> Stream mapping: > >>>> Stream #0:0 -> #0:0 (rawvideo (native) -> rawvideo (native)) > >>>> Press [q] to stop, [?] for help > >>>> Output #0, fbdev, to '/dev/fb0': > >>>> Metadata: > >>>> encoder : Lavf57.83.100 > >>>> Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 480x272, > >>>> q=2-31, 72765 kb/s, 17.42 fps, 17.42 tbn, 17.42 tbc > >>>> Metadata: > >>>> encoder : Lavc57.107.100 rawvideo > >>>> > >>>> > >>>> This shows me the information is available in some ways from v4l2, but > >>>> I wonder if there is a missing IOCTL for VIDIOC_ENUM_FMT for the isp > >>>> driver somewhere. Shouldn't VIDIOC_ENUM_FMT return UYVY? > >>>> > >>>> I noticed vpbe_display.c has a function that appears to correspond to > >>>> this. There is a patch at [1] for an older kernel. Is this something > >>>> worth pursuing? > >>>> > >>>> [1] - > >>>> https://stackoverflow.com/questions/20693155/gstreamer-failed-to-enumerate-video-formats-and-inappropriate-ioctl-for-device -- Regards, Laurent Pinchart
[GIT PULL FOR v5.5] uvcvideo and omap4iss fixes
Hi Mauro, The following changes since commit 3ff3a712a9eabb3d7bf52c263dd1ece054345df4: media: ti-vpe: vpe: don't rely on colorspace member for conversion (2019-10-10 13:54:22 -0300) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/v4l2-next-20191016 for you to fetch changes up to 3852c5c20448eb08142a9eee6fc6caa12a7d55d8: staging: media: Make use of devm_platform_ioremap_resource (2019-10-16 12:54:08 +0300) - uvcvideo miscellaneous fixes - omap4iss miscellaneous fixes Christophe JAILLET (1): media: uvcvideo: Fix a typo in UVC_METATADA_BUF_SIZE Hariprasad Kelam (1): staging: media: Make use of devm_platform_ioremap_resource Laurent Pinchart (1): media: uvcvideo: Fix error path in control parsing failure Nachammai Karuppiah (1): staging: media: omap4iss: Replace NULL comparison. drivers/media/usb/uvc/uvc_driver.c | 28 +++- drivers/media/usb/uvc/uvc_metadata.c | 4 ++-- drivers/media/usb/uvc/uvc_queue.c | 2 +- drivers/media/usb/uvc/uvcvideo.h | 2 +- drivers/staging/media/omap4iss/iss.c | 6 +- drivers/staging/media/omap4iss/iss_video.c | 4 ++-- 6 files changed, 22 insertions(+), 24 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCHv6 0/3] v4l2-core: improve ioctl validation
On Mon, Oct 14, 2019 at 10:40:18AM +0200, Hans Verkuil wrote: > This supersedes > https://www.mail-archive.com/linux-media@vger.kernel.org/msg150027.html > based on feedback from Laurent: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg150117.html > > and Sakari: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg150129.html > > This v6 only moves some code from patch 1 to patch 3, the final code > is the same as for v5. I plan to make a PR for this very soon together > with the vivid metadata patches that need this. > > Regards, > > Hans > > Changes in v6: > > Patch 1/3 dropped the check against GRABBER for the g_parm ioctl, > but that is too early: this should be done in patch 3/3 where this > code no longer applies to touch devices (which was the reason for > the GRABBER test). > > Changes in v5: > > I now check if a GRABBER device is a video or metadata device > (or both!) by checking device_caps. > > > Hans Verkuil (2): > v4l2-dev: simplify the SDR checks > v4l2-dev: fix is_tch checks > > Vandana BN (1): > v4l2-core: correctly validate video and metadata ioctls For the whole series, Acked-by: Laurent Pinchart > > drivers/media/v4l2-core/v4l2-dev.c | 104 --- > drivers/media/v4l2-core/v4l2-ioctl.c | 16 - > 2 files changed, 75 insertions(+), 45 deletions(-) > -- Regards, Laurent Pinchart
Re: [PATCH v2 1/2] rcar-vin: Define which hardware supports NV12
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:16:14AM +0200, Niklas Söderlund wrote:
> Most but not all Gen3 hardware support outputting NV12, add a flag to
> indicate which SoCs do support it.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
> drivers/media/platform/rcar-vin/rcar-vin.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 334c62805959cc8a..dcb539711151a3b5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -983,6 +983,7 @@ static const struct rvin_group_route
> rcar_info_r8a7795_routes[] = {
> static const struct rvin_info rcar_info_r8a7795 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a7795_routes,
> @@ -1077,6 +1078,7 @@ static const struct rvin_group_route
> rcar_info_r8a7796_routes[] = {
> static const struct rvin_info rcar_info_r8a7796 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a7796_routes,
> @@ -1121,6 +1123,7 @@ static const struct rvin_group_route
> rcar_info_r8a77965_routes[] = {
> static const struct rvin_info rcar_info_r8a77965 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a77965_routes,
> @@ -1168,6 +1171,7 @@ static const struct rvin_group_route
> rcar_info_r8a77980_routes[] = {
> static const struct rvin_info rcar_info_r8a77980 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a77980_routes,
> @@ -1184,6 +1188,7 @@ static const struct rvin_group_route
> rcar_info_r8a77990_routes[] = {
> static const struct rvin_info rcar_info_r8a77990 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a77990_routes,
> @@ -1196,6 +1201,7 @@ static const struct rvin_group_route
> rcar_info_r8a77995_routes[] = {
> static const struct rvin_info rcar_info_r8a77995 = {
> .model = RCAR_GEN3,
> .use_mc = true,
> + .nv12 = true,
> .max_width = 4096,
> .max_height = 4096,
> .routes = rcar_info_r8a77995_routes,
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 86e9bad44484092c..a36b0824f81d171d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -126,6 +126,7 @@ struct rvin_group_route {
> * struct rvin_info - Information about the particular VIN implementation
> * @model: VIN model
> * @use_mc: use media controller instead of controlling subdevice
> + * @nv12:support outputing NV12 pixel format
> * @max_width: max input width the VIN supports
> * @max_height: max input height the VIN supports
> * @routes: list of possible routes from the CSI-2 recivers to
> @@ -134,6 +135,7 @@ struct rvin_group_route {
> struct rvin_info {
> enum model_id model;
> bool use_mc;
> + bool nv12;
>
> unsigned int max_width;
> unsigned int max_height;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/2] rcar-vin: Add support for outputting NV12
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:16:15AM +0200, Niklas Söderlund wrote:
> Most Gen3 boards can output frames in NV12 format, add support for this
> with a runtime check that the running hardware supports it.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Simon Horman
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 5 ++-
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 39 +
> 2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index af4f774149f08597..cf9029efeb0450cb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -118,6 +118,7 @@
> #define VNDMR_ABIT (1 << 2)
> #define VNDMR_DTMD_YCSEP (1 << 1)
While at it, I would define this as (2 << 0).
> #define VNDMR_DTMD_ARGB (1 << 0)
> +#define VNDMR_DTMD_YCSEP_420 (3 << 0)
>
> /* Video n Data Mode Register 2 bits */
> #define VNDMR2_VPS (1 << 30)
> @@ -701,11 +702,13 @@ static int rvin_setup(struct rvin_dev *vin)
>* Output format
>*/
> switch (vin->format.pixelformat) {
> + case V4L2_PIX_FMT_NV12:
> case V4L2_PIX_FMT_NV16:
> rvin_write(vin,
> ALIGN(vin->format.bytesperline * vin->format.height,
>0x80), VNUVAOF_REG);
> - dmr = VNDMR_DTMD_YCSEP;
> + dmr = vin->format.pixelformat == V4L2_PIX_FMT_NV12 ?
> + VNDMR_DTMD_YCSEP_420 : VNDMR_DTMD_YCSEP;
According to the datasheet, VNDMR_DTMD_YCSEP_420 is only valid for some
of the channels (see footnote of the VnDMR register documentation).
> output_is_yuv = true;
> break;
> case V4L2_PIX_FMT_YUYV:
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 13b7cd5d2e40415a..9e2e63ffcc47acad 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -30,6 +30,10 @@
> */
>
> static const struct rvin_video_format rvin_formats[] = {
> + {
> + .fourcc = V4L2_PIX_FMT_NV12,
> + .bpp= 1,
> + },
> {
> .fourcc = V4L2_PIX_FMT_NV16,
> .bpp= 1,
> @@ -72,6 +76,9 @@ const struct rvin_video_format
> *rvin_format_from_pixel(struct rvin_dev *vin,
> if (vin->info->model == RCAR_M1 && pixelformat == V4L2_PIX_FMT_XBGR32)
> return NULL;
>
> + if (pixelformat == V4L2_PIX_FMT_NV12 && !vin->info->nv12)
> + return NULL;
> +
> for (i = 0; i < ARRAY_SIZE(rvin_formats); i++)
> if (rvin_formats[i].fourcc == pixelformat)
> return rvin_formats + i;
> @@ -90,17 +97,29 @@ static u32 rvin_format_bytesperline(struct rvin_dev *vin,
> if (WARN_ON(!fmt))
> return -EINVAL;
>
> - align = pix->pixelformat == V4L2_PIX_FMT_NV16 ? 0x20 : 0x10;
> + switch (pix->pixelformat) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV16:
> + align = 0x20;
> + break;
> + default:
> + align = 0x10;
> + break;
> + }
>
> return ALIGN(pix->width, align) * fmt->bpp;
> }
>
> static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
> {
> - if (pix->pixelformat == V4L2_PIX_FMT_NV16)
> + switch (pix->pixelformat) {
> + case V4L2_PIX_FMT_NV12:
> + return pix->bytesperline * pix->height * 3 / 2;
> + case V4L2_PIX_FMT_NV16:
> return pix->bytesperline * pix->height * 2;
> -
> - return pix->bytesperline * pix->height;
> + default:
> + return pix->bytesperline * pix->height;
> + }
> }
>
> static void rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> @@ -124,8 +143,16 @@ static void rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix)
> break;
> }
>
> - /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> - walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> + /* HW limit width to a multiple of 32 (2^5) for NV12/16 else 2 (2^1) */
> + switch (vin->format.pixelformat) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV16:
> + walign = 5;
> + break;
> + default:
> + walign = 1;
> + break;
> + }
>
> /* Limit to VIN capabilities */
> v4l_bound_align_image(&pix->width, 2, vin->info->max_width, walign,
--
Regards,
Laurent Pinchart
Re: [PATCHv6 4/3] v4l2-dev: disable frequency and tuner ioctls for touch
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:01:05PM +0200, Hans Verkuil wrote:
> Touch devices have obviously no tuner, so don't attempt to enable those ioctls
> for such devices.
Shouldn't this be disabled for pure metadata devices (is_meta &&
!is_vid) too ?
> Signed-off-by: Hans Verkuil
> ---
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> index cec588b04711..da42d172714a 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -581,8 +581,10 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> set_bit(_IOC_NR(VIDIOC_TRY_EXT_CTRLS), valid_ioctls);
> if (vdev->ctrl_handler || ops->vidioc_querymenu)
> set_bit(_IOC_NR(VIDIOC_QUERYMENU), valid_ioctls);
> - SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
> - SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
> + if (!is_tch) {
> + SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
> + }
> SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
> #ifdef CONFIG_VIDEO_ADV_DEBUG
> set_bit(_IOC_NR(VIDIOC_DBG_G_CHIP_INFO), valid_ioctls);
> @@ -754,7 +756,7 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> SET_VALID_IOCTL(ops, VIDIOC_G_MODULATOR, vidioc_g_modulator);
> SET_VALID_IOCTL(ops, VIDIOC_S_MODULATOR, vidioc_s_modulator);
> }
> - if (is_rx) {
> + if (is_rx && !is_tch) {
> /* receiver only ioctls */
> SET_VALID_IOCTL(ops, VIDIOC_G_TUNER, vidioc_g_tuner);
> SET_VALID_IOCTL(ops, VIDIOC_S_TUNER, vidioc_s_tuner);
>
--
Regards,
Laurent Pinchart
Re: [PATCHv6 3/3] v4l2-dev: fix is_tch checks
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 10:40:21AM +0200, Hans Verkuil wrote:
> Touch devices mark too many ioctls as valid. Restrict the list of
> valid ioctls for touch devices.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/v4l2-core/v4l2-dev.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> index 27fb96a6c2a8..cec588b04711 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -596,8 +596,8 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> if (ops->vidioc_enum_freq_bands || ops->vidioc_g_tuner ||
> ops->vidioc_g_modulator)
> set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
>
> - if (is_vid || is_tch) {
> - /* video and touch specific ioctls */
> + if (is_vid) {
> + /* video specific ioctls */
> if ((is_rx && (ops->vidioc_enum_fmt_vid_cap ||
> ops->vidioc_enum_fmt_vid_overlay)) ||
> (is_tx && ops->vidioc_enum_fmt_vid_out))
> @@ -675,6 +675,19 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> ops->vidioc_try_fmt_sliced_vbi_out)))
> set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
> SET_VALID_IOCTL(ops, VIDIOC_G_SLICED_VBI_CAP,
> vidioc_g_sliced_vbi_cap);
> + } else if (is_tch) {
> + /* touch specific ioctls */
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, vidioc_enum_fmt_vid_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_vid_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_vid_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_vid_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FRAMESIZES,
> vidioc_enum_framesizes);
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FRAMEINTERVALS,
> vidioc_enum_frameintervals);
> + SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, vidioc_enum_input);
> + SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
> + SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
> + SET_VALID_IOCTL(ops, VIDIOC_G_PARM, vidioc_g_parm);
> + SET_VALID_IOCTL(ops, VIDIOC_S_PARM, vidioc_s_parm);
> } else if (is_sdr && is_rx) {
> /* SDR receiver specific ioctls */
> SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, vidioc_enum_fmt_sdr_cap);
> @@ -702,8 +715,8 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
> }
>
> - if (is_vid || is_vbi || is_tch || is_meta) {
> - /* ioctls valid for video, vbi, touch and metadata */
> + if (is_vid || is_vbi || is_meta) {
> + /* ioctls valid for video, vbi and metadata */
> if (ops->vidioc_s_std)
> set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);
> SET_VALID_IOCTL(ops, VIDIOC_S_STD, vidioc_s_std);
> @@ -727,8 +740,7 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> SET_VALID_IOCTL(ops, VIDIOC_G_AUDOUT, vidioc_g_audout);
> SET_VALID_IOCTL(ops, VIDIOC_S_AUDOUT, vidioc_s_audout);
> }
> - if (ops->vidioc_g_parm || (vdev->vfl_type == VFL_TYPE_GRABBER &&
> - ops->vidioc_g_std))
> + if (ops->vidioc_g_parm || ops->vidioc_g_std)
> set_bit(_IOC_NR(VIDIOC_G_PARM), valid_ioctls);
This will become potentially valid for VBI devices, is it intended ?
> SET_VALID_IOCTL(ops, VIDIOC_S_PARM, vidioc_s_parm);
> SET_VALID_IOCTL(ops, VIDIOC_S_DV_TIMINGS, vidioc_s_dv_timings);
--
Regards,
Laurent Pinchart
Re: [PATCHv6 2/3] v4l2-dev: simplify the SDR checks
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 10:40:20AM +0200, Hans Verkuil wrote:
> In determine_valid_ioctls() we can use SET_VALID_IOCTL to enable
> ioctls for SDR, simplifying the code.
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-dev.c | 24
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> index 1bf543932e4f..27fb96a6c2a8 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -677,24 +677,16 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> SET_VALID_IOCTL(ops, VIDIOC_G_SLICED_VBI_CAP,
> vidioc_g_sliced_vbi_cap);
> } else if (is_sdr && is_rx) {
> /* SDR receiver specific ioctls */
> - if (ops->vidioc_enum_fmt_sdr_cap)
> - set_bit(_IOC_NR(VIDIOC_ENUM_FMT), valid_ioctls);
> - if (ops->vidioc_g_fmt_sdr_cap)
> - set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
> - if (ops->vidioc_s_fmt_sdr_cap)
> - set_bit(_IOC_NR(VIDIOC_S_FMT), valid_ioctls);
> - if (ops->vidioc_try_fmt_sdr_cap)
> - set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, vidioc_enum_fmt_sdr_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_sdr_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_sdr_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_sdr_cap);
> } else if (is_sdr && is_tx) {
> /* SDR transmitter specific ioctls */
> - if (ops->vidioc_enum_fmt_sdr_out)
> - set_bit(_IOC_NR(VIDIOC_ENUM_FMT), valid_ioctls);
> - if (ops->vidioc_g_fmt_sdr_out)
> - set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
> - if (ops->vidioc_s_fmt_sdr_out)
> - set_bit(_IOC_NR(VIDIOC_S_FMT), valid_ioctls);
> - if (ops->vidioc_try_fmt_sdr_out)
> - set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, vidioc_enum_fmt_sdr_out);
> + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_sdr_out);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_sdr_out);
> + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_sdr_out);
> }
>
> if (is_vid || is_vbi || is_sdr || is_tch || is_meta) {
--
Regards,
Laurent Pinchart
Re: [PATCHv6 1/3] v4l2-core: correctly validate video and metadata ioctls
V4L2_CAP_META_OUTPUT; > struct video_device *vfd = video_devdata(file); > const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops; > - bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER; > + bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER && > + (vfd->device_caps & vid_caps); > bool is_vbi = vfd->vfl_type == VFL_TYPE_VBI; > bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR; > bool is_tch = vfd->vfl_type == VFL_TYPE_TOUCH; > + bool is_meta = vfd->vfl_type == VFL_TYPE_GRABBER && > +(vfd->device_caps & meta_caps); > bool is_rx = vfd->vfl_dir != VFL_DIR_TX; > bool is_tx = vfd->vfl_dir != VFL_DIR_RX; > > @@ -996,11 +1006,11 @@ static int check_fmt(struct file *file, enum > v4l2_buf_type type) > return 0; > break; > case V4L2_BUF_TYPE_META_CAPTURE: > - if (is_vid && is_rx && ops->vidioc_g_fmt_meta_cap) > + if (is_meta && is_rx && ops->vidioc_g_fmt_meta_cap) > return 0; > break; > case V4L2_BUF_TYPE_META_OUTPUT: > - if (is_vid && is_tx && ops->vidioc_g_fmt_meta_out) > + if (is_meta && is_tx && ops->vidioc_g_fmt_meta_out) > return 0; > break; > default: -- Regards, Laurent Pinchart
Re: [PATCH v2] rcar-vin: Do not enumerate unsupported pixel formats
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:07:50AM +0200, Niklas Söderlund wrote:
> If a pixel format is not supported by the hardware NULL is returned by
> rvin_format_from_pixel() for that fourcc. Verify that the pixel format
> is supported using this or skip it when enumerating.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 9a9b89c0dc0b3be4..13b7cd5d2e40415a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -296,12 +296,22 @@ static int rvin_g_fmt_vid_cap(struct file *file, void
> *priv,
> static int rvin_enum_fmt_vid_cap(struct file *file, void *priv,
>struct v4l2_fmtdesc *f)
> {
> - if (f->index >= ARRAY_SIZE(rvin_formats))
> - return -EINVAL;
> -
> - f->pixelformat = rvin_formats[f->index].fourcc;
> + struct rvin_dev *vin = video_drvdata(file);
> + unsigned int i;
> + int matched;
> +
> + matched = -1;
> + for (i = 0; i < ARRAY_SIZE(rvin_formats); i++) {
> + if (rvin_format_from_pixel(vin, rvin_formats[i].fourcc))
> + matched++;
> +
> + if (matched == f->index) {
> + f->pixelformat = rvin_formats[i].fourcc;
> + return 0;
> + }
> + }
I wonder if the following would be more readable ?
struct rvin_dev *vin = video_drvdata(file);
unsigned int index = f->index;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(rvin_formats); i++) {
if (rvin_format_from_pixel(vin, rvin_formats[i].fourcc))
continue;
if (index-- == 0) {
f->pixelformat = rvin_formats[i].fourcc;
return 0;
}
}
return -EINVAL;
In any case,
Reviewed-by: Laurent Pinchart
> - return 0;
> + return -EINVAL;
> }
>
> static int rvin_g_selection(struct file *file, void *fh,
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] rcar-vin: Create compose rectangle where it is used
Hi Nklas,
Thank you for the patch.
On Wed, Oct 09, 2019 at 01:22:01AM +0200, Niklas Söderlund wrote:
> The rectangle used to correct the compose settings when changing the
> format was created inside a helper function and not where it was used.
> This is confusing and makes the code harder to read, fix this.
>
> This cleanup is made possible due to refactoring elsewhere and there is
> no functional change.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 25 +
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index f809350c514c337c..9a9b89c0dc0b3be4 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -181,8 +181,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
>
> static int rvin_try_format(struct rvin_dev *vin, u32 which,
> struct v4l2_pix_format *pix,
> -struct v4l2_rect *src_rect,
> -struct v4l2_rect *compose)
> +struct v4l2_rect *src_rect)
> {
> struct v4l2_subdev *sd = vin_to_source(vin);
> struct v4l2_subdev_pad_config *pad_cfg;
> @@ -229,13 +228,6 @@ static int rvin_try_format(struct rvin_dev *vin, u32
> which,
> pix->height = height;
>
> rvin_format_align(vin, pix);
> -
> - if (compose) {
> - compose->top = 0;
> - compose->left = 0;
> - compose->width = pix->width;
> - compose->height = pix->height;
> - }
> done:
> v4l2_subdev_free_pad_config(pad_cfg);
>
> @@ -259,28 +251,33 @@ static int rvin_try_fmt_vid_cap(struct file *file, void
> *priv,
> {
> struct rvin_dev *vin = video_drvdata(file);
>
> - return rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, &f->fmt.pix, NULL,
> -NULL);
> + return rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, &f->fmt.pix, NULL);
> }
>
> static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
> struct v4l2_format *f)
> {
> struct rvin_dev *vin = video_drvdata(file);
> - struct v4l2_rect src_rect, compose;
> + struct v4l2_rect fmt_rect, src_rect;
I would rename fmt_rect to something more descriptive. Maybe full_rect,
compose_bounds, ... ? Apart from that,
Reviewed-by: Laurent Pinchart
> int ret;
>
> if (vb2_is_busy(&vin->queue))
> return -EBUSY;
>
> ret = rvin_try_format(vin, V4L2_SUBDEV_FORMAT_ACTIVE, &f->fmt.pix,
> - &src_rect, &compose);
> + &src_rect);
> if (ret)
> return ret;
>
> vin->format = f->fmt.pix;
> +
> + fmt_rect.top = 0;
> + fmt_rect.left = 0;
> + fmt_rect.width = vin->format.width;
> + fmt_rect.height = vin->format.height;
> +
> v4l2_rect_map_inside(&vin->crop, &src_rect);
> - v4l2_rect_map_inside(&vin->compose, &compose);
> + v4l2_rect_map_inside(&vin->compose, &fmt_rect);
> vin->src_rect = src_rect;
>
> return 0;
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] rcar-vin: Rename wrongly named rectangle
Hi Niklas,
Thank you for the patch.
On Wed, Oct 09, 2019 at 01:22:00AM +0200, Niklas Söderlund wrote:
> After recent refactoring the rectangle named crop no longer reflects it
> usage, to contain the source rectangle. Fix this by renaming it. There
> is no functional change.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index a7ee44dd248ea0a1..f809350c514c337c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -181,7 +181,8 @@ static int rvin_reset_format(struct rvin_dev *vin)
>
> static int rvin_try_format(struct rvin_dev *vin, u32 which,
> struct v4l2_pix_format *pix,
> -struct v4l2_rect *crop, struct v4l2_rect *compose)
> +struct v4l2_rect *src_rect,
> +struct v4l2_rect *compose)
> {
> struct v4l2_subdev *sd = vin_to_source(vin);
> struct v4l2_subdev_pad_config *pad_cfg;
> @@ -214,11 +215,11 @@ static int rvin_try_format(struct rvin_dev *vin, u32
> which,
>
> v4l2_fill_pix_format(pix, &format.format);
>
> - if (crop) {
> - crop->top = 0;
> - crop->left = 0;
> - crop->width = pix->width;
> - crop->height = pix->height;
> + if (src_rect) {
> + src_rect->top = 0;
> + src_rect->left = 0;
> + src_rect->width = pix->width;
> + src_rect->height = pix->height;
> }
>
> if (field != V4L2_FIELD_ANY)
> @@ -266,21 +267,21 @@ static int rvin_s_fmt_vid_cap(struct file *file, void
> *priv,
> struct v4l2_format *f)
> {
> struct rvin_dev *vin = video_drvdata(file);
> - struct v4l2_rect crop, compose;
> + struct v4l2_rect src_rect, compose;
> int ret;
>
> if (vb2_is_busy(&vin->queue))
> return -EBUSY;
>
> ret = rvin_try_format(vin, V4L2_SUBDEV_FORMAT_ACTIVE, &f->fmt.pix,
> - &crop, &compose);
> + &src_rect, &compose);
> if (ret)
> return ret;
>
> vin->format = f->fmt.pix;
> - v4l2_rect_map_inside(&vin->crop, &crop);
> + v4l2_rect_map_inside(&vin->crop, &src_rect);
> v4l2_rect_map_inside(&vin->compose, &compose);
> - vin->src_rect = crop;
> + vin->src_rect = src_rect;
>
> return 0;
> }
--
Regards,
Laurent Pinchart
Re: [PATCH v2] media: uvcvideo: Add a quirk to force GEO GC6500 Camera bits-per-pixel value
Hi Sergey, On Wed, Oct 02, 2019 at 09:15:45PM +0400, Sergey Zakharchenko wrote: > Sergey Zakharchenko : > > Laurent Pinchart : > > > Do you think it would make sense to do this by default, without > > > requiring a quirk ? Or are there cases where this calculation would lead > > > to incorrect results while the bpp reported by the camera would be right > > > ? > > > > The loop is a simplified version of the v4l2_fill_pixfmt() loop. The > > calculation might need some checking, and might be invalid, in case > > block_w/block_h format fields are significant (not 0 and not 1), > > because then effective bits-per-pixel would seemingly be fractional, > > and depend on the image dimensions if they weren't aligned; however I > > see no formats using the block_w/block_h fields defined so far. > > It's likely possible to directly replace the bpp-using computation in > https://github.com/torvalds/linux/blob/2874c5fd284268364ece81a7bd936f3c8168e567/drivers/media/usb/uvc/uvc_driver.c#L636 > with a call to v4l2_fill_pixfmt() and the sizeimage it returns. > However, bpp is used elsewhere, and it's hard to tell what it should > be taken to be to in the hypothetical exotic cases I'm considering, so > I'm reluctant to go that route. Would it make sense to split the calculation from v4l2_fill_pixfmt() to a helper function that the UVC driver could call ? > I'm going to send v3 in an hour unless there are other suggestions. -- Regards, Laurent Pinchart
Re: [PATCH v2] media: uvcvideo: Add a quirk to force GEO GC6500 Camera bits-per-pixel value
Hi Sergey,
Thank you for the patch.
On Wed, Oct 02, 2019 at 01:01:02PM +, Sergey Zakharchenko wrote:
> This device does not function correctly in raw mode in kernel
> versions validating buffer sizes in bulk mode. It erroneously
> announces 16 bits per pixel instead of 12 for NV12 format, so it
> needs this quirk to fix computed frame size and avoid legitimate
> frames getting discarded.
>
> Signed-off-by: Sergey Zakharchenko
> ---
> drivers/media/usb/uvc/uvc_driver.c | 27 +++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c
> index 66ee168ddc7e..23f62456946d 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -446,10 +446,12 @@ static int uvc_parse_format(struct uvc_device *dev,
> struct usb_host_interface *alts = intf->cur_altsetting;
> struct uvc_format_desc *fmtdesc;
> struct uvc_frame *frame;
> + const struct v4l2_format_info *info;
> const unsigned char *start = buffer;
> unsigned int width_multiplier = 1;
> unsigned int interval;
> unsigned int i, n;
> + unsigned int div;
> u8 ftype;
>
> format->type = buffer[2];
> @@ -497,6 +499,18 @@ static int uvc_parse_format(struct uvc_device *dev,
> }
> }
>
> + /* Some devices report bpp that doesn't match the format. */
> + if (dev->quirks & UVC_QUIRK_FORCE_BPP) {
> + info = v4l2_format_info(format->fcc);
> + if (info) {
> + div = info->hdiv * info->vdiv;
> + n = info->bpp[0] * div;
> + for (i = 1; i < info->comp_planes; i++)
> + n += info->bpp[i];
> + format->bpp = DIV_ROUND_UP(8 * n, div);
> + }
> + }
Do you think it would make sense to do this by default, without
requiring a quirk ? Or are there cases where this calculation would lead
to incorrect results while the bpp reported by the camera would be right
?
> +
> if (buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED) {
> ftype = UVC_VS_FRAME_UNCOMPRESSED;
> } else {
> @@ -2384,6 +2398,10 @@ static const struct uvc_device_info uvc_quirk_force_y8
> = {
> .quirks = UVC_QUIRK_FORCE_Y8,
> };
>
> +static const struct uvc_device_info uvc_quirk_force_bpp = {
> + .quirks = UVC_QUIRK_FORCE_BPP,
> +};
> +
> #define UVC_INFO_QUIRK(q) (kernel_ulong_t)&(struct uvc_device_info){.quirks
> = q}
> #define UVC_INFO_META(m) (kernel_ulong_t)&(struct uvc_device_info) \
> {.meta_format = m}
> @@ -2869,6 +2887,15 @@ static const struct usb_device_id uvc_ids[] = {
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> .driver_info = UVC_INFO_META(V4L2_META_FMT_D4XX) },
> + /* GEO Semiconductor GC6500 */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x29fe,
> + .idProduct= 0x4d53,
Could you please keep the entries sorted by idVendor/idProduct ?
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = (kernel_ulong_t)&uvc_quirk_force_bpp },
As this is the only device using this quirk, you can drop
uvc_quirk_force_bpp and use
.driver_info= UVC_INFO_QUIRK(UVC_QUIRK_FORCE_BPP) },
> /* Generic USB Video Class */
> { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_UNDEFINED) },
> { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_15) },
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h
> index c7c1baa90dea..24e3d8c647e7 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -198,6 +198,7 @@
> #define UVC_QUIRK_RESTRICT_FRAME_RATE0x0200
> #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x0400
> #define UVC_QUIRK_FORCE_Y8 0x0800
> +#define UVC_QUIRK_FORCE_BPP 0x1000
>
> /* Format flags */
> #define UVC_FMT_FLAG_COMPRESSED 0x0001
>
> base-commit: 20a438d53fd9d12a894161bc56cbeab7a9993c39
> prerequisite-patch-id: 521eb9602d395ea667eecc75cd2273b59cd3ed76
--
Regards,
Laurent Pinchart
Re: [PATCH v4 1/3] media: v4l2-subdev: add g_csi_active_lanes() op
Hi Philipp,
(CC'ing Sakari, Jacopo, Kieran and Niklas)
Thank you for the patch.
On Tue, Sep 24, 2019 at 01:49:53PM +0200, Philipp Zabel wrote:
> Add a subdevice video operation that allows to query the number
> of data lanes a MIPI CSI-2 TX is actively transmitting on.
>
> Suggested-by: Hans Verkuil
> Signed-off-by: Philipp Zabel
> ---
> New in v4.
> ---
> include/media/v4l2-subdev.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 71f1f2f0da53..bb71eedc38f6 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -411,6 +411,8 @@ struct v4l2_mbus_frame_desc {
> * @s_rx_buffer: set a host allocated memory buffer for the subdev. The
> subdev
> * can adjust @size to a lower value and must not write more data to the
> * buffer starting at @data than the original value of @size.
> + *
> + * @g_csi_active_lanes: Get number of currently active MIPI CSI-2 data lanes.
> */
> struct v4l2_subdev_video_ops {
> int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
> config);
> @@ -441,6 +443,7 @@ struct v4l2_subdev_video_ops {
>const struct v4l2_mbus_config *cfg);
> int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> unsigned int *size);
> + int (*g_csi_active_lanes)(struct v4l2_subdev *sd, u32 *lanes);
This shouldn't be a video operation but a pad operation, as a subdev
could have multiple CSI-2 pads.
Furthermore, you need to define the semantics of this operation more
precisely. When can it be called, when is the information valid ? Can
the subdev change the number of lanes it supports at runtime ? If so,
how are race conditions avoided ? All this needs to be documented.
Finally, the number of lanes is far from being the only information
about a physical bus that could be interesting for a remote subdev. I
would much prefer a more generic operation to retrieve bus
information/configuration, with a data structure that we will be able to
extend later.
> };
>
> /**
--
Regards,
Laurent Pinchart
Re: [ANN] Media sessions in Lyon in October: libcamera
Hello, On Tue, Sep 24, 2019 at 07:48:55PM -0300, Helen Koike wrote: > On 9/23/19 3:21 PM, Daniel Gomez wrote: > > Hi Laurent, Hans: > > On Mon, 23 Sep 2019 at 20:16, Shuah Khan wrote: > >> > >> On 9/23/19 9:57 AM, Laurent Pinchart wrote: > >>> Hello everybody, > >>> > >>> On Mon, Sep 23, 2019 at 04:03:54PM +0100, Kieran Bingham wrote: > >>>> On 23/09/2019 15:47, Nicolas Dufresne wrote: > >>>>> Le lundi 23 septembre 2019 à 16:21 +0200, Hans Verkuil a écrit : > >>>>>> 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 second session deals with libcamera and is on Wednesday morning > >>>>>> from 9:00 to 13:00. > >>>>>> > >>>>>> Attendees for this session: > >>>>>> > >>>>>> Kieran Bingham > >>>> > >>>> Unfortunately I can no longer attend ELCE. > >>>> > >>>> (My second baby will be a bit too new for an extended stay away from > >>>> home) > >>>> > >>>>>> Boris Brezillon > >>>>>> Alexandre Courbot > >>>>>> Tomasz Figa > >>>>>> Ezequiel Garcia > >>>>>> Daniel Gomez > >>>>>> Dafna Hirschfeld > >>>>>> Eugen Hristev > >>>>>> Shuah Khan > >>>>>> Helen Koike > >>>>>> Jacopo Mondi > >>>>>> Laurent Pinchart > >>>>>> Niklas Söderlund > >>>>>> Hans Verkuil > >>>>>> > >>>>>> If I missed someone, or you are on the list but won't attend after > >>>>>> all, then > >>>>>> please let me know. > >>>>> > >>>>> I would like to join this one to, as after ELCE I should have some time > >>>>> to spend on this. I understand thought hat this would make use reach > >>>>> the limit, let me know if there is any issues, I can spare my seat if > >>>>> needed. > >>>> > >>>> You now have my seat, and I've just made you a required attendee to go > >>>> in my place :-D > >>> > >>> Thank you for the offer Kieran. > >>> > >>> We're reaching the room capacity, and I know of several people who may > >>> attend ELCE and would be beneficial for the discussions. If anyone in > >>> the above list only has a general curiosity about libcamera but doesn't > >>> expect to really contribute to the discussions, and would consider > >>> giving their seat if required, could you please let me know ? > >>> > > > > I would like to attend if possible since we are going to work with libcamera > > but not sure how much I can contribute so, no problem to give my seat > > if necessary. > > Same thing for me. I also would like to attend since I intend to work on > libcamera, > more specifically in the Rockchip support part. But not sure how much I can > contribute. Given the recent offers from multiple people to give away their seat if needed, I would like to, first of all, thank everybody, and then to repeat that I will do my best to ensure that as many interested people as possible will be able to attend. This will partly depend on whether extending the room capacity will be possible, so I'm afraid the final answer will need to wait for the beginning of the conference. > >> Looks like I have a conflict with my talk for the an hour so towards the > >> end of this morning session. I might as well give up my seat so it can > >> be given to somebody that can attend the session in full. > >> > >> I am attending the afternoon session on Wednesday. -- Regards, Laurent Pinchart
Re: [ANN] Media sessions in Lyon in October: libcamera
Hi Shuah and Daniel, On Mon, Sep 23, 2019 at 08:21:58PM +0200, Daniel Gomez wrote: > On Mon, 23 Sep 2019 at 20:16, Shuah Khan wrote: > > On 9/23/19 9:57 AM, Laurent Pinchart wrote: > >> On Mon, Sep 23, 2019 at 04:03:54PM +0100, Kieran Bingham wrote: > >>> On 23/09/2019 15:47, Nicolas Dufresne wrote: > >>>> Le lundi 23 septembre 2019 à 16:21 +0200, Hans Verkuil a écrit : > >>>>> 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 second session deals with libcamera and is on Wednesday morning > >>>>> from 9:00 to 13:00. > >>>>> > >>>>> Attendees for this session: > >>>>> > >>>>> Kieran Bingham > >>> > >>> Unfortunately I can no longer attend ELCE. > >>> > >>> (My second baby will be a bit too new for an extended stay away from home) > >>> > >>>>> Boris Brezillon > >>>>> Alexandre Courbot > >>>>> Tomasz Figa > >>>>> Ezequiel Garcia > >>>>> Daniel Gomez > >>>>> Dafna Hirschfeld > >>>>> Eugen Hristev > >>>>> Shuah Khan > >>>>> Helen Koike > >>>>> Jacopo Mondi > >>>>> Laurent Pinchart > >>>>> Niklas Söderlund > >>>>> Hans Verkuil > >>>>> > >>>>> If I missed someone, or you are on the list but won't attend after all, > >>>>> then > >>>>> please let me know. > >>>> > >>>> I would like to join this one to, as after ELCE I should have some time > >>>> to spend on this. I understand thought hat this would make use reach > >>>> the limit, let me know if there is any issues, I can spare my seat if > >>>> needed. > >>> > >>> You now have my seat, and I've just made you a required attendee to go > >>> in my place :-D > >> > >> Thank you for the offer Kieran. > >> > >> We're reaching the room capacity, and I know of several people who may > >> attend ELCE and would be beneficial for the discussions. If anyone in > >> the above list only has a general curiosity about libcamera but doesn't > >> expect to really contribute to the discussions, and would consider > >> giving their seat if required, could you please let me know ? > > I would like to attend if possible since we are going to work with libcamera > but not sure how much I can contribute so, no problem to give my seat > if necessary. Thank you for the offers. My goal is to secure a seat for everybody who is interested in attending, and I will make sure to let all parties know of the success (or lack thereof) of that initiative as we get closer to the event. > > Looks like I have a conflict with my talk for the an hour so towards the > > end of this morning session. I might as well give up my seat so it can > > be given to somebody that can attend the session in full. > > > > I am attending the afternoon session on Wednesday. -- Regards, Laurent Pinchart
Re: [ANN] Media sessions in Lyon in October: codecs
Hello, (CC'ing Maxime) On Mon, Sep 23, 2019 at 05:02:13PM +0200, Jacopo Mondi wrote: > On Mon, Sep 23, 2019 at 04:12:55PM +0200, 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). > > I'm not really working on codecs, so if you're running almost at full > capacity please feel free to re-assign my seat. Same here. I think that Maxime Ripard, who isn't in the above list, would be able to contribute more than I could. > If there are free seats I might flock in, but without contributing too > much to the discussions :) > > > 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
Re: [ANN] Media sessions in Lyon in October: libcamera
Hi Hans, On Mon, Sep 23, 2019 at 04:21:04PM +0200, 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 second session deals with libcamera and is on Wednesday morning > from 9:00 to 13:00. > > Attendees for this session: > > Kieran Bingham > Boris Brezillon > Alexandre Courbot > Tomasz Figa > Ezequiel Garcia > Daniel Gomez > Dafna Hirschfeld > Eugen Hristev > Shuah Khan > Helen Koike > Jacopo Mondi > Laurent Pinchart > Niklas Söderlund > Hans Verkuil > > If I missed someone, or you are on the list but won't attend after all, then > please let me know. > > Attendees: it is probably useful if you let us know whether you have to > join this meeting because you plan to use libcamera, or if you are 'just > interested'. After the libcamera presentation on Tuesday afternoon we > should know how many of the 'just interested' list can join. > > Agenda: > > Laurent, can you fill this in? Yes, but it's a bit early still. I will make sure to fill the agenda as we get closer to the event, based on the development status and the final list of attendees, most probably mid-October. If anyone has any particular topic they would like to discuss, please let me know. -- Regards, Laurent Pinchart
Re: [ANN] Media sessions in Lyon in October: libcamera
Hello everybody, On Mon, Sep 23, 2019 at 04:03:54PM +0100, Kieran Bingham wrote: > On 23/09/2019 15:47, Nicolas Dufresne wrote: > > Le lundi 23 septembre 2019 à 16:21 +0200, Hans Verkuil a écrit : > >> 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 second session deals with libcamera and is on Wednesday morning > >> from 9:00 to 13:00. > >> > >> Attendees for this session: > >> > >> Kieran Bingham > > Unfortunately I can no longer attend ELCE. > > (My second baby will be a bit too new for an extended stay away from home) > > >> Boris Brezillon > >> Alexandre Courbot > >> Tomasz Figa > >> Ezequiel Garcia > >> Daniel Gomez > >> Dafna Hirschfeld > >> Eugen Hristev > >> Shuah Khan > >> Helen Koike > >> Jacopo Mondi > >> Laurent Pinchart > >> Niklas Söderlund > >> Hans Verkuil > >> > >> If I missed someone, or you are on the list but won't attend after all, > >> then > >> please let me know. > > > > I would like to join this one to, as after ELCE I should have some time > > to spend on this. I understand thought hat this would make use reach > > the limit, let me know if there is any issues, I can spare my seat if > > needed. > > You now have my seat, and I've just made you a required attendee to go > in my place :-D Thank you for the offer Kieran. We're reaching the room capacity, and I know of several people who may attend ELCE and would be beneficial for the discussions. If anyone in the above list only has a general curiosity about libcamera but doesn't expect to really contribute to the discussions, and would consider giving their seat if required, could you please let me know ? > > Nicolas Dufresne -- Regards, Laurent Pinchart
Re: [PATCHv4 0/3] v4l2-core: Add metadata type to vfl_devnode_type
On Mon, Sep 23, 2019 at 10:47:56AM +0200, Hans Verkuil wrote: > On 9/23/19 10:17 AM, Sakari Ailus wrote: > > On Mon, Sep 23, 2019 at 10:11:09AM +0200, Hans Verkuil wrote: > >> On 9/21/19 1:48 AM, Laurent Pinchart wrote: > >>> On Tue, Sep 17, 2019 at 03:36:44PM +0200, Hans Verkuil wrote: > >>>> This is a follow-up series from Vandana's "[v3] v4l2-core: Add metadata > >>>> type to > >>>> vfl_devnode_type" patch: https://patchwork.linuxtv.org/patch/58755/ > >>>> > >>>> While testing that v3 patch with a patched version of vivid that has > >>>> metadata > >>>> capture support, I realized that metadata should be treated the same way > >>>> as > >>>> vbi in determine_valid_ioctls(). That makes sense since vbi *is* > >>>> effectively > >>>> metadata. So I changed Vandana's patch (hence my Co-Developed-by tag) to > >>>> correctly validate the ioctls for metadata. > >>>> > >>>> I also added two follow-up patches to simplify the SDR code in that > >>>> function, > >>>> and to fix the code for v4l-touch devices (too many ioctls were enabled > >>>> for > >>>> such devices). I think the final code is easier to read as well. > >>> > >>> Quoting my reply to "[RFC] V4L2 & Metadata: switch to /dev/v4l-metaX > >>> instead of /dev/videoX]" as it may have fell through the cracks, and I > >>> don't want this series to be merged without addressing the issue, > >>> > >>> One of the reason [we didn't introduce a metadata video node type] is > >>> CSI-2 sensors and CSI-2 receivers. A CSI-2 link often carries both video > >>> and metadata using two different datatypes. From the point of view of > >>> the CSI-2 receiver or the DMA engines, video and metadata are not > >>> distinguishable, the CSI-2 receiver receives one stream with two data > >>> types, demultiplexes them, and passes them to different DMA engines. A > >>> sensor could send two video datatypes, or even conceptually two metadata > >>> data types, and this would work the exact same way, with each of the two > >>> DMA engines capturing data to buffers without caring about the contents. > >>> Given that the datatype selection happens at runtime, a given DMA engine > >> > >> 'happens at runtime': what decides this? The user-specified topology? > >> Something else? > >> > >> Is this documented somewhere? > > > > Yes. This ultimately depends on the formats configured by the user. Some of > > the formats are metadata, and with sub-stream support, these will be > > routable by different video nodes. > > > > I we designate video nodes either "metadata" or "pixel data" nodes, then > > this would need to be changed dynamically based on the format selected. I > > don't think it's really worth it, as the user space also doesn't expect the > > node type to change. > > So these video device nodes will need to have both VIDEO_CAPTURE and > METADATA_CAPTURE > set in the device_caps field as returned by VIDIOC_QUERYCAP. Both are needed, > otherwise userspace wouldn't know that it can call ENUM_FMT with both buf > types. > > When the format is changed from video to metadata or vice versa, then the > driver > will have to change the type field in the vb2_queue struct to correspond with > the > chosen format. > > This also means that in determine_valid_ioctls() in v4l2-dev.c I will have to > check vdev->device_caps if this is a video node that can switch between video > and metadata mode dynamically. > > Is this correct? There's a bit of a chicken-and-egg problem though, as the queue type would need to be changed in response to a VIDIO_S_FMT call... > >> To my knowledge there are no drivers that can do this in mainline code, > >> right? The current drivers all create dedicated metadata devices. > > > > Not right now, no. But it's just a question of when, not if. > > This should be emulated by vivid or possibly vimc. That way we can ensure that > the API is correct and that v4l2-compliance can check this properly. > > Next time we MUST have proper emulation and tests in place before we add > such features. > > >> Also, this specific use-case is for capture only. Do you think this > >> might be needed for metadata output as well? > > > > As Laurent noted, the DMA engines don't know the data they handle, so in > > principle it's possible that this could be relevant for output, too. -- Regards, Laurent Pinchart
Re: [PATCHv4 0/3] v4l2-core: Add metadata type to vfl_devnode_type
Hi Hans, On Tue, Sep 17, 2019 at 03:36:44PM +0200, Hans Verkuil wrote: > This is a follow-up series from Vandana's "[v3] v4l2-core: Add metadata type > to > vfl_devnode_type" patch: https://patchwork.linuxtv.org/patch/58755/ > > While testing that v3 patch with a patched version of vivid that has metadata > capture support, I realized that metadata should be treated the same way as > vbi in determine_valid_ioctls(). That makes sense since vbi *is* effectively > metadata. So I changed Vandana's patch (hence my Co-Developed-by tag) to > correctly validate the ioctls for metadata. > > I also added two follow-up patches to simplify the SDR code in that function, > and to fix the code for v4l-touch devices (too many ioctls were enabled for > such devices). I think the final code is easier to read as well. Quoting my reply to "[RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX]" as it may have fell through the cracks, and I don't want this series to be merged without addressing the issue, One of the reason [we didn't introduce a metadata video node type] is CSI-2 sensors and CSI-2 receivers. A CSI-2 link often carries both video and metadata using two different datatypes. From the point of view of the CSI-2 receiver or the DMA engines, video and metadata are not distinguishable, the CSI-2 receiver receives one stream with two data types, demultiplexes them, and passes them to different DMA engines. A sensor could send two video datatypes, or even conceptually two metadata data types, and this would work the exact same way, with each of the two DMA engines capturing data to buffers without caring about the contents. Given that the datatype selection happens at runtime, a given DMA engine is thus not dedicated to video or metadata, any of the DMA engines (and there could also be more than two) could handle any type of data. For this type of system we thus can't dedicate device nodes to video or metadata, they need to support either. > Hans Verkuil (2): > v4l2-dev: simplify the SDR checks > v4l2-dev: fix is_tch checks > > Vandana BN (1): > v4l2-core: Add metadata type to vfl_devnode_type > > drivers/media/v4l2-core/v4l2-dev.c | 97 > drivers/media/v4l2-core/v4l2-ioctl.c | 5 +- > include/media/v4l2-dev.h | 2 + > 3 files changed, 61 insertions(+), 43 deletions(-) -- Regards, Laurent Pinchart
Re: [RFC, v3, 1/4] dt-binding: mt8183: Add Mediatek MDP3 dt-bindings
};
> +
> + mdp_rsz1: mdp_rsz1@14004000 {
> + compatible = "mediatek,mt8183-mdp-rsz";
> + mediatek,mdp-id = <1>;
> + reg = <0 0x14004000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400 0x4000
> 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ1>;
> + };
> +
> + mdp_wrot0: mdp_wrot0@14005000 {
> + compatible = "mediatek,mt8183-mdp-wrot";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14005000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400 0x5000
> 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WROT0>;
> + iommus = <&iommu M4U_PORT_MDP_WROT0>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + mdp_path0_sout@14005000 {
> + compatible = "mediatek,mt8183-mdp-path";
> + mediatek,mdp-id = <0>;
> + };
> +
> + mdp_wdma: mdp_wdma@14006000 {
> + compatible = "mediatek,mt8183-mdp-wdma";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x14006000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400 0x6000
> 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WDMA0>;
> + iommus = <&iommu M4U_PORT_MDP_WDMA0>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + mdp_path1_sout@14006000 {
> + compatible = "mediatek,mt8183-mdp-path";
> + mediatek,mdp-id = <1>;
> + };
> +
> + mdp_ccorr: mdp_ccorr@1401c000 {
> + compatible = "mediatek,mt8183-mdp-ccorr";
> + mediatek,mdp-id = <0>;
> + reg = <0 0x1401c000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401 0xc000
> 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_CCORR>;
> + };
--
Regards,
Laurent Pinchart
Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote: > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter > wrote: > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > > > +Patches for the media subsystem should be sent to the media mailing > > > > > list > > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > > +HTML will be automatically rejected by the mail server. There's no > > > > > need > > > > > +to copy the maintainer or sub-maintainer(s). > > > > > > > > There's too much traffic on mailing lists for me to follow everything, I > > > > much prefer being CC'ed on patches. > > > > > > Well, by using patchwork, the best is to take a look on it at least for > > > the patches that you're interested. You could script something using > > > pwclient in order to make it easier. > > > > > > Anyway, not sure if the other sub-maintainers see the same way. From my > > > side, > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > patchwork for media patches. What about changing this to: > > > > > > Patches for the media subsystem should be sent to the media mailing > > > list > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails > > > with > > > HTML will be automatically rejected by the mail server. It could be > > > wise > > > to also copy the sub-maintainer(s). > > > > The documentation should say "Use get_maintainer.pl" and do what it > > says. Everything else is too complicated. > > +1 > > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > Cook from the CC list because they worked all over the tree and I know > > them. I also normally remove LKML if there is another mailing list but > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > So the safest instructions are "Use get_matainer.pl and add the person > > who wrote the commit in the Fixes tag". > > Better: perhaps get_maintainer.pl can be taught to add the author of the > commit pointed to by the Fixes tag, if present? And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up get_maintainer.pl a bit is a good idea. I'm for instance not sure adding LKML automatically is a good idea if other mailing lists are already CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it when no other mailing list is appropriate certainly makes sense). -- Regards, Laurent Pinchart
Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
Hi Mauro, On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 18 Sep 2019 15:36:20 +0300 Laurent Pinchart escreveu: > > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > > > Document the basic policies of the media subsystem profile. > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > --- > > > > > > That's basically a modified version of: > > > https://patchwork.linuxtv.org/patch/52999/ > > > > > > Applied to the new template > > > > > > Documentation/media/index.rst | 1 + > > > .../media/maintainer-entry-profile.rst| 140 ++ > > > MAINTAINERS | 1 + > > > 3 files changed, 142 insertions(+) > > > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > > > > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > > > index 0301c25ff887..ac94685b822a 100644 > > > --- a/Documentation/media/index.rst > > > +++ b/Documentation/media/index.rst > > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > > > .. toctree:: > > > :maxdepth: 2 > > > > > > + maintainer-entry-profile > > > media_uapi > > > media_kapi > > > dvb-drivers/index > > > diff --git a/Documentation/media/maintainer-entry-profile.rst > > > b/Documentation/media/maintainer-entry-profile.rst > > > new file mode 100644 > > > index ..81d3b0f9c36a > > > --- /dev/null > > > +++ b/Documentation/media/maintainer-entry-profile.rst > > > @@ -0,0 +1,140 @@ > > > +Media Subsystem Profile > > > +=== > > > + > > > +Overview > > > + > > > + > > > +The media subsystem cover support for a variety of devices: stream > > > > s/cover/covers/ > > > > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > > > +and media pipeline control. > > > + > > > +It covers, mainly, the contents of those directories: > > > + > > > + - drivers/media > > > + - drivers/staging/media > > > + - Documentation/media > > > + - include/media > > > + > > > +Both media userspace and Kernel APIs are documented and should be kept in > > > +sync with the API changes. It means that all patches that add new > > > +features to the subsystem should also bring changes to the corresponding > > > +API files. > > > + > > > +Also, patches for device drivers that changes the Open Firmware/Device > > > +Tree bindings should be reviewed by the Device Tree maintainers. > > > > You may want to make it clear that this covers bindings only, not driver > > code that parses the DT. I would just remove "for device drivers", as > > the rule should also apply to DT bindings documentation that is not > > driver-specific. > > > > > +Due to the size and wide scope of the media subsystem, media's > > > +maintainership model is to have sub-maintainers that have a broad > > > +knowledge of an specific aspect of the subsystem. It is a > > > +sub-maintainers task to review the patches, providing feedback to users > > > > s/sub-maintainers/sub-maintainer's/ > > > > > +if the patches are following the subsystem rules and are properly using > > > +the media internal and external APIs. > > > + > > > +Patches for the media subsystem should be sent to the media mailing list > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > +HTML will be automatically rejected by the mail server. There's no need > > > +to copy the maintainer or sub-maintainer(s). > > > > There's too much traffic on mailing lists for me to follow everything, I > > much prefer being CC'ed on patches. > > Well, by using patchwork, the best is to take a look on it at least for > the patches that you're interested. You could script something using > pwclient in order to make it easier. > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > I prefer not to be c/c, as this is just more noise, as I just rely on > patchwork for media patches. What about changing this to: > > Patches for the media subsystem should be sent to the media mailing list > at linux-media@vger.kernel.org as plain text only e-mail. Emails w
Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
Hi Mauro, On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > Document the basic policies of the media subsystem profile. > > Signed-off-by: Mauro Carvalho Chehab > --- > > That's basically a modified version of: > https://patchwork.linuxtv.org/patch/52999/ > > Applied to the new template > > Documentation/media/index.rst | 1 + > .../media/maintainer-entry-profile.rst| 140 ++ > MAINTAINERS | 1 + > 3 files changed, 142 insertions(+) > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > index 0301c25ff887..ac94685b822a 100644 > --- a/Documentation/media/index.rst > +++ b/Documentation/media/index.rst > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > .. toctree:: > :maxdepth: 2 > > + maintainer-entry-profile > media_uapi > media_kapi > dvb-drivers/index > diff --git a/Documentation/media/maintainer-entry-profile.rst > b/Documentation/media/maintainer-entry-profile.rst > new file mode 100644 > index ..81d3b0f9c36a > --- /dev/null > +++ b/Documentation/media/maintainer-entry-profile.rst > @@ -0,0 +1,140 @@ > +Media Subsystem Profile > +=== > + > +Overview > + > + > +The media subsystem cover support for a variety of devices: stream s/cover/covers/ > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > +and media pipeline control. > + > +It covers, mainly, the contents of those directories: > + > + - drivers/media > + - drivers/staging/media > + - Documentation/media > + - include/media > + > +Both media userspace and Kernel APIs are documented and should be kept in > +sync with the API changes. It means that all patches that add new > +features to the subsystem should also bring changes to the corresponding > +API files. > + > +Also, patches for device drivers that changes the Open Firmware/Device > +Tree bindings should be reviewed by the Device Tree maintainers. You may want to make it clear that this covers bindings only, not driver code that parses the DT. I would just remove "for device drivers", as the rule should also apply to DT bindings documentation that is not driver-specific. > +Due to the size and wide scope of the media subsystem, media's > +maintainership model is to have sub-maintainers that have a broad > +knowledge of an specific aspect of the subsystem. It is a > +sub-maintainers task to review the patches, providing feedback to users s/sub-maintainers/sub-maintainer's/ > +if the patches are following the subsystem rules and are properly using > +the media internal and external APIs. > + > +Patches for the media subsystem should be sent to the media mailing list > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > +HTML will be automatically rejected by the mail server. There's no need > +to copy the maintainer or sub-maintainer(s). There's too much traffic on mailing lists for me to follow everything, I much prefer being CC'ed on patches. > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > +is submitted, it should appear at: > + > + - https://patchwork.linuxtv.org/project/linux-media/list/ > + > +If it doesn't automatically appear there after a few minutes, then > +probably something got wrong on your submission. Please check if the > +email is in plain text only and if your emailer is not mangling with > +whitespaces before complaining or submit it again. > + > +Sub-maintainers > > + > +At the media subsystem, we have a group of senior developers that are How about "experienced" instead of "senior" ? Quality doesn't always come with age, neither for people nor wine :-) > +responsible for doing the code reviews at the drivers (called > +sub-maintainers), and another senior developer responsible for the > +subsystem as a hole. For core changes, whenever possible, multiple > +media (sub-)maintainers do the review. > + > +The sub-maintainers work on specific areas of the subsystem, as > +described below: > + > +Digital TV: > + Sean Young > + > +HDMI CEC: > + Hans Verkuil > + > +Media controller drivers: > + Laurent Pinchart > + > +Remote Controllers: > + Sean Young > + > +Sensor drivers: > + Sakari Ailus > + > +V4L2 drivers: > + Hans Verkuil > + > +Submit Checklist Addendum > +- > + > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > +t
Re: [ANN] Topics for a media summit in Lyon in October
Hi Angelo, On Mon, Sep 16, 2019 at 10:39:56AM +, Angelo Ribeiro wrote: > On Mon, Sep 16, 2019 at 10:54:51 Laurent Pinchart wrote: > > On Mon, Sep 16, 2019 at 10:48:51AM +0200, Hans Verkuil wrote: > > > On 9/16/19 10:40 AM, Jose Abreu wrote: > > > > From: Hans Verkuil > > > > Date: Aug/16/2019, 09:06:30 (UTC+00:00) > > > > > > > >> Rather then discussing topics for a meeting under the subject 'Lisbon' > > > >> let's start a new thread referring to the right place :-) > > > >> > > > >> I will try to organize a room, either during the ELCE or (if that > > > >> doesn't > > > >> work) perhaps on the Thursday afterwards. If that's going to be a > > > >> problem > > > >> for someone, please let me know. > > > >> > > > >> I do need to know how many people I can expect. I have the following > > > >> confirmed attendees (and please reply if you are not listed!): > > > > > > > > Hi Hans, > > > > > > > > It's been a while, hope you are doing well :) > > > > > > > > I'm no longer working in media subsystem but my colleagues Angelo and > > > > Joao would like to attend. > > > > > > > > We currently have HDMI and CSI support for our IPs using V4L2 and we > > > > would like to interact with the community in order to get this > > > > up-streamed so that we have as many features supported as possible. > > > > > > > > Is it possible ? > > > > > > Yes. That said, since this is fairly specific and doesn't fall into any of > > > the three discussions that we plan (codecs, libcamera, future > > > developments) > > > I think it is more useful if I discuss this separately with Angelo and > > > Joao on Monday or Tuesday afternoon. > > > > > > I can definitely discuss HDMI support, and probably give a good stab at > > > the > > > CSI support (too bad Sakari won't be there). > > > > > > How about we get together after Greg KH's keynote on Monday? > > > > I'll try to join as well. I've run into issues in the past with the > > development process related to an HDMI IP (but on the DRM/KMS side), and > > I'd like to try and avoid the same mistakes here. > > Thanks for the meeting proposal, for me sounds great. > Currently I'm building a DRM/KMS video pipeline for our HW solution with > Synopsys DSI IP, that is supported by the dw-mipi-dsi driver. Can you share details about the part of the pipeline before the DSI encoder ? Are there Synopsys IPs there too, or is the DSI encoder connected to a display controller from the SoC vendor ? > Also I'm going to support the DesignWare MIPI CSI-2 Host and D-PHY > that uses V4l2. -- Regards, Laurent Pinchart
Re: [ANN] Topics for a media summit in Lyon in October
On Mon, Sep 16, 2019 at 10:48:51AM +0200, Hans Verkuil wrote: > On 9/16/19 10:40 AM, Jose Abreu wrote: > > From: Hans Verkuil > > Date: Aug/16/2019, 09:06:30 (UTC+00:00) > > > >> Rather then discussing topics for a meeting under the subject 'Lisbon' > >> let's start a new thread referring to the right place :-) > >> > >> I will try to organize a room, either during the ELCE or (if that doesn't > >> work) perhaps on the Thursday afterwards. If that's going to be a problem > >> for someone, please let me know. > >> > >> I do need to know how many people I can expect. I have the following > >> confirmed attendees (and please reply if you are not listed!): > > > > Hi Hans, > > > > It's been a while, hope you are doing well :) > > > > I'm no longer working in media subsystem but my colleagues Angelo and > > Joao would like to attend. > > > > We currently have HDMI and CSI support for our IPs using V4L2 and we > > would like to interact with the community in order to get this > > up-streamed so that we have as many features supported as possible. > > > > Is it possible ? > > Yes. That said, since this is fairly specific and doesn't fall into any of > the three discussions that we plan (codecs, libcamera, future developments) > I think it is more useful if I discuss this separately with Angelo and > Joao on Monday or Tuesday afternoon. > > I can definitely discuss HDMI support, and probably give a good stab at the > CSI support (too bad Sakari won't be there). > > How about we get together after Greg KH's keynote on Monday? I'll try to join as well. I've run into issues in the past with the development process related to an HDMI IP (but on the DRM/KMS side), and I'd like to try and avoid the same mistakes here. -- Regards, Laurent Pinchart
Re: [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX
Hi Hans, On Thu, Sep 12, 2019 at 09:48:11AM +0200, Hans Verkuil wrote: > Hi all, > > I am increasingly unhappy about the choice of /dev/videoX for metadata > devices. > > It is confusing for end-users (especially w.r.t. the common uvc driver) and > if we want to change this, then we need to do it soon. > > This patch https://patchwork.linuxtv.org/patch/58693/ adds a new > VFL_TYPE_METADATA > so at least drivers can now explicitly signal that they want to register a > metadata device. > > This also makes it possible to add a kernel config option that allows you > to select whether you want metadata devices to appear as videoX or v4l-metaX. > I would prefer to set it to v4l-metaX by default. > > We can also consider backporting this to the stable/long-term kernels. > > Metadata capture was introduced in 4.12 for the vsp1 driver, in 4.16 for the > uvc driver and in 5.0 for the staging ipu3 driver. > > Does someone remember the reason why we picked /dev/videoX for this in the > first place? One of the reason is CSI-2 sensors and CSI-2 receivers. A CSI-2 link often carries both video and metadata using two different datatypes. >From the point of view of the CSI-2 receiver or the DMA engines, video and metadata are not distinguishable, the CSI-2 receiver receives one stream with two data types, demultiplexes them, and passes them to different DMA engines. A sensor could send two video datatypes, or even conceptually two metadata data types, and this would work the exact same way, with each of the two DMA engines capturing data to buffers without caring about the contents. Given that the datatype selection happens at runtime, a given DMA engine is thus not dedicated to video or metadata, any of the DMA engines (and there could also be more than two) could handle any type of data. For this type of system we thus can't dedicate device nodes to video or metadata, they need to support either. -- Regards, Laurent Pinchart
Re: [PATCH] rcar-vin: Do not enumerate unsupported pixel formats
Hi Niklas,
Thank you for the patch.
On Fri, Sep 06, 2019 at 04:35:00PM +0200, Niklas Söderlund wrote:
> If a pixel format is not supported by the hardware NULL is returned by
> rvin_format_from_pixel() for that fourcc. Verify that the pixel format
> is supported using this or skip it when enumerating.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index cbc1c07f0a9631a4..ba08f6c49956e899 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -302,10 +302,20 @@ static int rvin_g_fmt_vid_cap(struct file *file, void
> *priv,
> static int rvin_enum_fmt_vid_cap(struct file *file, void *priv,
>struct v4l2_fmtdesc *f)
> {
> + struct rvin_dev *vin = video_drvdata(file);
> + unsigned int i, skip = 0;
This doesn't seem right. Let's consider, as initial conditions,
rvin_formats = { RGB, unsupported, unsupported, YUV }
ARRAY_SIZE(rvin_formats) == 4
f->index = 1
You want to return YUV.
> +
> if (f->index >= ARRAY_SIZE(rvin_formats))
> return -EINVAL;
This check will pass.
> - f->pixelformat = rvin_formats[f->index].fourcc;
> + for (i = 0; i <= f->index; i++)
> + if (!rvin_format_from_pixel(vin, rvin_formats[i].fourcc))
> + skip++;
This loop will have two iterations, i == 0 and i == 1. The second
iteration will increase skip, so skip == 1.
> +
> + if (f->index + skip >= ARRAY_SIZE(rvin_formats))
> + return -EINVAL;
This check will pass.
> +
> + f->pixelformat = rvin_formats[f->index + skip].fourcc;
This will return unsupported format.
>
> return 0;
> }
--
Regards,
Laurent Pinchart
Re: [PATCH v2] media: mc-device.c: fix memleak in media_device_register_entity
Hi Sakari, On Fri, Sep 06, 2019 at 01:11:34PM +0300, Sakari Ailus wrote: > On Fri, Sep 06, 2019 at 12:12:03PM +0300, Laurent Pinchart wrote: > > On Mon, Aug 19, 2019 at 09:51:30AM +0800, zhengbin wrote: > > > In media_device_register_entity, if media_graph_walk_init fails, > > > need to free the previously memory. > > > > > > Reported-by: Hulk Robot > > > Signed-off-by: zhengbin > > > > This looks good to me. > > > > Reviewed-by: Laurent Pinchart > > > > and applied to my tree, for v5.5. > > Hmm. This is in my tree as well. Would you like to drop it from yours? :-) Sure :-) I wonder if we should setup a shared git tree for this. -- Regards, Laurent Pinchart
Re: [PATCH v2] media: mc-device.c: fix memleak in media_device_register_entity
Hello Zhengbin,
On Mon, Aug 19, 2019 at 09:51:30AM +0800, zhengbin wrote:
> In media_device_register_entity, if media_graph_walk_init fails,
> need to free the previously memory.
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
This looks good to me.
Reviewed-by: Laurent Pinchart
and applied to my tree, for v5.5.
> ---
> drivers/media/mc/mc-device.c | 65
> ++--
> 1 file changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/media/mc/mc-device.c b/drivers/media/mc/mc-device.c
> index e19df51..da80883 100644
> --- a/drivers/media/mc/mc-device.c
> +++ b/drivers/media/mc/mc-device.c
> @@ -575,6 +575,38 @@ static void media_device_release(struct media_devnode
> *devnode)
> dev_dbg(devnode->parent, "Media device released\n");
> }
>
> +static void __media_device_unregister_entity(struct media_entity *entity)
> +{
> + struct media_device *mdev = entity->graph_obj.mdev;
> + struct media_link *link, *tmp;
> + struct media_interface *intf;
> + unsigned int i;
> +
> + ida_free(&mdev->entity_internal_idx, entity->internal_idx);
> +
> + /* Remove all interface links pointing to this entity */
> + list_for_each_entry(intf, &mdev->interfaces, graph_obj.list) {
> + list_for_each_entry_safe(link, tmp, &intf->links, list) {
> + if (link->entity == entity)
> + __media_remove_intf_link(link);
> + }
> + }
> +
> + /* Remove all data links that belong to this entity */
> + __media_entity_remove_links(entity);
> +
> + /* Remove all pads that belong to this entity */
> + for (i = 0; i < entity->num_pads; i++)
> + media_gobj_destroy(&entity->pads[i].graph_obj);
> +
> + /* Remove the entity */
> + media_gobj_destroy(&entity->graph_obj);
> +
> + /* invoke entity_notify callbacks to handle entity removal?? */
> +
> + entity->graph_obj.mdev = NULL;
> +}
> +
> /**
> * media_device_register_entity - Register an entity with a media device
> * @mdev:The media device
> @@ -632,6 +664,7 @@ int __must_check media_device_register_entity(struct
> media_device *mdev,
>*/
> ret = media_graph_walk_init(&new, mdev);
> if (ret) {
> + __media_device_unregister_entity(entity);
> mutex_unlock(&mdev->graph_mutex);
> return ret;
> }
> @@ -644,38 +677,6 @@ int __must_check media_device_register_entity(struct
> media_device *mdev,
> }
> EXPORT_SYMBOL_GPL(media_device_register_entity);
>
> -static void __media_device_unregister_entity(struct media_entity *entity)
> -{
> - struct media_device *mdev = entity->graph_obj.mdev;
> - struct media_link *link, *tmp;
> - struct media_interface *intf;
> - unsigned int i;
> -
> - ida_free(&mdev->entity_internal_idx, entity->internal_idx);
> -
> - /* Remove all interface links pointing to this entity */
> - list_for_each_entry(intf, &mdev->interfaces, graph_obj.list) {
> - list_for_each_entry_safe(link, tmp, &intf->links, list) {
> - if (link->entity == entity)
> - __media_remove_intf_link(link);
> - }
> - }
> -
> - /* Remove all data links that belong to this entity */
> - __media_entity_remove_links(entity);
> -
> - /* Remove all pads that belong to this entity */
> - for (i = 0; i < entity->num_pads; i++)
> - media_gobj_destroy(&entity->pads[i].graph_obj);
> -
> - /* Remove the entity */
> - media_gobj_destroy(&entity->graph_obj);
> -
> - /* invoke entity_notify callbacks to handle entity removal?? */
> -
> - entity->graph_obj.mdev = NULL;
> -}
> -
> void media_device_unregister_entity(struct media_entity *entity)
> {
> struct media_device *mdev = entity->graph_obj.mdev;
--
Regards,
Laurent Pinchart
Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
caling or the driver code
> >> itself? It would be undesirable to do such scaling in a kernel driver,
> >> so if that's not something handled by the hardware, the downscaled
> >> image might need to be provided from the userspace.
> >
> > Thanks for your comments.
> >
> > Yes, FD hardware will do the scaling itself, so driver could set the
> > sizes.
> >
> >> >, besides driver default values, user or proprietary
> >>> algorithm library can manually set the desired image sizes, therefore,
> >>> we would need the following controls:
> >>> V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH and
> >>> V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT.
> >>> In MTK FD driver, we implement these controls as array of
> >>> V4L2_CTRL_TYPE_U16 with the dimension 15.
> >>
> >> Why 15?
> >
> > It consists of one input image size and 14 down-scaled image sizes,
> > the amount 15 (or say 14) is defined by the MTK FD algo library,
> > therefore I remain the number of 15 here for communicate with the
> > library.
> > Maybe it should be defined as following?
> > MTK_FD_MAX_SCALE_SIZE_NUM 14
> > and
> > MTK_FD_SCALE_ARR_NUM15
> >
> >>> For controlling detection speed, we would need the
> >>> V4L2_CID_DETECT_SPEED, the faster speedup implies the lower accuracy of
> >>> detection, In MTK FD driver, the max level of speedup is 7, and default
> >>> value is 0.
> >>>
> >>> For MTK FD algorithm user library, they would need select extra
> >>> detection features(models) used in HW, we need
> >>> V4L2_CID_MTK_FD_EXTRA_MODEL, this will be set to 1 for using extra
> >>> model. However, we are considering make this control more
> >>> chip-independent and can be added into standard.
> >>> for example, V4L2_CID_DETECTION_FD_MODEL or ...FD_ALGO,
> >>> drivers can define the detection algorithm or detection model to be used
> >>> for users to select. How do you think?
> >>
> >> Sounds like something that could be a menu control, so it could vary
> >> between drivers.
> >
> > Ok, and maybe it should be created by v4l2_ctrl_new_int_menu(...)?
> >
> >>> In short, I summery the control IDs as following:
> >>> V4L2_CID_DETECT_ANGLE: set the angle of face in degrees. 90 ~ -90
> >>> degrees.
> >>> V4L2_CID_DETECT_DIRECTION: set the rotation of the head in degrees.
> >>> 0~330 degrees.
> >>> V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH: set the image widths for an input
> >>> image to be scaled down for face detection
> >>> V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT: set the image heights for an
> >>> input image to be scaled down for face detection
> >>> V4L2_CID_DETECT_SPEED: set the detection speed, usually reducing
> >>> accuracy.
> >>> V4L2_CID_DETECTION_FD_MODEL: select the detection model or algorithm to
> >>> be used by face detection driver.
> >>>
> >>>>> +#define ENABLE_FD 0x111
> >>>>> +#define FD_HW_ENABLE 0x4
> >>>>> +#define FD_INT_EN 0x15c
> >>>>> +#define FD_INT 0x168
> >>>>> +#define FD_RESULT 0x178
> >>>>> +#define FD_IRQ_MASK0x001
> >>>>> +
> >>>>> +#define RS_MAX_BUF_SIZE2288788
> >>>>> +#define FD_MAX_SPEEDUP 7
> >>>>> +#define FD_MAX_POSE_VAL0xfff
> >>>>> +#define FD_DEF_POSE_VAL0x3ff
> >>>>> +#define MAX_FD_SEL_NUM 1026
> >>>>
> >>>> If that file is supposed to be included by anything beyond the driver
> >>>> itself, we need proper prefixing. (same for anything else in here)
> >>>
> >>> I will fix it as following:
> >>>
> >>> #define FD_ENABLE0x111
> >>>
> >>> #define FD_REG_OFFSET_HW_ENABLE 0x4
> >>> #define FD_REG_OFFSET_INT_EN 0x15c
> >>> #define FD_REG_OFFSET_INT_VAL0x168
> >>> #define FD_REG_OFFSET_RESULT 0x178
> >>>
> >>> #define FD_IRQ_MASK 1
> >>> #define FD_MAX_RS_BUF_SIZE 2288788
> >>> #define FD_MAX_SPEEDUP 7
> >>> #define FD_MAX_RESULT_NUM 1026
> >>
> >> I'd suggest the MTK_FD_ prefix.
> >
> > Ok, I will use MTK_FD_ prefix.
> >
> >>>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>>>> b/include/uapi/linux/v4l2-controls.h
> >>>>> index 3dcfc61..eae876e 100644
> >>>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>>> @@ -192,6 +192,10 @@ enum v4l2_colorfx {
> >>>>> * We reserve 16 controls for this driver. */
> >>>>> #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE
> >>>>> + 0x10b0)
> >>>>>
> >>>>> +/* The base for the mediatek FD driver controls */
> >>>>> +/* We reserve 16 controls for this driver. */
> >>>>> +#define V4L2_CID_USER_MTK_FD_BASE (V4L2_CID_USER_BASE +
> >>>>> 0x10d0)
> >>>>
> >>>> Why only the base, but not the actual IDs in uapi ?
> >>>>
> >>> I will put actual IDs in uapi/ for user to reference.
>
> Enrico, any thoughts on the explanation that Jerry provided and
> further discussion above?
I agree with Enrico that standardising the face detection API is the way
to go.
--
Regards,
Laurent Pinchart
Re: [RFC PATCH V2 3/4] media: platform: Add Mediatek FD driver KConfig
Hi Jerry, Thank you for the patch. On Tue, Jul 09, 2019 at 04:41:11PM +0800, Jerry-ch Chen wrote: > From: Jerry-ch Chen > > This patch adds KConfig for Mediatek Face Detection driver (FD). > FD is embedded in Mediatek SoCs. It can provide hardware > accelerated face detection function. > > Signed-off-by: Jerry-ch Chen You can squash this patch with 4/4, there's no need to keep it separate. > --- > drivers/media/platform/Kconfig| 2 ++ > drivers/media/platform/mtk-isp/fd/Kconfig | 17 + > 2 files changed, 19 insertions(+) > create mode 100644 drivers/media/platform/mtk-isp/fd/Kconfig > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index a505e9f..ae99258e 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -32,6 +32,8 @@ source "drivers/media/platform/davinci/Kconfig" > > source "drivers/media/platform/omap/Kconfig" > > +source "drivers/media/platform/mtk-isp/fd/Kconfig" > + > config VIDEO_ASPEED > tristate "Aspeed AST2400 and AST2500 Video Engine driver" > depends on VIDEO_V4L2 > diff --git a/drivers/media/platform/mtk-isp/fd/Kconfig > b/drivers/media/platform/mtk-isp/fd/Kconfig > new file mode 100644 > index 000..0c5eaf0 > --- /dev/null > +++ b/drivers/media/platform/mtk-isp/fd/Kconfig > @@ -0,0 +1,17 @@ > +config VIDEO_MEDIATEK_FD > + bool "Mediatek face detection processing function" > + select DMA_SHARED_BUFFER > + select VIDEOBUF2_DMA_CONTIG > + select VIDEOBUF2_CORE > + select VIDEOBUF2_V4L2 > + select VIDEOBUF2_MEMOPS > + select VIDEOBUF2_VMALLOC Do you need both VIDEOBUF2_DMA_CONTIG and VIDEOBUF2_VMALLOC ? The driver doesn't seem to make use of VIDEOBUF2_VMALLOC. > + select MEDIA_CONTROLLER > + > + default n > + help > + Support the Face Detectioin (FD) feature. s/Detectioin/Detection/ Maybe "... feature found in the Mediatek SoCs." ? > + > + FD driver is a V4L2 memory-to-memory device driver which > + provides hardware accelerated face detection function, > + it can detect different sizes of faces in a raw image. -- Regards, Laurent Pinchart
Re: [PATCH v2 01/10] media: dt-bindings: Document 'location' property
Hi Jacopo, On Mon, Sep 02, 2019 at 09:48:30PM +0200, Jacopo Mondi wrote: > On Mon, Sep 02, 2019 at 07:49:37PM +0300, Laurent Pinchart wrote: > > On Mon, Sep 02, 2019 at 06:40:31PM +0200, Jacopo Mondi wrote: > >> On Mon, Sep 02, 2019 at 02:38:40PM +0100, Rob Herring wrote: > >>> On Thu, Aug 29, 2019 at 02:46:40PM +0200, Jacopo Mondi wrote: > >>>> On Tue, Aug 27, 2019 at 03:21:26PM +0300, Laurent Pinchart wrote: > >>>>> On Tue, Aug 27, 2019 at 11:23:27AM +0200, Jacopo Mondi wrote: > >>>>>> Add the 'location' device property, used to specify the camera device > >>>>>> mounting position. The property is particularly meaningful for mobile > >>>>>> devices with a well defined usage orientation. > >>>>>> > >>>>>> Signed-off-by: Jacopo Mondi > >>>>>> --- > >>>>>> .../devicetree/bindings/media/video-interfaces.txt | 10 ++ > >>>>>> 1 file changed, 10 insertions(+) > >>>>>> > >>>>>> diff --git > >>>>>> a/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>>>> b/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>>>> index f884ada0bffc..865f4142f432 100644 > >>>>>> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>>>> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>>>> @@ -89,6 +89,16 @@ Optional properties > >>>>>>but a number of degrees counter clockwise. Typical values are 0 and > >>>>>> 180 > >>>>>>(upside down). > >>>>>> > >>>>>> +- location: The camera sensor mounting location, expressed as a > >>>>>> position > >>>>>> + relative to the usage orientation of the device the sensor is > >>>>>> installed on. > >>>>> > >>>>> DT bindings being ABIs, we need to be precise and thorough there. One > >>>>> particular point that bothers me is that the property is named location, > >>>>> and its description refers to camera sensor mounting location. > >>>>> > >>>>> I see two options to fix this. One of them is to rename the property to > >>>>> camera-location, but that would limit its future usage for other types > >>>>> of devices. The other one is to document the property as applying to a > >>>>> "device" instead of a "camera sensor", and add one sentence stating that > >>>>> this property is valid for camera sensors only. > >>>>> > >>>>> This will require finding another name for the device that the device is > >>>>> mounted on though, as using device twice would be very confusing. > >>>> > >>>> I had the same concern, but I cannot find another term to convey > >>>> this... suggestions? > >>> > >>> For accelerometers and/or gyroscopes, we already have 'mount-matrix'. > >> > >> Pardon my ignorance, but I could not find it documented. Some binding > >> files refers to an iio/mount-matrix.txt file which I cannot find. Has > >> it been removed? Anyway, some individual bindings report examples of > >> mount matrices (ie > >> Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt) > >> > >>> That would replace 'rotation'. Maybe we can do something similar here? > >> > >> I think 'rotation' simply expressed as degrees is fine here, our > >> problem was to find a term that would make it possible to specify that > >> rotation/location are applied to a 'device' mounted on a 'device'. > >> Sakari suggested on irc to use 'system' in place of the second > >> 'device' and that seems to work well to me. > >> > >> Or were you suggesting to use a construct similar to mount-matrix for > >> a purpose I didn't get :) ? > > > > mount-matrix would allow exposing the rotation in a more generic way, > > and if there are standard DT bindings, I think this would make sense, > > especially given that we could have device with camera sensors not > > mounted parallel to the device side. > > After reading this entry you pointed me to > https://lore.kernel.org/patchwork/patch/1044786/ > I un
Re: [PATCH v2 03/10] media: v4l2-ctrl: Document V4L2_CID_CAMERA_SENSOR_ROTATION
Hi Tomasz, On Tue, Sep 03, 2019 at 01:16:21PM +0900, Tomasz Figa wrote: > On Tue, Sep 3, 2019 at 1:43 AM Laurent Pinchart wrote: > > On Mon, Sep 02, 2019 at 01:20:49PM +0200, Jacopo Mondi wrote: > >> On Tue, Aug 27, 2019 at 03:51:32PM +0300, Laurent Pinchart wrote: > >>> On Tue, Aug 27, 2019 at 11:23:29AM +0200, Jacopo Mondi wrote: > >>>> Add documentation for the V4L2_CID_CAMERA_SENSOR_ROTATION camera > >>>> control. The newly added read-only control reports the camera device > >>>> mounting rotation. > >>>> > >>>> Signed-off-by: Jacopo Mondi > >>>> --- > >>>> Documentation/media/uapi/v4l/ext-ctrls-camera.rst | 9 + > >>>> 1 file changed, 9 insertions(+) > >>>> > >>>> diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >>>> b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >>>> index ecf151f3f0f4..03d1c23d18f7 100644 > >>>> --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >>>> +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >>>> @@ -544,6 +544,15 @@ enum v4l2_scene_mode - > >>>> > >>>> > >>>> > >>>> +``V4L2_CID_CAMERA_SENSOR_ROTATION (integer)`` > >>>> +This read-only control describes the camera sensor orientation by > >>>> +reporting its mounting rotation in respect to the device intended > >>>> usage > >>>> +orientation, expressed in counter clockwise degrees. The control > >>>> value is > >>> > >>> Counter clockwise relative to what ? :-) > >> > >> I think it is expressed in the previous line: > >> "mounting rotation in respect to the device intended usage > >> orientation, expressed in counter clockwise degrees" > >> > >> Would you prefer to have this re-phrased as: > >> > >> This read-only control describes the camera sensor orientation > >> expressed as rotation in counter clockwise degrees in respect to > >> the device intended usage orientation. > >> > >> ? > > > > Rotation is expressed in degrees around an axis, which is itself > > expressed as a vector. It's pretty intuitive that the rotation vector > > should be perpendicular to the plane of the sensor (which itself should > > be parallel to the plane of the device side on which it is mounted, as > > expressed by the location property), but there are still two possible > > directions for the vector, facing in the same direction as the sensor or > > the opposite direction. Unless there's a good reason to do so, I would > > use the same direction as the one defined by Android. I don't know what > > direction that is though :-) > > I don't think Android exposes camera rotation to the layers above the > HAL. The stream is expected to be pre-rotated by the HAL, taking into > account the desired target rotation of the stream itself [1]. > > [1] > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/camera3.h#1428 > > That said, Android seems to use "degrees counterclockwise" for rotations. Counterclockwise seems better to me as that's coherent with trigonometry. We still have to define the direction of the rotation axis though :-) -- Regards, Laurent Pinchart
Re: [ANN] Topics for a media summit in Lyon in October
Hi Hans, On Tue, Sep 03, 2019 at 09:21:43AM +0200, Hans Verkuil wrote: > Hi all, > > I've decided to hold the meeting during the ELCE and not on Thursday. > Two key people can't be there on Thursday and some travel back Thursday > evening and so would have to leave early. > > Looking at the schedule I propose instead to have one meeting on > Tuesday morning concentrating on finalizing the codec support. > > On Wednesday we have a second meeting for libcamera (morning) and looking > at future V4L2 developments such as v4l2_ext_buffer/format, Request API and > complex camera pipelines (afternoon). > > Laurent, it would make sense if you or one of the other libcamera devs is > 'chairing' the libcamera meeting. Do you agree? If so, can you prepare an > agenda for that meeting? > > I plan on leaving Thursday afternoon, so we have the option to continue the > talks around that last topic on Thursday morning. > > I have no idea where we will hold these meetings since I've no idea > what the conference center looks like and if they have suitable places > for doing something like this. So I'll look around on the Monday and > mail the details of where to meet then. > > Confirmed attendees: > > Boris Brezillon > Alexandre Courbot > Nicolas Dufresne > Tomasz Figa > Ezequiel Garcia > Eugen Hristev > Paul Kocialkowski > Helen Koike > Jacopo Mondi > Laurent Pinchart > Hans Verkuil > > If you are not on this list, but want to join, please let me know. > > Since this is really three half-day meetings, each with a different > topic, please let me know which of those half-day meetings you want > to attend. The schedule looks good to me. I may skip the codec part, but will be there on Wednesday. On the libcamera side, I was wondering if we should announce the meeting beforehand (possibly on the libcamera-devel mailing list and/or during Jacopo's talk on Tuesday afternoon). We don't have a room secured, right ? Did the LF say they have no room available during the conference ? -- Regards, Laurent Pinchart
Re: [PATCH v2 01/10] media: dt-bindings: Document 'location' property
Hi Jacopo, On Mon, Sep 02, 2019 at 06:40:31PM +0200, Jacopo Mondi wrote: > On Mon, Sep 02, 2019 at 02:38:40PM +0100, Rob Herring wrote: > > On Thu, Aug 29, 2019 at 02:46:40PM +0200, Jacopo Mondi wrote: > >> On Tue, Aug 27, 2019 at 03:21:26PM +0300, Laurent Pinchart wrote: > >>> On Tue, Aug 27, 2019 at 11:23:27AM +0200, Jacopo Mondi wrote: > >>>> Add the 'location' device property, used to specify the camera device > >>>> mounting position. The property is particularly meaningful for mobile > >>>> devices with a well defined usage orientation. > >>>> > >>>> Signed-off-by: Jacopo Mondi > >>>> --- > >>>> .../devicetree/bindings/media/video-interfaces.txt | 10 ++ > >>>> 1 file changed, 10 insertions(+) > >>>> > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>> b/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>> index f884ada0bffc..865f4142f432 100644 > >>>> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > >>>> @@ -89,6 +89,16 @@ Optional properties > >>>>but a number of degrees counter clockwise. Typical values are 0 and > >>>> 180 > >>>>(upside down). > >>>> > >>>> +- location: The camera sensor mounting location, expressed as a position > >>>> + relative to the usage orientation of the device the sensor is > >>>> installed on. > >>> > >>> DT bindings being ABIs, we need to be precise and thorough there. One > >>> particular point that bothers me is that the property is named location, > >>> and its description refers to camera sensor mounting location. > >>> > >>> I see two options to fix this. One of them is to rename the property to > >>> camera-location, but that would limit its future usage for other types > >>> of devices. The other one is to document the property as applying to a > >>> "device" instead of a "camera sensor", and add one sentence stating that > >>> this property is valid for camera sensors only. > >>> > >>> This will require finding another name for the device that the device is > >>> mounted on though, as using device twice would be very confusing. > >> > >> I had the same concern, but I cannot find another term to convey > >> this... suggestions? > > > > For accelerometers and/or gyroscopes, we already have 'mount-matrix'. > > Pardon my ignorance, but I could not find it documented. Some binding > files refers to an iio/mount-matrix.txt file which I cannot find. Has > it been removed? Anyway, some individual bindings report examples of > mount matrices (ie > Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt) > > > That would replace 'rotation'. Maybe we can do something similar here? > > I think 'rotation' simply expressed as degrees is fine here, our > problem was to find a term that would make it possible to specify that > rotation/location are applied to a 'device' mounted on a 'device'. > Sakari suggested on irc to use 'system' in place of the second > 'device' and that seems to work well to me. > > Or were you suggesting to use a construct similar to mount-matrix for > a purpose I didn't get :) ? mount-matrix would allow exposing the rotation in a more generic way, and if there are standard DT bindings, I think this would make sense, especially given that we could have device with camera sensors not mounted parallel to the device side. -- Regards, Laurent Pinchart
Re: [PATCH v2 03/10] media: v4l2-ctrl: Document V4L2_CID_CAMERA_SENSOR_ROTATION
Hi Jacopo, On Mon, Sep 02, 2019 at 01:20:49PM +0200, Jacopo Mondi wrote: > On Tue, Aug 27, 2019 at 03:51:32PM +0300, Laurent Pinchart wrote: > > On Tue, Aug 27, 2019 at 11:23:29AM +0200, Jacopo Mondi wrote: > >> Add documentation for the V4L2_CID_CAMERA_SENSOR_ROTATION camera > >> control. The newly added read-only control reports the camera device > >> mounting rotation. > >> > >> Signed-off-by: Jacopo Mondi > >> --- > >> Documentation/media/uapi/v4l/ext-ctrls-camera.rst | 9 + > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >> b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >> index ecf151f3f0f4..03d1c23d18f7 100644 > >> --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >> +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > >> @@ -544,6 +544,15 @@ enum v4l2_scene_mode - > >> > >> > >> > >> +``V4L2_CID_CAMERA_SENSOR_ROTATION (integer)`` > >> +This read-only control describes the camera sensor orientation by > >> +reporting its mounting rotation in respect to the device intended > >> usage > >> +orientation, expressed in counter clockwise degrees. The control > >> value is > > > > Counter clockwise relative to what ? :-) > > I think it is expressed in the previous line: > "mounting rotation in respect to the device intended usage > orientation, expressed in counter clockwise degrees" > > Would you prefer to have this re-phrased as: > > This read-only control describes the camera sensor orientation > expressed as rotation in counter clockwise degrees in respect to > the device intended usage orientation. > > ? Rotation is expressed in degrees around an axis, which is itself expressed as a vector. It's pretty intuitive that the rotation vector should be perpendicular to the plane of the sensor (which itself should be parallel to the plane of the device side on which it is mounted, as expressed by the location property), but there are still two possible directions for the vector, facing in the same direction as the sensor or the opposite direction. Unless there's a good reason to do so, I would use the same direction as the one defined by Android. I don't know what direction that is though :-) > >> +constant and not modifiable by software and its value is retrieved > >> from the > >> +firmware interface by parsing the 'rotation' property. Typical values > >> are 0 > >> +degrees for upright mounted sensors and 180 degrees for sensors > >> mounted > >> +upside down. > > > > Same comment as for 02/10 regarding how the value is known to the > > driver. > > > >> + > >> .. [#f1] > >> This control may be changed to a menu control in the future, if more > >> options are required. -- Regards, Laurent Pinchart
Re: [PATCH] dt-bindings: sh-mobile-ceu: Remove now unimplemented bindings documentation
Hi Simon,
Thank you for the patch.
On Mon, Sep 02, 2019 at 10:43:52AM +0200, Simon Horman wrote:
> Remove the SH Mobile CEU bindings documentation as the corresponding driver
> was removed v5.1 by the following commit:
>
> 43a445f188e1 ("media: sh_mobile_ceu_camera: remove obsolete soc_camera
> driver")
>
> Signed-off-by: Simon Horman
One less file to convert to yaml ;-)
Acked-by: Laurent Pinchart
> ---
> .../devicetree/bindings/media/sh_mobile_ceu.txt | 17
> -
> 1 file changed, 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
> b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
> deleted file mode 100644
> index cfa4ffada8ae..
> --- a/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -Bindings, specific for the sh_mobile_ceu_camera.c driver:
> - - compatible: Should be "renesas,sh-mobile-ceu"
> - - reg: register base and size
> - - interrupts: the interrupt number
> - - renesas,max-width: maximum image width, supported on this SoC
> - - renesas,max-height: maximum image height, supported on this SoC
> -
> -Example:
> -
> -ceu0: ceu@fe91 {
> - compatible = "renesas,sh-mobile-ceu";
> - reg = <0xfe91 0xa0>;
> - interrupt-parent = <&intcs>;
> - interrupts = <0x880>;
> - renesas,max-width = <8188>;
> - renesas,max-height = <8188>;
> -};
--
Regards,
Laurent Pinchart
Re: [PATCH v2 09/10] media: i2c: ov5670: Report native size and crop bounds
place to report the
> > > active area, or maybe the concept of active area is ill-defined if
> > > the sensor is cross-shaped:
> > >
> > > // -> Pixel array size
> > > --
> > > |x||--- x|--> 4:3 crop bounds
> > > |x--x|
> > > |x| || |x|
> > > |x| || |x|--> 21:9 crop bounds
> > > |x| || |x|
> > > |x--x|
> > > |x||x|
> > > --
> > > | |
> > > ---> Black pixels colums
> > >
> > >>
> > >> I have no clear answer for you, to be honest, but it can get tricky.
> > >>
> > >
> > > Indeed, but assuming a simpler square-shaped sensor, is the crop bound
> > > target the right one to report the active pixel area ?
> >
> > I don't think so.
> >
> > The crop bounds defines the outer bounds of the area where you can put
> > your crop rectangle. This can very well include areas where the pixels
> > are covered and so always return black (sometimes used to obtain black
> > levels, I believe).
>
> Ah, I didn't considered black pixels as part of a possible crop
> selection..
The whole point of black pixels is that they can be captured (or at
least part of them), for the ISP to calculate an average black level and
subtract it from the active pixels. Let's thus make sure we clearly
define every selection rectangle in the specification.
> > The default crop rectangle would be the one that reports the active
> > area. The native size rectangle would be the full pixel array.
> >
> > So CROP_DEFAULT <= CROP_BOUNDS <= NATIVE_SIZE.
>
> I see thanks for clarifying this
>
> > For a cross-shaped sensor I would expect that the CROP_BOUNDS/DEFAULT
> > depends on the format (aspect ratio).
>
> Currently the selection API do not support to retrieve that
> information depending on the aspect-ratio though
>
> > I think this makes sense.
> >
> > The specification definitely needs to be improved, patches are welcome...
> >
> > >>>
> > >>> How would you report the two information I need?
> > >>
> > >> It depends on my original question: what do you need this information
> > >> for?
> > >
> > > Please note that it's for the android camera stack in this case, but
> > > it's an information that userspace might want to know for several
> > > different reasons. Calibration and FOV calculation come to mind. Does
> > > this makes sense to you?
> >
> > Ah, so that's what it is used for :-)
> >
> > Which of the three targets above would match with what Android needs?
>
> the full pixel array size would be reported by the NATIVE_SIZE target
> the active area size by the CROP_DEFAULT rectangle (regardless of the
> aspect ratio)
>
> It's still not clear to me what the CROP_BOUNDS rectangle would then
> be used for, unless it is made to be dependent on an aspect ratio but
> that would require userspace to provide a populated rectangle to
> G_SELECTION and drivers to inspect it and return an opportune
> CROP_BOUNDS one. Would this be acceptable ?
>
> > >>>> I don't think this patch and the next have anything to do with the
> > >>>> location/rotate
> > >>>> support. I would split it off from this series.
> > >>>>
> > >>>
> > >>> Agreed, they were split in v1, maybe it has not been a wise move to
> > >>> make a single series out of them. I'll split again.
> > >>>
> > >>>>> + break;
> > >>>>> + default:
> > >>>>> + return -EINVAL;
> > >>>>> + }
> > >>>>> +
> > >>>>> + return 0;
> > >>>>> +}
> > >>>>> +
> > >>>>> static int ov5670_get_skip_frames(struct v4l2_subdev *sd, u32
> > >>>>> *frames)
> > >>>>> {
> > >>>>> *frames = OV5670_NUM_OF_SKIP_FRAMES;
> > >>>>> @@ -2425,6 +2444,7 @@ static const struct v4l2_subdev_pad_ops
> > >>>>> ov5670_pad_ops = {
> > >>>>> .enum_mbus_code = ov5670_enum_mbus_code,
> > >>>>> .get_fmt = ov5670_get_pad_format,
> > >>>>> .set_fmt = ov5670_set_pad_format,
> > >>>>> + .get_selection = ov5670_get_selection,
> > >>>>> .enum_frame_size = ov5670_enum_frame_size,
> > >>>>> };
> > >>>>>
--
Regards,
Laurent Pinchart
Re: [PATCH v2 06/10] media: v4l2-fwnode: Add helper to register controls from fw
Hi Hans, On Thu, Aug 29, 2019 at 05:32:52PM +0200, Hans Verkuil wrote: > On 8/29/19 5:05 PM, Laurent Pinchart wrote: > > On Thu, Aug 29, 2019 at 03:04:42PM +0200, Hans Verkuil wrote: > >> On 8/29/19 2:45 PM, Jacopo Mondi wrote: > >>> On Thu, Aug 29, 2019 at 12:31:37PM +0200, Hans Verkuil wrote: > >>>> On 8/27/19 11:23 AM, Jacopo Mondi wrote: > >>>>> Add the 'v4l2_fwnode_register_controls()' helper to v4l2-fwnode. The > >>>>> function parses the device node and endpoint firmware properties to > >>>>> which a v4l2 control is associated to and registers the control with the > >>>>> provided handler. > >>>>> > >>>>> Signed-off-by: Jacopo Mondi > >>>>> --- > >>>>> drivers/media/v4l2-core/v4l2-fwnode.c | 57 +++ > >>>>> include/media/v4l2-fwnode.h | 30 ++ > >>>>> 2 files changed, 87 insertions(+) > >>>>> > >>>>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c > >>>>> b/drivers/media/v4l2-core/v4l2-fwnode.c > >>>>> index 3bd1888787eb..669801fceb64 100644 > >>>>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c > >>>>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c > >>>>> @@ -25,6 +25,7 @@ > >>>>> #include > >>>>> > >>>>> #include > >>>>> +#include > >>>>> #include > >>>>> #include > >>>>> > >>>>> @@ -595,6 +596,62 @@ void v4l2_fwnode_put_link(struct v4l2_fwnode_link > >>>>> *link) > >>>>> } > >>>>> EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link); > >>>>> > >>>>> +int v4l2_fwnode_register_controls(struct fwnode_handle *fwnode, > >>>>> + struct v4l2_ctrl_handler *hdl, > >>>>> + const struct v4l2_ctrl_ops *ctrl_ops) > >>>> > >>>> I'm not convinced that this helper is a good idea. > >>>> > >>>> A helper that parses and validates this information makes sense, > >>>> but combining that with creating the controls feels wrong to me. > >>>> > >>>> You're mixing two very different things in one function. > >>>> > >>>> I think something like this would work better in a driver: > >>>> > >>>> if (!v4l2_fwnode_parse_location(&val)) > >>>> v4l2_ctrl_new_std(hdl, ctrl_ops, > >>>>V4L2_CID_CAMERA_SENSOR_LOCATION, > >>>>val, val, 1, val); > >>>> if (!v4l2_fwnode_parse_rotation(&val)) > >>>> v4l2_ctrl_new_std(hdl, ctrl_ops, > >>>>V4L2_CID_CAMERA_SENSOR_ROTATION, > >>>>val, val, 1, val); > >>>> > >>>> Much cleaner IMHO. (Just a brainstorm, so don't get stuck on these > >>>> function prototypes!) > >>>> > >>> > >>> Could the control registration being conditional on the presence of > >>> the *hdl parameter otherwise, or would you split the two operations > >>> (property parsing and control registration) nonetheless ? > >> > >> Split it. My main problem with this helper is that it is mixing two > >> frameworks. Most of Laurent's comments on this patch just go away if > >> you leave the control creation to the driver. > >> > >> It really isn't much code, and it is much easier to review a driver > >> if all the controls are created in the same place instead of some > >> controls being magically created in a helper function. > > > > But this would require copying the above code in every single camera > > sensor driver. Furthermore, the helper proposed by Jacopo would make > > addition of new firmware properties much simpler, as we wouldn't need to > > modify all sensor drivers. > > > > V4L2 requires lots of boilerplate code for sensor drivers, and I think > > more helper would be useful. There's really not point in doing the same > > thing slightly differently in dozens of drivers. Maybe we could > > experiment with a v4l2_camera_subdev structure ? > > You can make one v4l2_fwnode helper that parses all the sensor
Re: [PATCH v2 06/10] media: v4l2-fwnode: Add helper to register controls from fw
_find(hdl, V4L2_CID_CAMERA_SENSOR_LOCATION))
> >>> + pr_debug("Skip control '%s': already registered",
> >>> + v4l2_ctrl_get_name(
> >>> + V4L2_CID_CAMERA_SENSOR_LOCATION));
> >>> + else
> >>> + v4l2_ctrl_new_std(hdl, ctrl_ops,
> >>> + V4L2_CID_CAMERA_SENSOR_LOCATION,
> >>> + val, val, 1, val);
> >>> + }
> >>> +
> >>> + ret = fwnode_property_read_u32(fwnode, "rotation", &val);
> >>> + if (!ret) {
> >>> + if (val > 360) {
> >>
> >> I'd add '|| val % 90' to this condition.
> >
> > Do we want to enforce this? I can't imagine any use case, but why a
> > camera cannot be rotated of an arbitrary number of degrees ?
>
> I would start out by enforcing this until someone comes up with a
> realistic use-case.
>
> As long as it is a multiple of 90 degree, then there is a clear interaction
> with the ROTATE/HFLIP/VFLIP controls. For other angles that gets more
> confusing
> and I'd rather avoid that for now.
If we enfore this, then let's update the DT bindings accordingly. yaml
would help with validation ;-)
> >>> + pr_warn("Unsupported rotation: %u\n", val);
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + if (v4l2_ctrl_find(hdl, V4L2_CID_CAMERA_SENSOR_ROTATION))
> >>> + pr_debug("Skip control '%s': already registered",
> >>> + v4l2_ctrl_get_name(
> >>> + V4L2_CID_CAMERA_SENSOR_ROTATION));
> >>> + else
> >>> + v4l2_ctrl_new_std(hdl, ctrl_ops,
> >>> + V4L2_CID_CAMERA_SENSOR_ROTATION,
> >>> + val, val, 1, val);
> >>> + }
> >>> +
> >>> + if (hdl->error) {
> >>> + pr_warn("Failed to register controls from firmware: %d\n",
> >>> + hdl->error);
> >>> + return hdl->error;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(v4l2_fwnode_register_controls);
> >>> +
> >>> static int
> >>> v4l2_async_notifier_fwnode_parse_endpoint(struct device *dev,
> >>> struct v4l2_async_notifier *notifier,
> >>> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> >>> index f6a7bcd13197..0dad6968bde9 100644
> >>> --- a/include/media/v4l2-fwnode.h
> >>> +++ b/include/media/v4l2-fwnode.h
> >>> @@ -25,6 +25,8 @@
> >>> struct fwnode_handle;
> >>> struct v4l2_async_notifier;
> >>> struct v4l2_async_subdev;
> >>> +struct v4l2_ctrl_handler;
> >>> +struct v4l2_ctrl_ops;
> >>>
> >>> #define V4L2_FWNODE_CSI2_MAX_DATA_LANES 4
> >>>
> >>> @@ -233,6 +235,34 @@ int v4l2_fwnode_parse_link(struct fwnode_handle
> >>> *fwnode,
> >>> */
> >>> void v4l2_fwnode_put_link(struct v4l2_fwnode_link *link);
> >>>
> >>> +/**
> >>> + * v4l2_fwnode_register_controls() - parse device and endpoint fwnode
> >>> + *properties and register a v4l2
> >>> control
> >>> + *for each of them
> >>> + * @fwnode: pointer to the device fwnode handle
> >>> + * @hdl: pointer to the v4l2 control handler to register controls with
> >>> + * @ctrl_ops: pointer to the v4l2 control operations to register with
> >>> the handler
> >>> + *
> >>> + * Parse the @fwnode device and endpoint properties to which a v4l2
> >>> control
> >>> + * is associated and register them with the provided handler @hdl.
> >>> + * Currently the following v4l2 controls are parsed and registered:
> >>> + * - V4L2_CID_CAMERA_SENSOR_LOCATION;
> >>> + * - V4L2_CID_CAMERA_SENSOR_ROTATION;
> >>> + *
> >>> + * Controls already registered by the caller with the @hdl control
> >>> handler are
> >>> + * not overwritten. Callers should register the controls they want to
> >>> handle
> >>> + * themselves before calling this function.
> >>> + *
> >>> + * NOTE: This function locks the @hdl control handler mutex, the caller
> >>> shall
> >>> + * not hold the lock when calling this function.
> >>> + *
> >>> + * Return: 0 on success, -EINVAL if the fwnode properties are not
> >>> correctly
> >>> + * specified.
> >>> + */
> >>> +int v4l2_fwnode_register_controls(struct fwnode_handle *fwnode,
> >>> + struct v4l2_ctrl_handler *hdl,
> >>> + const struct v4l2_ctrl_ops *ctrl_ops);
> >>> +
> >>> /**
> >>> * typedef parse_endpoint_func - Driver's callback function to be called
> >>> on
> >>> * each V4L2 fwnode endpoint.
--
Regards,
Laurent Pinchart
Re: [PATCH v2 06/10] media: v4l2-fwnode: Add helper to register controls from fw
properties and register a v4l2 control > + *for each of them I don't think that description is accurate. > + * @fwnode: pointer to the device fwnode handle > + * @hdl: pointer to the v4l2 control handler to register controls with > + * @ctrl_ops: pointer to the v4l2 control operations to register with the > handler > + * > + * Parse the @fwnode device and endpoint properties to which a v4l2 control > + * is associated and register them with the provided handler @hdl. > + * Currently the following v4l2 controls are parsed and registered: > + * - V4L2_CID_CAMERA_SENSOR_LOCATION; > + * - V4L2_CID_CAMERA_SENSOR_ROTATION; > + * > + * Controls already registered by the caller with the @hdl control handler > are > + * not overwritten. Callers should register the controls they want to handle > + * themselves before calling this function. > + * > + * NOTE: This function locks the @hdl control handler mutex, the caller shall > + * not hold the lock when calling this function. > + * > + * Return: 0 on success, -EINVAL if the fwnode properties are not correctly > + * specified. > + */ > +int v4l2_fwnode_register_controls(struct fwnode_handle *fwnode, > + struct v4l2_ctrl_handler *hdl, > + const struct v4l2_ctrl_ops *ctrl_ops); > + > /** > * typedef parse_endpoint_func - Driver's callback function to be called on > * each V4L2 fwnode endpoint. -- Regards, Laurent Pinchart
Re: [PATCH v2 05/10] media: v4l2-ctrl: Add V4L2_CID_CAMERA_SENSOR_ROTATION
Hi Jacopo,
Thank you for the patch.
On Tue, Aug 27, 2019 at 11:23:32AM +0200, Jacopo Mondi wrote:
> Add support for the newly defined V4L2_CID_CAMERA_SENSOR_ROTATION
> read-only control used to report the camera device mounting rotation.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
(although I would squash it with the previous patch)
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
> include/uapi/linux/v4l2-controls.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index db7124494530..b7af47a25125 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -995,6 +995,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_PAN_SPEED:return "Pan, Speed";
> case V4L2_CID_TILT_SPEED: return "Tilt, Speed";
> case V4L2_CID_CAMERA_SENSOR_LOCATION: return "Camera Sensor Location";
> + case V4L2_CID_CAMERA_SENSOR_ROTATION: return "Camera Sensor Rotation";
>
> /* FM Radio Modulator controls */
> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
> @@ -1320,6 +1321,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
> case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
> case V4L2_CID_CAMERA_SENSOR_LOCATION:
> + case V4L2_CID_CAMERA_SENSOR_ROTATION:
> *type = V4L2_CTRL_TYPE_INTEGER;
> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> break;
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 387c2c8553cb..f2be7a99818e 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -917,6 +917,8 @@ enum v4l2_auto_focus_range {
> #define V4L2_LOCATION_BACK 1
> #define V4L2_LOCATION_EXTERNAL 2
>
> +#define V4L2_CID_CAMERA_SENSOR_ROTATION
> (V4L2_CID_CAMERA_CLASS_BASE+35)
> +
> /* FM Modulator class control IDs */
>
> #define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
--
Regards,
Laurent Pinchart
Re: [PATCH v2 04/10] media: v4l2-ctrl: Add V4L2_CID_CAMERA_SENSOR_LOCATION
Hi Jacopo,
Thank you for the patch.
On Tue, Aug 27, 2019 at 11:23:30AM +0200, Jacopo Mondi wrote:
> Add support for the newly defined V4L2_CID_CAMERA_SENSOR_LOCATION
> read-only control used to report the camera device mounting position.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
> include/uapi/linux/v4l2-controls.h | 5 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 1d8f38824631..db7124494530 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_CAMERA_SENSOR_LOCATION: return "Camera Sensor Location";
>
> /* FM Radio Modulator controls */
> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
> @@ -1318,6 +1319,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> break;
> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
> case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
> + case V4L2_CID_CAMERA_SENSOR_LOCATION:
> *type = V4L2_CTRL_TYPE_INTEGER;
> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> break;
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index a2669b79b294..387c2c8553cb 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -912,6 +912,11 @@ enum v4l2_auto_focus_range {
> #define V4L2_CID_PAN_SPEED (V4L2_CID_CAMERA_CLASS_BASE+32)
> #define V4L2_CID_TILT_SPEED (V4L2_CID_CAMERA_CLASS_BASE+33)
>
> +#define V4L2_CID_CAMERA_SENSOR_LOCATION
> (V4L2_CID_CAMERA_CLASS_BASE+34)
> +#define V4L2_LOCATION_FRONT 0
> +#define V4L2_LOCATION_BACK 1
> +#define V4L2_LOCATION_EXTERNAL 2
> +
> /* FM Modulator class control IDs */
>
> #define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
--
Regards,
Laurent Pinchart
Re: [PATCH v2 03/10] media: v4l2-ctrl: Document V4L2_CID_CAMERA_SENSOR_ROTATION
Hi Jacopo, Thank you for the patch. On Tue, Aug 27, 2019 at 11:23:29AM +0200, Jacopo Mondi wrote: > Add documentation for the V4L2_CID_CAMERA_SENSOR_ROTATION camera > control. The newly added read-only control reports the camera device > mounting rotation. > > Signed-off-by: Jacopo Mondi > --- > Documentation/media/uapi/v4l/ext-ctrls-camera.rst | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > index ecf151f3f0f4..03d1c23d18f7 100644 > --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > @@ -544,6 +544,15 @@ enum v4l2_scene_mode - > > > > +``V4L2_CID_CAMERA_SENSOR_ROTATION (integer)`` > +This read-only control describes the camera sensor orientation by > +reporting its mounting rotation in respect to the device intended usage > +orientation, expressed in counter clockwise degrees. The control value is Counter clockwise relative to what ? :-) > +constant and not modifiable by software and its value is retrieved from > the > +firmware interface by parsing the 'rotation' property. Typical values > are 0 > +degrees for upright mounted sensors and 180 degrees for sensors mounted > +upside down. Same comment as for 02/10 regarding how the value is known to the driver. > + > .. [#f1] > This control may be changed to a menu control in the future, if more > options are required. -- Regards, Laurent Pinchart
Re: [PATCH v2 02/10] media: v4l2-ctrl: Document V4L2_CID_CAMERA_SENSOR_LOCATION
Hi Jacopo, Thank you for the patch. On Tue, Aug 27, 2019 at 11:23:28AM +0200, Jacopo Mondi wrote: > Add documentation for the V4L2_CID_CAMERA_SENSOR_LOCATION camera > control. The newly added read-only control reports the camera device > mounting position. > > Signed-off-by: Jacopo Mondi > --- > .../media/uapi/v4l/ext-ctrls-camera.rst | 34 +++ > 1 file changed, 34 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > index 51c1d5c9eb00..ecf151f3f0f4 100644 > --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > @@ -510,6 +510,40 @@ enum v4l2_scene_mode - > value down. A value of zero stops the motion if one is in progress > and has no effect otherwise. > > +``V4L2_CID_CAMERA_SENSOR_LOCATION (integer)`` > +This read-only control describes the camera sensor location by > +reporting its mounting position on the device where the camera is > +installed. The control value is constant and not modifiable by software > +and its value is retrieved from the firmware interface by parsing the > +'location' property. How the value is known to the driver is irrelevant in this context, I would drop "and its value ...". > This control is particularly meaningful for > +devices which have a well defined orientation, such as phones, laptops > +and portable devices as the camera location is expressed as a position > +relative to the device intended usage orientation. In example, a camera s/In example/For example/ > +sensor installed on the user-facing side of a phone, a tablet or a > +laptop device is said to be installed in the ``V4L2_LOCATION_FRONT`` > +location while camera sensors installed on the side opposed to the s/opposed to the front one/opposite the front/ > +front one are said to be installed in the ``V4L2_LOCATION_BACK`` > +location. Camera sensors connected to the device by extension cables > +which are freely movable regardless of the device orientation, such as > +webcams and digital cameras, are said to be have > +``V4L2_LOCATION_EXTERNAL`` location. Same comment as for the DT bindings regarding cables. > + > + > + > +.. flat-table:: > +:header-rows: 0 > +:stub-columns: 0 > + > +* - ``V4L2_LOCATION_FRONT`` > + - The camera sensor is located on the front side of the device. > +* - ``V4L2_LOCATION_BACK`` > + - The camera sensor is located on the back side of the device. > +* - ``V4L2_LOCATION_EXTERNAL`` > + - The camera sensor is connected by extension cables to the device and > +it's freely movable. s/it's/is/ > + > + > + > .. [#f1] > This control may be changed to a menu control in the future, if more > options are required. -- Regards, Laurent Pinchart
Re: [PATCH v2 01/10] media: dt-bindings: Document 'location' property
Hi Jacopo, Thank you for the patch. On Tue, Aug 27, 2019 at 11:23:27AM +0200, Jacopo Mondi wrote: > Add the 'location' device property, used to specify the camera device > mounting position. The property is particularly meaningful for mobile > devices with a well defined usage orientation. > > Signed-off-by: Jacopo Mondi > --- > .../devicetree/bindings/media/video-interfaces.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt > index f884ada0bffc..865f4142f432 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -89,6 +89,16 @@ Optional properties >but a number of degrees counter clockwise. Typical values are 0 and 180 >(upside down). > > +- location: The camera sensor mounting location, expressed as a position > + relative to the usage orientation of the device the sensor is installed on. DT bindings being ABIs, we need to be precise and thorough there. One particular point that bothers me is that the property is named location, and its description refers to camera sensor mounting location. I see two options to fix this. One of them is to rename the property to camera-location, but that would limit its future usage for other types of devices. The other one is to document the property as applying to a "device" instead of a "camera sensor", and add one sentence stating that this property is valid for camera sensors only. This will require finding another name for the device that the device is mounted on though, as using device twice would be very confusing. > + Possible values are: > + 0 - Front. The image sensor is mounted on the front facing side of the > device. > + For mobile devices such as smartphones, tablets and laptops the front side > is > + the user facing side of the device. > + 1 - Back. The image sensor is mounted on the back side of the device, > which is > + defined as the opposite side of the front facing one. > + 2 - External. The image sensor is connected to the device by extension > cables, > + and can be freely moved, regardless of the device position. It could be something else than cables (wireless possibly ?). I would phrase this along the lines of "The device is not attached directly to the [device], or is attached in a way that allows it to move to different locations." > > Optional endpoint properties > -- Regards, Laurent Pinchart
Re: [PATCH] media: bindings: video-interfaces: Update the example
= <180>; /* The camera is mounted upside down! */
> > > +
> > > + /* With a single port, use 'port' and not 'ports'. */
> > > + port {
> > > + /* With 1 endpoint per port no need for addresses. */
> > > + imx074_1: endpoint {
> > > + bus-type = 4;
> > > + /* If lane re-ordering is not supported, no
> > > +need to tell where the clock lane is! */
> > > + /* clock-lanes = <0>; */
> > > + /* But the number of data lanes is important! */
> > > + data-lanes = <1 2>;
> > > + remote-endpoint = <&csi20_in>;
> > > };
> > > };
> > > };
> > > +};
> > >
> > > - csi2: csi2@ffc9 {
> > > - compatible = "renesas,sh-mobile-csi2";
> > > - reg = <0xffc9 0x1000>;
> > > - interrupts = <0x17a0>;
> > > +csi20: csi2@fea8 {
> > > + compatible = "renesas,r8a7795-csi2";
> > > + reg = <0 0xfea8 0 0x1>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 714>;
> > > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > > + resets = <&cpg 714>;
> >
> > Do we need all reg, interrupts, clocks, power-domains and resets in the
> > example?
>
> Probably not, but they were present in the previous example, so I kept
> it. I would be fine by dropping them anyway...
We actually need them. When moving to yaml the example will be compiled,
so they must be valid. Let's ensure they are already.
Bonus points if you can convert this file to yaml schema :-)
> > > +
> > > + ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > - port@1 {
> > > - compatible = "renesas,csi2c"; /* One of CSI2I and
> > > CSI2C. */
> > > - reg = <1>; /* CSI-2 PHY #1 of 2:
> > > PHY_S,
> > > -PHY_M has port
> > > address 0,
> > > -is unused. */
> > > - csi2_1: endpoint {
> > > - clock-lanes = <0>;
> > > - data-lanes = <2 1>;
> > > + port@0 {
> > > + reg = <0>;
> > > +
> > > + csi20_in: endpoint {
> > > + bus-type = 4;
> > > + /* Use the same number of data lanes as the
> > > +one used by the remote endpoint! */
> >
> > nit: Do this comment bring value, or is it confusing?
>
> Maybe it does not bring much value, but why is it confusing ?
>
> > > + data-lanes = <1 2>;
> > > remote-endpoint = <&imx074_1>;
> > > };
> > > };
> > > - port@2 {
> > > - reg = <2>; /* port 2: link to the
> > > CEU */
> > >
> > > - csi2_2: endpoint {
> > > - remote-endpoint = <&ceu0_0>;
> > > + port@1 {
> > > + reg = <1>;
> > > +
> > > + /* Data path to the VIN4 DMA engine. */
> >
> > Needed?
>
> Not really...
>
> > > + csi20vin4: endpoint {
> > > + remote-endpoint = <&vin4csi20>;
> > > + };
> > > + };
> > > + };
> > > +};
> > > +
> > > +vin4: video@e6ef4000 {
> > > + compatible = "renesas,vin-r8a7795";
> > > + reg = <0 0xe6ef4000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 807>;
> > > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > > + resets = <&cpg 807>;
> > > + renesas,id = <4>;
> >
> > Same comment as above, is all properties needed in the example?
> > Specially renesas,id can be confusing as it's a driver specific binding
> > needed to workaround a fun hardware design.
>
> I agree, but I'm debated.. one looks at the example and it doesn't
> match the actual VIN bindings, and then might be even more confused.
> I'm find dropping all of this. Maybe we can add a line in the intro
> that says the example is fictional and does not report all the
> required properties for a device to work.
>
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel input port: HDMI decoder */
> > > + port@0 {
> > > + reg = <0>;
> > > +
> > > + vin4_digital_in: endpoint {
> > > + bus-type = 5;
> > > + bus-width = <8>;/* Used data lines */
> > > + data-shift = <2>; /* Lines 9:2 are used */
> > > + data-active = <1>; /* Active high */
> > > + pclk-sample = <0>; /* Falling */
> > > + /* If hsync-active/vsync-active are missing,
> > > + * embedded BT.656 sync is used */
> >
> > I feel if this comment is to be kept it should be expanded.
>
> I copied it from the existing example. How would you expand it?
>
> > > + hsync-active = <0>;
> > > + vsync-active = <0>;
> > > + remote-endpoint = <&adv7612_out>;
> > > + };
> > > + };
> > > +
> > > +
> > > + /* Data path to the MIPI CSI-2 receiver. */
> > > + port@1 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + reg =<1>;
> > > +
> > > + /* Need endpoint numbers when multiple endpoints are
> > > +present. */
> >
> > I think this can be dropped.
>
> Ok
>
> Thanks for review
>
> > > + vin4csi20: endpoint@0 {
> > > + reg = <0>;
> > > + remote-endpoint = <&csi20vin4>;
> > > + };
> > > +
> > > + /* Not connected in this example. */
> > > + vin4csi41: endpoint@3 {
> > > + reg = <3>;
> > > + remote-endpoint = <&csi41vin4>;
> > > };
> > > };
> > > };
> > > +};
--
Regards,
Laurent Pinchart
Re: [PATCH v2 5/7] media: use the BIT() macro
Hi Mauro, Thank you for the patch. On Fri, Aug 23, 2019 at 06:47:30AM -0300, Mauro Carvalho Chehab wrote: > As warned by cppcheck: > > [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > ... > [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > > There are lots of places where we're doing 1 << 31. That's bad, > as, depending on the architecture, this has an undefined behavior. > > The BIT() macro is already prepared to handle this, so, let's > just switch all "1 << number" macros by BIT(number) at the header files > with has 1 << 31. > > Signed-off-by: Mauro Carvalho Chehab > --- > > v2: > As suggested by Laurent: > - Don't touch multi-bit masks > - remove explicit casts > > drivers/media/pci/cobalt/cobalt-driver.h | 63 +- > drivers/media/pci/ivtv/ivtv-irq.h | 28 +- > drivers/media/pci/mantis/mantis_reg.h | 152 ++--- > drivers/media/pci/solo6x10/solo6x10-regs.h| 286 - > .../media/platform/am437x/am437x-vpfe_regs.h | 26 +- > .../media/platform/davinci/dm644x_ccdc_regs.h | 20 +- > .../media/platform/exynos4-is/fimc-lite-reg.h | 80 +-- > drivers/media/platform/exynos4-is/fimc-reg.h | 138 +++-- > drivers/media/platform/omap3isp/ispreg.h | 580 +- > drivers/media/platform/s3c-camif/camif-regs.h | 118 ++-- > drivers/media/platform/tegra-cec/tegra_cec.h | 80 +-- > drivers/media/platform/ti-vpe/vpe_regs.h | 94 +-- > drivers/media/platform/vsp1/vsp1_regs.h | 224 +++ > drivers/media/platform/xilinx/xilinx-vip.h| 29 +- > drivers/media/radio/wl128x/fmdrv_common.h | 88 +-- > drivers/staging/media/ipu3/ipu3-tables.h | 4 +- > 16 files changed, 1011 insertions(+), 999 deletions(-) [snip] > diff --git a/drivers/media/platform/omap3isp/ispreg.h > b/drivers/media/platform/omap3isp/ispreg.h > index 38e2b99b3f10..4c6ebc0b74d1 100644 > --- a/drivers/media/platform/omap3isp/ispreg.h > +++ b/drivers/media/platform/omap3isp/ispreg.h [snip] > @@ -1167,14 +1167,14 @@ > #define ISPHIST_HV_INFO_MASK 0x3FFF3FFF > > #define ISPCCDC_LSC_ENABLE 1 This is a bit too, it could be replaced with BIT(0). > -#define ISPCCDC_LSC_BUSY (1 << 7) > +#define ISPCCDC_LSC_BUSY BIT(7) > #define ISPCCDC_LSC_GAIN_MODE_N_MASK 0x700 > #define ISPCCDC_LSC_GAIN_MODE_N_SHIFT8 > #define ISPCCDC_LSC_GAIN_MODE_M_MASK 0x3800 > #define ISPCCDC_LSC_GAIN_MODE_M_SHIFT12 > #define ISPCCDC_LSC_GAIN_FORMAT_MASK 0xE > #define ISPCCDC_LSC_GAIN_FORMAT_SHIFT1 > -#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK (1<<6) > +#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK BIT(6) > > #define ISPCCDC_LSC_INITIAL_X_MASK 0x3F > #define ISPCCDC_LSC_INITIAL_X_SHIFT 0 [snip] With this small issue addressed, For omap3isp, vsp1, xilinx, wl128x and ipu3, Reviewed-by: Laurent Pinchart -- Regards, Laurent Pinchart
Re: [PATCH 5/7] media: use the BIT() macro
Hi Mauro, Thank you for the patch. On Thu, Aug 22, 2019 at 04:39:32PM -0300, Mauro Carvalho Chehab wrote: > As warned by cppcheck: > > [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > ... > [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed > 32-bit value by 31 bits is undefined behaviour > > There are lots of places where we're doing 1 << 31. That's bad, > as, depending on the architecture, this has an undefined behavior. > > The BIT() macro is already prepared to handle this, so, let's > just switch all "1 << number" macros by BIT(number) at the header files > with has 1 << 31. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/pci/cobalt/cobalt-driver.h | 63 +- > drivers/media/pci/ivtv/ivtv-irq.h | 28 +- > drivers/media/pci/mantis/mantis_reg.h | 156 ++--- > drivers/media/pci/solo6x10/solo6x10-regs.h| 290 - > .../media/platform/am437x/am437x-vpfe_regs.h | 28 +- > .../media/platform/davinci/dm644x_ccdc_regs.h | 22 +- > .../media/platform/exynos4-is/fimc-lite-reg.h | 86 +-- > drivers/media/platform/exynos4-is/fimc-reg.h | 172 ++--- > drivers/media/platform/omap3isp/ispreg.h | 592 +- > drivers/media/platform/s3c-camif/camif-regs.h | 128 ++-- > drivers/media/platform/tegra-cec/tegra_cec.h | 80 +-- > drivers/media/platform/ti-vpe/vpe_regs.h | 94 +-- > drivers/media/platform/vsp1/vsp1_regs.h | 254 > drivers/media/platform/xilinx/xilinx-vip.h| 33 +- > drivers/media/radio/wl128x/fmdrv_common.h | 88 +-- > drivers/staging/media/ipu3/ipu3-tables.h | 4 +- > 16 files changed, 1065 insertions(+), 1053 deletions(-) > > diff --git a/drivers/media/pci/cobalt/cobalt-driver.h > b/drivers/media/pci/cobalt/cobalt-driver.h > index 429bee4ef79c..14b8ca2daa17 100644 > --- a/drivers/media/pci/cobalt/cobalt-driver.h > +++ b/drivers/media/pci/cobalt/cobalt-driver.h > @@ -10,6 +10,7 @@ > > #ifndef COBALT_DRIVER_H > #define COBALT_DRIVER_H > +#include > The blank line should go before the header, not after. > #include > #include [snip] > diff --git a/drivers/media/platform/omap3isp/ispreg.h > b/drivers/media/platform/omap3isp/ispreg.h > index 38e2b99b3f10..197f8f43c8fc 100644 > --- a/drivers/media/platform/omap3isp/ispreg.h > +++ b/drivers/media/platform/omap3isp/ispreg.h > @@ -45,7 +45,7 @@ > > #define ISPCCP2_REVISION (0x000) > #define ISPCCP2_SYSCONFIG(0x004) > -#define ISPCCP2_SYSCONFIG_SOFT_RESET (1 << 1) > +#define ISPCCP2_SYSCONFIG_SOFT_RESET BIT(1) > #define ISPCCP2_SYSCONFIG_AUTO_IDLE 0x1 > #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT12 > #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE\ > @@ -55,44 +55,44 @@ > #define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART\ > (0x2 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT) > #define ISPCCP2_SYSSTATUS(0x008) > -#define ISPCCP2_SYSSTATUS_RESET_DONE (1 << 0) > +#define ISPCCP2_SYSSTATUS_RESET_DONE BIT(0) > #define ISPCCP2_LC01_IRQENABLE (0x00C) > #define ISPCCP2_LC01_IRQSTATUS (0x010) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ(1 << 11) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQ(1 << 10) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQ(1 << 9) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQ(1 << 8) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ (1 << 7) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ (1 << 5) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ (1 << 4) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ (1 << 3) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQ(1 << 2) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ (1 << 1) > -#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ (1 << 0) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQBIT(11) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_LE_IRQBIT(10) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_LS_IRQBIT(9) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FE_IRQBIT(8) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_COUNT_IRQ BIT(7) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FIFO_OVF_IRQ BIT(5) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ BIT(4) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ BIT(3) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQBIT(2) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ BIT(1) > +#define ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ BIT(0) > > #define ISPCCP2_LC23_IRQENABLE (0x014) > #define ISPCCP2_LC23_IRQSTATUS (0x018) > #define ISPCCP2_LCM_IRQENABLE(0x02C) > -#define ISPCCP2_LCM_IRQSTATUS_EOF_IRQ(1 << 0) > -#define ISPCC
Re: [ANN] Topics for a media summit in Lyon in October
Hi Eugen, On Mon, Aug 19, 2019 at 03:24:26PM +, eugen.hris...@microchip.com wrote: > On 19.08.2019 18:04, Laurent Pinchart wrote: > > On Mon, Aug 19, 2019 at 11:43:56AM -0300, Ezequiel Garcia wrote: > >> On Mon, 2019-08-19 at 09:44 +0200, Hans Verkuil wrote: > >>> On 8/16/19 10:06 AM, Hans Verkuil wrote: > >>>> Rather then discussing topics for a meeting under the subject 'Lisbon' > >>>> let's start a new thread referring to the right place :-) > >>>> > >>>> I will try to organize a room, either during the ELCE or (if that doesn't > >>>> work) perhaps on the Thursday afterwards. If that's going to be a problem > >>>> for someone, please let me know. > >>>> > >>>> I do need to know how many people I can expect. I have the following > >>>> confirmed attendees (and please reply if you are not listed!): > >>>> > >>>> Alexandre Courbot > >>>> Tomasz Figa > >>>> Jacopo Mondi > >>>> Laurent Pinchart > >>>> Hans Verkuil > >>>> > >>>> I know there were more who mentioned on irc that they would attend, > >>>> but it is easier to keep track if I have it in an email. > >>>> > >>>> Topics posted under the previous thread: > >>>> > >>>> Tomasz: > >>>> > >>>> I would want to discuss various v4l2_buffer improvements, e.g. > >>>> - DMA-buf import with plane offsets, > >>>> - unifying the buffer structs for M and non-M formats, > >>>> - ability to import different FDs with offsets for non-M formats if the > >>>> layout matches driver expectations, etc. > >>>> > >>>> Besides that, I would be interested in the general idea on handling > >>>> complex cameras in the Linux kernel in spite of the remaining V4L2 > >>>> limitations, e.g. > >>>> - combinatorial explosion of /dev/video nodes, > >>>> - significant ioctl overhead, > >>>> - huge amount of historical legacy making the driver and userspace > >>>>implementations overly difficult and prone to repetitive mistakes, > >>>> - the above also limiting the flexibility of the API - formats, frame > >>>>rates, etc. set using distinct APIs, not covered by Request API, with > >>>>non-failure "negotiation hell", etc. > >>>> - lack of fences, etc. > >>>> > >>>> Jacopo: > >>>> > >>>> Apart from discussing libcamera and hope we could kickstart a review of > >>>> its API, I would like to re-start discussing multiplexed stream support, > >>>> but that would require Sakari to be there, something I'm not certain > >>>> about. Sakari? > >>>> > >>>> Alexandre: > >>>> > >>>> If Collabora/Bootlin is there, I'd certainly want to discuss stateless > >>>> codecs, in particular m2m codec helpers and finalize the specification > >>>> in general. > >>> > >>> Hans: > >>> > >>> Finalize the stateful encoder API. There are still two TODOs there, see: > >>> https://patchwork.kernel.org/cover/10972783/ > >> > >> A few Collaborans, including me will be attending. > >> > >> On my side, I'd like to discuss the staging stateless codec drivers > >> and the conditions and requirements for them to move out of staging. > > > > If time (and interest) permits, we could also discuss the next steps for > > libcamera and their implications on the kernel side. > > > > Is there any news regarding the date of the meeting ? Thursday after the > > conference would be best for me, but if it's during the conference, I > > could still attend part of the discussions (depending on the conference > > schedule). > > > > Hello, > > I will be in Lyon and would love to attend. I am pretty much new to > media subsystem and eager to learn more about it. > My interest is related to platform drivers and support for small ISPs > inside hardware controllers. I would be very interested in discussing that topic with you, at any time that would fit your schedule. > P.S. Not sure if will be still there on Thursday or only Mon-Wed -- Regards, Laurent Pinchart
Re: [ANN] Topics for a media summit in Lyon in October
Hello, On Mon, Aug 19, 2019 at 11:43:56AM -0300, Ezequiel Garcia wrote: > On Mon, 2019-08-19 at 09:44 +0200, Hans Verkuil wrote: > > On 8/16/19 10:06 AM, Hans Verkuil wrote: > > > Rather then discussing topics for a meeting under the subject 'Lisbon' > > > let's start a new thread referring to the right place :-) > > > > > > I will try to organize a room, either during the ELCE or (if that doesn't > > > work) perhaps on the Thursday afterwards. If that's going to be a problem > > > for someone, please let me know. > > > > > > I do need to know how many people I can expect. I have the following > > > confirmed attendees (and please reply if you are not listed!): > > > > > > Alexandre Courbot > > > Tomasz Figa > > > Jacopo Mondi > > > Laurent Pinchart > > > Hans Verkuil > > > > > > I know there were more who mentioned on irc that they would attend, > > > but it is easier to keep track if I have it in an email. > > > > > > Topics posted under the previous thread: > > > > > > Tomasz: > > > > > > I would want to discuss various v4l2_buffer improvements, e.g. > > > - DMA-buf import with plane offsets, > > > - unifying the buffer structs for M and non-M formats, > > > - ability to import different FDs with offsets for non-M formats if the > > > layout matches driver expectations, etc. > > > > > > Besides that, I would be interested in the general idea on handling > > > complex cameras in the Linux kernel in spite of the remaining V4L2 > > > limitations, e.g. > > > - combinatorial explosion of /dev/video nodes, > > > - significant ioctl overhead, > > > - huge amount of historical legacy making the driver and userspace > > > implementations overly difficult and prone to repetitive mistakes, > > > - the above also limiting the flexibility of the API - formats, frame > > > rates, etc. set using distinct APIs, not covered by Request API, with > > > non-failure "negotiation hell", etc. > > > - lack of fences, etc. > > > > > > Jacopo: > > > > > > Apart from discussing libcamera and hope we could kickstart a review of > > > its API, I would like to re-start discussing multiplexed stream support, > > > but that would require Sakari to be there, something I'm not certain > > > about. Sakari? > > > > > > Alexandre: > > > > > > If Collabora/Bootlin is there, I'd certainly want to discuss stateless > > > codecs, in particular m2m codec helpers and finalize the specification > > > in general. > > > > Hans: > > > > Finalize the stateful encoder API. There are still two TODOs there, see: > > https://patchwork.kernel.org/cover/10972783/ > > > > A few Collaborans, including me will be attending. > > On my side, I'd like to discuss the staging stateless codec drivers > and the conditions and requirements for them to move out of staging. If time (and interest) permits, we could also discuss the next steps for libcamera and their implications on the kernel side. Is there any news regarding the date of the meeting ? Thursday after the conference would be best for me, but if it's during the conference, I could still attend part of the discussions (depending on the conference schedule). -- Regards, Laurent Pinchart
Re: [PATCH v2] v4l: rcar-fcp: Read IP version register at probe time
Hi Geert, On Fri, Aug 16, 2019 at 10:21:42AM +0200, Geert Uytterhoeven wrote: > On Wed, Aug 14, 2019 at 4:55 PM Laurent Pinchart wrote: > > This helps identifying the IP core version, for debugging purpose only > > for now. > > > > Signed-off-by: Laurent Pinchart > > > --- a/drivers/media/platform/rcar-fcp.c > > +++ b/drivers/media/platform/rcar-fcp.c > > > @@ -138,6 +167,18 @@ static int rcar_fcp_probe(struct platform_device *pdev) > > > > pm_runtime_enable(&pdev->dev); > > > > + fcp->iomem = devm_platform_ioremap_resource(pdev, 0); > > + if (IS_ERR(fcp->iomem)) > > + return PTR_ERR(fcp->iomem); > > + > > + pm_runtime_get_sync(&pdev->dev); > > + version = rcar_fcp_read(fcp, FCP_VCR); > > + pm_runtime_put(&pdev->dev); > > Unless (dynamic) debugging is enabled, all of the above is done for obtaining > a version number that is not used. > Can this be improved? With FCNL support we'll need that anyway. This patch comes from a larger FCNL series that rejects devices with an unknown version, and I thought it could be fast-tracked in a stripped form already. I don't mind either way, I can wait until it's time to merge FCNL support. > > + > > + dev_dbg(&pdev->dev, "FCP category %u revision %u\n", > > + (version & FCP_VCR_CATEGORY_MASK) >> FCP_VCR_CATEGORY_SHIFT, > > + (version & FCP_VCR_REVISION_MASK) >> > > FCP_VCR_REVISION_SHIFT); > > + > > mutex_lock(&fcp_lock); > > list_add_tail(&fcp->list, &fcp_devices); > > mutex_unlock(&fcp_lock); -- Regards, Laurent Pinchart
Re: [PATCH v2] v4l: rcar-fcp: Read IP version register at probe time
Hi Kieran,
On Fri, Aug 16, 2019 at 09:07:14AM +0100, Kieran Bingham wrote:
> On 14/08/2019 15:54, Laurent Pinchart wrote:
> > This helps identifying the IP core version, for debugging purpose only
> > for now.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Use devm_platform_ioremap_resource()
> > ---
> > drivers/media/platform/rcar-fcp.c | 41 +++
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/drivers/media/platform/rcar-fcp.c
> > b/drivers/media/platform/rcar-fcp.c
> > index 43c78620c9d8..6e0c0e7c0f8c 100644
> > --- a/drivers/media/platform/rcar-fcp.c
> > +++ b/drivers/media/platform/rcar-fcp.c
> > @@ -8,6 +8,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -21,11 +22,38 @@
> > struct rcar_fcp_device {
> > struct list_head list;
> > struct device *dev;
> > + void __iomem *iomem;
> > };
> >
> > static LIST_HEAD(fcp_devices);
> > static DEFINE_MUTEX(fcp_lock);
> >
> > +#define FCP_VCR0x
> > +#define FCP_VCR_CATEGORY_MASK (0xff << 8)
> > +#define FCP_VCR_CATEGORY_SHIFT 8
> > +#define FCP_VCR_REVISION_MASK (0xff << 0)
> > +#define FCP_VCR_REVISION_SHIFT 0
> > +
> > +#define FCP_CFG0 0x0004
> > +#define FCP_RST0x0010
> > +#define FCP_STA0x0018
> > +#define FCP_TL_CTRL0x0070
> > +#define FCP_PICINFO1 0x00c4
> > +#define FCP_BA_ANC_Y0 0x0100
> > +#define FCP_BA_ANC_Y1 0x0104
> > +#define FCP_BA_ANC_Y2 0x0108
> > +#define FCP_BA_ANC_C 0x010c
> > +#define FCP_BA_REF_Y0 0x0110
> > +#define FCP_BA_REF_Y1 0x0114
> > +#define FCP_BA_REF_Y2 0x0118
> > +#define FCP_BA_REF_C 0x011c
>
> Do we need to pull in all these extra register definitions just to read
> the version?
>
> They don't hurt if they're for something else later...
At least FCP_CFG0 will be used for FCNL. Some of the other registers
could be left out, but I don't think they really hurt either, they don't
take any space in the compiled object.
> Otherwise,
>
> Reviewed-by: Kieran Bingham
>
> > +
> > +
> > +static inline u32 rcar_fcp_read(struct rcar_fcp_device *fcp, u32 reg)
> > +{
> > + return ioread32(fcp->iomem + reg);
> > +}
> > +
> > /*
> > -
> > * Public API
> > */
> > @@ -129,6 +157,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_disable);
> > static int rcar_fcp_probe(struct platform_device *pdev)
> > {
> > struct rcar_fcp_device *fcp;
> > + u32 version;
> >
> > fcp = devm_kzalloc(&pdev->dev, sizeof(*fcp), GFP_KERNEL);
> > if (fcp == NULL)
> > @@ -138,6 +167,18 @@ static int rcar_fcp_probe(struct platform_device *pdev)
> >
> > pm_runtime_enable(&pdev->dev);
> >
> > + fcp->iomem = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(fcp->iomem))
> > + return PTR_ERR(fcp->iomem);
> > +
> > + pm_runtime_get_sync(&pdev->dev);
> > + version = rcar_fcp_read(fcp, FCP_VCR);
> > + pm_runtime_put(&pdev->dev);
> > +
> > + dev_dbg(&pdev->dev, "FCP category %u revision %u\n",
> > + (version & FCP_VCR_CATEGORY_MASK) >> FCP_VCR_CATEGORY_SHIFT,
> > + (version & FCP_VCR_REVISION_MASK) >> FCP_VCR_REVISION_SHIFT);
> > +
> > mutex_lock(&fcp_lock);
> > list_add_tail(&fcp->list, &fcp_devices);
> > mutex_unlock(&fcp_lock);
--
Regards,
Laurent Pinchart
Re: [PATCH v6 05/13] media: tvp5150: add input source selection of_graph support
H Marco, On Thu, Aug 15, 2019 at 03:22:51PM +0200, Marco Felsch wrote: > On 19-08-15 15:51, Laurent Pinchart wrote: > > On Tue, Aug 13, 2019 at 10:54:29AM +0200, Marco Felsch wrote: > >> On 19-05-16 21:03, Laurent Pinchart wrote: > >>> On Tue, May 14, 2019 at 03:25:45PM -0300, Mauro Carvalho Chehab wrote: > >>>> Em Mon, 15 Apr 2019 14:44:05 +0200 Marco Felsch escreveu: > >>>> > >>>>> This patch adds the of_graph support to describe the tvp connections. > >>>>> Physical the TVP5150 has three ports: AIP1A, AIP1B and YOUT. As result > >>>>> of discussion [1],[2] the device-tree maps these ports 1:1. The svideo > >>>>> connector must be conneted to port@0/endpoint@1, look at the > >>>>> Documentation > >>> > >>> According to [2], it must be connected to port port@0 and port@1, not > >>> just port@0. > >> > >> You're right. I missed that.. I will change that for the v7. > >> > >>>>> for more information. Since the TVP5150 is a converter the device-tree > >>>>> must contain at least 1-input and 1-output port. The mc-connectors and > >>>>> mc-links are only created if the device-tree contains the corresponding > >>>>> connector nodes. If more than one connector is available the > >>>>> media_entity_operations.link_setup() callback ensures that only one > >>>>> connector is active. > >>>>> > >>>>> [1] https://www.spinics.net/lists/linux-media/msg138545.html > >>>>> [2] https://www.spinics.net/lists/linux-media/msg138546.html > >>>>> > >>>>> Signed-off-by: Marco Felsch > >>>>> --- > >>>>> Changelog: > >>>>> > >>>>> [1] https://patchwork.kernel.org/cover/10794703/ > >>>>> [2] https://patchwork.kernel.org/cover/10786553/ > >>>>> > >>>>> v6: > >>>>> - fix misspelled comments > >>>>> - use 'unsigned int' where it's possible > >>>>> - cleanup ifdef part-2: > >>>>> - tvp5150_mc_init, tvp5150_add_of_connectors: add surrounding > >>>>> CONFIG_MEDIA_CONTROLLER ifdef and stubs to improve readability > >>>>> - tvp5150_mc_init: uniform interface, use 'struct tvp5150' since all > >>>>> internal function do this. > >>>>> - tvp5150_add_of_connectors: call within probe() to make it cleaner > >>>>> - tvp5150_parse_dt: move local loop vars within the loop. > >>>>> > >>>>> v5: > >>>>> - Fixing build deps: > >>>>> - tvp5150_mc_init: fix CONFIG_MEDIA_CONTROLLER deps > >>>>> - struct tvp5150: drop CONFIG_MEDIA_CONTROLLER conditional property > >>>>> includes. This leads into to complex deps for futher development. > >>>>> - tvp5150_dt_cleanup: enable function only if CONFIG_OF is enabled > >>>>> - tvp5150_parse_dt: enable function only if CONFIG_OF is enabled > >>>>> - tvp5150_probe: call tvp5150_dt_cleanup only if CONFIG_OF is enabled > >>>>> > >>>>> - Simplify link_setup routine: > >>>>> - use generic connector parsing since both series [1,2] are squashed > >>>>> into > >>>>> one > >>>>> - struct tvp5150: drop pads_state and modify_second_link property > >>>>> due to link_setup() rework. > >>>>> - tvp5150_link_setup: add more comments > >>>>> - tvp5150_link_setup: simply the link setup routine a lot. Edit the > >>>>> 2nd > >>>>> link directly within the driver instead of a recursive > >>>>> media-framework > >>>>> call (__media_entity_setup_link). This improves the readability and > >>>>> shrinks the driver code. > >>>>> - tvp5150_link_setup: disable all active links in case user switches > >>>>> connectors without disable it first. > >>>>> - tvp5150_registered: simplify default link enable path due to > >>>>> link_setup() > >>>>> rework. > >>>>> > >>>>> - General cleanups > >>>>> - tvp5150_parse_dt: drop unecessary test > >>>>> - tvp5150_parse_dt: add err message due t
Re: [RFC 2/5] media: v4l2-ctrl: Document V4L2_CID_LOCATION
Hi Sakari, On Thu, Aug 15, 2019 at 04:08:49PM +0300, Sakari Ailus wrote: > On Thu, Aug 15, 2019 at 03:59:38PM +0300, Laurent Pinchart wrote: > > On Thu, Aug 15, 2019 at 10:00:25AM +0300, Sakari Ailus wrote: > > > On Wed, Aug 14, 2019 at 10:28:12PM +0200, Jacopo Mondi wrote: > > > > Add documentation for the V4L2_CID_LOCATION camera control. The newly > > > > added read-only control reports the camera device mounting position. > > > > > > > > Signed-off-by: Jacopo Mondi > > > > --- > > > > .../media/uapi/v4l/ext-ctrls-camera.rst | 23 +++ > > > > 1 file changed, 23 insertions(+) > > > > > > > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > > > > b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > > > > index 51c1d5c9eb00..fc0a02eee6d4 100644 > > > > --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > > > > +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst > > > > @@ -510,6 +510,29 @@ enum v4l2_scene_mode - > > > > value down. A value of zero stops the motion if one is in progress > > > > and has no effect otherwise. > > > > > > > > +``V4L2_CID_LOCATION (integer)`` > > > > +This read-only control describes the camera location by reporting > > > > its > > > > +mounting position on the device where the camera is installed. This > > > > +control is particularly meaningful for devices which have a well > > > > defined > > > > +orientation, such as phones, laptops and portable devices as the > > > > camera > > > > +location is expressed as a position relative to the device intended > > > > +usage position. In example, a camera installed on the user-facing > > > > side > > > > > > s/In/For/ > > > > > > > +of a phone device is said to be installed in the > > > > ``V4L2_LOCATION_FRONT`` > > > > +position. > > > > + > > > > + > > > > + > > > > +.. flat-table:: > > > > +:header-rows: 0 > > > > +:stub-columns: 0 > > > > + > > > > +* - ``V4L2_LOCATION_FRONT`` > > > > + - The camera device is located on the front side of the device. > > > > +* - ``V4L2_LOCATION_BACK`` > > > > + - The camera device is located on the back side of the device. > > > > + > > > > + > > > > + > > > > .. [#f1] > > > > This control may be changed to a menu control in the future, if more > > > > options are required. > > > > > > There's an effective limit of 64 for menus. ACPI has less than ten > > > different locations for a device, I think 64 will be enough here. > > > > > > So I'd be actually in favour of switching to a menu. > > > > Why ? As you explained yourself, it's a static read-only control, all it > > needs to report is a single value. > > Yes. That's true. It wasn't meant for this but it's nevertheless a > convenient API to get that information, both as integer and string. But why is that needed ? The integer seems enough to me. -- Regards, Laurent Pinchart
Re: [PATCH v6 02/13] media: v4l2-fwnode: add v4l2_fwnode_connector
Hi Marco, On Thu, Aug 15, 2019 at 03:04:37PM +0200, Marco Felsch wrote: > On 19-08-15 15:38, Laurent Pinchart wrote: > > On Fri, Aug 09, 2019 at 09:55:36AM +0200, Marco Felsch wrote: > >> On 19-05-16 19:36, Laurent Pinchart wrote: > >>> On Mon, Apr 15, 2019 at 02:44:02PM +0200, Marco Felsch wrote: > >>>> Currently every driver needs to parse the connector endpoints by it self. > >>> > >>> s/it self/itself/ > >>> > >>>> This is the initial work to make this generic. The generic connector has > >>>> some common fields and some connector specific parts. The generic one > >>>> includes: > >>>> - type > >>>> - label > >>>> - remote_port (the port where the connector is connected to) > >>>> - remote_id (the endpoint where the connector is connected to) > >>> > >>> This assumes a single connection between a connector and a remote port, > >>> and a single port on the connector side. Is this guaranteed ? For the > >>> mini-DIN-4 connectors (often used for S-Video) for instance, I recall > >>> from the extensive discussions we had in the past that they should be > >>> modeled with two pins, one for the Y component and one for C components. > >>> The rationale for this is to support systems where such a connector > >>> could be used to carry S-Video, but also two composite video signals > >>> (usually through an external adapter from 2 RCA female connectors to one > >>> S-Video male connector) that would be routed to two separate video > >>> decoders (or two different inputs of the same video decoder). Other > >>> topologies may be possible too. > >> > >> I got your concerns and I also remember the tvp5150 port bindings > >> myself in the past. Do you know how often such a setup you described > >> above happens these days? I would rather add more documentation to the > >> bindings [1] and add a check to v4l2_fwnode_parse_connector() to > >> guarantee that one port has only one endpoint. Because I don't think > >> that analog connectors has a bright future these days. > >> > >> [1] Documentation/devicetree/bindings/display/connector/ \ > >> analog-tv-connector.txt > > > > I have seen it on older hardware, I don't know about more recent > > systems. For the S-Video case at least, you need to support two DT > > ports, even if you don't support connecting them to two different > > devices yet. > > Can you take a look on the v7 I send a few minutes ago? I changed the > layout ;) I'll try to get to that ASAP, but I have a Rockchip driver to review first :-) > > In any case, I'm fine if those topologies are not supported yet, but it > > should be possible to support them in a backward-compatible way. In > > particular, in this case, we should make sure the DT bindings will allow > > such topologies, and the DT parsing API should make it possible to > > support them without fugure changes to drivers that use the API from > > this patch for "simple" topologies. > > You're right. I adapted the struct to be more extendible. > > >>>> The specific fields are within a union, since only one of them can be > >>>> available at the time. Since this is the initial support the patch adds > >>>> only the analog-connector specific ones. > >>>> > >>>> Signed-off-by: Marco Felsch > >>>> Reviewed-by: Jacopo Mondi > >>>> --- > >>>> [1] https://patchwork.kernel.org/cover/10794703/ > >>>> > >>>> v6: > >>>> - fix some spelling and style issues > >>>> - rm unnecessary comments > >>>> - drop vga and dvi connector > >>>> > >>>> v2-v4: > >>>> - nothing since the patch was squashed from series [1] into this > >>>> series. > >>>> > >>>> include/media/v4l2-connector.h | 30 ++ > >>>> include/media/v4l2-fwnode.h| 33 + > >>>> 2 files changed, 63 insertions(+) > >>>> create mode 100644 include/media/v4l2-connector.h > >>>> > >>>> diff --git a/include/media/v4l2-connector.h > >>>> b/include/media/v4l2-connector.h > >>>> new file mode 100644 > >>>> index ..3a951c54f50e > >>>> --- /dev/null
Re: [PATCH v6 01/13] dt-bindings: connector: analog: add tv norms property
Hi Marco, On Thu, Aug 15, 2019 at 02:50:02PM +0200, Marco Felsch wrote: > On 19-08-15 15:33, Laurent Pinchart wrote: > > On Fri, Aug 09, 2019 at 07:58:09AM +0200, Marco Felsch wrote: > >> On 19-05-16 19:27, Laurent Pinchart wrote: > >>> On Mon, Apr 15, 2019 at 02:44:01PM +0200, Marco Felsch wrote: > >>>> Some connectors no matter if in- or output supports only a limited > >>>> range of tv norms. It doesn't matter if the hardware behind that > >>>> connector supports more than the listed formats since the users are > >>>> restriced by a label e.g. to plug only a camera into this connector > >>>> which uses the PAL format. > >>>> > >>>> This patch adds the capability to describe such limitation within the > >>>> firmware. There are no format restrictions if the property isn't > >>>> present, so it's completely backward compatible. > >>> > >>> Why is this needed ? It's not really a hardware property, is it ? What's > >>> the use case ? > >> > >> Cause some hardware only support a limited range of formats to that > >> connector. Of course it is a hardware property. For example if a > >> customer wants to limit a connector to a specifc norm because the > >> hardware behind that connector only supports that format or is > >> restricted to that format. > > > > Then it should be a DT property of the hardware behind that connector > > (or information hardcoded directly into that driver), shouldn't it ? > > Why? The connector is the limiting factor and not the decoder/bridge > device behind that. Let me explain it a bit more in detail. Our customer > sells hardware boxes and cameras. The camera is connected to the box > using a custom plug. So it's guaranteed that only their cameras can be > connected to. Also the camera they are using supports only PAL. So the > PAL signal is the only one which can be received on that connector. The > TVP itself supports more than just PAL signals and has multiple inputs. > So there can be the use case that a hardware box supports two physical > connectors: e.g. connector-PAL, connector-NTSC. The TVP should be > limited to PAL signals if the connector-PAL is active or limited to NTSC > if the connector-NTSC is active. > > Hopefully you see now why we should model it on the connector side and > not on the device behind that connector. So it essentially means that if someone connects an NTSC camera on the PAL input with the same custom connector, the hardware will support it, right ? I don't think it's a hardware limitation of the connector in that case :-) And I don't think it belongs to DT. Userspace is probably where I would handle this type of policy. > >>>> Signed-off-by: Marco Felsch > >>>> Reviewed-by: Rob Herring > >>>> --- > >>>> [1] https://patchwork.kernel.org/cover/10794703/ > >>>> > >>>> v6: > >>>> - tvnorms.h: use tabs instead of spaces > >>>> - tvnorms.h: add TVNORM_PAL and TVNORM_SECAM > >>>> - tvnorms.h: drop rarely used TVNORM_ATSC_* norms > >>>> > >>>> v2-v4: > >>>> - nothing since the patch was squashed from series [1] into this > >>>> series. > >>>> > >>>> .../display/connector/analog-tv-connector.txt | 4 ++ > >>>> include/dt-bindings/media/tvnorms.h | 56 +++ > >>>> 2 files changed, 60 insertions(+) > >>>> create mode 100644 include/dt-bindings/media/tvnorms.h > >>>> > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt > >>>> > >>>> b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt > >>>> index 0c0970c210ab..346f8937a0b7 100644 > >>>> --- > >>>> a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt > >>>> +++ > >>>> b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt > >>>> @@ -6,6 +6,9 @@ Required properties: > >>>> > >>>> Optional properties: > >>>> - label: a symbolic name for the connector > >>>> +- tvnorms: limit the supported tv norms on a connector to the given > >>>> ones else > >>>> + all tv norms are allowed. Possible video standards are > >>>> defined in &
Re: [PATCH v6 12/13] media: tvp5150: add support to limit tv norms on connector
Hi Marco,
On Tue, Aug 13, 2019 at 11:10:30AM +0200, Marco Felsch wrote:
> On 19-05-16 21:07, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2019 at 02:44:12PM +0200, Marco Felsch wrote:
> > > The tvp5150 accepts NTSC(M,J,4.43), PAL (B,D,G,H,I,M,N) and SECAM video
> > > data and is able to auto-detect the input signal. The auto-detection
> > > does not work if the connector does not receive an input signal and the
> > > tvp5150 might not be configured correctly. This misconfiguration leads
> > > into wrong decoded video streams if the tvp5150 gets powered on before
> > > the video signal is present.
> > >
> > > Limit the supported tv norms according to the actual selected connector
> > > to avoid a misconfiguration.
> >
> > This seems a bit of a hack to me. In particular, on what grounds would
> > you specify a particular configuration in DT ? Also, this issue affects
> > non-DT systems, and should be solved globally.
>
> Why is this a hack? Imagine a hardware which supports PAL signals only.
> Then it should be forbidden for the user space to configure it to SECAM
> or any NTSC. Since the hardware makes the limitation it should be
> abstracted on DT level.
What part of the hardware would be the limiting factor here ? Clearly
not the TVP5150 as it supports all TV norms, and also not the connector,
as the connector hardware doesn't care about TV norms.
> > > Signed-off-by: Marco Felsch
> > > ---
> > > [1] https://patchwork.kernel.org/cover/10794703/
> > >
> > > v5:
> > > - probe() initialize supported tv-norms according the given connectors
> > > if they are available.
> > > - check if media-controller is used. Don't limit the norm if it isn't
> > > used.
> > > - add more logic to be smarter during connector changing so it is
> > > intuitiver for the user space.
> > >
> > > v2-v4:
> > > - nothing since the patch was squashed from series [1] into this
> > > series.
> > >
> > > drivers/media/i2c/tvp5150.c | 69 +++--
> > > 1 file changed, 67 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> > > index cd54715eb641..c0ee08546643 100644
> > > --- a/drivers/media/i2c/tvp5150.c
> > > +++ b/drivers/media/i2c/tvp5150.c
> > > @@ -32,6 +32,13 @@
> > > #define TVP5150_MBUS_FMT MEDIA_BUS_FMT_UYVY8_2X8
> > > #define TVP5150_FIELDV4L2_FIELD_ALTERNATE
> > > #define TVP5150_COLORSPACE V4L2_COLORSPACE_SMPTE170M
> > > +#define TVP5150_STD_MASK (V4L2_STD_NTSC | \
> > > + V4L2_STD_NTSC_443 | \
> > > + V4L2_STD_PAL | \
> > > + V4L2_STD_PAL_M| \
> > > + V4L2_STD_PAL_N| \
> > > + V4L2_STD_PAL_Nc | \
> > > + V4L2_STD_SECAM)
> > >
> > > MODULE_DESCRIPTION("Texas Instruments TVP5150A/TVP5150AM1/TVP5151 video
> > > decoder driver");
> > > MODULE_AUTHOR("Mauro Carvalho Chehab");
> > > @@ -66,6 +73,7 @@ struct tvp5150 {
> > > /* media-ctl properties */
> > > struct media_pad pads[TVP5150_NUM_PADS];
> > > struct tvp5150_connector *connectors;
> > > + struct tvp5150_connector *cur_connector;
> > > int connectors_num;
> > >
> > > struct v4l2_ctrl_handler hdl;
> > > @@ -785,17 +793,28 @@ static int tvp5150_g_std(struct v4l2_subdev *sd,
> > > v4l2_std_id *std)
> > > static int tvp5150_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
> > > {
> > > struct tvp5150 *decoder = to_tvp5150(sd);
> > > + struct tvp5150_connector *cur_con = decoder->cur_connector;
> > > + v4l2_std_id supported_norms = cur_con ?
> > > + cur_con->base.connector.analog.supported_tvnorms : V4L2_STD_ALL;
> > >
> > > if (decoder->norm == std)
> > > return 0;
> > >
> > > + /*
> > > + * check if requested std or group of std's is/are supported by the
> > > + * connector
> > > + */
> > > + if ((supported_norms & std) == 0)
> > > + return -EINVAL;
> > > +
> > > /* Change cropping height limits */
> > > if (std & V4L2_STD_525_60)
> > > decoder->rect.height = TVP5150_V_MAX_525_60;
> > > else
> >
Re: [PATCH v6 05/13] media: tvp5150: add input source selection of_graph support
On Tue, Aug 13, 2019 at 10:54:29AM +0200, Marco Felsch wrote:
> Hi Laurent,
>
> On 19-05-16 21:03, Laurent Pinchart wrote:
> > Hello Marco,
> >
> > Thank you for the patch.
> >
> > On Tue, May 14, 2019 at 03:25:45PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 15 Apr 2019 14:44:05 +0200 Marco Felsch escreveu:
> > >
> > > > This patch adds the of_graph support to describe the tvp connections.
> > > > Physical the TVP5150 has three ports: AIP1A, AIP1B and YOUT. As result
> > > > of discussion [1],[2] the device-tree maps these ports 1:1. The svideo
> > > > connector must be conneted to port@0/endpoint@1, look at the
> > > > Documentation
> >
> > According to [2], it must be connected to port port@0 and port@1, not
> > just port@0.
>
> You're right. I missed that.. I will change that for the v7.
>
> > > > for more information. Since the TVP5150 is a converter the device-tree
> > > > must contain at least 1-input and 1-output port. The mc-connectors and
> > > > mc-links are only created if the device-tree contains the corresponding
> > > > connector nodes. If more than one connector is available the
> > > > media_entity_operations.link_setup() callback ensures that only one
> > > > connector is active.
> > > >
> > > > [1] https://www.spinics.net/lists/linux-media/msg138545.html
> > > > [2] https://www.spinics.net/lists/linux-media/msg138546.html
> > > >
> > > > Signed-off-by: Marco Felsch
> > > > ---
> > > > Changelog:
> > > >
> > > > [1] https://patchwork.kernel.org/cover/10794703/
> > > > [2] https://patchwork.kernel.org/cover/10786553/
> > > >
> > > > v6:
> > > > - fix misspelled comments
> > > > - use 'unsigned int' where it's possible
> > > > - cleanup ifdef part-2:
> > > > - tvp5150_mc_init, tvp5150_add_of_connectors: add surrounding
> > > > CONFIG_MEDIA_CONTROLLER ifdef and stubs to improve readability
> > > > - tvp5150_mc_init: uniform interface, use 'struct tvp5150' since all
> > > > internal function do this.
> > > > - tvp5150_add_of_connectors: call within probe() to make it cleaner
> > > > - tvp5150_parse_dt: move local loop vars within the loop.
> > > >
> > > > v5:
> > > > - Fixing build deps:
> > > > - tvp5150_mc_init: fix CONFIG_MEDIA_CONTROLLER deps
> > > > - struct tvp5150: drop CONFIG_MEDIA_CONTROLLER conditional property
> > > > includes. This leads into to complex deps for futher development.
> > > > - tvp5150_dt_cleanup: enable function only if CONFIG_OF is enabled
> > > > - tvp5150_parse_dt: enable function only if CONFIG_OF is enabled
> > > > - tvp5150_probe: call tvp5150_dt_cleanup only if CONFIG_OF is enabled
> > > >
> > > > - Simplify link_setup routine:
> > > > - use generic connector parsing since both series [1,2] are squashed
> > > > into
> > > > one
> > > > - struct tvp5150: drop pads_state and modify_second_link property
> > > > due to link_setup() rework.
> > > > - tvp5150_link_setup: add more comments
> > > > - tvp5150_link_setup: simply the link setup routine a lot. Edit the
> > > > 2nd
> > > > link directly within the driver instead of a recursive
> > > > media-framework
> > > > call (__media_entity_setup_link). This improves the readability and
> > > > shrinks the driver code.
> > > > - tvp5150_link_setup: disable all active links in case user switches
> > > > connectors without disable it first.
> > > > - tvp5150_registered: simplify default link enable path due to
> > > > link_setup()
> > > > rework.
> > > >
> > > > - General cleanups
> > > > - tvp5150_parse_dt: drop unecessary test
> > > > - tvp5150_parse_dt: add err message due to misconfiguration
> > > > - tvp5150_parse_dt: make use of V4L2_MBUS_UNKNOWN definition
> > > > - s/dev_dbg/dev_dbg_lvl
> > > >
> > > > v4:
> > > > - rebase on top of media_tree/master, fix merge conflict due to commit
> > > >60359a28d592 ("media: v4l: fwnode: Initialise the V4L2 fwnode
> > > > endpoints
> > > >to zero")
> > > >
> > > > v3:
Re: [PATCH v6 03/13] media: v4l2-fwnode: add initial connector parsing support
Hi Marco,
On Fri, Aug 09, 2019 at 02:16:06PM +0200, Marco Felsch wrote:
> On 19-05-16 19:51, Laurent Pinchart wrote:
> > On Tue, May 14, 2019 at 03:20:04PM -0300, Mauro Carvalho Chehab wrote:
> >> Em Mon, 6 May 2019 12:10:41 +0200 Hans Verkuil escreveu:
> >>> On 4/15/19 2:44 PM, Marco Felsch wrote:
> >>>> The patch adds the initial connector parsing code, so we can move from a
> >>>> driver specific parsing code to a generic one. Currently only the
> >>>> generic fields and the analog-connector specific fields are parsed.
> >>>> Parsing
> >>>> the other connector specific fields can be added by a simple callbacks.
> >>>>
> >>>> Signed-off-by: Marco Felsch
> >>>> Reviewed-by: Jacopo Mondi
> >>>> ---
> >>>> [1] https://patchwork.kernel.org/cover/10794703/
> >>>>
> >>>> v6:
> >>>> - use 'unsigned int' count var
> >>>> - fix comment and style issues
> >>>> - place '/* fall through */' to correct places
> >>>> - fix error handling and cleanup by releasing fwnode
> >>>> - drop vga and dvi parsing support as those connectors are rarely used
> >>>> these days
> >>>>
> >>>> v5:
> >>>> - s/strlcpy/strscpy/
> >>>>
> >>>> v2-v4:
> >>>> - nothing since the patch was squashed from series [1] into this
> >>>> series.
> >>>>
> >>>> drivers/media/v4l2-core/v4l2-fwnode.c | 111 ++
> >>>> include/media/v4l2-fwnode.h | 16
> >>>> 2 files changed, 127 insertions(+)
> >>>>
> >>>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
> >>>> b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>>> index 20571846e636..f1cca95c8fef 100644
> >>>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> >>>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>>> @@ -592,6 +592,117 @@ void v4l2_fwnode_put_link(struct v4l2_fwnode_link
> >>>> *link)
> >>>> }
> >>>> EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link);
> >>>>
> >>>> +static const struct v4l2_fwnode_connector_conv {
> >>>> +enum v4l2_connector_type type;
> >>>> +const char *name;
> >
> > Maybe compatible instead of name ?
>
> Okay, I can change that.
>
> >>>> +} connectors[] = {
> >>>> +{
> >>>> +.type = V4L2_CON_COMPOSITE,
> >>>> +.name = "composite-video-connector",
> >>>> +}, {
> >>>> +.type = V4L2_CON_SVIDEO,
> >>>> +.name = "svideo-connector",
> >>>> +}, {
> >>>> +.type = V4L2_CON_HDMI,
> >>>> +.name = "hdmi-connector",
> >>>> +},
> >>>> +};
> >>>> +
> >>>> +static enum v4l2_connector_type
> >>>> +v4l2_fwnode_string_to_connector_type(const char *con_str)
> >>>> +{
> >>>> +unsigned int i;
> >>>> +
> >>>> +for (i = 0; i < ARRAY_SIZE(connectors); i++)
> >>>> +if (!strcmp(con_str, connectors[i].name))
> >>>> +return connectors[i].type;
> >>>> +
> >>>> +/* no valid connector found */
> >
> > The usual comment style in this file is to start with a capital letter
> > and end sentences with a period. I would however drop this comment, it's
> > not very useful. The other comments should be updated accordingly.
>
> I will change my comments and drop this one.
>
> >>>> +return V4L2_CON_UNKNOWN;
> >>>> +}
> >>>> +
> >>>> +static int
> >>>> +v4l2_fwnode_connector_parse_analog(struct fwnode_handle *fwnode,
> >>>> + struct v4l2_fwnode_connector *vc)
> >>>> +{
> >>>> +u32 tvnorms;
> >>>> +int ret;
> >>>> +
> >>>> +ret = fwnode_property_read_u32(fwnode, "tvnorms", &tvnorms);
> >>>> +
> >>>> +/* tvnorms is optional */
> >>>> +vc->connector
Re: [PATCH v6 02/13] media: v4l2-fwnode: add v4l2_fwnode_connector
Hi Marco, On Fri, Aug 09, 2019 at 09:55:36AM +0200, Marco Felsch wrote: > On 19-05-16 19:36, Laurent Pinchart wrote: > > On Mon, Apr 15, 2019 at 02:44:02PM +0200, Marco Felsch wrote: > > > Currently every driver needs to parse the connector endpoints by it self. > > > > s/it self/itself/ > > > > > This is the initial work to make this generic. The generic connector has > > > some common fields and some connector specific parts. The generic one > > > includes: > > > - type > > > - label > > > - remote_port (the port where the connector is connected to) > > > - remote_id (the endpoint where the connector is connected to) > > > > This assumes a single connection between a connector and a remote port, > > and a single port on the connector side. Is this guaranteed ? For the > > mini-DIN-4 connectors (often used for S-Video) for instance, I recall > > from the extensive discussions we had in the past that they should be > > modeled with two pins, one for the Y component and one for C components. > > The rationale for this is to support systems where such a connector > > could be used to carry S-Video, but also two composite video signals > > (usually through an external adapter from 2 RCA female connectors to one > > S-Video male connector) that would be routed to two separate video > > decoders (or two different inputs of the same video decoder). Other > > topologies may be possible too. > > I got your concerns and I also remember the tvp5150 port bindings > myself in the past. Do you know how often such a setup you described > above happens these days? I would rather add more documentation to the > bindings [1] and add a check to v4l2_fwnode_parse_connector() to > guarantee that one port has only one endpoint. Because I don't think > that analog connectors has a bright future these days. > > [1] Documentation/devicetree/bindings/display/connector/ \ > analog-tv-connector.txt I have seen it on older hardware, I don't know about more recent systems. For the S-Video case at least, you need to support two DT ports, even if you don't support connecting them to two different devices yet. In any case, I'm fine if those topologies are not supported yet, but it should be possible to support them in a backward-compatible way. In particular, in this case, we should make sure the DT bindings will allow such topologies, and the DT parsing API should make it possible to support them without fugure changes to drivers that use the API from this patch for "simple" topologies. > > > The specific fields are within a union, since only one of them can be > > > available at the time. Since this is the initial support the patch adds > > > only the analog-connector specific ones. > > > > > > Signed-off-by: Marco Felsch > > > Reviewed-by: Jacopo Mondi > > > --- > > > [1] https://patchwork.kernel.org/cover/10794703/ > > > > > > v6: > > > - fix some spelling and style issues > > > - rm unnecessary comments > > > - drop vga and dvi connector > > > > > > v2-v4: > > > - nothing since the patch was squashed from series [1] into this > > > series. > > > > > > include/media/v4l2-connector.h | 30 ++ > > > include/media/v4l2-fwnode.h| 33 + > > > 2 files changed, 63 insertions(+) > > > create mode 100644 include/media/v4l2-connector.h > > > > > > diff --git a/include/media/v4l2-connector.h > > > b/include/media/v4l2-connector.h > > > new file mode 100644 > > > index ..3a951c54f50e > > > --- /dev/null > > > +++ b/include/media/v4l2-connector.h > > > @@ -0,0 +1,30 @@ > > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > > +/* > > > + * v4l2-connector.h > > > + * > > > + * V4L2 connector types. > > > + * > > > + * Copyright 2019 Pengutronix, Marco Felsch > > > + */ > > > + > > > +#ifndef V4L2_CONNECTOR_H > > > +#define V4L2_CONNECTOR_H > > > + > > > +#define V4L2_CONNECTOR_MAX_LABEL 41 > > > > Hans pointed out this was a weird number. Should you turn the label > > field into a pointer to make this more generic (with a > > v4l2_fwnode_connector_cleanup() function then) ? > > Yes, that would be the better approach. I will change that. > > > > + > > > +/** > > > + * enum v4l2_connector_type - connector type > > > + * @V4L2_CON_UNKNOWN: unknown con
Re: [PATCH v6 01/13] dt-bindings: connector: analog: add tv norms property
Hi Marco,
On Fri, Aug 09, 2019 at 07:58:09AM +0200, Marco Felsch wrote:
> On 19-05-16 19:27, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2019 at 02:44:01PM +0200, Marco Felsch wrote:
> > > Some connectors no matter if in- or output supports only a limited
> > > range of tv norms. It doesn't matter if the hardware behind that
> > > connector supports more than the listed formats since the users are
> > > restriced by a label e.g. to plug only a camera into this connector
> > > which uses the PAL format.
> > >
> > > This patch adds the capability to describe such limitation within the
> > > firmware. There are no format restrictions if the property isn't
> > > present, so it's completely backward compatible.
> >
> > Why is this needed ? It's not really a hardware property, is it ? What's
> > the use case ?
>
> Cause some hardware only support a limited range of formats to that
> connector. Of course it is a hardware property. For example if a
> customer wants to limit a connector to a specifc norm because the
> hardware behind that connector only supports that format or is
> restricted to that format.
Then it should be a DT property of the hardware behind that connector
(or information hardcoded directly into that driver), shouldn't it ?
> > > Signed-off-by: Marco Felsch
> > > Reviewed-by: Rob Herring
> > > ---
> > > [1] https://patchwork.kernel.org/cover/10794703/
> > >
> > > v6:
> > > - tvnorms.h: use tabs instead of spaces
> > > - tvnorms.h: add TVNORM_PAL and TVNORM_SECAM
> > > - tvnorms.h: drop rarely used TVNORM_ATSC_* norms
> > >
> > > v2-v4:
> > > - nothing since the patch was squashed from series [1] into this
> > > series.
> > >
> > > .../display/connector/analog-tv-connector.txt | 4 ++
> > > include/dt-bindings/media/tvnorms.h | 56 +++
> > > 2 files changed, 60 insertions(+)
> > > create mode 100644 include/dt-bindings/media/tvnorms.h
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> > >
> > > b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> > > index 0c0970c210ab..346f8937a0b7 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> > > +++
> > > b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
> > > @@ -6,6 +6,9 @@ Required properties:
> > >
> > > Optional properties:
> > > - label: a symbolic name for the connector
> > > +- tvnorms: limit the supported tv norms on a connector to the given ones
> > > else
> > > + all tv norms are allowed. Possible video standards are
> > > defined in
> > > + include/dt-bindings/media/tvnorms.h.
> > >
> > > Required nodes:
> > > - Video port for TV input
> > > @@ -16,6 +19,7 @@ Example
> > > tv: connector {
> > > compatible = "composite-video-connector";
> > > label = "tv";
> > > + tvnorms = <(TVNORM_PAL_M | TVNORM_NTSC_M)>;
> > >
> > > port {
> > > tv_connector_in: endpoint {
> > > diff --git a/include/dt-bindings/media/tvnorms.h
> > > b/include/dt-bindings/media/tvnorms.h
> > > new file mode 100644
> > > index ..058ab8414145
> > > --- /dev/null
> > > +++ b/include/dt-bindings/media/tvnorms.h
> > > @@ -0,0 +1,56 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-only or X11 */
> > > +/*
> > > + * Copyright 2019 Pengutronix, Marco Felsch
> > > + */
> > > +
> > > +#ifndef _DT_BINDINGS_MEDIA_TVNORMS_H
> > > +#define _DT_BINDINGS_MEDIA_TVNORMS_H
> > > +
> > > +/* one bit for each */
> > > +#define TVNORM_PAL_B 0x0001
> > > +#define TVNORM_PAL_B10x0002
> > > +#define TVNORM_PAL_G 0x0004
> > > +#define TVNORM_PAL_H 0x0008
> > > +#define TVNORM_PAL_I 0x0010
> > > +#define TVNORM_PAL_D 0x0020
> > > +#define TVNORM_PAL_D10x0040
> > > +#define TVNORM_PAL_K 0x0080
> > > +
> > > +#define TVNORM_PAL (TVNORM_PAL_B | \
> > > + TVNORM_PAL_B1 | \
> > > +
[GIT PULL FOR v5.4] R-Car VSP1 change
Hi Mauro, The following changes since commit b20a6e298bcb8cb8ae18de26baaf462a6418515b: media: rc: imon: Allow iMON RC protocol for ffdc 7e device (2019-08-14 05:08:27 -0300) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/vsp1-next-20190814 for you to fetch changes up to f95c54e35811b711ce73e5a54c6a01e096bc324f: media: vsp1: fix memory leak of dl on error return path (2019-08-14 17:55:22 +0300) Miscellaneous R-Car VSP1 fix Colin Ian King (1): media: vsp1: fix memory leak of dl on error return path drivers/media/platform/vsp1/vsp1_dl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- Regards, Laurent Pinchart
[PATCH] media: uvc: Fix error path in control parsing failure
When parsing the UVC control descriptors fails, the error path tries to
cleanup a media device that hasn't been initialised, potentially
resulting in a crash. Fix this by initialising the media device before
the error handling path can be reached.
Fixes: 5a254d751e52 ("[media] uvcvideo: Register a v4l2_device")
Reported-by: syzbot+c86454eb3af9e8a4d...@syzkaller.appspotmail.com
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_driver.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 66ee168ddc7e..428235ca2635 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2151,6 +2151,20 @@ static int uvc_probe(struct usb_interface *intf,
sizeof(dev->name) - len);
}
+ /* Initialize the media device. */
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->mdev.dev = &intf->dev;
+ strscpy(dev->mdev.model, dev->name, sizeof(dev->mdev.model));
+ if (udev->serial)
+ strscpy(dev->mdev.serial, udev->serial,
+ sizeof(dev->mdev.serial));
+ usb_make_path(udev, dev->mdev.bus_info, sizeof(dev->mdev.bus_info));
+ dev->mdev.hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
+ media_device_init(&dev->mdev);
+
+ dev->vdev.mdev = &dev->mdev;
+#endif
+
/* Parse the Video Class control descriptor. */
if (uvc_parse_control(dev) < 0) {
uvc_trace(UVC_TRACE_PROBE, "Unable to parse UVC "
@@ -2171,19 +2185,7 @@ static int uvc_probe(struct usb_interface *intf,
"linux-uvc-devel mailing list.\n");
}
- /* Initialize the media device and register the V4L2 device. */
-#ifdef CONFIG_MEDIA_CONTROLLER
- dev->mdev.dev = &intf->dev;
- strscpy(dev->mdev.model, dev->name, sizeof(dev->mdev.model));
- if (udev->serial)
- strscpy(dev->mdev.serial, udev->serial,
- sizeof(dev->mdev.serial));
- usb_make_path(udev, dev->mdev.bus_info, sizeof(dev->mdev.bus_info));
- dev->mdev.hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
- media_device_init(&dev->mdev);
-
- dev->vdev.mdev = &dev->mdev;
-#endif
+ /* Register the V4L2 device. */
if (v4l2_device_register(&intf->dev, &dev->vdev) < 0)
goto error;
--
Regards,
Laurent Pinchart
[PATCH v2] v4l: rcar-fcp: Read IP version register at probe time
This helps identifying the IP core version, for debugging purpose only
for now.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Use devm_platform_ioremap_resource()
---
drivers/media/platform/rcar-fcp.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/drivers/media/platform/rcar-fcp.c
b/drivers/media/platform/rcar-fcp.c
index 43c78620c9d8..6e0c0e7c0f8c 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -21,11 +22,38 @@
struct rcar_fcp_device {
struct list_head list;
struct device *dev;
+ void __iomem *iomem;
};
static LIST_HEAD(fcp_devices);
static DEFINE_MUTEX(fcp_lock);
+#define FCP_VCR0x
+#define FCP_VCR_CATEGORY_MASK (0xff << 8)
+#define FCP_VCR_CATEGORY_SHIFT 8
+#define FCP_VCR_REVISION_MASK (0xff << 0)
+#define FCP_VCR_REVISION_SHIFT 0
+
+#define FCP_CFG0 0x0004
+#define FCP_RST0x0010
+#define FCP_STA0x0018
+#define FCP_TL_CTRL0x0070
+#define FCP_PICINFO1 0x00c4
+#define FCP_BA_ANC_Y0 0x0100
+#define FCP_BA_ANC_Y1 0x0104
+#define FCP_BA_ANC_Y2 0x0108
+#define FCP_BA_ANC_C 0x010c
+#define FCP_BA_REF_Y0 0x0110
+#define FCP_BA_REF_Y1 0x0114
+#define FCP_BA_REF_Y2 0x0118
+#define FCP_BA_REF_C 0x011c
+
+
+static inline u32 rcar_fcp_read(struct rcar_fcp_device *fcp, u32 reg)
+{
+ return ioread32(fcp->iomem + reg);
+}
+
/*
-
* Public API
*/
@@ -129,6 +157,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_disable);
static int rcar_fcp_probe(struct platform_device *pdev)
{
struct rcar_fcp_device *fcp;
+ u32 version;
fcp = devm_kzalloc(&pdev->dev, sizeof(*fcp), GFP_KERNEL);
if (fcp == NULL)
@@ -138,6 +167,18 @@ static int rcar_fcp_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
+ fcp->iomem = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(fcp->iomem))
+ return PTR_ERR(fcp->iomem);
+
+ pm_runtime_get_sync(&pdev->dev);
+ version = rcar_fcp_read(fcp, FCP_VCR);
+ pm_runtime_put(&pdev->dev);
+
+ dev_dbg(&pdev->dev, "FCP category %u revision %u\n",
+ (version & FCP_VCR_CATEGORY_MASK) >> FCP_VCR_CATEGORY_SHIFT,
+ (version & FCP_VCR_REVISION_MASK) >> FCP_VCR_REVISION_SHIFT);
+
mutex_lock(&fcp_lock);
list_add_tail(&fcp->list, &fcp_devices);
mutex_unlock(&fcp_lock);
--
Regards,
Laurent Pinchart
Re: [ANN] Media summit in Lisbon at September
On Wed, Aug 14, 2019 at 05:35:48PM +0900, Alexandre Courbot wrote: > That could be nice. Of course something more informal is also fine. > Anyone else planning to attend? I suspect Laurent and people living in > France might be there? I will, and so should the whole libcamera team. > On Mon, Aug 12, 2019 at 4:28 PM Hans Verkuil wrote: > > On 8/12/19 6:00 AM, Alexandre Courbot wrote: > > > On Thu, Aug 8, 2019 at 9:55 PM Mauro Carvalho Chehab wrote: > > >> Em Thu, 1 Aug 2019 09:34:00 -0300 Mauro Carvalho Chehab escreveu: > > >>> Em Sun, 30 Jun 2019 13:44:04 -0300 Mauro Carvalho Chehab escreveu: > > >>> > > >>>> Hi all, > > >>>> > > >>>> We are organizing a media mini-summit in Lisbon to happen in September, > > >>>> at the same week as the Linux Plumber Conference and the Kernel Summit. > > >>>> > > >>>> We're still discussing the details about that. > > >>> > > >>> Gently reminder. > > >>> > > >>> Right now, we have just one extra theme proposal from Sean: > > >>> > > >>> - possible dvb improvements. > > >>> > > >>> If we don't have more proposals, we may end skipping the Media > > >>> Summit this year. > > >> > > >> It sounds that we won't have material to have a media summit this year. > > >> So, let's cancel the media summit this year. > > > > > > Loosely related, but are there people planning to go to ELCE on > > > 10/28-30? Tomasz and I may attend if there is a chance to discuss > > > libcamera/V4L2 codecs. > > > > I'll be there and if there is enough interest in setting up a meeting > > to discuss this, then I can ask the LF to set a room aside for us for, > > say, half a day or so. -- Regards, Laurent Pinchart
Re: [PATCH 2/2] omap3isp: Don't set streaming state on random subdevs
Hi Sakari, Thank you for the patch. On Mon, Aug 12, 2019 at 11:32:27AM +0300, Sakari Ailus wrote: > The streaming state should be set to the first upstream sub-device only, > not everywhere, for a sub-device driver itself knows how to best control > the streaming state of its own upstream sub-devices. > > Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/isp.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c > index 008933beebe0..52533cdafb47 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -722,6 +722,10 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe, > s_stream, mode); > pipe->do_propagation = true; > } > + > + /* Stop at the first external sub-device. */ > + if (subdev->dev != isp->dev) > + break; > } > > return 0; > @@ -836,6 +840,10 @@ static int isp_pipeline_disable(struct isp_pipeline > *pipe) > &subdev->entity); > failure = -ETIMEDOUT; > } > + > + /* Stop at the first external sub-device. */ > + if (subdev->dev != isp->dev) > + break; > } > > return failure; -- Regards, Laurent Pinchart
Re: [PATCH 1/2] omap3isp: Set device on omap3isp subdevs
Hi Sakari,
Thank you for the patch.
On Mon, Aug 12, 2019 at 11:32:26AM +0300, Sakari Ailus wrote:
> The omap3isp driver registered subdevs without the dev field being set. Do
> that now.
>
> Signed-off-by: Sakari Ailus
The change looks fine, so
Reviewed-by: Laurent Pinchart
What are the implications of not setting the dev field ?
> ---
> drivers/media/platform/omap3isp/ispccdc.c| 1 +
> drivers/media/platform/omap3isp/ispccp2.c| 1 +
> drivers/media/platform/omap3isp/ispcsi2.c| 1 +
> drivers/media/platform/omap3isp/isppreview.c | 1 +
> drivers/media/platform/omap3isp/ispresizer.c | 1 +
> drivers/media/platform/omap3isp/ispstat.c| 2 ++
> 6 files changed, 7 insertions(+)
>
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c
> index 261ad1175f98..9297281402f5 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -2605,6 +2605,7 @@ int omap3isp_ccdc_register_entities(struct
> isp_ccdc_device *ccdc,
> int ret;
>
> /* Register the subdev and video node. */
> + ccdc->subdev.dev = vdev->mdev->dev;
> ret = v4l2_device_register_subdev(vdev, &ccdc->subdev);
> if (ret < 0)
> goto error;
> diff --git a/drivers/media/platform/omap3isp/ispccp2.c
> b/drivers/media/platform/omap3isp/ispccp2.c
> index 2dea423ffc0e..3cf9a32c1d9e 100644
> --- a/drivers/media/platform/omap3isp/ispccp2.c
> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> @@ -1034,6 +1034,7 @@ int omap3isp_ccp2_register_entities(struct
> isp_ccp2_device *ccp2,
> int ret;
>
> /* Register the subdev and video nodes. */
> + ccp2->subdev.dev = vdev->mdev->dev;
> ret = v4l2_device_register_subdev(vdev, &ccp2->subdev);
> if (ret < 0)
> goto error;
> diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
> b/drivers/media/platform/omap3isp/ispcsi2.c
> index da66ea65be5d..9977702d57ff 100644
> --- a/drivers/media/platform/omap3isp/ispcsi2.c
> +++ b/drivers/media/platform/omap3isp/ispcsi2.c
> @@ -1201,6 +1201,7 @@ int omap3isp_csi2_register_entities(struct
> isp_csi2_device *csi2,
> int ret;
>
> /* Register the subdev and video nodes. */
> + csi2->subdev.dev = vdev->mdev->dev;
> ret = v4l2_device_register_subdev(vdev, &csi2->subdev);
> if (ret < 0)
> goto error;
> diff --git a/drivers/media/platform/omap3isp/isppreview.c
> b/drivers/media/platform/omap3isp/isppreview.c
> index 6ea6aeafd751..94fc9cf01436 100644
> --- a/drivers/media/platform/omap3isp/isppreview.c
> +++ b/drivers/media/platform/omap3isp/isppreview.c
> @@ -2228,6 +2228,7 @@ int omap3isp_preview_register_entities(struct
> isp_prev_device *prev,
> int ret;
>
> /* Register the subdev and video nodes. */
> + prev->subdev.dev = vdev->mdev->dev;
> ret = v4l2_device_register_subdev(vdev, &prev->subdev);
> if (ret < 0)
> goto error;
> diff --git a/drivers/media/platform/omap3isp/ispresizer.c
> b/drivers/media/platform/omap3isp/ispresizer.c
> index b281cae036b3..d5cce8b8af97 100644
> --- a/drivers/media/platform/omap3isp/ispresizer.c
> +++ b/drivers/media/platform/omap3isp/ispresizer.c
> @@ -1684,6 +1684,7 @@ int omap3isp_resizer_register_entities(struct
> isp_res_device *res,
> int ret;
>
> /* Register the subdev and video nodes. */
> + res->subdev.dev = vdev->mdev->dev;
> ret = v4l2_device_register_subdev(vdev, &res->subdev);
> if (ret < 0)
> goto error;
> diff --git a/drivers/media/platform/omap3isp/ispstat.c
> b/drivers/media/platform/omap3isp/ispstat.c
> index 46a42c5dc1cc..bb1578d6eaf6 100644
> --- a/drivers/media/platform/omap3isp/ispstat.c
> +++ b/drivers/media/platform/omap3isp/ispstat.c
> @@ -1029,6 +1029,8 @@ void omap3isp_stat_unregister_entities(struct ispstat
> *stat)
> int omap3isp_stat_register_entities(struct ispstat *stat,
> struct v4l2_device *vdev)
> {
> + stat->subdev.dev = vdev->mdev->dev;
> +
> return v4l2_device_register_subdev(vdev, &stat->subdev);
> }
>
> --
> 2.20.1
>
--
Regards,
Laurent Pinchart
Re: [PATCH v2 4/6] rcar-vin: Do not reset the crop and compose rectangles in s_fmt
Hi Niklas, Thank you for the patch. On Thu, Aug 08, 2019 at 03:18:48AM +0200, Niklas Söderlund wrote: > The crop and compose rectangles are reset when s_fmt is called > resulting in potentially valid rectangles being lost when updating the > format. Isn't this the expected behaviour ? > Fix this by mapping the rectangles inside the new format. > > Signed-off-by: Niklas Söderlund > Reviewed-by: Kieran Bingham > --- > drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c > b/drivers/media/platform/rcar-vin/rcar-v4l2.c > index 8b30267f1636aaf1..5dcd787a9cf96ac9 100644 > --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c > +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c > @@ -279,8 +279,8 @@ static int rvin_s_fmt_vid_cap(struct file *file, void > *priv, > return ret; > > vin->format = f->fmt.pix; > - vin->crop = crop; > - vin->compose = compose; > + v4l2_rect_map_inside(&vin->crop, &crop); > + v4l2_rect_map_inside(&vin->compose, &compose); > vin->src_rect = crop; > > return 0; -- Regards, Laurent Pinchart
Re: [PATCH v2 3/6] rcar-vin: Rename rectangle holding the video source information
Hi Niklas,
Thank you for the patch.
On Thu, Aug 08, 2019 at 03:18:47AM +0200, Niklas Söderlund wrote:
> The variable to hold the video source information dimensions was poorly
> named 'source'. This is confusing as a lot of other members of structs
> share the same name with different purposes, rename it src_rect in
> preparation of refactoring code.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 33 +++--
> drivers/media/platform/rcar-vin/rcar-vin.h | 4 +--
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 402b40fcf7184fde..8b30267f1636aaf1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -163,13 +163,13 @@ static int rvin_reset_format(struct rvin_dev *vin)
>
> rvin_format_align(vin, &vin->format);
>
> - vin->source.top = 0;
> - vin->source.left = 0;
> - vin->source.width = vin->format.width;
> - vin->source.height = vin->format.height;
> + vin->src_rect.top = 0;
> + vin->src_rect.left = 0;
> + vin->src_rect.width = vin->format.width;
> + vin->src_rect.height = vin->format.height;
>
> - vin->crop = vin->source;
> - vin->compose = vin->source;
> + vin->crop = vin->src_rect;
> + vin->compose = vin->src_rect;
>
> return 0;
> }
> @@ -281,7 +281,7 @@ static int rvin_s_fmt_vid_cap(struct file *file, void
> *priv,
> vin->format = f->fmt.pix;
> vin->crop = crop;
> vin->compose = compose;
> - vin->source = crop;
> + vin->src_rect = crop;
>
> return 0;
> }
> @@ -319,8 +319,8 @@ static int rvin_g_selection(struct file *file, void *fh,
> case V4L2_SEL_TGT_CROP_BOUNDS:
> case V4L2_SEL_TGT_CROP_DEFAULT:
> s->r.left = s->r.top = 0;
> - s->r.width = vin->source.width;
> - s->r.height = vin->source.height;
> + s->r.width = vin->src_rect.width;
> + s->r.height = vin->src_rect.height;
> break;
> case V4L2_SEL_TGT_CROP:
> s->r = vin->crop;
> @@ -362,21 +362,22 @@ static int rvin_s_selection(struct file *file, void *fh,
> case V4L2_SEL_TGT_CROP:
> /* Can't crop outside of source input */
> max_rect.top = max_rect.left = 0;
> - max_rect.width = vin->source.width;
> - max_rect.height = vin->source.height;
> + max_rect.width = vin->src_rect.width;
> + max_rect.height = vin->src_rect.height;
> v4l2_rect_map_inside(&r, &max_rect);
>
> - v4l_bound_align_image(&r.width, 6, vin->source.width, 0,
> - &r.height, 2, vin->source.height, 0, 0);
> + v4l_bound_align_image(&r.width, 6, vin->src_rect.width, 0,
> + &r.height, 2, vin->src_rect.height, 0, 0);
>
> - r.top = clamp_t(s32, r.top, 0, vin->source.height - r.height);
> - r.left = clamp_t(s32, r.left, 0, vin->source.width - r.width);
> + r.top = clamp_t(s32, r.top, 0,
> + vin->src_rect.height - r.height);
> + r.left = clamp_t(s32, r.left, 0, vin->src_rect.width - r.width);
>
> vin->crop = s->r = r;
>
> vin_dbg(vin, "Cropped %dx%d@%d:%d of %dx%d\n",
> r.width, r.height, r.left, r.top,
> - vin->source.width, vin->source.height);
> + vin->src_rect.width, vin->src_rect.height);
> break;
> case V4L2_SEL_TGT_COMPOSE:
> /* Make sure compose rect fits inside output format */
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index e562c2ff21ec7e7b..86e9bad44484092c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -176,7 +176,7 @@ struct rvin_info {
> *
> * @crop:active cropping
> * @compose: active composing
> - * @source: active size of the video source
> + * @src_rect:active size of the video source
As this only holds a size you don't need a full rectangle, src_width and
src_height would save a bit of space. Up to you, in any case
Reviewed-by: Laurent Pinchart
> * @std: active video standard of the video source
> *
> * @alpha: Alpha component to fill in for supported pixel formats
> @@ -215,7 +215,7 @@ struct rvin_dev {
>
> struct v4l2_rect crop;
> struct v4l2_rect compose;
> - struct v4l2_rect source;
> + struct v4l2_rect src_rect;
> v4l2_std_id std;
>
> unsigned int alpha;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/6] rcar-vin: Make use of V4L2_FIELD_IS_INTERLACED() macro
Hi Niklas,
Thank you for the patch.
On Thu, Aug 08, 2019 at 03:18:46AM +0200, Niklas Söderlund wrote:
> The V4L2_FIELD_IS_INTERLACED() can be used to make the code more
> readable, use it.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index f16f2966f9628b72..6be1f33d44e2170c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -557,16 +557,11 @@ static void rvin_crop_scale_comp_gen2(struct rvin_dev
> *vin)
> rvin_write(vin, 0, VNSPPOC_REG);
> rvin_write(vin, 0, VNSLPOC_REG);
> rvin_write(vin, vin->format.width - 1, VNEPPOC_REG);
> - switch (vin->format.field) {
> - case V4L2_FIELD_INTERLACED:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> +
> + if (V4L2_FIELD_IS_INTERLACED(vin->format.field))
> rvin_write(vin, vin->format.height / 2 - 1, VNELPOC_REG);
> - break;
> - default:
> + else
> rvin_write(vin, vin->format.height - 1, VNELPOC_REG);
> - break;
> - }
>
> vin_dbg(vin,
> "Pre-Clip: %ux%u@%u:%u YS: %d XS: %d Post-Clip: %ux%u@%u:%u\n",
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/6] rcar-vin: Fix incorrect return statement in rvin_try_format()
Hi Niklas,
Thank you for the patch.
On Thu, Aug 08, 2019 at 03:18:45AM +0200, Niklas Söderlund wrote:
> While refactoring code the return statement became corrupted, fix it by
> returning the correct return code.
>
> Reported-by: Kieran Bingham
> Fixes: 897e371389e77514 ("media: rcar-vin: simplify how formats are set and
> reset"
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index cfed0a2604133849..402b40fcf7184fde 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -239,7 +239,7 @@ static int rvin_try_format(struct rvin_dev *vin, u32
> which,
> done:
> v4l2_subdev_free_pad_config(pad_cfg);
>
> - return 0;
> + return ret;
If the v4l2_subdev_call() call above returns -ENOIOCTLCMD, which you
don't consider as an error, you will end up returning that error value
here. You should set ret to 0 before the done: label. With this fixed,
Reviewed-by: Laurent Pinchart
> }
>
> static int rvin_querycap(struct file *file, void *priv,
--
Regards,
Laurent Pinchart
Re: [PATCH] rcar-vin: Report correct image stride
Hi Niklas,
Thank you for the patch.
On Thu, Aug 08, 2019 at 07:10:58AM +0200, Niklas Söderlund wrote:
> The image stride was adjusted when it was written to hardware and not
> when configuring the format. Calculate the correct stride value and
> report it to userspace.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 10 ++
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 -
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index f16f2966f9628b72..3cb29b2e0b2b18a9 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -577,6 +577,9 @@ static void rvin_crop_scale_comp_gen2(struct rvin_dev
> *vin)
>
> void rvin_crop_scale_comp(struct rvin_dev *vin)
> {
> + const struct rvin_video_format *fmt;
> + u32 stride;
> +
> /* Set Start/End Pixel/Line Pre-Clip */
> rvin_write(vin, vin->crop.left, VNSPPRC_REG);
> rvin_write(vin, vin->crop.left + vin->crop.width - 1, VNEPPRC_REG);
> @@ -600,10 +603,9 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
> if (vin->info->model != RCAR_GEN3)
> rvin_crop_scale_comp_gen2(vin);
>
> - if (vin->format.pixelformat == V4L2_PIX_FMT_NV16)
> - rvin_write(vin, ALIGN(vin->format.width, 0x20), VNIS_REG);
> - else
> - rvin_write(vin, ALIGN(vin->format.width, 0x10), VNIS_REG);
> + fmt = rvin_format_from_pixel(vin, vin->format.pixelformat);
You may want as an optimisation to cache the active rvin_video_format
pointer in rvin_dev, but that can be done in a separate patch.
Reviewed-by: Laurent Pinchart
> + stride = vin->format.bytesperline / fmt->bpp;
> + rvin_write(vin, stride, VNIS_REG);
> }
>
> /*
> -
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index cfed0a2604133849..cbc1c07f0a9631a4 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -83,13 +83,16 @@ static u32 rvin_format_bytesperline(struct rvin_dev *vin,
> struct v4l2_pix_format *pix)
> {
> const struct rvin_video_format *fmt;
> + u32 align;
>
> fmt = rvin_format_from_pixel(vin, pix->pixelformat);
>
> if (WARN_ON(!fmt))
> return -EINVAL;
>
> - return pix->width * fmt->bpp;
> + align = pix->pixelformat == V4L2_PIX_FMT_NV16 ? 0x20 : 0x10;
> +
> + return ALIGN(pix->width, align) * fmt->bpp;
> }
>
> static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
--
Regards,
Laurent Pinchart
Re: [PATCH] omap-dma/omap_vout_vrfb: fix off-by-one fi value
Hi Hans,
Thank you for the patch.
On Tue, Jul 30, 2019 at 08:14:19AM +0200, Hans Verkuil wrote:
> The OMAP 4 TRM specifies that when using double-index addressing
> the address increases by the ES plus the EI value minus 1 within
> a frame. When a full frame is transferred, the address increases
> by the ES plus the frame index (FI) value minus 1.
>
> The omap-dma code didn't account for the 'minus 1' in the FI register.
> To get correct addressing, add 1 to the src_icg value.
>
> This was found when testing a hacked version of the media m2m-deinterlace.c
> driver on a Pandaboard.
>
> The only other source that uses this feature is omap_vout_vrfb.c,
> and that adds a + 1 when setting the dst_icg. This is a workaround
> for the broken omap-dma.c behavior. So remove the workaround at the
> same time that we fix omap-dma.c.
>
> I tested the omap_vout driver with a Beagle XM board to check that
> the '+ 1' in omap_vout_vrfb.c was indeed a workaround for the omap-dma
> bug.
>
> Signed-off-by: Hans Verkuil
> ---
> It makes sense that this patch goes in through the dmaengine subsystem
> (Mauro, can you Ack this patch?), but if preferred it can also go in
> through the media subsystem if we get an Ack.
>
> Regards,
>
> Hans
> ---
> drivers/dma/ti/omap-dma.c| 4 ++--
> drivers/media/platform/omap/omap_vout_vrfb.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
> index ba2489d4ea24..ba27802efcd0 100644
> --- a/drivers/dma/ti/omap-dma.c
> +++ b/drivers/dma/ti/omap-dma.c
> @@ -1234,7 +1234,7 @@ static struct dma_async_tx_descriptor
> *omap_dma_prep_dma_interleaved(
> if (src_icg) {
> d->ccr |= CCR_SRC_AMODE_DBLIDX;
> d->ei = 1;
> - d->fi = src_icg;
> + d->fi = src_icg + 1;
> } else if (xt->src_inc) {
> d->ccr |= CCR_SRC_AMODE_POSTINC;
> d->fi = 0;
> @@ -1249,7 +1249,7 @@ static struct dma_async_tx_descriptor
> *omap_dma_prep_dma_interleaved(
> if (dst_icg) {
> d->ccr |= CCR_DST_AMODE_DBLIDX;
> sg->ei = 1;
> - sg->fi = dst_icg;
> + sg->fi = dst_icg + 1;
> } else if (xt->dst_inc) {
> d->ccr |= CCR_DST_AMODE_POSTINC;
> sg->fi = 0;
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index 29e3f5da59c1..729b1bf9395f 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -254,7 +254,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
>
> pixsize = vout->bpp * vout->vrfb_bpp;
> dst_icg = ((MAX_PIXELS_PER_LINE * pixsize) -
> - (vout->pix.width * vout->bpp)) + 1;
> + (vout->pix.width * vout->bpp));
You can remove the outer parentheses. Apart from that the patch looks OK
to me, it matches the documentation.
Reviewed-by: Laurent Pinchart
>
> xt->src_start = vout->buf_phy_addr[vb->i];
> xt->dst_start = vout->vrfb_context[vb->i].paddr[0];
--
Regards,
Laurent Pinchart
Re: [PATCH for 5.3] videodev2.h: change V4L2_PIX_FMT_BGRA444 define: fourcc was already in use
Hi Hans,
Thank you for the patch.
On Thu, Jul 11, 2019 at 10:53:25AM +0200, Hans Verkuil wrote:
> The V4L2_PIX_FMT_BGRA444 define clashed with the pre-existing
> V4L2_PIX_FMT_SGRBG12
> which strangely enough used the same fourcc, even though that fourcc made no
> sense
> for a Bayer format. In any case, you can't have duplicates, so change the
> fourcc of
> V4L2_PIX_FMT_BGRA444.
>
> Signed-off-by: Hans Verkuil
> Cc: # for v5.2 and up
Maybe a Fixes: line ?
Reviewed-by: Laurent Pinchart
> ---
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9d9705ceda76..2427bc4d8eba 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -518,7 +518,13 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16
> */
> -#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('B', 'A', '1', '2') /* 16
> */
> +
> +/*
> + * Originally this had 'BA12' as fourcc, but this clashed with the older
> + * V4L2_PIX_FMT_SGRBG12 which inexplicably used that same fourcc.
> + * So use 'GA12' instead for V4L2_PIX_FMT_BGRA444.
> + */
> +#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16 gggg
> */
> #define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_RGB555 v4l2_fourcc('R', 'G', 'B', 'O') /* 16
> RGB-5-5-5 */
> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
> ARGB-1-5-5-5 */
--
Regards,
Laurent Pinchart
Re: [PATCH v3 4/4] rcar-vin: Always setup controls when opening video device
Hi Niklas,
Thank you for the patch.
On Thu, Jul 04, 2019 at 03:58:17AM +0200, Niklas Söderlund wrote:
> Now that both Gen2 (device centric) and Gen3 (media device centric)
> modes of this driver have controls it make sens to call
s/sens/sense/
> v4l2_ctrl_handler_setup() unconditionally when opening the video device.
Not only does it make sense, but it's required by 3/4. I think you
should explain why in the commit message. Apart from that,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 30 ++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index f8b6ec4408b2f5fa..cbf5d8cd6db32d77 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -789,26 +789,26 @@ static int rvin_open(struct file *file)
> if (ret)
> goto err_unlock;
>
> - if (vin->info->use_mc) {
> + if (vin->info->use_mc)
> ret = v4l2_pipeline_pm_use(&vin->vdev.entity, 1);
> - if (ret < 0)
> - goto err_open;
> - } else {
> - if (v4l2_fh_is_singular_file(file)) {
> - ret = rvin_power_parallel(vin, true);
> - if (ret < 0)
> - goto err_open;
> + else if (v4l2_fh_is_singular_file(file))
> + ret = rvin_power_parallel(vin, true);
> +
> + if (ret < 0)
> + goto err_open;
> +
> + ret = v4l2_ctrl_handler_setup(&vin->ctrl_handler);
> + if (ret)
> + goto err_power;
>
> - ret = v4l2_ctrl_handler_setup(&vin->ctrl_handler);
> - if (ret)
> - goto err_parallel;
> - }
> - }
> mutex_unlock(&vin->lock);
>
> return 0;
> -err_parallel:
> - rvin_power_parallel(vin, false);
> +err_power:
> + if (vin->info->use_mc)
> + v4l2_pipeline_pm_use(&vin->vdev.entity, 0);
> + else if (v4l2_fh_is_singular_file(file))
> + rvin_power_parallel(vin, false);
> err_open:
> v4l2_fh_release(file);
> err_unlock:
--
Regards,
Laurent Pinchart
Re: [PATCH v3 3/4] rcar-vin: Add support for RGB formats with alpha component
Hi Niklas,
Thank you for the patch.
On Thu, Jul 04, 2019 at 03:58:16AM +0200, Niklas Söderlund wrote:
> The R-Car VIN module supports V4L2_PIX_FMT_ARGB555 and
> V4L2_PIX_FMT_ABGR32 pixel formats. Add the hardware register setup and
> allow the alpha component to be changed while streaming using the
> V4L2_CID_ALPHA_COMPONENT control.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 35 +
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 +
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 4e991cce5fb56a90..620976d173585694 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -111,8 +111,11 @@
> #define VNIE_EFE (1 << 1)
>
> /* Video n Data Mode Register bits */
> +#define VNDMR_A8BIT(n) ((n & 0xff) << 24)
> +#define VNDMR_A8BIT_MASK (0xff << 24)
> #define VNDMR_EXRGB (1 << 8)
> #define VNDMR_BPSM (1 << 4)
> +#define VNDMR_ABIT (1 << 2)
> #define VNDMR_DTMD_YCSEP (1 << 1)
> #define VNDMR_DTMD_ARGB (1 << 0)
>
> @@ -730,6 +733,12 @@ static int rvin_setup(struct rvin_dev *vin)
> /* Note: not supported on M1 */
> dmr = VNDMR_EXRGB;
> break;
> + case V4L2_PIX_FMT_ARGB555:
> + dmr = (vin->alpha ? VNDMR_ABIT : 0) | VNDMR_DTMD_ARGB;
> + break;
> + case V4L2_PIX_FMT_ABGR32:
> + dmr = VNDMR_A8BIT(vin->alpha) | VNDMR_EXRGB | VNDMR_DTMD_ARGB;
> + break;
> default:
> vin_err(vin, "Invalid pixelformat (0x%x)\n",
> vin->format.pixelformat);
> @@ -1346,5 +1355,31 @@ int rvin_set_channel_routing(struct rvin_dev *vin, u8
> chsel)
>
> void rvin_set_alpha(struct rvin_dev *vin, unsigned int alpha)
> {
> + unsigned long flags;
> + u32 dmr;
> +
> + spin_lock_irqsave(&vin->qlock, flags);
> +
> vin->alpha = alpha;
> +
> + if (vin->state == STOPPED)
> + goto out;
> +
> + switch (vin->format.pixelformat) {
> + case V4L2_PIX_FMT_ARGB555:
> + dmr = rvin_read(vin, VNDMR_REG) & ~VNDMR_ABIT;
> + if (vin->alpha)
> + dmr |= VNDMR_ABIT;
> + break;
> + case V4L2_PIX_FMT_ABGR32:
> + dmr = rvin_read(vin, VNDMR_REG) & ~VNDMR_A8BIT_MASK;
> + dmr |= VNDMR_A8BIT(vin->alpha);
> + break;
> + default:
> + goto out;
> + }
> +
> + rvin_write(vin, dmr, VNDMR_REG);
> +out:
> + spin_unlock_irqrestore(&vin->qlock, flags);
> }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 0936bcd98df1f75d..f8b6ec4408b2f5fa 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -54,6 +54,14 @@ static const struct rvin_video_format rvin_formats[] = {
> .fourcc = V4L2_PIX_FMT_XBGR32,
> .bpp= 4,
> },
> + {
> + .fourcc = V4L2_PIX_FMT_ARGB555,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_ABGR32,
> + .bpp= 4,
> + },
> };
>
> const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat)
> --
> 2.21.0
>
--
Regards,
Laurent Pinchart
Re: [PATCH 5/5] media/platform: don't set description in ENUM_FMT
Hi Hans,
Thank you for the patch.
On Wed, Jun 26, 2019 at 01:27:48PM +0200, Hans Verkuil wrote:
> The V4L2 core sets the format description and flags for the driver in order
> to ensure consistent naming.
>
> So drop the strscpy of the description in drivers. Also remove any
> description strings in driver-internal structures since those are
> no longer needed.
>
> Signed-off-by: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Prabhakar Lad
> Cc: Sylwester Nawrocki
> Cc: Jonathan Corbet
> Cc: Jacopo Mondi
> Cc: Benoit Parrot
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 18 ++---
> drivers/media/platform/davinci/vpbe_display.c | 14 ++
> drivers/media/platform/davinci/vpif_capture.c | 11 ++--
> drivers/media/platform/davinci/vpif_display.c | 4 ---
> drivers/media/platform/exynos-gsc/gsc-core.c | 22 ---
> drivers/media/platform/exynos-gsc/gsc-core.h | 2 --
> .../media/platform/exynos4-is/fimc-capture.c | 3 ---
> drivers/media/platform/exynos4-is/fimc-core.c | 20 --
> .../platform/exynos4-is/fimc-isp-video.c | 1 -
> drivers/media/platform/exynos4-is/fimc-isp.c | 3 ---
> drivers/media/platform/exynos4-is/fimc-lite.c | 8 --
> drivers/media/platform/exynos4-is/fimc-m2m.c | 1 -
> drivers/media/platform/m2m-deinterlace.c | 4 ---
> .../media/platform/marvell-ccic/mcam-core.c | 10 ---
> drivers/media/platform/mx2_emmaprp.c | 4 ---
> drivers/media/platform/omap/omap_vout.c | 7 -
> .../media/platform/s3c-camif/camif-capture.c | 11 +++-
> drivers/media/platform/s3c-camif/camif-core.c | 6 -
> drivers/media/platform/s3c-camif/camif-core.h | 1 -
> drivers/media/platform/s5p-g2d/g2d.c | 6 -
> drivers/media/platform/s5p-g2d/g2d.h | 1 -
> drivers/media/platform/s5p-jpeg/jpeg-core.c | 27 ---
> drivers/media/platform/s5p-jpeg/jpeg-core.h | 2 --
> .../media/platform/s5p-mfc/s5p_mfc_common.h | 1 -
> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 15 ---
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 10 ---
> drivers/media/platform/sh_veu.c | 19 ++---
> drivers/media/platform/sh_vou.c | 12 ++---
> drivers/media/platform/ti-vpe/vpe.c | 12 -
> drivers/media/platform/via-camera.c | 4 ---
> drivers/media/platform/xilinx/xilinx-dma.c| 2 --
> drivers/media/platform/xilinx/xilinx-vip.c| 16 +--
> drivers/media/platform/xilinx/xilinx-vip.h| 2 --
> include/media/drv-intf/exynos-fimc.h | 2 --
> 34 files changed, 28 insertions(+), 253 deletions(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index fe7b937eb5f2..7582c26f8459 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -76,7 +76,6 @@ struct bus_format {
>
> /*
> * struct vpfe_fmt - VPFE media bus format information
> - * @name: V4L2 format description
> * @code: V4L2 media bus format code
> * @shifted: V4L2 media bus format code for the same pixel layout but
> * shifted to be 8 bits per pixel. =0 if format is not shiftable.
> @@ -86,7 +85,6 @@ struct bus_format {
> * @supported: Indicates format supported by subdev
> */
> struct vpfe_fmt {
> - const char *name;
> u32 fourcc;
> u32 code;
> struct bus_format l;
> @@ -97,7 +95,6 @@ struct vpfe_fmt {
>
> static struct vpfe_fmt formats[] = {
> {
> - .name = "YUV 4:2:2 packed, YCbYCr",
> .fourcc = V4L2_PIX_FMT_YUYV,
> .code = MEDIA_BUS_FMT_YUYV8_2X8,
> .l.width= 10,
> @@ -106,7 +103,6 @@ static struct vpfe_fmt formats[] = {
> .s.bpp = 2,
> .supported = false,
> }, {
> - .name = "YUV 4:2:2 packed, CbYCrY",
> .fourcc = V4L2_PIX_FMT_UYVY,
> .code = MEDIA_BUS_FMT_UYVY8_2X8,
> .l.width= 10,
> @@ -115,7 +111,6 @@ static struct vpfe_fmt formats[] = {
> .s.bpp = 2,
> .supported = false,
> }, {
> - .name = "YUV 4:2:2 packed, YCrYCb",
> .fourcc = V4L2_PIX_FMT_YVYU,
> .code = MEDIA_BUS_FMT_YVYU8_2X8,
> .l.width= 10,
> @@ -124,7 +119,6 @@ static struct vpfe_fmt formats[] = {
> .s.bpp = 2,
> .supported = false,
> }, {
>
Re: [PATCH 4/5] drivers/staging/media: don't set description for ENUM_FMT
Hi Hans,
Thank you for the patch.
On Wed, Jun 26, 2019 at 01:27:47PM +0200, Hans Verkuil wrote:
> The V4L2 core sets the format description and flags for the driver in order
> to ensure consistent naming.
>
> So drop the strscpy of the description in drivers. Also remove any
> description strings in driver-internal structures since those are
> no longer needed.
>
> Note that bcm2835-camera.c: the formats array still stores the flags
> field for compressed formats since that information is used elsewhere
> in the driver. But enum_fmt doesn't use it anymore, since the core
> will set the COMPRESSED flag correctly.
>
> Signed-off-by: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Dave Stevenson
> Cc: Eric Anholt
Reviewed-by: Laurent Pinchart
> ---
> drivers/staging/media/omap4iss/iss_video.c| 40 +--
> drivers/staging/media/omap4iss/iss_video.h| 2 -
> drivers/staging/media/soc_camera/soc_camera.c | 2 -
> .../bcm2835-camera/bcm2835-camera.c | 29 --
> .../bcm2835-camera/mmal-common.h | 1 -
> include/media/drv-intf/soc_mediabus.h | 2 -
> 6 files changed, 19 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c
> index c307707480f7..54144dc9f509 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -31,61 +31,61 @@
> static struct iss_format_info formats[] = {
> { MEDIA_BUS_FMT_Y8_1X8, MEDIA_BUS_FMT_Y8_1X8,
> MEDIA_BUS_FMT_Y8_1X8, MEDIA_BUS_FMT_Y8_1X8,
> - V4L2_PIX_FMT_GREY, 8, "Greyscale 8 bpp", },
> + V4L2_PIX_FMT_GREY, 8, },
> { MEDIA_BUS_FMT_Y10_1X10, MEDIA_BUS_FMT_Y10_1X10,
> MEDIA_BUS_FMT_Y10_1X10, MEDIA_BUS_FMT_Y8_1X8,
> - V4L2_PIX_FMT_Y10, 10, "Greyscale 10 bpp", },
> + V4L2_PIX_FMT_Y10, 10, },
> { MEDIA_BUS_FMT_Y12_1X12, MEDIA_BUS_FMT_Y10_1X10,
> MEDIA_BUS_FMT_Y12_1X12, MEDIA_BUS_FMT_Y8_1X8,
> - V4L2_PIX_FMT_Y12, 12, "Greyscale 12 bpp", },
> + V4L2_PIX_FMT_Y12, 12, },
> { MEDIA_BUS_FMT_SBGGR8_1X8, MEDIA_BUS_FMT_SBGGR8_1X8,
> MEDIA_BUS_FMT_SBGGR8_1X8, MEDIA_BUS_FMT_SBGGR8_1X8,
> - V4L2_PIX_FMT_SBGGR8, 8, "BGGR Bayer 8 bpp", },
> + V4L2_PIX_FMT_SBGGR8, 8, },
> { MEDIA_BUS_FMT_SGBRG8_1X8, MEDIA_BUS_FMT_SGBRG8_1X8,
> MEDIA_BUS_FMT_SGBRG8_1X8, MEDIA_BUS_FMT_SGBRG8_1X8,
> - V4L2_PIX_FMT_SGBRG8, 8, "GBRG Bayer 8 bpp", },
> + V4L2_PIX_FMT_SGBRG8, 8, },
> { MEDIA_BUS_FMT_SGRBG8_1X8, MEDIA_BUS_FMT_SGRBG8_1X8,
> MEDIA_BUS_FMT_SGRBG8_1X8, MEDIA_BUS_FMT_SGRBG8_1X8,
> - V4L2_PIX_FMT_SGRBG8, 8, "GRBG Bayer 8 bpp", },
> + V4L2_PIX_FMT_SGRBG8, 8, },
> { MEDIA_BUS_FMT_SRGGB8_1X8, MEDIA_BUS_FMT_SRGGB8_1X8,
> MEDIA_BUS_FMT_SRGGB8_1X8, MEDIA_BUS_FMT_SRGGB8_1X8,
> - V4L2_PIX_FMT_SRGGB8, 8, "RGGB Bayer 8 bpp", },
> + V4L2_PIX_FMT_SRGGB8, 8, },
> { MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8, MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
> MEDIA_BUS_FMT_SGRBG10_1X10, 0,
> - V4L2_PIX_FMT_SGRBG10DPCM8, 8, "GRBG Bayer 10 bpp DPCM8", },
> + V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
> { MEDIA_BUS_FMT_SBGGR10_1X10, MEDIA_BUS_FMT_SBGGR10_1X10,
> MEDIA_BUS_FMT_SBGGR10_1X10, MEDIA_BUS_FMT_SBGGR8_1X8,
> - V4L2_PIX_FMT_SBGGR10, 10, "BGGR Bayer 10 bpp", },
> + V4L2_PIX_FMT_SBGGR10, 10, },
> { MEDIA_BUS_FMT_SGBRG10_1X10, MEDIA_BUS_FMT_SGBRG10_1X10,
> MEDIA_BUS_FMT_SGBRG10_1X10, MEDIA_BUS_FMT_SGBRG8_1X8,
> - V4L2_PIX_FMT_SGBRG10, 10, "GBRG Bayer 10 bpp", },
> + V4L2_PIX_FMT_SGBRG10, 10, },
> { MEDIA_BUS_FMT_SGRBG10_1X10, MEDIA_BUS_FMT_SGRBG10_1X10,
> MEDIA_BUS_FMT_SGRBG10_1X10, MEDIA_BUS_FMT_SGRBG8_1X8,
> - V4L2_PIX_FMT_SGRBG10, 10, "GRBG Bayer 10 bpp", },
> + V4L2_PIX_FMT_SGRBG10, 10, },
> { MEDIA_BUS_FMT_SRGGB10_1X10, MEDIA_BUS_FMT_SRGGB10_1X10,
> MEDIA_BUS_FMT_SRGGB10_1X10, MEDIA_BUS_FMT_SRGGB8_1X8,
> - V4L2_PIX_FMT_SRGGB10, 10, "RGGB Bayer 10 bpp", },
> + V4L2_PIX_FMT_SRGGB10, 10, },
> { MEDIA_BUS_FMT_SBGGR12_1X12, MEDIA_BUS_FMT_SBGGR10_1X10,
> MEDIA_BUS_FMT_SBGGR12_1X12, MEDIA_BUS_FMT_SBGGR8_1X8,
> - V4L2_PIX_FMT_SBGGR12, 12, "BGGR Bayer 12 bpp", },
> + V4L2_PIX_FMT_SBGGR12, 12, },
> { MEDIA_BUS_FMT_SGBRG12_1X12, MEDIA_BUS_FMT_SGBRG10_1X10,
> MEDIA_BUS_FMT_SGBRG12_1X12, MEDIA_BUS_FMT_SGBRG8_1X8,
> - V4L2_PIX_FMT_SGBRG12, 12, "GBRG Bayer 12 bpp", },
> + V4L2_PIX_FMT_SGBRG12, 12, },
Re: [PATCH 1/5] v4l2-ioctl: add missing pixelformats
Hi Hans, Thank you for the patch. On Wed, Jun 26, 2019 at 01:27:44PM +0200, Hans Verkuil wrote: > The v4l_fill_fmtdesc() is supposed to be updated whenever a new pixelformat > is added, but a bunch of recently added pixelformats were forgotten. Sorry about forgetting tp update the code :-( > Update the list. > > Also change a few lower case words to upper case to keep the same style. > > Signed-off-by: Hans Verkuil > Cc: Laurent Pinchart > --- > drivers/media/v4l2-core/v4l2-ioctl.c | 29 ++-- > 1 file changed, 23 insertions(+), 6 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c > b/drivers/media/v4l2-core/v4l2-ioctl.c > index b1f4b991dba6..c1faa7ca1925 100644 > --- a/drivers/media/v4l2-core/v4l2-ioctl.c > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c > @@ -1169,9 +1169,21 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) > case V4L2_PIX_FMT_RGB444: descr = "16-bit A/XRGB 4-4-4-4"; break; > case V4L2_PIX_FMT_ARGB444: descr = "16-bit ARGB 4-4-4-4"; break; > case V4L2_PIX_FMT_XRGB444: descr = "16-bit XRGB 4-4-4-4"; break; > + case V4L2_PIX_FMT_RGBA444: descr = "16-bit RGBA 4-4-4-4"; break; > + case V4L2_PIX_FMT_RGBX444: descr = "16-bit RGBX 4-4-4-4"; break; > + case V4L2_PIX_FMT_ABGR444: descr = "16-bit ABGR 4-4-4-4"; break; > + case V4L2_PIX_FMT_XBGR444: descr = "16-bit XBGR 4-4-4-4"; break; > + case V4L2_PIX_FMT_BGRA444: descr = "16-bit BGRA 4-4-4-4"; break; > + case V4L2_PIX_FMT_BGRX444: descr = "16-bit BGRX 4-4-4-4"; break; > case V4L2_PIX_FMT_RGB555: descr = "16-bit A/XRGB 1-5-5-5"; break; > case V4L2_PIX_FMT_ARGB555: descr = "16-bit ARGB 1-5-5-5"; break; > case V4L2_PIX_FMT_XRGB555: descr = "16-bit XRGB 1-5-5-5"; break; > + case V4L2_PIX_FMT_ABGR555: descr = "16-bit ABGR 1-5-5-5"; break; > + case V4L2_PIX_FMT_XBGR555: descr = "16-bit XBGR 1-5-5-5"; break; > + case V4L2_PIX_FMT_RGBA555: descr = "16-bit RGBA 1-5-5-5"; break; > + case V4L2_PIX_FMT_RGBX555: descr = "16-bit RGBX 1-5-5-5"; break; > + case V4L2_PIX_FMT_BGRA555: descr = "16-bit BGRA 1-5-5-5"; break; > + case V4L2_PIX_FMT_BGRX555: descr = "16-bit BGRX 1-5-5-5"; break; Should the last four formats be described as 5-5-5-1 to match the order of the components ? With or without this changed, Reviewed-by: Laurent Pinchart > case V4L2_PIX_FMT_RGB565: descr = "16-bit RGB 5-6-5"; break; > case V4L2_PIX_FMT_RGB555X: descr = "16-bit A/XRGB 1-5-5-5 BE"; > break; > case V4L2_PIX_FMT_ARGB555X: descr = "16-bit ARGB 1-5-5-5 BE"; break; > @@ -1186,6 +1198,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) > case V4L2_PIX_FMT_RGB32:descr = "32-bit A/XRGB 8-8-8-8"; break; > case V4L2_PIX_FMT_ARGB32: descr = "32-bit ARGB 8-8-8-8"; break; > case V4L2_PIX_FMT_XRGB32: descr = "32-bit XRGB 8-8-8-8"; break; > + case V4L2_PIX_FMT_BGRA32: descr = "32-bit ABGR 8-8-8-8"; break; > + case V4L2_PIX_FMT_BGRX32: descr = "32-bit XBGR 8-8-8-8"; break; > + case V4L2_PIX_FMT_RGBA32: descr = "32-bit RGBA 8-8-8-8"; break; > + case V4L2_PIX_FMT_RGBX32: descr = "32-bit RGBX 8-8-8-8"; break; > case V4L2_PIX_FMT_GREY: descr = "8-bit Greyscale"; break; > case V4L2_PIX_FMT_Y4: descr = "4-bit Greyscale"; break; > case V4L2_PIX_FMT_Y6: descr = "6-bit Greyscale"; break; > @@ -1301,13 +1317,14 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) > case V4L2_SDR_FMT_PCU16BE: descr = "Planar Complex U16BE"; break; > case V4L2_SDR_FMT_PCU18BE: descr = "Planar Complex U18BE"; break; > case V4L2_SDR_FMT_PCU20BE: descr = "Planar Complex U20BE"; break; > - case V4L2_TCH_FMT_DELTA_TD16: descr = "16-bit signed deltas"; break; > - case V4L2_TCH_FMT_DELTA_TD08: descr = "8-bit signed deltas"; break; > - case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; > break; > - case V4L2_TCH_FMT_TU08: descr = "8-bit unsigned touch data"; > break; > + case V4L2_TCH_FMT_DELTA_TD16: descr = "16-bit Signed Deltas"; break; > + case V4L2_TCH_FMT_DELTA_TD08: descr = "8-bit Signed Deltas"; break; > + case V4L2_TCH_FMT_TU16:
Re: [PATCH] drivers/media: don't set pix->priv = 0
Hi Hans, Thank you for the patch. On Wed, Jun 26, 2019 at 11:58:02AM +0200, Hans Verkuil wrote: > The priv field of struct v4l2_pix_format shouldn't be set by drivers, > it's set by the v4l2 core instead to V4L2_PIX_FMT_PRIV_MAGIC. > > Drop this from the few media drivers that still do this. > > Note that the gspca patch is slightly more involved since some of the > sub-gspca drivers use the priv field internally. Do they use it in a non-standard way towards userspace, or just for communication with the gspca driver within the kernel ? In the former case, are you aware of applications using that ? > Signed-off-by: Hans Verkuil For everything but gspca, Reviewed-by: Laurent Pinchart > --- > diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c > b/drivers/media/pci/cobalt/cobalt-v4l2.c > index 39dabd4da60f..c8cd4c407540 100644 > --- a/drivers/media/pci/cobalt/cobalt-v4l2.c > +++ b/drivers/media/pci/cobalt/cobalt-v4l2.c > @@ -788,7 +788,6 @@ static int cobalt_try_fmt_vid_cap(struct file *file, void > *priv_fh, > > pix->sizeimage = pix->bytesperline * pix->height; > pix->field = V4L2_FIELD_NONE; > - pix->priv = 0; > > return 0; > } > diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > index 609100a46ff8..88e0cb0bf592 100644 > --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > @@ -886,7 +886,6 @@ static int solo_enc_try_fmt_cap(struct file *file, void > *priv, > pix->colorspace = V4L2_COLORSPACE_SMPTE170M; > pix->sizeimage = FRAME_BUF_SIZE; > pix->bytesperline = 0; > - pix->priv = 0; > > return 0; > } > @@ -941,7 +940,6 @@ static int solo_enc_get_fmt_cap(struct file *file, void > *priv, >V4L2_FIELD_NONE; > pix->sizeimage = FRAME_BUF_SIZE; > pix->colorspace = V4L2_COLORSPACE_SMPTE170M; > - pix->priv = 0; > > return 0; > } > diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c > b/drivers/media/pci/solo6x10/solo6x10-v4l2.c > index a968f75920b5..a670fe8e4f9c 100644 > --- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c > +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c > @@ -479,7 +479,6 @@ static int solo_try_fmt_cap(struct file *file, void *priv, > pix->field = V4L2_FIELD_INTERLACED; > pix->pixelformat = V4L2_PIX_FMT_UYVY; > pix->colorspace = V4L2_COLORSPACE_SMPTE170M; > - pix->priv = 0; > return 0; > } > > @@ -509,7 +508,6 @@ static int solo_get_fmt_cap(struct file *file, void *priv, > pix->sizeimage = solo_image_size(solo_dev); > pix->colorspace = V4L2_COLORSPACE_SMPTE170M; > pix->bytesperline = solo_bytesperline(solo_dev); > - pix->priv = 0; > > return 0; > } > diff --git a/drivers/media/pci/tw68/tw68-video.c > b/drivers/media/pci/tw68/tw68-video.c > index 8e0952d65ad4..d0c2ec70f9cd 100644 > --- a/drivers/media/pci/tw68/tw68-video.c > +++ b/drivers/media/pci/tw68/tw68-video.c > @@ -592,7 +592,6 @@ static int tw68_g_fmt_vid_cap(struct file *file, void > *priv, > f->fmt.pix.sizeimage = > f->fmt.pix.height * f->fmt.pix.bytesperline; > f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; > - f->fmt.pix.priv = 0; > return 0; > } > > diff --git a/drivers/media/platform/davinci/vpif_capture.c > b/drivers/media/platform/davinci/vpif_capture.c > index f0f7ef638c56..21a2ba797d0a 100644 > --- a/drivers/media/platform/davinci/vpif_capture.c > +++ b/drivers/media/platform/davinci/vpif_capture.c > @@ -979,7 +979,6 @@ static int vpif_try_fmt_vid_cap(struct file *file, void > *priv, > pixfmt->bytesperline = common->fmt.fmt.pix.width * 2; > pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height; > } > - pixfmt->priv = 0; > > dev_dbg(vpif_dev, "%s: %d x %d; pitch=%d pixelformat=0x%08x, field=%d, > size=%d\n", __func__, > pixfmt->width, pixfmt->height, > diff --git a/drivers/media/usb/au0828/au0828-video.c > b/drivers/media/usb/au0828/au0828-video.c > index 5e00019bce8a..37acfcb56822 100644 > --- a/drivers/media/usb/au0828/au0828-video.c > +++ b/drivers/media/usb/au0828/au0828-video.c > @@ -1153,7 +1153,6 @@ static int au0828_set_format(struct au0828_dev *dev, > unsigned int cmd, > format->fmt.pix.sizeimage = width * height * 2; > format->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; > format->fmt.pix.field = V4L2_FIELD_INTERLACED; > - format->fmt.pix.priv = 0; &g
Re: [PATCH 11/16] xilinx: set device_caps in struct video_device
Hi Hans, Thank you for the patch. On Wed, Jun 26, 2019 at 09:44:16AM +0200, Hans Verkuil wrote: > Instead of filling in the struct v4l2_capability device_caps > field, fill in the struct video_device device_caps field. > > That way the V4L2 core knows what the capabilities of the > video device are. > > Signed-off-by: Hans Verkuil > Cc: Laurent Pinchart Reviewed-by: Laurent Pinchart Please feel free to merge this patch along with the rest of the series. > --- > drivers/media/platform/xilinx/xilinx-dma.c | 16 +++- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/media/platform/xilinx/xilinx-dma.c > b/drivers/media/platform/xilinx/xilinx-dma.c > index c9d5fdb2d407..bcd783d9e5ae 100644 > --- a/drivers/media/platform/xilinx/xilinx-dma.c > +++ b/drivers/media/platform/xilinx/xilinx-dma.c > @@ -491,15 +491,8 @@ xvip_dma_querycap(struct file *file, void *fh, struct > v4l2_capability *cap) > struct v4l2_fh *vfh = file->private_data; > struct xvip_dma *dma = to_xvip_dma(vfh->vdev); > > - cap->device_caps = V4L2_CAP_STREAMING; > - > - if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE) > - cap->device_caps |= V4L2_CAP_VIDEO_CAPTURE; > - else > - cap->device_caps |= V4L2_CAP_VIDEO_OUTPUT; > - > - cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS > - | dma->xdev->v4l2_caps; > + cap->capabilities = dma->xdev->v4l2_caps | V4L2_CAP_STREAMING | > + V4L2_CAP_DEVICE_CAPS; > > strscpy(cap->driver, "xilinx-vipp", sizeof(cap->driver)); > strscpy(cap->card, dma->video.name, sizeof(cap->card)); > @@ -700,6 +693,11 @@ int xvip_dma_init(struct xvip_composite_device *xdev, > struct xvip_dma *dma, > dma->video.release = video_device_release_empty; > dma->video.ioctl_ops = &xvip_dma_ioctl_ops; > dma->video.lock = &dma->lock; > + dma->video.device_caps = V4L2_CAP_STREAMING; > + if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE) > + dma->video.device_caps |= V4L2_CAP_VIDEO_CAPTURE; > + else > + dma->video.device_caps |= V4L2_CAP_VIDEO_OUTPUT; > > video_set_drvdata(&dma->video, dma); -- Regards, Laurent Pinchart
Re: [PATCH 16/16] omap3isp: set device_caps in struct video_device
Hi Hans,
Thank you for the patch.
On Wed, Jun 26, 2019 at 09:44:21AM +0200, Hans Verkuil wrote:
> Instead of filling in the struct v4l2_capability device_caps
> field, fill in the struct video_device device_caps field.
>
> That way the V4L2 core knows what the capabilities of the
> video device are.
>
> Signed-off-by: Hans Verkuil
> Cc: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/ispvideo.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c
> index 175bbed9a235..d98b8c3ec0b2 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -660,12 +660,6 @@ isp_video_querycap(struct file *file, void *fh, struct
> v4l2_capability *cap)
>
> cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT
> | V4L2_CAP_STREAMING | V4L2_CAP_DEVICE_CAPS;
> -
> - if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> - cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
> - else
> - cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
> -
Could you please keep this blank line ?
> return 0;
> }
>
> @@ -1463,6 +1457,13 @@ int omap3isp_video_init(struct isp_video *video, const
> char *name)
> video->video.vfl_type = VFL_TYPE_GRABBER;
> video->video.release = video_device_release_empty;
> video->video.ioctl_ops = &isp_video_ioctl_ops;
> + if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + video->video.device_caps =
> + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
> + else
> + video->video.device_caps =
> + V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
Based on the coding style of the driver, this should be
if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
video->video.device_caps = V4L2_CAP_VIDEO_CAPTURE
| V4L2_CAP_STREAMING;
else
video->video.device_caps = V4L2_CAP_VIDEO_OUTPUT
| V4L2_CAP_STREAMING;
With those minor issues fixed,
Reviewed-by: Laurent Pinchart
Please feel free to merge this patch as part of the whole series.
> video->pipe.stream_state = ISP_PIPELINE_STREAM_STOPPED;
>
> video_set_drvdata(&video->video, video);
--
Regards,
Laurent Pinchart
Re: [PATCH 13/16] vsp1: set device_caps in struct video_device
Hi Hans,
Thank you for the patch.
On Wed, Jun 26, 2019 at 09:44:18AM +0200, Hans Verkuil wrote:
> Instead of filling in the struct v4l2_capability device_caps
> field, fill in the struct video_device device_caps field.
>
> That way the V4L2 core knows what the capabilities of the
> video device are.
>
> Signed-off-by: Hans Verkuil
> Cc: Laurent Pinchart
> ---
> drivers/media/platform/vsp1/vsp1_histo.c | 3 +--
> drivers/media/platform/vsp1/vsp1_video.c | 12
> 2 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_histo.c
> b/drivers/media/platform/vsp1/vsp1_histo.c
> index 8b01e99acd20..30d751f2cccf 100644
> --- a/drivers/media/platform/vsp1/vsp1_histo.c
> +++ b/drivers/media/platform/vsp1/vsp1_histo.c
> @@ -426,8 +426,6 @@ static int histo_v4l2_querycap(struct file *file, void
> *fh,
> | V4L2_CAP_VIDEO_CAPTURE_MPLANE
> | V4L2_CAP_VIDEO_OUTPUT_MPLANE
> | V4L2_CAP_META_CAPTURE;
> - cap->device_caps = V4L2_CAP_META_CAPTURE
> - | V4L2_CAP_STREAMING;
>
> strscpy(cap->driver, "vsp1", sizeof(cap->driver));
> strscpy(cap->card, histo->video.name, sizeof(cap->card));
> @@ -556,6 +554,7 @@ int vsp1_histogram_init(struct vsp1_device *vsp1, struct
> vsp1_histogram *histo,
> histo->video.vfl_type = VFL_TYPE_GRABBER;
> histo->video.release = video_device_release_empty;
> histo->video.ioctl_ops = &histo_v4l2_ioctl_ops;
> + histo->video.device_caps = V4L2_CAP_META_CAPTURE | V4L2_CAP_STREAMING;
>
> video_set_drvdata(&histo->video, histo);
>
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c
> index fd98e483b2f4..fee2ec45b1d6 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -955,14 +955,6 @@ vsp1_video_querycap(struct file *file, void *fh, struct
> v4l2_capability *cap)
> cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
> | V4L2_CAP_VIDEO_CAPTURE_MPLANE
> | V4L2_CAP_VIDEO_OUTPUT_MPLANE;
> -
> - if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
> - cap->device_caps = V4L2_CAP_VIDEO_CAPTURE_MPLANE
> - | V4L2_CAP_STREAMING;
> - else
> - cap->device_caps = V4L2_CAP_VIDEO_OUTPUT_MPLANE
> - | V4L2_CAP_STREAMING;
> -
Could you please keep this blank line ? Apart from that,
Reviewed-by: Laurent Pinchart
Feel free to merge the patch as part of the series, I don't have any
queued conflicting change.
> strscpy(cap->driver, "vsp1", sizeof(cap->driver));
> strscpy(cap->card, video->video.name, sizeof(cap->card));
> snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> @@ -1268,11 +1260,15 @@ struct vsp1_video *vsp1_video_create(struct
> vsp1_device *vsp1,
> video->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> video->pad.flags = MEDIA_PAD_FL_SOURCE;
> video->video.vfl_dir = VFL_DIR_TX;
> + video->video.device_caps = V4L2_CAP_VIDEO_OUTPUT_MPLANE |
> +V4L2_CAP_STREAMING;
> } else {
> direction = "output";
> video->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> video->pad.flags = MEDIA_PAD_FL_SINK;
> video->video.vfl_dir = VFL_DIR_RX;
> + video->video.device_caps = V4L2_CAP_VIDEO_CAPTURE_MPLANE |
> +V4L2_CAP_STREAMING;
> }
>
> mutex_init(&video->lock);
--
Regards,
Laurent Pinchart
Re: [PATCH] media: imx: mipi csi-2: Don't fail if initial state times-out
Hi Ezequiel,
Thank you for the patch.
On Tue, Jun 25, 2019 at 05:39:45PM -0300, Ezequiel Garcia wrote:
> Not all sensors will be able to guarantee a proper initial state.
> This may be either because the driver is not properly written,
> or (probably unlikely) because the hardware won't support it.
>
> While the right solution in the former case is to fix the sensor
> driver, the real world not always allows right solutions, due to lack
> of available documentation and support on these sensors.
>
> Let's relax this requirement, and allow the driver to support stream start,
> even if the sensor initial sequence wasn't the expected.
> A warning is still emitted, so users should be hinted that something is off.
I'm not sure this is a very good idea. Failure to detect the LP-11 state
may mean that the sensor is completely powered off, but it may also mean
that it is already streaming data. I don't know how the CSI-2 receiver
state machine will operate in the first case, but in the second case it
will not be able to synchronise to the incoming stream, so it won't work
anyway.
I think you should instead fix the problem in the sensor driver, as you
hinted. Relaxing the requirement here will only make it more confusing,
it's a hack, and isn't portable across CSI-2 receivers. The same buggy
sensor driver won't work with other CSI-2 receivers whose internal state
machine require starting in the LP-11 state.
Which sensor are you using ?
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/staging/media/imx/imx6-mipi-csi2.c | 33 ++
> 1 file changed, 9 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c
> b/drivers/staging/media/imx/imx6-mipi-csi2.c
> index f29e28df36ed..10342434e797 100644
> --- a/drivers/staging/media/imx/imx6-mipi-csi2.c
> +++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
> @@ -243,7 +243,7 @@ static int __maybe_unused csi2_dphy_wait_ulp(struct
> csi2_dev *csi2)
> }
>
> /* Waits for low-power LP-11 state on data and clock lanes. */
> -static int csi2_dphy_wait_stopstate(struct csi2_dev *csi2)
> +static void csi2_dphy_wait_stopstate(struct csi2_dev *csi2)
> {
> u32 mask, reg;
> int ret;
> @@ -253,29 +253,21 @@ static int csi2_dphy_wait_stopstate(struct csi2_dev
> *csi2)
>
> ret = readl_poll_timeout(csi2->base + CSI2_PHY_STATE, reg,
>(reg & mask) == mask, 0, 50);
> - if (ret) {
> - v4l2_err(&csi2->sd, "LP-11 timeout, phy_state = 0x%08x\n", reg);
> - return ret;
> - }
> -
> - return 0;
> + if (ret)
> + v4l2_warn(&csi2->sd, "LP-11 timeout, phy_state = 0x%08x\n",
> reg);
> }
>
> /* Wait for active clock on the clock lane. */
> -static int csi2_dphy_wait_clock_lane(struct csi2_dev *csi2)
> +static void csi2_dphy_wait_clock_lane(struct csi2_dev *csi2)
> {
> u32 reg;
> int ret;
>
> ret = readl_poll_timeout(csi2->base + CSI2_PHY_STATE, reg,
>(reg & PHY_RXCLKACTIVEHS), 0, 50);
> - if (ret) {
> - v4l2_err(&csi2->sd, "clock lane timeout, phy_state = 0x%08x\n",
> - reg);
> - return ret;
> - }
> -
> - return 0;
> + if (ret)
> + v4l2_warn(&csi2->sd, "clock lane timeout, phy_state = 0x%08x\n",
> + reg);
> }
>
> /* Setup the i.MX CSI2IPU Gasket */
> @@ -316,9 +308,7 @@ static int csi2_start(struct csi2_dev *csi2)
> csi2_enable(csi2, true);
>
> /* Step 5 */
> - ret = csi2_dphy_wait_stopstate(csi2);
> - if (ret)
> - goto err_assert_reset;
> + csi2_dphy_wait_stopstate(csi2);
>
> /* Step 6 */
> ret = v4l2_subdev_call(csi2->src_sd, video, s_stream, 1);
> @@ -327,14 +317,9 @@ static int csi2_start(struct csi2_dev *csi2)
> goto err_assert_reset;
>
> /* Step 7 */
> - ret = csi2_dphy_wait_clock_lane(csi2);
> - if (ret)
> - goto err_stop_upstream;
> -
> + csi2_dphy_wait_clock_lane(csi2);
> return 0;
>
> -err_stop_upstream:
> - v4l2_subdev_call(csi2->src_sd, video, s_stream, 0);
> err_assert_reset:
> csi2_enable(csi2, false);
> err_disable_clk:
--
Regards,
Laurent Pinchart
Re: [PATCH 1/1] MAINTAINERS: Add maintainers for Media Controller
Hi Mauro, On Mon, Jun 24, 2019 at 09:30:12AM -0300, Mauro Carvalho Chehab wrote: > Em Thu, 20 Jun 2019 17:19:55 +0300 Laurent Pinchart escreveu: > > On Thu, Jun 20, 2019 at 05:17:53PM +0300, Sakari Ailus wrote: > >> When Media Controller was merged to mainline long, long time ago, no-one > >> bothered to think what its MAINTAINERS entry should be. Now that Media > >> Controller is moved into its own directory, address this at the same time. > >> > >> So tell people to mail patches to myself and Laurent Pinchart. > >> > >> Note that the patches are still merged through the Media tree, just like > >> any other driver or framework bits that have separate "mail patches to" > >> entries different from the main drivers/media one. > >> > >> Signed-off-by: Sakari Ailus > > > > This will help me catching changes to the media controller, and being > > more active on reviews, so I welcome that change. > > Ok, but please notice that this is a core part of the subsystem, and > not a driver one. > > So, you should be sure that you'll have enough bandwidth to not > get patches accumulated here for no more than a reasonable time > (a couple of weeks). > > If both you and Sakari are ok with that, I'll pick it. I think that will be fine, based on the existing development rate for that code. Of course, if tomorrow 10 developers decide to work full time on it, I may not be able to follow, but that's hardly specific to MC, the media subsystem or me. -- Regards, Laurent Pinchart
Re: [PATCH 1/1] MAINTAINERS: Add maintainers for Media Controller
Hi Sakari, Thank you for the patch. On Thu, Jun 20, 2019 at 05:17:53PM +0300, Sakari Ailus wrote: > When Media Controller was merged to mainline long, long time ago, no-one > bothered to think what its MAINTAINERS entry should be. Now that Media > Controller is moved into its own directory, address this at the same time. > > So tell people to mail patches to myself and Laurent Pinchart. > > Note that the patches are still merged through the Media tree, just like > any other driver or framework bits that have separate "mail patches to" > entries different from the main drivers/media one. > > Signed-off-by: Sakari Ailus This will help me catching changes to the media controller, and being more active on reviews, so I welcome that change. Signed-off-by: Laurent Pinchart Reviewed-by: Laurent Pinchart (pick the tag you find the most appropriate, or both if you desire) > --- > This patch adds a MAINTAINERS entry for the MC framework and API, as > discussed in this week's weekly meeting. > > MAINTAINERS | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ad2bf808b02c..0a064d10a5df 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9643,6 +9643,17 @@ L: linux-...@vger.kernel.org > S: Maintained > F: drivers/iio/dac/cio-dac.c > > +MEDIA CONTROLLER FRAMEWORK > +M: Sakari Ailus > +M: Laurent Pinchart > +L: linux-media@vger.kernel.org > +W: https://www.linuxtv.org > +T: git git://linuxtv.org/media_tree.git > +S: Supported > +F: drivers/media/mc/ > +F: include/media/media-*.h > +F: include/uapi/linux/media.h > + > MEDIA DRIVERS FOR ASCOT2E > M: Sergey Kozlov > M: Abylay Ospan -- Regards, Laurent Pinchart
Re: [PATCH v2 3/3] rcar-vin: Add support for RGB formats with alpha component
Hi Niklas,
Thank you for the patch.
On Thu, Jun 13, 2019 at 02:04:39AM +0200, Niklas Söderlund wrote:
> The R-Car VIN module supports V4L2_PIX_FMT_ARGB555 and
> V4L2_PIX_FMT_ABGR32 pixel formats. Add the hardware register setup and
> allow the alpha component to be changed while streaming using the
> V4L2_CID_ALPHA_COMPONENT control.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 30 +
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 ++
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 4e991cce5fb56a90..5c0ed27c5d05dd45 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -111,8 +111,11 @@
> #define VNIE_EFE (1 << 1)
>
> /* Video n Data Mode Register bits */
> +#define VNDMR_A8BIT(n) ((n & 0xff) << 24)
> +#define VNDMR_A8BIT_MASK (0xff << 24)
> #define VNDMR_EXRGB (1 << 8)
> #define VNDMR_BPSM (1 << 4)
> +#define VNDMR_ABIT (1 << 2)
> #define VNDMR_DTMD_YCSEP (1 << 1)
> #define VNDMR_DTMD_ARGB (1 << 0)
>
> @@ -730,6 +733,12 @@ static int rvin_setup(struct rvin_dev *vin)
> /* Note: not supported on M1 */
> dmr = VNDMR_EXRGB;
> break;
> + case V4L2_PIX_FMT_ARGB555:
> + dmr = (vin->alpha ? VNDMR_ABIT : 0) | VNDMR_DTMD_ARGB;
> + break;
> + case V4L2_PIX_FMT_ABGR32:
> + dmr = VNDMR_A8BIT(vin->alpha) | VNDMR_EXRGB | VNDMR_DTMD_ARGB;
> + break;
> default:
> vin_err(vin, "Invalid pixelformat (0x%x)\n",
> vin->format.pixelformat);
> @@ -1346,5 +1355,26 @@ int rvin_set_channel_routing(struct rvin_dev *vin, u8
> chsel)
>
> void rvin_set_alpha(struct rvin_dev *vin, unsigned int alpha)
> {
> + u32 dmr;
> +
> vin->alpha = alpha;
> +
> + if (vin->state == STOPPED)
The state is protected by the vin->qlock spinlock. Is it safe to check
it here without holding the spinlock ? The answer may be yes if you can
guarantee that no code patch will race except for the IRQ handler, and
guarantee that the race with the IRQ handler isn't an issue.
Additionally, what happens if the control is set and streaming is then
started ? I don't see in call to v4l2_ctrl_handler_setup() in 2/3 or
3/3.
> + return;
> +
> + switch (vin->format.pixelformat) {
> + case V4L2_PIX_FMT_ARGB555:
> + dmr = rvin_read(vin, VNDMR_REG) & ~VNDMR_ABIT;
> + if (vin->alpha)
> + dmr |= VNDMR_ABIT;
> + break;
> + case V4L2_PIX_FMT_ABGR32:
> + dmr = rvin_read(vin, VNDMR_REG) & ~VNDMR_A8BIT_MASK;
> + dmr |= VNDMR_A8BIT(vin->alpha);
> + break;
> + default:
> + return;
> + }
> +
> + rvin_write(vin, dmr, VNDMR_REG);
> }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 7cbdcbf9b090c638..bb2900f5d000f9a6 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -54,6 +54,14 @@ static const struct rvin_video_format rvin_formats[] = {
> .fourcc = V4L2_PIX_FMT_XBGR32,
> .bpp= 4,
> },
> + {
> + .fourcc = V4L2_PIX_FMT_ARGB555,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_ABGR32,
> + .bpp= 4,
> + },
> };
>
> const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat)
--
Regards,
Laurent Pinchart
Re: Route lifetime in SUBDEV_[GS]_ROUTING
up to the driver implementation -inside an entity-. > > > > > > - The cross-entity (sorry, I lack a better term here) multiplexing > > > happens on physical bus that allows so, and I can only think of > > > CSI-2 at the moment. Sure, you could share the lines of a parallel > > > bus playing with enables/disables of the transmitters, but this > > > is a custom hack that does not play well in this model. > > > Each CSI-2 source pad has up to 4 streams (one per VC) and the > > > content of those streams is retrieved from the transmitter by the > > > receiver through the remote frame_desc operation [*], as receivers > > > might need to be setup using to filter on particular VC/DT combinations > > > to receive the stream. > > > > Note that the concept of a "stream" is different in our proposed API and in > > CSI-2 (virtual channel): on CSI-2 virtual channels can carry multiple data > > types but in our definition they do not. That means there will be more > > streams on SUBDEV_[GS]_ROUTING API than there are on a CSI-2 bus. > > > > We also do not limit the use of the new API to old CSI-2 D-PHYs that > > only support four virtual channels. Therefore we need to think how this > > would work on 16 or 32 virtual channels, and preferrably not posing > > problems with larger numbers either. > > > > > > > > - Each CSI-2 receiver sink pad supports 4 streams (the CSI-2 VCs) and any > > > of those streams can be directed to any of its source pads, to > > > implement what you have described (one pad connected to an ISP-like > > > device, on other to the DMA engine directly etc) > > > > > > - DT negotiation is still a bit vague. The example we have on the > > > series (adv748x and r-car csi2) configure the receiver's accepted DT > > > inspecting the remote frame_desc. Again, as per [*] this migh be > > > limitied to 1 DT for VC, which might not be enough and would require > > > re-thinking the operation used for the negotiation. > > > > > > - Configuring a multiplexed source pad image format is today not > > > possible, the format is always propagated from the sink pad to which > > > a route is enabled to the source pad. Might this be a limitation on > > > how we control which DTs are multiplexed inside a VC and won't allow > > > to model any format conversion that might happen at the source pad > > > output. I was toying myself with the idea of a stream-aware set > > > format operation for multiplexed source pads, not sure it might work > > > though. > > > > > > Can I ask you why: > > > - you mention 16 or 32 VCs ? Each CSI-2 link supports up to 4. > > > > See above. > > > > > - you put DT in the routing mix, and I suspect it is here where our > > > disconnection happens. I always assume DT configuration as a result > > > of a format configuration operation, which currently has limitations > > > as noted here above. > > > > Yes; DT comes from the format and is generally determined by the > > transmitting driver. Nothing else limits the number of DTs on a VC except > > the number of DTs --- which is currently 64. > > > > > [*] I would later like to talk about if this is the most appropriate > > > operation to handle this negotiation, as I'm not sure we can handle DT > > > negotiation properly with that, but that's for later. > > > > > > > CSI-2 receivers support a number of simultaneous streams, and as the > > > > stream > > > > is demultiplexed there, this means there will be as many source pads as > > > > there are supported simultaneous streams. This heavily depe`nds on the > > > > hardware, but the number could be e.g. 1, 4 or 8. Much smaller than > > > > 2048 in > > > > any case. > > > > > > Why 8? Is this related to DT multiplexing again? > > > > Yes and no. It's just a random number between 1 and 2048. :-) > > > > > > Another option could be creating no routes at all at device init time, > > > > and > > > > letting the user create them. We could add a new flag for routes telling > > > > that a route is dynamic: disabling a dynamic route would simply delete > > > > it. > > > > Likewise, a SUBDEV_G_ROUTING returning no routes (but no error either) > > > > would also tell the user only dynamic routes are supported. > > > > > > > > We should document this and change the driver implementation > > > > accordingly. > > > > No API changes are needed (apart from adding the dynamic flag --- or > > > > rather > > > > call it "volatile", to avoid confusing with routes that can be enabled > > > > or > > > > disabled while streaming). > > > > > > I have v5 of the series ready. Do you want me to post it to progress > > > discussion, or should we clarify this first? > > > > Feel free to post it. But to merge the series, I think we need to address > > this. -- Regards, Laurent Pinchart
Re: [PATCH for v5.2] videobuf2-core.c: always reacquire USERPTR memory
Hi Nicolas,
On Tue, Jun 11, 2019 at 08:09:13PM -0400, Nicolas Dufresne wrote:
> Le mardi 11 juin 2019 à 13:24 +0300, Laurent Pinchart a écrit :
> > On Fri, Jun 07, 2019 at 03:38:39PM -0400, Nicolas Dufresne wrote:
> >> Le vendredi 07 juin 2019 à 16:58 +0300, Laurent Pinchart a écrit :
> >>> On Fri, Jun 07, 2019 at 03:55:05PM +0200, Marek Szyprowski wrote:
> >>>> On 2019-06-07 15:40, Hans Verkuil wrote:
> >>>>> On 6/7/19 2:47 PM, Hans Verkuil wrote:
> >>>>>> On 6/7/19 2:23 PM, Hans Verkuil wrote:
> >>>>>>> On 6/7/19 2:14 PM, Marek Szyprowski wrote:
> >>>>>>>> On 2019-06-07 14:01, Hans Verkuil wrote:
> >>>>>>>>> On 6/7/19 1:16 PM, Laurent Pinchart wrote:
> >>>>>>>>>> Thank you for the patch.
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Jun 07, 2019 at 10:45:31AM +0200, Hans Verkuil wrote:
> >>>>>>>>>>> The __prepare_userptr() function made the incorrect assumption
> >>>>>>>>>>> that if the
> >>>>>>>>>>> same user pointer was used as the last one for which memory was
> >>>>>>>>>>> acquired, then
> >>>>>>>>>>> there was no need to re-acquire the memory. This assumption was
> >>>>>>>>>>> never properly
> >>>>>>>>>>> tested, and after doing that it became clear that this was in
> >>>>>>>>>>> fact wrong.
> >>>>>>>>>> Could you explain in the commit message why the assumption is not
> >>>>>>>>>> correct ?
> >>>>>>>>> You can free the memory, then allocate it again and you can get the
> >>>>>>>>> same pointer,
> >>>>>>>>> even though it is not necessarily using the same physical pages for
> >>>>>>>>> the memory
> >>>>>>>>> that the kernel is still using for it.
> >>>>>>>>>
> >>>>>>>>> Worse, you can free the memory, then allocate only half the memory
> >>>>>>>>> you need and
> >>>>>>>>> get back the same pointer. vb2 wouldn't notice this. And it seems
> >>>>>>>>> to work (since
> >>>>>>>>> the original mapping still remains), but this can corrupt userspace
> >>>>>>>>> memory
> >>>>>>>>> causing the application to crash. It's not quite clear to me how
> >>>>>>>>> the memory can
> >>>>>>>>> get corrupted. I don't know enough of those low-level mm internals
> >>>>>>>>> to understand
> >>>>>>>>> the sequence of events.
> >>>>>>>>>
> >>>>>>>>> I have test code for v4l2-compliance available if someone wants to
> >>>>>>>>> test this.
> >>>>>>>> I'm interested, I would really like to know what happens in the mm
> >>>>>>>> subsystem in such case.
> >>>>>>> Here it is:
> >>>>>>>
> >>>>>>> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>>>> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>>>> index be606e48..9abf41da 100644
> >>>>>>> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>>>> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>>>> @@ -797,7 +797,7 @@ int testReadWrite(struct node *node)
> >>>>>>> return 0;
> >>>>>>> }
> >>>>>>>
> >>>>>>> -static int captureBufs(struct node *node, const cv4l_queue &q,
> >>>>>>> +static int captureBufs(struct node *node, cv4l_queue &q,
> >>>>>>> const cv4l_queue &m2m_q, unsigned frame_count, int
> >>>>>>> pollmode,
> >>>>>>> unsigned &capture_count)
> >>>>>>> {
> >>>>>>> @@ -962,6 +962,21 @@ static int captureBufs(struct node *node, const
> >>>>>>> cv4l_queue &q,
> &
Re: [PATCH for v5.2] videobuf2-core.c: always reacquire USERPTR memory
Hi Nicolas,
On Fri, Jun 07, 2019 at 03:38:39PM -0400, Nicolas Dufresne wrote:
> Le vendredi 07 juin 2019 à 16:58 +0300, Laurent Pinchart a écrit :
> > On Fri, Jun 07, 2019 at 03:55:05PM +0200, Marek Szyprowski wrote:
> >> On 2019-06-07 15:40, Hans Verkuil wrote:
> >>> On 6/7/19 2:47 PM, Hans Verkuil wrote:
> >>>> On 6/7/19 2:23 PM, Hans Verkuil wrote:
> >>>>> On 6/7/19 2:14 PM, Marek Szyprowski wrote:
> >>>>>> On 2019-06-07 14:01, Hans Verkuil wrote:
> >>>>>>> On 6/7/19 1:16 PM, Laurent Pinchart wrote:
> >>>>>>>> Thank you for the patch.
> >>>>>>>>
> >>>>>>>> On Fri, Jun 07, 2019 at 10:45:31AM +0200, Hans Verkuil wrote:
> >>>>>>>>> The __prepare_userptr() function made the incorrect assumption that
> >>>>>>>>> if the
> >>>>>>>>> same user pointer was used as the last one for which memory was
> >>>>>>>>> acquired, then
> >>>>>>>>> there was no need to re-acquire the memory. This assumption was
> >>>>>>>>> never properly
> >>>>>>>>> tested, and after doing that it became clear that this was in fact
> >>>>>>>>> wrong.
> >>>>>>>> Could you explain in the commit message why the assumption is not
> >>>>>>>> correct ?
> >>>>>>> You can free the memory, then allocate it again and you can get the
> >>>>>>> same pointer,
> >>>>>>> even though it is not necessarily using the same physical pages for
> >>>>>>> the memory
> >>>>>>> that the kernel is still using for it.
> >>>>>>>
> >>>>>>> Worse, you can free the memory, then allocate only half the memory
> >>>>>>> you need and
> >>>>>>> get back the same pointer. vb2 wouldn't notice this. And it seems to
> >>>>>>> work (since
> >>>>>>> the original mapping still remains), but this can corrupt userspace
> >>>>>>> memory
> >>>>>>> causing the application to crash. It's not quite clear to me how the
> >>>>>>> memory can
> >>>>>>> get corrupted. I don't know enough of those low-level mm internals to
> >>>>>>> understand
> >>>>>>> the sequence of events.
> >>>>>>>
> >>>>>>> I have test code for v4l2-compliance available if someone wants to
> >>>>>>> test this.
> >>>>>> I'm interested, I would really like to know what happens in the mm
> >>>>>> subsystem in such case.
> >>>>> Here it is:
> >>>>>
> >>>>> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>> index be606e48..9abf41da 100644
> >>>>> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> >>>>> @@ -797,7 +797,7 @@ int testReadWrite(struct node *node)
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>> -static int captureBufs(struct node *node, const cv4l_queue &q,
> >>>>> +static int captureBufs(struct node *node, cv4l_queue &q,
> >>>>> const cv4l_queue &m2m_q, unsigned frame_count, int
> >>>>> pollmode,
> >>>>> unsigned &capture_count)
> >>>>> {
> >>>>> @@ -962,6 +962,21 @@ static int captureBufs(struct node *node, const
> >>>>> cv4l_queue &q,
> >>>>> buf.s_flags(V4L2_BUF_FLAG_REQUEST_FD);
> >>>>> buf.s_request_fd(buf_req_fds[req_idx]);
> >>>>> }
> >>>>> + if (v4l_type_is_capture(buf.g_type()) &&
> >>>>> q.g_memory() == V4L2_MEMORY_USERPTR) {
> >>>>> + printf("\nidx: %d", buf.g_index());
> >>>>> + for (unsigned p = 0; p <
> >>>>> q.g_num_planes();
Re: [PATCH] v4l: rcar-fcp: Read IP version register at probe time
Hi Geert, On Sun, Jun 09, 2019 at 01:51:24PM +0200, Geert Uytterhoeven wrote: > On Sun, Jun 9, 2019 at 12:09 PM Laurent Pinchart wrote: > > On Sun, Jun 09, 2019 at 10:06:19AM +0200, Geert Uytterhoeven wrote: > > > On Sat, Jun 8, 2019 at 2:55 PM Laurent Pinchart wrote: > > > > This helps identifying the IP core version, for debugging purpose only > > > > for now. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > > > > Thanks for your patch! > > > > > > > --- a/drivers/media/platform/rcar-fcp.c > > > > +++ b/drivers/media/platform/rcar-fcp.c > > > > > + if (IS_ERR(fcp->iomem)) > > > > + return PTR_ERR(fcp->iomem); > > > > + > > > > + pm_runtime_get_sync(&pdev->dev); > > > > + version = rcar_fcp_read(fcp, FCP_VCR); > > > > > > Please note that rcar_fcp_read() does not exist in upstream nor next, > > > and linux-renesas-soc hasn't seen the patch that added it. > > > > That's why it was added in this patch :-) > > Bummer... Do you plan to have other users? > If not, I'd just open-code this single-line function. Yes, with FNCL support there should be other users. -- Regards, Laurent Pinchart
Re: [PATCH] v4l: rcar-fcp: Read IP version register at probe time
Hi Geert, On Sun, Jun 09, 2019 at 10:06:19AM +0200, Geert Uytterhoeven wrote: > On Sat, Jun 8, 2019 at 2:55 PM Laurent Pinchart wrote: > > This helps identifying the IP core version, for debugging purpose only > > for now. > > > > Signed-off-by: Laurent Pinchart > > Thanks for your patch! > > > --- a/drivers/media/platform/rcar-fcp.c > > +++ b/drivers/media/platform/rcar-fcp.c > > > @@ -138,6 +168,19 @@ static int rcar_fcp_probe(struct platform_device *pdev) > > > > pm_runtime_enable(&pdev->dev); > > > > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + fcp->iomem = devm_ioremap_resource(&pdev->dev, mem); > > devm_platform_ioremap_resource()? Nice, I've thought about adding such a function for some time, I didn't know it had been merged. > > + if (IS_ERR(fcp->iomem)) > > + return PTR_ERR(fcp->iomem); > > + > > + pm_runtime_get_sync(&pdev->dev); > > + version = rcar_fcp_read(fcp, FCP_VCR); > > Please note that rcar_fcp_read() does not exist in upstream nor next, > and linux-renesas-soc hasn't seen the patch that added it. That's why it was added in this patch :-) -- Regards, Laurent Pinchart
