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: Thu Nov 16 05:00:24 CET 2017
media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10
media_build git
The pnp_irq() function returns -1 if an error occurs.
pnp_irq() error checking for zero is not correct.
Signed-off-by: Arvind Yadav
---
drivers/media/rc/winbond-cir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir
On Wed, Nov 15, 2017 at 4:28 PM, Mauro Carvalho Chehab
wrote:
>
> PS.: This time, there is a merge from staging tree, from the same commit
> you pulled on your tree, in order to solve a conflict at the
> atomisp driver, as reported by Stephen Rothwell.
Please don't do that.
I got confl
On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote:
> On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote:
> > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
> >> Add support for the TDA1997x HDMI receivers.
> >>
> >> Cc: Hans Verkuil
> >> Signed-off-by: Tim Harvey
> >> ---
>
Hi, all
I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver
version 4 on 13th/Oct.
Are there any comments, advices and review results for them?
I'd like to get better understanding of current review status for our codes.
Regards,
Takiguchi
Hello,
This small RFC is an attempt to handle the race condition that exists between
device access and device unbind.
Devices can be unbound from drivers in three different ways:
- When the driver module is unloaded, the driver is unregistered and unbound
from all devices it was bound to. As m
To avoid races between device access and unplug, call the
video_device_unplug() function in the platform driver remove handler.
This will unsure that all device access completes before the remove
handler proceeds to free resources.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/rcar-
Device unplug being asynchronous, it naturally races with operations
performed by userspace through ioctls or other file operations on video
device nodes.
This leads to potential access to freed memory or to other resources
during device access if unplug occurs during device access. To solve
this,
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
tags/media/v4.15-1
For:
- Documentation for digital TV (both kAPI and uAPI) are now in sync with
the implementation (except for legacy/deprecated ioctls). This is a major
step, as there were alw
Hi Niklas,
On Thursday, 16 November 2017 01:34:33 EET Niklas Söderlund wrote:
> On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote:
> > The rvin_dev data structure contains driver private data for an instance
> > of the VIN. It is allocated dynamically at probe time, and must be freed
> > once a
Hi Laurent,
Thanks for your patch.
On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote:
> The rvin_dev data structure contains driver private data for an instance
> of the VIN. It is allocated dynamically at probe time, and must be freed
> once all users are gone.
>
> The structure is currently
Hi Rob,
Thanks for your feedback.
On 2017-11-15 13:59:36 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > are located between the video sources (CSI-2 transmitters) and th
Hi Rob,
Thanks for your feedback, much appreciated!
On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> >
> > There is a need to add a custom property '
The rvin_dev data structure contains driver private data for an instance
of the VIN. It is allocated dynamically at probe time, and must be freed
once all users are gone.
The structure is currently allocated with devm_kzalloc(), which results
in memory being freed when the device is unbound. If a
On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This info
On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
>
> Each CSI-2 device is connected
Todor et all,
Any hint on how to tackle this?
I can contribute patches, but I'd like to understand what the idea is.
Thanks,
Daniel
On Thursday, October 26, 2017 06:11 PM, Daniel Mack wrote:
> Hi Todor,
>
> When using the camss driver trough one of its /dev/videoX device nodes,
> application
Hi Jacopo,
On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi wrote:
> On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>> wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
>> > @@ -0,0 +1,
On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote:
> On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil
>> Signed-off-by: Tim Harvey
>> ---
>> v3:
>> - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>> - fixed missing b
Hi Geert,
On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC devicetree folks
Yeah, sorry I forgot them. Sorry about this and thanks for adding the
address back!
>
> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
> wrote:
> > Add bindings documentation for R
videobuf2 core reports an error when not all buffers have been returned
to the framework:
drivers/media/v4l2-core/videobuf2-core.c:1651
WARN_ON(atomic_read(&q->owned_by_drv_count))
Fix this returning all buffers currently in capture queue.
Signed-off-by: Jacopo Mondi
---
I know I'm working to
From: Gustavo Padovan
Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers can't be queued to the
driver before its fences signal. And a buffer can't be queue to the driver
out of the order they were queued from userspace. That mean
From: Gustavo Padovan
ordered_in_driver is used to optimize the use of explicit synchronization
when the driver guarantees ordering we can use the same fence context for
out-fences. In this case userspace will know that the buffers won't be
signaling out of order. vivid queues are already ordered
From: Javier Martinez Canillas
Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.
v2: - use fence context provided by the caller in vb2_fence_alloc()
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Gustavo
From: Gustavo Padovan
Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.
v3:
- Do not hold yet another ref to the out_fence (Brian Starkey)
v2: - change it to reflect fd_install at DQEVENT
- add fence context for out-fences
Signed-off-by: Gustavo Padovan
From: Gustavo Padovan
Add section to VIDIOC_QBUF about it
v4:
- Document ordering behavior for in-fences
- Document V4L2_CAP_ORDERED capability
- Remove doc about OUT_FENCE event
- Document immediate return of out-fence in QBUF
v3:
- make the out_fence re
From: Gustavo Padovan
When using explicit synchronization userspace needs to know if
the queue can deliver everything back in the same order, so we added
a new capability that drivers can use to report that they are capable
of keeping ordering.
In videobuf2 core when using fences we also make su
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to userspace on the fence_fd field as a
return arg for the QBUF call.
The fence is signaled on buffer_done(), when the job on the buffer is
finished.
With out-fences we do no
From: Gustavo Padovan
vivid guarantees the ordering of buffer when processing then, so add the
V4L2_CAP_ORDERED capability to inform userspace of that.
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/vivid/vivid-core.c | 19 ---
1 file changed, 12 insertions(+), 7 del
From: Gustavo Padovan
To support explicit synchronization we need to run all operations that can
fail before we queue the buffer to the driver. With fences the queueing
will be delayed if the fence is not signaled yet and it will be better if
such callback do not fail.
For that we move the vb2_s
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2
From: Gustavo Padovan
We use ordered_in_driver property to optimize for the case where
the driver can deliver the buffers in an ordered fashion. When it
is ordered we can use the same fence context for all fences, but
when it is not we need to a new context for each out-fence.
So the ordered_in_
From: Gustavo Padovan
Hi,
After the comments received in the last patchset[1] and
during the media summit [2] here is the new and improved version
of the patchset. The implementation is simpler, smaller and cover
a lot more cases.
If you look to the last patchset I got rid of a few things, the
Hi,
I just noticed I made a small mistake in this patch, see bellow. I will
send out a new version in a few days with this fix included but I don't
want to spam the list too much so I give it a few more days if there is
any other feedback.
On 2017-11-11 01:25:26 +0100, Niklas Söderlund wrote:
On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
> Add support for the TDA1997x HDMI receivers.
>
> Cc: Hans Verkuil
> Signed-off-by: Tim Harvey
> ---
> v3:
> - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
> - fixed missing break
> - use only hdmi_infoframe_log for infoframe logging
>
When matching and registering a sub-device from a sub-notifier use the
v4l2_device from the root parent notifier. Using the v4l2_dev stored in
the sub-notifier itself is incorrect as it might not be set.
This can be demonstrated by unbinding and rebinding the adv748x driver
and observing that it f
Hi Tomasz,
2017-11-15 16:03 GMT+08:00 Tomasz Figa :
> Hi Jacob,
>
> Thanks for sending the series!
>
> On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen wrote:
>> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399
>> SoC.
>>
>> TODO:
>> - Thomas is rewriting the binding code
This makes it possible to poll a local device.
Getting the fd is preferrable to adding a dvb_dev_poll() function,
because we can poll several fds together in an event-based program.
This is not implemented for remote devices, as polling a remote fd
does not make sense.
We could instead return the
Hi Sakari,
thanks for review!
On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> Could you remove the original driver and send the patch using git
> send-email -C ? That way a single patch would address converting it to a
> proper V4L2 driver as well as move it to th
Hi Jacopo,
On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
wrote:
> Rename CEU clock to match the new platform driver name used in Migo-R.
>
> There are no other sh7722 based devices Migo-R apart, so we can safely
> rename this.
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/sh/kernel/cpu/sh4a/clo
Hi Jacopo,
CC devicetree folks
On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi
> ---
> .../devicetree/bindings/media/renesas,ceu.txt | 87
> ++
> 1 file changed,
Hi Jacopo,
Could you remove the original driver and send the patch using git
send-email -C ? That way a single patch would address converting it to a
proper V4L2 driver as well as move it to the correct location. The changes
would be easier to review that way since then, well, it'd be easier to se
Hi Jacopo,
On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> Add renesas-ceu header file.
>
> Do not remove the existing sh_mobile_ceu.h one as long as the original
> driver does not go away.
Hmm. This isn't really not about not removing a file but adding a new one.
Do you really n
Hi Jacopo,
Thanks for the patchset. Please see my comments below.
On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi
> ---
> .../devicetree/bindings/media/renesas,ceu.txt | 87
>
Hi Kieran,
> I think it's easier to see updated patches if they are posted as a new thread,
> with an increased version number. [PATCH v2], [PATCH v3] etc...
>
> Not a problem now - but might help your updated patches get seen next time.
I will keep that in mind for next time. :)
> Looks like my
Current implementation of __v4l2_async_notifier_parse_fwnode_endpoints()
checks first whether subdev_count >= subdev_max and only then whether
the port being parsed matches the given port index. This triggers an
error in otherwise valid cases of skipping ports that do not match.
Fix this by moving
Hi Edgar,
Thanks for addressing my concerns in this updated patch.
On 12/10/17 08:54, Edgar Thier wrote:
>
> Use flags the device exposes for UVC controls.
> This allows the device to define which property flags are set.
>
> Since some cameras offer auto-adjustments for properties (e.g. auto-ga
Hi Edgar,
On 15/11/17 08:11, Edgar Thier wrote:
> Hi,
>
> I was wondering if there are any problems with my latest patch or if it
> simply slipped through.
Slipped though in high mail volumes :)
I think it's easier to see updated patches if they are posted as a new thread,
with an increased ve
Hello Dear...
I know that this message will come to you as a surprise. I hoped that
you will not expose or betray this trust and confident that I am about
to repose on you, my name is M, Shakour Rosarita. I am 19 years old
Girl, female, from Tartu Syria, (never married) 61 kg, white in
complexion,
---
lib/include/libdvbv5/dvb-dev.h | 3 ++-
lib/include/libdvbv5/dvb-fe.h | 9 +++--
lib/include/libdvbv5/dvb-log.h | 33 +
lib/libdvbv5/dvb-dev.c | 3 ++-
lib/libdvbv5/dvb-fe.c | 15 ---
lib/libdvbv5/dvb-log.c | 3 ++-
---
utils/dvb/dvbv5-daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils/dvb/dvbv5-daemon.c b/utils/dvb/dvbv5-daemon.c
index 58485ac6..711694e0 100644
--- a/utils/dvb/dvbv5-daemon.c
+++ b/utils/dvb/dvbv5-daemon.c
@@ -570,7 +570,7 @@ void dvb_remote_log(void *priv, int
Hi Jacopo,
A couple of minor language fixups inline.
On 15/11/17 10:55, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi
> ---
> .../devicetree/bindings/media/renesas,ceu.txt | 87
> ++
> 1 file ch
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system
This commit does not remove the original soc_camera based driver.
Signed-off-by: Jacopo Mondi
---
drivers
Add driver for Renesas Capture Engine Unit (CEU).
The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).
This driver aims to replace the soc_camera based sh_mobile_ceu one.
Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.
T
Add bindings documentation for Renesas Capture Engine Unit (CEU).
Signed-off-by: Jacopo Mondi
---
.../devicetree/bindings/media/renesas,ceu.txt | 87 ++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
diff --g
Add renesas-ceu header file.
Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.
Signed-off-by: Jacopo Mondi
---
include/media/drv-intf/renesas-ceu.h | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 include/media/drv-
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.
Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers.
Also, memory for
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system
This commit does not remove the original soc_camera based driver.
Signed-off-by: Jacopo Mondi
---
drivers
Add Capture Engine Unit (CEU) node to device tree.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 4ed12a4..683d459 100644
---
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov772x.c | 1124
1 file changed, 1124 insertions(+)
create mode 100644
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/tw9910.c | 999 +
1 file changed, 999 insertions(+)
create mode 100644
Hello,
this series implementes a modern V4L2 driver for Renesas Capture Engine
Unit (CEU). CEU is currently supported by the soc_camera based driver
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
The driver supports capturing images in planar formats (NV12/21 and NV16/61)
and non-plan
Rename CEU clock to match the new platform driver name used in Migo-R.
There are no other sh7722 based devices Migo-R apart, so we can safely
rename this.
Signed-off-by: Jacopo Mondi
---
arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/a
This makes it possible to poll a local device.
Getting the fd is preferrable to adding a dvb_dev_poll() function,
because we can poll several fds together in an event-based program.
This is not implemented for remote devices, as polling a remote fd
does not make sense.
We could instead return the
Hi Alexandre,
On 15/11/17 10:38, Alexandre Courbot wrote:
> Hi Hans!
>
> Thanks for the patchset! It looks quite good at first sight, a few comments
> and
> questions follow though.
>
> On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Hi Alexandre,
Hi Hans!
Thanks for the patchset! It looks quite good at first sight, a few comments
and
questions follow though.
On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote:
From: Hans Verkuil
Hi Alexandre,
This is a first implementation of the request API in the
control framework. I
Hi Jacob,
Thanks for sending the series!
On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen wrote:
> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399
> SoC.
>
> TODO:
> - Thomas is rewriting the binding code between isp, phy, sensors, i hope we
> could get suggestions.
>
Hi,
I was wondering if there are any problems with my latest patch or if it simply
slipped through.
Regards,
Edgar
On 10/12/2017 09:54 AM, Edgar Thier wrote:
>
> Use flags the device exposes for UVC controls.
> This allows the device to define which property flags are set.
>
> Since some cam
68 matches
Mail list logo
