date:20160709

Re: [PATCH v2] doc-rst: add an option to ignore DocBooks when generating docs

2016-07-09 Thread Jonathan Corbet

On Sat,  9 Jul 2016 13:12:45 -0300
Mauro Carvalho Chehab  wrote:

> Sometimes, we want to do a partial build, instead of building
> everything. However, right now, if one wants to build just
> Sphinx books, it will build also the DocBooks.
> 
> Add an option to allow to ignore all DocBooks when building
> documentation.

Seems good, applied to the docs tree, thanks.

jon
--
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

cron job: media_tree daily build: ERRORS

2016-07-09 Thread 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:   Sun Jul 10 04:00:17 CEST 2016
git branch: test
git hash:   ca6e6126db5494f18c6c6615060d4d803b528bff
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mtk: OK
linux-git-arm-mx: OK
linux-git-arm-omap: 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.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: OK
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.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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

[PATCH] media: solo6x10: increase FRAME_BUF_SIZE

2016-07-09 Thread Andrey Utkin

In practice, devices sometimes return frames larger than current buffer
size, leading to failure in solo_send_desc().
It is not clear which minimal increase in buffer size would be enough,
so this patch doubles it, this should be safely assumed as sufficient.

Signed-off-by: Andrey Utkin 
---
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 8b1cde5..3991643 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -33,7 +33,7 @@
 #include "solo6x10-jpeg.h"
 
 #define MIN_VID_BUFFERS2
-#define FRAME_BUF_SIZE (196 * 1024)
+#define FRAME_BUF_SIZE (400 * 1024)
 #define MP4_QS 16
 #define DMA_ALIGN  4096
 
-- 
2.8.4

--
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.1 3/5] media: Refactor copying IOCTL arguments from and to user space

2016-07-09 Thread Sakari Ailus

On Sun, Jul 10, 2016 at 02:12:24AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Sunday 10 Jul 2016 01:03:09 Sakari Ailus wrote:
> > On Sat, Jul 09, 2016 at 10:29:03PM +0300, Laurent Pinchart wrote:
> > > On Monday 09 May 2016 16:16:26 Sakari Ailus wrote:
> > >> Laurent Pinchart wrote:
> > >>> On Wednesday 04 May 2016 16:09:51 Sakari Ailus wrote:
> >  Refactor copying the IOCTL argument structs from the user space and
> >  back, in order to reduce code copied around and make the
> >  implementation more robust.
> >  
> >  As a result, the copying is done while not holding the graph mutex.
> >  
> >  Signed-off-by: Sakari Ailus 
> >  ---
> >  since v2:
> >  
> >  - Remove function to calculate maximum argument size, replace by a
> >    char array of 256 or kmalloc() if that's too small.
> >   
> >   drivers/media/media-device.c | 194 ++---
> >   1 file changed, 94 insertions(+), 100 deletions(-)
> >  
> >  diff --git a/drivers/media/media-device.c
> >  b/drivers/media/media-device.c
> >  index 9b5a88d..0797e4b 100644
> >  --- a/drivers/media/media-device.c
> >  +++ b/drivers/media/media-device.c
> > > 
> > > [snip]
> > > 
> >  @@ -453,10 +432,24 @@ static long __media_device_ioctl(
> >  
> > info = &info_array[_IOC_NR(cmd)];
> >  
> >  +  if (_IOC_SIZE(info->cmd) > sizeof(__karg)) {
> >  +  karg = kmalloc(_IOC_SIZE(info->cmd), GFP_KERNEL);
> >  +  if (!karg)
> >  +  return -ENOMEM;
> >  +  }
> >  +
> >  +  info->arg_from_user(karg, arg, cmd);
> >  +
> > mutex_lock(&dev->graph_mutex);
> >  -  ret = info->fn(dev, arg);
> >  +  ret = info->fn(dev, karg);
> > mutex_unlock(&dev->graph_mutex);
> >  
> >  +  if (!ret)
> > >>> 
> > >>> How about if (!ret && info->arg_to_user) instead, and getting rid of
> > >>> copy_arg_to_user_nop() ?
> > >> 
> > >> I thought of that, but I decided to optimise the common case ---  which
> > >> is that the argument is copied back and forth. Not copying the argument
> > >> back is a very special case, we use it for a single compat IOCTL.
> > >> 
> > >> That said, we could use it for the proper ENUM_LINKS as well. Still that
> > >> does not change what's normal.
> > > 
> > > We're talking about one comparison and one branching instruction (that
> > > will not be taken in the common case). Is that micro-optimization really
> > > worth it in an ioctl path that is not that performance-critical ? If you
> > > think it is, could you analyse what the impact of the
> > > copy_arg_to_user_nop() function on cache locality is for the common case ?
> > > ;-)
> > 
> > I sense a certain amount of insistence in your arguments. Fine, I'll change
> > it.
> 
> Thanks. I'll change that in the next version of the request API patches I 
> will 
> send out.

I think we rather should try to decrease the size of the set and get the
preparation patches in first.

I'm ready to send a pull request on these (after testing the rebased
patches), but it's been pending on the minimum arg size vs. list of
supported sizes discussion.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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.1 3/5] media: Refactor copying IOCTL arguments from and to user space

2016-07-09 Thread Laurent Pinchart

Hi Sakari,

On Sunday 10 Jul 2016 01:03:09 Sakari Ailus wrote:
> On Sat, Jul 09, 2016 at 10:29:03PM +0300, Laurent Pinchart wrote:
> > On Monday 09 May 2016 16:16:26 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >>> On Wednesday 04 May 2016 16:09:51 Sakari Ailus wrote:
>  Refactor copying the IOCTL argument structs from the user space and
>  back, in order to reduce code copied around and make the
>  implementation more robust.
>  
>  As a result, the copying is done while not holding the graph mutex.
>  
>  Signed-off-by: Sakari Ailus 
>  ---
>  since v2:
>  
>  - Remove function to calculate maximum argument size, replace by a
>    char array of 256 or kmalloc() if that's too small.
>   
>   drivers/media/media-device.c | 194 ++---
>   1 file changed, 94 insertions(+), 100 deletions(-)
>  
>  diff --git a/drivers/media/media-device.c
>  b/drivers/media/media-device.c
>  index 9b5a88d..0797e4b 100644
>  --- a/drivers/media/media-device.c
>  +++ b/drivers/media/media-device.c
> > 
> > [snip]
> > 
>  @@ -453,10 +432,24 @@ static long __media_device_ioctl(
>  
>   info = &info_array[_IOC_NR(cmd)];
>  
>  +if (_IOC_SIZE(info->cmd) > sizeof(__karg)) {
>  +karg = kmalloc(_IOC_SIZE(info->cmd), GFP_KERNEL);
>  +if (!karg)
>  +return -ENOMEM;
>  +}
>  +
>  +info->arg_from_user(karg, arg, cmd);
>  +
>   mutex_lock(&dev->graph_mutex);
>  -ret = info->fn(dev, arg);
>  +ret = info->fn(dev, karg);
>   mutex_unlock(&dev->graph_mutex);
>  
>  +if (!ret)
> >>> 
> >>> How about if (!ret && info->arg_to_user) instead, and getting rid of
> >>> copy_arg_to_user_nop() ?
> >> 
> >> I thought of that, but I decided to optimise the common case ---  which
> >> is that the argument is copied back and forth. Not copying the argument
> >> back is a very special case, we use it for a single compat IOCTL.
> >> 
> >> That said, we could use it for the proper ENUM_LINKS as well. Still that
> >> does not change what's normal.
> > 
> > We're talking about one comparison and one branching instruction (that
> > will not be taken in the common case). Is that micro-optimization really
> > worth it in an ioctl path that is not that performance-critical ? If you
> > think it is, could you analyse what the impact of the
> > copy_arg_to_user_nop() function on cache locality is for the common case ?
> > ;-)
> 
> I sense a certain amount of insistence in your arguments. Fine, I'll change
> it.

Thanks. I'll change that in the next version of the request API patches I will 
send out.

> You might want to send a patch removing video_device_release_empty() as
> well. :-)

Actually we should, but for an entirely different reason : most drivers that 
use video_device_release_empty() do so because they believe devm_kzalloc() is 
the best invention since sliced bread, but in reality they will crash at 
unbind time if userspace holds a reference to the video node.

-- 
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: si2157: new revision?

2016-07-09 Thread Antti Palosaari

Hey, that's your problem :] Driver development is all the time resolving 
this kind of issues and you really need to resolve those yourself.


You will need to get I2C communication working with all the chips. First 
si2168 demod and after it answers to I2C you will need to get connection 
to Si2157 tuner. After both of those are answering you could try to get 
tuning tests to see if demod locks. After demod locks you know tuner is 
working and also demod is somehow working. If demod lock but there is no 
picture you know problem is TS interface. Try different TS settings for 
both USB-bridge and demod - those should match. If it does not starts 
working then you have to look sniffs and start replacing driver code 
with data from sniffs to until it starts working => problematic setting 
is found.


regards
Antti



On 07/10/2016 12:18 AM, Oleh Kravchenko wrote:

Hello!

I'm started playing i2c, but stuck with unknown error for me - 32 (EPIPE?):
[ 5651.958763] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60
len=15: c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01
[ 5651.958774] cx231xx #0: (pipe 0x80001000): OUT:  40 02 21 c0 00 00
0f 00
[ 5651.958775] >>> c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01FAILED!
[ 5651.959110] cx231xx 1-2:1.1: cx231xx_send_usb_command: failed with
status --32
[ 5651.959111] cx231xx #0 at cx231xx_i2c_xfer:  ERROR: -32

How this error can be fixed? :)

On 04.07.16 21:47, Antti Palosaari wrote:

Hello
On 07/04/2016 09:38 PM, Oleh Kravchenko wrote:

Hello Antti!

I started reverse-engineering of my new TV tuner "Evromedia USB Full
Hybrid Full HD" and discovered that start sequence is different from
si2157.c:
i2c_read_C1
 1 \xFE
i2c_write_C0
 15 \xC0\x00\x00\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01

Do you familiar with this revision?
Should I merge my changes to si2158.c?
Or define another driver?


According to chip markings those are tuner Si2158-A20 and demod
Si2168-A30. Both are supported already by si2157 and si2168 drivers.

Difference is just some settings. You need to identify which setting is
wrong and add that to configuration options. It should be pretty easy to
find it from the I2C dumps and just testing.

regards
Antti





--
http://palosaari.fi/
--
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 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

2016-07-09 Thread Sakari Ailus

Hi Laurent,

On Sat, Jul 09, 2016 at 10:47:27PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thank you for the patch.
> 
> On Wednesday 04 May 2016 14:20:54 Sakari Ailus wrote:
> > New IOCTLs (especially for the request API) do not necessarily need the
> > graph mutex acquired. Leave this up to the drivers.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/media-device.c | 47 +++-
> >  1 file changed, 28 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index 39fe07f..8aef5b8 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -390,21 +390,26 @@ static long copy_arg_to_user_nop(void __user *uarg,
> > void *karg, }
> >  #endif
> > 
> > -#define MEDIA_IOC_ARG(__cmd, func, from_user, to_user) \
> > -   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> > -   .cmd = MEDIA_IOC_##__cmd,   \
> > +/* Do acquire the graph mutex */
> > +#define MEDIA_IOC_FL_GRAPH_MUTEX   BIT(0)
> > +
> > +#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
> > +   [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> > +   .cmd = MEDIA_IOC_##__cmd,   \
> > .fn = (long (*)(struct media_device *, void *))func,\
> > -   .arg_from_user = from_user, \
> > -   .arg_to_user = to_user, \
> > +   .flags = fl,\
> > +   .arg_from_user = from_user, \
> > +   .arg_to_user = to_user, \
> > }
> > 
> > -#define MEDIA_IOC(__cmd, func) 
> \
> > -   MEDIA_IOC_ARG(__cmd, func, copy_arg_from_user, copy_arg_to_user)
> > +#define MEDIA_IOC(__cmd, func, fl) \
> > +   MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
> > 
> >  /* the table is indexed by _IOC_NR(cmd) */
> >  struct media_ioctl_info {
> > unsigned int cmd;
> > long (*fn)(struct media_device *dev, void *arg);
> > +   unsigned short flags;
> > long (*arg_from_user)(void *karg, void __user *uarg, unsigned int 
> cmd);
> > long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
> >  };
> > @@ -449,9 +454,13 @@ static long __media_device_ioctl(
> > 
> > info->arg_from_user(karg, arg, cmd);
> > 
> > -   mutex_lock(&dev->graph_mutex);
> > +   if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> > +   mutex_lock(&dev->graph_mutex);
> > +
> > ret = info->fn(dev, karg);
> > -   mutex_unlock(&dev->graph_mutex);
> > +
> > +   if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> > +   mutex_unlock(&dev->graph_mutex);
> > 
> > if (ret)
> > return ret;
> > @@ -460,11 +469,11 @@ static long __media_device_ioctl(
> >  }
> > 
> >  static const struct media_ioctl_info ioctl_info[] = {
> > -   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> > -   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> > -   MEDIA_IOC(ENUM_LINKS, media_device_enum_links),
> > -   MEDIA_IOC(SETUP_LINK, media_device_setup_link),
> > -   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> > +   MEDIA_IOC(DEVICE_INFO, media_device_get_info,
> > MEDIA_IOC_FL_GRAPH_MUTEX),
> 
> do we really need to acquire the graph mutex for this ioctl ?

Very probably not, but I would prefer not to change how the IOCTLs are
serialised in this patchset.

> 
> > +   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities,
> > MEDIA_IOC_FL_GRAPH_MUTEX), +MEDIA_IOC(ENUM_LINKS, 
> > media_device_enum_links,
> > MEDIA_IOC_FL_GRAPH_MUTEX), +MEDIA_IOC(SETUP_LINK, 
> > media_device_setup_link,
> > MEDIA_IOC_FL_GRAPH_MUTEX), +MEDIA_IOC(G_TOPOLOGY,
> > media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX), };
> > 
> >  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> > @@ -510,11 +519,11 @@ static long from_user_enum_links32(void *karg, void
> > __user *uarg, #define MEDIA_IOC_ENUM_LINKS32_IOWR('|', 
> > 0x02, 
> struct
> > media_links_enum32)
> > 
> >  static const struct media_ioctl_info compat_ioctl_info[] = {
> > -   MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> > -   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> > -   MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links,
> > from_user_enum_links32, copy_arg_to_user_nop), -MEDIA_IOC(SETUP_LINK,
> > media_device_setup_link),
> > -   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> > +   MEDIA_IOC(DEVICE_INFO, media_device_get_info, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> > +   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities,
> > MEDIA_IOC_FL_GRAPH_MUTEX), +MEDIA_IOC_ARG(ENUM_LINKS32,
> > media_device_enum_links, MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32,
> > copy_arg_to_user_nop), +MEDIA_IOC(SETUP_LINK, media_device_setup_link,
> > M

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

2016-07-09 Thread Sakari Ailus

Hi Laurent,

On Sat, Jul 09, 2016 at 10:29:03PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Monday 09 May 2016 16:16:26 Sakari Ailus wrote:
> > Laurent Pinchart wrote:
> > > On Wednesday 04 May 2016 16:09:51 Sakari Ailus wrote:
> > >> Refactor copying the IOCTL argument structs from the user space and back,
> > >> in order to reduce code copied around and make the implementation more
> > >> robust.
> > >> 
> > >> As a result, the copying is done while not holding the graph mutex.
> > >> 
> > >> Signed-off-by: Sakari Ailus 
> > >> ---
> > >> since v2:
> > >> 
> > >> - Remove function to calculate maximum argument size, replace by a char
> > >>   array of 256 or kmalloc() if that's too small.
> > >>  
> > >>  drivers/media/media-device.c | 194 -
> > >>  1 file changed, 94 insertions(+), 100 deletions(-)
> > >> 
> > >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > >> index 9b5a88d..0797e4b 100644
> > >> --- a/drivers/media/media-device.c
> > >> +++ b/drivers/media/media-device.c
> 
> [snip]
> 
> > >> @@ -453,10 +432,24 @@ static long __media_device_ioctl(
> > >> 
> > >>  info = &info_array[_IOC_NR(cmd)];
> > >> 
> > >> +if (_IOC_SIZE(info->cmd) > sizeof(__karg)) {
> > >> +karg = kmalloc(_IOC_SIZE(info->cmd), GFP_KERNEL);
> > >> +if (!karg)
> > >> +return -ENOMEM;
> > >> +}
> > >> +
> > >> +info->arg_from_user(karg, arg, cmd);
> > >> +
> > >>  mutex_lock(&dev->graph_mutex);
> > >> -ret = info->fn(dev, arg);
> > >> +ret = info->fn(dev, karg);
> > >>  mutex_unlock(&dev->graph_mutex);
> > >> 
> > >> +if (!ret)
> > > 
> > > How about if (!ret && info->arg_to_user) instead, and getting rid of
> > > copy_arg_to_user_nop() ?
> > 
> > I thought of that, but I decided to optimise the common case ---  which
> > is that the argument is copied back and forth. Not copying the argument
> > back is a very special case, we use it for a single compat IOCTL.
> > 
> > That said, we could use it for the proper ENUM_LINKS as well. Still that
> > does not change what's normal.
> 
> We're talking about one comparison and one branching instruction (that will 
> not be taken in the common case). Is that micro-optimization really worth it 
> in an ioctl path that is not that performance-critical ? If you think it is, 
> could you analyse what the impact of the copy_arg_to_user_nop() function on 
> cache locality is for the common case ? ;-)

I sense a certain amount of insistence in your arguments. Fine, I'll change
it.

You might want to send a patch removing video_device_release_empty() as
well. :-)

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 06/11] media: adv7180: add bt.656-4 OF property

2016-07-09 Thread Steve Longerbeam




On 07/09/2016 02:10 PM, Steve Longerbeam wrote:



On 07/09/2016 11:59 AM, Steve Longerbeam wrote:



On 07/07/2016 07:52 AM, Lars-Peter Clausen wrote:

On 07/07/2016 12:59 AM, Steve Longerbeam wrote:

Add a device tree boolean property "bt656-4" to allow setting
the ITU-R BT.656-4 compatible bit.

Signed-off-by: Steve Longerbeam 


+/* select ITU-R BT.656-4 compatible? */
+if (of_property_read_bool(client->dev.of_node, "bt656-4"))
+state->bt656_4 = true;
This property needs to be documented. In my opinion it should also be a
property of the endpoint sub-node rather than the toplevel device 
node since

this is a configuration of the endpoint format.


Agreed, it's really a config of the backend capture endpoint. I'll 
move it
there and also document it in 
Documentation/devicetree/bindings/media/i2c/adv7180.txt.


er, scratch that. ITU-R BT.656 compatibility is really a property of 
the bt.656 bus. It
should be added to v4l2 endpoints and parsed by 
v4l2_of_parse_endpoint(). I've created
a patch to add a "bt656-mode" property to v4l2 endpoints and will copy 
all the maintainers.


But I'm going back and forth on whether this property should be added to 
the adv7180's
local endpoint, or to the remote endpoint. I'm leaning towards the 
remote endpoint, since

this is more about how the backend wants the bus configured.

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: si2157: new revision?

2016-07-09 Thread Oleh Kravchenko

Hello!

I'm started playing i2c, but stuck with unknown error for me - 32 (EPIPE?):
[ 5651.958763] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60
len=15: c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01
[ 5651.958774] cx231xx #0: (pipe 0x80001000): OUT:  40 02 21 c0 00 00
0f 00
[ 5651.958775] >>> c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01FAILED!
[ 5651.959110] cx231xx 1-2:1.1: cx231xx_send_usb_command: failed with
status --32
[ 5651.959111] cx231xx #0 at cx231xx_i2c_xfer:  ERROR: -32

How this error can be fixed? :)

On 04.07.16 21:47, Antti Palosaari wrote:
> Hello
> On 07/04/2016 09:38 PM, Oleh Kravchenko wrote:
>> Hello Antti!
>>
>> I started reverse-engineering of my new TV tuner "Evromedia USB Full
>> Hybrid Full HD" and discovered that start sequence is different from
>> si2157.c:
>> i2c_read_C1
>>  1 \xFE
>> i2c_write_C0
>>  15 \xC0\x00\x00\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01
>>
>> Do you familiar with this revision?
>> Should I merge my changes to si2158.c?
>> Or define another driver?
> 
> According to chip markings those are tuner Si2158-A20 and demod
> Si2168-A30. Both are supported already by si2157 and si2168 drivers.
> 
> Difference is just some settings. You need to identify which setting is
> wrong and add that to configuration options. It should be pretty easy to
> find it from the I2C dumps and just testing.
> 
> regards
> Antti
> 

--
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 06/11] media: adv7180: add bt.656-4 OF property

2016-07-09 Thread Steve Longerbeam




On 07/09/2016 11:59 AM, Steve Longerbeam wrote:



On 07/07/2016 07:52 AM, Lars-Peter Clausen wrote:

On 07/07/2016 12:59 AM, Steve Longerbeam wrote:

Add a device tree boolean property "bt656-4" to allow setting
the ITU-R BT.656-4 compatible bit.

Signed-off-by: Steve Longerbeam 


+/* select ITU-R BT.656-4 compatible? */
+if (of_property_read_bool(client->dev.of_node, "bt656-4"))
+state->bt656_4 = true;
This property needs to be documented. In my opinion it should also be a
property of the endpoint sub-node rather than the toplevel device 
node since

this is a configuration of the endpoint format.


Agreed, it's really a config of the backend capture endpoint. I'll 
move it
there and also document it in 
Documentation/devicetree/bindings/media/i2c/adv7180.txt.


er, scratch that. ITU-R BT.656 compatibility is really a property of the 
bt.656 bus. It
should be added to v4l2 endpoints and parsed by 
v4l2_of_parse_endpoint(). I've created
a patch to add a "bt656-mode" property to v4l2 endpoints and will copy 
all 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

[PATCH] [media] cec: Fix anonymous union initialization with older toolchains.

2016-07-09 Thread Vinson Lee

This patch fixes this build error on CentOS 6.8 with GCC 4.4.7.

  CC [M]  drivers/staging/media/cec/cec-adap.o
drivers/staging/media/cec/cec-adap.c: In function ‘cec_queue_msg_fh’:
drivers/staging/media/cec/cec-adap.c:141: error: unknown field ‘lost_msgs’ 
specified in initializer

Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)")
Signed-off-by: Vinson Lee 
---
 drivers/staging/media/cec/cec-adap.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 5ffa839..a21c13d 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -137,8 +137,10 @@ static void cec_queue_event(struct cec_adapter *adap,
 static void cec_queue_msg_fh(struct cec_fh *fh, const struct cec_msg *msg)
 {
static const struct cec_event ev_lost_msg = {
+   .ts = 0,
.event = CEC_EVENT_LOST_MSGS,
-   .lost_msgs.lost_msgs = 1,
+   .flags = 0,
+   { .lost_msgs = { .lost_msgs = 1 } },
};
struct cec_msg_entry *entry;
 
-- 
1.7.1

--
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 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

2016-07-09 Thread Laurent Pinchart

Hi Sakari,

Thank you for the patch.

On Wednesday 04 May 2016 14:20:54 Sakari Ailus wrote:
> New IOCTLs (especially for the request API) do not necessarily need the
> graph mutex acquired. Leave this up to the drivers.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-device.c | 47 +++-
>  1 file changed, 28 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 39fe07f..8aef5b8 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -390,21 +390,26 @@ static long copy_arg_to_user_nop(void __user *uarg,
> void *karg, }
>  #endif
> 
> -#define MEDIA_IOC_ARG(__cmd, func, from_user, to_user)   \
> - [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> - .cmd = MEDIA_IOC_##__cmd,   \
> +/* Do acquire the graph mutex */
> +#define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0)
> +
> +#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user)   \
> + [_IOC_NR(MEDIA_IOC_##__cmd)] = {\
> + .cmd = MEDIA_IOC_##__cmd,   \
>   .fn = (long (*)(struct media_device *, void *))func,\
> - .arg_from_user = from_user, \
> - .arg_to_user = to_user, \
> + .flags = fl,\
> + .arg_from_user = from_user, \
> + .arg_to_user = to_user, \
>   }
> 
> -#define MEDIA_IOC(__cmd, func)   
\
> - MEDIA_IOC_ARG(__cmd, func, copy_arg_from_user, copy_arg_to_user)
> +#define MEDIA_IOC(__cmd, func, fl)   \
> + MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
> 
>  /* the table is indexed by _IOC_NR(cmd) */
>  struct media_ioctl_info {
>   unsigned int cmd;
>   long (*fn)(struct media_device *dev, void *arg);
> + unsigned short flags;
>   long (*arg_from_user)(void *karg, void __user *uarg, unsigned int 
cmd);
>   long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
>  };
> @@ -449,9 +454,13 @@ static long __media_device_ioctl(
> 
>   info->arg_from_user(karg, arg, cmd);
> 
> - mutex_lock(&dev->graph_mutex);
> + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> + mutex_lock(&dev->graph_mutex);
> +
>   ret = info->fn(dev, karg);
> - mutex_unlock(&dev->graph_mutex);
> +
> + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
> + mutex_unlock(&dev->graph_mutex);
> 
>   if (ret)
>   return ret;
> @@ -460,11 +469,11 @@ static long __media_device_ioctl(
>  }
> 
>  static const struct media_ioctl_info ioctl_info[] = {
> - MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> - MEDIA_IOC(ENUM_LINKS, media_device_enum_links),
> - MEDIA_IOC(SETUP_LINK, media_device_setup_link),
> - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> + MEDIA_IOC(DEVICE_INFO, media_device_get_info,
> MEDIA_IOC_FL_GRAPH_MUTEX),

do we really need to acquire the graph mutex for this ioctl ?

> + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities,
> MEDIA_IOC_FL_GRAPH_MUTEX), +  MEDIA_IOC(ENUM_LINKS, media_device_enum_links,
> MEDIA_IOC_FL_GRAPH_MUTEX), +  MEDIA_IOC(SETUP_LINK, media_device_setup_link,
> MEDIA_IOC_FL_GRAPH_MUTEX), +  MEDIA_IOC(G_TOPOLOGY,
> media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX), };
> 
>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -510,11 +519,11 @@ static long from_user_enum_links32(void *karg, void
> __user *uarg, #define MEDIA_IOC_ENUM_LINKS32  _IOWR('|', 0x02, 
struct
> media_links_enum32)
> 
>  static const struct media_ioctl_info compat_ioctl_info[] = {
> - MEDIA_IOC(DEVICE_INFO, media_device_get_info),
> - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities),
> - MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links,
> from_user_enum_links32, copy_arg_to_user_nop), -  MEDIA_IOC(SETUP_LINK,
> media_device_setup_link),
> - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology),
> + MEDIA_IOC(DEVICE_INFO, media_device_get_info, 
MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities,
> MEDIA_IOC_FL_GRAPH_MUTEX), +  MEDIA_IOC_ARG(ENUM_LINKS32,
> media_device_enum_links, MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32,
> copy_arg_to_user_nop), +  MEDIA_IOC(SETUP_LINK, media_device_setup_link,
> MEDIA_IOC_FL_GRAPH_MUTEX), +  MEDIA_IOC(G_TOPOLOGY,
> media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX), };
> 
>  static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

2016-07-09 Thread Laurent Pinchart

Hi Sakari,

On Monday 09 May 2016 16:16:26 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Wednesday 04 May 2016 16:09:51 Sakari Ailus wrote:
> >> Refactor copying the IOCTL argument structs from the user space and back,
> >> in order to reduce code copied around and make the implementation more
> >> robust.
> >> 
> >> As a result, the copying is done while not holding the graph mutex.
> >> 
> >> Signed-off-by: Sakari Ailus 
> >> ---
> >> since v2:
> >> 
> >> - Remove function to calculate maximum argument size, replace by a char
> >>   array of 256 or kmalloc() if that's too small.
> >>  
> >>  drivers/media/media-device.c | 194 -
> >>  1 file changed, 94 insertions(+), 100 deletions(-)
> >> 
> >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> >> index 9b5a88d..0797e4b 100644
> >> --- a/drivers/media/media-device.c
> >> +++ b/drivers/media/media-device.c

[snip]

> >> @@ -453,10 +432,24 @@ static long __media_device_ioctl(
> >> 
> >>info = &info_array[_IOC_NR(cmd)];
> >> 
> >> +  if (_IOC_SIZE(info->cmd) > sizeof(__karg)) {
> >> +  karg = kmalloc(_IOC_SIZE(info->cmd), GFP_KERNEL);
> >> +  if (!karg)
> >> +  return -ENOMEM;
> >> +  }
> >> +
> >> +  info->arg_from_user(karg, arg, cmd);
> >> +
> >>mutex_lock(&dev->graph_mutex);
> >> -  ret = info->fn(dev, arg);
> >> +  ret = info->fn(dev, karg);
> >>mutex_unlock(&dev->graph_mutex);
> >> 
> >> +  if (!ret)
> > 
> > How about if (!ret && info->arg_to_user) instead, and getting rid of
> > copy_arg_to_user_nop() ?
> 
> I thought of that, but I decided to optimise the common case ---  which
> is that the argument is copied back and forth. Not copying the argument
> back is a very special case, we use it for a single compat IOCTL.
> 
> That said, we could use it for the proper ENUM_LINKS as well. Still that
> does not change what's normal.

We're talking about one comparison and one branching instruction (that will 
not be taken in the common case). Is that micro-optimization really worth it 
in an ioctl path that is not that performance-critical ? If you think it is, 
could you analyse what the impact of the copy_arg_to_user_nop() function on 
cache locality is for the common case ? ;-)

-- 
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 06/11] media: adv7180: add bt.656-4 OF property

2016-07-09 Thread Steve Longerbeam




On 07/07/2016 07:52 AM, Lars-Peter Clausen wrote:

On 07/07/2016 12:59 AM, Steve Longerbeam wrote:

Add a device tree boolean property "bt656-4" to allow setting
the ITU-R BT.656-4 compatible bit.

Signed-off-by: Steve Longerbeam 


+   /* select ITU-R BT.656-4 compatible? */
+   if (of_property_read_bool(client->dev.of_node, "bt656-4"))
+   state->bt656_4 = true;
This property needs to be documented. In my opinion it should also be a
property of the endpoint sub-node rather than the toplevel device node since
this is a configuration of the endpoint format.


Agreed, it's really a config of the backend capture endpoint. I'll move it
there and also document it in 
Documentation/devicetree/bindings/media/i2c/adv7180.txt.


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 02/11] Revert "[media] adv7180: fix broken standards handling"

2016-07-09 Thread Steve Longerbeam




On 07/07/2016 08:45 AM, Lars-Peter Clausen wrote:

On 07/07/2016 12:59 AM, Steve Longerbeam wrote:

Autodetect was likely broken only because access to the
interrupt registers were broken, so there were no standard
change interrupts. After fixing that, and reverting this,
autodetect seems to work just fine on an i.mx6q SabreAuto.

This reverts commit 937feeed3f0ae8a0389d5732f6db63dd912acd99.

The brokenness the commit refers to is conceptual not functional. The driver
simply implemented the API incorrect. A subdev driver is not allowed to
automatically switch the output format/resolution randomly. In the best case
this will confuse the receiver which is not prepared to receive the changed
resolution, in the worst case it will cause buffer overruns with hardware
that has no boundary checks. This is why this was removed from the driver.

The correct sequence is for the driver to generate a change notification and
then have userspace react to that notification by stopping the current
stream, query the new format/resolution, reconfigure the video pipeline for
the new format/resolution and re-start the stream.


Hi Lars, ok thanks for the clarification. Yes I agree that makes sense.
I will undo the revert in the next version and retest.

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 v5 3/4] ARM: dts: koelsch: add HDMI input

2016-07-09 Thread Geert Uytterhoeven

On Wed, Jul 6, 2016 at 5:39 PM, Ulrich Hecht
 wrote:
> From: Hans Verkuil 
>
> Add support in the dts for the HDMI input. Based on the Lager dts
> patch from Ultich Hecht.

I assume he's the third son in the Hecht family? ;-)

> Signed-off-by: Hans Verkuil 
> [uli: removed "renesas," prefixes from pfc nodes]
> Signed-off-by: Ulrich Hecht 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [ANN] Media documentation converted to ReST markup language

2016-07-09 Thread Laurent Pinchart

Hi Mauro,

On Friday 08 Jul 2016 10:34:20 Mauro Carvalho Chehab wrote:
> As commented on the patch series I just submitted, we finished the
> conversion of the Media uAPI book from DocBook to ReST.
> 
> For now, I'm placing the new documentation, after parsed by Sphinx, at this
> place:
>   https://mchehab.fedorapeople.org/media_API_book/
> 
> There are some instructions there about how to use Sphinx too, with can be
> useful for the ones writing patches. Those are part of the docs-next that
> will be sent to Kernel 4.8, thanks to Jani Nikula an Jonathan Corbet.
> 
> The media docbook itself is located at:
>   https://mchehab.fedorapeople.org/media_API_book/linux_tv/index.html
> 
> And the patches are already at the media tree, under the "docs-next"
> branch:
>   https://git.linuxtv.org/media_tree.git/log/?h=docs-next
> 
> If you find anything inconsistent, wrong or incomplete, feel free to
> submit patches to it. My plan is to merge this branch on Kernel 4.8-rc1
> and then remove the Documentation/DocBook/media stuff from the Kernel.
> 
> PS.: I'll soon be adding one extra patch there renaming the media
> directory. "linux_tv" is not the best name for the media contents,
> but, on the other hand, having a "media/media" directory also doesn't
> make sense. So, I need to think for a better name before doing the
> change. Pehaps I'll go for:
>   Documentation/media - for all media documentation, were we
>   should also store things that are now under
>   /video4linux and under /dvb;
> 
> and:
>   Documentation/media/uapi - for the above book that were just
>   converted from DocBook.

The layout looks fresh and new, that's nice. I've noticed two pain points 
though. One of them is that the left-hand side navigation table requires 
Javascript. I wonder if there would be away to expand it fully, or even remove 
it, when Javascript is disabled.

The other one is related, the table of contents in the main page of each 
section 
(https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/v4l2.html 
for instance) only shows the first level entries. We have a full table of 
contents now, and that's very practical to quickly search for the information 
we need without requiring many clicks (or actually any click at all). How can 
we keep that feature ?

By the way, the "Video for Linux API" section (and the other sibling sections) 
are child nodes of the "Introduction" section. That feels quite odd.

-- 
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

[PATCH v2] doc-rst: add an option to ignore DocBooks when generating docs

2016-07-09 Thread Mauro Carvalho Chehab

Sometimes, we want to do a partial build, instead of building
everything. However, right now, if one wants to build just
Sphinx books, it will build also the DocBooks.

Add an option to allow to ignore all DocBooks when building
documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 496d4295ec38..01bab5014a4a 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,6 +6,8 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
+ifeq ($(IGNORE_DOCBOOKS),)
+
 DOCBOOKS := z8530book.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
writing_usb_driver.xml networking.xml \
@@ -215,6 +217,20 @@ silent_gen_xml = :
   -e "s/>/\\>/g"; \
   echo "")  > $@
 
+else
+
+# Needed, due to cleanmediadocs
+include Documentation/DocBook/media/Makefile
+
+htmldocs:
+pdfdocs:
+psdocs:
+xmldocs:
+installmandocs:
+
+endif # IGNORE_DOCBOOKS
+
+
 ###
 # Help targets as used by the top-level makefile
 dochelp:
@@ -229,6 +245,9 @@ dochelp:
@echo
@echo  '  make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs 
s1.xml s2.xml'
@echo  '  valid values for DOCBOOKS are: $(DOCBOOKS)'
+   @echo
+   @echo  "  make IGNORE_DOCBOOKS=1 [target] Don't generate docs from 
Docbook"
+   @echo  ' This is useful to generate only the ReST docs (Sphinx)'
 
 
 ###
-- 
2.7.4

--
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] doc-rst: add an option to ignore DocBooks when generating docs

2016-07-09 Thread Mauro Carvalho Chehab

Sometimes, we want to do a partial build, instead of building
everything. However, right now, if one wants to build just
Sphinx books, it will build also the DocBooks.

Add an option to allow to ignore all DocBooks when building
documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 496d4295ec38..1d322f2d421e 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,6 +6,8 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
+ifeq ($(IGNORE_DOCBOOKS),)
+
 DOCBOOKS := z8530book.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
writing_usb_driver.xml networking.xml \
@@ -17,6 +19,13 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
 
+else # IGNORE_DOCBOOKS
+
+DOCBOOKS = ""
+
+endif # IGNORE_DOCBOOKS
+
+
 include Documentation/DocBook/media/Makefile
 
 ###
@@ -229,6 +238,9 @@ dochelp:
@echo
@echo  '  make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs 
s1.xml s2.xml'
@echo  '  valid values for DOCBOOKS are: $(DOCBOOKS)'
+   @echo
+   @echo  "  make IGNORE_DOCBOOKS=1 [target] Don't generate docs from 
Docbook"
+   @echo  ' This is useful to generate only the ReST docs (Sphinx)'
 
 
 ###
-- 
2.7.4

--
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 RFC] doc-rst: media: reordered top sectioning

2016-07-09 Thread Markus Heiser

From: Markus Heiser 

Within the old section hierarchy, all doc parts has been placed under
the introduction, e.g:

* Linux Media Infrastructure API
+ Introduction
- Video for Linux API
- Digital TV API
- ...

With separating the introduction sibling to the other parts
we get a more common section hierarchy:

* Linux Media Infrastructure API
+ Introduction
+ Video for Linux API
+ Digital TV API
+ ...

BTW: compacting the intro text.

This patch is on top of media_tree/docs-next

Signed-off-by: Markus Heiser 
---
 Documentation/media/intro.rst  | 46 +
 Documentation/media/media_uapi.rst | 53 +-
 2 files changed, 47 insertions(+), 52 deletions(-)
 create mode 100644 Documentation/media/intro.rst

diff --git a/Documentation/media/intro.rst b/Documentation/media/intro.rst
new file mode 100644
index 000..be90bda
--- /dev/null
+++ b/Documentation/media/intro.rst
@@ -0,0 +1,46 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+
+Introduction
+
+
+This document covers the Linux Kernel to Userspace API's used by video
+and radio streaming devices, including video cameras, analog and digital
+TV receiver cards, AM/FM receiver cards, Software Defined Radio (SDR),
+streaming capture and output devices, codec devices and remote controllers.
+
+A typical media device hardware is shown at :ref:`typical_media_device`.
+
+.. _typical_media_device:
+
+.. figure::  media_api_files/typical_media_device.*
+:alt:typical_media_device.svg
+:align:  center
+
+Typical Media Device
+
+The media infrastructure API was designed to control such devices. It is
+divided into five parts.
+
+1. The :ref:`first part ` covers radio, video capture and output,
+   cameras, analog TV devices and codecs.
+
+2. The :ref:`second part ` covers the API used for digital TV and
+   Internet reception via one of the several digital tv standards. While it is
+   called as DVB API, in fact it covers several different video standards
+   including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S, DTMB, etc. The
+   complete list of supported standards can be found at
+   :ref:`fe-delivery-system-t`.
+
+3. The :ref:`third part ` covers the Remote Controller API.
+
+4. The :ref:`fourth part ` covers the Media Controller API.
+
+5. The :ref:`fifth part ` covers the CEC (Consumer Electronics Control) 
API.
+
+It should also be noted that a media device may also have audio components, 
like
+mixers, PCM capture, PCM playback, etc, which are controlled via ALSA API.  For
+additional information and for the latest development code, see:
+`https://linuxtv.org `__.  For discussing improvements,
+reporting troubles, sending new drivers, etc, please mail to: `Linux Media
+Mailing List (LMML) `__.
diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index 49f5cb5..527c6de 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -15,61 +15,10 @@ the license is included in the chapter entitled "GNU Free 
Documentation
 License".
 
 
-
-Introduction
-
-
-This document covers the Linux Kernel to Userspace API's used by video
-and radio streaming devices, including video cameras, analog and digital
-TV receiver cards, AM/FM receiver cards, Software Defined Radio (SDR),
-streaming capture and output devices, codec devices and remote controllers.
-
-A typical media device hardware is shown at
-:ref:`typical_media_device`.
-
-
-.. _typical_media_device:
-
-.. figure::  media_api_files/typical_media_device.*
-:alt:typical_media_device.svg
-:align:  center
-
-Typical Media Device
-
-The media infrastructure API was designed to control such devices. It is
-divided into five parts.
-
-The :ref:`first part ` covers radio, video capture and output,
-cameras, analog TV devices and codecs.
-
-The :ref:`second part ` covers the API used for digital TV and
-Internet reception via one of the several digital tv standards. While it
-is called as DVB API, in fact it covers several different video
-standards including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S,
-DTMB, etc. The complete list of supported standards can be found at
-:ref:`fe-delivery-system-t`.
-
-The :ref:`third part ` covers the Remote Controller API.
-
-The :ref:`fourth part ` covers the Media Controller API.
-
-The :ref:`fifth part ` covers the CEC (Consumer Electronics Control) API.
-
-It should also be noted that a media device may also have audio
-components, like mixers, PCM capture, PCM playback, etc, which are
-controlled via ALSA API.
-
-For additional information and for the latest development code, see:
-`https://linuxtv.org `__.
-
-For discussing improvements, reporting troubles, sending new drivers,
-etc, please mail to:
-`Linux Media Mailing List (LMML).

Re: mceusb xhci issue?

2016-07-09 Thread Mauro Carvalho Chehab

C/C linux-usb Mailing list:


Em Wed, 18 May 2016 08:52:28 -0600
Wade Berrier  escreveu:

> On May 14 20:29, Wade Berrier wrote:
> > On Wed Apr 27 21:07, Sean Young wrote:  
> > > On Mon, Apr 25, 2016 at 09:16:51PM -0600, Wade Berrier wrote:  
> > > > On Apr 25 18:15, Sean Young wrote:  
> > > > > On Sun, Apr 24, 2016 at 10:06:33PM -0600, Wade Berrier wrote:  
> > > > > > Hello,
> > > > > > 
> > > > > > I have a mceusb compatible transceiver that only seems to work with
> > > > > > certain computers.  I'm testing this on centos7 (3.10.0) and 
> > > > > > fedora23
> > > > > > (4.4.7).
> > > > > > 
> > > > > > The only difference I can see is that the working computer shows
> > > > > > "using uhci_hcd" and the non working shows "using xhci_hcd".
> > > > > > 
> > > > > > Here's the dmesg output of the non-working version:
> > > > > > 
> > > > > > -
> > > > > > 
> > > > > > [  217.951079] usb 1-5: new full-speed USB device number 10 using 
> > > > > > xhci_hcd
> > > > > > [  218.104087] usb 1-5: device descriptor read/64, error -71
> > > > > > [  218.371010] usb 1-5: config 1 interface 0 altsetting 0 endpoint 
> > > > > > 0x1 has an invalid bInterval 0, changing to 32
> > > > > > [  218.371019] usb 1-5: config 1 interface 0 altsetting 0 endpoint 
> > > > > > 0x81 has an invalid bInterval 0, changing to 32  
> > > > > 
> > > > > That's odd. Can you post a "lsusb -vvv" of the device please?
> > > > >   
> > > > 
> > > > Sure.
> > > > 
> > > > ---
> > > > 
> > > > Bus 002 Device 009: ID 1784:0006 TopSeed Technology Corp. eHome 
> > > > Infrared Transceiver
> > > > Device Descriptor:
> > > >   bLength18
> > > >   bDescriptorType 1
> > > >   bcdUSB   2.00
> > > >   bDeviceClass0 
> > > >   bDeviceSubClass 0 
> > > >   bDeviceProtocol 0 
> > > >   bMaxPacketSize0 8
> > > >   idVendor   0x1784 TopSeed Technology Corp.
> > > >   idProduct  0x0006 eHome Infrared Transceiver
> > > >   bcdDevice1.02
> > > >   iManufacturer   1 TopSeed Technology Corp.
> > > >   iProduct2 eHome Infrared Transceiver
> > > >   iSerial 3 TS004RrP
> > > >   bNumConfigurations  1
> > > >   Configuration Descriptor:
> > > > bLength 9
> > > > bDescriptorType 2
> > > > wTotalLength   32
> > > > bNumInterfaces  1
> > > > bConfigurationValue 1
> > > > iConfiguration  0 
> > > > bmAttributes 0xa0
> > > >   (Bus Powered)
> > > >   Remote Wakeup
> > > > MaxPower  100mA
> > > > Interface Descriptor:
> > > >   bLength 9
> > > >   bDescriptorType 4
> > > >   bInterfaceNumber0
> > > >   bAlternateSetting   0
> > > >   bNumEndpoints   2
> > > >   bInterfaceClass   255 Vendor Specific Class
> > > >   bInterfaceSubClass255 Vendor Specific Subclass
> > > >   bInterfaceProtocol255 Vendor Specific Protocol
> > > >   iInterface  0 
> > > >   Endpoint Descriptor:
> > > > bLength 7
> > > > bDescriptorType 5
> > > > bEndpointAddress 0x01  EP 1 OUT
> > > > bmAttributes3
> > > >   Transfer TypeInterrupt
> > > >   Synch Type   None
> > > >   Usage Type   Data
> > > > wMaxPacketSize 0x0020  1x 32 bytes
> > > > bInterval   0  
> > > 
> > > That's wrong indeed. It might be interesting to see if there is anything
> > > in the xhci debug messages with (in Fedora 23):
> > > 
> > > echo "file xhci*.c +p" > /sys/kernel/debug/dynamic_debug/control
> > > echo "file mceusb.c +p" > /sys/kernel/debug/dynamic_debug/control
> > > 
> > > And then plug in the receiver, and try to send IR to it with a remote.
> > > You should have quite a few kernel messages in the journal.  
> > 
> > Here's the output after enabling the debug options, plugging in the
> > receiver, running lircd, and pressing some remote buttons:
> >  
> 
> [snip]
> 
> > 
> > I'm not sure what to look for... ?
> >   
> > >   
> > > >   Endpoint Descriptor:
> > > > bLength 7
> > > > bDescriptorType 5
> > > > bEndpointAddress 0x81  EP 1 IN
> > > > bmAttributes3
> > > >   Transfer TypeInterrupt
> > > >   Synch Type   None
> > > >   Usage Type   Data
> > > > wMaxPacketSize 0x0020  1x 32 bytes
> > > > bInterval   0
> > > > Device Status: 0x0001
> > > >   Self Powered
> > > > 
> > > > ---
> > > > 
> > > > Also, here's a link to a response on the lirc list:
> > > > 
> > > > https://sourceforge.net/p/lirc/mailman/message/35039126/  
> > > 
> > > That seems suggest that mode2 works but

Re: [PATCH v2] Add tw5864 driver

2016-07-09 Thread Andrey Utkin

Hi Hans,

Thanks for great help.
I believe the issues highlighted by your are rectified by now.

One chunk of your proposed changes seems to be wrong.

Also I have one non-technical change I want to introduce to this driver, see it
in the bottom of this letter ("Also, I decided to document known video quality
issues in a printed warning...").

On Fri, Jul 01, 2016 at 03:35:40PM +0200, Hans Verkuil wrote:
> On 06/10/2016 12:11 AM, Andrey Utkin wrote:
> > +   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
> 
> This line can be dropped: the v4l2 core will do this automatically.

This seems not so: dropping it resulted in new compliance fails:

Required ioctls:
fail: v4l2-compliance.cpp(550): dcaps & ~caps
test VIDIOC_QUERYCAP: FAIL

Allow for multiple opens:
test second video open: OK
fail: v4l2-compliance.cpp(550): dcaps & ~caps
test VIDIOC_QUERYCAP: FAIL

I am running latest v4l-utils from git.
This particular fail happens on kernels built from next-20160707 and
next-20160609.

BTW next-20160707 makes my dev machine to hang after few minutes of uptime,
regardless of my module being loaded, so for now I am testing driver on
next-20160609.
This (running old linux-next) causes such new fail with latest v4l-utils:

fail: v4l2-test-buffers.cpp(293): g_flags() & V4L2_BUF_FLAG_DONE

which is understandable because of recent commit to v4l-utils flipping expected
behaviour in this regard:

commit 7d784c6894b10cdf5ec025c2cd7c320320f5f658
Author: Hans Verkuil 
Date:   Fri Jul 8 23:10:34 2016 +0200

v4l2-compliance: fix a check for the DONE flag

This was always set by vb2 drivers due to a bug. It is now cleared
again after that bug was fixed, but the test should now be inverted.

Signed-off-by: Hans Verkuil 

diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index fb14170..dc82918 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -290,7 +290,7 @@ int buffer::check(unsigned type, unsigned memory, unsigned 
index,
fail_on_test(g_bytesused(p) > g_length(p));
}
fail_on_test(!g_timestamp().tv_sec && !g_timestamp().tv_usec);
-   fail_on_test(!(g_flags() & V4L2_BUF_FLAG_DONE));
+   fail_on_test(g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test((int)g_sequence() < seq.last_seq + 1);
if (v4l_type_is_video(g_type())) {
fail_on_test(g_field() == V4L2_FIELD_ALTERNATE);

So please expect this fail in v4l2-compliance logs of my new submission.

Also, I decided to document known video quality issues in a printed warning; I
like how it looks now both in code and in dmesg, but checkpatch.pl doesn't like
it. See commit at
https://github.com/bluecherrydvr/linux/commit/83395b6c5e1e5ceb642c9a04a28db5fc22566c87

The message is split in pieces because otherwise it gets truncated.

I'd like some approval or suggestion for rework on this.

It looks like this in dmesg:

[ 5101.182151] tw5864 :06:07.0: BEWARE OF KNOWN ISSUES WITH VIDEO QUALITY

   This driver was developed by Bluecherry LLC by deducing 
behaviour of original manufacturer's driver, from both source code and 
execution traces.
   It is known that there are some artifacts on output video with 
this driver:
- on all known hardware samples: random pixels of wrong color 
(mostly white, red or blue) appearing and disappearing on sequences of P-frames;
- on some hardware samples (known with H.264 core version 
e006:2800): total madness on P-frames: blocks of wrong luminance; blocks of 
wrong colors "creeping" across the picture.
   There is a workaround for both issues: avoid P-frames by setting 
GOP size to 1. To do that, run such command on device files created by this 
driver:

   for dev in /dev/video*; do v4l2-ctl --device $dev 
--set-ctrl=video_gop_size=1; done

[ 5101.357312] systemd-journald[219]: Compressed data object 850 -> 636 using XZ
[ 5101.471071] tw5864 :06:07.0: These issues are not decoding errors; all 
produced H.264 streams are decoded properly. Streams without P-frames don't 
have these artifacts so it's not analog-to-digital conversion issues nor 
internal memory errors; we conclude it's internal H.264 encoder issues.
   We cannot even check the original driver's behaviour because it 
has never worked properly at all in our development environment. So these 
issues may be actually related to firmware or hardware. However it may be that 
there's just some more register settings missing in the driver which would 
please the hardware.
   Manufacturer didn't help much on our inquiries, but feel free to 
disturb again the support of Intersil (owner of former Techwell).

And checkpatch says this:

 $ ./../../../../scripts/checkpatch.pl -f tw5864-core

Re: [ANN] Media documentation converted to ReST markup language

2016-07-09 Thread Mauro Carvalho Chehab

Em Fri, 8 Jul 2016 15:45:52 +0200
Hans Verkuil  escreveu:

> On 07/08/2016 03:34 PM, Mauro Carvalho Chehab wrote:
> > As commented on the patch series I just submitted, we finished the 
> > conversion
> > of the Media uAPI book from DocBook to ReST.
> > 
> > For now, I'm placing the new documentation, after parsed by Sphinx, at this
> > place:
> > https://mchehab.fedorapeople.org/media_API_book/
> > 
> > There are some instructions there about how to use Sphinx too, with can be
> > useful for the ones writing patches. Those are part of the docs-next that
> > will be sent to Kernel 4.8, thanks to Jani Nikula an Jonathan Corbet.
> > 
> > The media docbook itself is located at:
> > https://mchehab.fedorapeople.org/media_API_book/linux_tv/index.html
> > 
> > And the patches are already at the media tree, under the "docs-next"
> > branch:
> > https://git.linuxtv.org/media_tree.git/log/?h=docs-next
> > 
> > If you find anything inconsistent, wrong or incomplete, feel free to
> > submit patches to it. My plan is to merge this branch on Kernel 4.8-rc1
> > and then remove the Documentation/DocBook/media stuff from the Kernel.
> > 
> > PS.: I'll soon be adding one extra patch there renaming the media
> > directory. "linux_tv" is not the best name for the media contents,
> > but, on the other hand, having a "media/media" directory also doesn't
> > make sense. So, I need to think for a better name before doing the
> > change. Pehaps I'll go for:
> > Documentation/media - for all media documentation, were we
> > should also store things that are now under 
> > /video4linux and under /dvb;
> > 
> > and:
> > Documentation/media/uapi - for the above book that were just
> > converted from DocBook.  
> 
> Sounds good to me!

I'm placing the ReST version of the document under:
https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html

For now, I'm updating it manually, as, currently, there's no way to
tell the Kernel build system to build just the media uAPI book.

Thanks,
Mauro
--
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] [media] doc-rst: make CEC look more like other parts of the book

2016-07-09 Thread Mauro Carvalho Chehab

Better organize the contents of the CEC part, moving the
introduction to chapter 1, placing all ioctls at chapter 2
and numerating all chapters and items.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/cec/cec-api.rst   | 60 +++---
 Documentation/media/uapi/cec/cec-funcs.rst | 21 +++
 Documentation/media/uapi/cec/cec-intro.rst | 31 +++
 3 files changed, 57 insertions(+), 55 deletions(-)
 create mode 100644 Documentation/media/uapi/cec/cec-funcs.rst
 create mode 100644 Documentation/media/uapi/cec/cec-intro.rst

diff --git a/Documentation/media/uapi/cec/cec-api.rst 
b/Documentation/media/uapi/cec/cec-api.rst
index f40103fefddc..e7dc8253f1e2 100644
--- a/Documentation/media/uapi/cec/cec-api.rst
+++ b/Documentation/media/uapi/cec/cec-api.rst
@@ -10,65 +10,15 @@ CEC API
 
 .. _cec-api:
 
-*
-CEC: Consumer Electronics Control
-*
-
-
-.. _cec-intro:
-
-Introduction
-
-
-Note: this documents the proposed CEC API. This API is not yet finalized
-and is currently only available as a staging kernel module.
-
-HDMI connectors provide a single pin for use by the Consumer Electronics
-Control protocol. This protocol allows different devices connected by an
-HDMI cable to communicate. The protocol for CEC version 1.4 is defined
-in supplements 1 (CEC) and 2 (HEAC or HDMI Ethernet and Audio Return
-Channel) of the HDMI 1.4a (:ref:`hdmi`) specification and the
-extensions added to CEC version 2.0 are defined in chapter 11 of the
-HDMI 2.0 (:ref:`hdmi2`) specification.
-
-The bitrate is very slow (effectively no more than 36 bytes per second)
-and is based on the ancient AV.link protocol used in old SCART
-connectors. The protocol closely resembles a crazy Rube Goldberg
-contraption and is an unholy mix of low and high level messages. Some
-messages, especially those part of the HEAC protocol layered on top of
-CEC, need to be handled by the kernel, others can be handled either by
-the kernel or by userspace.
-
-In addition, CEC can be implemented in HDMI receivers, transmitters and
-in USB devices that have an HDMI input and an HDMI output and that
-control just the CEC pin.
-
-Drivers that support CEC will create a CEC device node (/dev/cecX) to
-give userspace access to the CEC adapter. The
-:ref:`CEC_ADAP_G_CAPS` ioctl will tell
-userspace what it is allowed to do.
-
-
-.. _cec-user-func:
-
-**
-Function Reference
-**
-
+This part describes the CEC: Consumer Electronics Control
 
 .. toctree::
 :maxdepth: 1
+:numbered:
+:caption: Table of Contents
 
-cec-func-open
-cec-func-close
-cec-func-ioctl
-cec-func-poll
-cec-ioc-adap-g-caps
-cec-ioc-adap-g-log-addrs
-cec-ioc-adap-g-phys-addr
-cec-ioc-dqevent
-cec-ioc-g-mode
-cec-ioc-receive
+cec-intro
+cec-funcs
 cec-header
 
 
diff --git a/Documentation/media/uapi/cec/cec-funcs.rst 
b/Documentation/media/uapi/cec/cec-funcs.rst
new file mode 100644
index ..5b7630f2e076
--- /dev/null
+++ b/Documentation/media/uapi/cec/cec-funcs.rst
@@ -0,0 +1,21 @@
+.. _cec-user-func:
+
+**
+Function Reference
+**
+
+
+.. toctree::
+:maxdepth: 1
+:numbered:
+
+cec-func-open
+cec-func-close
+cec-func-ioctl
+cec-func-poll
+cec-ioc-adap-g-caps
+cec-ioc-adap-g-log-addrs
+cec-ioc-adap-g-phys-addr
+cec-ioc-dqevent
+cec-ioc-g-mode
+cec-ioc-receive
diff --git a/Documentation/media/uapi/cec/cec-intro.rst 
b/Documentation/media/uapi/cec/cec-intro.rst
new file mode 100644
index ..d6a878866b3f
--- /dev/null
+++ b/Documentation/media/uapi/cec/cec-intro.rst
@@ -0,0 +1,31 @@
+.. _cec-intro:
+
+Introduction
+
+
+Note: this documents the proposed CEC API. This API is not yet finalized
+and is currently only available as a staging kernel module.
+
+HDMI connectors provide a single pin for use by the Consumer Electronics
+Control protocol. This protocol allows different devices connected by an
+HDMI cable to communicate. The protocol for CEC version 1.4 is defined
+in supplements 1 (CEC) and 2 (HEAC or HDMI Ethernet and Audio Return
+Channel) of the HDMI 1.4a (:ref:`hdmi`) specification and the
+extensions added to CEC version 2.0 are defined in chapter 11 of the
+HDMI 2.0 (:ref:`hdmi2`) specification.
+
+The bitrate is very slow (effectively no more than 36 bytes per second)
+and is based on the ancient AV.link protocol used in old SCART
+connectors. The protocol closely resembles a crazy Rube Goldberg
+contraption and is an unholy mix of low and high level messages. Some
+messages, especially those part of the HEAC protocol layered on top of
+CEC, need to be handled by the kernel, others can be handled either by
+the kernel or by userspace.
+
+In addition, CEC can be implemented in HDMI receivers, transmitters and
+in USB devices that have an HDMI input and an HDMI o

[PATCH] [media] doc-rst: add CEC header file to the documentation

2016-07-09 Thread Mauro Carvalho Chehab

Adding the header file is interesting for several reasons:

1) It makes MC documentation consistend with other parts;
2) The header file can be used as a quick index to all API
   elements;
3) The cross-reference check helps to identify symbols that
   aren't documented.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/Makefile   |   6 +-
 Documentation/media/cec.h.rst.exceptions   | 492 +
 Documentation/media/uapi/cec/cec-api.rst   |   1 +
 Documentation/media/uapi/cec/cec-header.rst|  10 +
 .../media/uapi/cec/cec-ioc-adap-g-caps.rst |  12 +-
 .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst|  54 +--
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  14 +-
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst|  58 +--
 Documentation/media/uapi/cec/cec-ioc-receive.rst   |  32 +-
 9 files changed, 593 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/media/cec.h.rst.exceptions
 create mode 100644 Documentation/media/uapi/cec/cec-header.rst

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index cfab8e4f36e1..bcb9eb5921aa 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -2,10 +2,11 @@
 
 PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
 UAPI = $(srctree)/include/uapi/linux
+KAPI = $(srctree)/include/linux
 SRC_DIR=$(srctree)/Documentation/media
 
 FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \
- videodev2.h.rst media.h.rst
+ videodev2.h.rst media.h.rst cec.h.rst
 
 TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
 
@@ -49,5 +50,8 @@ $(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} 
$(SRC_DIR)/videodev2.
 $(BUILDDIR)/media.h.rst: ${UAPI}/media.h ${PARSER} 
$(SRC_DIR)/media.h.rst.exceptions
@$($(quiet)gen_rst)
 
+$(BUILDDIR)/cec.h.rst: ${KAPI}/cec.h ${PARSER} $(SRC_DIR)/cec.h.rst.exceptions
+   @$($(quiet)gen_rst)
+
 cleandocs:
-rm ${TARGETS}
diff --git a/Documentation/media/cec.h.rst.exceptions 
b/Documentation/media/cec.h.rst.exceptions
new file mode 100644
index ..b79339433718
--- /dev/null
+++ b/Documentation/media/cec.h.rst.exceptions
@@ -0,0 +1,492 @@
+# Ignore header name
+ignore define _CEC_UAPI_H
+
+# Rename some symbols, to avoid namespace conflicts
+replace struct cec_event_state_change cec-event-state-change_s
+replace struct cec_event_lost_msgs cec-event-lost-msgs_s
+replace enum cec_mode_initiator cec-mode-initiator_e
+replace enum cec_mode_follower cec-mode-follower_e
+
+# define macros to ignore
+
+ignore define CEC_MAX_MSG_SIZE
+ignore define CEC_MAX_LOG_ADDRS
+
+ignore define CEC_LOG_ADDR_MASK_TV
+ignore define CEC_LOG_ADDR_MASK_RECORD
+ignore define CEC_LOG_ADDR_MASK_TUNER
+ignore define CEC_LOG_ADDR_MASK_PLAYBACK
+ignore define CEC_LOG_ADDR_MASK_AUDIOSYSTEM
+ignore define CEC_LOG_ADDR_MASK_BACKUP
+ignore define CEC_LOG_ADDR_MASK_SPECIFIC
+ignore define CEC_LOG_ADDR_MASK_UNREGISTERED
+
+# Shouldn't them be documented?
+ignore define CEC_LOG_ADDR_INVALID
+ignore define CEC_PHYS_ADDR_INVALID
+
+ignore define CEC_VENDOR_ID_NONE
+
+ignore define CEC_MODE_INITIATOR_MSK
+ignore define CEC_MODE_FOLLOWER_MSK
+
+ignore define CEC_EVENT_FL_INITIAL_STATE
+
+# Part of CEC 2.0 spec - shouldn't be documented too?
+ignore define CEC_LOG_ADDR_TV
+ignore define CEC_LOG_ADDR_RECORD_1
+ignore define CEC_LOG_ADDR_RECORD_2
+ignore define CEC_LOG_ADDR_TUNER_1
+ignore define CEC_LOG_ADDR_PLAYBACK_1
+ignore define CEC_LOG_ADDR_AUDIOSYSTEM
+ignore define CEC_LOG_ADDR_TUNER_2
+ignore define CEC_LOG_ADDR_TUNER_3
+ignore define CEC_LOG_ADDR_PLAYBACK_2
+ignore define CEC_LOG_ADDR_RECORD_3
+ignore define CEC_LOG_ADDR_TUNER_4
+ignore define CEC_LOG_ADDR_PLAYBACK_3
+ignore define CEC_LOG_ADDR_BACKUP_1
+ignore define CEC_LOG_ADDR_BACKUP_2
+ignore define CEC_LOG_ADDR_SPECIFIC
+ignore define CEC_LOG_ADDR_UNREGISTERED
+ignore define CEC_LOG_ADDR_BROADCAST
+
+# IMHO, those should also be documented
+
+ignore define CEC_MSG_ACTIVE_SOURCE
+ignore define CEC_MSG_IMAGE_VIEW_ON
+ignore define CEC_MSG_TEXT_VIEW_ON
+
+ignore define CEC_MSG_INACTIVE_SOURCE
+ignore define CEC_MSG_REQUEST_ACTIVE_SOURCE
+ignore define CEC_MSG_ROUTING_CHANGE
+ignore define CEC_MSG_ROUTING_INFORMATION
+ignore define CEC_MSG_SET_STREAM_PATH
+
+ignore define CEC_MSG_STANDBY
+
+ignore define CEC_MSG_RECORD_OFF
+ignore define CEC_MSG_RECORD_ON
+
+ignore define CEC_OP_RECORD_SRC_OWN
+ignore define CEC_OP_RECORD_SRC_DIGITAL
+ignore define CEC_OP_RECORD_SRC_ANALOG
+ignore define CEC_OP_RECORD_SRC_EXT_PLUG
+ignore define CEC_OP_RECORD_SRC_EXT_PHYS_ADDR
+
+ignore define CEC_OP_SERVICE_ID_METHOD_BY_DIG_ID
+ignore define CEC_OP_SERVICE_ID_METHOD_BY_CHANNEL
+
+ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_GEN
+ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_GEN
+ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_DVB_GEN
+ignore define CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ARIB_BS
+ignore define CEC_OP_DIG_SERVICE_BCAS

[linuxtv-media:master 326/383] warning: (VIDEO_MEDIATEK_VCODEC && ..) selects VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && ..)

2016-07-09 Thread kbuild test robot

tree:   git://linuxtv.org/media_tree.git master
head:   9ad52b4db79d168867a2ca105eca00fb9cb28fe5
commit: c1023ba74fc77dc56dc317bd98f5060aab889ac1 [326/383] [media] 
drivers/media/platform/Kconfig: fix VIDEO_MEDIATEK_VCODEC dependency
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1023ba74fc77dc56dc317bd98f5060aab889ac1
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

warning: (VIDEO_MEDIATEK_VCODEC && VIDEO_DM365_VPFE && VIDEO_OMAP4) selects 
VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && 
HAS_DMA)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 3/3] [media] doc-rst: add media.h header to media contrller

2016-07-09 Thread Mauro Carvalho Chehab

Adding the header file is interesting for several reasons:

1) It makes MC documentation consistend with other parts;
2) The header file can be used as a quick index to all API
   elements;
3) The cross-reference check helps to identify symbols that
   aren't documented.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/Makefile   |   5 +-
 Documentation/media/media.h.rst.exceptions |  30 ++
 .../media/uapi/mediactl/media-controller.rst   |   2 +-
 Documentation/media/uapi/mediactl/media-header.rst |  10 ++
 .../media/uapi/mediactl/media-ioc-device-info.rst  |   2 +-
 .../uapi/mediactl/media-ioc-enum-entities.rst  |   4 +-
 .../media/uapi/mediactl/media-ioc-enum-links.rst   |   8 +-
 .../media/uapi/mediactl/media-ioc-g-topology.rst   |   2 +-
 .../media/uapi/mediactl/media-ioc-setup-link.rst   |   2 +-
 Documentation/media/uapi/mediactl/media-types.rst  | 117 -
 10 files changed, 170 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/media/media.h.rst.exceptions
 create mode 100644 Documentation/media/uapi/mediactl/media-header.rst

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 0efd91e9998b..cfab8e4f36e1 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -5,7 +5,7 @@ UAPI = $(srctree)/include/uapi/linux
 SRC_DIR=$(srctree)/Documentation/media
 
 FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \
- videodev2.h.rst
+ videodev2.h.rst media.h.rst
 
 TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
 
@@ -46,5 +46,8 @@ $(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} 
$(SRC_DIR)/video.h.rst.ex
 $(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} 
$(SRC_DIR)/videodev2.h.rst.exceptions
@$($(quiet)gen_rst)
 
+$(BUILDDIR)/media.h.rst: ${UAPI}/media.h ${PARSER} 
$(SRC_DIR)/media.h.rst.exceptions
+   @$($(quiet)gen_rst)
+
 cleandocs:
-rm ${TARGETS}
diff --git a/Documentation/media/media.h.rst.exceptions 
b/Documentation/media/media.h.rst.exceptions
new file mode 100644
index ..83d7f7c722fb
--- /dev/null
+++ b/Documentation/media/media.h.rst.exceptions
@@ -0,0 +1,30 @@
+# Ignore header name
+ignore define __LINUX_MEDIA_H
+
+# Ignore macros
+ignore define MEDIA_API_VERSION
+ignore define MEDIA_ENT_F_BASE
+ignore define MEDIA_ENT_F_OLD_BASE
+ignore define MEDIA_ENT_F_OLD_SUBDEV_BASE
+ignore define MEDIA_INTF_T_DVB_BASE
+ignore define MEDIA_INTF_T_V4L_BASE
+ignore define MEDIA_INTF_T_ALSA_BASE
+
+#ignore legacy entity type macros
+ignore define MEDIA_ENT_TYPE_SHIFT
+ignore define MEDIA_ENT_TYPE_MASK
+ignore define MEDIA_ENT_SUBTYPE_MASK
+ignore define MEDIA_ENT_T_DEVNODE_UNKNOWN
+ignore define MEDIA_ENT_T_DEVNODE
+ignore define MEDIA_ENT_T_DEVNODE_V4L
+ignore define MEDIA_ENT_T_DEVNODE_FB
+ignore define MEDIA_ENT_T_DEVNODE_ALSA
+ignore define MEDIA_ENT_T_DEVNODE_DVB
+ignore define MEDIA_ENT_T_UNKNOWN
+ignore define MEDIA_ENT_T_V4L2_VIDEO
+ignore define MEDIA_ENT_T_V4L2_SUBDEV
+ignore define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR
+ignore define MEDIA_ENT_T_V4L2_SUBDEV_FLASH
+ignore define MEDIA_ENT_T_V4L2_SUBDEV_LENS
+ignore define MEDIA_ENT_T_V4L2_SUBDEV_DECODER
+ignore define MEDIA_ENT_T_V4L2_SUBDEV_TUNER
diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
b/Documentation/media/uapi/mediactl/media-controller.rst
index 8758308997a7..0c1296c59571 100644
--- a/Documentation/media/uapi/mediactl/media-controller.rst
+++ b/Documentation/media/uapi/mediactl/media-controller.rst
@@ -22,7 +22,7 @@ Media Controller
 media-controller-intro
 media-controller-model
 media-types
-
+media-header
 
 .. _media-user-func:
 
diff --git a/Documentation/media/uapi/mediactl/media-header.rst 
b/Documentation/media/uapi/mediactl/media-header.rst
new file mode 100644
index ..96f7b0155e5a
--- /dev/null
+++ b/Documentation/media/uapi/mediactl/media-header.rst
@@ -0,0 +1,10 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _media_header:
+
+
+Media Controller Header File
+
+
+.. kernel-include:: $BUILDDIR/media.h.rst
+
diff --git a/Documentation/media/uapi/mediactl/media-ioc-device-info.rst 
b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
index cee8312bde7d..467d82cbb81e 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _media-ioc-device-info:
+.. _media_ioc_device_info:
 
 ***
 ioctl MEDIA_IOC_DEVICE_INFO
diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst 
b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
index ae88f46b3a9e..12d4b25d5b94 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
@@ -1,6 +1,6 @@
 .. -*- coding:

[PATCH 2/3] doc-rst: parse-headers: remove trailing spaces

2016-07-09 Thread Mauro Carvalho Chehab

The function that replace references add a "\ " at the end of
references, to avoid the ReST markup parser to not identify
them as references. That works fine except for the end of lines,
as a sequence of { '\', ' ', '\n' } characters makes Sphinx
to ignore the end of line. So, strip those escape/spaces at the
end of lines.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/sphinx/parse-headers.pl | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/sphinx/parse-headers.pl 
b/Documentation/sphinx/parse-headers.pl
index 0a3703bef5eb..34bd9e2630b0 100755
--- a/Documentation/sphinx/parse-headers.pl
+++ b/Documentation/sphinx/parse-headers.pl
@@ -303,6 +303,8 @@ foreach my $r (keys %typedefs) {
$data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
 }
 
+$data =~ s/\\ \n/\n/g;
+
 #
 # Generate output file
 #
-- 
2.7.4

--
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 1/3] [media] doc-rst: Add new types to media-types.rst

2016-07-09 Thread Mauro Carvalho Chehab

Changesets:
eaa0b96bbb65 ("[media] media: Add video statistics computation 
functions")
and
1179aab13db3 ("[media] media: Add video processing entity functions")

added some new elements to the "media entity types" table at the
DocBook. We need to do the same at the reST version, in order to
keep it in sync with the DocBook version.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/mediactl/media-types.rst | 69 +++
 1 file changed, 69 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index a35fc15a3137..a2932bfef20f 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -166,6 +166,75 @@ Types and flags used to represent the media graph elements
 
-  Audio Mixer Function Entity.
 
+-  .. row 23
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_COMPOSER``
+
+   -  Video composer (blender). An entity capable of video
+ composing must have at least two sink pads and one source
+ pad, and composes input video frames onto output video
+ frames. Composition can be performed using alpha blending,
+ color keying, raster operations (ROP), stitching or any other
+ means.
+
+-  ..  row 24
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER``
+
+   -  Video pixel formatter. An entity capable of pixel formatting
+ must have at least one sink pad and one source pad. Read
+ pixel formatters read pixels from memory and perform a subset
+ of unpacking, cropping, color keying, alpha multiplication
+ and pixel encoding conversion. Write pixel formatters perform
+ a subset of dithering, pixel encoding conversion and packing
+ and write pixels to memory.
+
+-  ..  row 25
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV``
+
+   -  Video pixel encoding converter. An entity capable of pixel
+ enconding conversion must have at least one sink pad and one
+ source pad, and convert the encoding of pixels received on
+ its sink pad(s) to a different encoding output on its source
+ pad(s). Pixel encoding conversion includes but isn't limited
+ to RGB to/from HSV, RGB to/from YUV and CFA (Bayer) to RGB
+ conversions.
+
+-  ..  row 26
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_LUT``
+
+   -  Video look-up table. An entity capable of video lookup table
+ processing must have one sink pad and one source pad. It uses
+ the values of the pixels received on its sink pad to look up
+ entries in internal tables and output them on its source pad.
+ The lookup processing can be performed on all components
+ separately or combine them for multi-dimensional table
+ lookups.
+
+-  ..  row 27
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_SCALER``
+
+   -  Video scaler. An entity capable of video scaling must have
+ at least one sink pad and one source pad, and scale the
+ video frame(s) received on its sink pad(s) to a different
+ resolution output on its source pad(s). The range of
+ supported scaling ratios is entity-specific and can differ
+ between the horizontal and vertical directions (in particular
+ scaling can be supported in one direction only). Binning and
+ skipping are considered as scaling.
+
+-  ..  row 28
+
+   -  ``MEDIA_ENT_F_PROC_VIDEO_STATISTICS``
+
+   -  Video statistics computation (histogram, 3A, ...). An entity
+ capable of statistics computation must have one sink pad and
+ one source pad. It computes statistics over the frames
+ received on its sink pad and outputs the statistics data on
+ its source pad.
 
 
 .. _media-entity-flag:
-- 
2.7.4

--
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] media: s5p-mfc fix invalid memory access from s5p_mfc_release()

2016-07-09 Thread Luis de Bethencourt

On 08/07/16 23:29, Shuah Khan wrote:
> If s5p_mfc_release() runs after s5p_mfc_remove(), the former will access
> invalid s5p_mfc_dev pointer saved in the s5p_mfc_ctx and runs into kernel
> paging request errors.
> 
> Clear ctx dev pointer in s5p_mfc_remove() and change s5p_mfc_release() to
> avoid work that requires ctx->dev.
> 
> odroid kernel: Unable to handle kernel paging request at virtual address
> f17c1104
> odroid kernel: pgd = ebca4000
> odroid kernel: [f17c1104] *pgd=6e23d811, *pte=, *ppte=
> odroid kernel: Internal error: Oops: 807 [#1] PREEMPT SMP ARM
> odroid kernel: Modules linked in: cpufreq_userspace cpufreq_powersave
> cpufreq_conservative s5p_mfc s5p_jpeg v4l2_mem2mem
> videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core
> v4l2_common videodev media
> odroid kernel: Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> odroid kernel: task: c2241400 ti: e7018000 task.ti: e7018000
> odroid kernel: PC is at s5p_mfc_reset+0x40/0x28c [s5p_mfc]
> odroid kernel: LR is at s5p_mfc_reset+0x34/0x28c [s5p_mfc]
> odroid kernel: pc : []lr : [] psr: 60010013
> odroid kernel: [] (s5p_mfc_reset [s5p_mfc]) from []
> (s5p_mfc_deinit_hw+0x14/0x3c [s5p_mfc])
> odroid kernel: [] (s5p_mfc_deinit_hw [s5p_mfc]) from []
> (s5p_mfc_release+0xac/0x1c4 [s5p_mfc])
> odroid kernel: [] (s5p_mfc_release [s5p_mfc]) from []
> (v4l2_release+0x38/0x74 [videodev])
> odroid kernel: [] (v4l2_release [videodev]) from []
> (__fput+0x80/0x1c8)
> odroid kernel: [] (__fput) from []
> (task_work_run+0x94/0xc8)
> odroid kernel: [] (task_work_run) from []
> (do_work_pending+0x7c/0xa4)
> odroid kernel: [] (do_work_pending) from []
> (slow_work_pending+0xc/0x20)
> odroid kernel: Code: eb3edacc e5953078 e3a06000 e2833c11 (e5836004)
> 
> Signed-off-by: Shuah Khan 
> ---

Thanks Shuah.

I've been following this while playing with an ODROID XU4 to fix some issues
in v4l2 usage in GStreamer. So I offered Shuah to test this for her.

Looks good :)

Tested-by: Luis de Bethencourt 
--
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: doc-rst: too much space around ``foo`` text

2016-07-09 Thread Markus Heiser

Hi Hans,

Am 08.07.2016 um 22:52 schrieb Hans Verkuil :

> Hi Markus,
> 
> First of all a big 'Thank you!' for working on this, very much appreciated.
> And I also am very grateful that you could convert the CEC docs so quickly 
> for me.

You are welcome :)

> That said, can you take a look at this:
> 
> https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/vidioc-enum-fmt.html
> 
> As you can see, every text written as ``foo`` in the rst file has a bit too 
> much space
> around it. It's especially clear in the description of the 'type' field: the 
> commas
> after each V4L2_BUF_TYPE_ constant should be right after the last character, 
> and now
> it looks as if there is a space in front.
> 
> It's jarring when you read it, but it is probably easy to fix for someone who 
> knows
> this stuff.

Yes, this is a good point, the layout of inline constant markup bothers me also.
The Read-The-Doc (RTD) theme we use is IMHO the best on the web, since it is 
well
maintained and supports a good layout on various viewports:

  http://read-the-docs.readthedocs.io/en/latest/theme.html

Nevertheless I think in some details it is a bit to excessive.

I will place it on my TODO list .. hopefully I find the time to solve
it in the next days.

-- Markus --

> 
> Thanks!
> 
>   Hans

--
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 v2] zc3xx: Remove deprecated create_singlethread_workqueue

2016-07-09 Thread Bhaktipriya Shridhar

The workqueue "work_thread" is involved in updating parameters for
transfers. It has a single work item(&sd->work) and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path. Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v2:
-Added call to flush_work

 drivers/media/usb/gspca/zc3xx.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/gspca/zc3xx.c b/drivers/media/usb/gspca/zc3xx.c
index c5d8ee6..5f7254d 100644
--- a/drivers/media/usb/gspca/zc3xx.c
+++ b/drivers/media/usb/gspca/zc3xx.c
@@ -53,7 +53,6 @@ struct sd {
struct v4l2_ctrl *jpegqual;

struct work_struct work;
-   struct workqueue_struct *work_thread;

u8 reg08;   /* webcam compression quality */

@@ -6826,8 +6825,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
return gspca_dev->usb_err;

/* Start the transfer parameters update thread */
-   sd->work_thread = create_singlethread_workqueue(KBUILD_MODNAME);
-   queue_work(sd->work_thread, &sd->work);
+   schedule_work(&sd->work);

return 0;
 }
@@ -6838,12 +6836,9 @@ static void sd_stop0(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;

-   if (sd->work_thread != NULL) {
-   mutex_unlock(&gspca_dev->usb_lock);
-   destroy_workqueue(sd->work_thread);
-   mutex_lock(&gspca_dev->usb_lock);
-   sd->work_thread = NULL;
-   }
+   mutex_unlock(&gspca_dev->usb_lock);
+   flush_work(&sd->work);
+   mutex_lock(&gspca_dev->usb_lock);
if (!gspca_dev->present)
return;
send_unknown(gspca_dev, sd->sensor);
--
2.1.4

--
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 2/2] mtk-vcodec: fix compiler warning

2016-07-09 Thread Hans Verkuil

From: Hans Verkuil 

mtk-vcodec/venc_vpu_if.c:40:30: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  struct venc_vpu_inst *vpu = (struct venc_vpu_inst *)msg->venc_inst;
  ^

Note: venc_inst is u64.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index b92c6d2..a01c759 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -37,7 +37,8 @@ static void handle_enc_encode_msg(struct venc_vpu_inst *vpu, 
void *data)
 static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
 {
struct venc_vpu_ipi_msg_common *msg = data;
-   struct venc_vpu_inst *vpu = (struct venc_vpu_inst *)msg->venc_inst;
+   struct venc_vpu_inst *vpu =
+   (struct venc_vpu_inst *)(unsigned long)msg->venc_inst;
 
mtk_vcodec_debug(vpu, "msg_id %x inst %p status %d",
 msg->msg_id, vpu, msg->status);
-- 
2.8.1

--
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 1/2] mtk-vcodec: fix two compiler warnings

2016-07-09 Thread Hans Verkuil

From: Hans Verkuil 

mtk-vcodec/mtk_vcodec_enc.c: In function 'mtk_venc_worker':
mtk-vcodec/mtk_vcodec_enc.c:1030:43: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}' 
[-Wformat=]
mtk-vcodec/mtk_vcodec_enc.c:1030:43: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned int}' 
[-Wformat=]

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 6dcae0a..907a6d1 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1028,7 +1028,7 @@ static void mtk_venc_worker(struct work_struct *work)
bs_buf.size = (size_t)dst_buf->planes[0].length;
 
mtk_v4l2_debug(2,
-   "Framebuf VA=%p PA=%llx Size=0x%lx;VA=%p PA=0x%llx 
Size=0x%lx;VA=%p PA=0x%llx Size=%zu",
+   "Framebuf VA=%p PA=%llx Size=0x%zx;VA=%p PA=0x%llx 
Size=0x%zx;VA=%p PA=0x%llx Size=%zu",
frm_buf.fb_addr[0].va,
(u64)frm_buf.fb_addr[0].dma_addr,
frm_buf.fb_addr[0].size,
-- 
2.8.1

--
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] doc-rst: add an option to ignore DocBooks when generating docs

cron job: media_tree daily build: ERRORS

[PATCH] media: solo6x10: increase FRAME_BUF_SIZE

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

Re: si2157: new revision?

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

Re: [PATCH 06/11] media: adv7180: add bt.656-4 OF property

Re: si2157: new revision?

Re: [PATCH 06/11] media: adv7180: add bt.656-4 OF property

[PATCH] [media] cec: Fix anonymous union initialization with older toolchains.

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

Re: [PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

Re: [PATCH 06/11] media: adv7180: add bt.656-4 OF property

Re: [PATCH 02/11] Revert "[media] adv7180: fix broken standards handling"

Re: [PATCH v5 3/4] ARM: dts: koelsch: add HDMI input

Re: [ANN] Media documentation converted to ReST markup language

[PATCH v2] doc-rst: add an option to ignore DocBooks when generating docs

[PATCH] doc-rst: add an option to ignore DocBooks when generating docs

[PATCH RFC] doc-rst: media: reordered top sectioning

Re: mceusb xhci issue?

Re: [PATCH v2] Add tw5864 driver

Re: [ANN] Media documentation converted to ReST markup language

[PATCH] [media] doc-rst: make CEC look more like other parts of the book

[PATCH] [media] doc-rst: add CEC header file to the documentation

[linuxtv-media:master 326/383] warning: (VIDEO_MEDIATEK_VCODEC && ..) selects VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && ..)

[PATCH 3/3] [media] doc-rst: add media.h header to media contrller

[PATCH 2/3] doc-rst: parse-headers: remove trailing spaces

[PATCH 1/3] [media] doc-rst: Add new types to media-types.rst

Re: [PATCH] media: s5p-mfc fix invalid memory access from s5p_mfc_release()

Re: doc-rst: too much space around ``foo`` text

[PATCH v2] zc3xx: Remove deprecated create_singlethread_workqueue

[PATCH 2/2] mtk-vcodec: fix compiler warning

[PATCH 1/2] mtk-vcodec: fix two compiler warnings

35 matches

Site Navigation

Mail list logo

Footer information