Hello,
On 5/21/18, Ezequiel Garcia wrote:
> The in-fence implementation involves having a per-buffer fence callback,
> that triggers on the fence signal. The fence callback is called
> asynchronously
> and needs a valid reference to the associated ideobuf2 buffer.
>
> Allow this by making the vb2
Hi Steve,
On Thu, 2018-05-24 at 14:33 -0700, Steve Longerbeam wrote:
> Hi Krzysztof, Philipp,
>
> And I can confirm that capturing planar 4:2:0 (YU12, YV12, or NV12),
> is broken because of the call to ipu_cpmem_skip_odd_chroma_rows().
> YU12 or NV12 images look correct again when commenting out
On Thu, 2018-05-24 at 11:12 -0700, Steve Longerbeam wrote:
[...]
> > The following is required as well. Now the question is why we can't skip
> > writing those odd UV rows. Anyway, with these 2 changes, I get a stable
> > NTSC (and probably PAL) interlaced video stream.
> >
> > The manual says: Re
On Fri, May 25, 2018 at 5:47 AM Sakari Ailus
wrote:
> Hi Jacopo,
> On Thu, May 24, 2018 at 10:07:38PM +0200, jacopo mondi wrote:
> ...
> > > > about that, but I wonder why setting controls should be enabled only
> > > > when streaming. I would have expected runtime_pm_get/put in
subdevices
> > >
Hello,
On 5/21/18, Ezequiel Garcia wrote:
> 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 queued to the driver
> out
Steve Longerbeam writes:
> Sorry I did find a bug. Please try this patch:
Ok, your patch fixes the first problem (sets the CSI interlaced mode
on input when field = NOE is requested on output). Posting in full since
your mail came somehow mangled with UTF-8.
--- a/drivers/staging/media/imx/imx-
On Thu, May 24, 2018 at 8:30 PM Baruch Siach wrote:
> Hi Tomasz,
> On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote:
> > On Mon, May 7, 2018 at 3:38 PM Baruch Siach wrote:
> > > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote:
> > > > On Thu, May 3, 2018 at 6:09 PM Baruch
On Thu, May 24, 2018 at 5:44 PM Hans Verkuil wrote:
> Memory-to-memory devices have one video node, one internal control handler
> but two vb2_queues (DMA engines). While often there is one buffer produced
> for every buffer consumed, but this is by no means standard. E.g.
deinterlacers
> will pr
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 May 25 05:00:16 CEST 2018
media-tree git hash:8ed8bba70b4355b1ba029b151ade84475dd12991
media_build gi
Hi Tomasz & Mauro,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Friday, May 18, 2018 11:38 PM
> To: mchehab+sams...@kernel.org
> Cc: Linux Media Mailing List ; Hu, Jerry W
> ; Mani, Rajmohan ;
On Fri, May 18, 2018 at 04:04:35PM +0200, Ana Guerrero Lopez wrote:
> On Wed, May 09, 2018 at 10:13:08AM +0800, ming_q...@realsil.com.cn wrote:
> > From: ming_qian
> >
> > The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1.
> > Change it to 48 for UVC 1.5 device,
> > and the UVC
Hi Jacopo,
Thanks for your work.
I really like what you did with this patch in v4.
On 2018-05-25 00:02:15 +0200, Jacopo Mondi wrote:
> The rcar-vin driver so far had a mutually exclusive code path for
> handling parallel and CSI-2 video input subdevices, with only the CSI-2
> use case supporting
The rcar-vin driver so far had a mutually exclusive code path for
handling parallel and CSI-2 video input subdevices, with only the CSI-2
use case supporting media-controller. As we add support for parallel
inputs to Gen3 media-controller compliant code path now parse both port@0
and port@1, handli
Hello,
this series adds support for parallel video input to the Gen3 version of
rcar-vin driver.
Compared to v3, this new iteration closes all comments from Niklas and Sergei.
As the meat of the patch series hasn't changed much, please refer to v3 cover
letter for more details.
The most notab
As the term 'digital' is used all over the rcar-vin code in place of
'parallel', rename all the occurrencies.
Signed-off-by: Jacopo Mondi
Acked-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 72 ++---
drivers/media/platform/rcar-vin/rcar-dma.c |
Remove leading underscore to align all rcar_group_route structure
declarations.
Signed-off-by: Jacopo Mondi
Acked-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-cor
When running with media-controller link the parallel input
media entities with the VIN entities at 'complete' callback time.
To create media links the v4l2_device should be registered first.
Check if the device is already registered, to avoid double registrations.
Signed-off-by: Jacopo Mondi
Ack
Handle parallel subdevices in link_notify callback. If the notified link
involves a parallel subdevice, do not change routing of the VIN-CSI-2
devices and mark the VIN instance as using a parallel input. If the
CSI-2 link setup succeeds instead, mark the VIN instance as using CSI-2.
Signed-off-by:
Remove un-necessary empty lines.
Signed-off-by: Jacopo Mondi
Acked-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 16d3e01..
Add R-Car R8A77995 SoC to the rcar-vin supported ones.
Signed-off-by: Jacopo Mondi
Reviewed-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
drivers/media/platform/rcar-vin/rcar-core.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/r
Media bus configuration flags and media bus type were so far a property
of each VIN instance, as the subdevice they were connected to was
immutable during the whole system life time.
With the forth-coming introduction of parallel input devices support,
a VIN instance can have the subdevice it is c
As CSI-2 subdevices are shared between several VIN instances, a shared
notifier to collect the CSI-2 async subdevices is required. So far, the
rcar-vin driver used the notifier of the last VIN instance to probe but
with the forth-coming introduction of parallel input subdevices support
in mc-compli
From: Koji Matsuoka
YCbCr planar formats can have different pitch values for the luma and
chroma planes. This isn't taken into account in the driver. Fix it.
Based on a BSP patch from Koji Matsuoka .
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1
Hi Krzysztof, Philipp,
And I can confirm that capturing planar 4:2:0 (YU12, YV12, or NV12),
is broken because of the call to ipu_cpmem_skip_odd_chroma_rows().
YU12 or NV12 images look correct again when commenting out that
call. Commits
14330d7f08 ("media: imx: csi: enable double write reduction
The LIF module has a data buffer to accommodate clock rate differences
between the DU and the VSP. Several programmable threshold values
control DU start of frame notification by the VSP and VSP clock
stop/resume. The R-Car Gen2 and Gen3 datasheets recommend values for the
different SoCs. Update th
Hi Krzysztof,
Sorry I did find a bug. Please try this patch:
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -631,7 +631,6 @@ static int csi_setup(struct csi_priv *priv)
{
struct v4l2_mbus_framefmt *infmt, *outfmt;
struct v4l2_m
Hi Jacopo,
On Thu, May 24, 2018 at 10:07:38PM +0200, jacopo mondi wrote:
...
> > > about that, but I wonder why setting controls should be enabled only
> > > when streaming. I would have expected runtime_pm_get/put in subdevices
> > > node open/close functions not only when streaming. Am I missing
From: Hans Verkuil
Refuse to initialize a vb2 queue if there is no lock specified.
Signed-off-by: Hans Verkuil
---
drivers/media/common/videobuf2/videobuf2-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobu
Now that all drivers provide a proper vb2_queue lock,
and that wait_{prepare, finish} are no longer in use,
get rid of them.
Signed-off-by: Ezequiel Garcia
---
Documentation/media/kapi/v4l2-dev.rst | 7 +++
drivers/input/rmi4/rmi_f54.c | 2 --
dri
From: Hans Verkuil
Drop checks for q->lock. Drop calls to wait_finish/prepare, just lock/unlock
q->lock.
Signed-off-by: Hans Verkuil
---
drivers/media/common/videobuf2/videobuf2-core.c | 21 ---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 27 +++--
inc
From: Hans Verkuil
vb2_queue now expects a valid lock pointer, so drop the checks for
that in v4l2-ioctl.c.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-ioctl.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/dr
The vb2_queue will soon be mandatory. The videobuf2 core
will throw a verbose warning if it's not set.
The stk1160 driver is setting the queue lock, but after
the vb2_queue_init call. Avoid the warning by setting
the lock before the queue initialization.
Signed-off-by: Ezequiel Garcia
---
drive
This driver is currently specifying a video_device lock,
which means it is protecting all the ioctls (including
queue ioctls) with a single mutex.
It's therefore straightforward to implement wait_prepare
and wait_finish, by explicitly setting the vb2_queue lock.
Having these callbacks releases th
This driver is currently specifying a video_device lock,
which means it is protecting all the ioctls (including
queue ioctls) with a single mutex.
It's therefore straightforward to implement wait_prepare
and wait_finish, by explicitly setting the vb2_queue lock.
Having these callbacks releases th
Currently, this driver does not serialize its video4linux
ioctls, which is a bug, as race conditions might appear.
In addition, video_device and vb2_queue locks are now both
mandatory. Add them, and implement wait_prepare and
wait_finish.
To stay on the safe side, this commit uses a single mutex
video_device and vb2_queue locks are now both
mandatory. Add them, remove driver ad-hoc locking,
and implement wait_{prepare, finish}.
To stay on the safe side, this commit uses a single mutex
for both locks. Better latency can be obtained by separating
these if needed.
Signed-off-by: Ezequiel Ga
Use the device mutex to protect the vb2_queue.
This allows to replace the ad-hoc wait_{prepare, finish}
with vb2_ops_wait_{prepare, finish}.
Signed-off-by: Ezequiel Garcia
---
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 24 +-
1 file changed, 5 insertions(+), 19 dele
Use the vb2 context mutex to protect the vb2_queue.
This allows to replace the ad-hoc wait_{prepare, finish}
with vb2_ops_wait_{prepare, finish}.
Signed-off-by: Ezequiel Garcia
---
drivers/media/dvb-core/dvb_vb2.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
dif
Use the mutex in struct mtk_mdp_ctx to protect the
capture and output vb2_queues. This allows to replace
the ad-hoc wait_{prepare, finish} with
vb2_ops_wait_{prepare, finish}.
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 20
1 file chang
vb2_queue locks is now mandatory. Add it, remove driver ad-hoc locks,
and implement wait_{prepare, finish}.
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/omap3isp/ispvideo.c | 65 +-
drivers/media/platform/omap3isp/ispvideo.h | 1 -
2 files changed, 11 in
This driver is currently specifying a vb2_queue lock,
which means it straightforward to implement wait_prepare
and wait_finish.
Having these callbacks releases the queue lock while blocking,
which improves latency by allowing for example streamoff
or qbuf operations while waiting in dqbuf.
Signed
vb2_queue lock is now mandatory. Add it, remove driver ad-hoc
locks, and implement wait_{prepare, finish}.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/omap4iss/iss_video.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/omap4i
This driver is currently specifying a vb2_queue lock,
which means it straightforward to implement wait_prepare
and wait_finish.
Having these callbacks releases the queue lock while blocking,
which improves latency by allowing for example streamoff
or qbuf operations while waiting in dqbuf.
Signed
Currently, this driver does not serialize its video4linux
ioctls, which is a bug, as race conditions might appear.
In addition, video_device and vb2_queue locks are now both
mandatory. Add them, and implement wait_prepare and
wait_finish.
To stay on the safe side, this commit uses a single mutex
From: Hans Verkuil
The ioctl serialization mutex (vdev->lock or q->lock for vb2 queues)
was taken at the highest level in v4l2-dev.c. This prevents more
fine-grained locking since at that level we cannot examine the ioctl
arguments, we can only do that after video_usercopy is called.
So push the
From: Hans Verkuil
For m2m devices the vdev->queue lock was always taken instead of the
lock for the specific capture or output queue. Now that we pushed
the locking down into __video_do_ioctl() we can pick the correct
lock and improve the performance of m2m devices.
Signed-off-by: Hans Verkuil
From: Hans Verkuil
This driver is the only V4L driver that does not set unlocked_ioctl
to video_ioctl2.
The only thing that pvr2_v4l2_ioctl does besides calling video_ioctl2
is calling pvr2_hdw_commit_ctl(). Add pvr2_hdw_commit_ctl() calls to
the various ioctls that need this, and we can replace
Third spin of the series posted by Hans:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg131363.html
Changelog
-
v3:
Reduce changes in patches 6 and 7 for omap3isp and omap4iss
drivers, as suggested by Hans.
v2:
Add the required driver modifications, fixing all
drivers so th
Hi Niklas,
On Thu, May 24, 2018 at 12:42:25AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-18 16:40:37 +0200, Jacopo Mondi wrote:
> > As the term 'digital' is used all over the rcar-vin code in place of
> > 'parallel', rename all the occurrencies.
> >
> > S
Hi Sakari,
On Wed, May 23, 2018 at 10:38:33AM +0300, Sakari Ailus wrote:
> Hi Jacopo and Bingbu,
>
> On Tue, May 22, 2018 at 10:08:48PM +0200, jacopo mondi wrote:
> ...
> > > +/* Get bayer order based on flip setting. */
> > > +static __u32 imx319_get_format_code(struct imx319 *imx319)
> > > +{
>
On Fri, May 25, 2018 at 01:16:32AM +0900, Akinobu Mita wrote:
> 2018-05-22 22:59 GMT+09:00 Sakari Ailus :
> > Dear Mita-san,
> >
> > On Mon, May 21, 2018 at 12:40:38AM +0900, Akinobu Mita wrote:
> >> The open() operation for the pxa_camera driver always calls s_power()
> >> operation to put its sub
Hi Krzysztof,
On 05/24/2018 08:56 AM, Krzysztof Hałasa wrote:
Hi,
I've experimented with the ADV7180 a bit and this is what I found.
First, I'm using (with a NTSC camera but I guess PAL won't be much
different):
media-ctl -V '"adv7180 2-0020":0[fmt:UYVY2X8 720x480 field:interlaced]'
media-ctl
2018-05-22 22:59 GMT+09:00 Sakari Ailus :
> Dear Mita-san,
>
> On Mon, May 21, 2018 at 12:40:38AM +0900, Akinobu Mita wrote:
>> The open() operation for the pxa_camera driver always calls s_power()
>> operation to put its subdevice sensor in normal operation mode, and the
>> release() operation alw
Hi,
I've experimented with the ADV7180 a bit and this is what I found.
First, I'm using (with a NTSC camera but I guess PAL won't be much
different):
media-ctl -V '"adv7180 2-0020":0[fmt:UYVY2X8 720x480 field:interlaced]'
media-ctl -V '"ipu2_csi1_mux":1[fmt:UYVY2X8 720x480 field:interlaced]'
medi
The ZS0211 internal autogain causes pumping and flickering with OV7648
sensor on 0ac8:307b webcam.
Implement OV7648 autogain and exposure control and use that instead.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 42 +
1 file changed, 3
Power line frequency settings for OV7648 sensor contain autogain
and exposure commands, affecting unrelated controls. Remove them.
Signed-off-by: Ondrej Zary
---
drivers/media/usb/gspca/zc3xx.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/media/u
The 50Hz and 60Hz power line frequency settings disable short (1/120s
and 1/100s) exposure times for banding filter, causing overexposed
image near lamps. No flicker setting enables them (when banding
filter is disabled and they're not used).
Seems that the logic is just the wrong way around. Fix
On Wed, May 23, 2018 at 11:31:58AM +0200, Daniel Mack wrote:
> Hi Maxime,
>
> On Tuesday, May 22, 2018 09:54 PM, Maxime Ripard wrote:
> > On Mon, May 21, 2018 at 09:39:02AM +0200, Maxime Ripard wrote:
> > > On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wrote:
>
> > > > This set of patch
Limit frame sizes to the [1, 65536] interval, media bus formats to
the available list of formats, and initialize pad and try formats.
Reported-by: Rui Miguel Silva
Signed-off-by: Philipp Zabel
Tested-by: Rui Miguel Silva
Acked-by: Sakari Ailus
---
Changes since v2:
- Make loop variables unsig
On 18/05/18 16:46, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thursday, 3 May 2018 17:53:12 EEST Hans Verkuil wrote:
>> From: Alexandre Courbot
>>
>> Document the request API for V4L2 devices, and amend the documentation
>> of system calls influenced by it.
>>
>> Sign
On Thu, May 24, 2018 at 02:42:41PM +0200, Philipp Zabel wrote:
> Hi Sakari,
>
> thank you for the review comments.
>
> On Thu, 2018-05-24 at 14:38 +0300, Sakari Ailus wrote:
> > Hi Philipp,
> >
> > Thanks for the patch.
> >
> > On Wed, May 23, 2018 at 11:24:23AM +0200, Philipp Zabel wrote:
> >
Hi Stanimir,
On Tue, May 15, 2018 at 5:08 PM Stanimir Varbanov <
stanimir.varba...@linaro.org> wrote:
[snip]
> diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
> index 41eef376eb2d..381bfdd688db 100644
> --- a/drivers/media/platform/qcom/venus/core.c
On Thu, May 24, 2018 at 09:06:58AM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
Acked-by: Mark Brown
signature.asc
Description: P
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
> Calculate the top and bottom fields for the interlaced frames and
> utilise the extended display list command feature to implement the
> auto-field operations. This allows the DU to update the VSP2 r
Hi Sakari,
thank you for the review comments.
On Thu, 2018-05-24 at 14:38 +0300, Sakari Ailus wrote:
> Hi Philipp,
>
> Thanks for the patch.
>
> On Wed, May 23, 2018 at 11:24:23AM +0200, Philipp Zabel wrote:
> > Limit frame sizes to the [1, 65536] interval, media bus formats to
> > the availabl
On Thu, 2018-05-24 at 10:15 +0200, Hans Verkuil wrote:
> On 23/05/18 22:51, Ezequiel Garcia wrote:
> >
> >
> > On 22 May 2018 at 05:16, Hans Verkuil wrote:
> > > On 18/05/18 19:51, Ezequiel Garcia wrote:
> > > > On 13 May 2018 at 06:47, Hans Verkuil wrote:
> > > > > From: Hans Verkuil
> > > >
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:20 EEST Kieran Bingham wrote:
> VSPD and VSP-DL devices can provide extended display lists supporting
> extended command display list objects.
>
> These extended commands require their own dma memory areas for a header
> and body
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
> Use the newly exposed VSP1 interface to enable interlaced frame support
> through the VSP1 lif pipelines.
s/lif/LIF/
>
> Signed-off-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crt
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
> Extended display list headers allow pre and post command lists to be
> executed by the VSP pipeline. This provides the base support for
> features such as AUTO_FLD (for interlaced support) and AUTO_D
Hi Philipp,
Thanks for the patch.
On Wed, May 23, 2018 at 11:24:23AM +0200, Philipp Zabel wrote:
> Limit frame sizes to the [1, 65536] interval, media bus formats to
> the available list of formats, and initialize pad and try formats.
>
> Reported-by: Rui Miguel Silva
> Signed-off-by: Philipp Z
On Mon, May 21, 2018 at 04:38:03PM +0200, Michał Winiarski wrote:
> Doing writes when the device is disabled seems to be a NOOP.
> Let's enable the device, write the values, and then disable it on init.
> This changes the behavior for wake device, which is now being disabled
> after init.
I don't
Hi,
On Wed 23 May 2018 at 09:24, Philipp Zabel wrote:
Limit frame sizes to the [1, 65536] interval, media bus formats
to
the available list of formats, and initialize pad and try
formats.
Reported-by: Rui Miguel Silva
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Limit to [1, 65536]
Hi Tomasz,
On Mon, May 07, 2018 at 06:41:50AM +, Tomasz Figa wrote:
> On Mon, May 7, 2018 at 3:38 PM Baruch Siach wrote:
> > On Mon, May 07, 2018 at 06:13:27AM +, Tomasz Figa wrote:
> > > On Thu, May 3, 2018 at 6:09 PM Baruch Siach wrote:
> > > > On Thu, Mar 08, 2018 at 05:47:55PM +0800,
On 08/05/18 12:45, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 09:45:27 +0200
> Hans Verkuil escreveu:
>
>> On 05/07/2018 07:20 PM, Mauro Carvalho Chehab wrote:
>>> Em Thu, 3 May 2018 16:52:56 +0200
>>> Hans Verkuil escreveu:
>>>
From: Hans Verkuil
We need to serialize
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
For whatever it is worth:
Acked-by: Hans Verkuil
Regards,
Ha
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
>
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> include/linux
On 08/05/18 12:21, Mauro Carvalho Chehab wrote:
> Em Fri, 4 May 2018 15:27:50 +0300
> Sakari Ailus escreveu:
>
>> Hi Hans,
>>
>> I've read this patch a large number of times and I think also the details
>> begin to seem sound. A few comments below.
>
> I'm sending this after analyzing the other
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:18 EEST Kieran Bingham wrote:
> Header mode display lists are now supported on all WPF outputs. To
> support extended headers and auto-fld capabilities for interlaced mode
> handling only header mode display lists can be used.
>
>
Since commit cb84343fced1 ("media: lirc: do not call close() or open() on
unregistered devices") rc_open() will return -ENODEV if rcdev->registered
is false. Ensure this is set before we register the input device and the
lirc device, else we have a short window where the neither the lirc or
input d
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:17 EEST Kieran Bingham wrote:
> The VSP1 devices define their specific capabilities through features
> marked in their device info structure. Various parts of the code read
> this info structure to infer if the features are availab
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:16 EEST Kieran Bingham wrote:
> If there is an error allocating a display list within a DLM object
> the existing display lists are not free'd, and neither is the DL body
> pool.
>
> Use the existing vsp1_dlm_destroy() function to
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:15 EEST Kieran Bingham wrote:
> The vsp1 reference in the vsp1_dl_body structure is not used.
> Remove it.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/vsp1/vsp1_dl.c | 2 --
>
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:14 EEST Kieran Bingham wrote:
> Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display
> list chain referencing the nodes as children, when in reality they are
> siblings.
>
> Update the terminology to 'dl_next' to b
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
drivers/platfo
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
include/linux/mfd/cros_ec_commands.h | 81
1 file changed, 81 insertions(+)
diff -
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at lea
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:13 EEST Kieran Bingham wrote:
> The use of the packed attribute can cause a performance penalty for
> all accesses to the struct members, as the compiler will assume that the
> structure has the potential to have an unaligned base.
Hi Jacopo,
Thanks for your work.
On 2018-05-18 16:40:44 +0200, Jacopo Mondi wrote:
> Remove trailing underscore to align all rcar_group_route structure
> declarations.
>
> Signed-off-by: Jacopo Mondi
With Sergei's comment addressed:
Acked-by: Niklas Söderlund
> ---
> drivers/media/platform
Hi Jacopo,
Thanks for your patch.
On 2018-05-18 16:40:43 +0200, Jacopo Mondi wrote:
> Handle parallel subdevices in link_notify callback. If the notified link
> involves a parallel subdevice, do not change routing of the VIN-CSI-2
> devices and mark the VIN instance as using a parallel input. If
Hi Jacopo,
Thanks for your patch.
On 2018-05-18 16:40:42 +0200, Jacopo Mondi wrote:
> When running with media-controller link the parallel input
> media entities with the VIN entities at 'complete' callback time.
>
> To create media links the v4l2_device should be registered first.
> Check if th
Hi Jacopo,
Thanks for your work.
On 2018-05-18 16:40:41 +0200, Jacopo Mondi wrote:
> The rcar-vin driver so far had a mutually exclusive code path for
> handling parallel and CSI-2 video input subdevices, with only the CSI-2
> use case supporting media-controller. As we add support for parallel
>
On 08/05/18 12:49, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 10:07:22 +0200
> Hans Verkuil escreveu:
>
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 76352eb59f14..a0f7c38d1a90 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:12 EEST Kieran Bingham wrote:
> The pixel format is 'unsupported'. Fix the small debug message which
> incorrectly declares this.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/
Hi Jacopo,
Thanks for your patch.
On 2018-05-18 16:40:40 +0200, Jacopo Mondi wrote:
> Media bus configuration flags and media bus type were so far a property
> of each VIN instance, as the subdevice they were connected to was
> immutable during the whole system life time.
>
> With the forth-comi
Hi Jacopo,
Thanks for your patch.
On 2018-05-18 16:40:39 +0200, Jacopo Mondi wrote:
> As CSI-2 subdevices are shared between several VIN instances, a shared
> notifier to collect the CSI-2 async subdevices is required. So far, the
> rcar-vin driver used the notifier of the last VIN instance to pr
Hi Kieran,
On Thursday, 3 May 2018 16:45:30 EEST Kieran Bingham wrote:
> On 03/05/18 12:13, Laurent Pinchart wrote:
[snip]
> >>> diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h
> >>> b/drivers/media/platform/vsp1/vsp1_rwpf.h index
> >>> 70742ecf766f..8d6e42f27908 100644
> >>> --- a/drivers/
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device reg
1 - 100 of 133 matches
Mail list logo
