cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Jul 13 04:00:22 CEST 2016
git branch: test
git hash:   25f1ec2462f4afe544c9374ef4dbb4f5f0a3b701
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-multi: 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: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
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: ERRORS
linux-4.0-i686: ERRORS
linux-4.1.1-i686: ERRORS
linux-4.2-i686: ERRORS
linux-4.3-i686: ERRORS
linux-4.4-i686: ERRORS
linux-4.5-i686: ERRORS
linux-4.6-i686: ERRORS
linux-4.7-rc1-i686: ERRORS
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
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: ERRORS
linux-4.0-x86_64: ERRORS
linux-4.1.1-x86_64: ERRORS
linux-4.2-x86_64: ERRORS
linux-4.3-x86_64: ERRORS
linux-4.4-x86_64: ERRORS
linux-4.5-x86_64: ERRORS
linux-4.6-x86_64: ERRORS
linux-4.7-rc1-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[李務誠]

On Wed, Jul 13, 2016 at 3:14 AM, Nicolas Dufresne
 wrote:
> Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit :
>> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :
>> > Decoder hardware produces MT21 (compressed). Image processor can
>> > convert it to a format that can be input of display driver.
>> > Tiffany.
>> > When do you plan to upstream image processor (mtk-mdp)?
>> > >
>> > > It can be as input format for encoder, MDP and display drivers in
>> > our
>> > > platform.
>> > I remember display driver can only accept uncompressed MT21. Right?
>> > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
>> > format. It's not usable until it's decompressed and converted by
>> > image
>> > processor.
>>
>> Previously it was described as MediaTek block mode, and now as a
>> MediaTek compressed format. It makes me think you have no idea what
>> this pixel format really is. Is that right ?
>>
>> The main reason why I keep asking, is that we often find similarities
>> between what vendor like to call their proprietary formats. Doing the
>> proper research helps not creating a mess like in Android where you
>> have a lot of formats that all point to the same format. I believe
>> there was the same concern when Samsung wanted to introduce their Z-
>> flip-Z NV12 tile format. In the end they simply provided sufficient
>> documentation so we could document it and implement software
>> converters
>> for test and validation purpose.
>
> Here's the kind of information we want in the documentation.
>
> https://chromium.googlesource.com/chromium/src/media/+/master/base/vide
> o_types.h#40
That is the documentation of decompressed MT21. Originally MT21 was meant
to be a YUV format and we can map it in CPU to use it. The name was changed
to mean a compressed format. The current design is only MTK image processor
can convert it. Software cannot decompress it. I'm not sure if we
should document
the format inside if we cannot decompress in software. For chromium, I'll update
the code to explain MT21 is an opaque compressed format.
>
>   // MediaTek proprietary format. MT21 is similar to NV21 except the memory
>   // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2
>   // interleaved VU plane. Each image contains two buffers -- Y plane and VU
>   // plane. Two planes can be non-contiguous in memory. The starting addresses
>   // of Y plane and VU plane are 4KB alignment.
>   // Suppose image dimension is (width, height). For both Y plane and VU 
> plane:
>   // Row pitch = ((width+15)/16) * 16.
>   // Plane size = Row pitch * (((height+31)/32)*32)
>
> Now obviously this is incomplete, as the swizzling need to be documented of 
> course.
>
>>
>> regards,
>> Nicolas
--
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 v4] [media] pci: Add tw5864 driver - fixed few style nits, going to resubmit soon

[Andrey Utkin]

Found and fixed few very minor coding style nits, will resubmit in few days,
now still waiting for comments to v4.

https://github.com/bluecherrydvr/linux/commits/tw5864

commit 31f7c98a144cb3fb8a94662f002d9b6142d1f390
Author: Andrey Utkin 
Date:   Wed Jul 13 05:00:28 2016 +0300

Fix checkpatch --strict issue

 CHECK: Alignment should match open parenthesis
 #3599: FILE: drivers/media/pci/tw5864/tw5864-video.c:539:
 +static int tw5864_fmt_vid_cap(struct file *file, void *priv,
 +   struct v4l2_format *f)

commit 11a09a1048af597ecf374507b08c809eed91b86d
Author: Andrey Utkin 
Date:   Wed Jul 13 04:59:34 2016 +0300

Fix checkpatch --strict issue

 CHECK: Please don't use multiple blank lines
 #3244: FILE: drivers/media/pci/tw5864/tw5864-video.c:184:

commit 861b2ba8593db7abe89291a4ba85976519783f4a
Author: Andrey Utkin 
Date:   Wed Jul 13 04:58:37 2016 +0300

Fix checkpatch --strict issue

 CHECK: No space is necessary after a cast
 #3053: FILE: drivers/media/pci/tw5864/tw5864-util.c:36:
 +   return (u8) tw_readl(TW5864_IND_DATA);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[tiffany lin]

On Tue, 2016-07-12 at 16:16 +0800, Wu-Cheng Li (李務誠) wrote:
> On Mon, Jul 11, 2016 at 10:56 AM, tiffany lin  
> wrote:
> > Hi Hans,
> >
> > On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> >> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> >> > Add V4L2_PIX_FMT_MT21 documentation
> >> >
> >> > Signed-off-by: Tiffany Lin 
> >> > ---
> >> >  Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> >> >  1 file changed, 6 insertions(+)
> >> >
> >> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> >> > b/Documentation/DocBook/media/v4l/pixfmt.xml
> >> > index 5a08aee..d40e0ce 100644
> >> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> >> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> >> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines 
> >> > is JPEG data and should be
> >> >  concatenated to form the JPEG stream. 
> >> >  
> >> >   
> >> > + 
> >> > +   V4L2_PIX_FMT_MT21
> >> > +   'MT21'
> >> > +   Compressed two-planar YVU420 format used by Mediatek 
> >> > MT8173
> >> > +   codec driver.
> >>
> >> Can you give a few more details? The encoder driver doesn't seem to 
> >> produce this
> >> format, so who is creating this? Where is this format documented?
> Decoder hardware produces MT21 (compressed). Image processor can
> convert it to a format that can be input of display driver. Tiffany.
> When do you plan to upstream image processor (mtk-mdp)?
> >
We are working on this. Will upstream soon.

> > It can be as input format for encoder, MDP and display drivers in our
> > platform.
> I remember display driver can only accept uncompressed MT21. Right?
> Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
> format. It's not usable until it's decompressed and converted by image
> processor.
That's right in MT8173 platform.

best regards,
Tiffany
> > This private format is only available in our platform.
> > So I put it in "Reserved Format Identifiers" sections.
> >
> >
> > best regards,
> > Tiffany
> >
> >> Regards,
> >>
> >>   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


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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[tiffany lin]

Hi Nicolas,

On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote:
> Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit :
> > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> > > Decoder hardware produces MT21 (compressed). Image processor can
> > > convert it to a format that can be input of display driver.
> > > Tiffany.
> > > When do you plan to upstream image processor (mtk-mdp)?
> > > > 
> > > > It can be as input format for encoder, MDP and display drivers in
> > > our
> > > > platform.
> > > I remember display driver can only accept uncompressed MT21. Right?
> > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
> > > format. It's not usable until it's decompressed and converted by
> > > image
> > > processor.
> > 
> > Previously it was described as MediaTek block mode, and now as a
> > MediaTek compressed format. It makes me think you have no idea what
> > this pixel format really is. Is that right ?
> > 
> > The main reason why I keep asking, is that we often find similarities
> > between what vendor like to call their proprietary formats. Doing the
> > proper research helps not creating a mess like in Android where you
> > have a lot of formats that all point to the same format. I believe
> > there was the same concern when Samsung wanted to introduce their Z-
> > flip-Z NV12 tile format. In the end they simply provided sufficient
> > documentation so we could document it and implement software
> > converters
> > for test and validation purpose.
> 
> Here's the kind of information we want in the documentation.
> 
> https://chromium.googlesource.com/chromium/src/media/+/master/base/vide
> o_types.h#40
> 
>   // MediaTek proprietary format. MT21 is similar to NV21 except the memory
>   // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2
>   // interleaved VU plane. Each image contains two buffers -- Y plane and VU
>   // plane. Two planes can be non-contiguous in memory. The starting addresses
>   // of Y plane and VU plane are 4KB alignment.
>   // Suppose image dimension is (width, height). For both Y plane and VU 
> plane:
>   // Row pitch = ((width+15)/16) * 16.
>   // Plane size = Row pitch * (((height+31)/32)*32)
> 
> Now obviously this is incomplete, as the swizzling need to be documented of 
> course.
> 
Because it's finally a compressed format from our codec hw, we cannot
describe its swizzling.

best regards,
Tiffany

> > 
> > regards,
> > Nicolas


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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[tiffany lin]

Hi Nicolas,

On Tue, 2016-07-12 at 15:08 -0400, Nicolas Dufresne wrote:
> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> > Decoder hardware produces MT21 (compressed). Image processor can
> > convert it to a format that can be input of display driver. Tiffany.
> > When do you plan to upstream image processor (mtk-mdp)?
> > >
> > > It can be as input format for encoder, MDP and display drivers in
> > our
> > > platform.
> > I remember display driver can only accept uncompressed MT21. Right?
> > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
> > format. It's not usable until it's decompressed and converted by
> > image
> > processor.
> 
> Previously it was described as MediaTek block mode, and now as a
> MediaTek compressed format. It makes me think you have no idea what
> this pixel format really is. Is that right ?
> 
That's not right.
Its a compressed format as I document in "[PATCH v3 3/9] DocBook/v4l:
Add compressed video formats used on MT8173 codec driver."
In MT8173 platform, when using this format, we need Image Processor to
cover it to standard format as wucheng mentioned.
To prevent this ambiguous, I will change it to V4L2_PIX_FMT_M21C, it
means its compressed data. Is it ok?

best regards,
Tiffany

> The main reason why I keep asking, is that we often find similarities
> between what vendor like to call their proprietary formats. Doing the
> proper research helps not creating a mess like in Android where you
> have a lot of formats that all point to the same format. I believe
> there was the same concern when Samsung wanted to introduce their Z-
> flip-Z NV12 tile format. In the end they simply provided sufficient
> documentation so we could document it and implement software converters
> for test and validation purpose.
> 
> regards,
> Nicolas


--
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 v4] [media] pci: Add tw5864 driver

[Andrey Utkin]

On Mon, Jul 11, 2016 at 09:40:53AM -0700, Joe Perches wrote:
> Each of these blocks will start with the dev_ prefix
> and the subsequent lines will not have the same prefix

Yes. I have checked how it looks before submitting, but I didn't see
this as a problem. I don't mind changing that (anyway I have found few
micro-issues with checkpatch --strict and would like to resubmit), but
would like to hear some second opinion.

> It also might be better to issue something like a single
> line dev_warn referring to the driver code and just leave
> this comment in the driver sources.
> 
> Something like:
> 
>   dev_warn(_dev->dev,
>   "This driver has known defects in video quality\n");

Things get complicated if you consider mainstream distros and their
years-behind kernels. The simplest way to preserve correspondence
between state of driver and such notice is to contain the notice in the
compiled driver. I hope the state of affairs will change to better
someday :)
--
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: s5p-mfc remove unnecessary error messages

[Shuah Khan]

Removing unnecessary error messages as appropriate error code is returned.

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index b6fde20..906f80c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -759,7 +759,6 @@ static int s5p_mfc_open(struct file *file)
/* Allocate memory for context */
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
-   mfc_err("Not enough memory\n");
ret = -ENOMEM;
goto err_alloc;
}
@@ -776,7 +775,6 @@ static int s5p_mfc_open(struct file *file)
while (dev->ctx[ctx->num]) {
ctx->num++;
if (ctx->num >= MFC_NUM_CONTEXTS) {
-   mfc_err("Too many open contexts\n");
ret = -EBUSY;
goto err_no_ctx;
}
-- 
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] userspace API definitions for auto-focus coil

[Mauro Carvalho Chehab]

Em Sat, 18 Jun 2016 17:38:46 +0200
Pavel Machek  escreveu:

> Hi!
> 
> > > Not V4L2_CID_USER_AD5820...?  
> > 
> > The rest of the controls have no USER as part of the macro name, so I
> > wouldn't use it here either.  
> 
> Ok.
> 
> > > Ok, separate header file for 2 lines seemed like a bit of overkill,
> > > but why not.  
> > 
> > That follows an existing pattern of how controls have been implemented in
> > other drivers.  
> 
> Ok.
> 
> > Could you merge this with the driver patch? I've dropped that from my ad5820
> > branch as it does not compile.  
> 
> Yes, merged patch should be in your inbox now.

The V4L2 core changes should be on a separate patch. Btw, you'll also
need to patch documentation to reflect such changes. We're right now
moving from DocBook to ReST markup language. The patches for it are
right now on a separate topic branch (docs-next), to be merged for
Kernel 4.8 on the next merge window.

You should either base the patch on such branch or wait for it to be
merged back mainstream to write such documentation additions.


> 
> Thanks,
>   Pavel
> 


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

Re: [PATCH 2/2] [media] s5p-g2d: Replace old driver with DRM version

[Mauro Carvalho Chehab]

I suspect that you'll be applying this one via DRM tree, so:

Em Tue, 24 May 2016 15:28:13 +0200
Krzysztof Kozlowski  escreveu:

> Remove the old non-DRM driver because it is now entirely supported by
> exynos_drm_g2d driver.
> 
> Cc: Kyungmin Park 
> Cc: Kamil Debski 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Mauro Carvalho Chehab 

PS.: If you prefer to apply this one via my tree, I'm ok too. Just
let me know when the first patch gets merged upstream.

Regards,
Mauro

> ---
>  MAINTAINERS   |   8 -
>  drivers/gpu/drm/exynos/Kconfig|   1 -
>  drivers/media/platform/Kconfig|  12 -
>  drivers/media/platform/Makefile   |   1 -
>  drivers/media/platform/s5p-g2d/Makefile   |   3 -
>  drivers/media/platform/s5p-g2d/g2d-hw.c   | 117 -
>  drivers/media/platform/s5p-g2d/g2d-regs.h | 122 -
>  drivers/media/platform/s5p-g2d/g2d.c  | 800 
> --
>  drivers/media/platform/s5p-g2d/g2d.h  |  91 
>  9 files changed, 1155 deletions(-)
>  delete mode 100644 drivers/media/platform/s5p-g2d/Makefile
>  delete mode 100644 drivers/media/platform/s5p-g2d/g2d-hw.c
>  delete mode 100644 drivers/media/platform/s5p-g2d/g2d-regs.h
>  delete mode 100644 drivers/media/platform/s5p-g2d/g2d.c
>  delete mode 100644 drivers/media/platform/s5p-g2d/g2d.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 243c0811a4d8..01763419c6a1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1616,14 +1616,6 @@ L: linux-arm-ker...@lists.infradead.org (moderated 
> for non-subscribers)
>  S:   Maintained
>  F:   arch/arm/mach-s5pv210/
>  
> -ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
> -M:   Kyungmin Park 
> -M:   Kamil Debski 
> -L:   linux-arm-ker...@lists.infradead.org
> -L:   linux-media@vger.kernel.org
> -S:   Maintained
> -F:   drivers/media/platform/s5p-g2d/
> -
>  ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
>  M:   Kyungmin Park 
>  M:   Kamil Debski 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index d814b3048ee5..b0eb20ba1b28 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -95,7 +95,6 @@ comment "Sub-drivers"
>  
>  config DRM_EXYNOS_G2D
>   bool "G2D"
> - depends on VIDEO_SAMSUNG_S5P_G2D=n
>   select FRAME_VECTOR
>   help
> Choose this option if you want to use Exynos G2D for DRM.
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 84e041c0a70e..171005c53d62 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -161,18 +161,6 @@ config VIDEO_MEM2MEM_DEINTERLACE
>   help
>   Generic deinterlacing V4L2 driver.
>  
> -config VIDEO_SAMSUNG_S5P_G2D
> - tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
> - depends on VIDEO_DEV && VIDEO_V4L2
> - depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> - depends on HAS_DMA
> - select VIDEOBUF2_DMA_CONTIG
> - select V4L2_MEM2MEM_DEV
> - default n
> - ---help---
> -   This is a v4l2 driver for Samsung S5P and EXYNOS4 G2D
> -   2d graphics accelerator.
> -
>  config VIDEO_SAMSUNG_S5P_JPEG
>   tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
>   depends on VIDEO_DEV && VIDEO_V4L2
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index bbb7bd1eb268..ad5e26a0bd17 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -32,7 +32,6 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)+= s5p-jpeg/
>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)  += s5p-mfc/
>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)   += s5p-tv/
>  
> -obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)  += s5p-g2d/
>  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)   += exynos-gsc/
>  
>  obj-$(CONFIG_VIDEO_STI_BDISP)+= sti/bdisp/
> diff --git a/drivers/media/platform/s5p-g2d/Makefile 
> b/drivers/media/platform/s5p-g2d/Makefile
> deleted file mode 100644
> index 2c48c416a804..
> --- a/drivers/media/platform/s5p-g2d/Makefile
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -s5p-g2d-objs := g2d.o g2d-hw.o
> -
> -obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)  += s5p-g2d.o
> diff --git a/drivers/media/platform/s5p-g2d/g2d-hw.c 
> b/drivers/media/platform/s5p-g2d/g2d-hw.c
> deleted file mode 100644
> index e87bd93811d4..
> --- a/drivers/media/platform/s5p-g2d/g2d-hw.c
> +++ /dev/null
> @@ -1,117 +0,0 @@
> -/*
> - * Samsung S5P G2D - 2D Graphics Accelerator Driver
> - *
> - * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> - * Kamil Debski, 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the 

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[Ian Arkver]

On 12/07/16 20:14, Nicolas Dufresne wrote:

Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit :

Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :

Decoder hardware produces MT21 (compressed). Image processor can
convert it to a format that can be input of display driver.
Tiffany.
When do you plan to upstream image processor (mtk-mdp)?

It can be as input format for encoder, MDP and display drivers in

our

platform.

I remember display driver can only accept uncompressed MT21. Right?
Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
format. It's not usable until it's decompressed and converted by
image
processor.

Previously it was described as MediaTek block mode, and now as a
MediaTek compressed format. It makes me think you have no idea what
this pixel format really is. Is that right ?

The main reason why I keep asking, is that we often find similarities
between what vendor like to call their proprietary formats. Doing the
proper research helps not creating a mess like in Android where you
have a lot of formats that all point to the same format. I believe
there was the same concern when Samsung wanted to introduce their Z-
flip-Z NV12 tile format. In the end they simply provided sufficient
documentation so we could document it and implement software
converters
for test and validation purpose.

Here's the kind of information we want in the documentation.

https://chromium.googlesource.com/chromium/src/media/+/master/base/vide
o_types.h#40

   // MediaTek proprietary format. MT21 is similar to NV21 except the memory
   // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2
   // interleaved VU plane. Each image contains two buffers -- Y plane and VU
   // plane. Two planes can be non-contiguous in memory. The starting addresses
   // of Y plane and VU plane are 4KB alignment.
   // Suppose image dimension is (width, height). For both Y plane and VU plane:
   // Row pitch = ((width+15)/16) * 16.
   // Plane size = Row pitch * (((height+31)/32)*32)

Now obviously this is incomplete, as the swizzling need to be documented of 
course.
Not sure where that chromium comment came from, but if MT21 really is 
similar to NV21 (a 4:2:0 format) and has 2x2 downsampled chroma, then 
the combined VU plane will be half the size of the Y plane.


Maybe that's not relevant to this discussion.

Regards,
Ian



regards,
Nicolas

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


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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[Nicolas Dufresne]

Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit :
> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> > Decoder hardware produces MT21 (compressed). Image processor can
> > convert it to a format that can be input of display driver.
> > Tiffany.
> > When do you plan to upstream image processor (mtk-mdp)?
> > > 
> > > It can be as input format for encoder, MDP and display drivers in
> > our
> > > platform.
> > I remember display driver can only accept uncompressed MT21. Right?
> > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
> > format. It's not usable until it's decompressed and converted by
> > image
> > processor.
> 
> Previously it was described as MediaTek block mode, and now as a
> MediaTek compressed format. It makes me think you have no idea what
> this pixel format really is. Is that right ?
> 
> The main reason why I keep asking, is that we often find similarities
> between what vendor like to call their proprietary formats. Doing the
> proper research helps not creating a mess like in Android where you
> have a lot of formats that all point to the same format. I believe
> there was the same concern when Samsung wanted to introduce their Z-
> flip-Z NV12 tile format. In the end they simply provided sufficient
> documentation so we could document it and implement software
> converters
> for test and validation purpose.

Here's the kind of information we want in the documentation.

https://chromium.googlesource.com/chromium/src/media/+/master/base/vide
o_types.h#40

  // MediaTek proprietary format. MT21 is similar to NV21 except the memory
  // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2
  // interleaved VU plane. Each image contains two buffers -- Y plane and VU
  // plane. Two planes can be non-contiguous in memory. The starting addresses
  // of Y plane and VU plane are 4KB alignment.
  // Suppose image dimension is (width, height). For both Y plane and VU plane:
  // Row pitch = ((width+15)/16) * 16.
  // Plane size = Row pitch * (((height+31)/32)*32)

Now obviously this is incomplete, as the swizzling need to be documented of 
course.

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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[Nicolas Dufresne]

Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> Decoder hardware produces MT21 (compressed). Image processor can
> convert it to a format that can be input of display driver. Tiffany.
> When do you plan to upstream image processor (mtk-mdp)?
> >
> > It can be as input format for encoder, MDP and display drivers in
> our
> > platform.
> I remember display driver can only accept uncompressed MT21. Right?
> Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
> format. It's not usable until it's decompressed and converted by
> image
> processor.

Previously it was described as MediaTek block mode, and now as a
MediaTek compressed format. It makes me think you have no idea what
this pixel format really is. Is that right ?

The main reason why I keep asking, is that we often find similarities
between what vendor like to call their proprietary formats. Doing the
proper research helps not creating a mess like in Android where you
have a lot of formats that all point to the same format. I believe
there was the same concern when Samsung wanted to introduce their Z-
flip-Z NV12 tile format. In the end they simply provided sufficient
documentation so we could document it and implement software converters
for test and validation purpose.

regards,
Nicolas
--
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] doc-rst: update CEC_RECEIVE

[Hans Verkuil]

From: Hans Verkuil 

The timestamp field was split into rx_ts and tx_ts, and the rx/tx_status
fields were moved. Update the doc accordingly.

Also fix a bug that stated that a non-zero tx_status field signaled an
error. That's not true, since TX_STATUS_OK is 1, not 0.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-receive.rst | 76 +---
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst 
b/Documentation/media/uapi/cec/cec-ioc-receive.rst
index 47aadcd..34382af 100644
--- a/Documentation/media/uapi/cec/cec-ioc-receive.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst
@@ -64,14 +64,20 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
 
-  __u64
 
-   -  ``ts``
+   -  ``tx_ts``
 
-   -  Timestamp of when the message was transmitted in ns in the case of
- :ref:`CEC_TRANSMIT` with ``reply`` set to 0, or the timestamp of the
- received message in all other cases.
+   -  Timestamp in ns of when the last byte of the message was transmitted.
 
 -  .. row 2
 
+   -  __u64
+
+   -  ``rx_ts``
+
+   -  Timestamp in ns of when the last byte of the message was received.
+
+-  .. row 3
+
-  __u32
 
-  ``len``
@@ -81,7 +87,7 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
  :ref:`CEC_RECEIVE` and for :ref:`CEC_TRANSMIT` it will be filled in 
with
  the length of the reply message if ``reply`` was set.
 
--  .. row 3
+-  .. row 4
 
-  __u32
 
@@ -94,7 +100,7 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
  then it will be replaced by 1000 if the ``reply`` is non-zero or
  ignored if ``reply`` is 0.
 
--  .. row 4
+-  .. row 5
 
-  __u32
 
@@ -105,7 +111,7 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
  framework to generate an event if a reply for a message was
  requested and the message was transmitted in a non-blocking mode.
 
--  .. row 5
+-  .. row 6
 
-  __u32
 
@@ -113,32 +119,10 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
 
-  Flags. No flags are defined yet, so set this to 0.
 
--  .. row 6
-
-   -  __u8
-
-   -  ``rx_status``
-
-   -  The status bits of the received message. See
- :ref:`cec-rx-status` for the possible status values. It is 0 if
- this message was transmitted, not received, unless this is the
- reply to a transmitted message. In that case both ``rx_status``
- and ``tx_status`` are set.
-
 -  .. row 7
 
-  __u8
 
-   -  ``tx_status``
-
-   -  The status bits of the transmitted message. See
- :ref:`cec-tx-status` for the possible status values. It is 0 if
- this messages was received, not transmitted.
-
--  .. row 8
-
-   -  __u8
-
-  ``msg``\ [16]
 
-  The message payload. For :ref:`CEC_TRANSMIT` this is filled in by the
@@ -146,7 +130,7 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
  for :ref:`CEC_TRANSMIT` it will be filled in with the payload of the
  reply message if ``reply`` was set.
 
--  .. row 9
+-  .. row 8
 
-  __u8
 
@@ -154,8 +138,8 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
 
-  Wait until this message is replied. If ``reply`` is 0 and the
  ``timeout`` is 0, then don't wait for a reply but return after
- transmitting the message. If there was an error as indicated by a
- non-zero ``tx_status`` field, then ``reply`` and ``timeout`` are
+ transmitting the message. If there was an error as indicated by the
+ ``tx_status`` field, then ``reply`` and ``timeout`` are
  both set to 0 by the driver. Ignored by :ref:`CEC_RECEIVE`. The case
  where ``reply`` is 0 (this is the opcode for the Feature Abort
  message) and ``timeout`` is non-zero is specifically allowed to
@@ -163,10 +147,32 @@ queue, then it will return -1 and set errno to the EBUSY 
error code.
  Feature Abort reply. In this case ``rx_status`` will either be set
  to :ref:`CEC_RX_STATUS_TIMEOUT ` or 
:ref:`CEC_RX_STATUS-FEATURE-ABORT `.
 
+-  .. row 9
+
+   -  __u8
+
+   -  ``rx_status``
+
+   -  The status bits of the received message. See
+ :ref:`cec-rx-status` for the possible status values. It is 0 if
+ this message was transmitted, not received, unless this is the
+ reply to a transmitted message. In that case both ``rx_status``
+ and ``tx_status`` are set.
+
 -  .. row 10
 
-  __u8
 
+   -  ``tx_status``
+
+   -  The status bits of the transmitted message. See
+ :ref:`cec-tx-status` for the possible status 

[PATCH 2/2] doc-rst: improve CEC documentation

[Hans Verkuil]

From: Hans Verkuil 

Lots of fixups relating to references.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-func-ioctl.rst|  2 +-
 Documentation/media/uapi/cec/cec-func-open.rst | 10 +++
 .../media/uapi/cec/cec-ioc-adap-g-caps.rst | 18 ++--
 .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst| 14 -
 .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst| 14 -
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  2 +-
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst| 34 +-
 Documentation/media/uapi/cec/cec-ioc-receive.rst   | 28 +-
 8 files changed, 58 insertions(+), 64 deletions(-)

diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst 
b/Documentation/media/uapi/cec/cec-func-ioctl.rst
index a07cc7c..d0279e6d 100644
--- a/Documentation/media/uapi/cec/cec-func-ioctl.rst
+++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst
@@ -29,7 +29,7 @@ Arguments
 
 ``request``
 CEC ioctl request code as defined in the cec.h header file, for
-example CEC_ADAP_G_CAPS.
+example :ref:`CEC_ADAP_G_CAPS`.
 
 ``argp``
 Pointer to a request-specific structure.
diff --git a/Documentation/media/uapi/cec/cec-func-open.rst 
b/Documentation/media/uapi/cec/cec-func-open.rst
index 245d679..cbf1176 100644
--- a/Documentation/media/uapi/cec/cec-func-open.rst
+++ b/Documentation/media/uapi/cec/cec-func-open.rst
@@ -32,11 +32,11 @@ Arguments
 Open flags. Access mode must be ``O_RDWR``.
 
 When the ``O_NONBLOCK`` flag is given, the
-:ref:`CEC_RECEIVE` ioctl will return EAGAIN
-error code when no message is available, and the
-:ref:`CEC_TRANSMIT`,
-:ref:`CEC_ADAP_S_PHYS_ADDR` and
-:ref:`CEC_ADAP_S_LOG_ADDRS` ioctls
+:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN
+error code when no message is available, and ioctls
+:ref:`CEC_TRANSMIT `,
+:ref:`CEC_ADAP_S_PHYS_ADDR ` and
+:ref:`CEC_ADAP_S_LOG_ADDRS `
 all act in non-blocking mode.
 
 Other flags have no effect.
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index 2ca9199..63b808e 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -34,7 +34,7 @@ Description
 .. note:: This documents the proposed CEC API. This API is not yet finalized
and is currently only available as a staging kernel module.
 
-All cec devices must support the :ref:`CEC_ADAP_G_CAPS` ioctl. To query
+All cec devices must support ``CEC_ADAP_G_CAPS``. To query
 device information, applications call the ioctl with a pointer to a
 struct :ref:`cec_caps `. The driver fills the structure and
 returns the information to the application. The ioctl never fails.
@@ -99,8 +99,8 @@ returns the information to the application. The ioctl never 
fails.
 
-  0x0001
 
-   -  Userspace has to configure the physical address by calling
- :ref:`CEC_ADAP_S_PHYS_ADDR`. If
+   -  Userspace has to configure the physical address by calling ioctl
+ :ref:`CEC_ADAP_S_PHYS_ADDR `. If
  this capability isn't set, then setting the physical address is
  handled by the kernel whenever the EDID is set (for an HDMI
  receiver) or read (for an HDMI transmitter).
@@ -111,8 +111,8 @@ returns the information to the application. The ioctl never 
fails.
 
-  0x0002
 
-   -  Userspace has to configure the logical addresses by calling
- :ref:`CEC_ADAP_S_LOG_ADDRS`. If
+   -  Userspace has to configure the logical addresses by calling ioctl
+ :ref:`CEC_ADAP_S_LOG_ADDRS `. If
  this capability isn't set, then the kernel will have configured
  this.
 
@@ -122,8 +122,8 @@ returns the information to the application. The ioctl never 
fails.
 
-  0x0004
 
-   -  Userspace can transmit CEC messages by calling
- :ref:`CEC_TRANSMIT`. This implies that
+   -  Userspace can transmit CEC messages by calling ioctl
+ :ref:`CEC_TRANSMIT `. This implies that
  userspace can be a follower as well, since being able to transmit
  messages is a prerequisite of becoming a follower. If this
  capability isn't set, then the kernel will handle all CEC
@@ -135,8 +135,8 @@ returns the information to the application. The ioctl never 
fails.
 
-  0x0008
 
-   -  Userspace can use the passthrough mode by calling
- :ref:`CEC_S_MODE`.
+   -  Userspace can use the passthrough mode by calling ioctl
+ :ref:`CEC_S_MODE `.
 
 -  .. _`CEC-CAP-RC`:
 
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
index 7d7a3b4..d082830 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
+++ 

[PATCH 0/2] doc-rst: CEC improvements

[Hans Verkuil]

From: Hans Verkuil 

Note: patch 1 assumes this pull request has been merged:

https://patchwork.linuxtv.org/patch/35377/

Regards,

Hans

Hans Verkuil (2):
  doc-rst: update CEC_RECEIVE
  doc-rst: improve CEC documentation

 Documentation/media/uapi/cec/cec-func-ioctl.rst|   2 +-
 Documentation/media/uapi/cec/cec-func-open.rst |  10 +-
 .../media/uapi/cec/cec-ioc-adap-g-caps.rst |  18 ++--
 .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst|  14 +--
 .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst|  14 +--
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |   2 +-
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst|  34 +++
 Documentation/media/uapi/cec/cec-ioc-receive.rst   | 104 +++--
 8 files changed, 99 insertions(+), 99 deletions(-)

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

[Tejun Heo]

On Sat, Jul 09, 2016 at 01:22:29PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in updating parameters for
> transfers. It has a single work item(>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 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] media: s5p-mfc Fix misspelled error message and checkpatch errors

[Shuah Khan]

Fix misspelled error message and existing checkpatch errors in the
error message conditional.

WARNING: suspect code indent for conditional statements (8, 24)
if (ctx->state != MFCINST_HEAD_PARSED &&
[...]
mfc_err("Can not get crop information\n");

Signed-off-by: Shuah Khan 
Reviewed-by: Javier Martinez Canillas 
---
Changes since v1:
- Addressed review comments from Joe Perches
- Added reviewed by tag from Javier Martinez Canillas

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index a01a373..0a9e8d1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -775,11 +775,12 @@ static int vidioc_g_crop(struct file *file, void *priv,
u32 left, right, top, bottom;
 
if (ctx->state != MFCINST_HEAD_PARSED &&
-   ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
-   && ctx->state != MFCINST_FINISHED) {
-   mfc_err("Cannont set crop\n");
-   return -EINVAL;
-   }
+   ctx->state != MFCINST_RUNNING &&
+   ctx->state != MFCINST_FINISHING &&
+   ctx->state != MFCINST_FINISHED) {
+   mfc_err("Can not get crop information\n");
+   return -EINVAL;
+   }
if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_H264) {
left = s5p_mfc_hw_call(dev->mfc_ops, get_crop_info_h, ctx);
right = left >> S5P_FIMV_SHARED_CROP_RIGHT_SHIFT;
-- 
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 06/11] media: adv7180: add bt.656-4 OF property

[Steve Longerbeam]

Hi Ian,

On 07/12/2016 03:25 AM, Ian Arkver wrote:
> This conversation has drifted off topic, sorry.
> It now relates to code in drivers/gpu/ipu-v3/ipu-csi.c, so adding Philipp 
> Zabel.
>

> On 11/07/16 23:03, Steve Longerbeam wrote:
>> On 07/11/2016 12:06 AM, Ian Arkver wrote:
>>>
>>> Hi Steve,
>>>
>>> Once you dsicover that the 3-bit fields in each CCIR_CODE register 
>>> correspond to the H, V and F flags in the SAV/EAV code (in that order, 
>>> MSbit->LSbit),  those registers make more sense. Pity that's
>>> not mentioned in the Ref Manual.
>> Hi Ian, that's a plausible theory, but it doesn't work. I looked at the value
>> programmed to CCIR_CODE_1 register (according to imx6 ref manual is
>> values for first field), for NTSC : 0xD07DF.  Comparing with the definition 
>> of
>> the H/V/F bits in the AV codes in the bt.656 spec:
>>
>> F = 1 during field 2, 0 during field 1
>> V = 1 during field blanking, 0 elsewhere
>> H = 1 in EAV, 0 in SAV
>>
>> There's no correspondence, for example F bit should be zero everywhere in
>> CCIR_CODE_1. And wutz this "first/second blanking line command" stuff about?
>> None of it makes any sense to me.
> Hi,
>
> d07df = 001 101  011 111 011 111

Oops, I was misreading the register fields in the ref manual.
I misread the reserved field starting at bit 12 as 3 bits long, but
it is 4 bits long. The H,V,F bits for those CCIR_CODE values make
sense now.

So this clears up a lot for me. Due to confusion surrounding these
registers, one of my theories as to what these registers were doing
was that they were telling the CSI actually where to look for the SAV/EAV
codes in the stream, as a line number or something. But I see now that
the registers are simply telling the IPU about the standard, so they are
more like "set it and forget it" registers, and would only be set to something
other than what the standard specifies in order to deal with non-standard
streams (like adv718x "NEWAVMODE", see below).

So the IPU must be detecting the AV codes using the AV code preamble,
which is a good thing.

Also, it clears up how to deal with bt.656-3 vs. bt.656-4 in the imx6 backend a 
bit
more. The CCIR code registers do not need to be touched when switching between
bt.656-3 and bt.656-4. It's more a matter of the number of active lines the 
decoder
sends (bt.656-3 has 10 extra active lines).

>
>   H V F
> CSI0_STRT_FLD0_ACTV   0 0 1
> CSI0_END_FLD0_ACTV1 0 1
> CSI0_STRT_FLD0_BLNK_2ND   0 1 1
> CSI0_END_FLD0_BLNK_2ND1 1 1
> CSI0_STRT_FLD0_BLNK_1ST   0 1 1
> CSI0_END_FLD0_BLNK_1ST1 1 1
>
> 40596 = 000 100  010 110 010 110
> 405A6 = 000 100  010 110 100 110
>
>   H V F
> CSI0_STRT_FLD1_ACTV   0 0 0
> CSI0_END_FLD1_ACTV1 0 0
> CSI0_STRT_FLD1_BLNK_2ND   0 1 0
> CSI0_END_FLD1_BLNK_2ND1 1 0
> CSI0_STRT_FLD1_BLNK_1ST   0 1 0or 1 0 0 ?
> CSI0_END_FLD1_BLNK_1ST1 1 0
>
> For PAL:  IPU_CSI0_CCIR_CODE_1 = 0x40596, IPU_CSI0_CCIR_CODE_1 = 0xd07df
> For NTSC: IPU_CSI0_CCIR_CODE_1 = 0xd07df, IPU_CSI0_CCIR_CODE_1 = 0x405A6
>
> So, for the PAL case the field values make sense to me. The F bit is constant 
> throughout each field.
> I'm not sure why the NTSC case has 405A6 instead of 40596 again. This looks 
> like a bug to me.

Actually we made this change to deal with "NEWAVMODE" setting in the adv7180. 
But now
I see that NEWAVMODE breaks the bt.656 standard, and will create problems for 
other backends.

So I will remove the NEWAVMODE patch to adv7180, and revert the patch that sets 
the above
0x405A6 value in IPU_CSI0_CCIR_CODE_1.


> If you look back at the original Freescale capture driver[1], they use 40596 
> for both PAL and NTSC.
>
> The values are swapped between NTSC and PAL to account for the differing 
> field order. I think using
> the capture width and height to do this is poor as any "bt.656-like" source 
> with non standard
> dimensions will end up in the dev_err("Unsupported") case.

yes this code was inherited originally from Freescale. There's needs to be a 
better
API for that.

> Also, looking at BT.1120-8, for interlaced
> video the same SAV and EAV codes as PAL are used, so 
> IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR and
> IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR modes are currently broken.

right, I haven't even touched bt.1120 support. I don't have any h/w to test.

>
> I think the 1st and 2nd blanking values might be needed for some odd non 656 
> streams maybe?
> Also for progressive (originally) the value 40030 is used which is
>
> 40030 = 000 100  000 000 110 000
>
> This leaves the 2nd blank values empty. In the HW I'd guess both fire on SAV 
> but there's a fixed
> event priority in the state machine, or it ignores events where both STRT and 
> END fire on the same
> clock tick.

Maybe the "1st" and "2nd" blanking fields just provide alternative matches
for the received AV codes.


>
> btw: The patch I sent you a while back[2] dumps the CCIR values in octal 
> which 

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

[Robert Jarzmik]

Hans Verkuil  writes:

> On 04/02/2016 04:26 PM, Robert Jarzmik wrote:
>> Transfer the formats translations to soc_mediabus. Even is soc_camera
>> was to be deprecated, soc_mediabus will survive, and should describe all
>> that happens on the bus connecting the image processing unit of the SoC
>> and the sensor.
>> 
>> The translation engine provides an easy way to compute the formats
>> available in the v4l2 device, given any sensors format capabilities
>> bound with known image processing transformations.
>
> I prefer that you just make a copy of this for use in the pxa driver.
>
> We might make this (or a variant) available for all drivers in the future,
> but for now just split off the pxa driver without introducing new media
> includes.
Okay, as you wish.

Cheers.

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

[GIT PULL FOR v4.8] Various fixes

[Hans Verkuil]

A bunch of vcodec code improvements and two cec changes: one adds a
sanity check, the other improves timestamping. A patch updating the
doc-rst will be posted separately.

Regards,

Hans

The following changes since commit 9d01315d132469fd0a92f5a13c0a605d6ce96b21:

  [media] pulse8-cec: declare function as static (2016-07-12 13:46:20 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.8j

for you to fetch changes up to 948ae91767dab720d978a3cb835f5b9f23f6f13b:

  mtk-vcodec: fix type mismatches (2016-07-12 19:07:27 +0200)


Arnd Bergmann (1):
  mtk-vcodec: fix type mismatches

Hans Verkuil (2):
  cec: add sanity check for msg->len
  cec: split the timestamp into an rx and tx timestamp

Wei Yongjun (4):
  VPU: mediatek: fix return value check in mtk_vpu_probe()
  VPU: mediatek: remove redundant dev_err call in mtk_vpu_probe()
  vcodec: mediatek: Fix return value check in mtk_vcodec_init_enc_pm()
  mtk-vcodec: remove redundant dev_err call in mtk_vcodec_probe()

 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |  8 
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  2 --
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  | 16 
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c  |  4 ++--
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c   |  4 ++--
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c|  4 ++--
 drivers/media/platform/mtk-vpu/mtk_vpu.c   | 12 
 drivers/staging/media/cec/cec-adap.c   | 27 
+++
 include/linux/cec.h| 18 ++
 9 files changed, 47 insertions(+), 48 deletions(-)
--
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 misspelled error message and checkpatch errors

[Joe Perches]

On Tue, 2016-07-12 at 10:08 -0600, Shuah Khan wrote:
> On 07/12/2016 09:51 AM, Joe Perches wrote:
> > On Tue, 2016-07-12 at 08:42 -0600, Shuah Khan wrote:
> > > On 07/12/2016 08:06 AM, Joe Perches wrote:
> > > > On Mon, 2016-07-11 at 16:39 -0600, Shuah Khan wrote:
> > > > > 
> > > > > Fix misspelled error message and existing checkpatch errors in the
> > > > > error message conditional.
> > > > []
> > > > > 
> > > > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> > > > > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > > > []
> > > > > 
> > > > > @@ -775,11 +775,11 @@ static int vidioc_g_crop(struct file *file, 
> > > > > void *priv,
> > > > >   u32 left, right, top, bottom;
> > > > >  
> > > > >   if (ctx->state != MFCINST_HEAD_PARSED &&
> > > > > - ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
> > > > > - && ctx->state != 
> > > > > MFCINST_FINISHED) {
> > > > > - mfc_err("Cannont set crop\n");
> > > > > - return -EINVAL;
> > > > > - }
> > > > > + ctx->state != MFCINST_RUNNING && ctx->state != 
> > > > > MFCINST_FINISHING
> > > > > + && ctx->state != MFCINST_FINISHED) {
> > > > > + mfc_err("Can not get crop information\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > is it a set or a get?
> > > vidioc_g_crop is a get routine.
> > > > 
> > > > 
> > > > It'd be nicer for humans to read if the alignment was consistent
> > > Are you okay with this alignment change or would you like it
> > > changed?
> > Well, if you're resubmitting, I'd prefer it changed.
> > Thanks.
> > 
> chekcpatch stopped complaining. Are you looking for the entire file
> alignments changed? I am not clear on what needs to be changed?

I think doing just this spelling and get/set correction and
fixing the alignment in this single case in a single patch
would be fine here.

Foxing the alignment for the entire file would be a more
significant change and isn't necessary in this patch.

Another thing possible for the file would be to change the
mfc_debug and mfc_err/mfc_info macros to use pr_
without the generally unnecessary __func__ and __LINE__
uses.

This could both enable dynamic_debug uses for the KERN_DEBUG
cases and reduce overall object size.

--
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 misspelled error message and checkpatch errors

[Shuah Khan]

On 07/12/2016 09:51 AM, Joe Perches wrote:
> On Tue, 2016-07-12 at 08:42 -0600, Shuah Khan wrote:
>> On 07/12/2016 08:06 AM, Joe Perches wrote:
>>> On Mon, 2016-07-11 at 16:39 -0600, Shuah Khan wrote:
 Fix misspelled error message and existing checkpatch errors in the
 error message conditional.
>>> []
 diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
 b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>> []
 @@ -775,11 +775,11 @@ static int vidioc_g_crop(struct file *file, void 
 *priv,
u32 left, right, top, bottom;
  
if (ctx->state != MFCINST_HEAD_PARSED &&
 -  ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
 -  && ctx->state != MFCINST_FINISHED) {
 -  mfc_err("Cannont set crop\n");
 -  return -EINVAL;
 -  }
 +  ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
 +  && ctx->state != MFCINST_FINISHED) {
 +  mfc_err("Can not get crop information\n");
 +  return -EINVAL;
 +  }
>>> is it a set or a get?
>> vidioc_g_crop is a get routine.
>>>
>>> It'd be nicer for humans to read if the alignment was consistent
>> Are you okay with this alignment change or would you like it
>> changed?
> 
> Well, if you're resubmitting, I'd prefer it changed.
> Thanks.
> 

chekcpatch stopped complaining. Are you looking for the entire file
alignments changed? I am not clear on what needs to be changed?

thanks,
-- Shuah

--
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: mceusb xhci issue?

[Alan Stern]

On Sat, 9 Jul 2016, Mauro Carvalho Chehab wrote:

> C/C linux-usb Mailing list:
> 
> 
> Em Wed, 18 May 2016 08:52:28 -0600
> Wade Berrier  escreveu:

...

> > > That message above links to some other threads describing the issue.
> > > Here's a post with a patch that supposedly works:
> > > 
> > > http://www.gossamer-threads.com/lists/mythtv/users/587930
> > > 
> > > No idea if that's the "correct" way to fix this.
> > > 
> > > I'll be trying that out and then report back...  
> > 
> > Indeed, this patch does fix the issue:
> > 
> > --
> > 
> > diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
> > index 31ccdcc..03321d4 100644
> > --- a/drivers/usb/core/config.c
> > +++ b/drivers/usb/core/config.c
> > @@ -247,7 +247,7 @@ static int usb_parse_endpoint(struct device *ddev, int 
> > cfgno, int inum,
> > /* For low-speed, 10 ms is the official minimum.
> >  * But some "overclocked" devices might want faster
> >  * polling so we'll allow it. */
> > -   n = 32;
> > +   n = 10;
> > break;
> > }
> > } else if (usb_endpoint_xfer_isoc(d)) {
> > 
> > 
> > --
> > 
> > Is this change appropriate to be pushed upstream?  Where to go from
> > here?
> 
> This issue is at the USB core. So, it should be reported to the
> linux-usb mailing list. 
> 
> The people there should help about how to proceed to get this
> fixed upstream.

Here's a proper version of that patch.  If this is okay, it can be 
merged.

Alan Stern



Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -213,8 +213,10 @@ static int usb_parse_endpoint(struct dev
memcpy(>desc, d, n);
INIT_LIST_HEAD(>urb_list);
 
-   /* Fix up bInterval values outside the legal range. Use 32 ms if no
-* proper value can be guessed. */
+   /*
+* Fix up bInterval values outside the legal range.
+* Use 10 or 8 ms if no proper value can be guessed.
+*/
i = 0;  /* i = min, j = max, n = default */
j = 255;
if (usb_endpoint_xfer_int(d)) {
@@ -223,13 +225,15 @@ static int usb_parse_endpoint(struct dev
case USB_SPEED_SUPER_PLUS:
case USB_SPEED_SUPER:
case USB_SPEED_HIGH:
-   /* Many device manufacturers are using full-speed
+   /*
+* Many device manufacturers are using full-speed
 * bInterval values in high-speed interrupt endpoint
 * descriptors. Try to fix those and fall back to a
-* 32 ms default value otherwise. */
+* 8 ms default value otherwise.
+*/
n = fls(d->bInterval*8);
if (n == 0)
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
j = 16;
 
/*
@@ -247,7 +251,7 @@ static int usb_parse_endpoint(struct dev
/* For low-speed, 10 ms is the official minimum.
 * But some "overclocked" devices might want faster
 * polling so we'll allow it. */
-   n = 32;
+   n = 10;
break;
}
} else if (usb_endpoint_xfer_isoc(d)) {
@@ -255,10 +259,10 @@ static int usb_parse_endpoint(struct dev
j = 16;
switch (to_usb_device(ddev)->speed) {
case USB_SPEED_HIGH:
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
break;
default:/* USB_SPEED_FULL */
-   n = 6;  /* 32 ms = 2^(6-1) frames */
+   n = 4;  /* 8 ms = 2^(4-1) frames */
break;
}
}

--
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 misspelled error message and checkpatch errors

[Joe Perches]

On Tue, 2016-07-12 at 08:42 -0600, Shuah Khan wrote:
> On 07/12/2016 08:06 AM, Joe Perches wrote:
> > On Mon, 2016-07-11 at 16:39 -0600, Shuah Khan wrote:
> > > Fix misspelled error message and existing checkpatch errors in the
> > > error message conditional.
> > []
> > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> > > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> > []
> > > @@ -775,11 +775,11 @@ static int vidioc_g_crop(struct file *file, void 
> > > *priv,
> > >   u32 left, right, top, bottom;
> > >  
> > >   if (ctx->state != MFCINST_HEAD_PARSED &&
> > > - ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
> > > - && ctx->state != MFCINST_FINISHED) {
> > > - mfc_err("Cannont set crop\n");
> > > - return -EINVAL;
> > > - }
> > > + ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
> > > + && ctx->state != MFCINST_FINISHED) {
> > > + mfc_err("Can not get crop information\n");
> > > + return -EINVAL;
> > > + }
> > is it a set or a get?
> vidioc_g_crop is a get routine.
> > 
> > It'd be nicer for humans to read if the alignment was consistent
> Are you okay with this alignment change or would you like it
> changed?

Well, if you're resubmitting, I'd prefer it changed.
Thanks.
--
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 28/54] MAINTAINERS: Add file patterns for media device tree bindings

[Geert Uytterhoeven]

Hi Mauro,

On Sun, Jul 10, 2016 at 5:27 PM, Mauro Carvalho Chehab
 wrote:
> Em Sun, 22 May 2016 11:06:05 +0200
> Geert Uytterhoeven  escreveu:
>
>> Submitters of device tree binding documentation may forget to CC
>> the subsystem maintainer if this is missing.
>
> I'm assuming that this patch will go via DT git tree, so:

No, please see below...

>> Signed-off-by: Geert Uytterhoeven 
>> Cc: Mauro Carvalho Chehab 
>
> Acked-by: Mauro Carvalho Chehab 

Thanks.

>> Cc: linux-media@vger.kernel.org
>> ---
>> Please apply this patch directly if you want to be involved in device
>> tree binding documentation for your subsystem.

... and apply it. Thanks again!

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: [PATCH] media: s5p-mfc Fix misspelled error message and checkpatch errors

[Javier Martinez Canillas]

Hello Shuah,

On 07/12/2016 11:07 AM, Shuah Khan wrote:
> On 07/12/2016 09:03 AM, Javier Martinez Canillas wrote:
>> Hello Shuah,
>>
>> On 07/11/2016 06:39 PM, Shuah Khan wrote:
>>> Fix misspelled error message and existing checkpatch errors in the
>>> error message conditional.
>>>
>>> WARNING: suspect code indent for conditional statements (8, 24)
>>> if (ctx->state != MFCINST_HEAD_PARSED &&
>>> [...]
>>> +   mfc_err("Can not get crop information\n");
>>>
>>> Signed-off-by: Shuah Khan 
>>> ---
>>
>> Patch looks good to me. Maybe is better to split the message and checkpatch
>> changes in two different patches. But I don't have a strong opinion on this:
>>
>> Reviewed-by: Javier Martinez Canillas 
>>
> 
> Thanks for the review. I considered splitting them, however the patch
> that fixes the message will be flagged by checkpatch. It does make
> sense to split the changes into two patches. What I could do is, make
> the checkpatch fixes the first patch and fix the error message in the
> second one.
> 
> How does that sound?
>

Sounds good to me.
 
> -- Shuah
> 
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 misspelled error message and checkpatch errors

[Shuah Khan]

On 07/12/2016 09:03 AM, Javier Martinez Canillas wrote:
> Hello Shuah,
> 
> On 07/11/2016 06:39 PM, Shuah Khan wrote:
>> Fix misspelled error message and existing checkpatch errors in the
>> error message conditional.
>>
>> WARNING: suspect code indent for conditional statements (8, 24)
>>  if (ctx->state != MFCINST_HEAD_PARSED &&
>> [...]
>> +   mfc_err("Can not get crop information\n");
>>
>> Signed-off-by: Shuah Khan 
>> ---
> 
> Patch looks good to me. Maybe is better to split the message and checkpatch
> changes in two different patches. But I don't have a strong opinion on this:
> 
> Reviewed-by: Javier Martinez Canillas 
> 

Thanks for the review. I considered splitting them, however the patch
that fixes the message will be flagged by checkpatch. It does make
sense to split the changes into two patches. What I could do is, make
the checkpatch fixes the first patch and fix the error message in the
second one.

How does that sound?

-- Shuah


--
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 -next] [media] rcar_vin: remove redundant return value check of platform_get_resource()

[weiyj_lk]

From: Wei Yongjun 

Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource(). And move those two call together
to make the connection between them more clear.

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/soc_camera/rcar_vin.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 9c13752..bf52262 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1888,10 +1888,6 @@ static int rcar_vin_probe(struct platform_device *pdev)
 
dev_dbg(>dev, "pdata_flags = %08x\n", pdata_flags);
 
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem == NULL)
-   return -EINVAL;
-
irq = platform_get_irq(pdev, 0);
if (irq <= 0)
return -EINVAL;
@@ -1901,6 +1897,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(>dev, mem);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);


--
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 remove void function return statement

[Javier Martinez Canillas]

Hello Shuah

On 07/11/2016 08:29 PM, Shuah Khan wrote:
> Remove void function return statement
> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index c96421f..b6fde20 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -495,7 +495,6 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
>   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>   s5p_mfc_clock_off();
>   wake_up_dev(dev, reason, err);
> - return;
>  }
>  
>  /* Header parsing interrupt handling */
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 misspelled error message and checkpatch errors

[Javier Martinez Canillas]

Hello Shuah,

On 07/11/2016 06:39 PM, Shuah Khan wrote:
> Fix misspelled error message and existing checkpatch errors in the
> error message conditional.
> 
> WARNING: suspect code indent for conditional statements (8, 24)
>   if (ctx->state != MFCINST_HEAD_PARSED &&
> [...]
> +   mfc_err("Can not get crop information\n");
> 
> Signed-off-by: Shuah Khan 
> ---

Patch looks good to me. Maybe is better to split the message and checkpatch
changes in two different patches. But I don't have a strong opinion on this:

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: fix a missing reference for V4L2_BUF_FLAG_LAST

[Mauro Carvalho Chehab]

Fix it by adding a header to the flat-table to match to
the list of define symbols.

As a side-effect, it also removes some exceptions from
videodev2.h.rst.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/buffer.rst| 38 +-
 Documentation/media/videodev2.h.rst.exceptions | 21 --
 2 files changed, 19 insertions(+), 40 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 16cdd8e2c4d7..5deb4a46f992 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -512,7 +512,7 @@ Buffer Flags
 :widths:   3 1 4
 
 
--  .. row 1
+-  .. _`V4L2-BUF-FLAG-MAPPED`:
 
-  ``V4L2_BUF_FLAG_MAPPED``
 
@@ -526,7 +526,7 @@ Buffer Flags
  :ref:`VIDIOC_DQBUF ` ioctl is called. Set by the
  driver.
 
--  .. row 2
+-  .. _`V4L2-BUF-FLAG-QUEUED`:
 
-  ``V4L2_BUF_FLAG_QUEUED``
 
@@ -541,7 +541,7 @@ Buffer Flags
  the ``VIDIOC_QBUF``\ ioctl it is always set and after
  ``VIDIOC_DQBUF`` always cleared.
 
--  .. row 3
+-  .. _`V4L2-BUF-FLAG-DONE`:
 
-  ``V4L2_BUF_FLAG_DONE``
 
@@ -557,7 +557,7 @@ Buffer Flags
  buffer is in "dequeued" state, in the application domain so to
  say.
 
--  .. row 4
+-  .. _`V4L2-BUF-FLAG-ERROR`:
 
-  ``V4L2_BUF_FLAG_ERROR``
 
@@ -569,7 +569,7 @@ Buffer Flags
  normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
  called.
 
--  .. row 5
+-  .. _`V4L2-BUF-FLAG-KEYFRAME`:
 
-  ``V4L2_BUF_FLAG_KEYFRAME``
 
@@ -582,7 +582,7 @@ Buffer Flags
  Applications can set this bit when ``type`` refers to an output
  stream.
 
--  .. row 6
+-  .. _`V4L2-BUF-FLAG-PFRAME`:
 
-  ``V4L2_BUF_FLAG_PFRAME``
 
@@ -593,7 +593,7 @@ Buffer Flags
  Applications can set this bit when ``type`` refers to an output
  stream.
 
--  .. row 7
+-  .. _`V4L2-BUF-FLAG-BFRAME`:
 
-  ``V4L2_BUF_FLAG_BFRAME``
 
@@ -605,7 +605,7 @@ Buffer Flags
  frames to specify its content. Applications can set this bit when
  ``type`` refers to an output stream.
 
--  .. row 8
+-  .. _`V4L2-BUF-FLAG-TIMECODE`:
 
-  ``V4L2_BUF_FLAG_TIMECODE``
 
@@ -616,7 +616,7 @@ Buffer Flags
  this bit and the corresponding ``timecode`` structure when
  ``type`` refers to an output stream.
 
--  .. row 9
+-  .. _`V4L2-BUF-FLAG-PREPARED`:
 
-  ``V4L2_BUF_FLAG_PREPARED``
 
@@ -629,7 +629,7 @@ Buffer Flags
  :ref:`VIDIOC_QBUF` or
  :ref:`VIDIOC_DQBUF ` ioctl is called.
 
--  .. row 10
+-  .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`:
 
-  ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE``
 
@@ -641,7 +641,7 @@ Buffer Flags
  will, probably, be passed on to a DMA-capable hardware unit for
  further processing or output.
 
--  .. row 11
+-  .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
 
-  ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
 
@@ -652,7 +652,7 @@ Buffer Flags
  this buffer has not been created by the CPU but by some
  DMA-capable unit, in which case caches have not been used.
 
--  .. row 12
+-  .. _`V4L2-BUF-FLAG-LAST`:
 
-  ``V4L2_BUF_FLAG_LAST``
 
@@ -668,7 +668,7 @@ Buffer Flags
  :ref:`VIDIOC_DQBUF ` ioctl will not block anymore,
  but return an ``EPIPE`` error code.
 
--  .. row 13
+-  .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
 
-  ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
 
@@ -678,7 +678,7 @@ Buffer Flags
  out bits not belonging to timestamp type by performing a logical
  and operation with buffer flags and timestamp mask.
 
--  .. row 14
+-  .. _`V4L2-BUF-FLAG-TIMESTAMP-UNKNOWN`:
 
-  ``V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN``
 
@@ -692,7 +692,7 @@ Buffer Flags
  :c:func:`clock_gettime(2)` using clock IDs ``CLOCK_MONOTONIC``
  and ``CLOCK_REALTIME``, respectively.
 
--  .. row 15
+-  .. _`V4L2-BUF-FLAG-TIMESTAMP-MONOTONIC`:
 
-  ``V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC``
 
@@ -702,7 +702,7 @@ Buffer Flags
  clock. To access the same clock outside V4L2, use
  :c:func:`clock_gettime(2)`.
 
--  .. row 16
+-  .. _`V4L2-BUF-FLAG-TIMESTAMP-COPY`:
 
-  ``V4L2_BUF_FLAG_TIMESTAMP_COPY``
 
@@ -711,7 +711,7 @@ Buffer Flags
-  The CAPTURE buffer timestamp has been taken from the corresponding
  OUTPUT buffer. This flag applies only to mem2mem devices.
 
--  .. row 17
+-  .. _`V4L2-BUF-FLAG-TSTAMP-SRC-MASK`:
 
-  ``V4L2_BUF_FLAG_TSTAMP_SRC_MASK``
 
@@ -725,7 +725,7 @@ Buffer Flags
  ``type`` refers to an output stream and
  ``V4L2_BUF_FLAG_TIMESTAMP_COPY`` is set.
 
--  .. row 18
+-  .. _`V4L2-BUF-FLAG-TSTAMP-SRC-EOF`:
 
-  ``V4L2_BUF_FLAG_TSTAMP_SRC_EOF``
 
@@ -738,7 

Re: [PATCH] media: s5p-mfc Fix misspelled error message and checkpatch errors

[Shuah Khan]

On 07/12/2016 08:06 AM, Joe Perches wrote:
> On Mon, 2016-07-11 at 16:39 -0600, Shuah Khan wrote:
>> Fix misspelled error message and existing checkpatch errors in the
>> error message conditional.
> []
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> []
>> @@ -775,11 +775,11 @@ static int vidioc_g_crop(struct file *file, void *priv,
>>  u32 left, right, top, bottom;
>>  
>>  if (ctx->state != MFCINST_HEAD_PARSED &&
>> -ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
>> -&& ctx->state != MFCINST_FINISHED) {
>> -mfc_err("Cannont set crop\n");
>> -return -EINVAL;
>> -}
>> +ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
>> +&& ctx->state != MFCINST_FINISHED) {
>> +mfc_err("Can not get crop information\n");
>> +return -EINVAL;
>> +}
> 
> is it a set or a get?

vidioc_g_crop is a get routine.

> 
> It'd be nicer for humans to read if the alignment was consistent

Are you okay with this alignment change or would you like it
changed? checkpatch stopped complaining with the code as follows:

> 
>   if (ctx->state != MFCINST_HEAD_PARSED &&
>   ctx->state != MFCINST_RUNNING &&
>   ctx->state != MFCINST_FINISHING &&
>   ctx->state != MFCINST_FINISHED) {
>   mfc_err("Can not get crop information\n");
>   return -EINVAL;
>   }
> 
> 

thanks,
-- Shuah

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

vidioc-g-dv-timings.rst: document interlaced defines

[Hans Verkuil]

Fix missing references.

Signed-off-by: Hans Verkuil 

diff --git a/Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst 
b/Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst
index e19d64e..f7bf21f 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-dv-timings.rst
@@ -100,7 +100,7 @@ EBUSY

-  ``interlaced``

-   -  Progressive (0) or interlaced (1)
+   -  Progressive (``V4L2_DV_PROGRESSIVE``) or interlaced 
(``V4L2_DV_INTERLACED``).

 -  .. row 4

diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c15660f..b9be796 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -280,8 +280,8 @@ replace define V4L2_STD_ALL v4l2-std-id

 # V4L2 DT BT timings definitions

-replace define V4L2_DV_PROGRESSIVE v4l2-dv-fixme
-replace define V4L2_DV_INTERLACED v4l2-dv-fixme
+replace define V4L2_DV_PROGRESSIVE v4l2-bt-timings
+replace define V4L2_DV_INTERLACED v4l2-bt-timings

 replace define V4L2_DV_VSYNC_POS_POL v4l2-bt-timings
 replace define V4L2_DV_HSYNC_POS_POL v4l2-bt-timings
--
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] pixfmt-006.rst: add missing V4L2_YCBCR_ENC_SMPTE240M

[Hans Verkuil]

Fix missing reference.

Signed-off-by: Hans Verkuil 

diff --git a/Documentation/media/uapi/v4l/pixfmt-006.rst 
b/Documentation/media/uapi/v4l/pixfmt-006.rst
index 9a0f494..987b9a8 100644
--- a/Documentation/media/uapi/v4l/pixfmt-006.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-006.rst
@@ -240,6 +240,12 @@ needs to be filled in.

-  Use the constant luminance BT.2020 Yc'CbcCrc encoding.

+-  .. row 10
+
+   -  ``V4L2_YCBCR_ENC_SMPTE_240M``
+
+   -  Use the SMPTE 240M Y'CbCr encoding.
+


 .. _v4l2-quantization:
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c15660f..8852b99 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -85,9 +85,7 @@ replace symbol V4L2_YCBCR_ENC_DEFAULT v4l2-ycbcr-encoding
 replace symbol V4L2_YCBCR_ENC_SYCC v4l2-ycbcr-encoding
 replace symbol V4L2_YCBCR_ENC_XV601 v4l2-ycbcr-encoding
 replace symbol V4L2_YCBCR_ENC_XV709 v4l2-ycbcr-encoding
-
-# Is this deprecated, or just a missing reference?
-replace symbol V4L2_YCBCR_ENC_SMPTE240M v4l2-ycbcr-encoding-FIXME
+replace symbol V4L2_YCBCR_ENC_SMPTE240M v4l2-ycbcr-encoding

 # Documented enum v4l2_quantization
 replace symbol V4L2_QUANTIZATION_DEFAULT v4l2-quantization
--
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 misspelled error message and checkpatch errors

[Joe Perches]

On Mon, 2016-07-11 at 16:39 -0600, Shuah Khan wrote:
> Fix misspelled error message and existing checkpatch errors in the
> error message conditional.
[]
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
[]
> @@ -775,11 +775,11 @@ static int vidioc_g_crop(struct file *file, void *priv,
>   u32 left, right, top, bottom;
>  
>   if (ctx->state != MFCINST_HEAD_PARSED &&
> - ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
> - && ctx->state != MFCINST_FINISHED) {
> - mfc_err("Cannont set crop\n");
> - return -EINVAL;
> - }
> + ctx->state != MFCINST_RUNNING && ctx->state != MFCINST_FINISHING
> + && ctx->state != MFCINST_FINISHED) {
> + mfc_err("Can not get crop information\n");
> + return -EINVAL;
> + }

is it a set or a get?

It'd be nicer for humans to read if the alignment was consistent

if (ctx->state != MFCINST_HEAD_PARSED &&
    ctx->state != MFCINST_RUNNING &&
    ctx->state != MFCINST_FINISHING &&
    ctx->state != MFCINST_FINISHED) {
mfc_err("Can not get crop information\n");
return -EINVAL;
}


--
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 03/20] [media] lirc.h: remove several unused ioctls

[Mauro Carvalho Chehab]

Em Tue, 12 Jul 2016 14:54:38 +0100
Sean Young  escreveu:

> On Tue, Jul 12, 2016 at 02:35:56PM +0100, Sean Young wrote:
> > On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:  
> > > Em Tue, 12 Jul 2016 14:14:06 +0100
> > > Sean Young  escreveu:  
> > > > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:  
> > -snip-  
> > > > > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> > > > >   
> > > > 
> > > > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > > > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.  
> > > 
> > > Removing the "LIRC_CAN" macros can break userspace, as some app could
> > > be using it to print the LIRC features. That's why I opted to keep
> > > them, but to document that those features are unused - this is at
> > > the next patch (04/20).  
> > 
> > How is that different from removing the ioctls? Might as well go the whole
> > hog.  

If someone implemented LIRC_GET_FEATURES and handled all flags, such
program would break, as the API change.

> 
> Ah you meant that if someone later adds a new feature then we might reuse
> an existing bit. Oops, sorry.

Yes, this is another possibility. In such case, the ABI will also 
break, with is more severe than a pure API change.

Removing the ioctl declarations will still work for compiled programs,
as they'll still receive an error code when the ioctl is issued.

> 
> > Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
> > LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
> > end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.  
> 
> So there is an argument for removing LIRC_CAN_SET_REC_DUTY_CYCLE, but
> that should be a separate patch.

Yes. Yet, IMHO, the best would be to put those unused LIRC_CAN into a:

#ifndef __KERNEL

macro block, to:

1) avoid the risk of breaking userspace;
2) be clear that those are deprecated stuff and should not be used on
   newer programs;
3) Reserve the bits for not be used, to avoid possible conflicts.

Regards,
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 1/2] cec: add sanity check for msg->len

[Hans Verkuil]

Check (and warn) if the msg->len is too long or if it is 0.

Should never happen, but just in case...

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/cec-adap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 2cd656b..936df93 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -759,6 +759,9 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
bool is_reply = false;
bool valid_la = true;
 
+   if (WARN_ON(!msg->len || msg->len > CEC_MAX_MSG_SIZE))
+   return;
+
mutex_lock(>lock);
msg->ts = ktime_get_ns();
msg->rx_status = CEC_RX_STATUS_OK;
-- 
2.7.0

--
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] cec: split the timestamp into an rx and tx timestamp

[Hans Verkuil]

When transmitting a message and waiting for a reply it would be good
to know the time between when the message was transmitted and when
the reply arrived. With only one timestamp field it was set to when
the reply arrived and the original transmit time was overwritten.

Just taking the timestamp in userspace right before CEC_TRANSMIT is
called is not reliable, since the actual transmit can be delayed if the CEC bus
is busy. Only the driver can fill this in accurately.

So split up the ts field into an rx_ts and a tx_ts. Also move the
status fields to after the 'reply' field: they were placed in a
strange position and make much more sense when grouped with the
other status-related fields.

This patch also makes sure that the timestamp is taken as soon as
possible.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/cec-adap.c | 24 
 include/linux/cec.h  | 18 ++
 2 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 936df93..154aadb 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -280,7 +280,7 @@ static void cec_data_cancel(struct cec_data *data)
list_del_init(>list);
 
/* Mark it as an error */
-   data->msg.ts = ktime_get_ns();
+   data->msg.tx_ts = ktime_get_ns();
data->msg.tx_status = CEC_TX_STATUS_ERROR |
  CEC_TX_STATUS_MAX_RETRIES;
data->attempts = 0;
@@ -455,6 +455,7 @@ void cec_transmit_done(struct cec_adapter *adap, u8 status, 
u8 arb_lost_cnt,
 {
struct cec_data *data;
struct cec_msg *msg;
+   u64 ts = ktime_get_ns();
 
dprintk(2, "cec_transmit_done %02x\n", status);
mutex_lock(>lock);
@@ -473,7 +474,7 @@ void cec_transmit_done(struct cec_adapter *adap, u8 status, 
u8 arb_lost_cnt,
 
/* Drivers must fill in the status! */
WARN_ON(status == 0);
-   msg->ts = ktime_get_ns();
+   msg->tx_ts = ts;
msg->tx_status |= status;
msg->tx_arb_lost_cnt += arb_lost_cnt;
msg->tx_nack_cnt += nack_cnt;
@@ -557,7 +558,7 @@ static void cec_wait_timeout(struct work_struct *work)
 
/* Mark the message as timed out */
list_del_init(>list);
-   data->msg.ts = ktime_get_ns();
+   data->msg.rx_ts = ktime_get_ns();
data->msg.rx_status = CEC_RX_STATUS_TIMEOUT;
cec_data_completed(data);
 unlock:
@@ -762,13 +763,14 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
if (WARN_ON(!msg->len || msg->len > CEC_MAX_MSG_SIZE))
return;
 
-   mutex_lock(>lock);
-   msg->ts = ktime_get_ns();
+   msg->rx_ts = ktime_get_ns();
msg->rx_status = CEC_RX_STATUS_OK;
-   msg->tx_status = 0;
msg->sequence = msg->reply = msg->timeout = 0;
+   msg->tx_status = 0;
+   msg->tx_ts = 0;
msg->flags = 0;
 
+   mutex_lock(>lock);
dprintk(2, "cec_received_msg: %*ph\n", msg->len, msg->msg);
 
/* Check if this message was for us (directed or broadcast). */
@@ -790,7 +792,6 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
 */
list_for_each_entry(data, >wait_queue, list) {
struct cec_msg *dst = >msg;
-   u8 dst_reply;
 
/* Does the command match? */
if ((abort && cmd != dst->msg[1]) ||
@@ -803,11 +804,10 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
continue;
 
/* We got a reply */
-   msg->sequence = dst->sequence;
-   msg->tx_status = dst->tx_status;
-   dst_reply = dst->reply;
-   *dst = *msg;
-   dst->reply = dst_reply;
+   memcpy(dst->msg, msg->msg, msg->len);
+   dst->len = msg->len;
+   dst->rx_ts = msg->rx_ts;
+   dst->rx_status = msg->rx_status;
if (abort) {
dst->reply = 0;
dst->rx_status |= CEC_RX_STATUS_FEATURE_ABORT;
diff --git a/include/linux/cec.h b/include/linux/cec.h
index 6678afe..b3e2289 100644
--- a/include/linux/cec.h
+++ b/include/linux/cec.h
@@ -48,9 +48,10 @@
 
 /**
  * struct cec_msg - CEC message structure.
- * @ts:Timestamp in nanoseconds using CLOCK_MONOTONIC. Set by 
the
- * driver. It is set when the message transmission has finished
- * and it is set when a message was received.
+ * @tx_ts: Timestamp in nanoseconds using CLOCK_MONOTONIC. Set by the
+ * driver when the message transmission has finished.
+ * @rx_ts: Timestamp in nanoseconds using 

[PATCH 0/2] CEC improvements

[Hans Verkuil]

Two CEC patches: one adds a sanity check, the other splits the timestamp into
two: one for rx and one for tx.

The work on the CEC compliance test made us realize that you need this 
information
it order to diagnose problems like reply messages that take too long.

A documentation patch will follow.

Regards,

Hans

Hans Verkuil (2):
  cec: add sanity check for msg->len
  cec: split the timestamp into an rx and tx timestamp

 drivers/staging/media/cec/cec-adap.c | 27 +++
 include/linux/cec.h  | 18 ++
 2 files changed, 25 insertions(+), 20 deletions(-)

-- 
2.7.0

--
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 03/20] [media] lirc.h: remove several unused ioctls

[Sean Young]

On Tue, Jul 12, 2016 at 02:35:56PM +0100, Sean Young wrote:
> On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 12 Jul 2016 14:14:06 +0100
> > Sean Young  escreveu:
> > > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
> -snip-
> > > > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> > > 
> > > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.
> > 
> > Removing the "LIRC_CAN" macros can break userspace, as some app could
> > be using it to print the LIRC features. That's why I opted to keep
> > them, but to document that those features are unused - this is at
> > the next patch (04/20).
> 
> How is that different from removing the ioctls? Might as well go the whole
> hog.

Ah you meant that if someone later adds a new feature then we might reuse
an existing bit. Oops, sorry.

> Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
> LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
> end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.

So there is an argument for removing LIRC_CAN_SET_REC_DUTY_CYCLE, but
that should be a separate patch.


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

Re: [PATCH 03/20] [media] lirc.h: remove several unused ioctls

[Sean Young]

On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 12 Jul 2016 14:14:06 +0100
> Sean Young  escreveu:
> > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
-snip-
> > > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> > 
> > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.
> 
> Removing the "LIRC_CAN" macros can break userspace, as some app could
> be using it to print the LIRC features. That's why I opted to keep
> them, but to document that those features are unused - this is at
> the next patch (04/20).

How is that different from removing the ioctls? Might as well go the whole
hog.

Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.


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

Re: [PATCH 08/20] [media] doc-rst: document ioctl LIRC_GET_REC_MODE

[Mauro Carvalho Chehab]

Em Tue, 12 Jul 2016 14:01:59 +0100
Sean Young  escreveu:

> On Tue, Jul 12, 2016 at 09:42:02AM -0300, Mauro Carvalho Chehab wrote:
> > Move the documentation of this ioctl from lirc_ioctl to its
> > own file, and add a short description about the pulse mode
> > used by IR RX.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/uapi/rc/lirc-get-rec-mode.rst  | 59 
> > ++
> >  .../media/uapi/rc/lirc_device_interface.rst|  1 +
> >  Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
> >  3 files changed, 60 insertions(+), 9 deletions(-)
> >  create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> > 
> > diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
> > b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> > new file mode 100644
> > index ..d46a488594c9
> > --- /dev/null
> > +++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> > @@ -0,0 +1,59 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _lirc_get_rec_mode:
> > +
> > +***
> > +ioctl LIRC_GET_REC_MODE
> > +***
> > +
> > +Name
> > +
> > +
> > +LIRC_GET_REC_MODE - Get supported receive modes.
> > +
> > +Synopsis
> > +
> > +
> > +.. cpp:function:: int ioctl( int fd, int request, __u32 rx_modes)
> > +
> > +Arguments
> > +=
> > +
> > +``fd``
> > +File descriptor returned by open().
> > +
> > +``request``
> > +LIRC_GET_REC_MODE
> > +
> > +``rx_modes``
> > +Bitmask with the supported transmit modes.
> > +
> > +Description
> > +===
> > +
> > +Get supported receive modes.
> > +
> > +Supported receive modes
> > +===
> > +
> > +.. _lirc-mode-mode2:
> > +
> > +``LIRC_MODE_MODE2``
> > +
> > +The driver returns a sequence of pulse and space codes to userspace.
> > +
> > +.. _lirc-mode-lirccode:
> > +
> > +``LIRC_MODE_LIRCCODE``
> > +
> > +The IR signal is decoded internally by the receiver. The LIRC interface
> > +returns the scancode as an integer value. This is the usual mode used
> > +by several TV media cards.  
> 
> Actually rc devices that produce scancodes (rather than raw IR) do have not
> have an associated lirc device so no LIRC_MODE_LIRCCODE there.

Yeah, I noticed. Yet, the core reports feature = LIRC_MODE_LIRCCODE if the
driver doesn't set features.

> The exception 
> to this is the lirc_sasem and lirc_zilog drivers in staging; those two are 
> the 
> only drivers that use LIRC_MODE_LIRCCODE at all.
> 
> The lirc_sasem driver should be ported to rc-core, but I've never been able
> to find the hardware for it. When it is ported it won't need LIRCCODE any
> more.
> 
> The lirc_zilog driver is just for sending and also should be ported to 
> rc-core. The hardware supports sending raw IR, I just do not know how so
> I can't port it.

Still, it makes sense to have LIRC_MODE_LIRCCODE supported for IR send,
in order to support HDMI CEC. That's why I opted to keep it documented.

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

Re: [PATCH 03/20] [media] lirc.h: remove several unused ioctls

[Mauro Carvalho Chehab]

Em Tue, 12 Jul 2016 14:14:06 +0100
Sean Young  escreveu:

> On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
> > While reviewing the documentation gaps on LIRC, it was
> > noticed that several ioctls aren't used by any LIRC drivers
> > (nor at staging or mainstream).
> > 
> > It doesn't make sense to document them, as they're not used
> > anywhere. So, let's remove those from the lirc header.  
> 
> Good to see these go.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  include/uapi/linux/lirc.h | 39 ++-
> >  1 file changed, 2 insertions(+), 37 deletions(-)
> > 
> > diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
> > index 4b3ab2966b5a..991ab4570b8e 100644
> > --- a/include/uapi/linux/lirc.h
> > +++ b/include/uapi/linux/lirc.h
> > @@ -90,20 +90,11 @@
> >  
> >  #define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
> >  #define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
> > -#define LIRC_GET_SEND_CARRIER  _IOR('i', 0x0003, __u32)
> > -#define LIRC_GET_REC_CARRIER   _IOR('i', 0x0004, __u32)
> > -#define LIRC_GET_SEND_DUTY_CYCLE   _IOR('i', 0x0005, __u32)
> > -#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, __u32)
> >  #define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
> >  
> >  #define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
> >  #define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
> >  
> > -#define LIRC_GET_MIN_FILTER_PULSE  _IOR('i', 0x000a, __u32)
> > -#define LIRC_GET_MAX_FILTER_PULSE  _IOR('i', 0x000b, __u32)
> > -#define LIRC_GET_MIN_FILTER_SPACE  _IOR('i', 0x000c, __u32)
> > -#define LIRC_GET_MAX_FILTER_SPACE  _IOR('i', 0x000d, __u32)
> > -
> >  /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
> >  #define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
> >  
> > @@ -113,7 +104,6 @@
> >  #define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
> >  #define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
> >  #define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
> > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> 
> Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.

Removing the "LIRC_CAN" macros can break userspace, as some app could
be using it to print the LIRC features. That's why I opted to keep
them, but to document that those features are unused - this is at
the next patch (04/20).

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

Re: [PATCH 03/20] [media] lirc.h: remove several unused ioctls

[Sean Young]

On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
> While reviewing the documentation gaps on LIRC, it was
> noticed that several ioctls aren't used by any LIRC drivers
> (nor at staging or mainstream).
> 
> It doesn't make sense to document them, as they're not used
> anywhere. So, let's remove those from the lirc header.

Good to see these go.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/uapi/linux/lirc.h | 39 ++-
>  1 file changed, 2 insertions(+), 37 deletions(-)
> 
> diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
> index 4b3ab2966b5a..991ab4570b8e 100644
> --- a/include/uapi/linux/lirc.h
> +++ b/include/uapi/linux/lirc.h
> @@ -90,20 +90,11 @@
>  
>  #define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
>  #define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
> -#define LIRC_GET_SEND_CARRIER  _IOR('i', 0x0003, __u32)
> -#define LIRC_GET_REC_CARRIER   _IOR('i', 0x0004, __u32)
> -#define LIRC_GET_SEND_DUTY_CYCLE   _IOR('i', 0x0005, __u32)
> -#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, __u32)
>  #define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
>  
>  #define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
>  #define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
>  
> -#define LIRC_GET_MIN_FILTER_PULSE  _IOR('i', 0x000a, __u32)
> -#define LIRC_GET_MAX_FILTER_PULSE  _IOR('i', 0x000b, __u32)
> -#define LIRC_GET_MIN_FILTER_SPACE  _IOR('i', 0x000c, __u32)
> -#define LIRC_GET_MAX_FILTER_SPACE  _IOR('i', 0x000d, __u32)
> -
>  /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
>  #define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
>  
> @@ -113,7 +104,6 @@
>  #define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
>  #define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
>  #define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
> -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)

Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.

>  #define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
>  
>  /*
> @@ -127,42 +117,17 @@
>  #define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, __u32)
>  
>  /*
> - * pulses shorter than this are filtered out by hardware (software
> - * emulation in lirc_dev?)
> - */
> -#define LIRC_SET_REC_FILTER_PULSE  _IOW('i', 0x001a, __u32)
> -/*
> - * spaces shorter than this are filtered out by hardware (software
> - * emulation in lirc_dev?)
> - */
> -#define LIRC_SET_REC_FILTER_SPACE  _IOW('i', 0x001b, __u32)
> -/*
> - * if filter cannot be set independently for pulse/space, this should
> - * be used
> - */
> -#define LIRC_SET_REC_FILTER_IOW('i', 0x001c, __u32)

Also remove LIRC_CAN_SET_REC_FILTER.
> -
> -/*
>   * if enabled from the next key press on the driver will send
>   * LIRC_MODE2_FREQUENCY packets
>   */
>  #define LIRC_SET_MEASURE_CARRIER_MODE_IOW('i', 0x001d, __u32)
>  
>  /*
> - * to set a range use
> - * LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE with the
> - * lower bound first and later
> - * LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER with the upper bound
> + * to set a range use LIRC_SET_REC_CARRIER_RANGE with the
> + * lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
>   */
> -
> -#define LIRC_SET_REC_DUTY_CYCLE_RANGE  _IOW('i', 0x001e, __u32)
>  #define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
>  
> -#define LIRC_NOTIFY_DECODE _IO('i', 0x0020)

Also remove LIRC_CAN_NOTIFY_DECODE.

> -
> -#define LIRC_SETUP_START   _IO('i', 0x0021)
> -#define LIRC_SETUP_END _IO('i', 0x0022)
> -
>  #define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
>  
>  #endif

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

Re: [PATCH 08/20] [media] doc-rst: document ioctl LIRC_GET_REC_MODE

[Sean Young]

On Tue, Jul 12, 2016 at 09:42:02AM -0300, Mauro Carvalho Chehab wrote:
> Move the documentation of this ioctl from lirc_ioctl to its
> own file, and add a short description about the pulse mode
> used by IR RX.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/rc/lirc-get-rec-mode.rst  | 59 
> ++
>  .../media/uapi/rc/lirc_device_interface.rst|  1 +
>  Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
>  3 files changed, 60 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> 
> diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
> b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> new file mode 100644
> index ..d46a488594c9
> --- /dev/null
> +++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> @@ -0,0 +1,59 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _lirc_get_rec_mode:
> +
> +***
> +ioctl LIRC_GET_REC_MODE
> +***
> +
> +Name
> +
> +
> +LIRC_GET_REC_MODE - Get supported receive modes.
> +
> +Synopsis
> +
> +
> +.. cpp:function:: int ioctl( int fd, int request, __u32 rx_modes)
> +
> +Arguments
> +=
> +
> +``fd``
> +File descriptor returned by open().
> +
> +``request``
> +LIRC_GET_REC_MODE
> +
> +``rx_modes``
> +Bitmask with the supported transmit modes.
> +
> +Description
> +===
> +
> +Get supported receive modes.
> +
> +Supported receive modes
> +===
> +
> +.. _lirc-mode-mode2:
> +
> +``LIRC_MODE_MODE2``
> +
> +The driver returns a sequence of pulse and space codes to userspace.
> +
> +.. _lirc-mode-lirccode:
> +
> +``LIRC_MODE_LIRCCODE``
> +
> +The IR signal is decoded internally by the receiver. The LIRC interface
> +returns the scancode as an integer value. This is the usual mode used
> +by several TV media cards.

Actually rc devices that produce scancodes (rather than raw IR) do have not
have an associated lirc device so no LIRC_MODE_LIRCCODE there. The exception 
to this is the lirc_sasem and lirc_zilog drivers in staging; those two are the 
only drivers that use LIRC_MODE_LIRCCODE at all.

The lirc_sasem driver should be ported to rc-core, but I've never been able
to find the hardware for it. When it is ported it won't need LIRCCODE any
more.

The lirc_zilog driver is just for sending and also should be ported to 
rc-core. The hardware supports sending raw IR, I just do not know how so
I can't port it.


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

[PATCH 03/20] [media] lirc.h: remove several unused ioctls

[Mauro Carvalho Chehab]

While reviewing the documentation gaps on LIRC, it was
noticed that several ioctls aren't used by any LIRC drivers
(nor at staging or mainstream).

It doesn't make sense to document them, as they're not used
anywhere. So, let's remove those from the lirc header.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/uapi/linux/lirc.h | 39 ++-
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
index 4b3ab2966b5a..991ab4570b8e 100644
--- a/include/uapi/linux/lirc.h
+++ b/include/uapi/linux/lirc.h
@@ -90,20 +90,11 @@
 
 #define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
 #define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
-#define LIRC_GET_SEND_CARRIER  _IOR('i', 0x0003, __u32)
-#define LIRC_GET_REC_CARRIER   _IOR('i', 0x0004, __u32)
-#define LIRC_GET_SEND_DUTY_CYCLE   _IOR('i', 0x0005, __u32)
-#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, __u32)
 #define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
 
 #define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
 #define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
 
-#define LIRC_GET_MIN_FILTER_PULSE  _IOR('i', 0x000a, __u32)
-#define LIRC_GET_MAX_FILTER_PULSE  _IOR('i', 0x000b, __u32)
-#define LIRC_GET_MIN_FILTER_SPACE  _IOR('i', 0x000c, __u32)
-#define LIRC_GET_MAX_FILTER_SPACE  _IOR('i', 0x000d, __u32)
-
 /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
 #define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
 
@@ -113,7 +104,6 @@
 #define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
 #define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
 #define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
-#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)
 #define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
 
 /*
@@ -127,42 +117,17 @@
 #define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, __u32)
 
 /*
- * pulses shorter than this are filtered out by hardware (software
- * emulation in lirc_dev?)
- */
-#define LIRC_SET_REC_FILTER_PULSE  _IOW('i', 0x001a, __u32)
-/*
- * spaces shorter than this are filtered out by hardware (software
- * emulation in lirc_dev?)
- */
-#define LIRC_SET_REC_FILTER_SPACE  _IOW('i', 0x001b, __u32)
-/*
- * if filter cannot be set independently for pulse/space, this should
- * be used
- */
-#define LIRC_SET_REC_FILTER_IOW('i', 0x001c, __u32)
-
-/*
  * if enabled from the next key press on the driver will send
  * LIRC_MODE2_FREQUENCY packets
  */
 #define LIRC_SET_MEASURE_CARRIER_MODE  _IOW('i', 0x001d, __u32)
 
 /*
- * to set a range use
- * LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE with the
- * lower bound first and later
- * LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER with the upper bound
+ * to set a range use LIRC_SET_REC_CARRIER_RANGE with the
+ * lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
  */
-
-#define LIRC_SET_REC_DUTY_CYCLE_RANGE  _IOW('i', 0x001e, __u32)
 #define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
 
-#define LIRC_NOTIFY_DECODE _IO('i', 0x0020)
-
-#define LIRC_SETUP_START   _IO('i', 0x0021)
-#define LIRC_SETUP_END _IO('i', 0x0022)
-
 #define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
 
 #endif
-- 
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 17/20] [media] doc-rst: add documentation for LIRC_SET_MEASURE_CARRIER_MODE

[Mauro Carvalho Chehab]

Place documentation for this ioctl on its own page.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../uapi/rc/lirc-set-measure-carrier-mode.rst  | 48 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
 3 files changed, 49 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst 
b/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst
new file mode 100644
index ..e145d9d1902d
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst
@@ -0,0 +1,48 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_measure_carrier_mode:
+
+***
+ioctl LIRC_SET_MEASURE_CARRIER_MODE
+***
+
+Name
+
+
+LIRC_SET_MEASURE_CARRIER_MODE - enable or disable measure mode
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *enable )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_MEASURE_CARRIER_MODE
+
+``enable``
+enable = 1 means enable measure mode, enable = 0 means disable measure
+mode.
+
+
+Description
+===
+
+.. _lirc-mode2-frequency:
+
+Enable or disable measure mode. If enabled, from the next key
+press on, the driver will send ``LIRC_MODE2_FREQUENCY`` packets. By
+default this should be turned off.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 9e57779ca2a6..2810253ba852 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -25,4 +25,5 @@ LIRC Device Interface
 lirc-set-send-carrier
 lirc-set-transmitter-mask
 lirc-set-rec-timeout-reports
+lirc-set-measure-carrier-mode
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index d99fa0eeef4c..d220fc233e6d 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -54,15 +54,6 @@ device can rely on working with the default settings 
initially.
 Set send/receive mode. Largely obsolete for send, as only
 ``LIRC_MODE_PULSE`` is supported.
 
-.. _LIRC_SET_MEASURE_CARRIER_MODE:
-.. _lirc-mode2-frequency:
-
-``LIRC_SET_MEASURE_CARRIER_MODE``
-
-Enable (1)/disable (0) measure mode. If enabled, from the next key
-press on, the driver will send ``LIRC_MODE2_FREQUENCY`` packets. By
-default this should be turned off.
-
 .. _LIRC_SET_WIDEBAND_RECEIVER:
 
 ``LIRC_SET_WIDEBAND_RECEIVER``
-- 
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 16/20] [media] doc-rst: document LIRC_SET_REC_TIMEOUT_REPORTS

[Mauro Carvalho Chehab]

Add a separate page for this ioctl and improve its documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-rec-timeout-reports.rst | 49 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |  8 
 3 files changed, 50 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst 
b/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst
new file mode 100644
index ..0c7f85d0ce3b
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst
@@ -0,0 +1,49 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_rec_timeout_reports:
+
+**
+ioctl LIRC_SET_REC_TIMEOUT_REPORTS
+**
+
+Name
+
+
+LIRC_SET_REC_TIMEOUT_REPORTS - enable or disable timeout reports for IR receive
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *enable )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_REC_TIMEOUT_REPORTS
+
+``enable``
+enable = 1 means enable timeout report, enable = 0 means disable timeout
+reports.
+
+
+Description
+===
+
+Enable or disable timeout reports for IR receive. By default, timeout reports
+should be turned off.
+
+.. note::
+
+   This ioctl is only valid for :ref:`LIRC_MODE_MODE2 `.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index df576d90c73a..9e57779ca2a6 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -24,4 +24,5 @@ LIRC Device Interface
 lirc-set-rec-carrier-range
 lirc-set-send-carrier
 lirc-set-transmitter-mask
+lirc-set-rec-timeout-reports
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 26544a5fc946..d99fa0eeef4c 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -54,14 +54,6 @@ device can rely on working with the default settings 
initially.
 Set send/receive mode. Largely obsolete for send, as only
 ``LIRC_MODE_PULSE`` is supported.
 
-.. _LIRC_SET_REC_TIMEOUT_REPORTS:
-
-``LIRC_SET_REC_TIMEOUT_REPORTS``
-
-Enable (1) or disable (0) timeout reports in ``LIRC_MODE_MODE2.`` By
-default, timeout reports should be turned off.
-
-
 .. _LIRC_SET_MEASURE_CARRIER_MODE:
 .. _lirc-mode2-frequency:
 
-- 
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 14/20] [media] doc-rst: document LIRC_SET_TRANSMITTER_MASK

[Mauro Carvalho Chehab]

Add proper documentation for this ioctl, providing some
additional information about its usage.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-transmitter-mask.rst| 53 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 10 
 3 files changed, 54 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst 
b/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst
new file mode 100644
index ..2b35e21b9bb9
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst
@@ -0,0 +1,53 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_transmitter_mask:
+
+***
+ioctl LIRC_SET_TRANSMITTER_MASK
+***
+
+Name
+
+
+LIRC_SET_TRANSMITTER_MASK - Enables send codes on a given set of transmitters
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *mask )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_TRANSMITTER_MASK
+
+``mask``
+Mask with channels to enable tx. Channel 0 is the least significant bit.
+
+
+Description
+===
+
+Some IR TX devices have multiple output channels, in such case,
+:ref:`LIRC_CAN_SET_TRANSMITTER_MASK ` is
+returned via :ref:`LIRC_GET_FEATURES` and this ioctl sets what channels will
+send IR codes.
+
+This ioctl enables the given set of transmitters. The first transmitter is
+encoded by the least significant bit and so on.
+
+When an invalid bit mask is given, i.e. a bit is set, even though the device
+does not have so many transitters, then this ioctl returns the number of
+available transitters and does nothing otherwise.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 06257caa82db..96765eccaa69 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -22,4 +22,5 @@ LIRC Device Interface
 lirc-set-rec-carrier
 lirc-set-rec-carrier-range
 lirc-set-send-carrier
+lirc-set-transmitter-mask
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index b1cca1465997..86bd70dba290 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -54,16 +54,6 @@ device can rely on working with the default settings 
initially.
 Set send/receive mode. Largely obsolete for send, as only
 ``LIRC_MODE_PULSE`` is supported.
 
-.. _LIRC_SET_TRANSMITTER_MASK:
-
-``LIRC_SET_TRANSMITTER_MASK``
-
-This enables the given set of transmitters. The first transmitter is
-encoded by the least significant bit, etc. When an invalid bit mask
-is given, i.e. a bit is set, even though the device does not have so
-many transitters, then this ioctl returns the number of available
-transitters and does nothing otherwise.
-
 .. _LIRC_SET_REC_TIMEOUT:
 
 ``LIRC_SET_REC_TIMEOUT``
-- 
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 09/20] [media] doc-rst: document LIRC_GET_REC_RESOLUTION

[Mauro Carvalho Chehab]

Improve the documentation for this ioctl, adding it to
a separate file, in order to look like the rest of the
book, and to later allow to generate a man page for this
ioctl.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-get-rec-resolution.rst  | 49 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 10 -
 3 files changed, 50 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-resolution.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst 
b/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst
new file mode 100644
index ..6ef1723878b4
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-rec-resolution.rst
@@ -0,0 +1,49 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_rec_resolution:
+
+*
+ioctl LIRC_GET_REC_RESOLUTION
+*
+
+Name
+
+
+LIRC_GET_REC_RESOLUTION - Obtain the value of receive resolution, in 
microseconds.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *microseconds)
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_REC_RESOLUTION
+
+``microseconds``
+Resolution, in microseconds.
+
+
+Description
+===
+
+Some receivers have maximum resolution which is defined by internal
+sample rate or data format limitations. E.g. it's common that
+signals can only be reported in 50 microsecond steps.
+
+This ioctl returns the integer value with such resolution, with can be
+used by userspace applications like lircd to automatically adjust the
+tolerance value.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 34044b0c8f9c..532f4e92d1e9 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -15,4 +15,5 @@ LIRC Device Interface
 lirc-get-features
 lirc-get-send-mode
 lirc-get-rec-mode
+lirc-get-rec-resolution
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 4656e30a5b5a..347b86d368b4 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -58,16 +58,6 @@ I/O control requests
 could be used to switch off carrier generation in the future, so
 these values should be reserved.
 
-.. _LIRC_GET_REC_RESOLUTION:
-
-``LIRC_GET_REC_RESOLUTION``
-
-Some receiver have maximum resolution which is defined by internal
-sample rate or data format limitations. E.g. it's common that
-signals can only be reported in 50 microsecond steps. This integer
-value is used by lircd to automatically adjust the aeps tolerance
-value in the lircd config file.
-
 .. _LIRC_GET_MIN_TIMEOUT:
 .. _LIRC_GET_MAX_TIMEOUT:
 
-- 
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 10/20] [media] doc-rst: document LIRC_SET_SEND_DUTY_CYCLE

[Mauro Carvalho Chehab]

Add a separate page for this ioctl.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-send-duty-cycle.rst | 49 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
 3 files changed, 50 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst 
b/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst
new file mode 100644
index ..48e7bb15fb69
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst
@@ -0,0 +1,49 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_send_duty_cycle:
+
+**
+ioctl LIRC_SET_SEND_DUTY_CYCLE
+**
+
+Name
+
+
+LIRC_SET_SEND_DUTY_CYCLE - Set the duty cycle of the carrier signal for
+IR transmit.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *duty_cycle)
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_SEND_DUTY_CYCLE
+
+``duty_cycle``
+Duty cicle, describing the pulse width in percent (from 1 to 99) of
+the total cycle. Values 0 and 100 are reserved.
+
+
+Description
+===
+
+Get/set the duty cycle of the carrier signal for IR transmit.
+
+Currently, no special meaning is defined for 0 or 100, but this
+could be used to switch off carrier generation in the future, so
+these values should be reserved.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 532f4e92d1e9..56f2d6122238 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -16,4 +16,5 @@ LIRC Device Interface
 lirc-get-send-mode
 lirc-get-rec-mode
 lirc-get-rec-resolution
+lirc-set-send-duty-cycle
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 347b86d368b4..c486703b95b8 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -49,15 +49,6 @@ device can rely on working with the default settings 
initially.
 I/O control requests
 
 
-.. _LIRC_SET_SEND_DUTY_CYCLE:
-
-``LIRC_SET_SEND_DUTY_CYCLE``
-
-Set the duty cycle (from 0 to 100) of the carrier signal.
-Currently, no special meaning is defined for 0 or 100, but this
-could be used to switch off carrier generation in the future, so
-these values should be reserved.
-
 .. _LIRC_GET_MIN_TIMEOUT:
 .. _LIRC_GET_MAX_TIMEOUT:
 
-- 
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 18/20] [media] doc-rst: document LIRC_SET_WIDEBAND_RECEIVER

[Mauro Carvalho Chehab]

Put documentation for this ioctl on a separate page and
improve it.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-wideband-receiver.rst   | 56 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 19 
 3 files changed, 57 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst 
b/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst
new file mode 100644
index ..cffb01fd1042
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst
@@ -0,0 +1,56 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_wideband_receiver:
+
+
+ioctl LIRC_SET_WIDEBAND_RECEIVER
+
+
+Name
+
+
+LIRC_SET_WIDEBAND_RECEIVER - enable wide band receiver.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *enable )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_WIDEBAND_RECEIVER
+
+``enable``
+enable = 1 means enable wideband receiver, enable = 0 means disable
+wideband receiver.
+
+
+Description
+===
+
+Some receivers are equipped with special wide band receiver which is
+intended to be used to learn output of existing remote. This ioctl
+allows enabling or disabling it.
+
+This might be useful of receivers that have otherwise narrow band receiver
+that prevents them to be used with some remotes. Wide band receiver might
+also be more precise. On the other hand its disadvantage it usually
+reduced range of reception.
+
+.. note:: Wide band receiver might be implictly enabled if you enable
+carrier reports. In that case it will be disabled as soon as you disable
+carrier reports. Trying to disable wide band receiver while carrier
+reports are active will do nothing.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 2810253ba852..e9cb510349a0 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -26,4 +26,5 @@ LIRC Device Interface
 lirc-set-transmitter-mask
 lirc-set-rec-timeout-reports
 lirc-set-measure-carrier-mode
+lirc-set-wideband-receiver
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index d220fc233e6d..fe5f2719ea77 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -54,25 +54,6 @@ device can rely on working with the default settings 
initially.
 Set send/receive mode. Largely obsolete for send, as only
 ``LIRC_MODE_PULSE`` is supported.
 
-.. _LIRC_SET_WIDEBAND_RECEIVER:
-
-``LIRC_SET_WIDEBAND_RECEIVER``
-
-Some receivers are equipped with special wide band receiver which is
-intended to be used to learn output of existing remote. Calling that
-ioctl with (1) will enable it, and with (0) disable it. This might
-be useful of receivers that have otherwise narrow band receiver that
-prevents them to be used with some remotes. Wide band receiver might
-also be more precise On the other hand its disadvantage it usually
-reduced range of reception.
-
-.. note:: Wide band receiver might be
-   implictly enabled if you enable carrier reports. In that case it
-   will be disabled as soon as you disable carrier reports. Trying to
-   disable wide band receiver while carrier reports are active will do
-   nothing.
-
-
 .. _lirc_dev_errors:
 
 Return Value
-- 
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 20/20] [media] doc-rst: reorganize LIRC ReST files

[Mauro Carvalho Chehab]

Reorganize the LIRC rst files, using "-" instead of "_" on
their names, and creating a separate chapter for syscalls.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../uapi/rc/{lirc_dev_intro.rst => lirc-dev-intro.rst} |  0
 Documentation/media/uapi/rc/lirc-dev.rst   | 14 ++
 .../uapi/rc/{lirc_device_interface.rst => lirc-func.rst}   | 11 +--
 .../media/uapi/rc/{lirc_read.rst => lirc-read.rst} |  8 
 .../media/uapi/rc/{lirc_write.rst => lirc-write.rst}   |  0
 Documentation/media/uapi/rc/remote_controllers.rst |  3 +--
 6 files changed, 24 insertions(+), 12 deletions(-)
 rename Documentation/media/uapi/rc/{lirc_dev_intro.rst => lirc-dev-intro.rst} 
(100%)
 create mode 100644 Documentation/media/uapi/rc/lirc-dev.rst
 rename Documentation/media/uapi/rc/{lirc_device_interface.rst => 
lirc-func.rst} (81%)
 rename Documentation/media/uapi/rc/{lirc_read.rst => lirc-read.rst} (83%)
 rename Documentation/media/uapi/rc/{lirc_write.rst => lirc-write.rst} (100%)

diff --git a/Documentation/media/uapi/rc/lirc_dev_intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
similarity index 100%
rename from Documentation/media/uapi/rc/lirc_dev_intro.rst
rename to Documentation/media/uapi/rc/lirc-dev-intro.rst
diff --git a/Documentation/media/uapi/rc/lirc-dev.rst 
b/Documentation/media/uapi/rc/lirc-dev.rst
new file mode 100644
index ..03cde25f5859
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-dev.rst
@@ -0,0 +1,14 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_dev:
+
+LIRC Device Interface
+=
+
+
+.. toctree::
+:maxdepth: 1
+
+lirc-dev-intro
+lirc-func
+lirc-header
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc-func.rst
similarity index 81%
rename from Documentation/media/uapi/rc/lirc_device_interface.rst
rename to Documentation/media/uapi/rc/lirc-func.rst
index a2ad957c96ae..9b5a772ec96c 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc-func.rst
@@ -1,17 +1,16 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _lirc_dev:
+.. _lirc_func:
 
-LIRC Device Interface
-=
+LIRC Function Reference
+===
 
 
 .. toctree::
 :maxdepth: 1
 
-lirc_dev_intro
-lirc_read
-lirc_write
+lirc-read
+lirc-write
 lirc-get-features
 lirc-get-send-mode
 lirc-get-rec-mode
diff --git a/Documentation/media/uapi/rc/lirc_read.rst 
b/Documentation/media/uapi/rc/lirc-read.rst
similarity index 83%
rename from Documentation/media/uapi/rc/lirc_read.rst
rename to Documentation/media/uapi/rc/lirc-read.rst
index a8f1b446c294..8d4e9b6e507d 100644
--- a/Documentation/media/uapi/rc/lirc_read.rst
+++ b/Documentation/media/uapi/rc/lirc-read.rst
@@ -44,10 +44,10 @@ is greater than ``SSIZE_MAX``, the result is unspecified.
 The lircd userspace daemon reads raw IR data from the LIRC chardev. The
 exact format of the data depends on what modes a driver supports, and
 what mode has been selected. lircd obtains supported modes and sets the
-active mode via the ioctl interface, detailed at :ref:`lirc_ioctl`.
-The generally preferred mode is LIRC_MODE_MODE2, in which packets
-containing an int value describing an IR signal are read from the
-chardev.
+active mode via the ioctl interface, detailed at :ref:`lirc_func`.
+The generally preferred mode for receive is
+:ref:`LIRC_MODE_MODE2 `, in which packets containing an
+int value describing an IR signal are read from the chardev.
 
 See also
 `http://www.lirc.org/html/technical.html 
`__
diff --git a/Documentation/media/uapi/rc/lirc_write.rst 
b/Documentation/media/uapi/rc/lirc-write.rst
similarity index 100%
rename from Documentation/media/uapi/rc/lirc_write.rst
rename to Documentation/media/uapi/rc/lirc-write.rst
diff --git a/Documentation/media/uapi/rc/remote_controllers.rst 
b/Documentation/media/uapi/rc/remote_controllers.rst
index 3e9731afedd9..169286501ebb 100644
--- a/Documentation/media/uapi/rc/remote_controllers.rst
+++ b/Documentation/media/uapi/rc/remote_controllers.rst
@@ -23,8 +23,7 @@ Remote Controllers
 rc-sysfs-nodes
 rc-tables
 rc-table-change
-lirc_device_interface
-lirc-header
+lirc-dev
 
 
 **
-- 
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 13/20] [media] doc-rst: document LIRC set carrier ioctls

[Mauro Carvalho Chehab]

Put each ioctl on its own page and improve documentation, adding
cross-references for LIRC_SET_REC_CARRIER_RANGE and LIRC_SET_REC_CARRIER,
with can be used together to set a carrier frequency range.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-rec-carrier-range.rst   | 49 ++
 .../media/uapi/rc/lirc-set-rec-carrier.rst | 48 +
 .../media/uapi/rc/lirc-set-send-carrier.rst| 43 +++
 .../media/uapi/rc/lirc_device_interface.rst|  3 ++
 Documentation/media/uapi/rc/lirc_ioctl.rst | 18 
 5 files changed, 143 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-carrier.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-send-carrier.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst 
b/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst
new file mode 100644
index ..7cce9c8ba361
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst
@@ -0,0 +1,49 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_rec_carrier_range:
+
+
+ioctl LIRC_SET_REC_CARRIER_RANGE
+
+
+Name
+
+
+LIRC_SET_REC_CARRIER_RANGE - Set lower bond of the carrier used to modulate
+IR receive.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_REC_CARRIER_RANGE
+
+``frequency``
+Frequency of the carrier that modulates PWM data, in Hz.
+
+Description
+===
+
+This ioctl sets the upper range of carrier frequency that will be recognized
+by the IR receiver.
+
+.. note::
+
+   To set a range use :ref:`LIRC_SET_REC_CARRIER_RANGE
+   ` with the lower bound first and later call
+   :ref:`LIRC_SET_REC_CARRIER ` with the upper bound.
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst 
b/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst
new file mode 100644
index ..17ddb4723caa
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-rec-carrier.rst
@@ -0,0 +1,48 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_rec_carrier:
+
+**
+ioctl LIRC_SET_REC_CARRIER
+**
+
+Name
+
+
+LIRC_SET_REC_CARRIER - Set carrier used to modulate IR receive.
+
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_REC_CARRIER
+
+``frequency``
+Frequency of the carrier that modulates PWM data, in Hz.
+
+Description
+===
+
+Set receive carrier used to modulate IR PWM pulses and spaces.
+
+.. note::
+
+   If called together with :ref:`LIRC_SET_REC_CARRIER_RANGE`, this ioctl
+   sets the upper bound frequency that will be recognized by the device.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc-set-send-carrier.rst 
b/Documentation/media/uapi/rc/lirc-set-send-carrier.rst
new file mode 100644
index ..4314d4c86ced
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-send-carrier.rst
@@ -0,0 +1,43 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_send_carrier:
+
+***
+ioctl LIRC_SET_SEND_CARRIER
+***
+
+Name
+
+
+LIRC_SET_SEND_CARRIER - Set send carrier used to modulate IR TX.
+
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *frequency )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_SEND_CARRIER
+
+``frequency``
+Frequency of the carrier to be modulated, in Hz.
+
+Description
+===
+
+Set send carrier used to modulate IR PWM pulses and spaces.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index f8a619e233c0..06257caa82db 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -19,4 +19,7 @@ LIRC Device Interface
 lirc-set-send-duty-cycle
 lirc-get-timeout

[PATCH 05/20] [media] doc-rst: Fix LIRC_GET_FEATURES references

[Mauro Carvalho Chehab]

The references pointed by LIRC_GET_FEATURES ioctl are broken.

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/lirc.h.rst.exceptions |  4 +
 Documentation/media/uapi/rc/lirc-get-features.rst | 95 +--
 2 files changed, 60 insertions(+), 39 deletions(-)

diff --git a/Documentation/media/lirc.h.rst.exceptions 
b/Documentation/media/lirc.h.rst.exceptions
index 17f6e7e9550d..246c850151d7 100644
--- a/Documentation/media/lirc.h.rst.exceptions
+++ b/Documentation/media/lirc.h.rst.exceptions
@@ -24,6 +24,10 @@ ignore define LIRC_REC2MODE
 ignore define LIRC_CAN_SEND
 ignore define LIRC_CAN_REC
 
+ignore define LIRC_CAN_SEND_MASK
+ignore define LIRC_CAN_REC_MASK
+ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
+
 # Undocumented macros
 
 ignore define PULSE_BIT
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index 04ba9567053a..d89712190d43 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -40,120 +40,137 @@ is undefined.
 LIRC features
 =
 
-.. _LIRC_CAN_REC_RAW:
+.. _LIRC-CAN-REC-RAW:
 
 ``LIRC_CAN_REC_RAW``
+
 The driver is capable of receiving using
-:ref:`LIRC_MODE_RAW.`
+:ref:`LIRC_MODE_RAW `.
 
-.. _LIRC_CAN_REC_PULSE:
+.. _LIRC-CAN-REC-PULSE:
 
 ``LIRC_CAN_REC_PULSE``
+
 The driver is capable of receiving using
-:ref:`LIRC_MODE_PULSE.`
+:ref:`LIRC_MODE_PULSE `.
 
-.. _LIRC_CAN_REC_MODE2:
+.. _LIRC-CAN-REC-MODE2:
 
 ``LIRC_CAN_REC_MODE2``
+
 The driver is capable of receiving using
-:ref:`LIRC_MODE_MODE2.`
+:ref:`LIRC_MODE_MODE2 `.
 
-.. _LIRC_CAN_REC_LIRCCODE:
+.. _LIRC-CAN-REC-LIRCCODE:
 
 ``LIRC_CAN_REC_LIRCCODE``
+
 The driver is capable of receiving using
-:ref:`LIRC_MODE_LIRCCODE.`
+:ref:`LIRC_MODE_LIRCCODE `.
 
-.. _LIRC_CAN_SET_SEND_CARRIER:
+.. _LIRC-CAN-SET-SEND-CARRIER:
 
 ``LIRC_CAN_SET_SEND_CARRIER``
+
 The driver supports changing the modulation frequency via
-:ref:`LIRC_SET_SEND_CARRIER.`
+:ref:`ioctl LIRC_SET_SEND_CARRIER `.
 
-.. _LIRC_CAN_SET_SEND_DUTY_CYCLE:
+.. _LIRC-CAN-SET-SEND-DUTY-CYCLE:
 
 ``LIRC_CAN_SET_SEND_DUTY_CYCLE``
+
 The driver supports changing the duty cycle using
-:ref:`LIRC_SET_SEND_DUTY_CYCLE`.
+:ref:`ioctl LIRC_SET_SEND_DUTY_CYCLE `.
 
-.. _LIRC_CAN_SET_TRANSMITTER_MASK:
+.. _LIRC-CAN-SET-TRANSMITTER-MASK:
 
 ``LIRC_CAN_SET_TRANSMITTER_MASK``
+
 The driver supports changing the active transmitter(s) using
-:ref:`LIRC_SET_TRANSMITTER_MASK.`
+:ref:`ioctl LIRC_SET_TRANSMITTER_MASK `.
 
-.. _LIRC_CAN_SET_REC_CARRIER:
+.. _LIRC-CAN-SET-REC-CARRIER:
 
 ``LIRC_CAN_SET_REC_CARRIER``
+
 The driver supports setting the receive carrier frequency using
-:ref:`LIRC_SET_REC_CARRIER.`
+:ref:`ioctl LIRC_SET_REC_CARRIER `.
 
-.. _LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE:
+.. _LIRC-CAN-SET-REC-DUTY-CYCLE-RANGE:
 
 ``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE``
+
 Unused. Kept just to avoid breaking uAPI.
 
-.. _LIRC_CAN_SET_REC_CARRIER_RANGE:
+.. _LIRC-CAN-SET-REC-CARRIER-RANGE:
 
 ``LIRC_CAN_SET_REC_CARRIER_RANGE``
+
 The driver supports
-:ref:`LIRC_SET_REC_CARRIER_RANGE.`
+:ref:`ioctl LIRC_SET_REC_CARRIER_RANGE `.
 
-.. _LIRC_CAN_GET_REC_RESOLUTION:
+.. _LIRC-CAN-GET-REC-RESOLUTION:
 
 ``LIRC_CAN_GET_REC_RESOLUTION``
+
 The driver supports
-:ref:`LIRC_GET_REC_RESOLUTION.`
+:ref:`ioctl LIRC_GET_REC_RESOLUTION `.
 
-.. _LIRC_CAN_SET_REC_TIMEOUT:
+.. _LIRC-CAN-SET-REC-TIMEOUT:
 
 ``LIRC_CAN_SET_REC_TIMEOUT``
+
 The driver supports
-:ref:`LIRC_SET_REC_TIMEOUT.`
+:ref:`ioctl LIRC_SET_REC_TIMEOUT `.
 
-.. _LIRC_CAN_SET_REC_FILTER:
+.. _LIRC-CAN-SET-REC-FILTER:
 
 ``LIRC_CAN_SET_REC_FILTER``
+
 Unused. Kept just to avoid breaking uAPI.
 
-.. _LIRC_CAN_MEASURE_CARRIER:
+.. _LIRC-CAN-MEASURE-CARRIER:
 
 ``LIRC_CAN_MEASURE_CARRIER``
+
 The driver supports measuring of the modulation frequency using
-:ref:`LIRC_SET_MEASURE_CARRIER_MODE`.
+:ref:`ioctl LIRC_SET_MEASURE_CARRIER_MODE `.
 
-.. _LIRC_CAN_USE_WIDEBAND_RECEIVER:
+.. _LIRC-CAN-USE-WIDEBAND-RECEIVER:
 
 ``LIRC_CAN_USE_WIDEBAND_RECEIVER``
+
 The driver supports learning mode using
-:ref:`LIRC_SET_WIDEBAND_RECEIVER.`
+:ref:`ioctl LIRC_SET_WIDEBAND_RECEIVER `.
 
-.. _LIRC_CAN_NOTIFY_DECODE:
+.. _LIRC-CAN-NOTIFY-DECODE:
 
 ``LIRC_CAN_NOTIFY_DECODE``
+
 Unused. Kept just to avoid breaking uAPI.
 
-.. _LIRC_CAN_SEND_RAW:
+.. _LIRC-CAN-SEND-RAW:
 
 ``LIRC_CAN_SEND_RAW``
-The driver supports sending using
-:ref:`LIRC_MODE_RAW.`
 
-.. _LIRC_CAN_SEND_PULSE:
+The driver supports sending using :ref:`LIRC_MODE_RAW `.
+
+.. _LIRC-CAN-SEND-PULSE:
 
 ``LIRC_CAN_SEND_PULSE``
-The driver supports sending using
-:ref:`LIRC_MODE_PULSE.`
 
-.. _LIRC_CAN_SEND_MODE2:
+The driver supports sending using :ref:`LIRC_MODE_PULSE `.
+
+.. _LIRC-CAN-SEND-MODE2:
 
 

[PATCH 12/20] [media] doc-rst: Document LIRC_GET_LENGTH ioctl

[Mauro Carvalho Chehab]

Put documentation for this ioctl on its own page.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-length.rst| 45 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 11 --
 3 files changed, 46 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-length.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-length.rst 
b/Documentation/media/uapi/rc/lirc-get-length.rst
new file mode 100644
index ..d11c3d3f2c06
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-length.rst
@@ -0,0 +1,45 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_length:
+
+*
+ioctl LIRC_GET_LENGTH
+*
+
+Name
+
+
+LIRC_GET_LENGTH - Retrieves the code length in bits.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *length )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_LENGTH
+
+``length``
+length, in bits
+
+
+Description
+===
+
+Retrieves the code length in bits (only for ``LIRC-MODE-LIRCCODE``).
+Reads on the device must be done in blocks matching the bit count.
+The bit could should be rounded up so that it matches full bytes.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 197173f9ece5..f8a619e233c0 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -18,4 +18,5 @@ LIRC Device Interface
 lirc-get-rec-resolution
 lirc-set-send-duty-cycle
 lirc-get-timeout
+lirc-get-length
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 0a16659e9dad..93531c37fd27 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -46,17 +46,6 @@ device can rely on working with the default settings 
initially.
 
 .. _lirc-request:
 
-I/O control requests
-
-
-.. _LIRC_GET_LENGTH:
-
-``LIRC_GET_LENGTH``
-
-Retrieves the code length in bits (only for ``LIRC_MODE_LIRCCODE).``
-Reads on the device must be done in blocks matching the bit count.
-The bit could should be rounded up so that it matches full bytes.
-
 .. _LIRC_SET_SEND_MODE:
 .. _LIRC_SET_REC_MODE:
 
-- 
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 15/20] [media] doc-rst: document LIRC_SET_REC_TIMEOUT

[Mauro Carvalho Chehab]

Add a separate page for this ioctl and adds the cross-references.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/rc/lirc-set-rec-timeout.rst | 52 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 11 -
 3 files changed, 53 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-timeout.rst

diff --git a/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst 
b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
new file mode 100644
index ..ffc88f9fcd52
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
@@ -0,0 +1,52 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_rec_timeout:
+
+**
+ioctl LIRC_SET_REC_TIMEOUT
+**
+
+Name
+
+
+LIRC_SET_REC_TIMEOUT - sets the integer value for IR inactivity timeout.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *timeout )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_SET_REC_TIMEOUT
+
+``timeout``
+Timeout, in microseconds.
+
+
+Description
+===
+
+Sets the integer value for IR inactivity timeout.
+
+If supported by the hardware, setting it to 0  disables all hardware timeouts
+and data should be reported as soon as possible. If the exact value
+cannot be set, then the next possible value _greater_ than the
+given value should be set.
+
+.. note::
+
+   The range of supported timeout is given by :ref:`LIRC_GET_MIN_TIMEOUT`.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 96765eccaa69..df576d90c73a 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -18,6 +18,7 @@ LIRC Device Interface
 lirc-get-rec-resolution
 lirc-set-send-duty-cycle
 lirc-get-timeout
+lirc-set-rec-timeout
 lirc-get-length
 lirc-set-rec-carrier
 lirc-set-rec-carrier-range
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 86bd70dba290..26544a5fc946 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -54,17 +54,6 @@ device can rely on working with the default settings 
initially.
 Set send/receive mode. Largely obsolete for send, as only
 ``LIRC_MODE_PULSE`` is supported.
 
-.. _LIRC_SET_REC_TIMEOUT:
-
-``LIRC_SET_REC_TIMEOUT``
-
-Sets the integer value for IR inactivity timeout (cf.
-``LIRC_GET_MIN_TIMEOUT`` and ``LIRC_GET_MAX_TIMEOUT).`` A value of 0
-(if supported by the hardware) disables all hardware timeouts and
-data should be reported as soon as possible. If the exact value
-cannot be set, then the next possible value _greater_ than the
-given value should be set.
-
 .. _LIRC_SET_REC_TIMEOUT_REPORTS:
 
 ``LIRC_SET_REC_TIMEOUT_REPORTS``
-- 
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 08/20] [media] doc-rst: document ioctl LIRC_GET_REC_MODE

[Mauro Carvalho Chehab]

Move the documentation of this ioctl from lirc_ioctl to its
own file, and add a short description about the pulse mode
used by IR RX.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  | 59 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
 3 files changed, 60 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-mode.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
new file mode 100644
index ..d46a488594c9
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
@@ -0,0 +1,59 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_rec_mode:
+
+***
+ioctl LIRC_GET_REC_MODE
+***
+
+Name
+
+
+LIRC_GET_REC_MODE - Get supported receive modes.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 rx_modes)
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_REC_MODE
+
+``rx_modes``
+Bitmask with the supported transmit modes.
+
+Description
+===
+
+Get supported receive modes.
+
+Supported receive modes
+===
+
+.. _lirc-mode-mode2:
+
+``LIRC_MODE_MODE2``
+
+The driver returns a sequence of pulse and space codes to userspace.
+
+.. _lirc-mode-lirccode:
+
+``LIRC_MODE_LIRCCODE``
+
+The IR signal is decoded internally by the receiver. The LIRC interface
+returns the scancode as an integer value. This is the usual mode used
+by several TV media cards.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index f6ebf09cca60..34044b0c8f9c 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -14,4 +14,5 @@ LIRC Device Interface
 lirc_write
 lirc-get-features
 lirc-get-send-mode
+lirc-get-rec-mode
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 8e9809a03b8f..4656e30a5b5a 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -49,15 +49,6 @@ device can rely on working with the default settings 
initially.
 I/O control requests
 
 
-.. _LIRC_GET_REC_MODE:
-.. _lirc-mode-mode2:
-.. _lirc-mode-lirccode:
-
-``LIRC_GET_REC_MODE``
-
-Get supported receive modes. Only ``LIRC_MODE_MODE2`` and
-``LIRC_MODE_LIRCCODE`` are supported by lircd.
-
 .. _LIRC_SET_SEND_DUTY_CYCLE:
 
 ``LIRC_SET_SEND_DUTY_CYCLE``
-- 
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 04/20] [media] doc-rst: remove not used ioctls from documentation

[Mauro Carvalho Chehab]

As we removed those ioctls from the header file, do the
same at the documentation side.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-features.rst |  9 +--
 Documentation/media/uapi/rc/lirc_ioctl.rst| 74 ++-
 2 files changed, 9 insertions(+), 74 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index 6850f804a96c..04ba9567053a 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -91,8 +91,7 @@ LIRC features
 .. _LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE:
 
 ``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE``
-The driver supports
-:ref:`LIRC_SET_REC_DUTY_CYCLE_RANGE.`
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC_CAN_SET_REC_CARRIER_RANGE:
 
@@ -115,8 +114,7 @@ LIRC features
 .. _LIRC_CAN_SET_REC_FILTER:
 
 ``LIRC_CAN_SET_REC_FILTER``
-The driver supports
-:ref:`LIRC_SET_REC_FILTER.`
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC_CAN_MEASURE_CARRIER:
 
@@ -133,8 +131,7 @@ LIRC features
 .. _LIRC_CAN_NOTIFY_DECODE:
 
 ``LIRC_CAN_NOTIFY_DECODE``
-The driver supports
-:ref:`LIRC_NOTIFY_DECODE.`
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC_CAN_SEND_RAW:
 
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index b35c1953dc60..345e927e9d5d 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -67,26 +67,11 @@ I/O control requests
 Get supported receive modes. Only ``LIRC_MODE_MODE2`` and
 ``LIRC_MODE_LIRCCODE`` are supported by lircd.
 
-.. _LIRC_GET_SEND_CARRIER:
-
-``LIRC_GET_SEND_CARRIER``
-
-Get carrier frequency (in Hz) currently used for transmit.
-
-.. _LIRC_GET_REC_CARRIER:
-
-``LIRC_GET_REC_CARRIER``
-
-Get carrier frequency (in Hz) currently used for IR reception.
-
-.. _LIRC_GET_SEND_DUTY_CYCLE:
-.. _LIRC_GET_REC_DUTY_CYCLE:
 .. _LIRC_SET_SEND_DUTY_CYCLE:
-.. _LIRC_SET_REC_DUTY_CYCLE:
 
-``LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE``
+``LIRC_SET_SEND_DUTY_CYCLE``
 
-Get/set the duty cycle (from 0 to 100) of the carrier signal.
+Set the duty cycle (from 0 to 100) of the carrier signal.
 Currently, no special meaning is defined for 0 or 100, but this
 could be used to switch off carrier generation in the future, so
 these values should be reserved.
@@ -114,20 +99,6 @@ I/O control requests
 both ioctls will return the same value even though the timeout
 cannot be changed.
 
-.. _LIRC_GET_MIN_FILTER_PULSE:
-.. _LIRC_GET_MAX_FILTER_PULSE:
-.. _LIRC_GET_MIN_FILTER_SPACE:
-.. _LIRC_GET_MAX_FILTER_SPACE:
-
-``LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE}``
-
-Some devices are able to filter out spikes in the incoming signal
-using given filter rules. These ioctls return the hardware
-capabilities that describe the bounds of the possible filters.
-Filter settings depend on the IR protocols that are expected. lircd
-derives the settings from all protocols definitions found in its
-config file.
-
 .. _LIRC_GET_LENGTH:
 
 ``LIRC_GET_LENGTH``
@@ -179,16 +150,6 @@ I/O control requests
 Enable (1) or disable (0) timeout reports in ``LIRC_MODE_MODE2.`` By
 default, timeout reports should be turned off.
 
-.. _LIRC_SET_REC_FILTER_PULSE:
-.. _LIRC_SET_REC_FILTER_SPACE:
-.. _LIRC_SET_REC_FILTER:
-
-``LIRC_SET_REC_FILTER_{PULSE,SPACE}``
-
-Pulses/spaces shorter than this are filtered out by hardware. If
-filters cannot be set independently for pulse/space, the
-corresponding ioctls must return an error and ``LIRC_SET_REC_FILTER``
-shall be used instead.
 
 .. _LIRC_SET_MEASURE_CARRIER_MODE:
 .. _lirc-mode2-frequency:
@@ -199,40 +160,17 @@ I/O control requests
 press on, the driver will send ``LIRC_MODE2_FREQUENCY`` packets. By
 default this should be turned off.
 
-.. _LIRC_SET_REC_DUTY_CYCLE_RANGE:
+
 .. _LIRC_SET_REC_CARRIER_RANGE:
 
-``LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE``
+``LIRC_SET_REC_CARRIER_RANGE``
 
 To set a range use
-``LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE``
+``LIRC_SET_REC_CARRIER_RANGE``
 with the lower bound first and later
-``LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER`` with the upper
+``LIRC_SET_REC_CARRIER`` with the upper
 bound.
 
-.. _LIRC_NOTIFY_DECODE:
-
-``LIRC_NOTIFY_DECODE``
-
-This ioctl is called by lircd whenever a successful decoding of an
-incoming IR signal could be done. This can be used by supporting
-hardware to give visual feedback to the user e.g. by flashing a LED.
-
-.. _LIRC_SETUP_START:
-.. _LIRC_SETUP_END:
-
-``LIRC_SETUP_{START,END}``
-
-Setting of several driver parameters can be optimized by
-encapsulating the according ioctl calls with
-``LIRC_SETUP_START/LIRC_SETUP_END.`` When a driver receives a
-``LIRC_SETUP_START`` ioctl it can 

[PATCH 11/20] [media] doc-rst: document LIRC_GET_*_TIMEOUT ioctls

[Mauro Carvalho Chehab]

Improve the documentation for those ioctls, adding them to
a separate file, in order to look like the rest of the
book, and to later allow to generate a man page for those
ioctls.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-timeout.rst   | 55 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst | 13 -
 3 files changed, 56 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-timeout.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-timeout.rst 
b/Documentation/media/uapi/rc/lirc-get-timeout.rst
new file mode 100644
index ..6b8238f1f30e
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-timeout.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_min_timeout:
+.. _lirc_get_max_timeout:
+
+
+ioctls LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT
+
+
+Name
+
+
+LIRC_GET_MIN_TIMEOUT / LIRC_GET_MAX_TIMEOUT - Obtain the possible timeout
+range for IR receive.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *timeout)
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_MIN_TIMEOUT or LIRC_GET_MAX_TIMEOUT
+
+``timeout``
+Timeout, in microseconds.
+
+
+Description
+===
+
+Some devices have internal timers that can be used to detect when
+there's no IR activity for a long time. This can help lircd in
+detecting that a IR signal is finished and can speed up the decoding
+process. Returns an integer value with the minimum/maximum timeout
+that can be set.
+
+.. note::
+
+   Some devices have a fixed timeout, in that case
+   both ioctls will return the same value even though the timeout
+   cannot be changed via :ref:`LIRC_SET_REC_TIMEOUT`.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index 56f2d6122238..197173f9ece5 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -17,4 +17,5 @@ LIRC Device Interface
 lirc-get-rec-mode
 lirc-get-rec-resolution
 lirc-set-send-duty-cycle
+lirc-get-timeout
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index c486703b95b8..0a16659e9dad 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -49,19 +49,6 @@ device can rely on working with the default settings 
initially.
 I/O control requests
 
 
-.. _LIRC_GET_MIN_TIMEOUT:
-.. _LIRC_GET_MAX_TIMEOUT:
-
-``LIRC_GET_M{IN,AX}_TIMEOUT``
-
-Some devices have internal timers that can be used to detect when
-there's no IR activity for a long time. This can help lircd in
-detecting that a IR signal is finished and can speed up the decoding
-process. Returns an integer value with the minimum/maximum timeout
-that can be set. Some devices have a fixed timeout, in that case
-both ioctls will return the same value even though the timeout
-cannot be changed.
-
 .. _LIRC_GET_LENGTH:
 
 ``LIRC_GET_LENGTH``
-- 
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 06/20] [media] doc-rst: document ioctl LIRC_GET_SEND_MODE

[Mauro Carvalho Chehab]

Move the documentation of this ioctl from lirc_ioctl to its
own file, and add a short description about the pulse mode
used by IR TX.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-send-mode.rst | 48 ++
 .../media/uapi/rc/lirc_device_interface.rst|  1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
 3 files changed, 49 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-send-mode.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-send-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
new file mode 100644
index ..f58f0953851c
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
@@ -0,0 +1,48 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_send_mode:
+
+
+ioctl LIRC_GET_SEND_MODE
+
+
+Name
+
+
+LIRC_GET_SEND_MODE - Get supported transmit mode.
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *tx_modes )
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_SEND_MODE
+
+``tx_modes``
+Bitmask with the supported transmit modes.
+
+
+Description
+===
+
+Get supported transmit mode.
+
+.. _lirc-mode-pulse:
+
+Currently, only ``LIRC_MODE_PULSE`` is supported by lircd on TX. On
+puse mode, a sequence of pulse/space integer values are written to the
+lirc device using ``write()``.
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index fe13f7d65d30..f6ebf09cca60 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ b/Documentation/media/uapi/rc/lirc_device_interface.rst
@@ -13,4 +13,5 @@ LIRC Device Interface
 lirc_read
 lirc_write
 lirc-get-features
+lirc-get-send-mode
 lirc_ioctl
diff --git a/Documentation/media/uapi/rc/lirc_ioctl.rst 
b/Documentation/media/uapi/rc/lirc_ioctl.rst
index 345e927e9d5d..8e9809a03b8f 100644
--- a/Documentation/media/uapi/rc/lirc_ioctl.rst
+++ b/Documentation/media/uapi/rc/lirc_ioctl.rst
@@ -49,15 +49,6 @@ device can rely on working with the default settings 
initially.
 I/O control requests
 
 
-
-.. _LIRC_GET_SEND_MODE:
-.. _lirc-mode-pulse:
-
-``LIRC_GET_SEND_MODE``
-
-Get supported transmit mode. Only ``LIRC_MODE_PULSE`` is supported by
-lircd.
-
 .. _LIRC_GET_REC_MODE:
 .. _lirc-mode-mode2:
 .. _lirc-mode-lirccode:
-- 
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 19/20] [media] doc-rst: Document LIRC set mode ioctls

[Mauro Carvalho Chehab]

Add LIRC_SET_[REC|SEND]_MODE ioctls to the corresponding
GET functions, and put all LIRC modes altogether.

As now everything is already documented on its own ioctl
pages, get rid of lirc_ioctl.rst.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  | 32 +++
 Documentation/media/uapi/rc/lirc-get-send-mode.rst | 17 +++---
 Documentation/media/uapi/rc/lirc_dev_intro.rst | 34 
 .../media/uapi/rc/lirc_device_interface.rst|  1 -
 Documentation/media/uapi/rc/lirc_ioctl.rst | 64 --
 5 files changed, 50 insertions(+), 98 deletions(-)
 delete mode 100644 Documentation/media/uapi/rc/lirc_ioctl.rst

diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
index d46a488594c9..586860c36791 100644
--- a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
+++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
@@ -1,15 +1,16 @@
 .. -*- coding: utf-8; mode: rst -*-
 
 .. _lirc_get_rec_mode:
+.. _lirc_set_rec_mode:
 
-***
-ioctl LIRC_GET_REC_MODE
-***
+**
+ioctls LIRC_GET_REC_MODE and LIRC_SET_REC_MODE
+**
 
 Name
 
 
-LIRC_GET_REC_MODE - Get supported receive modes.
+LIRC_GET_REC_MODE/LIRC_GET_REC_MODE - Get/set supported receive modes.
 
 Synopsis
 
@@ -23,7 +24,7 @@ Arguments
 File descriptor returned by open().
 
 ``request``
-LIRC_GET_REC_MODE
+LIRC_GET_REC_MODE or LIRC_GET_REC_MODE
 
 ``rx_modes``
 Bitmask with the supported transmit modes.
@@ -31,24 +32,9 @@ Arguments
 Description
 ===
 
-Get supported receive modes.
-
-Supported receive modes
-===
-
-.. _lirc-mode-mode2:
-
-``LIRC_MODE_MODE2``
-
-The driver returns a sequence of pulse and space codes to userspace.
-
-.. _lirc-mode-lirccode:
-
-``LIRC_MODE_LIRCCODE``
-
-The IR signal is decoded internally by the receiver. The LIRC interface
-returns the scancode as an integer value. This is the usual mode used
-by several TV media cards.
+Get/set supported receive modes. Only :ref:`LIRC_MODE_MODE2 `
+and :ref:`LIRC_MODE_LIRCCODE ` are supported for IR
+receive.
 
 
 Return Value
diff --git a/Documentation/media/uapi/rc/lirc-get-send-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
index f3fd310a8d7c..3e1d96122ff2 100644
--- a/Documentation/media/uapi/rc/lirc-get-send-mode.rst
+++ b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
@@ -1,15 +1,16 @@
 .. -*- coding: utf-8; mode: rst -*-
 
 .. _lirc_get_send_mode:
+.. _lirc_set_send_mode:
 
-
-ioctl LIRC_GET_SEND_MODE
-
+
+ioctls LIRC_GET_SEND_MODE and LIRC_SET_SEND_MODE
+
 
 Name
 
 
-LIRC_GET_SEND_MODE - Get supported transmit mode.
+LIRC_GET_SEND_MODE/LIRC_SET_SEND_MODE - Get/set supported transmit mode.
 
 Synopsis
 
@@ -32,13 +33,9 @@ Arguments
 Description
 ===
 
-Get supported transmit mode.
+Get/set supported transmit mode.
 
-.. _lirc-mode-pulse:
-
-Currently, only ``LIRC_MODE_PULSE`` is supported by lircd on TX. On
-puse mode, a sequence of pulse/space integer values are written to the
-lirc device using :Ref:`lirc-write`.
+Only :ref:`LIRC_MODE_PULSE ` is supported by for IR send.
 
 Return Value
 
diff --git a/Documentation/media/uapi/rc/lirc_dev_intro.rst 
b/Documentation/media/uapi/rc/lirc_dev_intro.rst
index 9a784c8fe4ea..ef97e40f2fd8 100644
--- a/Documentation/media/uapi/rc/lirc_dev_intro.rst
+++ b/Documentation/media/uapi/rc/lirc_dev_intro.rst
@@ -26,3 +26,37 @@ What you should see for a chardev:
 
 $ ls -l /dev/lirc*
 crw-rw 1 root root 248, 0 Jul 2 22:20 /dev/lirc0
+
+**
+LIRC modes
+**
+
+LIRC supports some modes of receiving and sending IR codes, as shown
+on the following table.
+
+.. _lirc-mode-mode2:
+
+``LIRC_MODE_MODE2``
+
+The driver returns a sequence of pulse and space codes to userspace.
+
+This mode is used only for IR receive.
+
+.. _lirc-mode-lirccode:
+
+``LIRC_MODE_LIRCCODE``
+
+The IR signal is decoded internally by the receiver. The LIRC interface
+returns the scancode as an integer value. This is the usual mode used
+by several TV media cards.
+
+This mode is used only for IR receive.
+
+.. _lirc-mode-pulse:
+
+``LIRC_MODE_PULSE``
+
+On puse mode, a sequence of pulse/space integer values are written to the
+lirc device using :Ref:`lirc-write`.
+
+This mode is used only for IR send.
diff --git a/Documentation/media/uapi/rc/lirc_device_interface.rst 
b/Documentation/media/uapi/rc/lirc_device_interface.rst
index e9cb510349a0..a2ad957c96ae 100644
--- a/Documentation/media/uapi/rc/lirc_device_interface.rst
+++ 

[PATCH 00/20] Improve LIRC documentation

[Mauro Carvalho Chehab]

The LIRC documentation doesn't follow the remaining of the media book.

There's just a single page with all ioctls inside, and, IMHO, not very clear.
Also, the LIRC_CAN flags were not described.

This patchset address these. Also, it removes some LIRC ioctls that aren't
used.

Mauro Carvalho Chehab (20):
  [media] doc-rst: Document ioctl LIRC_GET_FEATURES
  [media] doc-rst: add media/uapi/rc/lirc-header.rst
  [media] lirc.h: remove several unused ioctls
  [media] doc-rst: remove not used ioctls from documentation
  [media] doc-rst: Fix LIRC_GET_FEATURES references
  [media] doc-rst: document ioctl LIRC_GET_SEND_MODE
  [media] doc-rst: fix some lirc cross-references
  [media] doc-rst: document ioctl LIRC_GET_REC_MODE
  [media] doc-rst: document LIRC_GET_REC_RESOLUTION
  [media] doc-rst: document LIRC_SET_SEND_DUTY_CYCLE
  [media] doc-rst: document LIRC_GET_*_TIMEOUT ioctls
  [media] doc-rst: Document LIRC_GET_LENGTH ioctl
  [media] doc-rst: document LIRC set carrier ioctls
  [media] doc-rst: document LIRC_SET_TRANSMITTER_MASK
  [media] doc-rst: document LIRC_SET_REC_TIMEOUT
  [media] doc-rst: document LIRC_SET_REC_TIMEOUT_REPORTS
  [media] doc-rst: add documentation for LIRC_SET_MEASURE_CARRIER_MODE
  [media] doc-rst: document LIRC_SET_WIDEBAND_RECEIVER
  [media] doc-rst: Document LIRC set mode ioctls
  [media] doc-rst: reorganize LIRC ReST files

 Documentation/media/lirc.h.rst.exceptions  |  39 +--
 .../rc/{lirc_dev_intro.rst => lirc-dev-intro.rst}  |  34 +++
 .../rc/{lirc_device_interface.rst => lirc-dev.rst} |   7 +-
 Documentation/media/uapi/rc/lirc-func.rst  |  28 +++
 Documentation/media/uapi/rc/lirc-get-features.rst  | 181 ++
 Documentation/media/uapi/rc/lirc-get-length.rst|  45 
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  45 
 .../media/uapi/rc/lirc-get-rec-resolution.rst  |  49 
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |  45 
 Documentation/media/uapi/rc/lirc-get-timeout.rst   |  55 +
 Documentation/media/uapi/rc/lirc-header.rst|  10 +
 .../media/uapi/rc/{lirc_read.rst => lirc-read.rst} |  10 +-
 .../uapi/rc/lirc-set-measure-carrier-mode.rst  |  48 
 .../media/uapi/rc/lirc-set-rec-carrier-range.rst   |  49 
 .../media/uapi/rc/lirc-set-rec-carrier.rst |  48 
 .../media/uapi/rc/lirc-set-rec-timeout-reports.rst |  49 
 .../media/uapi/rc/lirc-set-rec-timeout.rst |  52 
 .../media/uapi/rc/lirc-set-send-carrier.rst|  43 
 .../media/uapi/rc/lirc-set-send-duty-cycle.rst |  49 
 .../media/uapi/rc/lirc-set-transmitter-mask.rst|  53 
 .../media/uapi/rc/lirc-set-wideband-receiver.rst   |  56 +
 .../uapi/rc/{lirc_write.rst => lirc-write.rst} |   4 +-
 Documentation/media/uapi/rc/lirc_ioctl.rst | 270 -
 Documentation/media/uapi/rc/remote_controllers.rst |   3 +-
 include/uapi/linux/lirc.h  |  39 +--
 25 files changed, 956 insertions(+), 355 deletions(-)
 rename Documentation/media/uapi/rc/{lirc_dev_intro.rst => lirc-dev-intro.rst} 
(52%)
 rename Documentation/media/uapi/rc/{lirc_device_interface.rst => lirc-dev.rst} 
(67%)
 create mode 100644 Documentation/media/uapi/rc/lirc-func.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-features.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-length.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-mode.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-resolution.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-send-mode.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-get-timeout.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-header.rst
 rename Documentation/media/uapi/rc/{lirc_read.rst => lirc-read.rst} (83%)
 create mode 100644 
Documentation/media/uapi/rc/lirc-set-measure-carrier-mode.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-carrier-range.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-carrier.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-timeout-reports.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-send-carrier.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-send-duty-cycle.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-transmitter-mask.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-wideband-receiver.rst
 rename Documentation/media/uapi/rc/{lirc_write.rst => lirc-write.rst} (94%)
 delete mode 100644 Documentation/media/uapi/rc/lirc_ioctl.rst

-- 
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 02/20] [media] doc-rst: add media/uapi/rc/lirc-header.rst

[Mauro Carvalho Chehab]

changeset 68cd5e0bed99 ("[media] doc-rst: add LIRC header to the book")
did everything but adding the lirc-reader.rst :-p

My fault: I forgot to do a git add for this guy on such
changeset.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-header.rst | 10 ++
 1 file changed, 10 insertions(+)
 create mode 100644 Documentation/media/uapi/rc/lirc-header.rst

diff --git a/Documentation/media/uapi/rc/lirc-header.rst 
b/Documentation/media/uapi/rc/lirc-header.rst
new file mode 100644
index ..487fe00e5517
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-header.rst
@@ -0,0 +1,10 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_header:
+
+
+LIRC Header File
+
+
+.. kernel-include:: $BUILDDIR/lirc.h.rst
+
-- 
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 01/20] [media] doc-rst: Document ioctl LIRC_GET_FEATURES

[Mauro Carvalho Chehab]

The documentation for this ioctl was really crappy.

Add a better documentation, using the lirc.4 man pages as a
reference, plus what was written originally at the lirc-ioctl.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/lirc.h.rst.exceptions  |  35 -
 Documentation/media/uapi/rc/lirc-get-features.rst  | 168 +
 .../media/uapi/rc/lirc_device_interface.rst|   1 +
 Documentation/media/uapi/rc/lirc_ioctl.rst |   8 -
 4 files changed, 169 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-get-features.rst

diff --git a/Documentation/media/lirc.h.rst.exceptions 
b/Documentation/media/lirc.h.rst.exceptions
index 58439ef3b9d7..17f6e7e9550d 100644
--- a/Documentation/media/lirc.h.rst.exceptions
+++ b/Documentation/media/lirc.h.rst.exceptions
@@ -37,38 +37,3 @@ ignore define LIRC_VALUE_MASK
 ignore define LIRC_MODE2_MASK
 
 ignore define LIRC_MODE_RAW
-
-ignore define LIRC_CAN_SEND_RAW
-ignore define LIRC_CAN_SEND_PULSE
-ignore define LIRC_CAN_SEND_MODE2
-ignore define LIRC_CAN_SEND_LIRCCODE
-
-ignore define LIRC_CAN_SEND_MASK
-
-ignore define LIRC_CAN_SET_SEND_CARRIER
-ignore define LIRC_CAN_SET_SEND_DUTY_CYCLE
-ignore define LIRC_CAN_SET_TRANSMITTER_MASK
-
-ignore define LIRC_CAN_REC_RAW
-ignore define LIRC_CAN_REC_PULSE
-ignore define LIRC_CAN_REC_MODE2
-ignore define LIRC_CAN_REC_LIRCCODE
-
-ignore define LIRC_CAN_REC_MASK
-
-ignore define LIRC_CAN_SET_REC_CARRIER
-ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
-
-ignore define LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE
-ignore define LIRC_CAN_SET_REC_CARRIER_RANGE
-ignore define LIRC_CAN_GET_REC_RESOLUTION
-ignore define LIRC_CAN_SET_REC_TIMEOUT
-ignore define LIRC_CAN_SET_REC_FILTER
-
-ignore define LIRC_CAN_MEASURE_CARRIER
-ignore define LIRC_CAN_USE_WIDEBAND_RECEIVER
-
-ignore define LIRC_CAN_SEND(x)
-ignore define LIRC_CAN_REC(x)
-
-ignore define LIRC_CAN_NOTIFY_DECODE
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
new file mode 100644
index ..6850f804a96c
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -0,0 +1,168 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_get_features:
+
+***
+ioctl LIRC_GET_FEATURES
+***
+
+Name
+
+
+LIRC_GET_FEATURES - Get the underlying hardware device's features
+
+Synopsis
+
+
+.. cpp:function:: int ioctl( int fd, int request, __u32 *features)
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``request``
+LIRC_GET_FEATURES
+
+``features``
+Bitmask with the LIRC features.
+
+
+Description
+===
+
+
+Get the underlying hardware device's features. If a driver does not
+announce support of certain features, calling of the corresponding ioctls
+is undefined.
+
+LIRC features
+=
+
+.. _LIRC_CAN_REC_RAW:
+
+``LIRC_CAN_REC_RAW``
+The driver is capable of receiving using
+:ref:`LIRC_MODE_RAW.`
+
+.. _LIRC_CAN_REC_PULSE:
+
+``LIRC_CAN_REC_PULSE``
+The driver is capable of receiving using
+:ref:`LIRC_MODE_PULSE.`
+
+.. _LIRC_CAN_REC_MODE2:
+
+``LIRC_CAN_REC_MODE2``
+The driver is capable of receiving using
+:ref:`LIRC_MODE_MODE2.`
+
+.. _LIRC_CAN_REC_LIRCCODE:
+
+``LIRC_CAN_REC_LIRCCODE``
+The driver is capable of receiving using
+:ref:`LIRC_MODE_LIRCCODE.`
+
+.. _LIRC_CAN_SET_SEND_CARRIER:
+
+``LIRC_CAN_SET_SEND_CARRIER``
+The driver supports changing the modulation frequency via
+:ref:`LIRC_SET_SEND_CARRIER.`
+
+.. _LIRC_CAN_SET_SEND_DUTY_CYCLE:
+
+``LIRC_CAN_SET_SEND_DUTY_CYCLE``
+The driver supports changing the duty cycle using
+:ref:`LIRC_SET_SEND_DUTY_CYCLE`.
+
+.. _LIRC_CAN_SET_TRANSMITTER_MASK:
+
+``LIRC_CAN_SET_TRANSMITTER_MASK``
+The driver supports changing the active transmitter(s) using
+:ref:`LIRC_SET_TRANSMITTER_MASK.`
+
+.. _LIRC_CAN_SET_REC_CARRIER:
+
+``LIRC_CAN_SET_REC_CARRIER``
+The driver supports setting the receive carrier frequency using
+:ref:`LIRC_SET_REC_CARRIER.`
+
+.. _LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE:
+
+``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE``
+The driver supports
+:ref:`LIRC_SET_REC_DUTY_CYCLE_RANGE.`
+
+.. _LIRC_CAN_SET_REC_CARRIER_RANGE:
+
+``LIRC_CAN_SET_REC_CARRIER_RANGE``
+The driver supports
+:ref:`LIRC_SET_REC_CARRIER_RANGE.`
+
+.. _LIRC_CAN_GET_REC_RESOLUTION:
+
+``LIRC_CAN_GET_REC_RESOLUTION``
+The driver supports
+:ref:`LIRC_GET_REC_RESOLUTION.`
+
+.. _LIRC_CAN_SET_REC_TIMEOUT:
+
+``LIRC_CAN_SET_REC_TIMEOUT``
+The driver supports
+:ref:`LIRC_SET_REC_TIMEOUT.`
+
+.. _LIRC_CAN_SET_REC_FILTER:
+
+``LIRC_CAN_SET_REC_FILTER``
+The driver supports
+:ref:`LIRC_SET_REC_FILTER.`
+
+.. _LIRC_CAN_MEASURE_CARRIER:
+
+``LIRC_CAN_MEASURE_CARRIER``
+The driver supports measuring of the modulation frequency using
+:ref:`LIRC_SET_MEASURE_CARRIER_MODE`.
+
+.. 

[PATCH 07/20] [media] doc-rst: fix some lirc cross-references

[Mauro Carvalho Chehab]

Some references were broken. It was also mentioning LIRC_MODE_RAW,
with it is not implemented on current LIRC drivers.

So, fix the references.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-get-features.rst  | 5 ++---
 Documentation/media/uapi/rc/lirc-get-send-mode.rst | 2 +-
 Documentation/media/uapi/rc/lirc_read.rst  | 2 +-
 Documentation/media/uapi/rc/lirc_write.rst | 4 ++--
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index d89712190d43..e763ebfb2cb1 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -44,8 +44,7 @@ LIRC features
 
 ``LIRC_CAN_REC_RAW``
 
-The driver is capable of receiving using
-:ref:`LIRC_MODE_RAW `.
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC-CAN-REC-PULSE:
 
@@ -153,7 +152,7 @@ LIRC features
 
 ``LIRC_CAN_SEND_RAW``
 
-The driver supports sending using :ref:`LIRC_MODE_RAW `.
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC-CAN-SEND-PULSE:
 
diff --git a/Documentation/media/uapi/rc/lirc-get-send-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
index f58f0953851c..f3fd310a8d7c 100644
--- a/Documentation/media/uapi/rc/lirc-get-send-mode.rst
+++ b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
@@ -38,7 +38,7 @@ Get supported transmit mode.
 
 Currently, only ``LIRC_MODE_PULSE`` is supported by lircd on TX. On
 puse mode, a sequence of pulse/space integer values are written to the
-lirc device using ``write()``.
+lirc device using :Ref:`lirc-write`.
 
 Return Value
 
diff --git a/Documentation/media/uapi/rc/lirc_read.rst 
b/Documentation/media/uapi/rc/lirc_read.rst
index 37f164f7526a..a8f1b446c294 100644
--- a/Documentation/media/uapi/rc/lirc_read.rst
+++ b/Documentation/media/uapi/rc/lirc_read.rst
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _lirc_read:
+.. _lirc-read:
 
 ***
 LIRC read()
diff --git a/Documentation/media/uapi/rc/lirc_write.rst 
b/Documentation/media/uapi/rc/lirc_write.rst
index e27bda30afcc..dcba3b1bee6e 100644
--- a/Documentation/media/uapi/rc/lirc_write.rst
+++ b/Documentation/media/uapi/rc/lirc_write.rst
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _lirc_write:
+.. _lirc-write:
 
 
 LIRC write()
@@ -36,7 +36,7 @@ Arguments
 Description
 ===
 
-:ref:`write() ` writes up to ``count`` bytes to the device
+:ref:`write() ` writes up to ``count`` bytes to the device
 referenced by the file descriptor ``fd`` from the buffer starting at
 ``buf``.
 
-- 
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 -next] [media] rcar_jpu: Add missing clk_disable_unprepare() on error in jpu_open()

[Mikhail Ulyanov]

On Tue, Jul 12, 2016 at 2:21 PM,   wrote:
> From: Wei Yongjun 
>
> Add the missing clk_disable_unprepare() before return from
> jpu_open() in the software reset error handling case.
>
> Signed-off-by: Wei Yongjun 

Hello, Wei Yongjun.
Thanks for the patch!

Acked-by: Mikhail Ulyanov 


-- 
W.B.R, Mikhail.
--
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 00/44] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On 07/12/2016 02:16 PM, Daniel Vetter wrote:
> On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote:
>> Hi,
>>
>>
>> This is fifth approach for replacing struct dma_attrs with unsigned
>> long.
>>
>> The main patch (1/44) doing the change is split into many subpatches
>> for easier review (2-42).  They should be squashed together when
>> applying.
> 
> For all the drm driver patches:
> 
> Acked-by: Daniel Vetter 
> 
> Should I pull these in through drm-misc, or do you prefer to merge them
> through a special topic branch (with everything else) instead on your own?
> -Daniel

Thanks. I saw today that Andrew Morton applied the patchset so I think
he will handle it.

Best regards,
Krzysztof

--
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 00/44] dma-mapping: Use unsigned long for dma_attrs

[Daniel Vetter]

On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> This is fifth approach for replacing struct dma_attrs with unsigned
> long.
> 
> The main patch (1/44) doing the change is split into many subpatches
> for easier review (2-42).  They should be squashed together when
> applying.

For all the drm driver patches:

Acked-by: Daniel Vetter 

Should I pull these in through drm-misc, or do you prefer to merge them
through a special topic branch (with everything else) instead on your own?
-Daniel

> 
> 
> Rebased on v4.7-rc5.
> 
> For easier testing the patchset is available here:
> repo:   https://github.com/krzk/linux
> branch: for-next/dma-attrs-const-v5
> 
> 
> Changes since v4
> 
> 1. Collect some acks. Still need more.
> 2. Minor fixes pointed by Robin Murphy.
> 3. Applied changes from Bart Van Assche's comment.
> 4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).
> 
> 
> Changes since v3
> 
> 1. Collect some acks.
> 2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
>the value of DMA_ATTR_WEAK_ORDERING").
> 3. Minor fix pointed out by Michael Ellerman.
> 
> 
> Changes since v2
> 
> 1. Follow Christoph Hellwig's comments (don't use BIT add
>documentation, remove dma_get_attr).
> 
> 
> Rationale
> =
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer.  Thus the pointer can point to const
> data.  However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
> 
> 1. This is just simpler.  Both in terms of reading the code and setting
>attributes.  Instead of initializing local attributes on the stack
>and passing pointer to it to dma_set_attr(), just set the bits.
> 
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.
> 
> 
> Best regards,
> Krzysztof
> 
> 
> Krzysztof Kozlowski (44):
>   dma-mapping: Use unsigned long for dma_attrs
>   alpha: dma-mapping: Use unsigned long for dma_attrs
>   arc: dma-mapping: Use unsigned long for dma_attrs
>   ARM: dma-mapping: Use unsigned long for dma_attrs
>   arm64: dma-mapping: Use unsigned long for dma_attrs
>   avr32: dma-mapping: Use unsigned long for dma_attrs
>   blackfin: dma-mapping: Use unsigned long for dma_attrs
>   c6x: dma-mapping: Use unsigned long for dma_attrs
>   cris: dma-mapping: Use unsigned long for dma_attrs
>   frv: dma-mapping: Use unsigned long for dma_attrs
>   drm/exynos: dma-mapping: Use unsigned long for dma_attrs
>   drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
>   drm/msm: dma-mapping: Use unsigned long for dma_attrs
>   drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
>   drm/rockship: dma-mapping: Use unsigned long for dma_attrs
>   infiniband: dma-mapping: Use unsigned long for dma_attrs
>   iommu: dma-mapping: Use unsigned long for dma_attrs
>   [media] dma-mapping: Use unsigned long for dma_attrs
>   xen: dma-mapping: Use unsigned long for dma_attrs
>   swiotlb: dma-mapping: Use unsigned long for dma_attrs
>   powerpc: dma-mapping: Use unsigned long for dma_attrs
>   video: dma-mapping: Use unsigned long for dma_attrs
>   x86: dma-mapping: Use unsigned long for dma_attrs
>   iommu: intel: dma-mapping: Use unsigned long for dma_attrs
>   h8300: dma-mapping: Use unsigned long for dma_attrs
>   hexagon: dma-mapping: Use unsigned long for dma_attrs
>   ia64: dma-mapping: Use unsigned long for dma_attrs
>   m68k: dma-mapping: Use unsigned long for dma_attrs
>   metag: dma-mapping: Use unsigned long for dma_attrs
>   microblaze: dma-mapping: Use unsigned long for dma_attrs
>   mips: dma-mapping: Use unsigned long for dma_attrs
>   mn10300: dma-mapping: Use unsigned long for dma_attrs
>   nios2: dma-mapping: Use unsigned long for dma_attrs
>   openrisc: dma-mapping: Use unsigned long for dma_attrs
>   parisc: dma-mapping: Use unsigned long for dma_attrs
>   misc: mic: dma-mapping: Use unsigned long for dma_attrs
>   s390: dma-mapping: Use unsigned long for dma_attrs
>   sh: dma-mapping: Use unsigned long for dma_attrs
>   sparc: dma-mapping: Use unsigned long for dma_attrs
>   tile: dma-mapping: Use unsigned long for dma_attrs
>   unicore32: dma-mapping: Use unsigned long for dma_attrs
>   xtensa: dma-mapping: Use unsigned long for dma_attrs
>   dma-mapping: Remove dma_get_attr
>   dma-mapping: Document the DMA attributes next to the declaration
> 
>  Documentation/DMA-API.txt  |  33 +++---
>  Documentation/DMA-attributes.txt   |   2 +-
>  arch/alpha/include/asm/dma-mapping.h   |   2 -
>  arch/alpha/kernel/pci-noop.c   |   2 +-
>  arch/alpha/kernel/pci_iommu.c  |  12 +-
>  arch/arc/mm/dma.c  |  12 +-
>  arch/arm/common/dmabounce.c|   4 +-
>  arch/arm/include/asm/dma-mapping.h   

[PATCH -next] [media] mtk-vcodec: remove .owner field for driver

[weiyj_lk]

From: Wei Yongjun 

Remove .owner field if calls are used which set it automatically.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 9c10cc2..60b0bde 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -430,7 +430,6 @@ static struct platform_driver mtk_vcodec_enc_driver = {
.remove = mtk_vcodec_enc_remove,
.driver = {
.name   = MTK_VCODEC_ENC_NAME,
-   .owner  = THIS_MODULE,
.of_match_table = mtk_vcodec_enc_match,
},
 };


--
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 -next] [media] s5p-mfc: remove redundant return value check of platform_get_resource()

[weiyj_lk]

From: Wei Yongjun 

Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e3f104f..83a47d6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1158,10 +1158,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
dev->variant = mfc_get_drv_data(pdev);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (res == NULL) {
-   dev_err(>dev, "failed to get io resource\n");
-   return -ENOENT;
-   }
dev->regs_base = devm_ioremap_resource(>dev, res);
if (IS_ERR(dev->regs_base))
return PTR_ERR(dev->regs_base);


--
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 -next] [media] mtk-vcodec: remove redundant dev_err call in mtk_vcodec_probe()

[tiffany lin]

Reviewed-by: Tiffany Lin 

On Tue, 2016-07-12 at 11:02 +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> index 9c10cc2..b33a931 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> @@ -279,8 +279,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
>   }
>   dev->reg_base[i] = devm_ioremap_resource(>dev, res);
>   if (IS_ERR((__force void *)dev->reg_base[i])) {
> - dev_err(>dev,
> - "devm_ioremap_resource %d failed.", i);
>   ret = PTR_ERR((__force void *)dev->reg_base[i]);
>   goto err_res;
>   }
> 
> 


--
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 -next] [media] rcar_jpu: Add missing clk_disable_unprepare() on error in jpu_open()

[weiyj_lk]

From: Wei Yongjun 

Add the missing clk_disable_unprepare() before return from
jpu_open() in the software reset error handling case.

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/rcar_jpu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar_jpu.c 
b/drivers/media/platform/rcar_jpu.c
index 16782ce..8e6c617 100644
--- a/drivers/media/platform/rcar_jpu.c
+++ b/drivers/media/platform/rcar_jpu.c
@@ -1280,7 +1280,7 @@ static int jpu_open(struct file *file)
/* ...issue software reset */
ret = jpu_reset(jpu);
if (ret)
-   goto device_prepare_rollback;
+   goto jpu_reset_rollback;
}
 
jpu->ref_count++;
@@ -1288,6 +1288,8 @@ static int jpu_open(struct file *file)
mutex_unlock(>mutex);
return 0;
 
+jpu_reset_rollback:
+   clk_disable_unprepare(jpu->clk);
 device_prepare_rollback:
mutex_unlock(>mutex);
 v4l_prepare_rollback:


--
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 -next] [media] vcodec: mediatek: Fix return value check in mtk_vcodec_init_enc_pm()

[tiffany lin]

Reviewed-by:Tiffany Lin 

On Tue, 2016-07-12 at 11:02 +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> In case of error, the function devm_clk_get() returns ERR_PTR()
> and not returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> index 2379e97..3e73e9d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> @@ -67,27 +67,27 @@ int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
>   pm->dev = >dev;
>  
>   pm->vencpll_d2 = devm_clk_get(>dev, "venc_sel_src");
> - if (pm->vencpll_d2 == NULL) {
> + if (IS_ERR(pm->vencpll_d2)) {
>   mtk_v4l2_err("devm_clk_get vencpll_d2 fail");
> - ret = -1;
> + ret = PTR_ERR(pm->vencpll_d2);
>   }
>  
>   pm->venc_sel = devm_clk_get(>dev, "venc_sel");
> - if (pm->venc_sel == NULL) {
> + if (IS_ERR(pm->venc_sel)) {
>   mtk_v4l2_err("devm_clk_get venc_sel fail");
> - ret = -1;
> + ret = PTR_ERR(pm->venc_sel);
>   }
>  
>   pm->univpll1_d2 = devm_clk_get(>dev, "venc_lt_sel_src");
> - if (pm->univpll1_d2 == NULL) {
> + if (IS_ERR(pm->univpll1_d2)) {
>   mtk_v4l2_err("devm_clk_get univpll1_d2 fail");
> - ret = -1;
> + ret = PTR_ERR(pm->univpll1_d2);
>   }
>  
>   pm->venc_lt_sel = devm_clk_get(>dev, "venc_lt_sel");
> - if (pm->venc_lt_sel == NULL) {
> + if (IS_ERR(pm->venc_lt_sel)) {
>   mtk_v4l2_err("devm_clk_get venc_lt_sel fail");
> - ret = -1;
> + ret = PTR_ERR(pm->venc_lt_sel);
>   }
>  
>   return ret;
> 
> 


--
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 -next] [media] vcodec: mediatek: Fix return value check in mtk_vcodec_init_enc_pm()

[weiyj_lk]

From: Wei Yongjun 

In case of error, the function devm_clk_get() returns ERR_PTR()
and not returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
index 2379e97..3e73e9d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
@@ -67,27 +67,27 @@ int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
pm->dev = >dev;
 
pm->vencpll_d2 = devm_clk_get(>dev, "venc_sel_src");
-   if (pm->vencpll_d2 == NULL) {
+   if (IS_ERR(pm->vencpll_d2)) {
mtk_v4l2_err("devm_clk_get vencpll_d2 fail");
-   ret = -1;
+   ret = PTR_ERR(pm->vencpll_d2);
}
 
pm->venc_sel = devm_clk_get(>dev, "venc_sel");
-   if (pm->venc_sel == NULL) {
+   if (IS_ERR(pm->venc_sel)) {
mtk_v4l2_err("devm_clk_get venc_sel fail");
-   ret = -1;
+   ret = PTR_ERR(pm->venc_sel);
}
 
pm->univpll1_d2 = devm_clk_get(>dev, "venc_lt_sel_src");
-   if (pm->univpll1_d2 == NULL) {
+   if (IS_ERR(pm->univpll1_d2)) {
mtk_v4l2_err("devm_clk_get univpll1_d2 fail");
-   ret = -1;
+   ret = PTR_ERR(pm->univpll1_d2);
}
 
pm->venc_lt_sel = devm_clk_get(>dev, "venc_lt_sel");
-   if (pm->venc_lt_sel == NULL) {
+   if (IS_ERR(pm->venc_lt_sel)) {
mtk_v4l2_err("devm_clk_get venc_lt_sel fail");
-   ret = -1;
+   ret = PTR_ERR(pm->venc_lt_sel);
}
 
return ret;


--
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 -next] [media] mtk-vcodec: remove redundant dev_err call in mtk_vcodec_probe()

[weiyj_lk]

From: Wei Yongjun 

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 9c10cc2..b33a931 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -279,8 +279,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
dev->reg_base[i] = devm_ioremap_resource(>dev, res);
if (IS_ERR((__force void *)dev->reg_base[i])) {
-   dev_err(>dev,
-   "devm_ioremap_resource %d failed.", i);
ret = PTR_ERR((__force void *)dev->reg_base[i]);
goto err_res;
}


--
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 -next] [media] VPU: mediatek: fix return value check in mtk_vpu_probe()

[weiyj_lk]

From: Wei Yongjun 

In case of error, the function devm_clk_get() returns ERR_PTR()
and not returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/mtk-vpu/mtk_vpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index b60d02c..c8b2c72 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -788,9 +788,9 @@ static int mtk_vpu_probe(struct platform_device *pdev)
 
/* Get VPU clock */
vpu->clk = devm_clk_get(dev, "main");
-   if (!vpu->clk) {
+   if (IS_ERR(vpu->clk)) {
dev_err(dev, "get vpu clock failed\n");
-   return -EINVAL;
+   return PTR_ERR(vpu->clk);
}
 
platform_set_drvdata(pdev, vpu);


--
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 -next] [media] VPU: mediatek: remove redundant dev_err call in mtk_vpu_probe()

[weiyj_lk]

From: Wei Yongjun 

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/mtk-vpu/mtk_vpu.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index b60d02c..532d2a4 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -774,17 +774,13 @@ static int mtk_vpu_probe(struct platform_device *pdev)
vpu->dev = >dev;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcm");
vpu->reg.tcm = devm_ioremap_resource(dev, res);
-   if (IS_ERR((__force void *)vpu->reg.tcm)) {
-   dev_err(dev, "devm_ioremap_resource vpu tcm failed.\n");
+   if (IS_ERR((__force void *)vpu->reg.tcm))
return PTR_ERR((__force void *)vpu->reg.tcm);
-   }
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_reg");
vpu->reg.cfg = devm_ioremap_resource(dev, res);
-   if (IS_ERR((__force void *)vpu->reg.cfg)) {
-   dev_err(dev, "devm_ioremap_resource vpu cfg failed.\n");
+   if (IS_ERR((__force void *)vpu->reg.cfg))
return PTR_ERR((__force void *)vpu->reg.cfg);
-   }
 
/* Get VPU clock */
vpu->clk = devm_clk_get(dev, "main");


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

[Ian Arkver]

This conversation has drifted off topic, sorry.
It now relates to code in drivers/gpu/ipu-v3/ipu-csi.c, so adding 
Philipp Zabel.


On 11/07/16 23:03, Steve Longerbeam wrote:

On 07/11/2016 12:06 AM, Ian Arkver wrote:

On 10/07/16 23:34, Steve Longerbeam wrote:


On 07/10/2016 07:30 AM, Hans Verkuil wrote:

On 07/10/2016 04:17 PM, Ian Arkver wrote:

On 10/07/16 13:55, Hans Verkuil wrote:

On 07/10/2016 02:10 PM, Lars-Peter Clausen wrote:

On 07/09/2016 11:36 PM, Steve Longerbeam wrote:

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? */

Please don't use the '-4': BT.656 is sufficient. The -4 is just the version
number of the standard (and 5 is the latest anyway).

   From the ADV7180 DS [1]:

BT.656-4, ITU-R BT.656-4 Enable, Address 0x04[7]

Between Revision 3 and Revision 4 of the ITU-R BT.656 standards, the ITU
has changed the toggling position for the V bit within the SAV EAV codes
for NTSC. The ITU-R BT.656-4 standard bit allows the user to select an
output mode that is compliant with either the previous or new standard.
For further information, visit the International Telecommunication Union
website.

Note that the standard change only affects NTSC and has no bearing on PAL.

When ITU-R BT.656-4 is 0 (default), the ITU-R BT.656-3 specification is
used. The V bit goes low at EAV of Line 10 and Line 273.

When ITU-R BT.656-4 is 1, the ITU-R BT.656-4 specification is used. The
V bit goes low at EAV of Line 20 and Line 283.

[1]www.analog.com/media/en/technical-documentation/data-sheets/*ADV7180*.pdf

Rev 4 came in in 1998. I would say that that is the default. We have had any
problems with this and I would need some proof that this is really needed.

Hi Hans, yeah I agree with you that new capture drivers should not
expect BT.656-3 compatible buss' any longer. The problem with i.MX6
however, is that the IPU CSI CCIR_CODE registers, which inform the IPU
about the AV code positions, are very poorly documented. In order for
i.MX6 to support BT.656-4 it would require very time-consuming reverse
engineering to find the right values to plug into those registers to conform
to the BT.656-4 AV code positions.

Steve


Hi Steve,

Once you dsicover that the 3-bit fields in each CCIR_CODE register correspond to 
the H, V and F flags in the SAV/EAV code (in that order, MSbit->LSbit),  those 
registers make more sense. Pity that's
not mentioned in the Ref Manual.

Hi Ian, that's a plausible theory, but it doesn't work. I looked at the value
programmed to CCIR_CODE_1 register (according to imx6 ref manual is
values for first field), for NTSC : 0xD07DF.  Comparing with the definition of
the H/V/F bits in the AV codes in the bt.656 spec:

F = 1 during field 2, 0 during field 1
V = 1 during field blanking, 0 elsewhere
H = 1 in EAV, 0 in SAV

There's no correspondence, for example F bit should be zero everywhere in
CCIR_CODE_1. And wutz this "first/second blanking line command" stuff about?
None of it makes any sense to me.

Hi,

d07df = 001 101  011 111 011 111

  H V F
CSI0_STRT_FLD0_ACTV   0 0 1
CSI0_END_FLD0_ACTV1 0 1
CSI0_STRT_FLD0_BLNK_2ND   0 1 1
CSI0_END_FLD0_BLNK_2ND1 1 1
CSI0_STRT_FLD0_BLNK_1ST   0 1 1
CSI0_END_FLD0_BLNK_1ST1 1 1

40596 = 000 100  010 110 010 110
405A6 = 000 100  010 110 100 110

  H V F
CSI0_STRT_FLD1_ACTV   0 0 0
CSI0_END_FLD1_ACTV1 0 0
CSI0_STRT_FLD1_BLNK_2ND   0 1 0
CSI0_END_FLD1_BLNK_2ND1 1 0
CSI0_STRT_FLD1_BLNK_1ST   0 1 0or 1 0 0 ?
CSI0_END_FLD1_BLNK_1ST1 1 0

For PAL:  IPU_CSI0_CCIR_CODE_1 = 0x40596, IPU_CSI0_CCIR_CODE_1 = 0xd07df
For NTSC: IPU_CSI0_CCIR_CODE_1 = 0xd07df, IPU_CSI0_CCIR_CODE_1 = 0x405A6

So, for the PAL case the field values make sense to me. The F bit is 
constant throughout each field.
I'm not sure why the NTSC case has 405A6 instead of 40596 again. This 
looks like a bug to me.
If you look back at the original Freescale capture driver[1], they use 
40596 for both PAL and NTSC.


The values are swapped between NTSC and PAL to account for the differing 
field order. I think using
the capture width and height to do this is poor as any "bt.656-like" 
source with non standard
dimensions will end up in the dev_err("Unsupported") case. Also, looking 
at BT.1120-8, for interlaced
video the same SAV and EAV codes as PAL are used, so 
IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR and

IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR modes are currently broken.

I think the 1st and 2nd blanking values might be needed for some odd non 
656 streams maybe? Also for

progressive (originally) the value 40030 is used which is

40030 = 000 100  

Re: [PATCHv2 3/5] pulse8-cec: new driver for the Pulse-Eight USB-CEC Adapter

[Hans Verkuil]

On 07/11/16 12:17, Lars Op den Kamp wrote:
> Hi Hans,
> 
> On 11-07-16 12:02, Hans Verkuil wrote:
>> Hi Lars,
>>
>> On 07/11/2016 11:41 AM, Lars Op den Kamp wrote:
>>> Hi Hans,
>>>
>>> just did a quick scan of this patch.
>>>
>>> The code should work on any firmware >= v2 revision 8, though older
>>> versions may return 0 when the build date is requested. I believe I
>>> added that in v3. Might want to add a !=0 check before writing to the log.
>>>
>>> The CEC adapter has an "autonomous mode", used when it's not being
>>> controlled by our userspace application or this kernel driver. It'll
>>> respond to some basic CEC commands that allow the PC to be woken up by TV.
>>> If the adapter doesn't receive a MSGCODE_PING for 30 seconds when it's
>>> in "controlled mode", then it'll revert to autonomous mode and it'll
>>> reset all states internally.
>> Ah, that was rather obscure. Good to know.
>>
>> What I do now (and that seems to work) is that in the pulse8_setup I turn
>> off the autonomous mode and then write that new setting to the EEPROM. After
>> that it looks like the autonomous mode stays off. Is that correct?
> Correct, that'll work too, but I suggest you don't do that and update the 
> eeprom values like we do in userspace. That'll allow the adapter to wake up 
> the PC when the kernel module isn't running. Disabling autonomous mode will 
> prevent that from working. You can only write to the eeprom once every 10 
> seconds by the way.
> 
>>
>> The autonomous mode really doesn't work well with the framework as it is
>> today.
>>
>> CEC framework support for 'wakeup on CEC command' is something that is 
>> planned
>> for the future.
> The autonomous mode is only really meant for waking up the PC, from S3 with 
> the USB version and all modes with the internal version for Intel boards. It 
> should be disabled as long as the userspace application or kernel module is 
> running, by sending MSGCODE_SET_CONTROLLED 1 and then send a poll before the 
> 30 second timeout times out. Then, when the kernel module stops using the 
> module, when the system powers off or goes to standby, you send a 
> MSGCODE_SET_CONTROLLED 0 and then close the connection. The adapter will then 
> take over, allowing the TV to wake up the PC again.

Thank you for the information, very useful.

I've added this to the TODO file of the driver. I have made a pull request for
the driver in the current state. It will be in drivers/staging anyway, so it
doesn't have to be perfect initially. But it is very useful to 'show off' the
new API for kernel 4.8.

I'll work more on this driver so by the time it can be moved out of staging
it should have all this functionality built-in.

Regards,

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

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[李務誠]

On Mon, Jul 11, 2016 at 10:56 AM, tiffany lin  wrote:
> Hi Hans,
>
> On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
>> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
>> > Add V4L2_PIX_FMT_MT21 documentation
>> >
>> > Signed-off-by: Tiffany Lin 
>> > ---
>> >  Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
>> > b/Documentation/DocBook/media/v4l/pixfmt.xml
>> > index 5a08aee..d40e0ce 100644
>> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
>> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
>> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is 
>> > JPEG data and should be
>> >  concatenated to form the JPEG stream. 
>> >  
>> >   
>> > + 
>> > +   V4L2_PIX_FMT_MT21
>> > +   'MT21'
>> > +   Compressed two-planar YVU420 format used by Mediatek MT8173
>> > +   codec driver.
>>
>> Can you give a few more details? The encoder driver doesn't seem to produce 
>> this
>> format, so who is creating this? Where is this format documented?
Decoder hardware produces MT21 (compressed). Image processor can
convert it to a format that can be input of display driver. Tiffany.
When do you plan to upstream image processor (mtk-mdp)?
>
> It can be as input format for encoder, MDP and display drivers in our
> platform.
I remember display driver can only accept uncompressed MT21. Right?
Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
format. It's not usable until it's decompressed and converted by image
processor.
> This private format is only available in our platform.
> So I put it in "Reserved Format Identifiers" sections.
>
>
> best regards,
> Tiffany
>
>> Regards,
>>
>>   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
--
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