On 06/09/2017 06:10 PM, Kevin Hilman wrote:
The davinci VPIF is a single hardware block, but the existing driver
is broken up into a common library (vpif.c), output (vpif_display.c) and
intput (vpif_capture.c).
When migrating to DT, to better model the hardware, and because
registers, interrupts
On Sat, Jun 17, 2017 at 9:00 AM, Zhi, Yong wrote:
> Hi, Andy,
>
>> -Original Message-
>> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
>> Sent: Friday, June 16, 2017 3:59 PM
>> To: Zhi, Yong
>> Cc: Linux Media Mailing List ;
>> sakari.ai...@linux.intel.com; Zheng, Jian Xu ;
>>
Hi, Andy,
> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Friday, June 16, 2017 3:59 PM
> To: Zhi, Yong
> Cc: Linux Media Mailing List ;
> sakari.ai...@linux.intel.com; Zheng, Jian Xu ;
> tf...@chromium.org; Mani, Rajmohan ;
> Toivonen, Tuukka
> Su
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi wrote:
Commit message.
> Signed-off-by: Yong Zhi
> + /* Set Power */
> + r = pm_runtime_get_sync(dev);
> + if (r < 0) {
> + dev_err(dev, "failed to set imgu power\n");
> + pm_runtime_put(dev);
I'm not sur
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi wrote:
Commit message.
> Signed-off-by: Yong Zhi
> +static void writes(void *mem, ssize_t len, void __iomem *reg)
> +{
> + while (len >= 4) {
> + writel(*(u32 *)mem, reg);
> + mem += 4;
> + reg += 4;
> +
On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi wrote:
> A collection of routines that are mainly responsible
> to calculate the acc parameters.
> +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
> + unsigned int divider)
> +{
> + unsign
On Fri, Jun 16, 2017 at 10:49:24AM -0700, Kevin Hilman wrote:
> Sakari Ailus writes:
>
> > Hi Kevin,
> >
> > On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
> >> The davinci VPIF is a single hardware block, but the existing driver
> >> is broken up into a common library (vpif.c), ou
Hi Dave,
(Cc the devicetree list, I missed that earlier. It's DT binding
documentation so that list should be cc'd.)
On Fri, Jun 16, 2017 at 03:40:02PM +0100, Dave Stevenson wrote:
> Hi Sakari
>
> On 16 June 2017 at 10:57, Sakari Ailus wrote:
> > Hi Dave,
> >
> > On Thu, Jun 15, 2017 at 05:15:0
Remove the soc_camera dependencies and move the diver to i2c
Lost features, fortunately not used or not critical on test platform:
- soc_camera power on/off callback - replaced with clock enable/disable
only, no support for platform provided regulators nor power callback,
- soc_camera sense requ
On Fri, Jun 16, 2017 at 07:56:41PM +0200, Janusz Krzysztofik wrote:
> On Friday 16 June 2017 12:16:21 Sakari Ailus wrote:
> > Hi Janusz,
> >
> > Thanks for the patch. A few comments below.
> >
> > On Fri, Jun 16, 2017 at 12:52:43AM +0200, Janusz Krzysztofik wrote:
> > > Remove the soc_camera depe
On Friday 16 June 2017 12:16:21 Sakari Ailus wrote:
> Hi Janusz,
>
> Thanks for the patch. A few comments below.
>
> On Fri, Jun 16, 2017 at 12:52:43AM +0200, Janusz Krzysztofik wrote:
> > Remove the soc_camera dependencies.
> >
> > Lost features, fortunately not used or not critical on test pla
Sakari Ailus writes:
> Hi Kevin,
>
> On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
>> The davinci VPIF is a single hardware block, but the existing driver
>> is broken up into a common library (vpif.c), output (vpif_display.c) and
>> intput (vpif_capture.c).
>>
>> When migrating
Le vendredi 16 juin 2017 à 16:39 +0900, Gustavo Padovan a écrit :
> > From: Gustavo Padovan
>
> For explicit synchronization (and soon for HAL3/Request API) we need
> the v4l2-driver to guarantee the ordering which the buffer were queued
> by userspace. This is already true for many drivers, but
On 16 June 2017 at 17:08, Hans Verkuil wrote:
> On 06/16/2017 05:55 PM, Dave Stevenson wrote:
>>
>> On 16 June 2017 at 15:05, Hans Verkuil wrote:
>>>
>>> On 06/15/17 17:11, Dave Stevenson wrote:
On 15 June 2017 at 15:14, Hans Verkuil wrote:
>
> On 06/15/17 15:38, Dave Stevenson
The Synopsys Designware HDMI RX controller is an HDMI receiver controller that
is responsible to process digital data that comes from a phy. The final result
is a stream of raw video data that can then be connected to a video DMA, for
example, and transfered into RAM so that it can be displayed.
T
This adds support for the Synopsys Designware HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.
Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable chara
Add a entry for Synopsys Designware HDMI Receivers drivers
and phys.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bd..e798040 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11294,6 +
Document the bindings for the Synopsys Designware HDMI RX.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Mark Rutland
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Changes from v2:
- Document edid-phandle property
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.t
This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.
The controller + phy pipeline can then be integrated into a fully
featured system that ca
On 06/16/2017 05:55 PM, Dave Stevenson wrote:
On 16 June 2017 at 15:05, Hans Verkuil wrote:
On 06/15/17 17:11, Dave Stevenson wrote:
On 15 June 2017 at 15:14, Hans Verkuil wrote:
On 06/15/17 15:38, Dave Stevenson wrote:
Hi Hans.
"On 15 June 2017 at 08:12, Hans Verkuil wrote:
Hi Dave,
He
On 06/16/2017 05:52 PM, Jose Abreu wrote:
Hi Hans,
On 16-06-2017 14:44, Hans Verkuil wrote:
+ /* CEC */
+ dw_dev->cec_adap = cec_allocate_adapter(&dw_hdmi_cec_adap_ops,
+ dw_dev, dev_name(dev), CEC_CAP_TRANSMIT |
+ CEC_CAP_PHYS_ADDR
On 16 June 2017 at 15:05, Hans Verkuil wrote:
> On 06/15/17 17:11, Dave Stevenson wrote:
>> On 15 June 2017 at 15:14, Hans Verkuil wrote:
>>> On 06/15/17 15:38, Dave Stevenson wrote:
Hi Hans.
"On 15 June 2017 at 08:12, Hans Verkuil wrote:
> Hi Dave,
>
> Here is a quick
Hi Hans,
On 16-06-2017 14:44, Hans Verkuil wrote:
>
>>>
>>>
+ /* CEC */
+ dw_dev->cec_adap = cec_allocate_adapter(&dw_hdmi_cec_adap_ops,
+ dw_dev, dev_name(dev), CEC_CAP_TRANSMIT |
+ CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS,
>>> Add CEC_CAP_RC
Hi Sakari,
On 06/16/2017 05:14 PM, Sakari Ailus wrote:
The V4L2_BUF_TYPE_META_OUTPUT buffer type complements the metadata buffer
types support for OUTPUT buffers, capture being already supported. This is
intended for similar cases than V4L2_BUF_TYPE_META_CAPTURE but for output
buffers, e.g. devi
On 06/16/2017 05:14 PM, Sakari Ailus wrote:
Document the interface for metadata output, including
V4L2_BUF_TYPE_META_OUTPUT buffer type and V4L2_CAP_META_OUTPUT capability
bits.
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/buffer.rst | 3 +++
Documentation/media/uap
On 06/16/2017 05:14 PM, Sakari Ailus wrote:
The V4L2_BUF_TYPE_META_OUTPUT mirrors the V4L2_BUF_TYPE_META_CAPTURE with
the exception that it is an OUTPUT type. The use case for this is to pass
buffers to the device that are not image data but metadata. The formats,
just as the metadata capture for
Hi Thierry,
Thank you for the patch.
Can you give a use case for resolution change event?
Also plase see inline.
W dniu 12.06.2017 o 19:13, Thierry Escande pisze:
From: henryhsu
This patch adds support for resolution change event to notify clients so
they can prepare correct output buffer.
Hi Thierry,
Thank you for the patch. Please see inline.
W dniu 12.06.2017 o 19:13, Thierry Escande pisze:
From: henryhsu
On Exynos5420, the STREAM_STAT bit raised on the JPGINTST register means
there is a syntax error or an unrecoverable error on compressed file
when ERR_INT_EN is set to 1.
Document the interface for metadata output, including
V4L2_BUF_TYPE_META_OUTPUT buffer type and V4L2_CAP_META_OUTPUT capability
bits.
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/buffer.rst | 3 +++
Documentation/media/uapi/v4l/dev-meta.rst| 32 ++---
The V4L2_BUF_TYPE_META_OUTPUT mirrors the V4L2_BUF_TYPE_META_CAPTURE with
the exception that it is an OUTPUT type. The use case for this is to pass
buffers to the device that are not image data but metadata. The formats,
just as the metadata capture formats, are typically device specific and
highly
The V4L2_BUF_TYPE_META_OUTPUT buffer type complements the metadata buffer
types support for OUTPUT buffers, capture being already supported. This is
intended for similar cases than V4L2_BUF_TYPE_META_CAPTURE but for output
buffers, e.g. device parameters that may be complex and highly
hierarchical
Hi Yong,
On Wed, Jun 14, 2017 at 05:19:26PM -0500, Yong Zhi wrote:
> +int ipu3_v4l2_register(struct imgu_device *dev)
> +{
> + struct ipu3_mem2mem2_device *m2m2 = &dev->mem2mem2;
> + int i, r;
> +
> + /* Initialize miscellaneous variables */
> + m2m2->streaming = false;
> + m2m
Hi Sakari
On 16 June 2017 at 10:57, Sakari Ailus wrote:
> Hi Dave,
>
> On Thu, Jun 15, 2017 at 05:15:04PM +0100, Dave Stevenson wrote:
>> Hi Sakari.
>>
>> Thanks for the review.
>>
>> On 15 June 2017 at 13:59, Sakari Ailus wrote:
>> > Hi Dave,
>> >
>> > Thanks for the set!
>> >
>> > On Wed, Jun
On 06/15/17 17:11, Dave Stevenson wrote:
> On 15 June 2017 at 15:14, Hans Verkuil wrote:
>> On 06/15/17 15:38, Dave Stevenson wrote:
>>> Hi Hans.
>>>
>>> "On 15 June 2017 at 08:12, Hans Verkuil wrote:
Hi Dave,
Here is a quick review of this driver. Once a v2 is posted I'll do a mor
On 06/16/17 15:21, Jose Abreu wrote:
> Hi Hans,
>
>
> On 16-06-2017 13:38, Hans Verkuil wrote:
>> Hi Jose,
>>
>> Just a quick review of the new CEC code:
>
> Thanks!
>
>>
>> On 06/16/17 12:07, Jose Abreu wrote:
>>> This is an initial submission for the Synopsys Designware HDMI RX
>>> Controller
Hi Hans,
On 16-06-2017 13:38, Hans Verkuil wrote:
> Hi Jose,
>
> Just a quick review of the new CEC code:
Thanks!
>
> On 06/16/17 12:07, Jose Abreu wrote:
>> This is an initial submission for the Synopsys Designware HDMI RX
>> Controller Driver. This driver interacts with a phy driver so that
>
The following changes since commit acec3630155763c170c7ae6508cf973355464508:
[media] s3c-camif: fix arguments position in a function call (2017-06-13
14:21:24 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v4.13e
for you to fetch changes up to
Hi!
> > > These types devices aren't directly related to the sensor, but are
> > > nevertheless handled by the smiapp driver due to the relationship of these
> > > component to the main part of the camera module --- the sensor.
> > >
> > > Additionally, for the async sub-device registration to wo
Hi Hans,
On Mon, May 08, 2017 at 04:35:06PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Unfortunately the use of 'type' was inconsistent for multiplanar
> buffer types. Starting with 4.12 both the normal and _MPLANE variants
> are allowed, thus making it possible to write sensible code.
Hi Hans,
Cc Sylwester and Marek as well.
On Mon, May 08, 2017 at 04:35:05PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The type field in struct v4l2_selection is supposed to never use the
> _MPLANE variants. E.g. if the driver supports
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
> then user
Hi Pavel,
On Fri, Jun 16, 2017 at 02:42:42PM +0200, Pavel Machek wrote:
> Hi!
>
> > These types devices aren't directly related to the sensor, but are
> > nevertheless handled by the smiapp driver due to the relationship of these
> > component to the main part of the camera module --- the sensor.
Hi!
> These types devices aren't directly related to the sensor, but are
> nevertheless handled by the smiapp driver due to the relationship of these
> component to the main part of the camera module --- the sensor.
>
> Additionally, for the async sub-device registration to work, the notifier
> c
Hi Jose,
Just a quick review of the new CEC code:
On 06/16/17 12:07, Jose Abreu wrote:
> This is an initial submission for the Synopsys Designware HDMI RX
> Controller Driver. This driver interacts with a phy driver so that
> a communication between them is created and a video pipeline is
> confi
Hi Pavel,
On Fri, Jun 16, 2017 at 02:07:13PM +0200, Pavel Machek wrote:
> Hi!
>
> > These types devices aren't directly related to the sensor, but are
> > nevertheless handled by the smiapp driver due to the relationship of these
> > component to the main part of the camera module --- the sensor.
Hi!
> These types devices aren't directly related to the sensor, but are
> nevertheless handled by the smiapp driver due to the relationship of these
> component to the main part of the camera module --- the sensor.
>
> Additionally, for the async sub-device registration to work, the notifier
> c
On Fri, Jun 16, 2017 at 10:03:41AM +0200, Hans Verkuil wrote:
> On 06/16/2017 12:23 AM, Pavel Machek wrote:
> >
> >Fix compilation of isp.c
> >Signed-off-by: Pavel Machek
> >
> >diff --git a/drivers/media/platform/omap3isp/isp.c
> >b/drivers/media/platform/omap3isp/isp.c
> >index 4ca3fc9..b80debf
Hi Tomasz,
On Mon, Jun 12, 2017 at 06:59:18PM +0900, Tomasz Figa wrote:
> Hi Yong,
>
> Please see my comments inline.
>
> On Wed, Jun 7, 2017 at 10:34 AM, Yong Zhi wrote:
> > This patch adds CIO2 CSI-2 device driver for
> > Intel's IPU3 camera sub-system support.
> >
> > Signed-off-by: Yong Zhi
On 05/12/17 04:42, Minghsiu Tsai wrote:
> From: Daniel Kurtz
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
Please drop this, since this no longer applies to this patch.
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
Are you r
Hi Yong,
Please see my comments inline.
On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote:
> Functions to load and install imgu FW blobs
>
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/ipu3-abi.h| 1572
>
> drivers/media/pci/intel/ipu3/ipu3-css-f
The Synopsys Designware HDMI RX controller is an HDMI receiver controller that
is responsible to process digital data that comes from a phy. The final result
is a stream of raw video data that can then be connected to a video DMA, for
example, and transfered into RAM so that it can be displayed.
T
Add a entry for Synopsys Designware HDMI Receivers drivers
and phys.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bd..e798040 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11294,6 +
This adds support for the Synopsys Designware HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.
Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable chara
This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.
The controller + phy pipeline can then be integrated into a fully
featured system that ca
Document the bindings for the Synopsys Designware HDMI RX.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Mark Rutland
Cc: Mauro Carvalho Chehab
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 41 ++
1 file changed, 41 insertions(+)
create mod
Hi Dave,
On Thu, Jun 15, 2017 at 05:15:04PM +0100, Dave Stevenson wrote:
> Hi Sakari.
>
> Thanks for the review.
>
> On 15 June 2017 at 13:59, Sakari Ailus wrote:
> > Hi Dave,
> >
> > Thanks for the set!
> >
> > On Wed, Jun 14, 2017 at 04:15:46PM +0100, Dave Stevenson wrote:
> >> Document the D
On Fri, Jun 16, 2017 at 6:19 PM, Sakari Ailus wrote:
> On Fri, Jun 16, 2017 at 06:03:13PM +0900, Tomasz Figa wrote:
>> On Fri, Jun 16, 2017 at 5:49 PM, Sakari Ailus wrote:
>> > Hi Tomasz,
>> >
>> > On Fri, Jun 16, 2017 at 05:35:52PM +0900, Tomasz Figa wrote:
>> >> On Fri, Jun 16, 2017 at 5:25 PM,
Hi Hans,
On Tue, Jun 06, 2017 at 10:07:45AM +0200, Hans Verkuil wrote:
> On 05/06/17 22:39, Yong Zhi wrote:
> > From: Tuukka Toivonen
> >
> > This driver translates Intel IPU3 internal virtual
> > address to physical address.
> >
> > Signed-off-by: Yong Zhi
> > ---
> > drivers/media/pci/intel
On Fri, Jun 16, 2017 at 06:03:13PM +0900, Tomasz Figa wrote:
> On Fri, Jun 16, 2017 at 5:49 PM, Sakari Ailus wrote:
> > Hi Tomasz,
> >
> > On Fri, Jun 16, 2017 at 05:35:52PM +0900, Tomasz Figa wrote:
> >> On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
> >> > Hi Tomasz,
> >> >
> >> > On Fri,
Hi Janusz,
Thanks for the patch. A few comments below.
On Fri, Jun 16, 2017 at 12:52:43AM +0200, Janusz Krzysztofik wrote:
> Remove the soc_camera dependencies.
>
> Lost features, fortunately not used or not critical on test platform:
> - soc_camera power on/off callback - replaced with clock en
On Fri, Jun 16, 2017 at 5:49 PM, Sakari Ailus wrote:
> Hi Tomasz,
>
> On Fri, Jun 16, 2017 at 05:35:52PM +0900, Tomasz Figa wrote:
>> On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
>> > Hi Tomasz,
>> >
>> > On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
>> >> On Tue, Jun 6, 20
Hi Tomasz,
On Fri, Jun 16, 2017 at 05:35:52PM +0900, Tomasz Figa wrote:
> On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
> > Hi Tomasz,
> >
> > On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
> >> On Tue, Jun 6, 2017 at 7:09 PM, Tomasz Figa wrote:
> >> > On Tue, Jun 6, 2017 at
Hi Kevin,
On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
> The davinci VPIF is a single hardware block, but the existing driver
> is broken up into a common library (vpif.c), output (vpif_display.c) and
> intput (vpif_capture.c).
>
> When migrating to DT, to better model the hardwa
On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
> Hi Tomasz,
>
> On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
>> On Tue, Jun 6, 2017 at 7:09 PM, Tomasz Figa wrote:
>> > On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil wrote:
>> >> On 06/06/17 09:25, Sakari Ailus wrote:
>> >>> Hi
Hi Tomasz,
On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
> On Tue, Jun 6, 2017 at 7:09 PM, Tomasz Figa wrote:
> > On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil wrote:
> >> On 06/06/17 09:25, Sakari Ailus wrote:
> >>> Hi Tomasz,
> >>>
> >>> On Tue, Jun 06, 2017 at 01:30:41PM +0900,
Hi Mauro,
Second attempt to add the venus driver.
Regards,
Hans
The following changes since commit acec3630155763c170c7ae6508cf973355464508:
[media] s3c-camif: fix arguments position in a function call (2017-06-13
14:21:24 -0300)
are available in the git repository at:
git://li
On 06/16/2017 12:23 AM, Pavel Machek wrote:
Fix compilation of isp.c
Signed-off-by: Pavel Machek
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 4ca3fc9..b80debf 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/plat
On 06/16/2017 12:52 AM, Janusz Krzysztofik wrote:
Remove the soc_camera dependencies.
Lost features, fortunately not used or not critical on test platform:
- soc_camera power on/off callback - replaced with clock enable/disable
only, no support for platform provided regulators nor power callb
From: Gustavo Padovan
Implement the needed pieces to let userspace subscribe for
V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
DQEVENT ioctl.
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/v4l2-ctrls.c | 6 +-
drivers/media/v4l2-core/videobuf2-core.c
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence for the buffer and return it to userspace on the fence_fd
field. It only works with ordered queues.
The fence is signaled on buffer_done(), when the job on the buffer is
finished.
v2: check
From: Gustavo Padovan
To enable vivid to be used with explicit synchronization we need
to mark its queues as ordered.
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/vivid/vivid-core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/vivid/vivid-core.c
From: Gustavo Padovan
Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/videobuf2-core.c | 31 +++
include/media/videobuf2-core.h | 5 +
2 files changed, 36 insertions(+)
From: Javier Martinez Canillas
Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Gustavo Padovan
---
include/media/videobuf2-fence.h | 49 ++
From: Gustavo Padovan
Instead of assigning the global v4l2 device, assign the specific device.
This was causing trouble when using using V4L2 events with vivid
devices. The device's queue should be the same we opened in userspace.
Signed-off-by: Gustavo Padovan
---
drivers/media/platform/vivid
From: Gustavo Padovan
Add a new event the userspace can subscribe to receive notifications
when a buffer is queued onto the driver. The event provides the index of
the queued buffer.
Signed-off-by: Gustavo Padovan
---
include/uapi/linux/videodev2.h | 6 ++
1 file changed, 6 insertions(+)
From: Gustavo Padovan
For explicit synchronization (and soon for HAL3/Request API) we need
the v4l2-driver to guarantee the ordering which the buffer were queued
by userspace. This is already true for many drivers, but we never had
the need to say it.
Signed-off-by: Gustavo Padovan
---
include
From: Gustavo Padovan
Hi,
This adds support for Explicit Synchronization of shared buffers in V4L2.
It uses the Sync File Framework[1] as vector to communicate the fences
between kernel and userspace.
Explicit Synchronization allows us to control the synchronization of
shared buffers from users
From: Gustavo Padovan
Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
v4l.
Signed-off-by: Gustavo Padovan
---
drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uv
From: Gustavo Padovan
In order to support explicit synchronization we need to divide
vb2_core_qbuf() in two parts, one to be executed before the fence
signals and another one to do the actual queueing of the buffer.
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/videobuf2-core.c |
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
Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fence signals.
v2:
- fix vb2_queue_or_prepare_buf() ret check
Thanks!
You could remove
intstatus &= ~MASK_HDMI_INT;
in line 1289 as well.
Regards,
Mats Randgaard
On 15/06/2017, 18:49, "Gustavo A. R. Silva" wrote:
Remove useless variable assignment in function tc358743_isr().
The value stored in variable _intstatus_ at line 1299 is
overw
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 Jun 16 05:00:18 CEST 2017
media-tree git hash:acec3630155763c170c7ae6508cf973355464508
media_build gi
82 matches
Mail list logo
