cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Sat Dec 31 05:00:08 CET 2016
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: a710e1bb7c6803a9347d3899b9129d887221985f
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

On 12/30/2016 11:06 AM, Marek Vasut wrote:

On 12/29/2016 09:51 PM, Robert Schwebel wrote:

Hi Jean-Michel,

Hi,


On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:

What is the status of this work?

Philipp's patches have been reworked with the review feedback from the
last round and a new version will be posted when he is back from
holidays.

IMO Philipp's patches are better integrated and well structured, so I'd
rather like to see his work in at some point.


Granted I am biased, but I will state my case. "Better integrated" - my 
patches
are also well integrated with the media core infrastructure. Philipp's 
patches

in fact require modification to media core, whereas mine require none.
Some changes are needed of course (more subdev type definitions for
one).

As for "well structured", I don't really understand what is meant by that,
but my driver is also well structured.

Philipp's driver only supports unconverted image capture from the SMFC. 
In addition
to that, mine allows for all the hardware links supported by the IPU, 
including routing
frames from the CSI directly to the Image converter for scaling up to 
4096x4096,
colorspace conversion, rotation, and motion compensated de-interlace. 
Yes all these
conversion can be carried out post-capture via a mem2mem device, but 
conversion
directly from CSI capture has advantages, including minimized CPU 
utilization and
lower AXI bus traffic. In any case, Freescale added these hardware 
paths, and my

driver supports them.

I leave it up to the maintainers.

Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Marek Vasut]

On 12/29/2016 09:51 PM, Robert Schwebel wrote:
> Hi Jean-Michel,

Hi,

> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:
>> What is the status of this work?
> 
> Philipp's patches have been reworked with the review feedback from the
> last round and a new version will be posted when he is back from
> holidays.

IMO Philipp's patches are better integrated and well structured, so I'd
rather like to see his work in at some point.

-- 
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control

[Steve Longerbeam]

Hi Linus, Lothar,


On 12/30/2016 05:17 AM, Linus Walleij wrote:

On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
 wrote:


Add optional reset-gpios pin control. If present, de-assert the
specified reset gpio pin to bring the chip out of reset.

Signed-off-by: Steve Longerbeam 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.


Ok, I'll send the next version separately.





@@ -133,6 +134,7 @@ struct pca953x_chip {
 const char *const *names;
 unsigned long driver_data;
 struct regulator *regulator;
+   struct gpio_desc *reset_gpio;

Why do you even keep this around in the device state container?

As you only use it in the probe() function, use a local variable.

The descriptor will be free():ed by the devm infrastructure anyways.


I think my reasoning for putting the gpio handle into the device
struct was for possibly using it for run-time reset control at some
point. But that could be done later if needed, so I'll go ahead and
make it local.


+   /* see if we need to de-assert a reset pin */
+   chip->reset_gpio = devm_gpiod_get_optional(>dev,
+  "reset",
+  GPIOD_OUT_LOW);
+   if (IS_ERR(chip->reset_gpio)) {
+   dev_err(>dev, "request for reset pin failed\n");
+   return PTR_ERR(chip->reset_gpio);
+   }

Nice.


+   if (chip->reset_gpio) {
+   /* bring chip out of reset */
+   dev_info(>dev, "releasing reset\n");
+   gpiod_set_value(chip->reset_gpio, 0);
+   }

Is this really needed given that you set it low in the
devm_gpiod_get_optional()?


Yep, this is left over from a previous iteration, but it isn't needed now.
I'll remove it.

Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Sean Young]

Hi Ivo,

On Fri, Dec 30, 2016 at 03:50:42PM +0200, Ivaylo Dimitrov wrote:
> On 30.12.2016 15:30, Sean Young wrote:
> >On Fri, Dec 30, 2016 at 01:07:52PM +, Sean Young wrote:
> >Speaking of which, if you would please test this, that would be great. My
> >N900 died many years ago.
> 
> Will do, but next year :) .

Great, thanks!

Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][V3] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in err message

Signed-off-by: Colin Ian King 
---
 drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/gp8psk.c 
b/drivers/media/usb/dvb-usb/gp8psk.c
index 2360e7e..26461f2 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -161,7 +161,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
goto out_free;
}
if (buflen > 64) {
-   err("firmare chunk size bigger than 64 bytes.");
+   err("firmware chunk size bigger than 64 bytes.");
goto out_free;
}
 
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][V2] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"

[Kalle Valo]

Colin King  writes:

> From: Colin Ian King 
>
> Trivial fix to spelling mistake in err message. Also change "don't" to
> "does not".
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/usb/dvb-usb/gp8psk.c  | 2 +-
>  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Could you split the rtlwifi part to it's own patch? I can't apply
patches touching media drivers.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Ivaylo Dimitrov]

On 30.12.2016 15:30, Sean Young wrote:


On Fri, Dec 30, 2016 at 01:07:52PM +, Sean Young wrote:

Hi Ivo,,

On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:

On 20.12.2016 19:50, Sean Young wrote:

This driver was written using lirc since rc-core did not support
transmitter-only hardware at that time. Now that it does, port
this driver.

Compile tested only.



I guess after that change, there will be no more /dev/lircN device, right?
Neither will LIRC_XXX IOCTL codes be supported?


Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs
will be fixed. For example, at the moment it is possible to write hours
of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders,
and when that is in place, any rc-core driver will get it for free.


That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi for
example), which will be broken by the change.


Nothing should break.


Speaking of which, if you would please test this, that would be great. My
N900 died many years ago.



Will do, but next year :) .

Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] uvcvideo: (cosmetic) add and use an inline function

[Guennadi Liakhovetski]

Hi Laurent,

On Fri, 30 Dec 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thank you for the patch.
> 
> On Monday 12 Dec 2016 12:16:49 Guennadi Liakhovetski wrote:
> > From: Guennadi Liakhovetski 
> > 
> > Add an inline function to obtain a struct uvc_buffer pointer from a
> > struct vb2_v4l2_buffer one.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/media/usb/uvc/uvc_queue.c | 6 +++---
> >  drivers/media/usb/uvc/uvcvideo.h  | 4 
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/usb/uvc/uvc_queue.c
> > b/drivers/media/usb/uvc/uvc_queue.c index 77edd20..c119551 100644
> > --- a/drivers/media/usb/uvc/uvc_queue.c
> > +++ b/drivers/media/usb/uvc/uvc_queue.c
> > @@ -89,7 +89,7 @@ static int uvc_buffer_prepare(struct vb2_buffer *vb)
> >  {
> > struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> > struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
> > -   struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> > +   struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
> > 
> > if (vb->type == V4L2_BUF_TYPE_VIDEO_OUTPUT &&
> > vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0)) {
> > @@ -116,7 +116,7 @@ static void uvc_buffer_queue(struct vb2_buffer *vb)
> >  {
> > struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> > struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
> > -   struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> > +   struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
> > unsigned long flags;
> > 
> > spin_lock_irqsave(>irqlock, flags);
> > @@ -138,7 +138,7 @@ static void uvc_buffer_finish(struct vb2_buffer *vb)
> > struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> > struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
> > struct uvc_streaming *stream = uvc_queue_to_stream(queue);
> > -   struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> > +   struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
> > 
> > if (vb->state == VB2_BUF_STATE_DONE)
> > uvc_video_clock_update(stream, vbuf, buf);
> > diff --git a/drivers/media/usb/uvc/uvcvideo.h
> > b/drivers/media/usb/uvc/uvcvideo.h index 3d6cc62..a1e6a19 100644
> > --- a/drivers/media/usb/uvc/uvcvideo.h
> > +++ b/drivers/media/usb/uvc/uvcvideo.h
> > @@ -679,6 +679,10 @@ static inline int uvc_queue_streaming(struct
> > uvc_video_queue *queue) {
> > return vb2_is_streaming(>queue);
> >  }
> > +static inline struct uvc_buffer *uvc_vbuf_to_buffer(struct vb2_v4l2_buffer
> > *vbuf)
> 
> If you rename vbuf to buf you'll fit within the 80 columns limit.
> 
> I also propose moving the function to uvc_queue.c as it's only used there, 
> like the uvc_queue_to_stream() function.

No, it was your proposal to move this function to uvcvideo.h in a separate 
patch to make it available to the forthcoming metadata node patch.

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> If you're fine with those changes there's no need to resubmit, I'll fix when 
> applying (for v4.11).

Thanks
Guennadi

> > +{
> > +   return container_of(vbuf, struct uvc_buffer, buf);
> > +}
> > 
> >  /* V4L2 interface */
> >  extern const struct v4l2_ioctl_ops uvc_ioctl_ops;
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] uvcvideo: fix a wrong macro

[Laurent Pinchart]

Hi Guennadi,

Thank you for the patch.

On Monday 12 Dec 2016 12:16:51 Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes.
> 
> Signed-off-by: Guennadi Liakhovetski 
> Cc: sta...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

and applied to my tree for v4.11.

> ---
>  drivers/media/usb/uvc/uvc_queue.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_queue.c
> b/drivers/media/usb/uvc/uvc_queue.c index c119551..b9ef31c 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -412,7 +412,7 @@ struct uvc_buffer *uvc_queue_next_buffer(struct
> uvc_video_queue *queue, nextbuf = NULL;
>   spin_unlock_irqrestore(>irqlock, flags);
> 
> - buf->state = buf->error ? VB2_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
> + buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
>   vb2_set_plane_payload(>buf.vb2_buf, 0, buf->bytesused);
>   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Sean Young]

On Fri, Dec 30, 2016 at 01:07:52PM +, Sean Young wrote:
> Hi Ivo,,
> 
> On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:
> > On 20.12.2016 19:50, Sean Young wrote:
> > >This driver was written using lirc since rc-core did not support
> > >transmitter-only hardware at that time. Now that it does, port
> > >this driver.
> > >
> > >Compile tested only.
> > >
> > 
> > I guess after that change, there will be no more /dev/lircN device, right?
> > Neither will LIRC_XXX IOCTL codes be supported?
> 
> Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
> supported through ir-lirc-codec.c.
> 
> By using rc-core, the driver will be more succinct, and some latent bugs
> will be fixed. For example, at the moment it is possible to write hours
> of IR data and keep the n900 from suspending.
> 
> I'm working on lirc scancode sending and receiving using the IR encoders,
> and when that is in place, any rc-core driver will get it for free.
> 
> > That looks to me as a completely new driver, not a port to new API.
> > 
> > Right now there are applications using the current behaviour (pierogi for
> > example), which will be broken by the change.
> 
> Nothing should break.

Speaking of which, if you would please test this, that would be great. My
N900 died many years ago.

Many thanks,

Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/4] uvcvideo: (cosmetic) remove a superfluous assignment

[Laurent Pinchart]

Hi Guennadi,

Thank you for the patch.

On Monday 12 Dec 2016 12:16:50 Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> Remove a superfluous assignment to a local variable at the end of a
> function.
> 
> Signed-off-by: Guennadi Liakhovetski 

Reviewed-by: Laurent Pinchart 

and applied to my tree for v4.11.

> ---
>  drivers/media/usb/uvc/uvc_video.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index b5589d5..51b5ae5 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1262,8 +1262,7 @@ static void uvc_video_decode_bulk(struct urb *urb,
> struct uvc_streaming *stream, uvc_video_decode_end(stream, buf,
> stream->bulk.header,
>   stream->bulk.payload_size);
>   if (buf->state == UVC_BUF_STATE_READY)
> - buf = uvc_queue_next_buffer(>queue,
> - buf);
> + uvc_queue_next_buffer(>queue, buf);
>   }
> 
>   stream->bulk.header_size = 0;

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] uvcvideo: (cosmetic) add and use an inline function

[Laurent Pinchart]

Hi Guennadi,

Thank you for the patch.

On Monday 12 Dec 2016 12:16:49 Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> Add an inline function to obtain a struct uvc_buffer pointer from a
> struct vb2_v4l2_buffer one.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
>  drivers/media/usb/uvc/uvc_queue.c | 6 +++---
>  drivers/media/usb/uvc/uvcvideo.h  | 4 
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_queue.c
> b/drivers/media/usb/uvc/uvc_queue.c index 77edd20..c119551 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -89,7 +89,7 @@ static int uvc_buffer_prepare(struct vb2_buffer *vb)
>  {
>   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
>   struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
> - struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> + struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
> 
>   if (vb->type == V4L2_BUF_TYPE_VIDEO_OUTPUT &&
>   vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0)) {
> @@ -116,7 +116,7 @@ static void uvc_buffer_queue(struct vb2_buffer *vb)
>  {
>   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
>   struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
> - struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> + struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
>   unsigned long flags;
> 
>   spin_lock_irqsave(>irqlock, flags);
> @@ -138,7 +138,7 @@ static void uvc_buffer_finish(struct vb2_buffer *vb)
>   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
>   struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
>   struct uvc_streaming *stream = uvc_queue_to_stream(queue);
> - struct uvc_buffer *buf = container_of(vbuf, struct uvc_buffer, buf);
> + struct uvc_buffer *buf = uvc_vbuf_to_buffer(vbuf);
> 
>   if (vb->state == VB2_BUF_STATE_DONE)
>   uvc_video_clock_update(stream, vbuf, buf);
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h index 3d6cc62..a1e6a19 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -679,6 +679,10 @@ static inline int uvc_queue_streaming(struct
> uvc_video_queue *queue) {
>   return vb2_is_streaming(>queue);
>  }
> +static inline struct uvc_buffer *uvc_vbuf_to_buffer(struct vb2_v4l2_buffer
> *vbuf)

If you rename vbuf to buf you'll fit within the 80 columns limit.

I also propose moving the function to uvc_queue.c as it's only used there, 
like the uvc_queue_to_stream() function.

Apart from that,

Reviewed-by: Laurent Pinchart 

If you're fine with those changes there's no need to resubmit, I'll fix when 
applying (for v4.11).

> +{
> + return container_of(vbuf, struct uvc_buffer, buf);
> +}
> 
>  /* V4L2 interface */
>  extern const struct v4l2_ioctl_ops uvc_ioctl_ops;

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Laurent Pinchart]

Hi Guennadi,

On Friday 30 Dec 2016 14:04:34 Guennadi Liakhovetski wrote:
> On Fri, 30 Dec 2016, Laurent Pinchart wrote:
> > On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> >> Hi Laurent,
> >> 
> >> I'd like to discuss extending this patch a bit, preferably as an
> >> incremental patch.
> >> 
> >> First let me confirm my current understanding of the way the UVC driver
> >> creates its media device topology. Do I understand it correctly, that
> >> the driver allocates UVC entities (not media controller entities) for all
> >> UVC units and terminals, but then uses subdevices for all such UVC
> >> entities, except terminals, i.e. only for UVC units? struct uvc_entity
> >> has an embedded struct v4l2_subdev object, but it's unused for UVC
> >> terminals. Instead terminals are associated to video devices, which are
> >> then linked into the MC topology? Is this my understanding correct?
> > 
> > That's correct, but looking at the code now, I think the driver should use
> > a struct media_entity directly instead of a struct v4l2_subdev as it
> > doesn't need any of the infrastructure provided by subdevs.
> > 
> >> I have a problem with the current version of this patch, that there is
> >> no way to associate video device nodes with respepctive metadata nodes.
> >> Would it be acceptable to use an MC link for this association?
> > 
> > No, links describe data connections.
> 
> Well, it is data - it's metadata, extracted from USB buffers.
> 
> >> Is it allowed for video device MC entities to have source pads
> >> additionally to their (usually single) sink pad(s) (in case of input
> >> video devices)? If that would be acceptable, I could create an additional
> >> patch to add a source pad to output terminal video nodes to link it to
> >> metadata nodes.
> > 
> > That's a hack, I don't think it's a good idea.
> 
> Ok, would a completely specialised one-off sysfs solution be better? Maybe
> a link under the metadata node to the main node?

Come on, I know you're better than that. Stop thinking short term about the 
quickest hack that can provide the feature you need.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control

[Linus Walleij]

On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
 wrote:

> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org

This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.


> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> +   struct gpio_desc *reset_gpio;

Why do you even keep this around in the device state container?

As you only use it in the probe() function, use a local variable.

The descriptor will be free():ed by the devm infrastructure anyways.

> +   /* see if we need to de-assert a reset pin */
> +   chip->reset_gpio = devm_gpiod_get_optional(>dev,
> +  "reset",
> +  GPIOD_OUT_LOW);
> +   if (IS_ERR(chip->reset_gpio)) {
> +   dev_err(>dev, "request for reset pin 
> failed\n");
> +   return PTR_ERR(chip->reset_gpio);
> +   }

Nice.

> +   if (chip->reset_gpio) {
> +   /* bring chip out of reset */
> +   dev_info(>dev, "releasing reset\n");
> +   gpiod_set_value(chip->reset_gpio, 0);
> +   }

Is this really needed given that you set it low in the
devm_gpiod_get_optional()?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Sean Young]

Hi Ivo,,

On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:
> On 20.12.2016 19:50, Sean Young wrote:
> >This driver was written using lirc since rc-core did not support
> >transmitter-only hardware at that time. Now that it does, port
> >this driver.
> >
> >Compile tested only.
> >
> 
> I guess after that change, there will be no more /dev/lircN device, right?
> Neither will LIRC_XXX IOCTL codes be supported?

Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs
will be fixed. For example, at the moment it is possible to write hours
of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders,
and when that is in place, any rc-core driver will get it for free.

> That looks to me as a completely new driver, not a port to new API.
> 
> Right now there are applications using the current behaviour (pierogi for
> example), which will be broken by the change.

Nothing should break.

Thanks,

Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with uvcvideo timestamps

[Laurent Pinchart]

Hi Niels,

On Monday 31 Oct 2016 14:42:54 Niels Möller wrote:
> Hi,
> 
> I'm tracking down a problem in Chrome, where video streams captured
> from a Logitech c930e camera get bogus timestamps. Chrome started
> using camera timestamps on linux a few months ago. I've noted commit
> 
>  
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> 5d0fd3c806b9e932010931ae67dbb482020e0882
> 
>   "[media] uvcvideo: Disable hardware timestamps by default"
> 
> but I'm running with a kernel which doesn't have that change.
> 
> First, let me say that for our purposes, the hairy syncing to the
> "SOF" clock done by uvc_video_clock_update is not that useful.
> Ideally, I would prefer if the v4l2_buffer of a captured frame
> included both
> 
>   * untranslated pts timestamp from the camera device (if I've
> understood this correctly, and there is a pts sent over the wire),

There's a PTS sent over the wire, yes.

> and
> 
>   * the value of system monotonic clock at the point when the frame
> was received by the kernel.
> 
> Is there any reasonable way to get this information out from the
> driver?

The system monotonic clock timestamp is what the driver provides (with the 
above patch at least). We however have no field in the v4l2_buffer structure 
at the moment to provide the PTS.

> We could then do estimation of the camera's epoch and clock drift in the
> application.

Unless I'm mistaken, you can only do that if you get the SCR/PTS values in 
your application, and they're currently not provided. How do you plan to solve 
that ?

> The raw pts is the most important piece of information.

What do you want to use it for by the way ?

> Second, I'd like to try to provide some logs to help track down the
> bug. To reproduce, I'm using the example program at
> https://gist.github.com/maxlapshin/1253534, modified to print out
> camera timestamp and gettimeofday for each frame. Log attached as
> time-2.log.

Thank you. I have a device I can use to reproduce the problem, but haven't had 
time to fix it yet :-/ Performing the timestamp translation in userspace would 
allow for more precise calculation, so I'm not advocating for a kernel-only 
solution. However, I don't want every application to implement timestamp 
translation. A common implementation in libv4l2 could be a good solution.

> I also enabled tracing of the clock translation logic using
> 
>   echo 4096 > /sys/module/uvcvideo/parameters/trace
> 
> The corresponding kernel log messages are attached as trace-2.log.
> 
> In time-2.log (i.e., the application log), I see that camera
> timestamps move backwards in time,
> 
>   TIMESTAMP_MONOTONIC
>  cam: 2321521.085372
>  sys: 1477913910.983620
>   TIMESTAMP_MONOTONIC
>  cam: 2321520.879272
>  sys: 1477913911.051628
> 
> In trace-2.log (i.e., kernel log messages) I see
> 
>   uvcvideo: Logitech Webcam C930e: PTS 219483992 y 4084.798004 SOF
> 4084.798004 (x1 2064310082 x2 2148397132 y1 218759168 y2 268238848 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4084.798004 y 3105900702 ts
> 2321520.879272 buf ts 2321521.153372 (x1 218759168/1546/1290 x2
> 274071552/1878/2045 y1 10 y2 3380001263)
>   uvcvideo: Logitech Webcam C930e: PTS 221480532 y 4156.709564 SOF
> 4156.709564 (x1 2079524156 x2 2148397450 y1 256376832 y2 272629760 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4156.709564 y 2453257742 ts
> 2321520.378627 buf ts 2321521.217373 (x1 262275072/1698/1864 x2
> 278265856/1942/64 y1 10 y2 3292003672)
>   uvcvideo: Logitech Webcam C930e: PTS 223477044 y 4223.428085 SOF
> 4223.428085 (x1 2081269216 x2 2148397122 y1 264568832 y2 276955136 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 2175.428085 y 2158773894 ts
> 2321520.208143 buf ts 2321521.285373 (x1 136183808/1822/1989 x2
> 148504576/2010/130 y1 10 y2 3236003012)
> 
> I don't know the details of the usb protocol, but it looks like the
> "SOF" value is usually increasing. But close to the bogus output
> timestamp of 2321520.879272, it goes through some kind of wraparound,
> with the sequence of values
> 
>   4156.709564
>   4223.428085
>   2175.428085# 2048 less than previous value
>   2243.169921
> 
> I hope the attached logs provide enough information to analyze where
> uvc_video_clock_update gets this wrong.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

On Fri, 30 Dec 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> > Hi Laurent,
> > 
> > I'd like to discuss extending this patch a bit, preferably as an
> > incremental patch.
> > 
> > First let me confirm my current understanding of the way the UVC driver
> > creates its media device topology. Do I understand it correctly, that the
> > driver allocates UVC entities (not media controller entities) for all UVC
> > units and terminals, but then uses subdevices for all such UVC entities,
> > except terminals, i.e. only for UVC units? struct uvc_entity has an
> > embedded struct v4l2_subdev object, but it's unused for UVC terminals.
> > Instead terminals are associated to video devices, which are then linked
> > into the MC topology? Is this my understanding correct?
> 
> That's correct, but looking at the code now, I think the driver should use a 
> struct media_entity directly instead of a struct v4l2_subdev as it doesn't 
> need any of the infrastructure provided by subdevs.
> 
> > I have a problem with the current version of this patch, that there is no
> > way to associate video device nodes with respepctive metadata nodes. Would
> > it be acceptable to use an MC link for this association?
> 
> No, links describe data connections.

Well, it is data - it's metadata, extracted from USB buffers.

> > Is it allowed for video device MC entities to have source pads additionally
> > to their (usually single) sink pad(s) (in case of input video devices)? If
> > that would be acceptable, I could create an additional patch to add a source
> > pad to output terminal video nodes to link it to metadata nodes.
> 
> That's a hack, I don't think it's a good idea.

Ok, would a completely specialised one-off sysfs solution be better? Maybe 
a link under the metadata node to the main node?

Thanks
Guennadi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Laurent Pinchart]

Hi Guennadi,

On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> Hi Laurent,
> 
> I'd like to discuss extending this patch a bit, preferably as an
> incremental patch.
> 
> First let me confirm my current understanding of the way the UVC driver
> creates its media device topology. Do I understand it correctly, that the
> driver allocates UVC entities (not media controller entities) for all UVC
> units and terminals, but then uses subdevices for all such UVC entities,
> except terminals, i.e. only for UVC units? struct uvc_entity has an
> embedded struct v4l2_subdev object, but it's unused for UVC terminals.
> Instead terminals are associated to video devices, which are then linked
> into the MC topology? Is this my understanding correct?

That's correct, but looking at the code now, I think the driver should use a 
struct media_entity directly instead of a struct v4l2_subdev as it doesn't 
need any of the infrastructure provided by subdevs.

> I have a problem with the current version of this patch, that there is no
> way to associate video device nodes with respepctive metadata nodes. Would
> it be acceptable to use an MC link for this association?

No, links describe data connections.

> Is it allowed for video device MC entities to have source pads additionally
> to their (usually single) sink pad(s) (in case of input video devices)? If
> that would be acceptable, I could create an additional patch to add a source
> pad to output terminal video nodes to link it to metadata nodes.

That's a hack, I don't think it's a good idea.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Ivaylo Dimitrov]

Hi,

On 20.12.2016 19:50, Sean Young wrote:

This driver was written using lirc since rc-core did not support
transmitter-only hardware at that time. Now that it does, port
this driver.

Compile tested only.



I guess after that change, there will be no more /dev/lircN device, 
right? Neither will LIRC_XXX IOCTL codes be supported?


That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi 
for example), which will be broken by the change.


Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

Hi Laurent,

I'd like to discuss extending this patch a bit, preferably as an 
incremental patch.

First let me confirm my current understanding of the way the UVC driver 
creates its media device topology. Do I understand it correctly, that the 
driver allocates UVC entities (not media controller entities) for all UVC 
units and terminals, but then uses subdevices for all such UVC entities, 
except terminals, i.e. only for UVC units? struct uvc_entity has an 
embedded struct v4l2_subdev object, but it's unused for UVC terminals. 
Instead terminals are associated to video devices, which are then linked 
into the MC topology? Is this my understanding correct?

I have a problem with the current version of this patch, that there is no 
way to associate video device nodes with respepctive metadata nodes. Would 
it be acceptable to use an MC link for this association? Is it allowed for 
video device MC entities to have source pads additionally to their 
(usually single) sink pad(s) (in case of input video devices)? If that 
would be acceptable, I could create an additional patch to add a source 
pad to output terminal video nodes to link it to metadata nodes.

Thanks
Guennadi

On Mon, 12 Dec 2016, Guennadi Liakhovetski wrote:

> From: Guennadi Liakhovetski 
> 
> Some UVC video cameras contain metadata in their payload headers. This
> patch extracts that data, skipping the standard part of the header, on
> both bulk and isochronous endpoints and makes it available to the user
> space on a separate video node, using the V4L2_CAP_META_CAPTURE
> capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. Even
> though different cameras will have different metadata formats, we use
> the same V4L2_META_FMT_UVC pixel format for all of them. Users have to
> parse data, based on the specific camera model information.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v3: all comments to v2 have been addressed - thanks! Most important 
> ones:
> 
> * metadata nodes are now only created for cameras, for which a 
>   UVC_QUIRK_METADATA_NODE flag is specified
> * no metadata nodes are created for video interfaces with isochronous 
>   endpoints. For those to be meaningfully supported a UVC standard 
>   extension is required.
> * the uvc_queue.c vb2_queue implementation is extended and used 
>   instead of a separate implementation
> 
>  drivers/media/usb/uvc/Makefile   |   2 +-
>  drivers/media/usb/uvc/uvc_driver.c   |   4 +
>  drivers/media/usb/uvc/uvc_isight.c   |   2 +-
>  drivers/media/usb/uvc/uvc_metadata.c | 159 
> +++
>  drivers/media/usb/uvc/uvc_queue.c|  68 ++-
>  drivers/media/usb/uvc/uvc_video.c|  41 -
>  drivers/media/usb/uvc/uvcvideo.h |  19 -
>  drivers/media/v4l2-core/v4l2-ioctl.c |   1 +
>  include/uapi/linux/uvcvideo.h|   7 ++
>  include/uapi/linux/videodev2.h   |   3 +
>  10 files changed, 278 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> 
> diff --git a/drivers/media/usb/uvc/Makefile b/drivers/media/usb/uvc/Makefile
> index c26d12f..06c7cd3 100644
> --- a/drivers/media/usb/uvc/Makefile
> +++ b/drivers/media/usb/uvc/Makefile
> @@ -1,5 +1,5 @@
>  uvcvideo-objs  := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o 
> \
> -   uvc_status.o uvc_isight.o uvc_debugfs.o
> +   uvc_status.o uvc_isight.o uvc_debugfs.o uvc_metadata.o
>  ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
>  uvcvideo-objs  += uvc_entity.o
>  endif
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index 04bf350..b2e9eef 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1865,6 +1865,7 @@ static void uvc_unregister_video(struct uvc_device *dev)
>   continue;
>  
>   video_unregister_device(>vdev);
> + video_unregister_device(>meta.vdev);
>  
>   uvc_debugfs_cleanup_stream(stream);
>   }
> @@ -1926,6 +1927,9 @@ static int uvc_register_video(struct uvc_device *dev,
>   return ret;
>   }
>  
> + /* Register a metadata node. */
> + uvc_meta_register(stream);
> +
>   if (stream->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
>   stream->chain->caps |= V4L2_CAP_VIDEO_CAPTURE;
>   else
> diff --git a/drivers/media/usb/uvc/uvc_isight.c 
> b/drivers/media/usb/uvc/uvc_isight.c
> index 8510e725..fb940cf 100644
> --- a/drivers/media/usb/uvc/uvc_isight.c
> +++ b/drivers/media/usb/uvc/uvc_isight.c
> @@ -100,7 +100,7 @@ static int isight_decode(struct uvc_video_queue *queue, 
> struct uvc_buffer *buf,
>  }
>  
>  void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
> - struct uvc_buffer *buf)
> + struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
>  {
>   int ret, i;
>  
> diff --git 

The update of RockChip media framework plan

[Randy Li]

To those guy who cares Rockchip

There is a update about Rockchip media framework, I decided not to 
continue of developing the VA-API driver for produces purpose(both 
official and private plan). As there is really to much problem with 
VA-API with V4L2. But I may develop the VA-API driver to know how to 
expend the parser in Gstreamer.
The currently Gstreamer plugins using a rockchip video parser and HAL 
layer library could be located here

https://github.com/rockchip-linux/gstreamer-rockchip

For the future develop plan, I would try to move all the thing to 
Gstreamer V4L2 plugin, maybe I would create a new plugin. But it would 
be a long time to go. As there is no critical need of the Media 
framework for Rockchip in Linux, the official plan would be paused, if 
the kodi or LibreELEC is not interesting to my supervisor, this plan 
will become my private plan, but good news is that my plan about the ISP 
support would become official.


Any the result would be there is a standard V4L2 API and a driver for 
those stateless video driver(Do remember we don't need firmware). And I 
would use the Gstreamer in userspace and welcome the other to offer the 
support in the other project.


For the those project who have supported the ffmpeg, I would suggest you 
to add support for Gstreamer, the role of Gstreamer in a player is not 
different to the ffmpeg. The support of ffmpeg of Rockchip project would 
be dropped, as we need a power way to rendering decoding result for 
those 4K video. The Gstreamer is the only Media Framework who could 
offer a static interface and easy to extend. Even the Gstreamer, 
currently I found it could only cover the 80% solution of I would meet,

but it is enough for Linux.

On 12/23/2016 07:17 PM, Christian Hewitt wrote:

Hello Randy,

I would like LibreELEC to run great on a wide range of devices including
rockchip so it is good to have direct contact - thanks Lionel.

Our core focus is Kodi so I have cc'd Keith Herrington from the Kodi
project board. Keith and senior developers on Kodi’s team can guide you
on their technical direction and requirements for Linux. Once there is
agreement on the right approach for your developers we can start looking
at hardware support.

Kind regards,

Christian

--
Christian Hewitt
Project Lead
chew...@libreelec.tv 
+971 50 3570 499

On 22 Dec 2016, at 07:49 pm, LongChair . > wrote:


Hi Christian,

I have been looking around recently to RockChip latest SoCs, which are
RK3288 and RK3399.
They seem great on paper, and I have some interest in those.

What i know about those so far is that :
- They Run Linux 4.4
- They Have some V4L2 compliance which was made by rockChip for
Google/chromium
- They also have a va-api wrapper (only supporting h264 so far, but
intended to be extended in a near future to other codecs)
- They have some muscles (A72 for RK3399) and Mali 8XX as GPU which
makes them probably snappier than AML SoCs.

I am considering investigating this as a potential platform for US,
which means integrating it into LE.
I am not sure if that would be a valid approach, or if that would meet
any kodi eventual requirements as well.

I'm available to discuss that with you anytime.
I will cc also Ayaka to this email. He's a Rockchip employee in charge
of Linux Support.
Should you have deeper technical questions about this, he will
probably be able to answer that :)

Cheers,

Lionel






--
Randy Li
The third produce department

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html