Re: [PATCH v3 1/2] media: dt-bindings: bind nokia,n900-ir to generic pwm-ir-tx driver
On 29.08.2018 20:07, Mauro Carvalho Chehab wrote:
Em Fri, 13 Jul 2018 13:22:29 +0100
Sean Young escreveu:
The generic pwm-ir-tx driver should work for the Nokia n900.
Compile tested only.
It would be good to have some tests...
Unfortunately, it turned out I won't be able to test soon, so please,
somebody else do it.
Cc: Rob Herring
Cc: Ivaylo Dimitrov
Cc: Pali Rohár
Cc: Pavel Machek
Cc: Timo Kokkonen
Cc: Tony Lindgren
And some acks
Before merging it.
Signed-off-by: Sean Young
---
arch/arm/boot/dts/omap3-n900.dts | 2 +-
drivers/media/rc/pwm-ir-tx.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 182a53991c90..fd12dea15799 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -154,7 +154,7 @@
};
ir: n900-ir {
- compatible = "nokia,n900-ir";
+ compatible = "nokia,n900-ir", "pwm-ir-tx";
pwms = < 0 26316 0>; /* 38000 Hz */
};
diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
index 27d0f5837a76..272947b430c8 100644
--- a/drivers/media/rc/pwm-ir-tx.c
+++ b/drivers/media/rc/pwm-ir-tx.c
@@ -30,6 +30,7 @@ struct pwm_ir {
};
static const struct of_device_id pwm_ir_of_match[] = {
+ { .compatible = "nokia,n900-ir" },
{ .compatible = "pwm-ir-tx", },
{ },
};
Thanks,
Mauro
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Aug 31 05:00:13 CEST 2018 media-tree git hash:3799eca51c5be3cd76047a582ac52087373b54b3 media_build git hash: 9623f0df237febbd2d3b36ee9541d8bebba19b2d v4l-utils git hash: fcccd99ebdc6ff01296f57948c52dacc9c1d2695 edid-decode git hash: b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.5-marune linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-i686: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.101-i686: ERRORS linux-3.0.101-x86_64: ERRORS linux-3.1.10-i686: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.102-i686: ERRORS linux-3.2.102-x86_64: ERRORS linux-3.3.8-i686: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.113-i686: ERRORS linux-3.4.113-x86_64: ERRORS linux-3.5.7-i686: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-i686: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.10-i686: ERRORS linux-3.7.10-x86_64: ERRORS linux-3.8.13-i686: ERRORS linux-3.8.13-x86_64: ERRORS linux-3.9.11-i686: ERRORS linux-3.9.11-x86_64: ERRORS linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10/arch/x86/include/asm/msr.h:131, linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74/arch/x86/include/asm/apic.h:234:13: error: storage class specified for parameter 'clear_local_APIC' linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.14.79/arch/x86/include/asm/preempt.h:6, linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.119-i686: ERRORS linux-3.18.119-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.152-i686: ERRORS linux-4.4.152-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.124-i686: ERRORS linux-4.9.124-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.67-i686: ERRORS linux-4.14.67-x86_64: ERRORS linux-4.15.18-i686: ERRORS linux-4.15.18-x86_64: ERRORS linux-4.16.18-i686: ERRORS linux-4.16.18-x86_64: ERRORS linux-4.17.19-i686: ERRORS linux-4.17.19-x86_64: ERRORS linux-4.18.5-i686: ERRORS linux-4.18.5-x86_64: ERRORS linux-4.19-rc1-i686: ERRORS linux-4.19-rc1-x86_64: ERRORS apps: OK specified for parameter 'kernel_sock_ioctl' specified for parameter 'printk_address' specified for parameter 'printk_address' specified for parameter 'printk_address' specified for parameter 'dev_load' specified for parameter 'irq_set_irq_wake' specified for parameter 'ftrace_graph_init_task' specified for parameter 'kernel_page_present' specified for parameter 'numa_set_node' specified for parameter 'llist_add_batch' specified for parameter 'llist_add_batch' specified for parameter 'llist_add_batch' specified for parameter 'io_schedule_timeout' specified for parameter 'io_schedule_timeout' specified for parameter 'simple_empty' specifiers or '...' before 'atomic_long_t' specified for parameter 'next_online_pgdat' specified for parameter 'klist_add_tail' specified for parameter 'next_online_pgdat' specified for parameter 'unlock_vector_lock' specified for parameter 'device_rename' specifiers or '...' before 'atomic64_t' specifiers or '...' before 'atomic64_t' spec-git: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: Question regarding optimizing pipeline in Vimc
On Wed, Aug 22, 2018 at 3:49 AM Hans Verkuil wrote: > > My basic idea was that you use a TPG state structure that contains the > desired output: the sensor starts with e.g. 720p using some bayer pixelformat, > the debayer module replaces the pixelformat with e.g. PIX_FMT_RGB32, a > grayscale filter replaces it with PI_FMT_GREY, and that's what the TPG for the > video device eventually will use to generate the video. > > This assumes of course that all the vimc blocks only do operations that can > be handled by the TPG. Depending on what the blocks will do the TPG might need > to be extended if a feature is missing. > Hi Hans, I start to work on this task but I have another question. I understand that the final image should have the correct format as if the frame was passing through the whole topology. But the operations itself doesn't needed to be done on each entity. For example, a scaled image will have deformations that will not be present if it is generated on the end of the pipeline with the final size. You just need the format, size and properties to be correct, do I got it right? Thanks Lucas.
[GIT PULL FOR v4.20] Add detection of reduced FPS
Some HDMI receivers are able to tell the difference between 59.94 and 60 Hz, but there was no way to expose that to userspace. Add the V4L2_DV_FL_CAN_DETECT_REDUCED_FPS flag and allow receivers to set the V4L2_DV_FL_REDUCED_FPS if they detect this. Implemented and tested this with the adv7842, which is one of the rare receivers that is accurate enough. This pull request contains the v2 patch series: https://www.spinics.net/lists/linux-media/msg139144.html It's just rebased to 4.19. Regards, Hans The following changes since commit 3799eca51c5be3cd76047a582ac52087373b54b3: media: camss: add missing includes (2018-08-29 14:02:06 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git reduced-fps for you to fetch changes up to 80cc532774debbef408b105ddcbae05114bce5f3: adv7842: enable reduced fps detection (2018-08-30 16:51:08 +0200) Hans Verkuil (2): vidioc-g-dv-timings.rst: document V4L2_DV_FL_CAN_DETECT_REDUCED_FPS adv7842: enable reduced fps detection Jose Abreu (3): videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper cobalt: Use v4l2_calc_timeperframe helper Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst | 27 +++ drivers/media/i2c/adv7842.c | 9 + drivers/media/pci/cobalt/cobalt-v4l2.c | 9 +++-- drivers/media/v4l2-core/v4l2-dv-timings.c| 39 +++ include/media/v4l2-dv-timings.h | 11 +++ include/uapi/linux/videodev2.h | 7 +++ 6 files changed, 92 insertions(+), 10 deletions(-)
Re: [PATCHv2 09/10] media-request: EPERM -> EACCES
On Thu, Aug 30, 2018 at 01:51:39PM +0200, Hans Verkuil wrote: > On 08/30/2018 12:15 PM, Sakari Ailus wrote: > > Hi Hans, > > > > Thanks a lot for working on this! > > > > On Tue, Aug 28, 2018 at 03:49:10PM +0200, Hans Verkuil wrote: > >> From: Hans Verkuil > >> > >> If requests are not supported by the driver, then return EACCES, not > >> EPERM. This is consistent with the error that an invalid request_fd will > >> give, and if requests are not supported, then all request_fd values are > >> invalid. > >> > >> Signed-off-by: Hans Verkuil > >> --- > >> Documentation/media/uapi/v4l/buffer.rst | 2 +- > >> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 9 - > >> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 15 +-- > >> drivers/media/media-request.c | 4 ++-- > >> 4 files changed, 16 insertions(+), 14 deletions(-) > >> > >> diff --git a/Documentation/media/uapi/v4l/buffer.rst > >> b/Documentation/media/uapi/v4l/buffer.rst > >> index 1865cd5b9d3c..58a6d7d336e6 100644 > >> --- a/Documentation/media/uapi/v4l/buffer.rst > >> +++ b/Documentation/media/uapi/v4l/buffer.rst > >> @@ -314,7 +314,7 @@ struct v4l2_buffer > >>:ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. > >>Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls > >>other than :ref:`VIDIOC_QBUF `. > >> - If the device does not support requests, then ``EPERM`` will be > >> returned. > >> + If the device does not support requests, then ``EACCES`` will be > >> returned. > >>If requests are supported but an invalid request file descriptor is > >>given, then ``EINVAL`` will be returned. > >> > >> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > >> b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > >> index ad8908ce3095..54a999df5aec 100644 > >> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > >> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > >> @@ -100,7 +100,7 @@ file descriptor and ``which`` is set to > >> ``V4L2_CTRL_WHICH_REQUEST_VAL``, > >> then the controls are not applied immediately when calling > >> :ref:`VIDIOC_S_EXT_CTRLS `, but instead are applied by > >> the driver for the buffer associated with the same request. > >> -If the device does not support requests, then ``EPERM`` will be returned. > >> +If the device does not support requests, then ``EACCES`` will be returned. > >> If requests are supported but an invalid request file descriptor is given, > >> then ``EINVAL`` will be returned. > >> > >> @@ -233,7 +233,7 @@ still cause this situation. > >>these controls have to be retrieved from a request or tried/set for > >>a request. In the latter case the ``request_fd`` field contains the > >>file descriptor of the request that should be used. If the device > >> - does not support requests, then ``EPERM`` will be returned. > >> + does not support requests, then ``EACCES`` will be returned. > >> > >>.. note:: > >> > >> @@ -299,7 +299,7 @@ still cause this situation. > >>- ``request_fd`` > >>- File descriptor of the request to be used by this operation. Only > >>valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``. > >> - If the device does not support requests, then ``EPERM`` will be > >> returned. > >> + If the device does not support requests, then ``EACCES`` will be > >> returned. > >>If requests are supported but an invalid request file descriptor is > >>given, then ``EINVAL`` will be returned. > >> * - __u32 > >> @@ -408,6 +408,5 @@ EACCES > >> control, or to get a control from a request that has not yet been > >> completed. > >> > >> -EPERM > > > > -EACCES here, too? > > The '-' in -EPERM is from diff, meaning: delete this line :-) Oh, I missed that while reading the quoted message. X-) > > > > >> -The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the > >> +Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but > >> the > >> device does not support requests. > >> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst > >> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst > >> index 7bff69c15452..a2f4ac0b0ba1 100644 > >> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst > >> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst > >> @@ -104,7 +104,7 @@ in use. Setting it means that the buffer will not be > >> passed to the driver > >> until the request itself is queued. Also, the driver will apply any > >> settings associated with the request for this buffer. This field will > >> be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. > >> -If the device does not support requests, then ``EPERM`` will be returned. > >> +If the device does not support requests, then ``EACCES`` will be returned. > >> If requests are supported but an invalid request file descriptor is given, > >> then ``EINVAL`` will be returned. > >> > >> @@ -175,9
Re: [PATCHv2 09/10] media-request: EPERM -> EACCES
On 08/30/2018 12:15 PM, Sakari Ailus wrote: > Hi Hans, > > Thanks a lot for working on this! > > On Tue, Aug 28, 2018 at 03:49:10PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> If requests are not supported by the driver, then return EACCES, not >> EPERM. This is consistent with the error that an invalid request_fd will >> give, and if requests are not supported, then all request_fd values are >> invalid. >> >> Signed-off-by: Hans Verkuil >> --- >> Documentation/media/uapi/v4l/buffer.rst | 2 +- >> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 9 - >> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 15 +-- >> drivers/media/media-request.c | 4 ++-- >> 4 files changed, 16 insertions(+), 14 deletions(-) >> >> diff --git a/Documentation/media/uapi/v4l/buffer.rst >> b/Documentation/media/uapi/v4l/buffer.rst >> index 1865cd5b9d3c..58a6d7d336e6 100644 >> --- a/Documentation/media/uapi/v4l/buffer.rst >> +++ b/Documentation/media/uapi/v4l/buffer.rst >> @@ -314,7 +314,7 @@ struct v4l2_buffer >> :ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. >> Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls >> other than :ref:`VIDIOC_QBUF `. >> -If the device does not support requests, then ``EPERM`` will be >> returned. >> +If the device does not support requests, then ``EACCES`` will be >> returned. >> If requests are supported but an invalid request file descriptor is >> given, then ``EINVAL`` will be returned. >> >> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst >> b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst >> index ad8908ce3095..54a999df5aec 100644 >> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst >> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst >> @@ -100,7 +100,7 @@ file descriptor and ``which`` is set to >> ``V4L2_CTRL_WHICH_REQUEST_VAL``, >> then the controls are not applied immediately when calling >> :ref:`VIDIOC_S_EXT_CTRLS `, but instead are applied by >> the driver for the buffer associated with the same request. >> -If the device does not support requests, then ``EPERM`` will be returned. >> +If the device does not support requests, then ``EACCES`` will be returned. >> If requests are supported but an invalid request file descriptor is given, >> then ``EINVAL`` will be returned. >> >> @@ -233,7 +233,7 @@ still cause this situation. >> these controls have to be retrieved from a request or tried/set for >> a request. In the latter case the ``request_fd`` field contains the >> file descriptor of the request that should be used. If the device >> -does not support requests, then ``EPERM`` will be returned. >> +does not support requests, then ``EACCES`` will be returned. >> >> .. note:: >> >> @@ -299,7 +299,7 @@ still cause this situation. >>- ``request_fd`` >>- File descriptor of the request to be used by this operation. Only >> valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``. >> -If the device does not support requests, then ``EPERM`` will be >> returned. >> +If the device does not support requests, then ``EACCES`` will be >> returned. >> If requests are supported but an invalid request file descriptor is >> given, then ``EINVAL`` will be returned. >> * - __u32 >> @@ -408,6 +408,5 @@ EACCES >> control, or to get a control from a request that has not yet been >> completed. >> >> -EPERM > > -EACCES here, too? The '-' in -EPERM is from diff, meaning: delete this line :-) > >> -The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the >> +Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but >> the >> device does not support requests. >> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst >> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst >> index 7bff69c15452..a2f4ac0b0ba1 100644 >> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst >> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst >> @@ -104,7 +104,7 @@ in use. Setting it means that the buffer will not be >> passed to the driver >> until the request itself is queued. Also, the driver will apply any >> settings associated with the request for this buffer. This field will >> be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. >> -If the device does not support requests, then ``EPERM`` will be returned. >> +If the device does not support requests, then ``EACCES`` will be returned. >> If requests are supported but an invalid request file descriptor is given, >> then ``EINVAL`` will be returned. >> >> @@ -175,9 +175,12 @@ EPIPE >> codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already >> dequeued and no new buffers are expected to become available. >> >> -EPERM >> +EACCES >> The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not >> -support requests.
Re: [PATCH 4/5] videodev2.h: add new capabilities for buffer types
On 08/29/2018 10:49 AM, Tomasz Figa wrote: > On Tue, Aug 28, 2018 at 9:37 PM Hans Verkuil wrote: >> >> On 24/08/18 16:36, Tomasz Figa wrote: >>> Hi Hans, >>> >>> On Fri, Aug 24, 2018 at 5:22 PM Hans Verkuil wrote: From: Hans Verkuil VIDIOC_REQBUFS and VIDIOC_CREATE_BUFFERS will return capabilities telling userspace what the given buffer type is capable of. >>> >>> Please see my comments below. >>> Signed-off-by: Hans Verkuil --- .../media/uapi/v4l/vidioc-create-bufs.rst | 10 +- .../media/uapi/v4l/vidioc-reqbufs.rst | 36 ++- include/uapi/linux/videodev2.h| 13 +-- 3 files changed, 55 insertions(+), 4 deletions(-) diff --git a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst index a39e18d69511..fd34d3f236c9 100644 --- a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst +++ b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst @@ -102,7 +102,15 @@ than the number requested. - ``format`` - Filled in by the application, preserved by the driver. * - __u32 - - ``reserved``\ [8] + - ``capabilities`` + - Set by the driver. If 0, then the driver doesn't support +capabilities. In that case all you know is that the driver is + guaranteed to support ``V4L2_MEMORY_MMAP`` and *might* support + other :c:type:`v4l2_memory` types. It will not support any others + capabilities. See :ref:`here ` for a list of the + capabilities. >>> >>> Perhaps it would make sense to document how the application is >>> expected to query for these capabilities? Right now, the application >>> is expected to fill in the "memory" field in this struct (and reqbufs >>> counterpart), but it sounds a bit strange that one needs to know what >>> "memory" value to write there to query what set of "memory" values is >>> supported. In theory, MMAP is expected to be always supported, but it >>> sounds strange anyway. Also, is there a way to call REQBUFS without >>> altering the buffer allocation? >> >> No, this is only possible with CREATE_BUFS. >> >> But it is reasonable to call REQBUFS with a count of 0, since you want to >> start with a clean slate anyway. >> >> The only option I see would be to introduce a new memory type (e.g. >> V4L2_MEMORY_CAPS) to just return the capabilities. But that's more ugly >> then just requiring that you use MMAP when calling this. >> >> I'm inclined to just document that you need to set memory to MMAP if >> you want to get the capabilities since MMAP is always guaranteed to >> exist. > > I guess it's the least evil we can get without changing the API too > much. Fair enough. > Can you ack the updated patch: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134624.html And take a look at patches 6-10 as well, if you have time. I'd like to get this merged in a request topic branch asap. Regards, Hans > Best regards, > Tomasz >
Hello dear.
Hello dear. It is wonderful to contact you, I want us to have correspondence. I wish you will have the desire so that we can get acquainted to each other. Life itself is a mystery, you never know where it might lead you. I'm Aisha.gaddafi, the only biological douther of Qi,muamar gaddafi president of libya . I will be pleased if you reply through (mrsaishagaddaf...@gmail.com) thanks aisha.gaddafi
[GIT PULL for 4.20] Sensor and Intel CIO2 driver cleanups, fixes
Hi Mauro, Here are a few cleanups and fixes for sensor and Intel CIO2 CSI-2 receiver drivers. Please pull. The following changes since commit 3799eca51c5be3cd76047a582ac52087373b54b3: media: camss: add missing includes (2018-08-29 14:02:06 -0400) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git for-4.20-1 for you to fetch changes up to 4d99425e4b2a34e00a4d79ed5526524548288568: media: ov5640: fix mode change regression (2018-08-30 14:14:20 +0300) Akinobu Mita (2): media: ov772x: use SCCB regmap media: ov9650: use SCCB regmap Alexey Khoroshilov (1): media: ov772x: Disable clk on error path Hugues Fruchet (1): media: ov5640: fix mode change regression Sakari Ailus (2): ov5670, ov13858: Use pm_runtime_idle i2c: Fix pm_runtime_get_if_in_use() usage in sensor drivers zhong jiang (1): media: ipu3-cio2: Use dma_zalloc_coherent to replace dma_alloc_coherent + memset drivers/media/i2c/Kconfig| 2 + drivers/media/i2c/ov13858.c | 12 +- drivers/media/i2c/ov2685.c | 2 +- drivers/media/i2c/ov5640.c | 21 +++- drivers/media/i2c/ov5670.c | 12 +- drivers/media/i2c/ov5695.c | 2 +- drivers/media/i2c/ov772x.c | 193 +-- drivers/media/i2c/ov7740.c | 2 +- drivers/media/i2c/ov9650.c | 157 - drivers/media/pci/intel/ipu3/ipu3-cio2.c | 6 +- 10 files changed, 184 insertions(+), 225 deletions(-) -- Sakari Ailus e-mail: sakari.ai...@iki.fi
Re: [PATCH 1/2] dt-bindings: dw9714, dw9807-vcm: Add files to MAINTAINERS, rename files
Ping?
On Mon, Jul 23, 2018 at 01:50:38PM +0300, Sakari Ailus wrote:
> Add the DT binding documentation for dw9714 and dw9807-vcm to the
> MAINTAINERS file. The dw9807-vcm binding documentation file is renamed to
> match the dw9807's VCM bit's compatible string.
>
> Signed-off-by: Sakari Ailus
> ---
> .../bindings/media/i2c/{dongwoon,dw9807.txt => dongwoon,dw9807-vcm.txt} | 0
> MAINTAINERS | 2
> ++
> 2 files changed, 2 insertions(+)
> rename Documentation/devicetree/bindings/media/i2c/{dongwoon,dw9807.txt =>
> dongwoon,dw9807-vcm.txt} (100%)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> rename to Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bbd9b9b3d74f..44e917de2c8c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4410,6 +4410,7 @@ L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> F: drivers/media/i2c/dw9714.c
> +F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
>
> DONGWOON DW9807 LENS VOICE COIL DRIVER
> M: Sakari Ailus
> @@ -4417,6 +4418,7 @@ L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> F: drivers/media/i2c/dw9807.c
> +F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
>
> DOUBLETALK DRIVER
> M: "James R. Van Zandt"
> --
> 2.11.0
>
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
[GIT PULL FOR v4.20] Add Request API for the topic branch
Hi Mauro, This is a pull request to add the Request API v18 as a topic branch. Note that this does not yet include the follow-up patches: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134630.html Those will come in a separate pull request on top of this one once this is agreed upon (hopefully soon!). Regards, Hans The following changes since commit 3799eca51c5be3cd76047a582ac52087373b54b3: media: camss: add missing includes (2018-08-29 14:02:06 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git reqv18 for you to fetch changes up to 1212ceb69544eee3864ec8461bc53ee6ddd87fb0: vivid: add request support (2018-08-30 12:01:28 +0200) Alexandre Courbot (2): Documentation: v4l: document request API videodev2.h: add request_fd field to v4l2_ext_controls Hans Verkuil (32): uapi/linux/media.h: add request API media-request: implement media requests media-request: add media_request_get_by_fd media-request: add media_request_object_find v4l2-device.h: add v4l2_device_supports_requests() helper v4l2-dev: lock req_queue_mutex v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev v4l2-ctrls: prepare internal structs for request API v4l2-ctrls: alloc memory for p_req v4l2-ctrls: use ref in helper instead of ctrl v4l2-ctrls: add core request support v4l2-ctrls: support g/s_ext_ctrls for requests v4l2-ctrls: add v4l2_ctrl_request_hdl_find/put/ctrl_find functions videobuf2-v4l2: move __fill_v4l2_buffer() function videobuf2-v4l2: replace if by switch in __fill_vb2_buffer() vb2: store userspace data in vb2_v4l2_buffer davinci_vpfe: remove bogus vb2->state check vb2: drop VB2_BUF_STATE_PREPARED, use bool prepared/synced instead videodev2.h: Add request_fd field to v4l2_buffer vb2: add init_buffer buffer op videobuf2-core: embed media_request_object videobuf2-core: integrate with media requests videobuf2-v4l2: integrate with media requests videobuf2-core: add request helper functions videobuf2-v4l2: add vb2_request_queue/validate helpers videobuf2-core: add uses_requests/qbuf flags videobuf2-v4l2: refuse qbuf if queue uses requests or vv. v4l2-mem2mem: add vb2_m2m_request_queue vim2m: use workqueue vim2m: support requests vivid: add mc vivid: add request support Sakari Ailus (1): media: doc: Add media-request.h header to documentation build Documentation/media/kapi/mc-core.rst | 2 + Documentation/media/uapi/mediactl/media-controller.rst | 1 + Documentation/media/uapi/mediactl/media-funcs.rst | 6 + Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst | 65 + Documentation/media/uapi/mediactl/media-request-ioc-queue.rst | 82 ++ Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst | 51 Documentation/media/uapi/mediactl/request-api.rst | 245 ++ Documentation/media/uapi/mediactl/request-func-close.rst | 48 Documentation/media/uapi/mediactl/request-func-ioctl.rst | 67 + Documentation/media/uapi/mediactl/request-func-poll.rst| 77 ++ Documentation/media/uapi/v4l/buffer.rst| 21 +- Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst| 53 +++- Documentation/media/uapi/v4l/vidioc-qbuf.rst | 32 ++- Documentation/media/videodev2.h.rst.exceptions | 1 + drivers/media/Makefile | 3 +- drivers/media/common/videobuf2/videobuf2-core.c| 262 +++ drivers/media/common/videobuf2/videobuf2-v4l2.c| 508 + drivers/media/dvb-core/dvb_vb2.c | 5 +- drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +- drivers/media/media-device.c | 24 +- drivers/media/media-request.c | 489 drivers/media/pci/bt8xx/bttv-driver.c | 2 +- drivers/media/pci/cx23885/cx23885-417.c| 2 +- drivers/media/pci/cx88/cx88-blackbird.c| 2 +- drivers/media/pci/cx88/cx88-video.c| 2 +- drivers/media/pci/saa7134/saa7134-empress.c| 4 +- drivers/media/pci/saa7134/saa7134-video.c | 2 +- drivers/media/platform/exynos4-is/fimc-capture.c | 2 +- drivers/media/platform/omap3isp/ispvideo.c | 4 +- drivers/media/platform/rcar-vin/rcar-core.c| 2 +- drivers/media/platform/rcar_drif.c | 2 +-
[PATCH for v4.19] staging/media/mt9t031/Kconfig: remove bogus entry
The 'config SOC_CAMERA_IMX074' is a copy-and-paste error and should be removed. This Kconfig is for mt9t031 only. Signed-off-by: Hans Verkuil --- diff --git a/drivers/staging/media/mt9t031/Kconfig b/drivers/staging/media/mt9t031/Kconfig index f48e06a03cdb..9a58aaf72edd 100644 --- a/drivers/staging/media/mt9t031/Kconfig +++ b/drivers/staging/media/mt9t031/Kconfig @@ -1,9 +1,3 @@ -config SOC_CAMERA_IMX074 - tristate "imx074 support (DEPRECATED)" - depends on SOC_CAMERA && I2C - help - This driver supports IMX074 cameras from Sony - config SOC_CAMERA_MT9T031 tristate "mt9t031 support (DEPRECATED)" depends on SOC_CAMERA && I2C
Re: [PATCHv2 09/10] media-request: EPERM -> EACCES
Hi Hans, Thanks a lot for working on this! On Tue, Aug 28, 2018 at 03:49:10PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > If requests are not supported by the driver, then return EACCES, not > EPERM. This is consistent with the error that an invalid request_fd will > give, and if requests are not supported, then all request_fd values are > invalid. > > Signed-off-by: Hans Verkuil > --- > Documentation/media/uapi/v4l/buffer.rst | 2 +- > .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 9 - > Documentation/media/uapi/v4l/vidioc-qbuf.rst | 15 +-- > drivers/media/media-request.c | 4 ++-- > 4 files changed, 16 insertions(+), 14 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/buffer.rst > b/Documentation/media/uapi/v4l/buffer.rst > index 1865cd5b9d3c..58a6d7d336e6 100644 > --- a/Documentation/media/uapi/v4l/buffer.rst > +++ b/Documentation/media/uapi/v4l/buffer.rst > @@ -314,7 +314,7 @@ struct v4l2_buffer > :ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. > Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls > other than :ref:`VIDIOC_QBUF `. > - If the device does not support requests, then ``EPERM`` will be > returned. > + If the device does not support requests, then ``EACCES`` will be > returned. > If requests are supported but an invalid request file descriptor is > given, then ``EINVAL`` will be returned. > > diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > index ad8908ce3095..54a999df5aec 100644 > --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst > @@ -100,7 +100,7 @@ file descriptor and ``which`` is set to > ``V4L2_CTRL_WHICH_REQUEST_VAL``, > then the controls are not applied immediately when calling > :ref:`VIDIOC_S_EXT_CTRLS `, but instead are applied by > the driver for the buffer associated with the same request. > -If the device does not support requests, then ``EPERM`` will be returned. > +If the device does not support requests, then ``EACCES`` will be returned. > If requests are supported but an invalid request file descriptor is given, > then ``EINVAL`` will be returned. > > @@ -233,7 +233,7 @@ still cause this situation. > these controls have to be retrieved from a request or tried/set for > a request. In the latter case the ``request_fd`` field contains the > file descriptor of the request that should be used. If the device > - does not support requests, then ``EPERM`` will be returned. > + does not support requests, then ``EACCES`` will be returned. > > .. note:: > > @@ -299,7 +299,7 @@ still cause this situation. >- ``request_fd`` >- File descriptor of the request to be used by this operation. Only > valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``. > - If the device does not support requests, then ``EPERM`` will be > returned. > + If the device does not support requests, then ``EACCES`` will be > returned. > If requests are supported but an invalid request file descriptor is > given, then ``EINVAL`` will be returned. > * - __u32 > @@ -408,6 +408,5 @@ EACCES > control, or to get a control from a request that has not yet been > completed. > > -EPERM -EACCES here, too? > -The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the > +Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the > device does not support requests. > diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst > b/Documentation/media/uapi/v4l/vidioc-qbuf.rst > index 7bff69c15452..a2f4ac0b0ba1 100644 > --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst > +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst > @@ -104,7 +104,7 @@ in use. Setting it means that the buffer will not be > passed to the driver > until the request itself is queued. Also, the driver will apply any > settings associated with the request for this buffer. This field will > be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. > -If the device does not support requests, then ``EPERM`` will be returned. > +If the device does not support requests, then ``EACCES`` will be returned. > If requests are supported but an invalid request file descriptor is given, > then ``EINVAL`` will be returned. > > @@ -175,9 +175,12 @@ EPIPE > codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already > dequeued and no new buffers are expected to become available. > > -EPERM > +EACCES > The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not > -support requests. Or the first buffer was queued via a request, but > -the application now tries to queue it directly, or vice versa (it is > -not permitted to mix the two APIs). Or an attempt is made to queue a > -
[GIT PULL FOR v4.20] vicodec improvements
Various vicodec improvements that make it more useful and easier to
re-use in userspace applications like v4l2-ctl and qvidcap.
- add support for quantization parameters
- support many more pixel formats
- code simplifications
- rename source and use proper prefixes for the codec: this makes it
independent from the vicodec driver and easier to reuse in userspace
(similar to what we do for the v4l2-tpg code).
- split off the v4l2 'frontend' code for the FWHT codec into its own
source for easier re-use elsewhere (i.e. v4l2-ctl/qvidcap).
- fix out-of-range values when decoding.
I made a v4l-utils branch that uses the FWHT codec to compress video
when streaming over the network:
https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=qvidcap
Regards,
Hans
The following changes since commit 3799eca51c5be3cd76047a582ac52087373b54b3:
media: camss: add missing includes (2018-08-29 14:02:06 -0400)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git vicodec
for you to fetch changes up to a12ff4f22c26492ee38dc27fe04a2f90aeb98d8b:
vicodec: fix out-of-range values when decoding (2018-08-30 10:35:18 +0200)
Hans Verkuil (8):
vicodec: add QP controls
vicodec: add support for more pixel formats
vicodec: simplify flags handling
vicodec: simplify blocktype checking
vicodec: improve handling of uncompressable planes
vicodec: rename and use proper fwht prefix for codec
vicodec: split off v4l2 specific parts for the codec
vicodec: fix out-of-range values when decoding
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 2 +-
drivers/media/platform/vicodec/Makefile | 2 +-
drivers/media/platform/vicodec/{vicodec-codec.c => codec-fwht.c} | 158
+
drivers/media/platform/vicodec/{vicodec-codec.h => codec-fwht.h} | 80 +++
drivers/media/platform/vicodec/codec-v4l2-fwht.c | 325
+
drivers/media/platform/vicodec/codec-v4l2-fwht.h | 50
drivers/media/platform/vicodec/vicodec-core.c| 483
--
7 files changed, 731 insertions(+), 369 deletions(-)
rename drivers/media/platform/vicodec/{vicodec-codec.c => codec-fwht.c} (84%)
rename drivers/media/platform/vicodec/{vicodec-codec.h => codec-fwht.h} (64%)
create mode 100644 drivers/media/platform/vicodec/codec-v4l2-fwht.c
create mode 100644 drivers/media/platform/vicodec/codec-v4l2-fwht.h
Re: [PATCH 03/14] staging: media: tegra-vde: Prepare for interlacing support
On Mon, Aug 13, 2018 at 04:50:16PM +0200, Thierry Reding wrote: > static void tegra_vde_setup_iram_tables(struct tegra_vde *vde, > + unsigned int num_ref_pics, > struct video_frame *dpb_frames, > unsigned int ref_frames_nb, > unsigned int with_earlier_poc_nb) > @@ -251,13 +260,17 @@ static void tegra_vde_setup_iram_tables(struct > tegra_vde *vde, > u32 value, aux_addr; > int with_later_poc_nb; > unsigned int i, k; > + size_t size; > + > + size = num_ref_pics * 4 * 8; > + memset(vde->iram, 0, size); I can't get behind the magical size calculation... :( regards, dan carpenter
Re: [RFC 1/1] v4l: samsung, ov9650: Rely on V4L2-set sub-device names
On 08/29/2018 12:58 PM, Sakari Ailus wrote: > v4l2_i2c_subdev_init() sets the name of the sub-devices (as well as > entities) to what is fairly certainly known to be unique in the system, > even if there were more devices of the same kind. > > These drivers (m5mols, noon010pc30, ov9650, s5c73m3, s5k4ecgx, s5k6aa) set > the name to the name of the driver or the module while omitting the > device's I²C address and bus, leaving the devices with a static name and > effectively limiting the number of such devices in a media device to 1. > > Address this by using the name set by the V4L2 framework. > > Signed-off-by: Sakari Ailus If Samsung agrees to fix this, then you can add my: Acked-by: Hans Verkuil I think it depends a bit on whether these sensors are for in-house Samsung use only, or if anyone can buy them and use in products. In the latter case I am in favor of fixing this, but if it is in-house only, then I don't care that much. Although I would like to see a patch adding comments to these drivers that warn of this complication (to avoid people using code from these drivers as a template). Regards, Hans > --- > Hi, > > I'm a bit uncertain about this one. I discussed the matter with Hans and > his view was this is a bug (I don't disagree), but this bug affects uAPI. > Also these devices tend to be a few years old and might not see much use > in newer devices, so why bother? The naming convention musn't be copied to > newer drivers though. > > Any opinions? > > This patch depends on my non-RFC set I just posted, this patch in particular: > > https://patchwork.linuxtv.org/patch/51788/> > > drivers/media/i2c/m5mols/m5mols_core.c | 1 - > drivers/media/i2c/noon010pc30.c | 1 - > drivers/media/i2c/ov9650.c | 1 - > drivers/media/i2c/s5c73m3/s5c73m3-core.c | 4 ++-- > drivers/media/i2c/s5k4ecgx.c | 1 - > drivers/media/i2c/s5k6aa.c | 1 - > 6 files changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/i2c/m5mols/m5mols_core.c > b/drivers/media/i2c/m5mols/m5mols_core.c > index 12e79f9e32d5..320e79b63555 100644 > --- a/drivers/media/i2c/m5mols/m5mols_core.c > +++ b/drivers/media/i2c/m5mols/m5mols_core.c > @@ -987,7 +987,6 @@ static int m5mols_probe(struct i2c_client *client, > > sd = >sd; > v4l2_i2c_subdev_init(sd, client, _ops); > - strlcpy(sd->name, MODULE_NAME, sizeof(sd->name)); > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > > sd->internal_ops = _subdev_internal_ops; > diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c > index 88c498ad45df..0629bc138fbc 100644 > --- a/drivers/media/i2c/noon010pc30.c > +++ b/drivers/media/i2c/noon010pc30.c > @@ -720,7 +720,6 @@ static int noon010_probe(struct i2c_client *client, > mutex_init(>lock); > sd = >sd; > v4l2_i2c_subdev_init(sd, client, _ops); > - strlcpy(sd->name, MODULE_NAME, sizeof(sd->name)); > > sd->internal_ops = _subdev_internal_ops; > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c > index 5bea31cd41aa..7e116eb415e5 100644 > --- a/drivers/media/i2c/ov9650.c > +++ b/drivers/media/i2c/ov9650.c > @@ -1546,7 +1546,6 @@ static int ov965x_probe(struct i2c_client *client, > > sd = >sd; > v4l2_i2c_subdev_init(sd, client, _subdev_ops); > - strlcpy(sd->name, DRIVER_NAME, sizeof(sd->name)); > > sd->internal_ops = _sd_internal_ops; > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE | > diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > index ce196b60f917..64212551524e 100644 > --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > @@ -1683,7 +1683,7 @@ static int s5c73m3_probe(struct i2c_client *client, > v4l2_subdev_init(sd, _subdev_ops); > sd->owner = client->dev.driver->owner; > v4l2_set_subdevdata(sd, state); > - strlcpy(sd->name, "S5C73M3", sizeof(sd->name)); > + v4l2_i2c_subdev_set_name(sd, client, NULL, NULL); > > sd->internal_ops = _internal_ops; > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > @@ -1698,7 +1698,7 @@ static int s5c73m3_probe(struct i2c_client *client, > return ret; > > v4l2_i2c_subdev_init(oif_sd, client, _subdev_ops); > - strcpy(oif_sd->name, "S5C73M3-OIF"); > + v4l2_i2c_subdev_set_name(sd, client, NULL, "-OIF"); > > oif_sd->internal_ops = _internal_ops; > oif_sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c > index 6ebcf254989a..8aaf5ad26826 100644 > --- a/drivers/media/i2c/s5k4ecgx.c > +++ b/drivers/media/i2c/s5k4ecgx.c > @@ -954,7 +954,6 @@ static int s5k4ecgx_probe(struct i2c_client *client, > sd = >sd; > /* Registering subdev */ > v4l2_i2c_subdev_init(sd, client, _ops); > - strlcpy(sd->name,
Re: [PATCH 3/3] sr030pc30: Remove redundant setting of sub-device name
On 08/29/2018 12:52 PM, Sakari Ailus wrote: > The sub-device name is set right after in v4l2_i2c_subdev_init(). Remove > the redundant strcpy() call. > > Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Thanks! Hans > --- > drivers/media/i2c/sr030pc30.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/media/i2c/sr030pc30.c b/drivers/media/i2c/sr030pc30.c > index 2a4882cddc51..3d3fb1cda28c 100644 > --- a/drivers/media/i2c/sr030pc30.c > +++ b/drivers/media/i2c/sr030pc30.c > @@ -703,7 +703,6 @@ static int sr030pc30_probe(struct i2c_client *client, > return -ENOMEM; > > sd = >sd; > - strcpy(sd->name, MODULE_NAME); > info->pdata = client->dev.platform_data; > > v4l2_i2c_subdev_init(sd, client, _ops); >
Re: [PATCH 1/3] v4l: subdev: Add a function to set an I²C sub-device's name
On 08/29/2018 12:52 PM, Sakari Ailus wrote:
> v4l2_i2c_subdev_set_name() can be used to assign a name to a sub-device.
> This way uniform names can be formed easily without having to resort to
> things such as snprintf in drivers.
>
> Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/v4l2-core/v4l2-common.c | 18 ++
> include/media/v4l2-common.h | 12
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c
> index b518b92d6d96..9c48b90b4ae8 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -109,6 +109,19 @@ EXPORT_SYMBOL(v4l2_ctrl_query_fill);
>
> #if IS_ENABLED(CONFIG_I2C)
>
> +void v4l2_i2c_subdev_set_name(struct v4l2_subdev *sd, struct i2c_client
> *client,
> + const char *devname, const char *postfix)
> +{
> + if (!devname)
> + devname = client->dev.driver->name;
> + if (!postfix)
> + postfix = "";
> +
> + snprintf(sd->name, sizeof(sd->name), "%s%s %d-%04x", devname, postfix,
> + i2c_adapter_id(client->adapter), client->addr);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_set_name);
> +
> void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client,
> const struct v4l2_subdev_ops *ops)
> {
> @@ -120,10 +133,7 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct
> i2c_client *client,
> /* i2c_client and v4l2_subdev point to one another */
> v4l2_set_subdevdata(sd, client);
> i2c_set_clientdata(client, sd);
> - /* initialize name */
> - snprintf(sd->name, sizeof(sd->name), "%s %d-%04x",
> - client->dev.driver->name, i2c_adapter_id(client->adapter),
> - client->addr);
> + v4l2_i2c_subdev_set_name(sd, client, NULL, NULL);
> }
> EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
>
> diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> index cdc87ec61e54..bd880a909ecf 100644
> --- a/include/media/v4l2-common.h
> +++ b/include/media/v4l2-common.h
> @@ -155,6 +155,18 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct
> v4l2_device *v4l2_dev,
> const unsigned short *probe_addrs);
>
> /**
> + * v4l2_i2c_subdev_set_name - Set name for an I²C sub-device
> + *
> + * @sd: pointer to v4l2_subdev
> + * @client: pointer to struct i2c_client
> + * @devname: the name of the device; if NULL, the I²C device's name will be
> used
> + * @postfix: sub-device specific string to put right after the I²C device
> name;
> + *may be NULL
> + */
> +void v4l2_i2c_subdev_set_name(struct v4l2_subdev *sd, struct i2c_client
> *client,
> + const char *devname, const char *postfix);
> +
> +/**
> * v4l2_i2c_subdev_init - Initializes a v4l2_subdev with data from
> * an i2c_client struct.
> *
>
Re: [PATCH 2/3] smiapp: Use v4l2_i2c_subdev_set_name
On 08/29/2018 12:52 PM, Sakari Ailus wrote: > Use v4l2_i2c_subdev_set_name() to set the name of the smiapp driver's > sub-devices. There is no functional change. > > Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Thanks! Hans > --- > drivers/media/i2c/smiapp/smiapp-core.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c > b/drivers/media/i2c/smiapp/smiapp-core.c > index 1236683da8f7..99f3b295ae3c 100644 > --- a/drivers/media/i2c/smiapp/smiapp-core.c > +++ b/drivers/media/i2c/smiapp/smiapp-core.c > @@ -2617,9 +2617,7 @@ static void smiapp_create_subdev(struct smiapp_sensor > *sensor, > ssd->npads = num_pads; > ssd->source_pad = num_pads - 1; > > - snprintf(ssd->sd.name, > - sizeof(ssd->sd.name), "%s %s %d-%4.4x", sensor->minfo.name, > - name, i2c_adapter_id(client->adapter), client->addr); > + v4l2_i2c_subdev_set_name(>sd, client, sensor->minfo.name, name); > > smiapp_get_native_size(ssd, >sink_fmt); > > @@ -3064,9 +3062,9 @@ static int smiapp_probe(struct i2c_client *client, > if (sensor->minfo.smiapp_profile == SMIAPP_PROFILE_0) > sensor->pll.flags |= SMIAPP_PLL_FLAG_NO_OP_CLOCKS; > > - smiapp_create_subdev(sensor, sensor->scaler, "scaler", 2); > - smiapp_create_subdev(sensor, sensor->binner, "binner", 2); > - smiapp_create_subdev(sensor, sensor->pixel_array, "pixel_array", 1); > + smiapp_create_subdev(sensor, sensor->scaler, " scaler", 2); > + smiapp_create_subdev(sensor, sensor->binner, " binner", 2); > + smiapp_create_subdev(sensor, sensor->pixel_array, " pixel_array", 1); > > dev_dbg(>dev, "profile %d\n", sensor->minfo.smiapp_profile); > >
Re: [RFC] Request API and V4L2 capabilities
On 08/29/2018 06:30 AM, Tomasz Figa wrote: > On Fri, Aug 24, 2018 at 2:33 AM Nicolas Dufresne wrote: >> >> Le jeudi 23 août 2018 à 10:05 +0200, Paul Kocialkowski a écrit : >>> Hi, >>> >>> On Wed, 2018-08-22 at 14:33 -0300, Ezequiel Garcia wrote: On Wed, 2018-08-22 at 16:10 +0200, Paul Kocialkowski wrote: > Hi, > > On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote: >> Hi Hans, Paul, >> >> On Mon, Aug 6, 2018 at 6:29 PM Paul Kocialkowski >> wrote: >>> >>> On Mon, 2018-08-06 at 11:23 +0200, Hans Verkuil wrote: On 08/06/2018 11:13 AM, Paul Kocialkowski wrote: > Hi, > > On Mon, 2018-08-06 at 10:32 +0200, Hans Verkuil wrote: >> On 08/06/2018 10:16 AM, Paul Kocialkowski wrote: >>> On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: Regarding point 3: I think this should be documented next to the pixel format. I.e. the MPEG-2 Slice format used by the stateless cedrus codec requires the request API and that two MPEG-2 controls (slice params and quantization matrices) must be present in each request. I am not sure a control flag (e.g. V4L2_CTRL_FLAG_REQUIRED_IN_REQ) is needed here. It's really implied by the fact that you use a stateless codec. It doesn't help generic applications like v4l2-ctl or qv4l2 either since in order to support stateless codecs they will have to know about the details of these controls anyway. So I am inclined to say that it is not necessary to expose this information in the API, but it has to be documented together with the pixel format documentation. >>> >>> I think this is affected by considerations about codec profile/level >>> support. More specifically, some controls will only be required for >>> supporting advanced codec profiles/levels, so they can only be >>> explicitly marked with appropriate flags by the driver when the >>> target >>> profile/level is known. And I don't think it would be sane for >>> userspace >>> to explicitly set what profile/level it's aiming at. As a result, I >>> don't think we can explicitly mark controls as required or optional. >> >> I'm not sure this is entirely true. The hardware may need to be >> explicitly told what profile the video is. It may even not be the >> hardware, but the driver itself too, given that the profile may imply >> the CAPTURE pixel format, e.g. for VP9 profiles: >> >> profile 0 >> color depth: 8 bit/sample, chroma subsampling: 4:2:0 >> profile 1 >> color depth: 8 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 >> profile 2 >> color depth: 10–12 bit, chroma subsampling: 4:2:0 >> profile 3 >> color depth: 10–12 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 >> >> (reference: https://en.wikipedia.org/wiki/VP9#Profiles) > > I think it would be fair to expect userspace to select the right > destination format (and maybe have the driver error if there's a > mismatch with the meta-data) instead of having the driver somewhat > expose what format should be used. > > But maybe this would be an API violation, since all the enumerated > formats are probably supposed to be selectable? > > We could also look at it the other way round and consider that selecting > an exposed format is always legit, but that it implies passing a > bitstream that matches it or the driver will error (because of an > invalid bitstream passed, not because of a "wrong" selected format). > The API requires the user to negotiate via TRY_FMT/S_FMT. The driver usually does not return error on invalid formats, and simply return a format it can work with. I think the kernel-user contract has to guarantee if the driver accepted a given format, it won't fail to encoder or decode. >>> >>> Well, the issue here is that in order to correctly enumerate the >>> formats, the driver needs to be aware of: >>> 1. in what destination format the bitstream data is decoded to; >> >> This is covered by the state-full specification patch if I remember >> correctly. So the driver, if it's a multi-format, will first return all >> possible formats, and later on, will return the proper subset. So let's >> take an encoder, after setting the capture format, the enumeration of >> the raw formats could then be limited to what is supported for this >> output. For an H264 encoder, what could also affect this list is the >> profile that being set. For decoder, this list is reduced after >> sufficient headers information has been given. Though for decoder it's >> also limited case, since it only apply to
