RE: [PATCH v2 08/12] intel-ipu3: params: compute and program ccs

[Zhi, Yong]

Hi, Andy,

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
> Sent: Friday, June 16, 2017 3:53 PM
> To: Zhi, Yong 
> Cc: Linux Media Mailing List ;
> sakari.ai...@linux.intel.com; Zheng, Jian Xu ;
> tf...@chromium.org; Mani, Rajmohan ;
> Toivonen, Tuukka 
> Subject: Re: [PATCH v2 08/12] intel-ipu3: params: compute and program ccs
> 
> On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi  wrote:
> > A collection of routines that are mainly responsible to calculate the
> > acc parameters.
> 
> > +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
> > +   unsigned int divider) {
> > +   unsigned int i = 0;
> > +
> > +   while (counter <= divider / 2) {
> > +   divider /= 2;
> > +   i++;
> > +   }
> > +
> > +   return i;
> 
> We have a lot of different helpers including one you may use instead of this
> function.
> 
> It's *highly* recommended you learn what we have under lib/ (and not only
> there) in kernel bewfore submitting a new version.
> 

Tried to identify more places that could be re-implemented with lib helpers or 
more generic method, but we failed to spot any obvious candidate thus far.

> --
> With Best Regards,
> Andy Shevchenko

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 Oct 11 05:00:15 CEST 2017
media-tree git hash:c1301077213d4dca34f01fc372b64d3c4a49a437
media_build git hash:   4f1031979bd1ff205f19f88c85f387d6e5408f5e
v4l-utils git hash: 01c04f7c8ad1a91af33e20621eba9200f447737e
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

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

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/index.html

RE: [PATCH v2 09/12] intel-ipu3: css hardware setup

[Zhi, Yong]

Hi, Andy,

Thanks for the review.

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
> Sent: Saturday, June 17, 2017 12:07 PM
> To: Sakari Ailus 
> Cc: Zhi, Yong ; Linux Media Mailing List  me...@vger.kernel.org>; sakari.ai...@linux.intel.com; Zheng, Jian Xu
> ; Tomasz Figa ; Mani,
> Rajmohan ; Toivonen, Tuukka
> 
> Subject: Re: [PATCH v2 09/12] intel-ipu3: css hardware setup
> 
> On Sat, Jun 17, 2017 at 9:43 PM, Sakari Ailus  wrote:
> > On Sat, Jun 17, 2017 at 01:54:51AM +0300, Andy Shevchenko wrote:
> >> On Thu, Jun 15, 2017 at 1:19 AM, Yong Zhi  wrote:
> 
> >> > +static void writes(void *mem, ssize_t len, void __iomem *reg) {
> >> > +   while (len >= 4) {
> >> > +   writel(*(u32 *)mem, reg);
> >> > +   mem += 4;
> >> > +   reg += 4;
> >> > +   len -= 4;
> >> > +   }
> >> > +}
> >>
> >> Again, I just looked into patches and first what I see is reinventing the
> wheel.
> >>
> >> memcpy_toio()
> 
> > That doesn't quite work: the hardware only supports 32-bit access.
> >
> > So the answer is writesl().
> 
> Makes sense!
> 

We are not able to use writesl() in the past because it's not defined for x86 
platform, but now the helper function is available in 4.14, we will use it in 
next update.

> --
> With Best Regards,
> Andy Shevchenko

[PATCH]media: dvb-frontends: Add delay to Si2168 restart

[Ron Economos]

On faster CPUs a delay is required after the POWER_UP/RESUME command and 
the DD_RESTART command. Without the delay, the DD_RESTART command often 
returns -EREMOTEIO and the Si2168 does not restart.


diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c

index 172fc36..f2a3c8f 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -15,6 +15,7 @@
  */

 #include "si2168_priv.h"
+#include 

 static const struct dvb_frontend_ops si2168_ops;

@@ -435,6 +436,7 @@ static int si2168_init(struct dvb_frontend *fe)
    if (ret)
    goto err;

+   udelay(100);
    memcpy(cmd.args, "\x85", 1);
    cmd.wlen = 1;
    cmd.rlen = 1;

Re: [PATCH v2] Staging: bcm2048 fix bare use of 'unsigned' in radio-bcm2048.c

[Tobin C. Harding]

Hi Branislav,

On Tue, Oct 10, 2017 at 03:29:19PM +0200, Branislav Radocaj wrote:
> This is a patch to the radio-bcm2048.c file that fixes up
> a warning found by the checkpatch.pl tool.
> 
> Signed-off-by: Branislav Radocaj 

Nice work, a few git log nit picks for you to ensure your future kernel 
development success.

You can read all this in Documentaton/process/submitting-patches.rst (section 
2).

- You can use imperative mood, i.e 'Fix foo by doing bar' instead of 'This 
patch ...'
- We don't need to mention the file (either in the summary or in the body), 
people can see this from
  the diff.

This is one way of writing the git log message for checkpatch fixes

checkpatch emits WARNING: EXPORT_SYMBOL(foo); should immediately follow
its function/variable.

Move EXPORT_SYMBOL macro call to immediately follow function definition.


Good work, hope this helps.

Tobin

{PATCH] media: dvb-core: Crash from uninitialized pointer

[Ron Economos]

In the function dvb_net_ule(), the pointer h.priv is not initialized. 
When a ULE packet is received, the kernel crashes.


diff --git a/drivers/media/dvb-core/dvb_net.c 
b/drivers/media/dvb-core/dvb_net.c

index 06b0dcc..abfa3e5 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -798,6 +798,7 @@ static void dvb_net_ule(struct net_device *dev, 
const u8 *buf, size_t buf_len)

 * For all TS cells in current buffer.
 * Appearently, we are called for every single TS cell.
 */
+   h.priv = netdev_priv(dev);
    for (h.ts = h.buf, h.ts_end = h.buf + h.buf_len;
 h.ts < h.ts_end; /* no incr. */) {
    if (h.new_ts) {

Re: [PATCH v7 5/7] media: open.rst: Adjust some terms to match the glossary

[Sakari Ailus]

Hi Mauro,

On Tue, Oct 10, 2017 at 08:37:43AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 6 Oct 2017 15:48:22 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Wed, Sep 27, 2017 at 07:23:47PM -0300, Mauro Carvalho Chehab wrote:
> > > As we now have a glossary, some terms used on open.rst
> > > require adjustments.
> > > 
> > > Acked-by: Hans Verkuil 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > >  Documentation/media/uapi/v4l/open.rst | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/Documentation/media/uapi/v4l/open.rst 
> > > b/Documentation/media/uapi/v4l/open.rst
> > > index f603bc9b49a0..0daf0c122c19 100644
> > > --- a/Documentation/media/uapi/v4l/open.rst
> > > +++ b/Documentation/media/uapi/v4l/open.rst
> > > @@ -143,7 +143,7 @@ Related Devices
> > >  Devices can support several functions. For example video capturing, VBI
> > >  capturing and radio support.
> > >  
> > > -The V4L2 API creates different nodes for each of these functions.
> > > +The V4L2 API creates different V4L2 device nodes for each of these 
> > > functions.  
> > 
> > A V4L2 device node is an instance of the V4L2 API. At the very least we
> > should call them "V4L2 device node types", not device nodes only. This
> > simply would suggests they're separate.
> 
> OK, I added "types" there.
> 
> > 
> > s/creates/defines/ ?
> 
> It is meant to say create.
> 
> A device that supports both radio, video and VBI for the same V4L2
> input will create three device nodes:
>   /dev/video0
>   /dev/radio0
>   /dev/vbi0
> 
> As all are associated to the same video input, and an ioctl send 
> to one device may affect the other devices too, as they all associated
> with the same hardware.

Right. In this case I'd change the sentence. What would you think of this?

"Each of these functions is available via separate V4L2 device node."

For it's not the V4L2 API that creates them. I failed to grasp what the
original sentence meant. Was it about API, or framework, or were the
devices nodes just separate or unlike as well?

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

On Tue, Oct 10, 2017 at 09:49:38AM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 14:54:35 +0300
> Sakari Ailus  escreveu:
> 
> > On Tue, Oct 10, 2017 at 06:15:03AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Fri, 6 Oct 2017 14:51:06 +0300
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Mauro,
> > > > 
> > > > On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:  
> > > > > > +V4L2 device node
> > > > > > +   A device node that is associated to a V4L2 main driver,
> > > > > > +   as specified in :ref:`v4l2_device_naming`.
> > > > 
> > > > I think we need to name the interface, not so much their instances.
> > > > 
> > > > How about adding:
> > > > 
> > > > V4L2
> > > > Video4Linux 2 interface. The interface implemented by **V4L2 
> > > > device
> > > > nodes**.
> > > > 
> > > > and:
> > > > 
> > > > V4L2 device node
> > > > A device node implementing the **V4L2** interface.  
> > > 
> > > Not sure if I answered it already. subdev API is part of V4L2.
> > > So, a change like that would cause more harm than good ;-)  
> > 
> > Hmm. There seems to be a gap here. It'd be much easier to maintain
> > consistency in naming and definitions if V4L2 sub-device nodes were also
> > documented to be V4L2 device nodes, just as any other device nodes exposed
> > by drivers through the V4L2 framework.
> > 
> > > 
> > > The definition should let it clear that only the devnodes 
> > > implemented by the V4L2 main driver are considered as
> > > V4L2 device nodes.  
> > 
> > Why? I don't think we should make assumptions on which driver exposes a
> > device node; this is not visible to the user space after all.
> 
> Because the V4L2 spec documents, with the exception of the subdev.rst
> (and where otherwise noticed), assumes that a V4L2 device node doesn't
> include subdevs.
> 
> So, if you loo, for example, at the chapter 1 name:
>   "common API elements"
> 
> it implies that every single V4L2 device node supports what's there.
> But that's not the case, for example, for what's described at
> Documentation/media/uapi/v4l/querycap.rst (with is part of
> chapter 1).

Ah. I see what you mean.

> 
> There are a couple of possible alternatives:
> 
> 1) define V4L2 device nodes excluding /dev/subdev, with is the
>current approach;
> 
> 2) rewrite the entire V4L2 uAPI spec to explicitly talk, on each
>section, if it applies or not to sub-devices;

There are exceptions in the common API elements section even now. For
instance, it mentions that radio devices don't support video streaming
related IOCTLs. Under common API elements, also the first section (opening
and closing devices) refers to the interfaces section which, as we know,
contains sub-device documentation.

Do you see that something else is needed than telling which common API
elements aren't relevant for sub-devices? (I didn't find explicit
information in other sections, by a quick glance at least, telling which
interfaces they apply to.)

Should we make such a change, this would be an additional argument for
supporting VIDIOC_QUERYCAP on sub-devices. Further on, section 8, "Common
definitions for V4L2 and V4L2 subdev interfaces", should probably be merged
with the "common API elements" section.

Just my thougts. Anyway... let's continue tomorrow.

> 
> 3) "promote" subdev API to a separate part of the media spec,
>just like what it was done for media controller, e. g. adding
>a /Documentation/media/uapi/subdev directory and add there
>descriptions for all syscalls that apply to subdevs
>(open, close, ioctl). That would be weird from kAPI point of
>view, as splitting it from V4L2 won't make sense there. So,
>we'll likely need to add some notes at both kAPI and uAPI to
>explain that the subdev API userspace API is just a different
>way to expose V4L2 hardware control, but, internally, both
>are implemented by the same V4L2 core.
> 
> This patchset assumes (1). I'm ok if someone wants to do either
> (2) or (3), but I won't have the required time to do such
> changes.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH v2 4/6] tuner-simple: allow setting mono radio mode

[Maciej S. Szmigiero]

For some types of tuners (Philips FMD1216ME(X) MK3 currently) we know that
letting TDA9887 output port 1 remain high (inactive) will switch FM radio
to mono mode.
Let's make use of this functionality - nothing changes for the default
stereo radio mode.

Tested on a Medion 95700 board which has a FMD1216ME tuner.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/tuners/tuner-simple.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/tuner-simple.c 
b/drivers/media/tuners/tuner-simple.c
index cf44d3657f55..01ab94681d2d 100644
--- a/drivers/media/tuners/tuner-simple.c
+++ b/drivers/media/tuners/tuner-simple.c
@@ -670,6 +670,7 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
int rc, j;
struct tuner_params *t_params;
unsigned int freq = params->frequency;
+   bool mono = params->audmode == V4L2_TUNER_MODE_MONO;
 
tun = priv->tun;
 
@@ -736,8 +737,8 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
config |= TDA9887_PORT2_ACTIVE;
if (t_params->intercarrier_mode)
config |= TDA9887_INTERCARRIER;
-/* if (t_params->port1_set_for_fm_mono)
-   config &= ~TDA9887_PORT1_ACTIVE;*/
+   if (t_params->port1_set_for_fm_mono && mono)
+   config &= ~TDA9887_PORT1_ACTIVE;
if (t_params->fm_gain_normal)
config |= TDA9887_GAIN_NORMAL;
if (t_params->radio_if == 2)

[PATCH v2 0/6] [media] Add analog mode support for Medion MD95700

[Maciej S. Szmigiero]

This series adds support for analog part of Medion 95700 in the cxusb
driver.

What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo / mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.

What does not work yet:
* Audio,
* VBI,
* Picture controls.

This series (as an one patch) was submitted for inclusion few years ago,
then waited few months in a patch queue.
Unfortunately, by the time it was supposed to be merged there
were enough changes in media that it was no longer mergable.

I thought at that time that I will be able to rebase and retest it soon
but unfortunately up till now I was never able to find enough time to do
so.
Also, with the passing of time the implementation diverged more and
more from the current kernel code, necessitating even more reworking.

That last iteration can be found here:
https://patchwork.linuxtv.org/patch/8048/

Since that version there had been the following changes:
* Adaptation to changes in V4L2 / DVB core,

* Radio device was added, with a possibility to tune to a FM radio
station and switch between stereo and mono modes (tested by taping
audio signal directly at tuner output pin),

* DVB / analog coexistence was improved - resolved a few cases where
DVB core would switch off power or reset the tuner when the device
was still being used but in the analog mode,

* Fixed issues reported by v4l2-compliance,

* Switching to raw BT.656 mode is now done by a custom streaming
parameter set via VIDIOC_S_PARM ioctl instead of using a
V4L2_BUF_TYPE_PRIVATE buffer (which was removed from V4L2),

* General small code cleanups (like using BIT() or ARRAY_SIZE() macros
instead of open coding them, code formatting improvements, etc.).

Changes from v1:
* Only support configuration of cx25840 pins that the cxusb driver is
actually using so there is no need for an ugly CX25840_PIN() macro,

* Split cxusb changes into two patches: first one implementing
digital / analog coexistence in this driver, second one adding the
actual implementation of the analog mode,

* Fix warning reported by kbuild test robot.

 drivers/media/i2c/cx25840/cx25840-core.c |  405 ++-
 drivers/media/i2c/cx25840/cx25840-core.h |   11 +
 drivers/media/i2c/cx25840/cx25840-vbi.c  |3 +
 drivers/media/pci/ivtv/ivtv-i2c.c|1 +
 drivers/media/tuners/tuner-simple.c  |5 +-
 drivers/media/usb/dvb-usb/Kconfig|8 +-
 drivers/media/usb/dvb-usb/Makefile   |2 +-
 drivers/media/usb/dvb-usb/cxusb-analog.c | 1865 ++
 drivers/media/usb/dvb-usb/cxusb.c|  453 +++-
 drivers/media/usb/dvb-usb/cxusb.h|  136 +++
 drivers/media/usb/dvb-usb/dvb-usb-dvb.c  |   20 +-
 drivers/media/usb/dvb-usb/dvb-usb-init.c |   13 +
 drivers/media/usb/dvb-usb/dvb-usb.h  |8 +
 include/media/drv-intf/cx25840.h |   74 +-
 14 files changed, 2937 insertions(+), 67 deletions(-)
 create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c

[PATCH v2 6/6] [media] cxusb: add analog mode support for Medion MD95700

[Maciej S. Szmigiero]

This patch adds support for analog part of Medion 95700 in the cxusb
driver.

What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo / mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.

What does not work yet:
* Audio,
* VBI,
* Picture controls.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/usb/dvb-usb/Kconfig|8 +-
 drivers/media/usb/dvb-usb/Makefile   |2 +-
 drivers/media/usb/dvb-usb/cxusb-analog.c | 1865 ++
 drivers/media/usb/dvb-usb/cxusb.c|3 +-
 drivers/media/usb/dvb-usb/cxusb.h|  114 +-
 5 files changed, 1973 insertions(+), 19 deletions(-)
 create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c

diff --git a/drivers/media/usb/dvb-usb/Kconfig 
b/drivers/media/usb/dvb-usb/Kconfig
index 959fa09dfd92..ba941069ae3b 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -118,7 +118,9 @@ config DVB_USB_UMT_010
 
 config DVB_USB_CXUSB
tristate "Conexant USB2.0 hybrid reference design support"
-   depends on DVB_USB
+   depends on DVB_USB && VIDEO_V4L2
+   select VIDEO_CX25840
+   select VIDEOBUF2_VMALLOC
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX22702 if MEDIA_SUBDRV_AUTOSELECT
select DVB_LGDT330X if MEDIA_SUBDRV_AUTOSELECT
@@ -136,8 +138,8 @@ config DVB_USB_CXUSB
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
help
  Say Y here to support the Conexant USB2.0 hybrid reference design.
- Currently, only DVB and ATSC modes are supported, analog mode
- shall be added in the future. Devices that require this module:
+ DVB and ATSC modes are supported, with basic analog mode support
+ for Medion MD95700. Devices that require this module:
 
  Medion MD95700 hybrid USB2.0 device.
  DViCO FusionHDTV (Bluebird) USB2.0 devices
diff --git a/drivers/media/usb/dvb-usb/Makefile 
b/drivers/media/usb/dvb-usb/Makefile
index 3b3f32b426d1..24d222e9acc7 100644
--- a/drivers/media/usb/dvb-usb/Makefile
+++ b/drivers/media/usb/dvb-usb/Makefile
@@ -40,7 +40,7 @@ obj-$(CONFIG_DVB_USB_M920X) += dvb-usb-m920x.o
 dvb-usb-digitv-objs := digitv.o
 obj-$(CONFIG_DVB_USB_DIGITV) += dvb-usb-digitv.o
 
-dvb-usb-cxusb-objs := cxusb.o
+dvb-usb-cxusb-objs := cxusb.o cxusb-analog.o
 obj-$(CONFIG_DVB_USB_CXUSB) += dvb-usb-cxusb.o
 
 dvb-usb-ttusb2-objs := ttusb2.o
diff --git a/drivers/media/usb/dvb-usb/cxusb-analog.c 
b/drivers/media/usb/dvb-usb/cxusb-analog.c
new file mode 100644
index ..c04c7c0493a9
--- /dev/null
+++ b/drivers/media/usb/dvb-usb/cxusb-analog.c
@@ -0,0 +1,1865 @@
+/* DVB USB compliant linux driver for Conexant USB reference design -
+ * (analog part).
+ *
+ * Copyright (C) 2011, 2017 Maciej S. Szmigiero (m...@maciej.szmigiero.name)
+ *
+ * TODO:
+ *  * audio support,
+ *  * finish radio support (requires audio of course),
+ *  * VBI support,
+ *  * controls support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cxusb.h"
+
+static int cxusb_medion_v_queue_setup(struct vb2_queue *q,
+ unsigned int *num_buffers,
+ unsigned int *num_planes,
+ unsigned int sizes[],
+ struct device *alloc_devs[])
+{
+   struct dvb_usb_device *dvbdev = vb2_get_drv_priv(q);
+   struct cxusb_medion_dev *cxdev = dvbdev->priv;
+   unsigned int size = cxdev->raw_mode ?
+   CXUSB_VIDEO_MAX_FRAME_SIZE :
+   cxdev->width * cxdev->height * 2;
+
+   if (*num_planes > 0) {
+   if (*num_planes != 1)
+   return -EINVAL;
+
+   if (sizes[0] < size)
+   return -EINVAL;
+   } else {
+   *num_planes = 1;
+   sizes[0] = size;
+   }
+
+   if (q->num_buffers + *num_buffers < 6)
+   *num_buffers = 6 - q->num_buffers;
+
+   return 0;
+}
+
+static int cxusb_medion_v_buf_init(struct vb2_buffer *vb)
+{
+   struct dvb_usb_device *dvbdev = vb2_get_drv_priv(vb->vb2_queue);
+   struct cxusb_medion_dev *cxdev = dvbdev->priv;
+
+   cxusb_vprintk(dvbdev, OPS, "buffer init\n");
+
+   if (cxdev->raw_mode) {
+   if (vb2_plane_size(vb, 0) < CXUSB_VIDEO_MAX_FRAME_SIZE)
+   return 

[PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

[Maciej S. Szmigiero]

This patch prepares cxusb driver for supporting the analog part of
Medion 95700 (previously only the digital - DVB - mode was supported).

Specifically, it adds support for:
* switching the device between analog and digital modes of operation,
* enforcing that only one mode is active at the same time due to hardware
limitations.

Actual implementation of the analog mode will be provided by the next
commit.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/usb/dvb-usb/cxusb.c| 450 +++
 drivers/media/usb/dvb-usb/cxusb.h|  48 
 drivers/media/usb/dvb-usb/dvb-usb-dvb.c  |  20 +-
 drivers/media/usb/dvb-usb/dvb-usb-init.c |  13 +
 drivers/media/usb/dvb-usb/dvb-usb.h  |   8 +
 5 files changed, 486 insertions(+), 53 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 37dea0adc695..f73ffa13d177 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -16,6 +16,7 @@
  * Copyright (C) 2005 Patrick Boettcher (patrick.boettc...@posteo.de)
  * Copyright (C) 2006 Michael Krufky (mkru...@linuxtv.org)
  * Copyright (C) 2006, 2007 Chris Pascoe (c.pas...@itee.uq.edu.au)
+ * Copyright (C) 2011, 2017 Maciej S. Szmigiero (m...@maciej.szmigiero.name)
  *
  *   This program is free software; you can redistribute it and/or modify it
  *   under the terms of the GNU General Public License as published by the Free
@@ -24,8 +25,11 @@
  * see Documentation/dvb/README.dvb-usb for more information
  */
 #include 
-#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 
 #include "cxusb.h"
 
@@ -46,17 +50,46 @@
 #include "si2157.h"
 
 /* debug */
-static int dvb_usb_cxusb_debug;
+int dvb_usb_cxusb_debug;
 module_param_named(debug, dvb_usb_cxusb_debug, int, 0644);
-MODULE_PARM_DESC(debug, "set debugging level (1=rc (or-able))." 
DVB_USB_DEBUG_STATUS);
+MODULE_PARM_DESC(debug, "set debugging level (see cxusb.h)."
+DVB_USB_DEBUG_STATUS);
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
-#define deb_info(args...)   dprintk(dvb_usb_cxusb_debug, 0x03, args)
-#define deb_i2c(args...)dprintk(dvb_usb_cxusb_debug, 0x02, args)
+#define deb_info(args...)   dprintk(dvb_usb_cxusb_debug, CXUSB_DBG_MISC, args)
+#define deb_i2c(args...)dprintk(dvb_usb_cxusb_debug, CXUSB_DBG_I2C, args)
+
+enum cxusb_table_index {
+   MEDION_MD95700,
+   DVICO_BLUEBIRD_LG064F_COLD,
+   DVICO_BLUEBIRD_LG064F_WARM,
+   DVICO_BLUEBIRD_DUAL_1_COLD,
+   DVICO_BLUEBIRD_DUAL_1_WARM,
+   DVICO_BLUEBIRD_LGZ201_COLD,
+   DVICO_BLUEBIRD_LGZ201_WARM,
+   DVICO_BLUEBIRD_TH7579_COLD,
+   DVICO_BLUEBIRD_TH7579_WARM,
+   DIGITALNOW_BLUEBIRD_DUAL_1_COLD,
+   DIGITALNOW_BLUEBIRD_DUAL_1_WARM,
+   DVICO_BLUEBIRD_DUAL_2_COLD,
+   DVICO_BLUEBIRD_DUAL_2_WARM,
+   DVICO_BLUEBIRD_DUAL_4,
+   DVICO_BLUEBIRD_DVB_T_NANO_2,
+   DVICO_BLUEBIRD_DVB_T_NANO_2_NFW_WARM,
+   AVERMEDIA_VOLAR_A868R,
+   DVICO_BLUEBIRD_DUAL_4_REV_2,
+   CONEXANT_D680_DMB,
+   MYGICA_D689,
+   MYGICA_T230,
+   MYGICA_T230C,
+   NR__cxusb_table_index
+};
+
+static struct usb_device_id cxusb_table[];
 
-static int cxusb_ctrl_msg(struct dvb_usb_device *d,
- u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
+int cxusb_ctrl_msg(struct dvb_usb_device *d,
+  u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
 {
struct cxusb_state *st = d->priv;
int ret;
@@ -88,7 +121,8 @@ static void cxusb_gpio_tuner(struct dvb_usb_device *d, int 
onoff)
struct cxusb_state *st = d->priv;
u8 o[2], i;
 
-   if (st->gpio_write_state[GPIO_TUNER] == onoff)
+   if (st->gpio_write_state[GPIO_TUNER] == onoff &&
+   !st->gpio_write_refresh[GPIO_TUNER])
return;
 
o[0] = GPIO_TUNER;
@@ -99,6 +133,7 @@ static void cxusb_gpio_tuner(struct dvb_usb_device *d, int 
onoff)
deb_info("gpio_write failed.\n");
 
st->gpio_write_state[GPIO_TUNER] = onoff;
+   st->gpio_write_refresh[GPIO_TUNER] = false;
 }
 
 static int cxusb_bluebird_gpio_rw(struct dvb_usb_device *d, u8 changemask,
@@ -258,7 +293,7 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg msg[],
 
 static u32 cxusb_i2c_func(struct i2c_adapter *adapter)
 {
-   return I2C_FUNC_I2C;
+   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
 static struct i2c_algorithm cxusb_i2c_algo = {
@@ -266,15 +301,48 @@ static struct i2c_algorithm cxusb_i2c_algo = {
.functionality = cxusb_i2c_func,
 };
 
-static int cxusb_power_ctrl(struct dvb_usb_device *d, int onoff)
+static int _cxusb_power_ctrl(struct dvb_usb_device *d, int onoff)
 {
u8 b = 0;
+
+   deb_info("setting power %s\n", onoff ? "ON" : "OFF");
+
if (onoff)
return cxusb_ctrl_msg(d, CMD_POWER_ON, , 1, NULL, 0);
else
return cxusb_ctrl_msg(d, CMD_POWER_OFF, 

[PATCH v2 1/6] cx25840: add pin to pad mapping and output format configuration

[Maciej S. Szmigiero]

This commit adds pin to pad mapping and output format configuration support
in CX2584x-series chips to cx25840 driver.

This functionality is then used to allow disabling ivtv-specific hacks
(called a "generic mode"), so cx25840 driver can be used for other devices
not needing them without risking compatibility problems.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 394 ++-
 drivers/media/i2c/cx25840/cx25840-core.h |  11 +
 drivers/media/i2c/cx25840/cx25840-vbi.c  |   3 +
 drivers/media/pci/ivtv/ivtv-i2c.c|   1 +
 include/media/drv-intf/cx25840.h |  74 +-
 5 files changed, 481 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index f38bf819d805..a1efc975852c 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -21,6 +21,9 @@
  * CX23888 DIF support for the HVR1850
  * Copyright (C) 2011 Steven Toth 
  *
+ * CX2584x pin to pad mapping and output format configuration support are
+ * Copyright (C) 2011 Maciej S. Szmigiero 
+ *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version 2
@@ -316,6 +319,260 @@ static int cx23885_s_io_pin_config(struct v4l2_subdev 
*sd, size_t n,
return 0;
 }
 
+static u8 cx25840_function_to_pad(struct i2c_client *client, u8 function)
+{
+   switch (function) {
+   case CX25840_PAD_ACTIVE:
+   return 1;
+
+   case CX25840_PAD_VACTIVE:
+   return 2;
+
+   case CX25840_PAD_CBFLAG:
+   return 3;
+
+   case CX25840_PAD_VID_DATA_EXT0:
+   return 4;
+
+   case CX25840_PAD_VID_DATA_EXT1:
+   return 5;
+
+   case CX25840_PAD_GPO0:
+   return 6;
+
+   case CX25840_PAD_GPO1:
+   return 7;
+
+   case CX25840_PAD_GPO2:
+   return 8;
+
+   case CX25840_PAD_GPO3:
+   return 9;
+
+   case CX25840_PAD_IRQ_N:
+   return 10;
+
+   case CX25840_PAD_AC_SYNC:
+   return 11;
+
+   case CX25840_PAD_AC_SDOUT:
+   return 12;
+
+   case CX25840_PAD_PLL_CLK:
+   return 13;
+
+   case CX25840_PAD_VRESET:
+   return 14;
+
+   default:
+   if (function != CX25840_PAD_DEFAULT)
+   v4l_err(client,
+   "invalid function %u, assuming default\n",
+   (unsigned int)function);
+   return 0;
+   }
+}
+
+static void cx25840_set_invert(u8 *pinctrl3, u8 *voutctrl4, u8 function,
+  u8 pin, bool invert)
+{
+   switch (function) {
+   case CX25840_PAD_IRQ_N:
+   if (invert)
+   *pinctrl3 &= ~2;
+   else
+   *pinctrl3 |= 2;
+   break;
+
+   case CX25840_PAD_ACTIVE:
+   if (invert)
+   *voutctrl4 |= BIT(2);
+   else
+   *voutctrl4 &= ~BIT(2);
+   break;
+
+   case CX25840_PAD_VACTIVE:
+   if (invert)
+   *voutctrl4 |= BIT(5);
+   else
+   *voutctrl4 &= ~BIT(5);
+   break;
+
+   case CX25840_PAD_CBFLAG:
+   if (invert)
+   *voutctrl4 |= BIT(4);
+   else
+   *voutctrl4 &= ~BIT(4);
+   break;
+
+   case CX25840_PAD_VRESET:
+   if (invert)
+   *voutctrl4 |= BIT(0);
+   else
+   *voutctrl4 &= ~BIT(0);
+   break;
+   }
+
+   if (function != CX25840_PAD_DEFAULT)
+   return;
+
+   switch (pin) {
+   case CX25840_PIN_DVALID_PRGM0:
+   if (invert)
+   *voutctrl4 |= BIT(6);
+   else
+   *voutctrl4 &= ~BIT(6);
+   break;
+
+   case CX25840_PIN_HRESET_PRGM2:
+   if (invert)
+   *voutctrl4 |= BIT(1);
+   else
+   *voutctrl4 &= ~BIT(1);
+   break;
+   }
+}
+
+static int cx25840_s_io_pin_config(struct v4l2_subdev *sd, size_t n,
+  struct v4l2_subdev_io_pin_config *p)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+   unsigned int i;
+   u8 pinctrl[6], pinconf[10], voutctrl4;
+
+   for (i = 0; i < 6; i++)
+   pinctrl[i] = cx25840_read(client, 0x114 + i);
+
+   for (i = 0; i < 10; i++)
+   pinconf[i] = cx25840_read(client, 0x11c + i);
+
+   voutctrl4 = cx25840_read(client, 0x407);

[PATCH v2 3/6] cx25840: fix a possible divide by zero in set_fmt callback

[Maciej S. Szmigiero]

If set_fmt callback is called with format->width or format->height set to
zero and HACTIVE_CNT or VACTIVE_CNT bits (respectively) in chip are zero
we will divide by zero later in this callback when we try to calculate
HSC or VSC values.

Fix this by explicitly rejecting these values.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index c36103587c4d..cebd1a540df8 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -1672,8 +1672,9 @@ static int cx25840_set_fmt(struct v4l2_subdev *sd,
 * height. Without that margin the cx23885 fails in this
 * check.
 */
-   if ((fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
-   (Vlines * 8 < Vsrc) || (Vsrc + 1 < Vlines)) {
+   if ((fmt->width == 0) || (Vlines == 0) ||
+   (fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
+   (Vlines * 8 < Vsrc) || (Vsrc + 1 < Vlines)) {
v4l_err(client, "%dx%d is not a valid size!\n",
fmt->width, fmt->height);
return -ERANGE;

[PATCH v2 2/6] cx25840: describe standard for 0b1100 value in AFD_FMT_STAT bits

[Maciej S. Szmigiero]

A 0b1100 value in 4 LSBs of "General Status 1" register (AFD_FMT_STAT) has
known meaning for CX2584x-series chips - it means that a SECAM signal is
currently detected by the chip.

Use this opportunity to also fix wrong binary values that were present
as comments attached to some entries in an array where
chip register -> V4L2 standard mappings are stored.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index a1efc975852c..c36103587c4d 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -2145,11 +2145,11 @@ static int cx25840_g_std(struct v4l2_subdev *sd, 
v4l2_std_id *std)
/* 0111 */ V4L2_STD_PAL_Nc,
/* 1000 */ V4L2_STD_PAL_60,
 
-   /* 1001 */ V4L2_STD_UNKNOWN,
-   /* 1010 */ V4L2_STD_UNKNOWN,
/* 1001 */ V4L2_STD_UNKNOWN,
/* 1010 */ V4L2_STD_UNKNOWN,
/* 1011 */ V4L2_STD_UNKNOWN,
+   /* 1100 */ V4L2_STD_SECAM,
+   /* 1101 */ V4L2_STD_UNKNOWN,
/* 1110 */ V4L2_STD_UNKNOWN,
/*  */ V4L2_STD_UNKNOWN
};

Re: [PATCH 2/8] Documentation: fix admin-guide doc refs

[Rafael J. Wysocki]

On Tue, Oct 10, 2017 at 7:36 PM, Tom Saeger  wrote:
> Make admin-guide document refs valid.
>
> Signed-off-by: Tom Saeger 

Acked-by: Rafael J. Wysocki 

> ---
>  Documentation/ABI/stable/sysfs-devices | 2 +-
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 6 --
>  Documentation/ABI/testing/sysfs-power  | 6 --
>  Documentation/admin-guide/README.rst   | 2 +-
>  Documentation/admin-guide/kernel-parameters.txt| 4 ++--
>  Documentation/admin-guide/reporting-bugs.rst   | 4 ++--
>  Documentation/laptops/laptop-mode.txt  | 6 +++---
>  Documentation/media/v4l-drivers/bttv.rst   | 2 +-
>  Documentation/power/interface.txt  | 3 ++-
>  9 files changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices 
> b/Documentation/ABI/stable/sysfs-devices
> index 35c457f8ce73..4404bd9b96c1 100644
> --- a/Documentation/ABI/stable/sysfs-devices
> +++ b/Documentation/ABI/stable/sysfs-devices
> @@ -1,5 +1,5 @@
>  # Note: This documents additional properties of any device beyond what
> -# is documented in Documentation/sysfs-rules.txt
> +# is documented in Documentation/admin-guide/sysfs-rules.rst
>
>  What:  /sys/devices/*/of_node
>  Date:  February 2015
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index f3d5817c4ef0..d6d862db3b5d 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -187,7 +187,8 @@ Description:Processor frequency boosting control
> This switch controls the boost setting for the whole system.
> Boosting allows the CPU and the firmware to run at a frequency
> beyound it's nominal limit.
> -   More details can be found in Documentation/cpu-freq/boost.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/cpufreq.rst
>
>
>  What:  /sys/devices/system/cpu/cpu#/crash_notes
> @@ -223,7 +224,8 @@ Description:Parameters for the Intel P-state 
> driver
> no_turbo: limits the driver to selecting P states below the 
> turbo
> frequency range.
>
> -   More details can be found in 
> Documentation/cpu-freq/intel-pstate.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/intel_pstate.rst
>
>  What:  
> /sys/devices/system/cpu/cpu*/cache/index*/
>  Date:  July 2014(documented, existed before August 2008)
> diff --git a/Documentation/ABI/testing/sysfs-power 
> b/Documentation/ABI/testing/sysfs-power
> index a1d1612f3651..1e0d1dac706b 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -18,7 +18,8 @@ Description:
> Writing one of the above strings to this file causes the 
> system
> to transition into the corresponding state, if available.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/mem_sleep
>  Date:  November 2016
> @@ -35,7 +36,8 @@ Description:
> represented by it to be used on subsequent attempts to suspend
> the system.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/disk
>  Date:  September 2006
> diff --git a/Documentation/admin-guide/README.rst 
> b/Documentation/admin-guide/README.rst
> index b5343c5aa224..63066db39910 100644
> --- a/Documentation/admin-guide/README.rst
> +++ b/Documentation/admin-guide/README.rst
> @@ -350,7 +350,7 @@ If something goes wrong
> help debugging the problem.  The text above the dump is also
> important: it tells something about why the kernel dumped code (in
> the above example, it's due to a bad kernel pointer). More information
> -   on making sense of the dump is in 
> Documentation/admin-guide/oops-tracing.rst
> +   on making sense of the dump is in 
> Documentation/admin-guide/bug-hunting.rst
>
>   - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
> as is, otherwise you will have to use the ``ksymoops`` program to make
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 05496622b4ef..e857bbbc8575 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2248,7 +2248,7 @@
> s2idle  - Suspend-To-Idle
>

Re: [PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum

[Andrey Utkin]

On Mon, Oct 09, 2017 at 07:19:11AM -0300, Mauro Carvalho Chehab wrote:
> Using enums makes easier to document, as it can use kernel-doc
> markups. It also allows cross-referencing, with increases the
> kAPI readability.
> 


All changes look legit.

But I'd expect cx88_querycap() return type change and such to be in
separate commit.

> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c 
> b/drivers/media/pci/cx88/cx88-blackbird.c
> index e3101f04941c..0e0952e60795 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
>  
>   strcpy(cap->driver, "cx88_blackbird");
>   sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
>  }
>  
>  static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
> diff --git a/drivers/media/pci/cx88/cx88-video.c 
> b/drivers/media/pci/cx88/cx88-video.c
> index 7d25ecd4404b..9be682cdb644 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
> *priv,
>   return 0;
>  }
>  
> -void cx88_querycap(struct file *file, struct cx88_core *core,
> -struct v4l2_capability *cap)
> +int cx88_querycap(struct file *file, struct cx88_core *core,
> +   struct v4l2_capability *cap)
>  {
>   struct video_device *vdev = video_devdata(file);
>  

Re: IMX CSI max pixel rate

[Tim Harvey]

On Fri, Oct 6, 2017 at 3:14 AM, Philipp Zabel  wrote:
>
> On Fri, 2017-10-06 at 10:49 +0300, Sakari Ailus wrote:
> > On Thu, Oct 05, 2017 at 10:21:16AM -0700, Tim Harvey wrote:
> > > Greetings,
> > >
> > > I'm working on a HDMI receiver driver for the TDA1997x
> > > (https://lwn.net/Articles/734692/) and wanted to throw an error if
> > > the
> > > detected input resolution/vidout-output-bus-format exceeded the max
> > > pixel rate of the SoC capture bus the chip connects to (in my case
> > > is
> > > the IMX6 CSI which has a limit of 180MP/sec).
>
> Where does this number come from? I see there are 180 MP/s advertised
> for burst mode still image capture (with up to 35% blanking overhead) in
> the i.MX6Q reference manual. For continuous still image capture, only
> 160 MP/s are advertised. The CSI really supports up to about 240 MHz
> pixel clock (assuming the IPU is clocked at 264 MHz), so MP/s for video
> really depends a lot on the blanking.

I got the number from the ref manual section 9.2.1.1 Camera ports which says:

The input rate supported by the camera port is as follows:
 - Peak: up to 240 MHz (values/sec)
 - Average (assuming 35% blanking overhead), for YUV 4:2:2
   - Pixel in one cycle (e.g. BT.1120): up to 180 MP/sec, e.g. 12M
pixels @ 15 fps
   - Pixel on two cycles (e.g. BT.656): up to 90 MP/sec, e.g. 6M
pixels @ 15 fps.
 - On-the-fly processing may be restricted to a lower input rate - see below.

I would agree that it appears 240MHz is the important limit here and
I'm not clear how they get 180/90 MP/sec from this assuming 35%
blanking - seems to me that should be 156MP/sec or 180MP/sec with 25%
blanking for single-cycle max.

The only place I've run into this is the 2-cycle BT656 case where
1080p@60 would exceed the input rate
(1920*1080*60fps*2cycles=248.8MHz).

Tim

[PATCH 5/8] Documentation: fix media related doc refs

[Tom Saeger]

Make media doc refs valid.

Signed-off-by: Tom Saeger 
---
 Documentation/admin-guide/kernel-parameters.txt| 4 ++--
 Documentation/media/dvb-drivers/bt8xx.rst  | 8 
 Documentation/media/uapi/v4l/dev-sliced-vbi.rst| 2 +-
 Documentation/media/uapi/v4l/extended-controls.rst | 2 +-
 Documentation/media/uapi/v4l/pixfmt-reserved.rst   | 2 +-
 Documentation/media/v4l-drivers/max2175.rst| 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 411b41127eee..cbfae6b1c644 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -439,7 +439,7 @@
bttv.card=  [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
-   bttv.pll=   See Documentation/video4linux/bttv/Insmod-options
+   bttv.pll=   See Documentation/media/v4l-drivers/bttv.rst
bttv.tuner=
 
bulk_remove=off [PPC]  This parameter disables the use of the pSeries
@@ -2251,7 +2251,7 @@
See Documentation/admin-guide/pm/sleep-states.rst.
 
meye.*= [HW] Set MotionEye Camera parameters
-   See Documentation/video4linux/meye.txt.
+   See Documentation/media/v4l-drivers/meye.rst.
 
mfgpt_irq=  [IA-32] Specify the IRQ to use for the
Multi-Function General Purpose Timers on AMD Geode
diff --git a/Documentation/media/dvb-drivers/bt8xx.rst 
b/Documentation/media/dvb-drivers/bt8xx.rst
index b43958b7340c..e3e387bdf498 100644
--- a/Documentation/media/dvb-drivers/bt8xx.rst
+++ b/Documentation/media/dvb-drivers/bt8xx.rst
@@ -18,7 +18,7 @@ General information
 
 This class of cards has a bt878a as the PCI interface, and require the bttv 
driver
 for accessing the i2c bus and the gpio pins of the bt8xx chipset.
-Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx 
PCI bridge:
+Please see Documentation/media/dvb-drivers/cards.rst => o Cards based on the 
Conexant Bt8xx PCI bridge:
 
 Compiling kernel please enable:
 
@@ -45,7 +45,7 @@ Loading Modules
 Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend 
and backend modules will be loaded automatically.
 Exceptions are:
 - Old TwinHan DST cards or clones with or without CA slot and not containing 
an Eeprom.
-People running udev please see Documentation/dvb/udev.txt.
+People running udev please see Documentation/media/dvb-drivers/udev.rst.
 
 In the following cases overriding the PCI type detection for dvb-bt8xx might 
be necessary:
 
@@ -72,7 +72,7 @@ Useful parameters for verbosity level and debugging the dst 
module:
 The autodetected values are determined by the cards' "response string".
 In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
 For bug reports please send in a complete log with verbose=4 activated.
-Please also see Documentation/dvb/ci.txt.
+Please also see Documentation/media/dvb-drivers/ci.rst.
 
 Running multiple cards
 ~~
@@ -100,7 +100,7 @@ Examples of card ID's:
 
$ modprobe bttv card=113 card=135
 
-For a full list of card ID's please see 
Documentation/video4linux/CARDLIST.bttv.
+For a full list of card ID's please see 
Documentation/media/v4l-drivers/bttv-cardlist.rst.
 In case of further problems please subscribe and send questions to the mailing 
list: linux-...@linuxtv.org.
 
 Probing the cards with broken PCI subsystem ID
diff --git a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst 
b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
index 9d6c860271cb..d311a6866b3b 100644
--- a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
@@ -431,7 +431,7 @@ MPEG stream.
 *Historical context*: This format specification originates from a
 custom, embedded, sliced VBI data format used by the ``ivtv`` driver.
 This format has already been informally specified in the kernel sources
-in the file ``Documentation/video4linux/cx2341x/README.vbi`` . The
+in the file ``Documentation/media/v4l-drivers/cx2341x.rst`` . The
 maximum size of the payload and other aspects of this format are driven
 by the CX23415 MPEG decoder's capabilities and limitations with respect
 to extracting, decoding, and displaying sliced VBI data embedded within
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index a3e81c1d276b..dfe49ae57e78 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -284,7 +284,7 @@ enum v4l2_mpeg_stream_vbi_fmt -
 * - ``V4L2_MPEG_STREAM_VBI_FMT_IVTV``
   - VBI in private packets, IVTV format (documented in the kernel
sources in the 

[PATCH 2/8] Documentation: fix admin-guide doc refs

[Tom Saeger]

Make admin-guide document refs valid.

Signed-off-by: Tom Saeger 
---
 Documentation/ABI/stable/sysfs-devices | 2 +-
 Documentation/ABI/testing/sysfs-devices-system-cpu | 6 --
 Documentation/ABI/testing/sysfs-power  | 6 --
 Documentation/admin-guide/README.rst   | 2 +-
 Documentation/admin-guide/kernel-parameters.txt| 4 ++--
 Documentation/admin-guide/reporting-bugs.rst   | 4 ++--
 Documentation/laptops/laptop-mode.txt  | 6 +++---
 Documentation/media/v4l-drivers/bttv.rst   | 2 +-
 Documentation/power/interface.txt  | 3 ++-
 9 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-devices 
b/Documentation/ABI/stable/sysfs-devices
index 35c457f8ce73..4404bd9b96c1 100644
--- a/Documentation/ABI/stable/sysfs-devices
+++ b/Documentation/ABI/stable/sysfs-devices
@@ -1,5 +1,5 @@
 # Note: This documents additional properties of any device beyond what
-# is documented in Documentation/sysfs-rules.txt
+# is documented in Documentation/admin-guide/sysfs-rules.rst
 
 What:  /sys/devices/*/of_node
 Date:  February 2015
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index f3d5817c4ef0..d6d862db3b5d 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -187,7 +187,8 @@ Description:Processor frequency boosting control
This switch controls the boost setting for the whole system.
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
-   More details can be found in Documentation/cpu-freq/boost.txt
+   More details can be found in
+   Documentation/admin-guide/pm/cpufreq.rst
 
 
 What:  /sys/devices/system/cpu/cpu#/crash_notes
@@ -223,7 +224,8 @@ Description:Parameters for the Intel P-state driver
no_turbo: limits the driver to selecting P states below the 
turbo
frequency range.
 
-   More details can be found in 
Documentation/cpu-freq/intel-pstate.txt
+   More details can be found in
+   Documentation/admin-guide/pm/intel_pstate.rst
 
 What:  
/sys/devices/system/cpu/cpu*/cache/index*/
 Date:  July 2014(documented, existed before August 2008)
diff --git a/Documentation/ABI/testing/sysfs-power 
b/Documentation/ABI/testing/sysfs-power
index a1d1612f3651..1e0d1dac706b 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -18,7 +18,8 @@ Description:
Writing one of the above strings to this file causes the system
to transition into the corresponding state, if available.
 
-   See Documentation/power/states.txt for more information.
+   See Documentation/admin-guide/pm/sleep-states.rst for more
+   information.
 
 What:  /sys/power/mem_sleep
 Date:  November 2016
@@ -35,7 +36,8 @@ Description:
represented by it to be used on subsequent attempts to suspend
the system.
 
-   See Documentation/power/states.txt for more information.
+   See Documentation/admin-guide/pm/sleep-states.rst for more
+   information.
 
 What:  /sys/power/disk
 Date:  September 2006
diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index b5343c5aa224..63066db39910 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -350,7 +350,7 @@ If something goes wrong
help debugging the problem.  The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example, it's due to a bad kernel pointer). More information
-   on making sense of the dump is in Documentation/admin-guide/oops-tracing.rst
+   on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst
 
  - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the ``ksymoops`` program to make
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 05496622b4ef..e857bbbc8575 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2248,7 +2248,7 @@
s2idle  - Suspend-To-Idle
shallow - Power-On Suspend or equivalent (if supported)
deep- Suspend-To-RAM or equivalent (if supported)
-   See Documentation/power/states.txt.
+   See Documentation/admin-guide/pm/sleep-states.rst.
 
meye.*= [HW] Set MotionEye Camera 

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

[Nicolas Dufresne]

Le mardi 29 août 2017 à 14:26 +0300, Stanimir Varbanov a écrit :
> Currently videobuf2-dma-sg checks for dma direction for
> every single page and videobuf2-dc lacks any dma direction
> checks and calls set_page_dirty_lock unconditionally.
> 
> Thus unify and align the invocations of set_page_dirty_lock
> for videobuf2-dc, videobuf2-sg  memory allocators with
> videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
> copied to dc and dma-sg.

Just before we go too far in "doing like vmalloc", I would like to
share this small video that display coherency issues when rendering
vmalloc backed DMABuf over various KMS/DRM driver. I can reproduce this
easily with Intel and MSM display drivers using UVC or Vivid as source.

The following is an HDMI capture of the following GStreamer pipeline
running on Dragonboard 410c.

gst-launch-1.0 -v v4l2src device=/dev/video2 ! 
video/x-raw,format=NV16,width=1280,height=720 ! kmssink
https://people.collabora.com/~nicolas/vmalloc-issue.mov

Feedback on this issue would be more then welcome. It's not clear to me
who's bug is this (v4l2, drm or iommu). The software is unlikely to be
blamed as this same pipeline works fine with non-vmalloc based sources.

regards,
Nicolas

> 
> Suggested-by: Marek Szyprowski 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 --
>  drivers/media/v4l2-core/videobuf2-dma-sg.c | 7 +++
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 9f389f36566d..696e24f9128d 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -434,8 +434,10 @@ static void vb2_dc_put_userptr(void *buf_priv)
>   pages = frame_vector_pages(buf->vec);
>   /* sgt should exist only if vector contains pages... */
>   BUG_ON(IS_ERR(pages));
> - for (i = 0; i < frame_vector_count(buf->vec); i++)
> - set_page_dirty_lock(pages[i]);
> + if (buf->dma_dir == DMA_FROM_DEVICE ||
> + buf->dma_dir == DMA_BIDIRECTIONAL)
> + for (i = 0; i < frame_vector_count(buf->vec); i++)
> + set_page_dirty_lock(pages[i]);
>   sg_free_table(sgt);
>   kfree(sgt);
>   }
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> index 6808231a6bdc..753ed3138dcc 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> @@ -292,11 +292,10 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
>   if (buf->vaddr)
>   vm_unmap_ram(buf->vaddr, buf->num_pages);
>   sg_free_table(buf->dma_sgt);
> - while (--i >= 0) {
> - if (buf->dma_dir == DMA_FROM_DEVICE ||
> - buf->dma_dir == DMA_BIDIRECTIONAL)
> + if (buf->dma_dir == DMA_FROM_DEVICE ||
> + buf->dma_dir == DMA_BIDIRECTIONAL)
> + while (--i >= 0)
>   set_page_dirty_lock(buf->pages[i]);
> - }
>   vb2_destroy_framevec(buf->vec);
>   kfree(buf);
>  }

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v8 4/7] media: open.rst: document vdevnode-centric and mc-centric types

[Hans Verkuil]

More word-smithing...

On 10/10/2017 01:45 PM, Mauro Carvalho Chehab wrote:
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node.
> 
> Yet, we have never clearly documented in the V4L2 specification
> the differences between the two types.
> 
> Let's document them based on the the current implementation.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst | 55 
> +++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index 46ef63e05696..1a8a9e1d0e84 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -7,6 +7,61 @@ Opening and Closing Devices
>  ***
>  
>  
> +.. _v4l2_hardware_control:
> +
> +
> +Types of V4L2 media hardware control
> +
> +
> +A :term:`V4L2 hardware` is usually complex: support for it is

No 'A '.

> +implemented via a :term:`V4L2 main driver` and often by several

I prefer 'by' instead of 'via'.

> +additional :term:`drivers `.
> +The main driver always exposes one or more
> +:term:`V4L2 device nodes `
> +(see :ref:`v4l2_device_naming`) with are responsible for implementing

with -> which

> +data streaming, if applicable.
> +
> +The other drivers are called :term:`V4L2 sub-devices `

I'd say "V4L2 sub-device drivers"

> +and provide control to other
> +:term:`hardware components ` are usually connected

:term:`hardware components `. Those component are usually 
controlled

> +via a serial bus (like :term:`I²C`, :term:`SMBus` or :term:`SPI`).
> +Depending on the main driver, they can be implicitly
> +controlled directly by the main driver or explicitly via
> +the V4L2 sub-device API (see :ref:`subdev`).
> +
> +When **V4L2** was originally designed, the
> +:term:`V4L2 device nodes ` served the purpose of both
> +control and data interfaces and there was no separation
> +between the two interface-wise. V4L2 controls, setting inputs and outputs,

Instead of 'interface-wise' I'd use 'API-wise'. That reminds me: should we add
'API' to the glossary as well? (Can be done later)

> +format configuration and buffer related operations were all performed
> +through the same **V4L2 device nodes**. Devices offering such interface are
> +called **V4L2 device node centric**.
> +
> +Later on, support for the :term:`media controller` interface was added
> +to V4L2 in order to better support complex :term:`V4L2 hardware` where the
> +**V4L2** interface alone could no longer meaningfully serve as both a
> +control and a data interface. On such V4L2 hardware, **V4L2** interface

**V4L2** -> the **V4L2**

> +remains a data interface whereas control takes place through the
> +:term:`media controller` and :term:`V4L2 sub-device` interfaces. Stream
> +control is an exception to this: streaming is enabled and disabled
> +through the **V4L2** interface. These devices are called
> +**Media controller centric**.
> +
> +**MC-centric** V4L2 hardware provide more versatile control of the

provide -> provides

> +hardware than **V4L2 device node centric** devices at the expense of
> +requiring device-specific userspace settings.
> +
> +On **MC-centric** V4L2 hardware, the **V4L2 sub-device nodes**
> +represent specific parts of the V4L2 hardware, to which they enable
> +control.

I'd rephrase this:

On **MC-centric** V4L2 hardware, the **V4L2 sub-device nodes**
provide control of the specific part of the V4L2 hardware represented
by each node.

> +
> +Also, the additional versatility of **MC-centric** V4L2 hardware comes
> +with additional responsibilities, the main one of which is the requirements

...of which the main one is the requirement...

> +of the user configuring the device pipeline before starting streaming. This
> +typically involves configuring the links using the **Media controller**
> +interface and the media bus formats on pads (at both ends of the links)
> +using the **V4L2 sub-device** interface.
> +
>  .. _v4l2_device_naming:
>  
>  V4L2 Device Node Naming
> 

Regards,

Hans

Re: [PATCH v15 04/32] v4l: async: Fix notifier complete callback error handling

[Sakari Ailus]

Hi Hans,

On Tue, Oct 10, 2017 at 03:18:13PM +0200, Hans Verkuil wrote:
> On 10/10/2017 02:57 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Mon, Oct 09, 2017 at 01:45:25PM +0200, Hans Verkuil wrote:
> >> On 04/10/17 23:50, Sakari Ailus wrote:
> >>> The notifier complete callback may return an error. This error code was
> >>> simply returned to the caller but never handled properly.
> >>>
> >>> Move calling the complete callback function to the caller from
> >>> v4l2_async_test_notify and undo the work that was done either in async
> >>> sub-device or async notifier registration.
> >>>
> >>> Reported-by: Russell King 
> >>> Signed-off-by: Sakari Ailus 
> >>> ---
> >>>  drivers/media/v4l2-core/v4l2-async.c | 78 
> >>> +++-
> >>>  1 file changed, 60 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> >>> b/drivers/media/v4l2-core/v4l2-async.c
> >>> index ca281438a0ae..4924481451ca 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-async.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >>> @@ -122,9 +122,6 @@ static int v4l2_async_test_notify(struct 
> >>> v4l2_async_notifier *notifier,
> >>>   /* Move from the global subdevice list to notifier's done */
> >>>   list_move(>async_list, >done);
> >>>  
> >>> - if (list_empty(>waiting) && notifier->complete)
> >>> - return notifier->complete(notifier);
> >>> -
> >>>   return 0;
> >>>  }
> >>>  
> >>> @@ -136,11 +133,27 @@ static void v4l2_async_cleanup(struct v4l2_subdev 
> >>> *sd)
> >>>   sd->asd = NULL;
> >>>  }
> >>>  
> >>> +static void v4l2_async_notifier_unbind_all_subdevs(
> >>> + struct v4l2_async_notifier *notifier)
> >>> +{
> >>> + struct v4l2_subdev *sd, *tmp;
> >>> +
> >>> + list_for_each_entry_safe(sd, tmp, >done, async_list) {
> >>> + if (notifier->unbind)
> >>> + notifier->unbind(notifier, sd, sd->asd);
> >>> +
> >>> + v4l2_async_cleanup(sd);
> >>> +
> >>> + list_move(>async_list, _list);
> >>> + }
> >>> +}
> >>> +
> >>>  int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> >>>struct v4l2_async_notifier *notifier)
> >>>  {
> >>>   struct v4l2_subdev *sd, *tmp;
> >>>   struct v4l2_async_subdev *asd;
> >>> + int ret;
> >>>   int i;
> >>>  
> >>>   if (!v4l2_dev || !notifier->num_subdevs ||
> >>> @@ -185,19 +198,30 @@ int v4l2_async_notifier_register(struct v4l2_device 
> >>> *v4l2_dev,
> >>>   }
> >>>   }
> >>>  
> >>> + if (list_empty(>waiting) && notifier->complete) {
> >>> + ret = notifier->complete(notifier);
> >>> + if (ret)
> >>> + goto err_complete;
> >>> + }
> >>> +
> >>>   /* Keep also completed notifiers on the list */
> >>>   list_add(>list, _list);
> >>>  
> >>>   mutex_unlock(_lock);
> >>>  
> >>>   return 0;
> >>> +
> >>> +err_complete:
> >>> + v4l2_async_notifier_unbind_all_subdevs(notifier);
> >>> +
> >>> + mutex_unlock(_lock);
> >>> +
> >>> + return ret;
> >>>  }
> >>>  EXPORT_SYMBOL(v4l2_async_notifier_register);
> >>>  
> >>>  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> >>>  {
> >>> - struct v4l2_subdev *sd, *tmp;
> >>> -
> >>>   if (!notifier->v4l2_dev)
> >>>   return;
> >>>  
> >>> @@ -205,14 +229,7 @@ void v4l2_async_notifier_unregister(struct 
> >>> v4l2_async_notifier *notifier)
> >>>  
> >>>   list_del(>list);
> >>>  
> >>> - list_for_each_entry_safe(sd, tmp, >done, async_list) {
> >>> - if (notifier->unbind)
> >>> - notifier->unbind(notifier, sd, sd->asd);
> >>> -
> >>> - v4l2_async_cleanup(sd);
> >>> -
> >>> - list_move(>async_list, _list);
> >>> - }
> >>> + v4l2_async_notifier_unbind_all_subdevs(notifier);
> >>>  
> >>>   mutex_unlock(_lock);
> >>>  
> >>> @@ -223,6 +240,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
> >>>  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
> >>>  {
> >>>   struct v4l2_async_notifier *notifier;
> >>> + int ret;
> >>>  
> >>>   /*
> >>>* No reference taken. The reference is held by the device
> >>> @@ -238,19 +256,43 @@ int v4l2_async_register_subdev(struct v4l2_subdev 
> >>> *sd)
> >>>  
> >>>   list_for_each_entry(notifier, _list, list) {
> >>>   struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
> >>> sd);
> >>> - if (asd) {
> >>> - int ret = v4l2_async_test_notify(notifier, sd, asd);
> >>> - mutex_unlock(_lock);
> >>> - return ret;
> >>> - }
> >>> + int ret;
> >>> +
> >>> + if (!asd)
> >>> + continue;
> >>> +
> >>> + ret = v4l2_async_test_notify(notifier, sd, asd);
> >>> + if (ret)
> >>> + goto err_unlock;
> >>> +
> >>> + if (!list_empty(>waiting) || !notifier->complete)
> >>> + goto out_unlock;
> >>> +
> >>> + ret = notifier->complete(notifier);
> >>> +

Re: [PATCH 18/24] media: vb2-core: use bitops for bits

[Sakari Ailus]

On Mon, Oct 09, 2017 at 07:19:24AM -0300, Mauro Carvalho Chehab wrote:
> Use the existing macros to identify vb2_io_modes bits.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v8 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Hans Verkuil]

More (mostly) small stuff:

On 10/10/2017 01:45 PM, Mauro Carvalho Chehab wrote:
> Add a glossary of terms for V4L2, as several concepts are complex
> enough to cause misunderstandings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/glossary.rst | 167 
> ++
>  Documentation/media/uapi/v4l/v4l2.rst |   1 +
>  2 files changed, 168 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> 
> diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> b/Documentation/media/uapi/v4l/glossary.rst
> new file mode 100644
> index ..a5a832b4dda5
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/glossary.rst
> @@ -0,0 +1,167 @@
> +
> +Glossary
> +
> +
> +.. note::
> +
> +   This goal of section is to standardize the terms used within the V4L2
> +   documentation. It is written incrementally as they are standardized in
> +   the V4L2 documentation. So, it is a Work In Progress.
> +
> +.. Please keep the glossary entries in alphabetical order
> +
> +.. glossary::
> +
> +Bridge driver
> + A driver that provides a bridge between the CPU's bus to the
> + data and control buses of a :term:`media hardware`. Often, the
> + bridge driver is the same as :term:`V4L2 main driver`.
> +
> +Chip
> + :See: :term:`Integrated circuit`.
> +
> +Device Driver
> +Driver
> + The part of the Linux Kernel that implements support
> + for a :term:`hardware component`.
> +
> +Device Node
> + A character device node in the file system used to control and/or
> + do input/output data transfers from/to a Kernel driver.
> +
> +Digital Signal Processor
> +DSP
> + A specialized :term:`microprocessor`, with its architecture optimized
> + for the operational requirements of digital signal processing.
> +
> +Field-programmable Gate Array
> +FPGA
> + A field-programmable gate array (FPGA) is an :term:`integrated circuit`
> + designed to be configured by a customer or a designer after
> + manufacturing.
> +
> + :See: https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> +
> +Hardware component
> + A subset of the :term:`media hardware`. For example an :term:`I²C`
> + or :term:`SPI` device, or an :term:`IP block` inside an
> + :term:`SoC` or :term:`FPGA`.
> +
> +Image Signal Processor
> +ISP
> + A specialized :term:`microprocessor` that implements a set of
> + algorithms for processing image data. ISPs may implement algorithms
> + for lens shading correction, demosaic, scaling and pixel format
> + conversion as well as produce statistics for the use of the control
> + algorithms (e.g. automatic exposure, white balance and focus).
> +
> + ISP drivers often contain a receiver for image data from external
> + sources such as sensors and act as :term:`V4L2 main driver`.
> +
> +Integrated circuit
> +IC
> + A set of electronic circuits on one small flat piece of
> + semiconductor material, normally silicon.
> +
> + Also known as :term:`chip`.
> +
> +Intellectual property core
> +IP core
> + In electronic design a semiconductor intellectual property core,
> + is a reusable unit of logic, cell, or integrated circuit layout
> + design that is the intellectual property of one party.
> + IP cores may be licensed to another party or can be owned
> + and used by a single party alone.
> +
> + :See: 
> https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> +
> +Inter-Integrated Circuit
> +I²C
> + A  multi-master, multi-slave, packet switched, single-ended,
> + serial computer bus. A :term:`V4L2 sub-device driver` usually is
> + controlled via this bus.
> +
> + :See: http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> +
> +IP block
> + :See: :term:`IP core`.
> +
> +Media controller
> +MC
> + An API designed to expose and control the relationships of the
> + :term:`media hardware` to applications.
> +
> + :See: :ref:`media_controller`.
> +
> +Media controller centric
> +MC-centric
> + :term:`V4L2 hardware` that requires a :term:`media controller`.
> +
> + :See: :ref:`v4l2_hardware_control`.
> +
> +Media hardware
> + A group of hardware components that together form the
> + functional media hardware. For instance the :term:`SoC`
> + :term:`ISP` :term:`IP cores ` and external camera
> + sensors together form the camera media hardware.

Perhaps this is a bit better:

...form the media hardware for a camera.

> +
> +Media hardware control
> + Type of control for a :term:`media hardware` supported a

for a -> for
supported -> supported by

> + V4L2 :term:`driver`.
> +
> + :See: :ref:`v4l2_hardware_control`.

Do we actually need this term in the glossary? I'm not convinced. We will
typically talk about 

Re: [PATCH 22/24] media: vb2: add cross references at memops and v4l2 kernel-doc markups

[Sakari Ailus]

On Mon, Oct 09, 2017 at 07:19:28AM -0300, Mauro Carvalho Chehab wrote:
> Add cross-references where needed and add periods at the end of
> each kernel-doc paragraph, in order to make it coherent with other
> VB2 descriptions.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 21/24] media: vb2-core: fix descriptions for VB2-only functions

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 07:19:27AM -0300, Mauro Carvalho Chehab wrote:
> When we split VB2 into an independent streaming module and
> a V4L2 one, some vb2-core functions started to have a wrong
> description: they're meant to be used only by the API-specific
> parts of VB2, like vb2-v4l2, as the functions that V4L2 drivers
> should use are all under videobuf2-v4l2.h.
> 
> Correct their descriptions.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/videobuf2-core.h | 86 
> ++
>  1 file changed, 46 insertions(+), 40 deletions(-)
> 
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index ce795cd0a7cc..3165f0f9a85f 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -651,12 +651,14 @@ int vb2_wait_for_all_buffers(struct vb2_queue *q);
>   * @index:   id number of the buffer.
>   * @pb:  buffer struct passed from userspace.
>   *
> - * Should be called from _ioctl_ops->vidioc_querybuf ioctl handler
> - * in driver.
> + * Videbuf2 core helper to implement QUERYBUF operation. It is called

"Videobuf2" and "VIDIOC_" prefix for IOCTL commands. With this and the ones
below fixed,

Acked-by: Sakari Ailus 

> + * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
>   *
>   * The passed buffer should have been verified.
>   *
>   * This function fills the relevant information for the userspace.
> + *
> + * Return: returns zero on success; an error code otherwise.
>   */
>  void vb2_core_querybuf(struct vb2_queue *q, unsigned int index, void *pb);
>  
> @@ -666,27 +668,26 @@ void vb2_core_querybuf(struct vb2_queue *q, unsigned 
> int index, void *pb);
>   * @memory:  memory type, as defined by  vb2_memory.
>   * @count:   requested buffer count.
>   *
> - * Should be called from _ioctl_ops->vidioc_reqbufs ioctl
> - * handler of a driver.
> + * Videbuf2 core helper to implement REQBUF operation. It is called

Ditto.

> + * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
>   *
>   * This function:
>   *
> - * #) verifies streaming parameters passed from the userspace,
> - * #) sets up the queue,
> + * #) verifies streaming parameters passed from the userspace;
> + * #) sets up the queue;
>   * #) negotiates number of buffers and planes per buffer with the driver
> - *to be used during streaming,
> + *to be used during streaming;
>   * #) allocates internal buffer structures ( vb2_buffer), according to
> - *the agreed parameters,
> + *the agreed parameters;
>   * #) for MMAP memory type, allocates actual video memory, using the
> - *memory handling/allocation routines provided during queue 
> initialization
> + *memory handling/allocation routines provided during queue 
> initialization.
>   *
>   * If req->count is 0, all the memory will be freed instead.
>   *
>   * If the queue has been allocated previously by a previous 
> vb2_core_reqbufs()
>   * call and the queue is not busy, memory will be reallocated.
>   *
> - * The return values from this function are intended to be directly returned
> - * from _ioctl_ops->vidioc_reqbufs handler in driver.
> + * Return: returns zero on success; an error code otherwise.
>   */
>  int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>   unsigned int *count);
> @@ -699,17 +700,16 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   * @requested_planes: number of planes requested.
>   * @requested_sizes: array with the size of the planes.
>   *
> - * Should be called from _ioctl_ops->vidioc_create_bufs ioctl handler
> - * of a driver.
> + * Videbuf2 core helper to implement CREATE_BUFS operation. It is called

Ditto.

> + * internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
>   *
>   * This function:
>   *
> - * #) verifies parameter sanity
> - * #) calls the _ops->queue_setup queue operation
> - * #) performs any necessary memory allocations
> + * #) verifies parameter sanity;
> + * #) calls the _ops->queue_setup queue operation;
> + * #) performs any necessary memory allocations.
>   *
> - * Return: the return values from this function are intended to be directly
> - * returned from _ioctl_ops->vidioc_create_bufs handler in driver.
> + * Return: returns zero on success; an error code otherwise.
>   */
>  int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
>unsigned int *count, unsigned int requested_planes,
> @@ -723,16 +723,16 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   * @pb:  buffer structure passed from userspace to
>   *   _ioctl_ops->vidioc_prepare_buf handler in driver.
>   *
> - * Should be called from _ioctl_ops->vidioc_prepare_buf ioctl handler
> - * of a driver.
> + * Videbuf2 core helper to implement PREPARE_BUF operation. It is 

[PATCH] dtv-scan-tables: Elisa cable-tv (PKS+Riihimäki)

[Heikki Kantola]

Attached is the DVB-C tuning information for Elisa cable-TV in Finnish
capital region and Riihimäki.

-- 
Heikki Kantola 


fi-Elisa-PKS
Description: Binary data

Re: [PATCH 19/24] media: vb2-core: Improve kernel-doc markups

[Sakari Ailus]

Hi Mauro,

On Mon, Oct 09, 2017 at 07:19:25AM -0300, Mauro Carvalho Chehab wrote:
> There are several issues on the current markups:
> - lack of cross-references;
> - wrong cross-references;
> - lack of a period of the end of several phrases;
> - Some descriptions can be enhanced.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/videobuf2-core.h | 376 
> ++---
>  1 file changed, 204 insertions(+), 172 deletions(-)
> 
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 0308d8439049..e145f1475ffe 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h

...

>  /**
>   * vb2_core_queue_init() - initialize a videobuf2 queue
> - * @q:   videobuf2 queue; this structure should be allocated in 
> driver
> + * @q:   pointer to  vb2_queue with videobuf2 queue.
> + *   This structure should be allocated in driver
>   *
>   * The _queue structure should be allocated by the driver. The driver is
>   * responsible of clearing it's content and setting initial values for some
>   * required entries before calling this function.
> - * q->ops, q->mem_ops, q->type and q->io_modes are mandatory. Please refer
> - * to the struct vb2_queue description in include/media/videobuf2-core.h
> - * for more information.
> + *
> + * .. note::
> + *
> + *The following fields at @q should be set before calling this function:

should -> shall

I bet there's a lot of that in the documentation elsewhere, including this
patch.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH v2] Staging: bcm2048 fix bare use of 'unsigned' in radio-bcm2048.c

[Branislav Radocaj]

This is a patch to the radio-bcm2048.c file that fixes up
a warning found by the checkpatch.pl tool.

Signed-off-by: Branislav Radocaj 

---
[1]: https://marc.info/?l=linux-driver-devel=150331308401055=2

Changes in v2:

Removed unused 'size' argument from property_read macro.
In property_write macro, 'signal, size' is replaced by 'prop_type'.
This change implies the update of DEFINE_SYSFS_PROPERTY macro
and all places of its usage as well.
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 60 +--
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 58adaea44eb5..5d3b0e5a1283 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1964,7 +1964,7 @@ static ssize_t bcm2048_##prop##_write(struct device *dev, 
\
return err < 0 ? err : count;   \
 }
 
-#define property_read(prop, size, mask)
\
+#define property_read(prop, mask)  \
 static ssize_t bcm2048_##prop##_read(struct device *dev,   \
struct device_attribute *attr,  \
char *buf)  \
@@ -1999,9 +1999,9 @@ static ssize_t bcm2048_##prop##_read(struct device *dev,  
\
return sprintf(buf, mask "\n", value);  \
 }
 
-#define DEFINE_SYSFS_PROPERTY(prop, signal, size, mask, check) \
-property_write(prop, signal size, mask, check) \
-property_read(prop, size, mask)
+#define DEFINE_SYSFS_PROPERTY(prop, prop_type, mask, check)\
+property_write(prop, prop_type, mask, check)   \
+property_read(prop, mask)  \
 
 #define property_str_read(prop, size)  \
 static ssize_t bcm2048_##prop##_read(struct device *dev,   \
@@ -2027,39 +2027,39 @@ static ssize_t bcm2048_##prop##_read(struct device 
*dev,\
return count;   \
 }
 
-DEFINE_SYSFS_PROPERTY(power_state, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(mute, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(audio_route, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(dac_output, unsigned, int, "%u", 0)
-
-DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned, int, "%u", value > 3)
-
-DEFINE_SYSFS_PROPERTY(rds, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_wline, unsigned, int, "%u", 0)
-property_read(rds_pi, unsigned int, "%x")
+DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(mute, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, "%u", 0)
+
+DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, "%u", value > 3)
+
+DEFINE_SYSFS_PROPERTY(rds, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, "%u", 0)
+property_read(rds_pi, "%x")
 property_str_read(rds_rt, (BCM2048_MAX_RDS_RT + 1))
 property_str_read(rds_ps, (BCM2048_MAX_RDS_PS + 1))
 
-property_read(fm_rds_flags, unsigned int, "%u")
+property_read(fm_rds_flags, "%u")
 property_str_read(rds_data, 

Re: [PATCH v15 04/32] v4l: async: Fix notifier complete callback error handling

[Hans Verkuil]

On 10/10/2017 02:57 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Mon, Oct 09, 2017 at 01:45:25PM +0200, Hans Verkuil wrote:
>> On 04/10/17 23:50, Sakari Ailus wrote:
>>> The notifier complete callback may return an error. This error code was
>>> simply returned to the caller but never handled properly.
>>>
>>> Move calling the complete callback function to the caller from
>>> v4l2_async_test_notify and undo the work that was done either in async
>>> sub-device or async notifier registration.
>>>
>>> Reported-by: Russell King 
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-async.c | 78 
>>> +++-
>>>  1 file changed, 60 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
>>> b/drivers/media/v4l2-core/v4l2-async.c
>>> index ca281438a0ae..4924481451ca 100644
>>> --- a/drivers/media/v4l2-core/v4l2-async.c
>>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>>> @@ -122,9 +122,6 @@ static int v4l2_async_test_notify(struct 
>>> v4l2_async_notifier *notifier,
>>> /* Move from the global subdevice list to notifier's done */
>>> list_move(>async_list, >done);
>>>  
>>> -   if (list_empty(>waiting) && notifier->complete)
>>> -   return notifier->complete(notifier);
>>> -
>>> return 0;
>>>  }
>>>  
>>> @@ -136,11 +133,27 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
>>> sd->asd = NULL;
>>>  }
>>>  
>>> +static void v4l2_async_notifier_unbind_all_subdevs(
>>> +   struct v4l2_async_notifier *notifier)
>>> +{
>>> +   struct v4l2_subdev *sd, *tmp;
>>> +
>>> +   list_for_each_entry_safe(sd, tmp, >done, async_list) {
>>> +   if (notifier->unbind)
>>> +   notifier->unbind(notifier, sd, sd->asd);
>>> +
>>> +   v4l2_async_cleanup(sd);
>>> +
>>> +   list_move(>async_list, _list);
>>> +   }
>>> +}
>>> +
>>>  int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
>>>  struct v4l2_async_notifier *notifier)
>>>  {
>>> struct v4l2_subdev *sd, *tmp;
>>> struct v4l2_async_subdev *asd;
>>> +   int ret;
>>> int i;
>>>  
>>> if (!v4l2_dev || !notifier->num_subdevs ||
>>> @@ -185,19 +198,30 @@ int v4l2_async_notifier_register(struct v4l2_device 
>>> *v4l2_dev,
>>> }
>>> }
>>>  
>>> +   if (list_empty(>waiting) && notifier->complete) {
>>> +   ret = notifier->complete(notifier);
>>> +   if (ret)
>>> +   goto err_complete;
>>> +   }
>>> +
>>> /* Keep also completed notifiers on the list */
>>> list_add(>list, _list);
>>>  
>>> mutex_unlock(_lock);
>>>  
>>> return 0;
>>> +
>>> +err_complete:
>>> +   v4l2_async_notifier_unbind_all_subdevs(notifier);
>>> +
>>> +   mutex_unlock(_lock);
>>> +
>>> +   return ret;
>>>  }
>>>  EXPORT_SYMBOL(v4l2_async_notifier_register);
>>>  
>>>  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>>>  {
>>> -   struct v4l2_subdev *sd, *tmp;
>>> -
>>> if (!notifier->v4l2_dev)
>>> return;
>>>  
>>> @@ -205,14 +229,7 @@ void v4l2_async_notifier_unregister(struct 
>>> v4l2_async_notifier *notifier)
>>>  
>>> list_del(>list);
>>>  
>>> -   list_for_each_entry_safe(sd, tmp, >done, async_list) {
>>> -   if (notifier->unbind)
>>> -   notifier->unbind(notifier, sd, sd->asd);
>>> -
>>> -   v4l2_async_cleanup(sd);
>>> -
>>> -   list_move(>async_list, _list);
>>> -   }
>>> +   v4l2_async_notifier_unbind_all_subdevs(notifier);
>>>  
>>> mutex_unlock(_lock);
>>>  
>>> @@ -223,6 +240,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>>>  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>>>  {
>>> struct v4l2_async_notifier *notifier;
>>> +   int ret;
>>>  
>>> /*
>>>  * No reference taken. The reference is held by the device
>>> @@ -238,19 +256,43 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>>>  
>>> list_for_each_entry(notifier, _list, list) {
>>> struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
>>> sd);
>>> -   if (asd) {
>>> -   int ret = v4l2_async_test_notify(notifier, sd, asd);
>>> -   mutex_unlock(_lock);
>>> -   return ret;
>>> -   }
>>> +   int ret;
>>> +
>>> +   if (!asd)
>>> +   continue;
>>> +
>>> +   ret = v4l2_async_test_notify(notifier, sd, asd);
>>> +   if (ret)
>>> +   goto err_unlock;
>>> +
>>> +   if (!list_empty(>waiting) || !notifier->complete)
>>> +   goto out_unlock;
>>> +
>>> +   ret = notifier->complete(notifier);
>>> +   if (ret)
>>> +   goto err_cleanup;
>>> +
>>> +   goto out_unlock;
>>> }
>>>  
>>> /* None matched, wait for hot-plugging */
>>> list_add(>async_list, _list);
>>>  
>>> +out_unlock:
>>> 

Re: [PATCH v14 20/28] v4l: fwnode: Add a helper function to obtain device / integer references

[Hans Verkuil]

On 10/10/2017 01:27 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Mon, Oct 09, 2017 at 02:06:55PM +0200, Hans Verkuil wrote:
>> Hi Sakari,
>>
>> My reply here is also valid for v15.
>>
>> On 26/09/17 13:30, Sakari Ailus wrote:
>>> Hi Hans,
>>>
>>> Thanks for the review.
>>>
>>> On Tue, Sep 26, 2017 at 10:47:40AM +0200, Hans Verkuil wrote:
 On 26/09/17 00:25, Sakari Ailus wrote:
> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> the device's own fwnode, it will follow child fwnodes with the given
> property-value pair and return the resulting fwnode.
>
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 201 
> ++
>  1 file changed, 201 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index f739dfd16cf7..f93049c361e4 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -578,6 +578,207 @@ static int v4l2_fwnode_reference_parse(
>   return ret;
>  }
>  
> +/*
> + * v4l2_fwnode_reference_get_int_prop - parse a reference with integer
> + *   arguments
> + * @dev: struct device pointer
> + * @notifier: notifier for @dev
> + * @prop: the name of the property
> + * @index: the index of the reference to get
> + * @props: the array of integer property names
> + * @nprops: the number of integer property names in @nprops
> + *
> + * Find fwnodes referred to by a property @prop, then under that
> + * iteratively, @nprops times, follow each child node which has a
> + * property in @props array at a given child index the value of which
> + * matches the integer argument at an index.

 "at an index". Still makes no sense to me. Which index?
>>>
>>> How about this:
>>>
>>> First find an fwnode referred to by the reference at @index in @prop.
>>>
>>> Then under that fwnode, @nprops times, for each property in @props,
>>> iteratively follow child nodes starting from fwnode such that they have the
>>> property in @props array at the index of the child node distance from the
>>
>> distance? You mean 'instance'?
> 
> No. It's a tree structure: this is the distance between a node in the tree
> and the root node (i.e. device's fwnode).
> 
>>
>>> root node and the value of that property matching with the integer argument 
>>> of
>>> the reference, at the same index.
>>
>> You've completely lost me. About halfway through this sentence my brain 
>> crashed :-)
> 
> :-D
> 
> Did keeping distance have any effect?

No :-)

"the index of the child node distance from the root node": I have absolutely
no idea how to interpret that.

> 
>>
>>>

> + *
> + * For example, if this function was called with arguments and values
> + * @dev corresponding to device "SEN", @prop == "flash-leds", @index
> + * == 1, @props == { "led" }, @nprops == 1, with the ASL snippet below
> + * it would return the node marked with THISONE. The @dev argument in
> + * the ASL below.

 I know I asked for this before, but can you change the example to one where
 nprops = 2? I think that will help understanding this.
>>>
>>> I could do that but then the example no longer corresponds to any actual
>>> case that exists at the moment. LED nodes will use a single integer
>>> argument and lens-focus nodes none.
>>
>> So? The example is here to understand the code and it doesn't have to be
>> related to actual hardware for a mainlined driver.
> 
> This isn't about hardware, the definitions being parsed currently aren't
> specific to any single piece of hardware. I could add an example which does
> not exist, that's certainly possible. But I fail to see how it'd help
> while the contrary could well be the case.

It helps to relate the code (and the comments for that matter) to what is in
the ACPI. In fact, if you can make such an example, then I can see if I can
come up with a better description.

Regards,

Hans

> 
>>
>> If you really don't want to do this here, then put the example in the commit
>> log. I don't see any reason why you can't put it here, though.
>>
>> I think that once I see an 'nprops = 2' example I can rephrase that
>> brain-crash sentence for you...
>>
>> BTW, where are the ACPI 'bindings' defined anyway? For DT they are in the
>> bindings directory, but where does ACPI define such things? Just curious.
> 
> As the fwnode interface can be used to access information in both ACPI and
> DT, there is an incentive to maintain the interfaces effectively the same.
> In other words where the interfaces are the same, there is no need to
> define bindings for ACPI as such. Where there are differences the bindings
> are defined in Documentation/acpi/dsd .
> 
> The so far only technical reason to that is related to 

Re: [PATCH v15 04/32] v4l: async: Fix notifier complete callback error handling

[Sakari Ailus]

Hi Hans,

On Mon, Oct 09, 2017 at 01:45:25PM +0200, Hans Verkuil wrote:
> On 04/10/17 23:50, Sakari Ailus wrote:
> > The notifier complete callback may return an error. This error code was
> > simply returned to the caller but never handled properly.
> > 
> > Move calling the complete callback function to the caller from
> > v4l2_async_test_notify and undo the work that was done either in async
> > sub-device or async notifier registration.
> > 
> > Reported-by: Russell King 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c | 78 
> > +++-
> >  1 file changed, 60 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > b/drivers/media/v4l2-core/v4l2-async.c
> > index ca281438a0ae..4924481451ca 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -122,9 +122,6 @@ static int v4l2_async_test_notify(struct 
> > v4l2_async_notifier *notifier,
> > /* Move from the global subdevice list to notifier's done */
> > list_move(>async_list, >done);
> >  
> > -   if (list_empty(>waiting) && notifier->complete)
> > -   return notifier->complete(notifier);
> > -
> > return 0;
> >  }
> >  
> > @@ -136,11 +133,27 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
> > sd->asd = NULL;
> >  }
> >  
> > +static void v4l2_async_notifier_unbind_all_subdevs(
> > +   struct v4l2_async_notifier *notifier)
> > +{
> > +   struct v4l2_subdev *sd, *tmp;
> > +
> > +   list_for_each_entry_safe(sd, tmp, >done, async_list) {
> > +   if (notifier->unbind)
> > +   notifier->unbind(notifier, sd, sd->asd);
> > +
> > +   v4l2_async_cleanup(sd);
> > +
> > +   list_move(>async_list, _list);
> > +   }
> > +}
> > +
> >  int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> >  struct v4l2_async_notifier *notifier)
> >  {
> > struct v4l2_subdev *sd, *tmp;
> > struct v4l2_async_subdev *asd;
> > +   int ret;
> > int i;
> >  
> > if (!v4l2_dev || !notifier->num_subdevs ||
> > @@ -185,19 +198,30 @@ int v4l2_async_notifier_register(struct v4l2_device 
> > *v4l2_dev,
> > }
> > }
> >  
> > +   if (list_empty(>waiting) && notifier->complete) {
> > +   ret = notifier->complete(notifier);
> > +   if (ret)
> > +   goto err_complete;
> > +   }
> > +
> > /* Keep also completed notifiers on the list */
> > list_add(>list, _list);
> >  
> > mutex_unlock(_lock);
> >  
> > return 0;
> > +
> > +err_complete:
> > +   v4l2_async_notifier_unbind_all_subdevs(notifier);
> > +
> > +   mutex_unlock(_lock);
> > +
> > +   return ret;
> >  }
> >  EXPORT_SYMBOL(v4l2_async_notifier_register);
> >  
> >  void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> >  {
> > -   struct v4l2_subdev *sd, *tmp;
> > -
> > if (!notifier->v4l2_dev)
> > return;
> >  
> > @@ -205,14 +229,7 @@ void v4l2_async_notifier_unregister(struct 
> > v4l2_async_notifier *notifier)
> >  
> > list_del(>list);
> >  
> > -   list_for_each_entry_safe(sd, tmp, >done, async_list) {
> > -   if (notifier->unbind)
> > -   notifier->unbind(notifier, sd, sd->asd);
> > -
> > -   v4l2_async_cleanup(sd);
> > -
> > -   list_move(>async_list, _list);
> > -   }
> > +   v4l2_async_notifier_unbind_all_subdevs(notifier);
> >  
> > mutex_unlock(_lock);
> >  
> > @@ -223,6 +240,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
> >  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
> >  {
> > struct v4l2_async_notifier *notifier;
> > +   int ret;
> >  
> > /*
> >  * No reference taken. The reference is held by the device
> > @@ -238,19 +256,43 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
> >  
> > list_for_each_entry(notifier, _list, list) {
> > struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
> > sd);
> > -   if (asd) {
> > -   int ret = v4l2_async_test_notify(notifier, sd, asd);
> > -   mutex_unlock(_lock);
> > -   return ret;
> > -   }
> > +   int ret;
> > +
> > +   if (!asd)
> > +   continue;
> > +
> > +   ret = v4l2_async_test_notify(notifier, sd, asd);
> > +   if (ret)
> > +   goto err_unlock;
> > +
> > +   if (!list_empty(>waiting) || !notifier->complete)
> > +   goto out_unlock;
> > +
> > +   ret = notifier->complete(notifier);
> > +   if (ret)
> > +   goto err_cleanup;
> > +
> > +   goto out_unlock;
> > }
> >  
> > /* None matched, wait for hot-plugging */
> > list_add(>async_list, _list);
> >  
> > +out_unlock:
> > mutex_unlock(_lock);
> >  
> > return 0;
> > +
> > 

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Tue, 10 Oct 2017 14:54:35 +0300
Sakari Ailus  escreveu:

> On Tue, Oct 10, 2017 at 06:15:03AM -0300, Mauro Carvalho Chehab wrote:
> > Em Fri, 6 Oct 2017 14:51:06 +0300
> > Sakari Ailus  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:  
> > > > > +V4L2 device node
> > > > > + A device node that is associated to a V4L2 main driver,
> > > > > + as specified in :ref:`v4l2_device_naming`.
> > > 
> > > I think we need to name the interface, not so much their instances.
> > > 
> > > How about adding:
> > > 
> > > V4L2
> > >   Video4Linux 2 interface. The interface implemented by **V4L2 device
> > >   nodes**.
> > > 
> > > and:
> > > 
> > > V4L2 device node
> > >   A device node implementing the **V4L2** interface.  
> > 
> > Not sure if I answered it already. subdev API is part of V4L2.
> > So, a change like that would cause more harm than good ;-)  
> 
> Hmm. There seems to be a gap here. It'd be much easier to maintain
> consistency in naming and definitions if V4L2 sub-device nodes were also
> documented to be V4L2 device nodes, just as any other device nodes exposed
> by drivers through the V4L2 framework.
> 
> > 
> > The definition should let it clear that only the devnodes 
> > implemented by the V4L2 main driver are considered as
> > V4L2 device nodes.  
> 
> Why? I don't think we should make assumptions on which driver exposes a
> device node; this is not visible to the user space after all.

Because the V4L2 spec documents, with the exception of the subdev.rst
(and where otherwise noticed), assumes that a V4L2 device node doesn't
include subdevs.

So, if you loo, for example, at the chapter 1 name:
"common API elements"

it implies that every single V4L2 device node supports what's there.
But that's not the case, for example, for what's described at
Documentation/media/uapi/v4l/querycap.rst (with is part of
chapter 1).

There are a couple of possible alternatives:

1) define V4L2 device nodes excluding /dev/subdev, with is the
   current approach;

2) rewrite the entire V4L2 uAPI spec to explicitly talk, on each
   section, if it applies or not to sub-devices;

3) "promote" subdev API to a separate part of the media spec,
   just like what it was done for media controller, e. g. adding
   a /Documentation/media/uapi/subdev directory and add there
   descriptions for all syscalls that apply to subdevs
   (open, close, ioctl). That would be weird from kAPI point of
   view, as splitting it from V4L2 won't make sense there. So,
   we'll likely need to add some notes at both kAPI and uAPI to
   explain that the subdev API userspace API is just a different
   way to expose V4L2 hardware control, but, internally, both
   are implemented by the same V4L2 core.

This patchset assumes (1). I'm ok if someone wants to do either
(2) or (3), but I won't have the required time to do such
changes.


Thanks,
Mauro

Re: [PATCH v15 01/32] v4l: async: Remove re-probing support

[Sakari Ailus]

Hi Sylwester,

On Mon, Oct 09, 2017 at 06:44:52PM +0200, Sylwester Nawrocki wrote:
> Hi Sakari,
> 
> On 10/09/2017 04:18 PM, Sakari Ailus wrote:
> > Sure, how about this at the end of the current commit message:
> > 
> > If there is a need to support removing the clock provider in the future,
> > this should be implemented in the clock framework instead, not in V4L2.
> 
> I find it a little bit misleading, there is already support for removing
> the clock provider, only any clock references for consumers became then
> stale.  Perhaps:
> 
> "If there is a need to support the clock provider unregister/register 
> cycle while keeping the clock references in the consumers in the future, 
> this should be implemented in the clock framework instead, not in V4L2."

Yes, I'll use this in v16.

> 
> ? That said, I doubt this issue is going to be entirely solved solely 
> in the clock framework, as it is a more general problem of resource 
> dependencies.  It could be related to other resources, like regulator
> or GPIO.  It has been discussed for a long time now and it will likely 
> take time until a general solution is available.

I don't think we can have entirely generic solutions to this as the API
through which the resources are accessed is specific to the resources
(regulator, GPIO, clock). Or the generic solution would be used by the
frameworks behind those APIs. But as Laurent mentioned, we don't have this
case with other than clock currently.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

On Tue, Oct 10, 2017 at 06:15:03AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 6 Oct 2017 14:51:06 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:
> > > > +V4L2 device node
> > > > +   A device node that is associated to a V4L2 main driver,
> > > > +   as specified in :ref:`v4l2_device_naming`.  
> > 
> > I think we need to name the interface, not so much their instances.
> > 
> > How about adding:
> > 
> > V4L2
> > Video4Linux 2 interface. The interface implemented by **V4L2 device
> > nodes**.
> > 
> > and:
> > 
> > V4L2 device node
> > A device node implementing the **V4L2** interface.
> 
> Not sure if I answered it already. subdev API is part of V4L2.
> So, a change like that would cause more harm than good ;-)

Hmm. There seems to be a gap here. It'd be much easier to maintain
consistency in naming and definitions if V4L2 sub-device nodes were also
documented to be V4L2 device nodes, just as any other device nodes exposed
by drivers through the V4L2 framework.

> 
> The definition should let it clear that only the devnodes 
> implemented by the V4L2 main driver are considered as
> V4L2 device nodes.

Why? I don't think we should make assumptions on which driver exposes a
device node; this is not visible to the user space after all.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v4] staging: atomisp: add a driver for ov5648 camera sensor

[Sakari Ailus]

Hi Alan,

On Tue, Oct 10, 2017 at 10:08:40AM +0100, Alan Cox wrote:
> > Would it make sense to first get the other drivers to upstream and
> > then see what's the status of atomisp? 
> 
> Agreed
> 
> > the board specific information from firmware is conveyed to the
> > sensor drivers will change to what the rest of the sensor drivers are
> > using. I think a most straightforward way would be to amend the ACPI
> > tables to include the necessary information.
> 
> I don't see that happening. The firmware they have today is the
> firmware they will always have, and for any new devices we manage to
> get going is probably going to end up entirely hardcoded.

You'd need to pass the table use initrd to amend the existing tables.

Another option would be to parse the information from ACPI / EFI variables
or whatever to set things up in the atomisp driver, and rely on e.g. I²C
matching in the V4L2 async framework.

The board specific information needed by the sensor drivers need to be
somehow conveyed to the drivers. Perhaps using pset /
device_add_property()?

This is not trivial and would require at least either V4L2 framework or
sensor driver changes to support atomisp, which currently is a staging
driver.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH v8 0/7] document types of hardware control for V4L2

[Mauro Carvalho Chehab]

On Kernel 2.6.39, the omap3 driver was introduced together with a new way
to control complex V4L2 devices used on embedded systems, but this was
never documented, as the original idea were to have "soon" support for
standard apps to use it as well, via libv4l, but that didn't happen so far.

Also, it is not possible for an userspace applicatin to detect the kind of
control a device supports.

This series fill the gap, by documenting the new type of hardware
control and adding a way for userspace to detect if the device can be
used or not by an standard V4L2 application.

Notes:


1) For the sake of better review, this series start with the addition of a
glossary, as requested by Laurent. Please notice, however, that
the glossary there references some new captions that will only be added
by subsequent patches. So, when this series get applied, the glossary
patch should actually be merged after the patches that introduce those
new captions, in order to avoid warnings for non-existing references.

2) This series doesn't contain patches that actually use the new flag.
This will be added after such patch gets reviewed.

v8:
- Addressed Hans and Sakari's comments. Hopefully, we'll all agree
  with this one :-)
- Added :term:`foo` references at the glossary and at the first time a
  term appears inside a V4L2 section.
  I opted to not replace all occurences for a couple of reasons:
a) it sounded overkill to me;
b) if we decide to change some term, there will be a lot
   more stuff to be fixed, specially for terms in plural,
   as a plural for :term:`device` would be
   :term:`devices `.
  Once we set this patchset into a stone, it could make sense to
  run some script that would replace every other occurrence of the
  glossary terms within Documentation/media/uapi/v4l to link to
  the glossary reference - but let's postpone this to be applied
  on a separate patchset.
  Btw, it probably makes sense to make the glossary as a general
  media book glossary - but again, this is out of topic for this
  patchset.

v7:
- Altered some nomenclature at the glossary as suggested by Hans
  and used git-filter to change it on all patches.

v6:
- Some editorial changes based on comments from Hans and Sakari.

v5:
- Added more terms to the glossary
- Adjusted some wording as proposed by Hans on a few patches
  and added his ack on others

v4:

- Addressed Hans comments for v2;
- Fixed broken references at the glossary.rst

v3:

- Add a glossary to be used by the new documentation about hardware control;
- Add a patch removing minor number range
- Use glossary terms at open.rst
- Split the notice about subdev-API on vdev-centric, as this change
   will require further discussions.

v2:

- added a patch at the beginning of the series better defining the
  device node naming rules;
- better defined the differenes between device hardware and V4L2 device node
  as suggested by Laurent and with changes proposed by Hans and Sakari
- changed the caps flag to indicate MC-centric devices
- removed the final patch that would use the new caps flag. I'll write it
  once we agree on the new caps flag.

Mauro Carvalho Chehab (7):
  media: add glossary.rst with a glossary of terms used at V4L2 spec
  media: open.rst: better document device node naming
  media: open.rst: remove the minor number range
  media: open.rst: document vdevnode-centric and mc-centric types
  media: open.rst: Adjust some terms to match the glossary
  media: videodev2: add a flag for MC-centric devices
  media: open.rst: add a notice about subdev-API on vdev-centric

 Documentation/media/uapi/v4l/glossary.rst| 167 +++
 Documentation/media/uapi/v4l/open.rst| 158 +
 Documentation/media/uapi/v4l/v4l2.rst|   1 +
 Documentation/media/uapi/v4l/vidioc-querycap.rst |   5 +
 Documentation/media/videodev2.h.rst.exceptions   |   1 +
 include/uapi/linux/videodev2.h   |   2 +
 6 files changed, 309 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/glossary.rst

-- 
2.13.6

[PATCH v8 2/7] media: open.rst: better document device node naming

[Mauro Carvalho Chehab]

Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identify for a given device.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/open.rst | 53 ++-
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index afd116edb40d..de2144277f55 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -7,14 +7,16 @@ Opening and Closing Devices
 ***
 
 
-Device Naming
-=
+.. _v4l2_device_naming:
 
-V4L2 drivers are implemented as kernel modules, loaded manually by the
-system administrator or automatically when a device is first discovered.
-The driver modules plug into the "videodev" kernel module. It provides
-helper functions and a common application interface specified in this
-document.
+V4L2 Device Node Naming
+===
+
+V4L2 :term:`drivers ` are implemented as kernel modules, loaded
+manually by the system administrator or automatically when a device is
+first discovered. The driver modules plug into the ``videodev`` kernel
+module. It provides helper functions and a common application interface
+specified in this document.
 
 Each driver thus loaded registers one or more device nodes with major
 number 81 and a minor number between 0 and 255. Minor numbers are
@@ -23,6 +25,43 @@ option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor 
numbers
 are allocated in ranges depending on the device node type (video, radio,
 etc.).
 
+The existing :term:`device node` types defined at V4L2 spec are:
+
+ ==
+Default device node name Usage
+ ==
+``/dev/videoX`` Video input/output devices
+``/dev/vbiX``   Vertical blank data (i.e. closed captions, teletext)
+``/dev/radioX`` Radio tuners and modulators
+``/dev/swradioX``   Software Defined Radio tuners and modulators
+``/dev/v4l-touchX`` Touch sensors
+ ==
+
+Where ``X`` is a non-negative number.
+
+.. note::
+
+   1. The actual device node name is system-dependent, as udev rules may apply.
+   2. There is no guarantee that ``X`` will remain the same for the same
+  device, as the number depends on the device driver's probe order.
+  If you need an unique name, udev default rules produce
+  ``/dev/v4l/by-id/`` and ``/dev/v4l/by-path/`` directories containing
+  links that can be used uniquely to identify a V4L2 device node::
+
+   $ tree /dev/v4l
+   /dev/v4l
+   ??? by-id
+   ?   ??? usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> 
../../video0
+   ??? by-path
+   ??? pci-:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0
+
+   3. :term:`V4L2 sub-device` nodes (e. g. ``/dev/v4l-sudevX``) provide a
+  different API and aren't considered as
+  :term:`V4L2 device nodes `.
+
+  They are covered at :ref:`subdev`.
+
+
 Many drivers support "video_nr", "radio_nr" or "vbi_nr" module
 options to select specific video/radio/vbi node numbers. This allows the
 user to request that the device node is named e.g. /dev/video5 instead
-- 
2.13.6

[PATCH v8 4/7] media: open.rst: document vdevnode-centric and mc-centric types

[Mauro Carvalho Chehab]

When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node.

Yet, we have never clearly documented in the V4L2 specification
the differences between the two types.

Let's document them based on the the current implementation.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/open.rst | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 46ef63e05696..1a8a9e1d0e84 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -7,6 +7,61 @@ Opening and Closing Devices
 ***
 
 
+.. _v4l2_hardware_control:
+
+
+Types of V4L2 media hardware control
+
+
+A :term:`V4L2 hardware` is usually complex: support for it is
+implemented via a :term:`V4L2 main driver` and often by several
+additional :term:`drivers `.
+The main driver always exposes one or more
+:term:`V4L2 device nodes `
+(see :ref:`v4l2_device_naming`) with are responsible for implementing
+data streaming, if applicable.
+
+The other drivers are called :term:`V4L2 sub-devices `
+and provide control to other
+:term:`hardware components ` are usually connected
+via a serial bus (like :term:`I²C`, :term:`SMBus` or :term:`SPI`).
+Depending on the main driver, they can be implicitly
+controlled directly by the main driver or explicitly via
+the V4L2 sub-device API (see :ref:`subdev`).
+
+When **V4L2** was originally designed, the
+:term:`V4L2 device nodes ` served the purpose of both
+control and data interfaces and there was no separation
+between the two interface-wise. V4L2 controls, setting inputs and outputs,
+format configuration and buffer related operations were all performed
+through the same **V4L2 device nodes**. Devices offering such interface are
+called **V4L2 device node centric**.
+
+Later on, support for the :term:`media controller` interface was added
+to V4L2 in order to better support complex :term:`V4L2 hardware` where the
+**V4L2** interface alone could no longer meaningfully serve as both a
+control and a data interface. On such V4L2 hardware, **V4L2** interface
+remains a data interface whereas control takes place through the
+:term:`media controller` and :term:`V4L2 sub-device` interfaces. Stream
+control is an exception to this: streaming is enabled and disabled
+through the **V4L2** interface. These devices are called
+**Media controller centric**.
+
+**MC-centric** V4L2 hardware provide more versatile control of the
+hardware than **V4L2 device node centric** devices at the expense of
+requiring device-specific userspace settings.
+
+On **MC-centric** V4L2 hardware, the **V4L2 sub-device nodes**
+represent specific parts of the V4L2 hardware, to which they enable
+control.
+
+Also, the additional versatility of **MC-centric** V4L2 hardware comes
+with additional responsibilities, the main one of which is the requirements
+of the user configuring the device pipeline before starting streaming. This
+typically involves configuring the links using the **Media controller**
+interface and the media bus formats on pads (at both ends of the links)
+using the **V4L2 sub-device** interface.
+
 .. _v4l2_device_naming:
 
 V4L2 Device Node Naming
-- 
2.13.6

[PATCH v8 6/7] media: videodev2: add a flag for MC-centric devices

[Mauro Carvalho Chehab]

As both vdev-centric and MC-centric devices may implement the
same APIs, we need a flag to allow userspace to distinguish
between them.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/open.rst| 7 +++
 Documentation/media/uapi/v4l/vidioc-querycap.rst | 5 +
 Documentation/media/videodev2.h.rst.exceptions   | 1 +
 include/uapi/linux/videodev2.h   | 2 ++
 4 files changed, 15 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index c9e6bc9280a6..58ab75959584 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -62,6 +62,13 @@ typically involves configuring the links using the **Media 
controller**
 interface and the media bus formats on pads (at both ends of the links)
 using the **V4L2 sub-device** interface.
 
+.. attention::
+
+   Devices that require **MC-centric** media hardware control should
+   report a ``V4L2_MC_CENTRIC`` :c:type:`v4l2_capability` flag
+   (see :ref:`VIDIOC_QUERYCAP`).
+
+
 .. _v4l2_device_naming:
 
 V4L2 Device Node Naming
diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 66fb1b3d6e6e..944bc5ba484f 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -254,6 +254,11 @@ specification the ioctl returns an ``EINVAL`` error code.
 * - ``V4L2_CAP_TOUCH``
   - 0x1000
   - This is a touch device.
+* - ``V4L2_MC_CENTRIC``
+  - 0x2000
+  - Indicates that the device require **MC-centric** hardware
+control, and thus can't be used by **vdevnode-centric** applications.
+See :ref:`v4l2_hardware_control` for more details.
 * - ``V4L2_CAP_DEVICE_CAPS``
   - 0x8000
   - The driver fills the ``device_caps`` field. This capability can
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8686ac..b51a575f9f75 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -157,6 +157,7 @@ replace define V4L2_CAP_META_CAPTURE device-capabilities
 replace define V4L2_CAP_READWRITE device-capabilities
 replace define V4L2_CAP_ASYNCIO device-capabilities
 replace define V4L2_CAP_STREAMING device-capabilities
+replace define V4L2_CAP_MC_CENTRIC device-capabilities
 replace define V4L2_CAP_DEVICE_CAPS device-capabilities
 replace define V4L2_CAP_TOUCH device-capabilities
 
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 185d6a0acc06..4ff1224719a7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -460,6 +460,8 @@ struct v4l2_capability {
 
 #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
 
+#define V4L2_CAP_MC_CENTRIC 0x2000  /* Device require 
MC-centric hardware control */
+
 #define V4L2_CAP_DEVICE_CAPS0x8000  /* sets device 
capabilities field */
 
 /*
-- 
2.13.6

[PATCH v8 3/7] media: open.rst: remove the minor number range

[Mauro Carvalho Chehab]

minor numbers use to range between 0 to 255, but that
was changed a long time ago. While it still applies when
CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is
dynamically allocated, this may not be true. In any case,
this is not relevant, as udev will take care of it.

So, remove this useless misinformation.

Acked-by: Hans Verkuil 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/open.rst | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index de2144277f55..46ef63e05696 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -19,11 +19,10 @@ module. It provides helper functions and a common 
application interface
 specified in this document.
 
 Each driver thus loaded registers one or more device nodes with major
-number 81 and a minor number between 0 and 255. Minor numbers are
-allocated dynamically unless the kernel is compiled with the kernel
-option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers
-are allocated in ranges depending on the device node type (video, radio,
-etc.).
+number 81. Minor numbers are allocated dynamically unless the kernel
+is compiled with the kernel option CONFIG_VIDEO_FIXED_MINOR_RANGES.
+In that case minor numbers are allocated in ranges depending on the
+device node type.
 
 The existing :term:`device node` types defined at V4L2 spec are:
 
-- 
2.13.6

[PATCH v8 5/7] media: open.rst: Adjust some terms to match the glossary

[Mauro Carvalho Chehab]

As we now have a glossary, some terms used on open.rst
require adjustments.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/open.rst | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 1a8a9e1d0e84..c9e6bc9280a6 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -159,27 +159,28 @@ Related Devices
 Devices can support several functions. For example video capturing, VBI
 capturing and radio support.
 
-The V4L2 API creates different nodes for each of these functions.
+The V4L2 API creates different :term:`V4L2 device nodes `
+types for each of these functions.
 
-The V4L2 API was designed with the idea that one device node could
+The V4L2 API was designed with the idea that one :term:`device node` could
 support all functions. However, in practice this never worked: this
-'feature' was never used by applications and many drivers did not
-support it and if they did it was certainly never tested. In addition,
+'feature' was never used by applications and many :term:`drivers `
+did not support it and if they did it was certainly never tested. In addition,
 switching a device node between different functions only works when
 using the streaming I/O API, not with the
 :ref:`read() `/\ :ref:`write() ` API.
 
-Today each device node supports just one function.
+Today each V4L2 device node supports just one function.
 
-Besides video input or output the hardware may also support audio
-sampling or playback. If so, these functions are implemented as ALSA PCM
-devices with optional ALSA audio mixer devices.
+Besides video input or output, the :term:`media hardware` may also support
+audio sampling or playback. If so, these functions are implemented as ALSA
+PCM devices with optional ALSA audio mixer devices.
 
 One problem with all these devices is that the V4L2 API makes no
-provisions to find these related devices. Some really complex devices
-use the Media Controller (see :ref:`media_controller`) which can be
-used for this purpose. But most drivers do not use it, and while some
-code exists that uses sysfs to discover related devices (see
+provisions to find these related V4L2 device nodes. Some really complex
+hardware use the :term:`media controller` (see :ref:`media_controller`) which
+can be used for this purpose. But several drivers do not use it, and while
+some code exists that uses sysfs to discover related V4L2 device nodes (see
 libmedia_dev in the
 `v4l-utils `__ git
 repository), there is no library yet that can provide a single API
-- 
2.13.6

[PATCH v8 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

[Mauro Carvalho Chehab]

The documentation doesn't mention if vdev-centric hardware
control would have subdev API or not.

Add a notice about that, reflecting the current status, where
three drivers use it, in order to support some subdev-specific
controls.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/open.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index 58ab75959584..ccdf53ab347c 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -62,6 +62,13 @@ typically involves configuring the links using the **Media 
controller**
 interface and the media bus formats on pads (at both ends of the links)
 using the **V4L2 sub-device** interface.
 
+.. note::
+
+   A **vdevnode-centric** may also optionally expose V4L2 sub-devices via
+   :ref:`sub-device API `. In that case, it has to implement
+   the :ref:`media controller API ` as well.
+
+
 .. attention::
 
Devices that require **MC-centric** media hardware control should
-- 
2.13.6

[PATCH v8 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Add a glossary of terms for V4L2, as several concepts are complex
enough to cause misunderstandings.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/glossary.rst | 167 ++
 Documentation/media/uapi/v4l/v4l2.rst |   1 +
 2 files changed, 168 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/glossary.rst

diff --git a/Documentation/media/uapi/v4l/glossary.rst 
b/Documentation/media/uapi/v4l/glossary.rst
new file mode 100644
index ..a5a832b4dda5
--- /dev/null
+++ b/Documentation/media/uapi/v4l/glossary.rst
@@ -0,0 +1,167 @@
+
+Glossary
+
+
+.. note::
+
+   This goal of section is to standardize the terms used within the V4L2
+   documentation. It is written incrementally as they are standardized in
+   the V4L2 documentation. So, it is a Work In Progress.
+
+.. Please keep the glossary entries in alphabetical order
+
+.. glossary::
+
+Bridge driver
+   A driver that provides a bridge between the CPU's bus to the
+   data and control buses of a :term:`media hardware`. Often, the
+   bridge driver is the same as :term:`V4L2 main driver`.
+
+Chip
+   :See: :term:`Integrated circuit`.
+
+Device Driver
+Driver
+   The part of the Linux Kernel that implements support
+   for a :term:`hardware component`.
+
+Device Node
+   A character device node in the file system used to control and/or
+   do input/output data transfers from/to a Kernel driver.
+
+Digital Signal Processor
+DSP
+   A specialized :term:`microprocessor`, with its architecture optimized
+   for the operational requirements of digital signal processing.
+
+Field-programmable Gate Array
+FPGA
+   A field-programmable gate array (FPGA) is an :term:`integrated circuit`
+   designed to be configured by a customer or a designer after
+   manufacturing.
+
+   :See: https://en.wikipedia.org/wiki/Field-programmable_gate_array.
+
+Hardware component
+   A subset of the :term:`media hardware`. For example an :term:`I²C`
+   or :term:`SPI` device, or an :term:`IP block` inside an
+   :term:`SoC` or :term:`FPGA`.
+
+Image Signal Processor
+ISP
+   A specialized :term:`microprocessor` that implements a set of
+   algorithms for processing image data. ISPs may implement algorithms
+   for lens shading correction, demosaic, scaling and pixel format
+   conversion as well as produce statistics for the use of the control
+   algorithms (e.g. automatic exposure, white balance and focus).
+
+   ISP drivers often contain a receiver for image data from external
+   sources such as sensors and act as :term:`V4L2 main driver`.
+
+Integrated circuit
+IC
+   A set of electronic circuits on one small flat piece of
+   semiconductor material, normally silicon.
+
+   Also known as :term:`chip`.
+
+Intellectual property core
+IP core
+   In electronic design a semiconductor intellectual property core,
+   is a reusable unit of logic, cell, or integrated circuit layout
+   design that is the intellectual property of one party.
+   IP cores may be licensed to another party or can be owned
+   and used by a single party alone.
+
+   :See: 
https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
+
+Inter-Integrated Circuit
+I²C
+   A  multi-master, multi-slave, packet switched, single-ended,
+   serial computer bus. A :term:`V4L2 sub-device driver` usually is
+   controlled via this bus.
+
+   :See: http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
+
+IP block
+   :See: :term:`IP core`.
+
+Media controller
+MC
+   An API designed to expose and control the relationships of the
+   :term:`media hardware` to applications.
+
+   :See: :ref:`media_controller`.
+
+Media controller centric
+MC-centric
+   :term:`V4L2 hardware` that requires a :term:`media controller`.
+
+   :See: :ref:`v4l2_hardware_control`.
+
+Media hardware
+   A group of hardware components that together form the
+   functional media hardware. For instance the :term:`SoC`
+   :term:`ISP` :term:`IP cores ` and external camera
+   sensors together form the camera media hardware.
+
+Media hardware control
+   Type of control for a :term:`media hardware` supported a
+   V4L2 :term:`driver`.
+
+   :See: :ref:`v4l2_hardware_control`.
+
+Microprocessor
+   An electronic circuitry that carries out the instructions
+   of a computer program by performing the basic arithmetic, logical,
+   control and input/output (I/O) operations specified by the
+   instructions on a single :term:`integrated circuit`.
+
+SMBus
+   A subset of :term:`I²C`, with defines a stricter usage of the bus.
+
+Serial Peripheral Interface
+SPI
+   Synchronous serial communication 

Re: [PATCH v7 5/7] media: open.rst: Adjust some terms to match the glossary

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 15:48:22 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Wed, Sep 27, 2017 at 07:23:47PM -0300, Mauro Carvalho Chehab wrote:
> > As we now have a glossary, some terms used on open.rst
> > require adjustments.
> > 
> > Acked-by: Hans Verkuil 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/uapi/v4l/open.rst | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/open.rst 
> > b/Documentation/media/uapi/v4l/open.rst
> > index f603bc9b49a0..0daf0c122c19 100644
> > --- a/Documentation/media/uapi/v4l/open.rst
> > +++ b/Documentation/media/uapi/v4l/open.rst
> > @@ -143,7 +143,7 @@ Related Devices
> >  Devices can support several functions. For example video capturing, VBI
> >  capturing and radio support.
> >  
> > -The V4L2 API creates different nodes for each of these functions.
> > +The V4L2 API creates different V4L2 device nodes for each of these 
> > functions.  
> 
> A V4L2 device node is an instance of the V4L2 API. At the very least we
> should call them "V4L2 device node types", not device nodes only. This
> simply would suggests they're separate.

OK, I added "types" there.

> 
> s/creates/defines/ ?

It is meant to say create.

A device that supports both radio, video and VBI for the same V4L2
input will create three device nodes:
/dev/video0
/dev/radio0
/dev/vbi0

As all are associated to the same video input, and an ioctl send 
to one device may affect the other devices too, as they all associated
with the same hardware.

Thanks,
Mauro

Re: [PATCH v14 20/28] v4l: fwnode: Add a helper function to obtain device / integer references

[Sakari Ailus]

Hi Hans,

On Mon, Oct 09, 2017 at 02:06:55PM +0200, Hans Verkuil wrote:
> Hi Sakari,
> 
> My reply here is also valid for v15.
> 
> On 26/09/17 13:30, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > Thanks for the review.
> > 
> > On Tue, Sep 26, 2017 at 10:47:40AM +0200, Hans Verkuil wrote:
> >> On 26/09/17 00:25, Sakari Ailus wrote:
> >>> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> >>> the device's own fwnode, it will follow child fwnodes with the given
> >>> property-value pair and return the resulting fwnode.
> >>>
> >>> Signed-off-by: Sakari Ailus 
> >>> ---
> >>>  drivers/media/v4l2-core/v4l2-fwnode.c | 201 
> >>> ++
> >>>  1 file changed, 201 insertions(+)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> >>> b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> index f739dfd16cf7..f93049c361e4 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> @@ -578,6 +578,207 @@ static int v4l2_fwnode_reference_parse(
> >>>   return ret;
> >>>  }
> >>>  
> >>> +/*
> >>> + * v4l2_fwnode_reference_get_int_prop - parse a reference with integer
> >>> + *   arguments
> >>> + * @dev: struct device pointer
> >>> + * @notifier: notifier for @dev
> >>> + * @prop: the name of the property
> >>> + * @index: the index of the reference to get
> >>> + * @props: the array of integer property names
> >>> + * @nprops: the number of integer property names in @nprops
> >>> + *
> >>> + * Find fwnodes referred to by a property @prop, then under that
> >>> + * iteratively, @nprops times, follow each child node which has a
> >>> + * property in @props array at a given child index the value of which
> >>> + * matches the integer argument at an index.
> >>
> >> "at an index". Still makes no sense to me. Which index?
> > 
> > How about this:
> > 
> > First find an fwnode referred to by the reference at @index in @prop.
> > 
> > Then under that fwnode, @nprops times, for each property in @props,
> > iteratively follow child nodes starting from fwnode such that they have the
> > property in @props array at the index of the child node distance from the
> 
> distance? You mean 'instance'?

No. It's a tree structure: this is the distance between a node in the tree
and the root node (i.e. device's fwnode).

> 
> > root node and the value of that property matching with the integer argument 
> > of
> > the reference, at the same index.
> 
> You've completely lost me. About halfway through this sentence my brain 
> crashed :-)

:-D

Did keeping distance have any effect?

> 
> > 
> >>
> >>> + *
> >>> + * For example, if this function was called with arguments and values
> >>> + * @dev corresponding to device "SEN", @prop == "flash-leds", @index
> >>> + * == 1, @props == { "led" }, @nprops == 1, with the ASL snippet below
> >>> + * it would return the node marked with THISONE. The @dev argument in
> >>> + * the ASL below.
> >>
> >> I know I asked for this before, but can you change the example to one where
> >> nprops = 2? I think that will help understanding this.
> > 
> > I could do that but then the example no longer corresponds to any actual
> > case that exists at the moment. LED nodes will use a single integer
> > argument and lens-focus nodes none.
> 
> So? The example is here to understand the code and it doesn't have to be
> related to actual hardware for a mainlined driver.

This isn't about hardware, the definitions being parsed currently aren't
specific to any single piece of hardware. I could add an example which does
not exist, that's certainly possible. But I fail to see how it'd help
while the contrary could well be the case.

> 
> If you really don't want to do this here, then put the example in the commit
> log. I don't see any reason why you can't put it here, though.
> 
> I think that once I see an 'nprops = 2' example I can rephrase that
> brain-crash sentence for you...
> 
> BTW, where are the ACPI 'bindings' defined anyway? For DT they are in the
> bindings directory, but where does ACPI define such things? Just curious.

As the fwnode interface can be used to access information in both ACPI and
DT, there is an incentive to maintain the interfaces effectively the same.
In other words where the interfaces are the same, there is no need to
define bindings for ACPI as such. Where there are differences the bindings
are defined in Documentation/acpi/dsd .

The so far only technical reason to that is related to the same is that
ACPI can only refer to device nodes (i.e. nodes that correspond to struct
devices), not sub-nodes under them.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] media: imon: Fix null-ptr-deref in imon_probe

[Andrey Konovalov]

On Mon, Oct 9, 2017 at 8:14 PM, Arvind Yadav  wrote:
> It seems that the return value of usb_ifnum_to_if() can be NULL and
> needs to be checked.

Hi Arvind,

Your patch fixes the issue.

Thanks!

Tested-by: Andrey Konovalov 

>
> Signed-off-by: Arvind Yadav 
> ---
> This bug report by Andrey Konovalov usb/media/imon: null-ptr-deref
> in imon_probe
>
>  drivers/media/rc/imon.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index 7b3f31c..0c46155 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -2517,6 +2517,11 @@ static int imon_probe(struct usb_interface *interface,
> mutex_lock(_lock);
>
> first_if = usb_ifnum_to_if(usbdev, 0);
> +   if (!first_if) {
> +   ret = -ENODEV;
> +   goto fail;
> +   }
> +
> first_if_ctx = usb_get_intfdata(first_if);
>
> if (ifnum == 0) {
> --
> 2.7.4
>

Re: [PATCH v7 4/7] media: open.rst: document devnode-centric and mc-centric types

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 15:24:27 +0300
Sakari Ailus  escreveu:

> > +When V4L2 was originally designed, there was only one type of
> > +media hardware control: via the **V4L2 device nodes**. We refer to this 
> > kind
> > +of control as **V4L2 device node centric** (or, simply, 
> > "**vdevnode-centric**").  
> 
> I think this could be easier understood if we start with the differences
> instead of what we call the types. I'd also refer to interfaces rather than
> their instances.
> 
> How about (pending finalising discussion on naming):
> 
> When **V4L2** was originally designed, the **V4L2 device** served the
> purpose of both control and data interfaces and there was no separation
> between the two interface-wise. V4L2 controls, setting inputs and outputs,
> format configuration and buffer related operations were all performed
> through the same **V4L2 device nodes**. Devices offering such interface are
> called **V4L2 device node centric**.
> 
> Later on, support for the **Media controller** interface was added to V4L2
> in order to better support complex **V4L2 aggregate devices** where the
> **V4L2** interface alone could no longer meaningfully serve as both a
> control and a data interface. On such aggregate devices, **V4L2** interface
> remains a data interface whereas control takes place through the **Media
> controller** and **V4L2 sub-device** interfaces. Stream control is an
> exception to this: streaming is enabled and disabled through the **V4L2**
> interface. These devices are called **Media controller centric**.
> 
> **MC-centric** aggregate devices provide more versatile control of the
> hardware than **V4L2 device node centric** devices. On **MC-centric**
> aggregate devices the **V4L2 sub-device nodes** represent specific parts of
> the **V4L2 aggregate device**, to which they enable control.
> 
> Also, the additional versatility of **MC-centric** aggregate devices comes
> with additional responsibilities, the main one of which is the requirements
> of the user configuring the device pipeline before starting streaming. This
> typically involves configuring the links using the **Media controller**
> interface and the media bus formats on pads (at both ends of the links)
> using the **V4L2 sub-device** interface.

Works for me. 

Except that I didn't like the idea of "aggregate devices". So, I kept
the previously agreed term "V4L2 hardware".

Also, as everything comes with a price, I added it on this paragraph:

**MC-centric** V4L2 hardware provide more versatile control of the
hardware than **V4L2 device node centric** devices at the expense of
requiring device-specific userspace settings.

Finally, I'm now using :term:`foo` Sphinx directive on the patchset
(I'll send a new version soon) at the first time a term appears inside
a section[1].

[1] We might repeat that on every occurrence of a term, but:
a) it sounded overkill to me;
b) if we decide to change some term, there will be a lot
   more stuff to be fixed, specially for terms in plural,
   as a plural for :term:`device` would be
   :term:`devices `.
Once we set this patchset into a stone, it could make sense to
run some script that would replace every other occurrence of the
glossary terms within Documentation/media/uapi/v4l to link to
the glossary reference - but let's postpone this to be applied
on a separate patchset.
Btw, it probably makes sense to make the glossary as a general
media book glossary - but again, this is out of topic for this
patchset.


With this, the version I'm adding is:


When **V4L2** was originally designed, the
:term:`V4L2 device nodes ` served the purpose of both
control and data interfaces and there was no separation
between the two interface-wise. V4L2 controls, setting inputs and outputs,
format configuration and buffer related operations were all performed
through the same **V4L2 device nodes**. Devices offering such interface are
called **V4L2 device node centric**.

Later on, support for the :term:`media controller` interface was added
to V4L2 in order to better support complex :term:`V4L2 hardware` where the 
**V4L2** interface alone could no longer meaningfully serve as both a
control and a data interface. On such V4L2 hardware, **V4L2** interface
remains a data interface whereas control takes place through the 
:term:`media controller` and :term:`V4L2 sub-device` interfaces. Stream
control is an exception to this: streaming is enabled and disabled
through the **V4L2** interface. These devices are called
**Media controller centric**.

**MC-centric** V4L2 hardware provide more versatile control of the
hardware than **V4L2 device node centric** devices at the expense of
requiring device-specific userspace settings.

On **MC-centric** V4L2 hardware, the **V4L2 sub-device nodes** 
represent specific parts of the V4L2 hardware, to which they enable
control.

Also, the additional versatility 

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 14:51:06 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:
> > > +V4L2 device node
> > > + A device node that is associated to a V4L2 main driver,
> > > + as specified in :ref:`v4l2_device_naming`.  
> 
> I think we need to name the interface, not so much their instances.
> 
> How about adding:
> 
> V4L2
>   Video4Linux 2 interface. The interface implemented by **V4L2 device
>   nodes**.
> 
> and:
> 
> V4L2 device node
>   A device node implementing the **V4L2** interface.

Not sure if I answered it already. subdev API is part of V4L2.
So, a change like that would cause more harm than good ;-)

The definition should let it clear that only the devnodes 
implemented by the V4L2 main driver are considered as
V4L2 device nodes.

Regards,
Mauro

Re: [PATCH v4] staging: atomisp: add a driver for ov5648 camera sensor

[Alan Cox]

> Would it make sense to first get the other drivers to upstream and
> then see what's the status of atomisp? 

Agreed

> the board specific information from firmware is conveyed to the
> sensor drivers will change to what the rest of the sensor drivers are
> using. I think a most straightforward way would be to amend the ACPI
> tables to include the necessary information.

I don't see that happening. The firmware they have today is the
firmware they will always have, and for any new devices we manage to
get going is probably going to end up entirely hardcoded.

> For this reason I'm tempted to postpone applying this patch at least
> until the other drivers are available.

Yes - unless someone has a different controller and that sensor on a
board so can test it that way ?

Alan

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

On Tue, Oct 10, 2017 at 05:30:04AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 6 Oct 2017 13:22:29 +0300
> Sakari Ailus  escreveu:
> 
> > > +Bridge driver
> > > + The same as V4L2 main driver.  
> > 
> > Not all V4L2 main drivers can be bridge drivers. Mem-to-mem devices, for
> > instance. How about:
> > 
> > A driver for a device receiving image data from another device (or
> > transmitting it to a sub-device) controlled by a sub-device driver. Bridge
> > drivers typically act as V4L2 main drivers.
> 
> That is not true for some device drivers we have.
> 
> The GSPCA drivers are bridge drivers, but they don't use any sub-device
> (well, it should, but nobody will redesign it, as the efforts would
> be huge, for a very little gain). Also uvcdriver doesn't need sub-device
> drivers, as the camera's internal firmware does the interface with the
> sensors.
> 
> We could, instead define it as:
> 
> Bridge driver
>   A driver that provides a bridge between the CPU's bus to the
>   data and control buses of a media hardware. Often, the
>   bridge driver is the same as V4L2 main driver.

Looks good to me.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

[Sakari Ailus]

On Tue, Oct 10, 2017 at 10:01:36AM +0200, Marek Szyprowski wrote:
> Hi Stanimir,
> 
> On 2017-10-10 09:42, Stanimir Varbanov wrote:
> > Marek,
> > 
> > Any comments?
> 
> Oh, I thought that this one has been already merged. If not (yet),
> here is my ack.
> 
> > On 08/29/2017 02:26 PM, Stanimir Varbanov wrote:
> > > Currently videobuf2-dma-sg checks for dma direction for
> > > every single page and videobuf2-dc lacks any dma direction
> > > checks and calls set_page_dirty_lock unconditionally.
> > > 
> > > Thus unify and align the invocations of set_page_dirty_lock
> > > for videobuf2-dc, videobuf2-sg  memory allocators with
> > > videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
> > > copied to dc and dma-sg.
> > > 
> > > Suggested-by: Marek Szyprowski 
> > > Signed-off-by: Stanimir Varbanov 
> 
> Acked-by: Marek Szyprowski 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Add a glossary of terms for V4L2, as several concepts are complex
enough to cause misunderstandings.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/glossary.rst | 150 ++
 Documentation/media/uapi/v4l/v4l2.rst |   1 +
 2 files changed, 151 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/glossary.rst

diff --git a/Documentation/media/uapi/v4l/glossary.rst 
b/Documentation/media/uapi/v4l/glossary.rst
new file mode 100644
index ..08980e9cb98e
--- /dev/null
+++ b/Documentation/media/uapi/v4l/glossary.rst
@@ -0,0 +1,150 @@
+
+Glossary
+
+
+.. note::
+
+   This goal of section is to standardize the terms used within the V4L2
+   documentation. It is written incrementally as they are standardized in
+   the V4L2 documentation. So, it is a Work In Progress.
+
+.. Please keep the glossary entries in alphabetical order
+
+.. glossary::
+
+Bridge driver
+   A driver that provides a bridge between the CPU's bus to the
+   data and control buses of a media hardware. Often, the
+   bridge driver is the same as V4L2 main driver.
+
+Chip:
+   See: Integrated circuit.
+
+Device Node
+   A character device node in the file system used to control and/or
+   do input/output data transfers from/to a Kernel driver.
+
+Digital Signal Processor - DSP
+   A specialized microprocessor, with its architecture optimized for
+   the operational requirements of digital signal processing.
+
+Driver
+   The part of the Linux Kernel that implements support
+   for a hardware component.
+
+Field-programmable Gate Array - FPGA
+   A field-programmable gate array (FPGA) is an integrated circuit
+   designed to be configured by a customer or a designer after
+   manufacturing.
+
+   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
+
+Hardware component
+   A subset of the media hardware. For example an I²C or SPI device,
+   or an IP block inside an SoC or FPGA.
+
+Image Signal Processor - ISP
+   A specialised processor that implements a set of algorithms for
+   processing image data. ISPs may implement algorithms for lens
+   shading correction, demosaic, scaling and pixel format conversion
+   as well as produce statistics for the use of the control
+   algorithms (e.g. automatic exposure, white balance and focus).
+
+   ISP drivers often contain a receiver for image data from external
+   sources such as sensors and act as V4L2 main driver.
+
+Inter-Integrated Circuit - I²C
+   A  multi-master, multi-slave, packet switched, single-ended,
+   serial computer bus. Most V4L2 sub-devices are controlled
+   via this bus.
+
+   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
+
+Integrated circuit - IC
+   A set of electronic circuits on one small flat piece of
+   semiconductor material, normally silicon.
+
+   Also known as chip.
+
+Intellectual property core - IP core
+   In electronic design a semiconductor intellectual property core,
+   is a reusable unit of logic, cell, or integrated circuit layout
+   design that is the intellectual property of one party.
+   IP cores may be licensed to another party or can be owned
+   and used by a single party alone.
+
+   See 
https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
+
+IP block
+   See: IP core.
+
+Media Controller
+   An API designed to expose and control the relationships of the Media
+   Harware to applications.
+
+   See :ref:`media_controller`.
+
+Media Controller centric - MC-centric
+   V4L2 hardware that requires a Media controller.
+
+   See :ref:`v4l2_hardware_control`.
+
+Media hardware
+   A group of hardware components that together form the
+   functional media hardware. For instance the SoC ISP IP
+   cores and external camera sensors together form the
+   camera media hardware.
+
+Media hardware control
+   Type of control for a media hardware supported by V4L2 drivers.
+
+   See :ref:`v4l2_hardware_control`.
+
+Microprocessor
+   An electronic circuitry that carries out the instructions
+   of a computer program by performing the basic arithmetic, logical,
+   control and input/output (I/O) operations specified by the
+   instructions on a single integrated circuit.
+
+SMBus
+   A subset of I²C, with defines a stricter usage of the bus.
+
+Serial Peripheral Interface Bus - SPI
+   Synchronous serial communication interface specification used for
+   short distance communication, primarily in embedded systems.
+
+System on a Chip - SoC
+   An integrated circuit that integrates all components of a computer
+   or other electronic systems.
+
+V4L2 device node
+   A device node that is associated 

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 13:22:29 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> Thanks for continuing the work on this!
> 
> On Wed, Sep 27, 2017 at 07:23:43PM -0300, Mauro Carvalho Chehab wrote:
> > Add a glossary of terms for V4L2, as several concepts are complex
> > enough to cause misunderstandings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/uapi/v4l/glossary.rst | 136 
> > ++
> >  Documentation/media/uapi/v4l/v4l2.rst |   1 +
> >  2 files changed, 137 insertions(+)
> >  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> > 
> > diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> > b/Documentation/media/uapi/v4l/glossary.rst
> > new file mode 100644
> > index ..b6767da1a46e
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/glossary.rst
> > @@ -0,0 +1,136 @@
> > +
> > +Glossary
> > +
> > +
> > +.. note::
> > +
> > +   This goal of section is to standardize the terms used within the V4L2
> > +   documentation. It is written incrementally as they are standardized in
> > +   the V4L2 documentation. So, it is a Work In Progress.
> > +
> > +.. Please keep the glossary entries in alphabetical order
> > +
> > +.. glossary::
> > +
> > +Bridge driver
> > +   The same as V4L2 main driver.  
> 
> Not all V4L2 main drivers can be bridge drivers. Mem-to-mem devices, for
> instance. How about:
> 
> A driver for a device receiving image data from another device (or
> transmitting it to a sub-device) controlled by a sub-device driver. Bridge
> drivers typically act as V4L2 main drivers.
> 
> > +
> > +Device Node
> > +   A character device node in the file system used to control and do
> > +   input/output data transfers from/to a Kernel driver.
> > +
> > +Digital Signal Processor - DSP
> > +   A specialized microprocessor, with its architecture optimized for
> > +   the operational needs of digital signal processing.
> > +
> > +Driver
> > +   The part of the Linux Kernel that implements support
> > +   for a hardware component.
> > +
> > +Field-programmable Gate Array - FPGA
> > +   A field-programmable gate array (FPGA) is an integrated circuit
> > +   designed to be configured by a customer or a designer after
> > +   manufacturing.
> > +
> > +   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> > +
> > +Hardware component
> > +   A subset of the media hardware. For example an I²C or SPI device,
> > +   or an IP block inside an SoC or FPGA.
> > +
> > +Image Signal Processor - ISP
> > +   A specialised processor that implements a set of algorithms for
> > +   processing image data. ISPs may implement algorithms for lens
> > +   shading correction, demosaic, scaling and pixel format conversion
> > +   as well as produce statistics for the use of the control
> > +   algorithms (e.g. automatic exposure, white balance and focus).  
> 
> And perhaps add:
> 
> ISP drivers often contain a receiver for image data from external source
> such as a sensor and act as V4L2 main driver.

OK.

> 
> > +
> > +Inter-Integrated Circuit - I²C
> > +   A  multi-master, multi-slave, packet switched, single-ended,
> > +   serial computer bus used to control V4L2 sub-devices.
> > +
> > +   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> > +
> > +Integrated circuit - IC
> > +   A set of electronic circuits on one small flat piece of
> > +   semiconductor material, normally silicon.
> > +
> > +   Also known as chip.
> > +
> > +Intellectual property core - IP core
> > +   In electronic design a semiconductor intellectual property core,
> > +   is a reusable unit of logic, cell, or integrated circuit layout
> > +   design that is the intellectual property of one party.
> > +   IP cores may be licensed to another party or can be owned
> > +   and used by a single party alone.
> > +
> > +   See 
> > https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> > +
> > +IP block
> > +   The same as IP core.
> > +
> > +MC-centric
> > +   V4L2 hardware that requires a Media controller.
> > +
> > +   See :ref:`v4l2_hardware_control`.
> > +
> > +Media Controller
> > +   An API designed to expose and control devices and sub-devices
> > +   relationships to applications.
> > +
> > +   See :ref:`media_controller`.
> > +
> > +Media hardware
> > +   A group of hardware components that together make a larger
> > +   user-facing functional media hardware. For instance the SoC ISP IP
> > +   cores and external camera sensors together make a
> > +   camera media hardware.
> > +
> > +Media hardware control
> > +   Type of control for a media hardware supported by V4L2 drivers.
> > +
> > +   See :ref:`v4l2_hardware_control`.
> > +
> > +Microprocessor
> > +   An electronic circuitry that carries out the instructions
> > +   of a computer program by performing the basic arithmetic, logical,
> > +   

[PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Sean Young]

If you try to store u64 in a kfifo (or a struct with u64 members),
then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
padding due to alignment (note that struct __kfifo is 20 bytes
on 32 bit).

That in turn causes the __is_kfifo_ptr() to fail, which is caught
by kfifo_alloc(), which now returns EINVAL.

So, ensure that __is_kfifo_ptr() compares to the right structure.

Signed-off-by: Sean Young 
Acked-by: Stefani Seibold 

---
 include/linux/kfifo.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 41eb6fdf87a8..86b5fb08e96c 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2 __STRUCT_KFIFO_PTR(unsigned char, 2, 
void);
  * array is a part of the structure and the fifo type where the array is
  * outside of the fifo structure.
  */
-#define__is_kfifo_ptr(fifo)(sizeof(*fifo) == sizeof(struct 
__kfifo))
+#define__is_kfifo_ptr(fifo) \
+   (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)->type
 
 /**
  * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Tue, 10 Oct 2017 10:27:12 +0200
Hans Verkuil  escreveu:

> > +V4L2 sub-device driver
> > +   Part of the media hardware that implements support for
> > +   a hardware component.  
> 
> The description now no longer fits the term. I suggest:
> 
> "The V4L2 driver that implements support for a hardware component."

Look how we defined the term driver:

Driver
The part of the Linux Kernel that implements support
for a hardware component.

If we define sub-device driver as you're proposing, we're basically
saying that:
sub-device driver == Driver

with is not true.

I guess the proper definition would be, instead:

V4L2 sub-device driver
A driver for a media component whose bus(es) connects it
to the hardware controlled via the V4L2 main driver.



Thanks,
Mauro

Re: [PATCH v5 2/3] doc-rst: add IPU3 raw10 bayer pixel format definitions

[Sakari Ailus]

Hi Yong,

On Fri, Oct 06, 2017 at 06:39:00PM -0500, Yong Zhi wrote:
> The formats added by this patch are:
> 
> V4L2_PIX_FMT_IPU3_SBGGR10
> V4L2_PIX_FMT_IPU3_SGBRG10
> V4L2_PIX_FMT_IPU3_SGRBG10
> V4L2_PIX_FMT_IPU3_SRGGB10
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Hyungwoo Yang 
> ---
>  Documentation/media/uapi/v4l/pixfmt-rgb.rst|   1 +
>  .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst | 166 
> +
>  2 files changed, 167 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
> b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> index 4cc27195dc79..cf2ef7df9616 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
> @@ -16,6 +16,7 @@ RGB Formats
>  pixfmt-srggb10p
>  pixfmt-srggb10alaw8
>  pixfmt-srggb10dpcm8
> +pixfmt-srggb10-ipu3
>  pixfmt-srggb12
>  pixfmt-srggb12p
>  pixfmt-srggb16
> diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst 
> b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
> new file mode 100644
> index ..50292186a8b4
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
> @@ -0,0 +1,166 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2_PIX_FMT_IPU3_SBGGR10:
> +.. _V4L2_PIX_FMT_IPU3_SGBRG10:
> +.. _V4L2_PIX_FMT_IPU3_SGRBG10:
> +.. _V4L2_PIX_FMT_IPU3_SRGGB10:
> +
> +**
> +V4L2_PIX_FMT_IPU3_SBGGR10 ('ip3b'), V4L2_PIX_FMT_IPU3_SGBRG10 ('ip3g'), 
> V4L2_PIX_FMT_IPU3_SGRBG10 ('ip3G'), V4L2_PIX_FMT_IPU3_SRGGB10 ('ip3r')
> +**
> +
> +10-bit Bayer formats
> +
> +Description
> +===
> +
> +These four pixel formats are used by Intel IPU3 driver, they are raw
> +sRGB / Bayer formats with 10 bits per sample with every 25 pixels packed
> +to 32 bytes leaving 6 most significant bits padding in the last byte.
> +The format is little endian.
> +
> +In other respects this format is similar to :ref:`V4L2-PIX-FMT-SRGGB10`.

You could add:

Below is an example of a small image in V4L2_PIX_FMT_IPU3_SBGGR10 format.

> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. raw:: latex
> +
> +\newline\newline\begin{adjustbox}{width=\columnwidth}
> +
> +.. tabularcolumns:: 
> |p{1.3cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|

The width of this table is over one metre. Could you use fewer columns in
it, say, four or eight?

> +
> +.. flat-table::
> +
> +* - start + 0:
> +  - B\ :sub:`low`
> +  - G\ :sub:`0001low` \ (bits 7--2) B\ :sub:`high`\ (bits 1--0)
> +  - B\ :sub:`0002low` \ (bits 7--4) G\ :sub:`0001high`\ (bits 3--0)
> +  - G\ :sub:`0003low` \ (bits 7--6) B\ :sub:`0002high`\ (bits 5--0)
> +  - G\ :sub:`0003high`
> +  - B\ :sub:`0004low`
> +  - G\ :sub:`0005low` \ (bits 7--2) B\ :sub:`0004high`\ (bits 1--0)
> +  - B\ :sub:`0006low` \ (bits 7--4) G\ :sub:`0005high`\ (bits 3--0)
> +  - G\ :sub:`0007low` \ (bits 7--6) B\ :sub:`0006high`\ (bits 5--0)
> +  - G\ :sub:`0007high`
> +  - B\ :sub:`0008low`
> +  - G\ :sub:`0009low` \ (bits 7--2) B\ :sub:`0008high`\ (bits 1--0)
> +  - B\ :sub:`0010low` \ (bits 7--4) G\ :sub:`0009high`\ (bits 3--0)
> +  - G\ :sub:`0011low` \ (bits 7--6) B\ :sub:`0010high`\ (bits 5--0)
> +  - G\ :sub:`0011high`
> +  - B\ :sub:`0012low`
> +  - G\ :sub:`0013low` \ (bits 7--2) B\ :sub:`0012high`\ (bits 1--0)
> +  - B\ :sub:`0014low` \ (bits 7--4) G\ :sub:`0013high`\ (bits 3--0)
> +  - G\ :sub:`0015low` \ (bits 7--6) B\ :sub:`0014high`\ (bits 5--0)
> +  - G\ :sub:`0015high`
> +  - B\ :sub:`0016low`
> +  - G\ :sub:`0017low` \ (bits 7--2) B\ :sub:`0016high`\ (bits 1--0)
> +  - B\ :sub:`0018low` \ (bits 7--4) G\ :sub:`0017high`\ (bits 3--0)
> +  - G\ :sub:`0019low` \ (bits 7--6) B\ :sub:`0018high`\ (bits 5--0)
> +  - G\ :sub:`0019high`
> +  - B\ :sub:`0020low`
> +  - G\ :sub:`0021low` \ (bits 7--2) B\ :sub:`0020high`\ (bits 1--0)
> +  - B\ :sub:`0022low` \ (bits 7--4) G\ :sub:`0021high`\ (bits 3--0)
> +  - G\ :sub:`0023low` \ (bits 7--6) B\ :sub:`0022high`\ (bits 5--0)
> +  - G\ :sub:`0023high`
> +  - B\ :sub:`0024low`
> +  - B\ :sub:`0024high`\ (bits 1--0)
> +* - start + 32:
> +  - G\ :sub:`0100low`
> +  - R\ :sub:`0101low` \ (bits 7--2) G\ :sub:`0100high`\ (bits 

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Fri, 6 Oct 2017 13:22:29 +0300
Sakari Ailus  escreveu:

> > +Bridge driver
> > +   The same as V4L2 main driver.  
> 
> Not all V4L2 main drivers can be bridge drivers. Mem-to-mem devices, for
> instance. How about:
> 
> A driver for a device receiving image data from another device (or
> transmitting it to a sub-device) controlled by a sub-device driver. Bridge
> drivers typically act as V4L2 main drivers.

That is not true for some device drivers we have.

The GSPCA drivers are bridge drivers, but they don't use any sub-device
(well, it should, but nobody will redesign it, as the efforts would
be huge, for a very little gain). Also uvcdriver doesn't need sub-device
drivers, as the camera's internal firmware does the interface with the
sensors.

We could, instead define it as:

Bridge driver
A driver that provides a bridge between the CPU's bus to the
data and control buses of a media hardware. Often, the
bridge driver is the same as V4L2 main driver.

Thanks,
Mauro

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Hans Verkuil]

On 10/10/2017 10:20 AM, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 09:47:13 +0200
> Hans Verkuil  escreveu:
> 
>> On 09/28/2017 12:23 AM, Mauro Carvalho Chehab wrote:
>>> Add a glossary of terms for V4L2, as several concepts are complex
>>> enough to cause misunderstandings.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>  Documentation/media/uapi/v4l/glossary.rst | 136 
>>> ++
>>>  Documentation/media/uapi/v4l/v4l2.rst |   1 +
>>>  2 files changed, 137 insertions(+)
>>>  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
>>>
>>> diff --git a/Documentation/media/uapi/v4l/glossary.rst 
>>> b/Documentation/media/uapi/v4l/glossary.rst
>>> new file mode 100644
>>> index ..b6767da1a46e
>>> --- /dev/null
>>> +++ b/Documentation/media/uapi/v4l/glossary.rst
>>> @@ -0,0 +1,136 @@
>>> +
>>> +Glossary
>>> +
>>> +
>>> +.. note::
>>> +
>>> +   This goal of section is to standardize the terms used within the V4L2
>>> +   documentation. It is written incrementally as they are standardized in
>>> +   the V4L2 documentation. So, it is a Work In Progress.
>>> +
>>> +.. Please keep the glossary entries in alphabetical order
>>> +
>>> +.. glossary::
>>> +
>>> +Bridge driver
>>> +   The same as V4L2 main driver.  
>>
>> Change this to the more standard phrase:
>>
>> See: V4L2 main driver.
>>
>>> +
>>> +Device Node
>>> +   A character device node in the file system used to control and do  
>>
>> and -> and/or
>>
>>> +   input/output data transfers from/to a Kernel driver.
>>> +
>>> +Digital Signal Processor - DSP
>>> +   A specialized microprocessor, with its architecture optimized for
>>> +   the operational needs of digital signal processing.  
>>
>> I'd say 'requirements' instead of 'needs'. I think that's a better term.
>>
>>> +
>>> +Driver
>>> +   The part of the Linux Kernel that implements support
>>> +   for a hardware component.
>>> +
>>> +Field-programmable Gate Array - FPGA
>>> +   A field-programmable gate array (FPGA) is an integrated circuit
>>> +   designed to be configured by a customer or a designer after
>>> +   manufacturing.
>>> +
>>> +   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
>>> +
>>> +Hardware component
>>> +   A subset of the media hardware. For example an I²C or SPI device,
>>> +   or an IP block inside an SoC or FPGA.
>>> +
>>> +Image Signal Processor - ISP
>>> +   A specialised processor that implements a set of algorithms for
>>> +   processing image data. ISPs may implement algorithms for lens
>>> +   shading correction, demosaic, scaling and pixel format conversion
>>> +   as well as produce statistics for the use of the control
>>> +   algorithms (e.g. automatic exposure, white balance and focus).
>>> +
>>> +Inter-Integrated Circuit - I²C
>>> +   A  multi-master, multi-slave, packet switched, single-ended,
>>> +   serial computer bus used to control V4L2 sub-devices.  
>>
>> I'd rephrase this a bit:
>>
>>  A  multi-master, multi-slave, packet switched, single-ended,
>>  serial computer bus. Most V4L2 sub-devices are controlled via
>>  this bus.
>>
>> Your text suggested that i2c is used exclusively for V4L2 subdevs, but
>> of course it is used for many other devices as well.
>>
>>> +
>>> +   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
>>> +
>>> +Integrated circuit - IC
>>> +   A set of electronic circuits on one small flat piece of
>>> +   semiconductor material, normally silicon.
>>> +
>>> +   Also known as chip.  
>>
>> Perhaps add an entry for 'Chip' as well, with a 'See: Integrated circuit' as
>> description? Just to be consistent.
>>
>>> +
>>> +Intellectual property core - IP core
>>> +   In electronic design a semiconductor intellectual property core,
>>> +   is a reusable unit of logic, cell, or integrated circuit layout
>>> +   design that is the intellectual property of one party.
>>> +   IP cores may be licensed to another party or can be owned
>>> +   and used by a single party alone.
>>> +
>>> +   See 
>>> https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
>>> +
>>> +IP block
>>> +   The same as IP core.  
>>
>> 'See: '
>>
>>> +
>>> +MC-centric
>>> +   V4L2 hardware that requires a Media controller.
>>> +
>>> +   See :ref:`v4l2_hardware_control`.
>>> +
>>> +Media Controller
>>> +   An API designed to expose and control devices and sub-devices
>>> +   relationships to applications.  
>>
>> This sentence is not clear. I propose this:
>>
>>  An API designed to expose and control the relationships of the Media
>>  Harware to applications.
>>
>>> +
>>> +   See :ref:`media_controller`.
>>> +
>>> +Media hardware
>>> +   A group of hardware components that together make a larger
>>> +   user-facing functional media hardware. For instance the SoC ISP IP  
>>
>> I'd just say "form the functional". The term 'user-facing' is out of 

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Mauro Carvalho Chehab]

Em Tue, 10 Oct 2017 09:47:13 +0200
Hans Verkuil  escreveu:

> On 09/28/2017 12:23 AM, Mauro Carvalho Chehab wrote:
> > Add a glossary of terms for V4L2, as several concepts are complex
> > enough to cause misunderstandings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/media/uapi/v4l/glossary.rst | 136 
> > ++
> >  Documentation/media/uapi/v4l/v4l2.rst |   1 +
> >  2 files changed, 137 insertions(+)
> >  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> > 
> > diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> > b/Documentation/media/uapi/v4l/glossary.rst
> > new file mode 100644
> > index ..b6767da1a46e
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/glossary.rst
> > @@ -0,0 +1,136 @@
> > +
> > +Glossary
> > +
> > +
> > +.. note::
> > +
> > +   This goal of section is to standardize the terms used within the V4L2
> > +   documentation. It is written incrementally as they are standardized in
> > +   the V4L2 documentation. So, it is a Work In Progress.
> > +
> > +.. Please keep the glossary entries in alphabetical order
> > +
> > +.. glossary::
> > +
> > +Bridge driver
> > +   The same as V4L2 main driver.  
> 
> Change this to the more standard phrase:
> 
> See: V4L2 main driver.
> 
> > +
> > +Device Node
> > +   A character device node in the file system used to control and do  
> 
> and -> and/or
> 
> > +   input/output data transfers from/to a Kernel driver.
> > +
> > +Digital Signal Processor - DSP
> > +   A specialized microprocessor, with its architecture optimized for
> > +   the operational needs of digital signal processing.  
> 
> I'd say 'requirements' instead of 'needs'. I think that's a better term.
> 
> > +
> > +Driver
> > +   The part of the Linux Kernel that implements support
> > +   for a hardware component.
> > +
> > +Field-programmable Gate Array - FPGA
> > +   A field-programmable gate array (FPGA) is an integrated circuit
> > +   designed to be configured by a customer or a designer after
> > +   manufacturing.
> > +
> > +   See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> > +
> > +Hardware component
> > +   A subset of the media hardware. For example an I²C or SPI device,
> > +   or an IP block inside an SoC or FPGA.
> > +
> > +Image Signal Processor - ISP
> > +   A specialised processor that implements a set of algorithms for
> > +   processing image data. ISPs may implement algorithms for lens
> > +   shading correction, demosaic, scaling and pixel format conversion
> > +   as well as produce statistics for the use of the control
> > +   algorithms (e.g. automatic exposure, white balance and focus).
> > +
> > +Inter-Integrated Circuit - I²C
> > +   A  multi-master, multi-slave, packet switched, single-ended,
> > +   serial computer bus used to control V4L2 sub-devices.  
> 
> I'd rephrase this a bit:
> 
>   A  multi-master, multi-slave, packet switched, single-ended,
>   serial computer bus. Most V4L2 sub-devices are controlled via
>   this bus.
> 
> Your text suggested that i2c is used exclusively for V4L2 subdevs, but
> of course it is used for many other devices as well.
> 
> > +
> > +   See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> > +
> > +Integrated circuit - IC
> > +   A set of electronic circuits on one small flat piece of
> > +   semiconductor material, normally silicon.
> > +
> > +   Also known as chip.  
> 
> Perhaps add an entry for 'Chip' as well, with a 'See: Integrated circuit' as
> description? Just to be consistent.
> 
> > +
> > +Intellectual property core - IP core
> > +   In electronic design a semiconductor intellectual property core,
> > +   is a reusable unit of logic, cell, or integrated circuit layout
> > +   design that is the intellectual property of one party.
> > +   IP cores may be licensed to another party or can be owned
> > +   and used by a single party alone.
> > +
> > +   See 
> > https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> > +
> > +IP block
> > +   The same as IP core.  
> 
> 'See: '
> 
> > +
> > +MC-centric
> > +   V4L2 hardware that requires a Media controller.
> > +
> > +   See :ref:`v4l2_hardware_control`.
> > +
> > +Media Controller
> > +   An API designed to expose and control devices and sub-devices
> > +   relationships to applications.  
> 
> This sentence is not clear. I propose this:
> 
>   An API designed to expose and control the relationships of the Media
>   Harware to applications.
> 
> > +
> > +   See :ref:`media_controller`.
> > +
> > +Media hardware
> > +   A group of hardware components that together make a larger
> > +   user-facing functional media hardware. For instance the SoC ISP IP  
> 
> I'd just say "form the functional". The term 'user-facing' is out of place 
> here.
> 
> > +   cores and external camera sensors together 

Re: [PATCH v4 0/5] media: atmel-isc: Rework the format list and clock provider

[Sakari Ailus]

On Tue, Oct 10, 2017 at 10:46:35AM +0800, Wenyou Yang wrote:
> To improve the readability of code, rework the format list table,
> split the format array into two. Meanwhile, fix the issue of the
> clock provider operation and the pm runtime support.
> 
> Changes in v4:
>  - Call pm_runtime_get_sync() and pm_runtime_put_sync() in ->prepare
>and ->unprepare callback.
>  - Move pm_runtime_enable() call from the complete callback to the
>end of probe.
>  - Call pm_runtime_get_sync() and pm_runtime_put_sync() in
>->is_enabled() callbacks.
>  - Call clk_disable_unprepare() in ->remove callback.
> 
> Changes in v3:
>  - Fix the wrong used spinlock.
>  - s/_/- on the subject.
>  - Add a new flag for Raw Bayer format to remove MAX_RAW_FMT_INDEX define.
>  - Add the comments for define of the format flag.
>  - Rebase media_tree/master.
> 
> Changes in v2:
>  - Add the new patch to remove the unnecessary member from
>isc_subdev_entity struct.
>  - Rebase on the patch set,
> [PATCH 0/6] [media] Atmel: Adjustments for seven function 
> implementations
> 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html
> 
> Wenyou Yang (5):
>   media: atmel-isc: Add spin lock for clock enable ops
>   media: atmel-isc: Add prepare and unprepare ops
>   media: atmel-isc: Enable the clocks during probe
>   media: atmel-isc: Remove unnecessary member
>   media: atmel-isc: Rework the format list
> 
>  drivers/media/platform/atmel/atmel-isc-regs.h |   1 +
>  drivers/media/platform/atmel/atmel-isc.c  | 629 
> --
>  2 files changed, 498 insertions(+), 132 deletions(-)

Thanks for the update!!

For patches 0--4:

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v7 7/7] media: open.rst: add a notice about subdev-API on vdev-centric

[Hans Verkuil]

On 09/28/2017 12:23 AM, Mauro Carvalho Chehab wrote:
> The documentation doesn't mention if vdev-centric hardware
> control would have subdev API or not.
> 
> Add a notice about that, reflecting the current status, where
> three drivers use it, in order to support some subdev-specific
> controls.

Just to note that there is a pull request pending from me that
removes this from the cobalt driver. So once that's merged there
are only two drivers that do this.

Anyway:

Acked-by: Hans Verkuil 

Regards,

Hans

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index 75ccc9d6614d..ed011ed123cc 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -47,6 +47,13 @@ the periferal can be used. For such devices, the 
> sub-devices' configuration
>  can be controlled via the :ref:`sub-device API `, which creates one
>  device node per sub-device.
>  
> +.. note::
> +
> +   A **vdevnode-centric** may also optionally expose V4L2 sub-devices via
> +   :ref:`sub-device API `. In that case, it has to implement
> +   the :ref:`media controller API ` as well.
> +
> +
>  .. attention::
>  
> Devices that require **MC-centric** media hardware control should
> 

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

[Marek Szyprowski]

Hi Stanimir,

On 2017-10-10 09:42, Stanimir Varbanov wrote:

Marek,

Any comments?


Oh, I thought that this one has been already merged. If not (yet),
here is my ack.


On 08/29/2017 02:26 PM, Stanimir Varbanov wrote:

Currently videobuf2-dma-sg checks for dma direction for
every single page and videobuf2-dc lacks any dma direction
checks and calls set_page_dirty_lock unconditionally.

Thus unify and align the invocations of set_page_dirty_lock
for videobuf2-dc, videobuf2-sg  memory allocators with
videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
copied to dc and dma-sg.

Suggested-by: Marek Szyprowski 
Signed-off-by: Stanimir Varbanov 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 --
  drivers/media/v4l2-core/videobuf2-dma-sg.c | 7 +++
  2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 9f389f36566d..696e24f9128d 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -434,8 +434,10 @@ static void vb2_dc_put_userptr(void *buf_priv)
pages = frame_vector_pages(buf->vec);
/* sgt should exist only if vector contains pages... */
BUG_ON(IS_ERR(pages));
-   for (i = 0; i < frame_vector_count(buf->vec); i++)
-   set_page_dirty_lock(pages[i]);
+   if (buf->dma_dir == DMA_FROM_DEVICE ||
+   buf->dma_dir == DMA_BIDIRECTIONAL)
+   for (i = 0; i < frame_vector_count(buf->vec); i++)
+   set_page_dirty_lock(pages[i]);
sg_free_table(sgt);
kfree(sgt);
}
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 6808231a6bdc..753ed3138dcc 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -292,11 +292,10 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
-   while (--i >= 0) {
-   if (buf->dma_dir == DMA_FROM_DEVICE ||
-   buf->dma_dir == DMA_BIDIRECTIONAL)
+   if (buf->dma_dir == DMA_FROM_DEVICE ||
+   buf->dma_dir == DMA_BIDIRECTIONAL)
+   while (--i >= 0)
set_page_dirty_lock(buf->pages[i]);
-   }
vb2_destroy_framevec(buf->vec);
kfree(buf);
  }



Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v7 6/7] media: videodev2: add a flag for MC-centric devices

[Hans Verkuil]

On 09/28/2017 12:23 AM, Mauro Carvalho Chehab wrote:
> As both vdev-centric and MC-centric devices may implement the
> same APIs, we need a flag to allow userspace to distinguish
> between them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst| 7 +++
>  Documentation/media/uapi/v4l/vidioc-querycap.rst | 5 +
>  Documentation/media/videodev2.h.rst.exceptions   | 1 +
>  include/uapi/linux/videodev2.h   | 2 ++
>  4 files changed, 15 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index 0daf0c122c19..75ccc9d6614d 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -47,6 +47,13 @@ the periferal can be used. For such devices, the 
> sub-devices' configuration
>  can be controlled via the :ref:`sub-device API `, which creates one
>  device node per sub-device.
>  
> +.. attention::
> +
> +   Devices that require **MC-centric** media hardware control should

should -> shall

After that change you can add my:

Acked-by: Hans Verkuil 

Regards,

Hans


> +   report a ``V4L2_MC_CENTRIC`` :c:type:`v4l2_capability` flag
> +   (see :ref:`VIDIOC_QUERYCAP`).
> +
> +
>  .. _v4l2_device_naming:
>  
>  V4L2 Device Node Naming
> diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
> b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> index 66fb1b3d6e6e..944bc5ba484f 100644
> --- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> @@ -254,6 +254,11 @@ specification the ioctl returns an ``EINVAL`` error code.
>  * - ``V4L2_CAP_TOUCH``
>- 0x1000
>- This is a touch device.
> +* - ``V4L2_MC_CENTRIC``
> +  - 0x2000
> +  - Indicates that the device require **MC-centric** hardware
> +control, and thus can't be used by **vdevnode-centric** applications.
> +See :ref:`v4l2_hardware_control` for more details.
>  * - ``V4L2_CAP_DEVICE_CAPS``
>- 0x8000
>- The driver fills the ``device_caps`` field. This capability can
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index a5cb0a8686ac..b51a575f9f75 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -157,6 +157,7 @@ replace define V4L2_CAP_META_CAPTURE device-capabilities
>  replace define V4L2_CAP_READWRITE device-capabilities
>  replace define V4L2_CAP_ASYNCIO device-capabilities
>  replace define V4L2_CAP_STREAMING device-capabilities
> +replace define V4L2_CAP_MC_CENTRIC device-capabilities
>  replace define V4L2_CAP_DEVICE_CAPS device-capabilities
>  replace define V4L2_CAP_TOUCH device-capabilities
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 185d6a0acc06..4ff1224719a7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -460,6 +460,8 @@ struct v4l2_capability {
>  
>  #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
>  
> +#define V4L2_CAP_MC_CENTRIC 0x2000  /* Device require 
> MC-centric hardware control */
> +
>  #define V4L2_CAP_DEVICE_CAPS0x8000  /* sets device 
> capabilities field */
>  
>  /*
> 

[PATCH v2] media: venus: venc: fix bytesused v4l2_plane field

[Stanimir Varbanov]

This fixes wrongly filled bytesused field of v4l2_plane structure
by include data_offset in the plane, Also fill data_offset and
bytesused for capture type of buffers only.

Signed-off-by: Stanimir Varbanov 
---
v2: Just delete pointless WARN_ON.

 drivers/media/platform/qcom/venus/venc.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 6f123a387cf9..3fcf0e9b7b29 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -963,13 +963,12 @@ static void venc_buf_done(struct venus_inst *inst, 
unsigned int buf_type,
if (!vbuf)
return;
 
-   vb = >vb2_buf;
-   vb->planes[0].bytesused = bytesused;
-   vb->planes[0].data_offset = data_offset;
-
vbuf->flags = flags;
 
if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+   vb = >vb2_buf;
+   vb2_set_plane_payload(vb, 0, bytesused + data_offset);
+   vb->planes[0].data_offset = data_offset;
vb->timestamp = timestamp_us * NSEC_PER_USEC;
vbuf->sequence = inst->sequence_cap++;
} else {
-- 
2.11.0

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Hans Verkuil]

On 09/28/2017 12:23 AM, Mauro Carvalho Chehab wrote:
> Add a glossary of terms for V4L2, as several concepts are complex
> enough to cause misunderstandings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/glossary.rst | 136 
> ++
>  Documentation/media/uapi/v4l/v4l2.rst |   1 +
>  2 files changed, 137 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> 
> diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> b/Documentation/media/uapi/v4l/glossary.rst
> new file mode 100644
> index ..b6767da1a46e
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/glossary.rst
> @@ -0,0 +1,136 @@
> +
> +Glossary
> +
> +
> +.. note::
> +
> +   This goal of section is to standardize the terms used within the V4L2
> +   documentation. It is written incrementally as they are standardized in
> +   the V4L2 documentation. So, it is a Work In Progress.
> +
> +.. Please keep the glossary entries in alphabetical order
> +
> +.. glossary::
> +
> +Bridge driver
> + The same as V4L2 main driver.

Change this to the more standard phrase:

See: V4L2 main driver.

> +
> +Device Node
> + A character device node in the file system used to control and do

and -> and/or

> + input/output data transfers from/to a Kernel driver.
> +
> +Digital Signal Processor - DSP
> + A specialized microprocessor, with its architecture optimized for
> + the operational needs of digital signal processing.

I'd say 'requirements' instead of 'needs'. I think that's a better term.

> +
> +Driver
> + The part of the Linux Kernel that implements support
> + for a hardware component.
> +
> +Field-programmable Gate Array - FPGA
> + A field-programmable gate array (FPGA) is an integrated circuit
> + designed to be configured by a customer or a designer after
> + manufacturing.
> +
> + See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> +
> +Hardware component
> + A subset of the media hardware. For example an I²C or SPI device,
> + or an IP block inside an SoC or FPGA.
> +
> +Image Signal Processor - ISP
> + A specialised processor that implements a set of algorithms for
> + processing image data. ISPs may implement algorithms for lens
> + shading correction, demosaic, scaling and pixel format conversion
> + as well as produce statistics for the use of the control
> + algorithms (e.g. automatic exposure, white balance and focus).
> +
> +Inter-Integrated Circuit - I²C
> + A  multi-master, multi-slave, packet switched, single-ended,
> + serial computer bus used to control V4L2 sub-devices.

I'd rephrase this a bit:

A  multi-master, multi-slave, packet switched, single-ended,
serial computer bus. Most V4L2 sub-devices are controlled via
this bus.

Your text suggested that i2c is used exclusively for V4L2 subdevs, but
of course it is used for many other devices as well.

> +
> + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> +
> +Integrated circuit - IC
> + A set of electronic circuits on one small flat piece of
> + semiconductor material, normally silicon.
> +
> + Also known as chip.

Perhaps add an entry for 'Chip' as well, with a 'See: Integrated circuit' as
description? Just to be consistent.

> +
> +Intellectual property core - IP core
> + In electronic design a semiconductor intellectual property core,
> + is a reusable unit of logic, cell, or integrated circuit layout
> + design that is the intellectual property of one party.
> + IP cores may be licensed to another party or can be owned
> + and used by a single party alone.
> +
> + See 
> https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> +
> +IP block
> + The same as IP core.

'See: '

> +
> +MC-centric
> + V4L2 hardware that requires a Media controller.
> +
> + See :ref:`v4l2_hardware_control`.
> +
> +Media Controller
> + An API designed to expose and control devices and sub-devices
> + relationships to applications.

This sentence is not clear. I propose this:

An API designed to expose and control the relationships of the Media
Harware to applications.

> +
> + See :ref:`media_controller`.
> +
> +Media hardware
> + A group of hardware components that together make a larger
> + user-facing functional media hardware. For instance the SoC ISP IP

I'd just say "form the functional". The term 'user-facing' is out of place here.

> + cores and external camera sensors together make a

make a -> form the

Possible synonym for 'form': 'constitute'. I'm OK with either.

> + camera media hardware.
> +
> +Media hardware control
> + Type of control for a media hardware supported by V4L2 drivers.
> +
> + See :ref:`v4l2_hardware_control`.
> +
> +

Re: [PATCH v5 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Sakari Ailus]

Hi Yong,

Thanks for the update! Please see my comments below.

On Fri, Oct 06, 2017 at 06:39:01PM -0500, Yong Zhi wrote:
> This patch adds CIO2 CSI-2 device driver for
> Intel's IPU3 camera sub-system support.
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Hyungwoo Yang 
> Signed-off-by: Rajmohan Mani 
> Signed-off-by: Vijaykumar Ramya 
> ---
>  drivers/media/pci/Kconfig|2 +
>  drivers/media/pci/Makefile   |3 +-
>  drivers/media/pci/intel/Makefile |5 +
>  drivers/media/pci/intel/ipu3/Kconfig |   19 +
>  drivers/media/pci/intel/ipu3/Makefile|1 +
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 2052 
> ++
>  drivers/media/pci/intel/ipu3/ipu3-cio2.h |  452 +++
>  7 files changed, 2533 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/intel/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
>  create mode 100644 drivers/media/pci/intel/ipu3/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h
> 
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index da28e68c87d8..5932e225f9c0 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
>  source "drivers/media/pci/netup_unidvb/Kconfig"
>  endif
>  
> +source "drivers/media/pci/intel/ipu3/Kconfig"
> +
>  endif #MEDIA_PCI_SUPPORT
>  endif #PCI
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index a7e8af0f64a7..d8f98434fb8c 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -13,7 +13,8 @@ obj-y+= ttpci/  \
>   ddbridge/   \
>   saa7146/\
>   smipcie/\
> - netup_unidvb/
> + netup_unidvb/   \
> + intel/
>  
>  obj-$(CONFIG_VIDEO_IVTV) += ivtv/
>  obj-$(CONFIG_VIDEO_ZORAN) += zoran/
> diff --git a/drivers/media/pci/intel/Makefile 
> b/drivers/media/pci/intel/Makefile
> new file mode 100644
> index ..745c8b2a7819
> --- /dev/null
> +++ b/drivers/media/pci/intel/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the IPU3 cio2 and ImGU drivers
> +#
> +
> +obj-y+= ipu3/
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> new file mode 100644
> index ..0861077a4dae
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -0,0 +1,19 @@
> +config VIDEO_IPU3_CIO2
> + tristate "Intel ipu3-cio2 driver"
> + depends on VIDEO_V4L2 && PCI
> + depends on VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CONTROLLER
> + depends on HAS_DMA
> + depends on ACPI
> + depends on X86_64 || COMPILE_TEST

Why X86_64?

> + select V4L2_FWNODE
> + select VIDEOBUF2_DMA_SG
> +
> + ---help---
> + This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
> + Skylake and Kaby Lake SoCs and used for capturing images and
> + video from a camera sensor.
> +
> + Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> + connected camera.
> + The module will be called ipu3-cio2.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> new file mode 100644
> index ..20186e3ff2ae
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> new file mode 100644
> index ..2c2faa8f1d25
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> @@ -0,0 +1,2052 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Based partially on Intel IPU4 driver written by
> + *  Sakari Ailus 
> + *  Samu Onkalo 
> + *  Jouni Högander 
> + *  Jouni Ukkonen 
> + *  Antti Laakso 
> + * et al.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3-cio2.h"
> +
> +struct ipu3_cio2_fmt {
> + u32 mbus_code;
> + u32 fourcc;

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

[Stanimir Varbanov]

Marek,

Any comments?

On 08/29/2017 02:26 PM, Stanimir Varbanov wrote:
> Currently videobuf2-dma-sg checks for dma direction for
> every single page and videobuf2-dc lacks any dma direction
> checks and calls set_page_dirty_lock unconditionally.
> 
> Thus unify and align the invocations of set_page_dirty_lock
> for videobuf2-dc, videobuf2-sg  memory allocators with
> videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
> copied to dc and dma-sg.
> 
> Suggested-by: Marek Szyprowski 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 --
>  drivers/media/v4l2-core/videobuf2-dma-sg.c | 7 +++
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 9f389f36566d..696e24f9128d 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -434,8 +434,10 @@ static void vb2_dc_put_userptr(void *buf_priv)
>   pages = frame_vector_pages(buf->vec);
>   /* sgt should exist only if vector contains pages... */
>   BUG_ON(IS_ERR(pages));
> - for (i = 0; i < frame_vector_count(buf->vec); i++)
> - set_page_dirty_lock(pages[i]);
> + if (buf->dma_dir == DMA_FROM_DEVICE ||
> + buf->dma_dir == DMA_BIDIRECTIONAL)
> + for (i = 0; i < frame_vector_count(buf->vec); i++)
> + set_page_dirty_lock(pages[i]);
>   sg_free_table(sgt);
>   kfree(sgt);
>   }
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> index 6808231a6bdc..753ed3138dcc 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> @@ -292,11 +292,10 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
>   if (buf->vaddr)
>   vm_unmap_ram(buf->vaddr, buf->num_pages);
>   sg_free_table(buf->dma_sgt);
> - while (--i >= 0) {
> - if (buf->dma_dir == DMA_FROM_DEVICE ||
> - buf->dma_dir == DMA_BIDIRECTIONAL)
> + if (buf->dma_dir == DMA_FROM_DEVICE ||
> + buf->dma_dir == DMA_BIDIRECTIONAL)
> + while (--i >= 0)
>   set_page_dirty_lock(buf->pages[i]);
> - }
>   vb2_destroy_framevec(buf->vec);
>   kfree(buf);
>  }
> 

-- 
regards,
Stan

[PATCH v3 25/26] media: MAINTAINERS: add entry for zilog_ir

[Sean Young]

Add MAINTAINER's entry for this new driver ported from staging.

Signed-off-by: Sean Young 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fb5f548a568e..15d32348e902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14876,6 +14876,12 @@ Q: 
https://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/zd1301_demod*
 
+ZILOG/HAUPPAUGE IR TRANSMITTER
+M: Sean Young 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/rc/zilog_ir.c
+
 ZPOOL COMPRESSED PAGE STORAGE API
 M: Dan Streetman 
 L: linux...@kvack.org
-- 
2.13.6

[PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Sean Young]

If you try to store u64 in a kfifo (or a struct with u64 members),
then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
padding due to alignment (note that struct __kfifo is 20 bytes
on 32 bit).

That in turn causes the __is_kfifo_ptr() to fail, which is caught
by kfifo_alloc(), which now returns EINVAL.

So, ensure that __is_kfifo_ptr() compares to the right structure.

Signed-off-by: Sean Young 
---
 include/linux/kfifo.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 41eb6fdf87a8..86b5fb08e96c 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2 __STRUCT_KFIFO_PTR(unsigned char, 2, 
void);
  * array is a part of the structure and the fifo type where the array is
  * outside of the fifo structure.
  */
-#define__is_kfifo_ptr(fifo)(sizeof(*fifo) == sizeof(struct 
__kfifo))
+#define__is_kfifo_ptr(fifo) \
+   (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)->type
 
 /**
  * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object
-- 
2.13.6

[PATCH v3 24/26] media: MAINTAINERS: remove lirc staging area

[Sean Young]

Now that lirc is no longer in the staging area, remove the entry.

Signed-off-by: Sean Young 
---
 MAINTAINERS | 6 --
 1 file changed, 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a8126830829b..fb5f548a568e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12677,12 +12677,6 @@ S: Odd Fixes
 F: Documentation/devicetree/bindings/staging/iio/
 F: drivers/staging/iio/
 
-STAGING - LIRC (LINUX INFRARED REMOTE CONTROL) DRIVERS
-M: Jarod Wilson 
-W: http://www.lirc.org/
-S: Odd Fixes
-F: drivers/staging/media/lirc/
-
 STAGING - LUSTRE PARALLEL FILESYSTEM
 M: Oleg Drokin 
 M: Andreas Dilger 
-- 
2.13.6

[PATCH v3 23/26] media: lirc: scancode rc devices should have a lirc device too

[Sean Young]

Now that the lirc interface supports scancodes, RC scancode devices
can also have a lirc device. The only feature they will have
enabled is LIRC_CAN_REC_SCANCODE.

Note that CEC devices have no lirc device, since they can be controlled
from their /dev/cecN chardev.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 34 ++
 drivers/media/rc/lirc_dev.c  |  9 +++--
 drivers/media/rc/rc-main.c   |  6 +++---
 3 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 559a4049151e..6f1d9dd766d5 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -309,6 +309,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
 
switch (cmd) {
case LIRC_GET_FEATURES:
+   if (dev->driver_type == RC_DRIVER_SCANCODE)
+   val |= LIRC_CAN_REC_SCANCODE;
+
if (dev->driver_type == RC_DRIVER_IR_RAW) {
val |= LIRC_CAN_REC_MODE2 | LIRC_CAN_REC_SCANCODE;
if (dev->rx_resolution)
@@ -352,22 +355,37 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
break;
 
case LIRC_SET_REC_MODE:
-   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   switch (dev->driver_type) {
+   case RC_DRIVER_IR_RAW_TX:
return -ENOTTY;
-
-   if (!(val == LIRC_MODE_MODE2 || val == LIRC_MODE_SCANCODE))
-   return -EINVAL;
+   case RC_DRIVER_SCANCODE:
+   if (val != LIRC_MODE_SCANCODE)
+   return -EINVAL;
+   break;
+   case RC_DRIVER_IR_RAW:
+   if (!(val == LIRC_MODE_MODE2 ||
+ val == LIRC_MODE_SCANCODE))
+   return -EINVAL;
+   break;
+   }
 
dev->rec_mode = val;
dev->poll_mode = val;
return 0;
 
case LIRC_SET_POLL_MODES:
-   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   switch (dev->driver_type) {
+   case RC_DRIVER_IR_RAW_TX:
return -ENOTTY;
-
-   if (val & ~(LIRC_MODE_MODE2 | LIRC_MODE_SCANCODE))
-   return -EINVAL;
+   case RC_DRIVER_SCANCODE:
+   if (val != LIRC_MODE_SCANCODE)
+   return -EINVAL;
+   break;
+   case RC_DRIVER_IR_RAW:
+   if (val & ~(LIRC_MODE_MODE2 | LIRC_MODE_SCANCODE))
+   return -EINVAL;
+   break;
+   }
 
dev->poll_mode = val;
return 0;
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index aee7cbb04439..6fc1ec257153 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -61,8 +61,13 @@ int ir_lirc_register(struct rc_dev *dev)
else
dev->send_mode = LIRC_MODE_PULSE;
 
-   dev->rec_mode = LIRC_MODE_MODE2;
-   dev->poll_mode = LIRC_MODE_MODE2;
+   if (dev->driver_type == RC_DRIVER_SCANCODE) {
+   dev->rec_mode = LIRC_MODE_SCANCODE;
+   dev->poll_mode = LIRC_MODE_SCANCODE;
+   } else {
+   dev->rec_mode = LIRC_MODE_MODE2;
+   dev->poll_mode = LIRC_MODE_MODE2;
+   }
 
if (dev->driver_type == RC_DRIVER_IR_RAW) {
if (kfifo_alloc(>rawir, MAX_IR_EVENT_SIZE, GFP_KERNEL))
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dae427e25d71..9f39bc074837 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1810,7 +1810,7 @@ int rc_register_device(struct rc_dev *dev)
}
 
/* Ensure that the lirc kfifo is setup before we start the thread */
-   if (dev->driver_type != RC_DRIVER_SCANCODE) {
+   if (dev->allowed_protocols != RC_PROTO_BIT_CEC) {
rc = ir_lirc_register(dev);
if (rc < 0)
goto out_rx;
@@ -1831,7 +1831,7 @@ int rc_register_device(struct rc_dev *dev)
return 0;
 
 out_lirc:
-   if (dev->driver_type != RC_DRIVER_SCANCODE)
+   if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_unregister(dev);
 out_rx:
rc_free_rx_device(dev);
@@ -1892,7 +1892,7 @@ void rc_unregister_device(struct rc_dev *dev)
 * lirc device should be freed with dev->registered = false, so
 * that userspace polling will get notified.
 */
-   if (dev->driver_type != RC_DRIVER_SCANCODE)
+   if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
ir_lirc_unregister(dev);
 
device_del(>dev);
-- 
2.13.6

[PATCH v3 21/26] media: lirc: document LIRC_MODE_SCANCODE

[Sean Young]

Lirc supports a new mode which requires documentation.

Signed-off-by: Sean Young 
---
 Documentation/media/lirc.h.rst.exceptions  | 26 +++
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 51 +++---
 Documentation/media/uapi/rc/lirc-get-features.rst  | 16 +++
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  3 +-
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |  3 +-
 Documentation/media/uapi/rc/lirc-read.rst  | 15 +--
 Documentation/media/uapi/rc/lirc-write.rst | 19 ++--
 7 files changed, 118 insertions(+), 15 deletions(-)

diff --git a/Documentation/media/lirc.h.rst.exceptions 
b/Documentation/media/lirc.h.rst.exceptions
index 63ba1d341905..c6e3a35d2c4e 100644
--- a/Documentation/media/lirc.h.rst.exceptions
+++ b/Documentation/media/lirc.h.rst.exceptions
@@ -32,6 +32,32 @@ ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
 
 ignore ioctl LIRC_GET_LENGTH
 
+# rc protocols
+
+ignore symbol RC_PROTO_UNKNOWN
+ignore symbol RC_PROTO_OTHER
+ignore symbol RC_PROTO_RC5
+ignore symbol RC_PROTO_RC5X_20
+ignore symbol RC_PROTO_RC5_SZ
+ignore symbol RC_PROTO_JVC
+ignore symbol RC_PROTO_SONY12
+ignore symbol RC_PROTO_SONY15
+ignore symbol RC_PROTO_SONY20
+ignore symbol RC_PROTO_NEC
+ignore symbol RC_PROTO_NECX
+ignore symbol RC_PROTO_NEC32
+ignore symbol RC_PROTO_SANYO
+ignore symbol RC_PROTO_MCIR2_KBD
+ignore symbol RC_PROTO_MCIR2_MSE
+ignore symbol RC_PROTO_RC6_0
+ignore symbol RC_PROTO_RC6_6A_20
+ignore symbol RC_PROTO_RC6_6A_24
+ignore symbol RC_PROTO_RC6_6A_32
+ignore symbol RC_PROTO_RC6_MCE
+ignore symbol RC_PROTO_SHARP
+ignore symbol RC_PROTO_XMP
+ignore symbol RC_PROTO_CEC
+
 # Undocumented macros
 
 ignore define PULSE_BIT
diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index a3fa3c1ef169..47c6c218e72a 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -6,11 +6,12 @@
 Introduction
 
 
-The LIRC device interface is a bi-directional interface for transporting
-raw IR data between userspace and kernelspace. Fundamentally, it is just
-a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number of standard
-struct file_operations defined on it. With respect to transporting raw
-IR data to and fro, the essential fops are read, write and ioctl.
+LIRC stands for Linux Infrared Remote Control. The LIRC device interface is
+a bi-directional interface for transporting raw IR and decoded scancodes
+data between userspace and kernelspace. Fundamentally, it is just a chardev
+(/dev/lircX, for X = 0, 1, 2, ...), with a number of standard struct
+file_operations defined on it. With respect to transporting raw IR and
+decoded scancodes to and fro, the essential fops are read, write and ioctl.
 
 Example dmesg output upon a driver registering w/LIRC:
 
@@ -36,6 +37,46 @@ LIRC modes
 LIRC supports some modes of receiving and sending IR codes, as shown
 on the following table.
 
+.. _lirc-mode-scancode:
+.. _lirc-scancode-flag-toggle:
+.. _lirc-scancode-flag-repeat:
+
+``LIRC_MODE_SCANCODE``
+
+This mode is for both sending and receiving IR.
+
+For transmitting (aka sending), create a ``struct lirc_scancode`` with
+the desired scancode set in the ``scancode`` member, ``rc_proto`` set
+the IR protocol, and all other members set to 0. Write this struct to
+the lirc device.
+
+For receiving, you read ``struct lirc_scancode`` from the lirc device,
+with ``scancode`` set to the received scancode and the IR protocol
+``rc_proto``. If the scancode maps to a valid key code, this is set
+in the ``keycode`` field, else it is set to ``KEY_RESERVED``.
+
+The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set if the toggle
+bit is set in protocols that support it (e.g. rc-5 and rc-6), or
+``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for protocols
+that support it (e.g. nec).
+
+In the Sanyo and NEC protocol, if you hold a button on remote, rather than
+repeating the entire scancode, the remote sends a shorter message with
+no scancode, which just means button is held, a "repeat". When this is
+received, the ``LIRC_SCANCODE_FLAG_REPEAT`` is set and the scancode and
+keycode is repeated.
+
+With nec, there is no way to distinguish "button hold" from "repeatedly
+pressing the same button". The rc-5 and rc-6 protocols have a toggle bit.
+When a button is released and pressed again, the toggle bit is inverted.
+If the toggle bit is set, the ``LIRC_SCANCODE_FLAG_TOGGLE`` is set.
+
+The ``timestamp`` field is filled with the time nanoseconds
+(in ``CLOCK_MONOTONIC``) when the scancode was decoded.
+
+An ``enum rc_proto`` in the :ref:`lirc_header` lists all the supported
+IR protocols.
+
 .. _lirc-mode-mode2:
 
 ``LIRC_MODE_MODE2``
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 

[PATCH v3 19/26] media: lirc: implement reading scancode

[Sean Young]

This implements LIRC_MODE_SCANCODE reading from the lirc device. The
scancode can be read from the input device too, but with this interface
you get the rc protocol, keycode, toggle and repeat status in addition
to just the scancode.

int main()
{
int fd, mode, rc;
fd = open("/dev/lirc0", O_RDWR);

mode = LIRC_MODE_SCANCODE;
if (ioctl(fd, LIRC_SET_REC_MODE, )) {
// kernel too old or lirc does not support transmit
}
struct lirc_scancode scancode;
while (read(fd, , sizeof(scancode)) == sizeof(scancode)) {
printf("protocol:%d scancode:0x%x toggle:%d repeat:%d\n",
scancode.rc_proto, scancode.scancode,
!!(scancode.flags & LIRC_SCANCODE_FLAG_TOGGLE),
!!(scancode.flags & LIRC_SCANCODE_FLAG_REPEAT));
}
close(fd);
}

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c  | 102 +-
 drivers/media/rc/ir-mce_kbd-decoder.c |   5 ++
 drivers/media/rc/lirc_dev.c   |  13 +
 drivers/media/rc/rc-core-priv.h   |   3 +
 drivers/media/rc/rc-main.c|   7 +++
 include/media/rc-core.h   |   5 ++
 6 files changed, 120 insertions(+), 15 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 9127544883ed..92674bca8225 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -88,6 +88,21 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
wake_up_poll(>wait_poll, POLLIN | POLLRDNORM);
 }
 
+/**
+ * ir_lirc_scancode_event() - Send scancode data to lirc to be relayed to
+ * userspace
+ * @dev:   the struct rc_dev descriptor of the device
+ * @lscthe struct lirc_scancode describing the decoded scancode
+ */
+void ir_lirc_scancode_event(struct rc_dev *dev, struct lirc_scancode *lsc)
+{
+   lsc->timestamp = ktime_get_ns();
+
+   if (kfifo_put(>scancodes, *lsc))
+   wake_up_poll(>wait_poll, POLLIN | POLLRDNORM);
+}
+EXPORT_SYMBOL_GPL(ir_lirc_scancode_event);
+
 static int ir_lirc_open(struct inode *inode, struct file *file)
 {
struct rc_dev *dev = container_of(inode->i_cdev, struct rc_dev,
@@ -114,6 +129,8 @@ static int ir_lirc_open(struct inode *inode, struct file 
*file)
 
if (dev->driver_type == RC_DRIVER_IR_RAW)
kfifo_reset_out(>rawir);
+   if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
+   kfifo_reset_out(>scancodes);
 
dev->lirc_open++;
file->private_data = dev;
@@ -293,7 +310,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
switch (cmd) {
case LIRC_GET_FEATURES:
if (dev->driver_type == RC_DRIVER_IR_RAW) {
-   val |= LIRC_CAN_REC_MODE2;
+   val |= LIRC_CAN_REC_MODE2 | LIRC_CAN_REC_SCANCODE;
if (dev->rx_resolution)
val |= LIRC_CAN_GET_REC_RESOLUTION;
}
@@ -331,15 +348,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
return -ENOTTY;
 
-   val = LIRC_MODE_MODE2;
+   val = dev->rec_mode;
break;
 
case LIRC_SET_REC_MODE:
if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
return -ENOTTY;
 
-   if (val != LIRC_MODE_MODE2)
+   if (!(val == LIRC_MODE_MODE2 || val == LIRC_MODE_SCANCODE))
return -EINVAL;
+
+   dev->rec_mode = val;
return 0;
 
case LIRC_GET_SEND_MODE:
@@ -482,31 +501,31 @@ static unsigned int ir_lirc_poll(struct file *file,
 
poll_wait(file, >wait_poll, wait);
 
-   if (!rcdev->registered)
+   if (!rcdev->registered) {
events = POLLHUP | POLLERR;
-   else if (rcdev->driver_type == RC_DRIVER_IR_RAW &&
-!kfifo_is_empty(>rawir))
-   events = POLLIN | POLLRDNORM;
+   } else if (rcdev->driver_type != RC_DRIVER_IR_RAW_TX) {
+   if (rcdev->rec_mode == LIRC_MODE_SCANCODE &&
+   !kfifo_is_empty(>scancodes))
+   events = POLLIN | POLLRDNORM;
+
+   if (rcdev->rec_mode == LIRC_MODE_MODE2 &&
+   !kfifo_is_empty(>rawir))
+   events = POLLIN | POLLRDNORM;
+   }
 
return events;
 }
 
-static ssize_t ir_lirc_read(struct file *file, char __user *buffer,
-   size_t length, loff_t *ppos)
+static ssize_t ir_lirc_read_mode2(struct file *file, char __user *buffer,
+ size_t length)
 {
struct rc_dev *rcdev = file->private_data;
unsigned int copied;
int ret;
 
-   if 

[PATCH v3 18/26] media: lirc: remove last remnants of lirc kapi

[Sean Young]

rc-core has replaced the lirc kapi many years ago, and now with the last
driver ported to rc-core, we can finally remove it.

Note this has no effect on userspace.

All future IR drivers should use the rc-core api.

Signed-off-by: Sean Young 
---
 Documentation/media/kapi/rc-core.rst |   5 --
 drivers/media/rc/ir-lirc-codec.c |  45 +--
 drivers/media/rc/lirc_dev.c  | 147 ---
 drivers/media/rc/rc-core-priv.h  |   3 +
 drivers/media/rc/rc-main.c   |   1 -
 include/media/lirc_dev.h |  50 
 include/media/rc-core.h  |   8 +-
 7 files changed, 63 insertions(+), 196 deletions(-)
 delete mode 100644 include/media/lirc_dev.h

diff --git a/Documentation/media/kapi/rc-core.rst 
b/Documentation/media/kapi/rc-core.rst
index a45895886257..41c2256dbf6a 100644
--- a/Documentation/media/kapi/rc-core.rst
+++ b/Documentation/media/kapi/rc-core.rst
@@ -7,8 +7,3 @@ Remote Controller core
 .. kernel-doc:: include/media/rc-core.h
 
 .. kernel-doc:: include/media/rc-map.h
-
-LIRC
-
-
-.. kernel-doc:: include/media/lirc_dev.h
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 4411a3d0a778..9127544883ed 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -12,10 +12,10 @@
  *  GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "rc-core-priv.h"
 
@@ -90,8 +90,8 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
 
 static int ir_lirc_open(struct inode *inode, struct file *file)
 {
-   struct lirc_dev *d = container_of(inode->i_cdev, struct lirc_dev, cdev);
-   struct rc_dev *dev = d->rdev;
+   struct rc_dev *dev = container_of(inode->i_cdev, struct rc_dev,
+ lirc_cdev);
int retval;
 
retval = rc_open(dev);
@@ -532,7 +532,7 @@ static ssize_t ir_lirc_read(struct file *file, char __user 
*buffer,
return copied;
 }
 
-static const struct file_operations lirc_fops = {
+const struct file_operations lirc_fops = {
.owner  = THIS_MODULE,
.write  = ir_lirc_transmit_ir,
.unlocked_ioctl = ir_lirc_ioctl,
@@ -545,40 +545,3 @@ static const struct file_operations lirc_fops = {
.release= ir_lirc_close,
.llseek = no_llseek,
 };
-
-int ir_lirc_register(struct rc_dev *dev)
-{
-   struct lirc_dev *ldev;
-   int rc = -ENOMEM;
-
-   ldev = lirc_allocate_device();
-   if (!ldev)
-   return rc;
-
-   ldev->fops = _fops;
-   ldev->dev.parent = >dev;
-   ldev->rdev = dev;
-   ldev->owner = THIS_MODULE;
-
-   rc = lirc_register_device(ldev);
-   if (rc < 0)
-   goto out;
-
-   if (dev->tx_scancode)
-   dev->send_mode = LIRC_MODE_SCANCODE;
-   else
-   dev->send_mode = LIRC_MODE_PULSE;
-
-   dev->lirc_dev = ldev;
-   return 0;
-
-out:
-   lirc_free_device(ldev);
-   return rc;
-}
-
-void ir_lirc_unregister(struct rc_dev *dev)
-{
-   lirc_unregister_device(dev->lirc_dev);
-   dev->lirc_dev = NULL;
-}
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 4ac74fd86fd4..217c1203c87b 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -18,24 +18,19 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
 #include 
+#include 
 
 #include "rc-core-priv.h"
 #include 
-#include 
 
 #define LOGHEAD"lirc_dev (%s[%d]): "
 
 static dev_t lirc_base_dev;
 
 /* Used to keep track of allocated lirc devices */
-#define LIRC_MAX_DEVICES 256
 static DEFINE_IDA(lirc_ida);
 
 /* Only used for sysfs but defined to void otherwise */
@@ -43,124 +38,84 @@ static struct class *lirc_class;
 
 static void lirc_release_device(struct device *ld)
 {
-   struct lirc_dev *d = container_of(ld, struct lirc_dev, dev);
-   struct rc_dev *rcdev = d->rdev;
+   struct rc_dev *rcdev = container_of(ld, struct rc_dev, lirc_dev);
 
if (rcdev->driver_type == RC_DRIVER_IR_RAW)
kfifo_free(>rawir);
 
-   kfree(d);
-   module_put(THIS_MODULE);
-   put_device(d->dev.parent);
+   put_device(>dev);
 }
 
-struct lirc_dev *
-lirc_allocate_device(void)
+int ir_lirc_register(struct rc_dev *dev)
 {
-   struct lirc_dev *d;
-
-   d = kzalloc(sizeof(*d), GFP_KERNEL);
-   if (d) {
-   device_initialize(>dev);
-   d->dev.class = lirc_class;
-   d->dev.release = lirc_release_device;
-   __module_get(THIS_MODULE);
-   }
+   int err, minor;
 
-   return d;
-}
-EXPORT_SYMBOL(lirc_allocate_device);
-
-void lirc_free_device(struct lirc_dev *d)
-{
-   if (!d)
-   return;
+   device_initialize(>lirc_dev);
+  

[PATCH v3 22/26] media: lirc: introduce LIRC_SET_POLL_MODES

[Sean Young]

If you want to poll for both decoded scancodes and raw IR, then this
ioctl will help you.

int fd = open("/dev/lirc0", O_RDONLY | O_NONBLOCK);

for (;;) {
unsigned mode = LIRC_MODE_SCANCODE | LIRC_MODE_MODE2;
ioctl(fd, LIRC_SET_POLL_MODES, );
poll(&((struct pollfd){ .fd = fd, .events = POLLIN }), 1, -1);
mode = LIRC_MODE_SCANCODE;
ioctl(fd, LIRC_SET_REC_MODE, );
struct lirc_scancode sc;
if (read(fd, , sizeof(sc)) == sizeof(sc)) {
printf("scancode protocol:%d scancode:%llx\n",
sc.rc_proto, sc.scancode);
}
mode = LIRC_MODE_MODE2;
ioctl(fd, LIRC_SET_REC_MODE, );
unsigned sample;
if (read(fd, , sizeof(sample)) == sizeof(sample)) {
if (LIRC_IS_SPACE(sample))
printf("space %u\n", LIRC_VAL(sample)));
if (LIRC_IS_PULSE(sample))
printf("pulse %u\n", LIRC_VAL(sample)));
}
}

Note that LIRC_SET_REC_MODE will also affect the poll mode, so you
must set it again before calling poll.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-func.rst  |  1 +
 .../media/uapi/rc/lirc-set-poll-modes.rst  | 52 ++
 drivers/media/rc/ir-lirc-codec.c   | 19 ++--
 drivers/media/rc/lirc_dev.c|  1 +
 include/media/rc-core.h|  3 ++
 include/uapi/linux/lirc.h  |  9 
 6 files changed, 81 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-poll-modes.rst

diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
b/Documentation/media/uapi/rc/lirc-func.rst
index ddb4620de294..6493430aabef 100644
--- a/Documentation/media/uapi/rc/lirc-func.rst
+++ b/Documentation/media/uapi/rc/lirc-func.rst
@@ -25,3 +25,4 @@ LIRC Function Reference
 lirc-set-rec-timeout-reports
 lirc-set-measure-carrier-mode
 lirc-set-wideband-receiver
+lirc-set-poll-modes
diff --git a/Documentation/media/uapi/rc/lirc-set-poll-modes.rst 
b/Documentation/media/uapi/rc/lirc-set-poll-modes.rst
new file mode 100644
index ..2ae08dcd86ea
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-poll-modes.rst
@@ -0,0 +1,52 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_poll_modes:
+
+**
+ioctls LIRC_SET_POLL_MODES
+**
+
+Name
+
+
+LIRC_SET_POLL_MODES - Set LIRC modes to use for poll
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, LIRC_SET_POLL_MODES, __u32 modes)
+   :name: LIRC_SET_POLL_MODES
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``modes``
+Bitmask with enabled poll lirc modes
+
+Description
+===
+
+Set lirc modes for which read readiness is reported by poll. Only
+:ref:`LIRC_MODE_MODE2 ` and
+:ref:`LIRC_MODE_SCANCODE ` are supported. Poll
+can report read readiness for both modes if you bitwise or them together.
+Use :ref:`lirc_get_features` to find out which modes the driver supports.
+
+This ioctl is useful when you want to read both raw IR and decoded
+scancodes. You can set :ref:`LIRC_MODE_MODE2 ` and
+poll for raw IR for some time, and then set
+:ref:`LIRC_MODE_SCANCODE ` and poll for decoded
+scancodes, and repeat both modes again. Using this ioctl, you can poll
+for both without having to wait for a limited period in each mode.
+
+Note that using :ref:`lirc_set_rec_mode` resets the poll mode.
+
+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/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 92674bca8225..559a4049151e 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -359,6 +359,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
return -EINVAL;
 
dev->rec_mode = val;
+   dev->poll_mode = val;
+   return 0;
+
+   case LIRC_SET_POLL_MODES:
+   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   return -ENOTTY;
+
+   if (val & ~(LIRC_MODE_MODE2 | LIRC_MODE_SCANCODE))
+   return -EINVAL;
+
+   dev->poll_mode = val;
return 0;
 
case LIRC_GET_SEND_MODE:
@@ -504,13 +515,13 @@ static unsigned int ir_lirc_poll(struct file *file,
if (!rcdev->registered) {
events = POLLHUP | POLLERR;
} else if (rcdev->driver_type != RC_DRIVER_IR_RAW_TX) {
-   if (rcdev->rec_mode == LIRC_MODE_SCANCODE &&
+   if ((rcdev->poll_mode & LIRC_MODE_SCANCODE) &&
!kfifo_is_empty(>scancodes))
-   events = 

[PATCH v3 20/26] media: rc: ensure lirc device receives nec repeats

[Sean Young]

The lirc device should get lirc repeats whether there is a keymap
match or not.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index e9d6ce024cd2..dae427e25d71 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -662,19 +662,25 @@ void rc_repeat(struct rc_dev *dev)
 {
unsigned long flags;
unsigned int timeout = protocols[dev->last_protocol].repeat_period;
+   struct lirc_scancode sc = {
+   .scancode = dev->last_scancode, .rc_proto = dev->last_protocol,
+   .keycode = dev->keypressed ? dev->last_keycode : KEY_RESERVED,
+   .flags = LIRC_SCANCODE_FLAG_REPEAT |
+(dev->last_toggle ? LIRC_SCANCODE_FLAG_TOGGLE : 0)
+   };
 
-   spin_lock_irqsave(>keylock, flags);
+   ir_lirc_scancode_event(dev, );
 
-   if (!dev->keypressed)
-   goto out;
+   spin_lock_irqsave(>keylock, flags);
 
input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
input_sync(dev->input_dev);
 
-   dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
-   mod_timer(>timer_keyup, dev->keyup_jiffies);
+   if (dev->keypressed) {
+   dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
+   mod_timer(>timer_keyup, dev->keyup_jiffies);
+   }
 
-out:
spin_unlock_irqrestore(>keylock, flags);
 }
 EXPORT_SYMBOL_GPL(rc_repeat);
@@ -710,13 +716,14 @@ static void ir_do_keydown(struct rc_dev *dev, enum 
rc_proto protocol,
 
input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
 
+   dev->last_protocol = protocol;
+   dev->last_scancode = scancode;
+   dev->last_toggle = toggle;
+   dev->last_keycode = keycode;
+
if (new_event && keycode != KEY_RESERVED) {
/* Register a keypress */
dev->keypressed = true;
-   dev->last_protocol = protocol;
-   dev->last_scancode = scancode;
-   dev->last_toggle = toggle;
-   dev->last_keycode = keycode;
 
IR_dprintk(1, "%s: key down event, key 0x%04x, protocol 0x%04x, 
scancode 0x%08x\n",
   dev->device_name, keycode, protocol, scancode);
-- 
2.13.6

[PATCH v3 13/26] media: lirc: use kfifo rather than lirc_buffer for raw IR

[Sean Young]

Since the only mode lirc devices can handle is raw IR, handle this
in a plain kfifo.

Remove lirc_buffer since this is no longer needed.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c |  79 +---
 drivers/media/rc/lirc_dev.c  | 199 ---
 include/media/lirc_dev.h | 109 -
 include/media/rc-core.h  |   4 +
 4 files changed, 85 insertions(+), 306 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 05b2c1d5c0e6..7dc3fe8a5a96 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -66,8 +66,6 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
} else {
 
if (dev->gap) {
-   int gap_sample;
-
dev->gap_duration += ktime_to_ns(ktime_sub(ktime_get(),
 dev->gap_start));
 
@@ -76,9 +74,7 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
dev->gap_duration = min_t(u64, dev->gap_duration,
  LIRC_VALUE_MASK);
 
-   gap_sample = LIRC_SPACE(dev->gap_duration);
-   lirc_buffer_write(dev->lirc_dev->buf,
- (unsigned char *)_sample);
+   kfifo_put(>rawir, LIRC_SPACE(dev->gap_duration));
dev->gap = false;
}
 
@@ -88,10 +84,8 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
   TO_US(ev.duration), TO_STR(ev.pulse));
}
 
-   lirc_buffer_write(dev->lirc_dev->buf,
- (unsigned char *) );
-
-   wake_up(>lirc_dev->buf->wait_poll);
+   kfifo_put(>rawir, sample);
+   wake_up_poll(>wait_poll, POLLIN | POLLRDNORM);
 }
 
 static ssize_t ir_lirc_transmit_ir(struct file *file, const char __user *buf,
@@ -419,6 +413,66 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
return ret;
 }
 
+static unsigned int ir_lirc_poll(struct file *file,
+struct poll_table_struct *wait)
+{
+   struct rc_dev *rcdev = file->private_data;
+   struct lirc_dev *d = rcdev->lirc_dev;
+   unsigned int events = 0;
+
+   poll_wait(file, >wait_poll, wait);
+
+   if (!d->attached)
+   events = POLLHUP | POLLERR;
+   else if (rcdev->driver_type == RC_DRIVER_IR_RAW &&
+!kfifo_is_empty(>rawir))
+   events = POLLIN | POLLRDNORM;
+
+   return events;
+}
+
+static ssize_t ir_lirc_read(struct file *file, char __user *buffer,
+   size_t length, loff_t *ppos)
+{
+   struct rc_dev *rcdev = file->private_data;
+   struct lirc_dev *d = rcdev->lirc_dev;
+   unsigned int copied;
+   int ret;
+
+   if (rcdev->driver_type == RC_DRIVER_IR_RAW_TX)
+   return -EINVAL;
+
+   if (length < sizeof(unsigned int) || length % sizeof(unsigned int))
+   return -EINVAL;
+
+   if (!d->attached)
+   return -ENODEV;
+
+   do {
+   if (kfifo_is_empty(>rawir)) {
+   if (file->f_flags & O_NONBLOCK)
+   return -EAGAIN;
+
+   ret = wait_event_interruptible(rcdev->wait_poll,
+   !kfifo_is_empty(>rawir) ||
+   !d->attached);
+   if (ret)
+   return ret;
+   }
+
+   if (!d->attached)
+   return -ENODEV;
+
+   mutex_lock(>lock);
+   ret = kfifo_to_user(>rawir, buffer, length, );
+   mutex_unlock(>lock);
+   if (ret)
+   return ret;
+   } while (copied == 0);
+
+   return copied;
+}
+
 static const struct file_operations lirc_fops = {
.owner  = THIS_MODULE,
.write  = ir_lirc_transmit_ir,
@@ -426,8 +480,8 @@ static const struct file_operations lirc_fops = {
 #ifdef CONFIG_COMPAT
.compat_ioctl   = ir_lirc_ioctl,
 #endif
-   .read   = lirc_dev_fop_read,
-   .poll   = lirc_dev_fop_poll,
+   .read   = ir_lirc_read,
+   .poll   = ir_lirc_poll,
.open   = lirc_dev_fop_open,
.release= lirc_dev_fop_close,
.llseek = no_llseek,
@@ -444,9 +498,6 @@ int ir_lirc_register(struct rc_dev *dev)
 
snprintf(ldev->name, sizeof(ldev->name), "ir-lirc-codec (%s)",
 dev->driver_name);
-   ldev->buf = NULL;
-   ldev->chunk_size = sizeof(int);
-   ldev->buffer_size = LIRCBUF_SIZE;
ldev->fops = _fops;
ldev->dev.parent = >dev;
ldev->rdev = dev;
diff --git 

[PATCH v3 11/26] media: rc: document and fix rc_validate_scancode()

[Sean Young]

For some IR protocols, some scancode values not valid, i.e. they're part
of a different protocol variant.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 38393f13822f..ae1df089c96f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -776,21 +776,35 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum 
rc_proto protocol,
 EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
 
 /**
- * rc_validate_scancode() - checks that a scancode is valid for a protocol
+ * rc_validate_scancode() - checks that a scancode is valid for a protocol.
+ * For nec, it should do the opposite of ir_nec_bytes_to_scancode()
  * @proto: protocol
  * @scancode:  scancode
  */
 bool rc_validate_scancode(enum rc_proto proto, u32 scancode)
 {
switch (proto) {
+   /*
+* NECX has a 16-bit address; if the lower 8 bits match the upper
+* 8 bits inverted, then the address would match regular nec.
+*/
case RC_PROTO_NECX:
if scancode >> 16) ^ ~(scancode >> 8)) & 0xff) == 0)
return false;
break;
+   /*
+* NEC32 has a 16 bit address and 16 bit command. If the lower 8 bits
+* of the command match the upper 8 bits inverted, then it would
+* be either NEC or NECX.
+*/
case RC_PROTO_NEC32:
-   if scancode >> 24) ^ ~(scancode >> 16)) & 0xff) == 0)
+   if scancode >> 8) ^ ~scancode) & 0xff) == 0)
return false;
break;
+   /*
+* If the customer code (top 32-bit) is 0x800f, it is MCE else it
+* is regular mode-6a 32 bit
+*/
case RC_PROTO_RC6_MCE:
if ((scancode & 0x) != 0x800f)
return false;
-- 
2.13.6

[PATCH v3 17/26] media: lirc: remove name from lirc_dev

[Sean Young]

This is a duplicate of rcdev->driver_name.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 2 +-
 drivers/media/rc/ir-lirc-codec.c   | 2 --
 drivers/media/rc/lirc_dev.c| 9 +++--
 include/media/lirc_dev.h   | 2 --
 4 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index 3cacf9aeac40..a3fa3c1ef169 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -18,7 +18,7 @@ Example dmesg output upon a driver registering w/LIRC:
 
 $ dmesg |grep lirc_dev
 lirc_dev: IR Remote Control driver registered, major 248
-rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
+rc rc0: lirc_dev: driver mceusb registered at minor = 0
 
 What you should see for a chardev:
 
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index f852ec231f4e..4411a3d0a778 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -555,8 +555,6 @@ int ir_lirc_register(struct rc_dev *dev)
if (!ldev)
return rc;
 
-   snprintf(ldev->name, sizeof(ldev->name), "ir-lirc-codec (%s)",
-dev->driver_name);
ldev->fops = _fops;
ldev->dev.parent = >dev;
ldev->rdev = dev;
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 32124fb5c88e..4ac74fd86fd4 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -101,9 +101,6 @@ int lirc_register_device(struct lirc_dev *d)
return -EINVAL;
}
 
-   /* some safety check 8-) */
-   d->name[sizeof(d->name) - 1] = '\0';
-
if (rcdev->driver_type == RC_DRIVER_IR_RAW) {
if (kfifo_alloc(>rawir, MAX_IR_EVENT_SIZE, GFP_KERNEL))
return -ENOMEM;
@@ -131,7 +128,7 @@ int lirc_register_device(struct lirc_dev *d)
get_device(d->dev.parent);
 
dev_info(>dev, "lirc_dev: driver %s registered at minor = %d\n",
-d->name, d->minor);
+rcdev->driver_name, d->minor);
 
return 0;
 }
@@ -147,13 +144,13 @@ void lirc_unregister_device(struct lirc_dev *d)
rcdev = d->rdev;
 
dev_dbg(>dev, "lirc_dev: driver %s unregistered from minor = %d\n",
-   d->name, d->minor);
+   rcdev->driver_name, d->minor);
 
mutex_lock(>lock);
 
if (rcdev->lirc_open) {
dev_dbg(>dev, LOGHEAD "releasing opened driver\n",
-   d->name, d->minor);
+   rcdev->driver_name, d->minor);
wake_up_poll(>wait_poll, POLLHUP);
}
 
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index b45af81b4633..d12e1d1c3d67 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -21,7 +21,6 @@
 /**
  * struct lirc_dev - represents a LIRC device
  *
- * @name:  used for logging
  * @minor: the minor device (/dev/lircX) number for the device
  * @rdev:   rc_dev associated with the device
  * @fops:   file_operations for the device
@@ -30,7 +29,6 @@
  * @cdev:   cdev assigned to the device
  */
 struct lirc_dev {
-   char name[40];
unsigned int minor;
 
struct rc_dev *rdev;
-- 
2.13.6

[PATCH v3 14/26] media: lirc: move lirc_dev->attached to rc_dev->registered

[Sean Young]

This is done to further remove the lirc kernel api. Ensure that every
fops checks for this.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 16 ++--
 drivers/media/rc/lirc_dev.c  |  4 +---
 drivers/media/rc/rc-main.c   |  8 
 include/media/lirc_dev.h |  2 --
 include/media/rc-core.h  |  3 +++
 5 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 7dc3fe8a5a96..60ff8f188e6f 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -101,6 +101,9 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
unsigned int duration = 0; /* signal duration in us */
int i;
 
+   if (!dev->registered)
+   return -ENODEV;
+
start = ktime_get();
 
if (dev->send_mode == LIRC_MODE_SCANCODE) {
@@ -229,6 +232,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
return ret;
}
 
+   if (!dev->registered)
+   return -ENODEV;
+
switch (cmd) {
case LIRC_GET_FEATURES:
if (dev->driver_type == RC_DRIVER_IR_RAW) {
@@ -417,12 +423,11 @@ static unsigned int ir_lirc_poll(struct file *file,
 struct poll_table_struct *wait)
 {
struct rc_dev *rcdev = file->private_data;
-   struct lirc_dev *d = rcdev->lirc_dev;
unsigned int events = 0;
 
poll_wait(file, >wait_poll, wait);
 
-   if (!d->attached)
+   if (!rcdev->registered)
events = POLLHUP | POLLERR;
else if (rcdev->driver_type == RC_DRIVER_IR_RAW &&
 !kfifo_is_empty(>rawir))
@@ -435,7 +440,6 @@ static ssize_t ir_lirc_read(struct file *file, char __user 
*buffer,
size_t length, loff_t *ppos)
 {
struct rc_dev *rcdev = file->private_data;
-   struct lirc_dev *d = rcdev->lirc_dev;
unsigned int copied;
int ret;
 
@@ -445,7 +449,7 @@ static ssize_t ir_lirc_read(struct file *file, char __user 
*buffer,
if (length < sizeof(unsigned int) || length % sizeof(unsigned int))
return -EINVAL;
 
-   if (!d->attached)
+   if (!rcdev->registered)
return -ENODEV;
 
do {
@@ -455,12 +459,12 @@ static ssize_t ir_lirc_read(struct file *file, char 
__user *buffer,
 
ret = wait_event_interruptible(rcdev->wait_poll,
!kfifo_is_empty(>rawir) ||
-   !d->attached);
+   !rcdev->registered);
if (ret)
return ret;
}
 
-   if (!d->attached)
+   if (!rcdev->registered)
return -ENODEV;
 
mutex_lock(>lock);
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 9a0ad8d9a0cb..22171267aa90 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -122,7 +122,6 @@ int lirc_register_device(struct lirc_dev *d)
 
cdev_init(>cdev, d->fops);
d->cdev.owner = d->owner;
-   d->attached = true;
 
err = cdev_device_add(>cdev, >dev);
if (err) {
@@ -153,7 +152,6 @@ void lirc_unregister_device(struct lirc_dev *d)
 
mutex_lock(>mutex);
 
-   d->attached = false;
if (d->open) {
dev_dbg(>dev, LOGHEAD "releasing opened driver\n",
d->name, d->minor);
@@ -180,7 +178,7 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
*file)
if (retval)
return retval;
 
-   if (!d->attached) {
+   if (!rcdev->registered) {
retval = -ENODEV;
goto out;
}
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index ae1df089c96f..9e73899b5994 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1809,6 +1809,8 @@ int rc_register_device(struct rc_dev *dev)
goto out_lirc;
}
 
+   dev->registered = true;
+
IR_dprintk(1, "Registered rc%u (driver: %s)\n",
   dev->minor,
   dev->driver_name ? dev->driver_name : "unknown");
@@ -1871,6 +1873,12 @@ void rc_unregister_device(struct rc_dev *dev)
 
rc_free_rx_device(dev);
 
+   dev->registered = false;
+
+   /*
+* lirc device should be freed with dev->registered = false, so
+* that userspace polling will get notified.
+*/
if (dev->driver_type != RC_DRIVER_SCANCODE)
ir_lirc_unregister(dev);
 
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 14d3eb36672e..5782add67edd 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -26,7 +26,6 @@
  * @rdev:   rc_dev 

[PATCH v3 15/26] media: lirc: do not call rc_close() on unregistered devices

[Sean Young]

If a lirc chardev is held open after a device is unplugged, rc_close()
will be called after rc_unregister_device(). The driver is not expecting
any calls at this point, and the iguanair driver causes an oops in
this scenario.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 9e73899b5994..9a8fc86b0835 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -885,7 +885,7 @@ void rc_close(struct rc_dev *rdev)
if (rdev) {
mutex_lock(>lock);
 
-   if (!--rdev->users && rdev->close != NULL)
+   if (!--rdev->users && rdev->close && rdev->registered)
rdev->close(rdev);
 
mutex_unlock(>lock);
-- 
2.13.6

[PATCH v3 12/26] media: lirc: merge lirc_dev_fop_ioctl and ir_lirc_ioctl

[Sean Young]

Calculate lirc features when necessary, and add LIRC_{S,G}ET_REC_MODE
cases to ir_lirc_ioctl.

This makes lirc_dev_fop_ioctl() unnecessary since all cases are
already handled by ir_lirc_ioctl().

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 85 +++-
 drivers/media/rc/lirc_dev.c  | 62 ++---
 include/media/lirc_dev.h |  4 --
 3 files changed, 53 insertions(+), 98 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index d9406fdbc9a3..05b2c1d5c0e6 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -236,8 +236,57 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
}
 
switch (cmd) {
+   case LIRC_GET_FEATURES:
+   if (dev->driver_type == RC_DRIVER_IR_RAW) {
+   val |= LIRC_CAN_REC_MODE2;
+   if (dev->rx_resolution)
+   val |= LIRC_CAN_GET_REC_RESOLUTION;
+   }
+
+   if (dev->tx_scancode)
+   val |= LIRC_CAN_SEND_SCANCODE;
+
+   if (dev->tx_ir) {
+   val |= LIRC_CAN_SEND_PULSE | LIRC_CAN_SEND_SCANCODE;
+   if (dev->s_tx_mask)
+   val |= LIRC_CAN_SET_TRANSMITTER_MASK;
+   if (dev->s_tx_carrier)
+   val |= LIRC_CAN_SET_SEND_CARRIER;
+   if (dev->s_tx_duty_cycle)
+   val |= LIRC_CAN_SET_SEND_DUTY_CYCLE;
+   }
+
+   if (dev->s_rx_carrier_range)
+   val |= LIRC_CAN_SET_REC_CARRIER |
+   LIRC_CAN_SET_REC_CARRIER_RANGE;
+
+   if (dev->s_learning_mode)
+   val |= LIRC_CAN_USE_WIDEBAND_RECEIVER;
+
+   if (dev->s_carrier_report)
+   val |= LIRC_CAN_MEASURE_CARRIER;
+
+   if (dev->max_timeout)
+   val |= LIRC_CAN_SET_REC_TIMEOUT;
+
+   break;
 
/* mode support */
+   case LIRC_GET_REC_MODE:
+   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   return -ENOTTY;
+
+   val = LIRC_MODE_MODE2;
+   break;
+
+   case LIRC_SET_REC_MODE:
+   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   return -ENOTTY;
+
+   if (val != LIRC_MODE_MODE2)
+   return -EINVAL;
+   return 0;
+
case LIRC_GET_SEND_MODE:
if (!dev->tx_ir && !dev->tx_scancode)
return -ENOTTY;
@@ -361,7 +410,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
break;
 
default:
-   return lirc_dev_fop_ioctl(filep, cmd, arg);
+   return -ENOTTY;
}
 
if (_IOC_DIR(cmd) & _IOC_READ)
@@ -388,47 +437,13 @@ int ir_lirc_register(struct rc_dev *dev)
 {
struct lirc_dev *ldev;
int rc = -ENOMEM;
-   unsigned long features = 0;
 
ldev = lirc_allocate_device();
if (!ldev)
return rc;
 
-   if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
-   features |= LIRC_CAN_REC_MODE2;
-   if (dev->rx_resolution)
-   features |= LIRC_CAN_GET_REC_RESOLUTION;
-   }
-
-   if (dev->tx_scancode)
-   features |= LIRC_CAN_SEND_SCANCODE;
-
-   if (dev->tx_ir) {
-   features |= LIRC_CAN_SEND_PULSE | LIRC_CAN_SEND_SCANCODE;
-   if (dev->s_tx_mask)
-   features |= LIRC_CAN_SET_TRANSMITTER_MASK;
-   if (dev->s_tx_carrier)
-   features |= LIRC_CAN_SET_SEND_CARRIER;
-   if (dev->s_tx_duty_cycle)
-   features |= LIRC_CAN_SET_SEND_DUTY_CYCLE;
-   }
-
-   if (dev->s_rx_carrier_range)
-   features |= LIRC_CAN_SET_REC_CARRIER |
-   LIRC_CAN_SET_REC_CARRIER_RANGE;
-
-   if (dev->s_learning_mode)
-   features |= LIRC_CAN_USE_WIDEBAND_RECEIVER;
-
-   if (dev->s_carrier_report)
-   features |= LIRC_CAN_MEASURE_CARRIER;
-
-   if (dev->max_timeout)
-   features |= LIRC_CAN_SET_REC_TIMEOUT;
-
snprintf(ldev->name, sizeof(ldev->name), "ir-lirc-codec (%s)",
 dev->driver_name);
-   ldev->features = features;
ldev->buf = NULL;
ldev->chunk_size = sizeof(int);
ldev->buffer_size = LIRCBUF_SIZE;
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 3cc95deaa84e..95058ea01e62 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -109,6 +109,7 @@ EXPORT_SYMBOL(lirc_free_device);
 
 int lirc_register_device(struct lirc_dev *d)
 {
+   struct rc_dev *rcdev = 

[PATCH v3 16/26] media: lirc: create rc-core open and close lirc functions

[Sean Young]

Replace the generic kernel lirc api with ones which use rc-core, further
reducing the lirc_dev members.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 59 --
 drivers/media/rc/lirc_dev.c  | 68 ++--
 include/media/lirc_dev.h | 11 ---
 include/media/rc-core.h  |  2 ++
 4 files changed, 62 insertions(+), 78 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 60ff8f188e6f..f852ec231f4e 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -88,6 +88,61 @@ void ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
wake_up_poll(>wait_poll, POLLIN | POLLRDNORM);
 }
 
+static int ir_lirc_open(struct inode *inode, struct file *file)
+{
+   struct lirc_dev *d = container_of(inode->i_cdev, struct lirc_dev, cdev);
+   struct rc_dev *dev = d->rdev;
+   int retval;
+
+   retval = rc_open(dev);
+   if (retval)
+   return retval;
+
+   retval = mutex_lock_interruptible(>lock);
+   if (retval)
+   goto out_rc;
+
+   if (!dev->registered) {
+   retval = -ENODEV;
+   goto out_unlock;
+   }
+
+   if (dev->lirc_open) {
+   retval = -EBUSY;
+   goto out_unlock;
+   }
+
+   if (dev->driver_type == RC_DRIVER_IR_RAW)
+   kfifo_reset_out(>rawir);
+
+   dev->lirc_open++;
+   file->private_data = dev;
+
+   nonseekable_open(inode, file);
+   mutex_unlock(>lock);
+
+   return 0;
+
+out_unlock:
+   mutex_unlock(>lock);
+out_rc:
+   rc_close(dev);
+   return retval;
+}
+
+static int ir_lirc_close(struct inode *inode, struct file *file)
+{
+   struct rc_dev *dev = file->private_data;
+
+   mutex_lock(>lock);
+   dev->lirc_open--;
+   mutex_unlock(>lock);
+
+   rc_close(dev);
+
+   return 0;
+}
+
 static ssize_t ir_lirc_transmit_ir(struct file *file, const char __user *buf,
   size_t n, loff_t *ppos)
 {
@@ -486,8 +541,8 @@ static const struct file_operations lirc_fops = {
 #endif
.read   = ir_lirc_read,
.poll   = ir_lirc_poll,
-   .open   = lirc_dev_fop_open,
-   .release= lirc_dev_fop_close,
+   .open   = ir_lirc_open,
+   .release= ir_lirc_close,
.llseek = no_llseek,
 };
 
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 22171267aa90..32124fb5c88e 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -61,7 +61,6 @@ lirc_allocate_device(void)
 
d = kzalloc(sizeof(*d), GFP_KERNEL);
if (d) {
-   mutex_init(>mutex);
device_initialize(>dev);
d->dev.class = lirc_class;
d->dev.release = lirc_release_device;
@@ -150,15 +149,15 @@ void lirc_unregister_device(struct lirc_dev *d)
dev_dbg(>dev, "lirc_dev: driver %s unregistered from minor = %d\n",
d->name, d->minor);
 
-   mutex_lock(>mutex);
+   mutex_lock(>lock);
 
-   if (d->open) {
+   if (rcdev->lirc_open) {
dev_dbg(>dev, LOGHEAD "releasing opened driver\n",
d->name, d->minor);
wake_up_poll(>wait_poll, POLLHUP);
}
 
-   mutex_unlock(>mutex);
+   mutex_unlock(>lock);
 
cdev_device_del(>cdev, >dev);
ida_simple_remove(_ida, d->minor);
@@ -166,67 +165,6 @@ void lirc_unregister_device(struct lirc_dev *d)
 }
 EXPORT_SYMBOL(lirc_unregister_device);
 
-int lirc_dev_fop_open(struct inode *inode, struct file *file)
-{
-   struct lirc_dev *d = container_of(inode->i_cdev, struct lirc_dev, cdev);
-   struct rc_dev *rcdev = d->rdev;
-   int retval;
-
-   dev_dbg(>dev, LOGHEAD "open called\n", d->name, d->minor);
-
-   retval = mutex_lock_interruptible(>mutex);
-   if (retval)
-   return retval;
-
-   if (!rcdev->registered) {
-   retval = -ENODEV;
-   goto out;
-   }
-
-   if (d->open) {
-   retval = -EBUSY;
-   goto out;
-   }
-
-   if (d->rdev) {
-   retval = rc_open(d->rdev);
-   if (retval)
-   goto out;
-   }
-
-   if (rcdev->driver_type == RC_DRIVER_IR_RAW)
-   kfifo_reset_out(>rawir);
-
-   d->open++;
-
-   file->private_data = d->rdev;
-   nonseekable_open(inode, file);
-   mutex_unlock(>mutex);
-
-   return 0;
-
-out:
-   mutex_unlock(>mutex);
-   return retval;
-}
-EXPORT_SYMBOL(lirc_dev_fop_open);
-
-int lirc_dev_fop_close(struct inode *inode, struct file *file)
-{
-   struct rc_dev *rcdev = file->private_data;
-   struct lirc_dev *d = rcdev->lirc_dev;
-
-   mutex_lock(>mutex);
-
-   rc_close(rcdev);
-

[PATCH v3 10/26] media: lirc: validate scancode for transmit

[Sean Young]

Ensure we reject an attempt to transmit invalid scancodes.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 10 
 drivers/media/rc/rc-core-priv.h  |  1 +
 drivers/media/rc/rc-main.c   | 53 +---
 3 files changed, 44 insertions(+), 20 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index f2feca17c3a0..d9406fdbc9a3 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -121,6 +121,16 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (scan.flags || scan.keycode || scan.timestamp)
return -EINVAL;
 
+   /*
+* The scancode field in lirc_scancode is 64-bit simply
+* to future-proof it, since there are IR protocols encode
+* use more than 32 bits. For now only 32-bit protocols
+* are supported.
+*/
+   if (scan.scancode > U32_MAX ||
+   !rc_validate_scancode(scan.rc_proto, scan.scancode))
+   return -EINVAL;
+
if (dev->tx_scancode) {
ret = dev->tx_scancode(dev, );
return ret < 0 ? ret : n;
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 21e515d34f64..a064c401fa38 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -160,6 +160,7 @@ static inline bool is_timing_event(struct ir_raw_event ev)
 #define TO_STR(is_pulse)   ((is_pulse) ? "pulse" : "space")
 
 /* functions for IR encoders */
+bool rc_validate_scancode(enum rc_proto proto, u32 scancode);
 
 static inline void init_ir_raw_event_duration(struct ir_raw_event *ev,
  unsigned int pulse,
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 758c14b90a87..38393f13822f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -776,6 +776,37 @@ void rc_keydown_notimeout(struct rc_dev *dev, enum 
rc_proto protocol,
 EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
 
 /**
+ * rc_validate_scancode() - checks that a scancode is valid for a protocol
+ * @proto: protocol
+ * @scancode:  scancode
+ */
+bool rc_validate_scancode(enum rc_proto proto, u32 scancode)
+{
+   switch (proto) {
+   case RC_PROTO_NECX:
+   if scancode >> 16) ^ ~(scancode >> 8)) & 0xff) == 0)
+   return false;
+   break;
+   case RC_PROTO_NEC32:
+   if scancode >> 24) ^ ~(scancode >> 16)) & 0xff) == 0)
+   return false;
+   break;
+   case RC_PROTO_RC6_MCE:
+   if ((scancode & 0x) != 0x800f)
+   return false;
+   break;
+   case RC_PROTO_RC6_6A_32:
+   if ((scancode & 0x) == 0x800f)
+   return false;
+   break;
+   default:
+   break;
+   }
+
+   return true;
+}
+
+/**
  * rc_validate_filter() - checks that the scancode and mask are valid and
  *   provides sensible defaults
  * @dev:   the struct rc_dev descriptor of the device
@@ -793,26 +824,8 @@ static int rc_validate_filter(struct rc_dev *dev,
 
mask = protocols[protocol].scancode_bits;
 
-   switch (protocol) {
-   case RC_PROTO_NECX:
-   if s >> 16) ^ ~(s >> 8)) & 0xff) == 0)
-   return -EINVAL;
-   break;
-   case RC_PROTO_NEC32:
-   if s >> 24) ^ ~(s >> 16)) & 0xff) == 0)
-   return -EINVAL;
-   break;
-   case RC_PROTO_RC6_MCE:
-   if ((s & 0x) != 0x800f)
-   return -EINVAL;
-   break;
-   case RC_PROTO_RC6_6A_32:
-   if ((s & 0x) == 0x800f)
-   return -EINVAL;
-   break;
-   default:
-   break;
-   }
+   if (!rc_validate_scancode(protocol, s))
+   return -EINVAL;
 
filter->data &= mask;
filter->mask &= mask;
-- 
2.13.6

[PATCH v3 09/26] media: lirc: lirc interface should not be a raw decoder

[Sean Young]

The lirc user interface exists as a raw decoder, which does not make
much sense for transmit-only devices.

In addition, we want to have lirc char devices for devices which do not
use raw IR, i.e. scancode only devices.

Note that rc-code, lirc_dev, ir-lirc-codec are now calling functions of
each other, so they've been merged into one module rc-core to avoid
circular dependencies.

Since ir-lirc-codec no longer exists as separate codec module, there is no
need for RC_DRIVER_IR_RAW_TX type drivers to call ir_raw_event_register().

Signed-off-by: Sean Young 
---
 drivers/media/rc/Kconfig  |  29 ++--
 drivers/media/rc/Makefile |   5 +-
 drivers/media/rc/ir-lirc-codec.c  | 136 ++
 drivers/media/rc/ir-mce_kbd-decoder.c |   6 --
 drivers/media/rc/lirc_dev.c   |  47 
 drivers/media/rc/rc-core-priv.h   |  45 ---
 drivers/media/rc/rc-ir-raw.c  |  24 ++
 drivers/media/rc/rc-main.c|  52 ++---
 include/media/lirc_dev.h  |  10 ---
 include/media/rc-core.h   |  33 +
 10 files changed, 145 insertions(+), 242 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 2a47139e5811..d84c0d3f7494 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -16,34 +16,21 @@ menuconfig RC_CORE
 if RC_CORE
 source "drivers/media/rc/keymaps/Kconfig"
 
-menuconfig RC_DECODERS
-bool "Remote controller decoders"
-   depends on RC_CORE
-   default y
-
-if RC_DECODERS
 config LIRC
-   tristate "LIRC interface driver"
+   bool "LIRC user interface"
depends on RC_CORE
-
---help---
-  Enable this option to build the Linux Infrared Remote
-  Control (LIRC) core device interface driver. The LIRC
-  interface passes raw IR to and from userspace, where the
-  LIRC daemon handles protocol decoding for IR reception and
-  encoding for IR transmitting (aka "blasting").
+  Enable this option to enable the Linux Infrared Remote
+  Control user interface (e.g. /dev/lirc*). This interface
+  passes raw IR to and from userspace, which is needed for
+  IR transmitting (aka "blasting") and for the lirc daemon.
 
-config IR_LIRC_CODEC
-   tristate "Enable IR to LIRC bridge"
+menuconfig RC_DECODERS
+bool "Remote controller decoders"
depends on RC_CORE
-   depends on LIRC
default y
 
-   ---help---
-  Enable this option to pass raw IR to and from userspace via
-  the LIRC interface.
-
-
+if RC_DECODERS
 config IR_NEC_DECODER
tristate "Enable IR raw decoder for the NEC protocol"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index a6bf6827b1ed..d2c7ea328c10 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -1,9 +1,9 @@
-rc-core-objs   := rc-main.o rc-ir-raw.o
 
 obj-y += keymaps/
 
 obj-$(CONFIG_RC_CORE) += rc-core.o
-obj-$(CONFIG_LIRC) += lirc_dev.o
+rc-core-y := rc-main.o rc-ir-raw.o
+rc-core-$(CONFIG_LIRC) += lirc_dev.o ir-lirc-codec.o
 obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
 obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
 obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
@@ -12,7 +12,6 @@ obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
 obj-$(CONFIG_IR_SANYO_DECODER) += ir-sanyo-decoder.o
 obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
 obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
-obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
 
 # stand-alone IR receivers/transmitters
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 4355fbc10158..f2feca17c3a0 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -14,7 +14,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -23,21 +22,15 @@
 #define LIRCBUF_SIZE 256
 
 /**
- * ir_lirc_decode() - Send raw IR data to lirc_dev to be relayed to the
- *   lircd userspace daemon for decoding.
- * @input_dev: the struct rc_dev descriptor of the device
- * @duration:  the struct ir_raw_event descriptor of the pulse/space
+ * ir_lirc_raw_event() - Send raw IR data to lirc to be relayed to userspace
  *
- * This function returns -EINVAL if the lirc interfaces aren't wired up.
+ * @dev:   the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
  */
-static int ir_lirc_decode(struct rc_dev *dev, struct ir_raw_event ev)
+void ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event ev)
 {
-   struct lirc_codec *lirc = >raw->lirc;
int sample;
 
-   if (!dev->raw->lirc.ldev || !dev->raw->lirc.ldev->buf)
-   return -EINVAL;
-
/* Packet start */
if (ev.reset) {
/* 

[PATCH v3 07/26] media: promote lirc_zilog out of staging

[Sean Young]

Rename to zilog_ir in the process.

Signed-off-by: Sean Young 
---
 drivers/media/rc/Kconfig   | 12 
 drivers/media/rc/Makefile  |  1 +
 .../lirc/lirc_zilog.c => media/rc/zilog_ir.c}  |  0
 drivers/staging/media/Kconfig  |  3 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/lirc/Kconfig | 21 -
 drivers/staging/media/lirc/Makefile|  6 
 drivers/staging/media/lirc/TODO| 36 --
 8 files changed, 13 insertions(+), 67 deletions(-)
 rename drivers/{staging/media/lirc/lirc_zilog.c => media/rc/zilog_ir.c} (100%)
 delete mode 100644 drivers/staging/media/lirc/Kconfig
 delete mode 100644 drivers/staging/media/lirc/Makefile
 delete mode 100644 drivers/staging/media/lirc/TODO

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index afb3456d4e20..2a47139e5811 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -483,6 +483,18 @@ config IR_TANGO
   The HW decoder supports NEC, RC-5, RC-6 IR protocols.
   When compiled as a module, look for tango-ir.
 
+config IR_ZILOG
+   tristate "Zilog/Hauppauge IR Transmitter"
+   depends on RC_CORE
+   depends on LIRC
+   depends on I2C
+   ---help---
+  Driver for the Zilog/Hauppauge IR Transmitter, found on
+  PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards
+
+  To compile this driver as a module, choose M here: the
+  module will be called zilog_ir.
+
 config IR_ZX
tristate "ZTE ZX IR remote control"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 643797dc971b..a6bf6827b1ed 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -43,5 +43,6 @@ obj-$(CONFIG_IR_IMG) += img-ir/
 obj-$(CONFIG_IR_SERIAL) += serial_ir.o
 obj-$(CONFIG_IR_SIR) += sir_ir.o
 obj-$(CONFIG_IR_MTK) += mtk-cir.o
+obj-$(CONFIG_IR_ZILOG) += zilog_ir.o
 obj-$(CONFIG_IR_ZX) += zx-irdec.o
 obj-$(CONFIG_IR_TANGO) += tango-ir.o
diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/media/rc/zilog_ir.c
similarity index 100%
rename from drivers/staging/media/lirc/lirc_zilog.c
rename to drivers/media/rc/zilog_ir.c
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index f8c25ee082ef..3a09140700e6 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,7 +31,4 @@ source "drivers/staging/media/imx/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
-# Keep LIRC at the end, as it has sub-menus
-source "drivers/staging/media/lirc/Kconfig"
-
 endif
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index ac090c5fce30..9c057126d61f 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -1,7 +1,6 @@
 obj-$(CONFIG_I2C_BCM2048)  += bcm2048/
 obj-$(CONFIG_DVB_CXD2099)  += cxd2099/
 obj-$(CONFIG_VIDEO_IMX_MEDIA)  += imx/
-obj-$(CONFIG_LIRC_STAGING) += lirc/
 obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
 obj-$(CONFIG_VIDEO_OMAP4)  += omap4iss/
 obj-$(CONFIG_INTEL_ATOMISP) += atomisp/
diff --git a/drivers/staging/media/lirc/Kconfig 
b/drivers/staging/media/lirc/Kconfig
deleted file mode 100644
index 3e350a9922de..
--- a/drivers/staging/media/lirc/Kconfig
+++ /dev/null
@@ -1,21 +0,0 @@
-#
-# LIRC driver(s) configuration
-#
-menuconfig LIRC_STAGING
-   bool "Linux Infrared Remote Control IR receiver/transmitter drivers"
-   depends on LIRC
-   help
- Say Y here, and all supported Linux Infrared Remote Control IR and
- RF receiver and transmitter drivers will be displayed. When paired
- with a remote control and the lirc daemon, the receiver drivers
- allow control of your Linux system via remote control.
-
-if LIRC_STAGING
-
-config LIRC_ZILOG
-   tristate "Zilog/Hauppauge IR Transmitter"
-   depends on LIRC && I2C
-   help
- Driver for the Zilog/Hauppauge IR Transmitter, found on
- PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards
-endif
diff --git a/drivers/staging/media/lirc/Makefile 
b/drivers/staging/media/lirc/Makefile
deleted file mode 100644
index 665562436e30..
--- a/drivers/staging/media/lirc/Makefile
+++ /dev/null
@@ -1,6 +0,0 @@
-# Makefile for the lirc drivers.
-#
-
-# Each configuration option enables a list of files.
-
-obj-$(CONFIG_LIRC_ZILOG)   += lirc_zilog.o
diff --git a/drivers/staging/media/lirc/TODO b/drivers/staging/media/lirc/TODO
deleted file mode 100644
index a97800a8e127..
--- a/drivers/staging/media/lirc/TODO
+++ /dev/null
@@ -1,36 +0,0 @@
-1. Both ir-kbd-i2c and lirc_zilog provide support for RX events for
-the chips supported by lirc_zilog.  Before moving lirc_zilog out of staging:
-
-a. ir-kbd-i2c needs a module parameter added to 

[PATCH v3 08/26] media: lirc: remove LIRCCODE and LIRC_GET_LENGTH

[Sean Young]

LIRCCODE is a lirc mode where a driver produces driver-dependent
codes for receive and transmit. No driver uses this any more. The
LIRC_GET_LENGTH ioctl was used for this mode only.

Signed-off-by: Sean Young 
---
 Documentation/media/lirc.h.rst.exceptions  |  5 +++
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 15 
 Documentation/media/uapi/rc/lirc-func.rst  |  1 -
 Documentation/media/uapi/rc/lirc-get-features.rst  |  7 +---
 Documentation/media/uapi/rc/lirc-get-length.rst| 44 --
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  4 +-
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |  3 +-
 drivers/media/rc/ir-lirc-codec.c   |  1 -
 drivers/media/rc/lirc_dev.c| 12 --
 include/media/lirc_dev.h   |  4 --
 10 files changed, 9 insertions(+), 87 deletions(-)
 delete mode 100644 Documentation/media/uapi/rc/lirc-get-length.rst

diff --git a/Documentation/media/lirc.h.rst.exceptions 
b/Documentation/media/lirc.h.rst.exceptions
index c130617a9986..63ba1d341905 100644
--- a/Documentation/media/lirc.h.rst.exceptions
+++ b/Documentation/media/lirc.h.rst.exceptions
@@ -28,6 +28,10 @@ ignore define LIRC_CAN_SEND_MASK
 ignore define LIRC_CAN_REC_MASK
 ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
 
+# Obsolete ioctls
+
+ignore ioctl LIRC_GET_LENGTH
+
 # Undocumented macros
 
 ignore define PULSE_BIT
@@ -40,3 +44,4 @@ ignore define LIRC_VALUE_MASK
 ignore define LIRC_MODE2_MASK
 
 ignore define LIRC_MODE_RAW
+ignore define LIRC_MODE_LIRCCODE
diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index d1936eeb9ce0..3cacf9aeac40 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -72,21 +72,6 @@ on the following table.
 this packet will be sent, with the number of microseconds with
 no IR.
 
-.. _lirc-mode-lirccode:
-
-``LIRC_MODE_LIRCCODE``
-
-This mode can be used for IR receive and send.
-
-The IR signal is decoded internally by the receiver, or encoded by the
-transmitter. The LIRC interface represents the scancode as byte string,
-which might not be a u32, it can be any length. The value is entirely
-driver dependent. This mode is used by some older lirc drivers.
-
-The length of each code depends on the driver, which can be retrieved
-with :ref:`lirc_get_length`. This length is used both
-for transmitting and receiving IR.
-
 .. _lirc-mode-pulse:
 
 ``LIRC_MODE_PULSE``
diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
b/Documentation/media/uapi/rc/lirc-func.rst
index 9b5a772ec96c..ddb4620de294 100644
--- a/Documentation/media/uapi/rc/lirc-func.rst
+++ b/Documentation/media/uapi/rc/lirc-func.rst
@@ -18,7 +18,6 @@ LIRC Function Reference
 lirc-set-send-duty-cycle
 lirc-get-timeout
 lirc-set-rec-timeout
-lirc-get-length
 lirc-set-rec-carrier
 lirc-set-rec-carrier-range
 lirc-set-send-carrier
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index 64f89a4f9d9c..50c2c26d8e89 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -62,8 +62,7 @@ LIRC features
 
 ``LIRC_CAN_REC_LIRCCODE``
 
-The driver is capable of receiving using
-:ref:`LIRC_MODE_LIRCCODE `.
+Unused. Kept just to avoid breaking uAPI.
 
 .. _LIRC-CAN-SET-SEND-CARRIER:
 
@@ -170,9 +169,7 @@ LIRC features
 
 ``LIRC_CAN_SEND_LIRCCODE``
 
-The driver supports sending (also called as IR blasting or IR TX) using
-:ref:`LIRC_MODE_LIRCCODE `.
-
+Unused. Kept just to avoid breaking uAPI.
 
 Return Value
 
diff --git a/Documentation/media/uapi/rc/lirc-get-length.rst 
b/Documentation/media/uapi/rc/lirc-get-length.rst
deleted file mode 100644
index 3990af5de0e9..
--- a/Documentation/media/uapi/rc/lirc-get-length.rst
+++ /dev/null
@@ -1,44 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _lirc_get_length:
-
-*
-ioctl LIRC_GET_LENGTH
-*
-
-Name
-
-
-LIRC_GET_LENGTH - Retrieves the code length in bits.
-
-Synopsis
-
-
-.. c:function:: int ioctl( int fd, LIRC_GET_LENGTH, __u32 *length )
-:name: LIRC_GET_LENGTH
-
-Arguments
-=
-
-``fd``
-File descriptor returned by open().
-
-``length``
-length, in bits
-
-
-Description
-===
-
-Retrieves the code length in bits (only for
-:ref:`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 

[PATCH v3 05/26] media: lirc_zilog: fix variable types and other ugliness

[Sean Young]

Cleans up code and makes checkpatch happy.

Signed-off-by: Sean Young 
---
 drivers/staging/media/lirc/lirc_zilog.c | 162 +++-
 1 file changed, 55 insertions(+), 107 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index 757b3fc247ac..902fade98d57 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -32,32 +32,15 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
  */
 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 #include 
 
@@ -70,7 +53,7 @@ struct IR_tx {
struct i2c_client *c;
 
/* TX additional actions needed */
-   int need_boot;
+   bool need_boot;
bool post_tx_ready_poll;
struct lirc_dev *l;
 };
@@ -81,45 +64,39 @@ struct IR_tx {
 /* Hauppauge IR transmitter data */
 struct tx_data_struct {
/* Boot block */
-   unsigned char *boot_data;
+   u8 *boot_data;
 
/* Start of binary data block */
-   unsigned char *datap;
+   u8 *datap;
 
/* End of binary data block */
-   unsigned char *endp;
+   u8 *endp;
 
/* Number of installed codesets */
-   unsigned int num_code_sets;
+   u32 num_code_sets;
 
/* Pointers to codesets */
-   unsigned char **code_sets;
+   u8 **code_sets;
 
/* Global fixed data template */
int fixed[TX_BLOCK_SIZE];
 };
 
 static struct tx_data_struct *tx_data;
-static struct mutex tx_data_lock;
-
-/* module parameters */
-static bool debug; /* debug output */
+static DEFINE_MUTEX(tx_data_lock);
 
 /* safe read of a uint32 (always network byte order) */
-static int read_uint32(unsigned char **data,
-  unsigned char *endp, unsigned int *val)
+static int read_u32(u8 **data, u8 *endp, u32 *val)
 {
if (*data + 4 > endp)
return 0;
-   *val = ((*data)[0] << 24) | ((*data)[1] << 16) |
-  ((*data)[2] << 8) | (*data)[3];
+   *val = get_unaligned_be32(*data);
*data += 4;
return 1;
 }
 
 /* safe read of a uint8 */
-static int read_uint8(unsigned char **data,
- unsigned char *endp, unsigned char *val)
+static int read_u8(u8 **data, u8 *endp, u8 *val)
 {
if (*data + 1 > endp)
return 0;
@@ -128,8 +105,8 @@ static int read_uint8(unsigned char **data,
 }
 
 /* safe skipping of N bytes */
-static int skip(unsigned char **data,
-   unsigned char *endp, unsigned int distance)
+static int skip(u8 **data,
+   u8 *endp, unsigned int distance)
 {
if (*data + distance > endp)
return 0;
@@ -138,11 +115,11 @@ static int skip(unsigned char **data,
 }
 
 /* decompress key data into the given buffer */
-static int get_key_data(unsigned char *buf,
+static int get_key_data(u8 *buf,
unsigned int codeset, unsigned int key)
 {
-   unsigned char *data, *endp, *diffs, *key_block;
-   unsigned char keys, ndiffs, id;
+   u8 *data, *endp, *diffs, *key_block;
+   u8 keys, ndiffs, id;
unsigned int base, lim, pos, i;
 
/* Binary search for the codeset */
@@ -150,7 +127,7 @@ static int get_key_data(unsigned char *buf,
pos = base + (lim >> 1);
data = tx_data->code_sets[pos];
 
-   if (!read_uint32(, tx_data->endp, ))
+   if (!read_u32(, tx_data->endp, ))
goto corrupt;
 
if (i == codeset) {
@@ -169,8 +146,8 @@ static int get_key_data(unsigned char *buf,
tx_data->code_sets[pos + 1] : tx_data->endp;
 
/* Read the block header */
-   if (!read_uint8(, endp, ) ||
-   !read_uint8(, endp, ) ||
+   if (!read_u8(, endp, ) ||
+   !read_u8(, endp, ) ||
ndiffs > TX_BLOCK_SIZE || keys == 0)
goto corrupt;
 
@@ -180,16 +157,16 @@ static int get_key_data(unsigned char *buf,
goto corrupt;
 
/* Read the id of the first key */
-   if (!read_uint8(, endp, ))
+   if (!read_u8(, endp, ))
goto corrupt;
 
/* Unpack the first key's data */
for (i = 0; i < TX_BLOCK_SIZE; ++i) {
if (tx_data->fixed[i] == -1) {
-   if (!read_uint8(, endp, [i]))
+   if (!read_u8(, endp, [i]))
goto corrupt;
} 

[PATCH v3 06/26] media: lirc_zilog: port to rc-core using scancode tx interface

[Sean Young]

Now that rc-core can send a scancode by rc protocol and scancode, port
the lirc_zilog to this interface. The firmware file needs updating
to contain the protocol and scancode, so we have haup-ir-blaster-v2.bin
for this.

The LIRC_MODE_LIRCCODE is no longer supported, and transmit can only
be done using the new LIRC_MODE_SCANCODE interface.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c|  30 ++-
 drivers/staging/media/lirc/lirc_zilog.c | 446 
 include/media/rc-core.h |   2 +
 3 files changed, 191 insertions(+), 287 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index a5369978e56f..41259b1ce3c2 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -122,6 +122,10 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (!lirc)
return -EFAULT;
 
+   dev = lirc->dev;
+   if (!dev)
+   return -EFAULT;
+
if (lirc->send_mode == LIRC_MODE_SCANCODE) {
struct lirc_scancode scan;
 
@@ -134,6 +138,11 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (scan.flags || scan.keycode || scan.timestamp)
return -EINVAL;
 
+   if (dev->tx_scancode) {
+   ret = dev->tx_scancode(dev, );
+   return ret < 0 ? ret : n;
+   }
+
raw = kmalloc_array(LIRCBUF_SIZE, sizeof(*raw), GFP_KERNEL);
if (!raw)
return -ENOMEM;
@@ -174,12 +183,6 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
return PTR_ERR(txbuf);
}
 
-   dev = lirc->dev;
-   if (!dev) {
-   ret = -EFAULT;
-   goto out;
-   }
-
if (!dev->tx_ir) {
ret = -EINVAL;
goto out;
@@ -252,16 +255,19 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
 
/* mode support */
case LIRC_GET_SEND_MODE:
-   if (!dev->tx_ir)
+   if (!dev->tx_ir && !dev->tx_scancode)
return -ENOTTY;
 
val = lirc->send_mode;
break;
 
case LIRC_SET_SEND_MODE:
-   if (!dev->tx_ir)
+   if (!dev->tx_ir && !dev->tx_scancode)
return -ENOTTY;
 
+   if (!dev->tx_ir && val == LIRC_MODE_PULSE)
+   return -EINVAL;
+
if (!(val == LIRC_MODE_PULSE || val == LIRC_MODE_SCANCODE))
return -EINVAL;
 
@@ -410,6 +416,9 @@ static int ir_lirc_register(struct rc_dev *dev)
features |= LIRC_CAN_GET_REC_RESOLUTION;
}
 
+   if (dev->tx_scancode)
+   features |= LIRC_CAN_SEND_SCANCODE;
+
if (dev->tx_ir) {
features |= LIRC_CAN_SEND_PULSE | LIRC_CAN_SEND_SCANCODE;
if (dev->s_tx_mask)
@@ -450,7 +459,10 @@ static int ir_lirc_register(struct rc_dev *dev)
if (rc < 0)
goto out;
 
-   dev->raw->lirc.send_mode = LIRC_MODE_PULSE;
+   if (dev->tx_scancode)
+   dev->raw->lirc.send_mode = LIRC_MODE_SCANCODE;
+   else
+   dev->raw->lirc.send_mode = LIRC_MODE_PULSE;
 
dev->raw->lirc.ldev = ldev;
dev->raw->lirc.dev = dev;
diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index 902fade98d57..62614e7265eb 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -41,11 +41,11 @@
 #include 
 #include 
 
-#include 
-#include 
+#include 
 
+#define DEVICE_NAME"Zilog/Hauppauge i2c IR TX"
 /* Max transfer size done by I2C transfer functions */
-#define MAX_XFER_SIZE  64
+#define MAX_XFER_SIZE  64
 
 struct IR_tx {
/* TX device */
@@ -55,7 +55,8 @@ struct IR_tx {
/* TX additional actions needed */
bool need_boot;
bool post_tx_ready_poll;
-   struct lirc_dev *l;
+   struct rc_dev *rc;
+   char phys[32];
 };
 
 /* Block size for IR transmitter */
@@ -115,102 +116,103 @@ static int skip(u8 **data,
 }
 
 /* decompress key data into the given buffer */
-static int get_key_data(u8 *buf,
-   unsigned int codeset, unsigned int key)
+static int get_key_data(u8 *buf, enum rc_proto proto, u32 scancode)
 {
u8 *data, *endp, *diffs, *key_block;
-   u8 keys, ndiffs, id;
-   unsigned int base, lim, pos, i;
+   unsigned int lim, i, base, codeset, pos;
+   u8 keys, ndiffs, p;
+   u32 protocols, s;
 
/* Binary search for the codeset */
-   for (base = 0, lim = tx_data->num_code_sets; lim; lim >>= 1) {
-   pos = base + (lim >> 1);
-   data = tx_data->code_sets[pos];
+   for 

[PATCH v3 03/26] media: rc: auto load encoder if necessary

[Sean Young]

When sending scancodes, load the encoder if we need it.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-core-priv.h | 1 +
 drivers/media/rc/rc-ir-raw.c| 2 ++
 drivers/media/rc/rc-main.c  | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 3cf09408df6c..d29b1b1ef4b7 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -271,6 +271,7 @@ void ir_raw_event_free(struct rc_dev *dev);
 void ir_raw_event_unregister(struct rc_dev *dev);
 int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
+void ir_raw_load_modules(u64 *protocols);
 void ir_raw_init(void);
 
 /*
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 0814e08a280b..b84201cb012a 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -457,6 +457,8 @@ int ir_raw_encode_scancode(enum rc_proto protocol, u32 
scancode,
int ret = -EINVAL;
u64 mask = 1ULL << protocol;
 
+   ir_raw_load_modules();
+
mutex_lock(_raw_handler_lock);
list_for_each_entry(handler, _raw_handler_list, list) {
if (handler->protocols & mask && handler->encode) {
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index cb78e5702bef..62102b3ef5aa 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1081,7 +1081,7 @@ static int parse_protocol_change(u64 *protocols, const 
char *buf)
return count;
 }
 
-static void ir_raw_load_modules(u64 *protocols)
+void ir_raw_load_modules(u64 *protocols)
 {
u64 available;
int i, ret;
-- 
2.13.6

[PATCH v3 02/26] media: lirc: use the correct carrier for scancode transmit

[Sean Young]

If the lirc device supports it, set the carrier for the protocol.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-jvc-decoder.c |  1 +
 drivers/media/rc/ir-lirc-codec.c  |  7 +++
 drivers/media/rc/ir-mce_kbd-decoder.c |  1 +
 drivers/media/rc/ir-nec-decoder.c |  1 +
 drivers/media/rc/ir-rc5-decoder.c |  1 +
 drivers/media/rc/ir-rc6-decoder.c |  1 +
 drivers/media/rc/ir-sanyo-decoder.c   |  1 +
 drivers/media/rc/ir-sharp-decoder.c   |  1 +
 drivers/media/rc/ir-sony-decoder.c|  1 +
 drivers/media/rc/rc-core-priv.h   |  1 +
 drivers/media/rc/rc-ir-raw.c  | 30 ++
 include/media/rc-core.h   |  1 +
 12 files changed, 47 insertions(+)

diff --git a/drivers/media/rc/ir-jvc-decoder.c 
b/drivers/media/rc/ir-jvc-decoder.c
index e2bd68c42edf..2ae20dfc0e61 100644
--- a/drivers/media/rc/ir-jvc-decoder.c
+++ b/drivers/media/rc/ir-jvc-decoder.c
@@ -212,6 +212,7 @@ static struct ir_raw_handler jvc_handler = {
.protocols  = RC_PROTO_BIT_JVC,
.decode = ir_jvc_decode,
.encode = ir_jvc_encode,
+   .carrier= 38000,
 };
 
 static int __init ir_jvc_decode_init(void)
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 2c89b4474e31..a5369978e56f 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -154,6 +154,13 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
for (i = 0; i < count; i++)
/* Convert from NS to US */
txbuf[i] = DIV_ROUND_UP(raw[i].duration, 1000);
+
+   if (dev->s_tx_carrier) {
+   int carrier = ir_raw_encode_carrier(scan.rc_proto);
+
+   if (carrier > 0)
+   dev->s_tx_carrier(dev, carrier);
+   }
} else {
if (n < sizeof(unsigned int) || n % sizeof(unsigned int))
return -EINVAL;
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 7c572a643656..efa3b735dcc4 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -474,6 +474,7 @@ static struct ir_raw_handler mce_kbd_handler = {
.encode = ir_mce_kbd_encode,
.raw_register   = ir_mce_kbd_register,
.raw_unregister = ir_mce_kbd_unregister,
+   .carrier= 36000,
 };
 
 static int __init ir_mce_kbd_decode_init(void)
diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index a95d09acc22a..4ace5648866d 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -264,6 +264,7 @@ static struct ir_raw_handler nec_handler = {
RC_PROTO_BIT_NEC32,
.decode = ir_nec_decode,
.encode = ir_nec_encode,
+   .carrier= 38000,
 };
 
 static int __init ir_nec_decode_init(void)
diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index 1292f534de43..cd1c4ee5fcd4 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -282,6 +282,7 @@ static struct ir_raw_handler rc5_handler = {
RC_PROTO_BIT_RC5_SZ,
.decode = ir_rc5_decode,
.encode = ir_rc5_encode,
+   .carrier= 36000,
 };
 
 static int __init ir_rc5_decode_init(void)
diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index 5d0d2fe3b7a7..665025303c28 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -408,6 +408,7 @@ static struct ir_raw_handler rc6_handler = {
  RC_PROTO_BIT_RC6_MCE,
.decode = ir_rc6_decode,
.encode = ir_rc6_encode,
+   .carrier= 36000,
 };
 
 static int __init ir_rc6_decode_init(void)
diff --git a/drivers/media/rc/ir-sanyo-decoder.c 
b/drivers/media/rc/ir-sanyo-decoder.c
index 758c60956850..723e7d75a593 100644
--- a/drivers/media/rc/ir-sanyo-decoder.c
+++ b/drivers/media/rc/ir-sanyo-decoder.c
@@ -218,6 +218,7 @@ static struct ir_raw_handler sanyo_handler = {
.protocols  = RC_PROTO_BIT_SANYO,
.decode = ir_sanyo_decode,
.encode = ir_sanyo_encode,
+   .carrier= 38000,
 };
 
 static int __init ir_sanyo_decode_init(void)
diff --git a/drivers/media/rc/ir-sharp-decoder.c 
b/drivers/media/rc/ir-sharp-decoder.c
index ed43a4212479..73174081e843 100644
--- a/drivers/media/rc/ir-sharp-decoder.c
+++ b/drivers/media/rc/ir-sharp-decoder.c
@@ -226,6 +226,7 @@ static struct ir_raw_handler sharp_handler = {
.protocols  = RC_PROTO_BIT_SHARP,
.decode = ir_sharp_decode,
.encode = ir_sharp_encode,
+   

[PATCH v3 01/26] media: lirc: implement scancode sending

[Sean Young]

This introduces a new lirc mode: scancode. Any device which can send raw IR
can now also send scancodes.

int main()
{
int mode, fd = open("/dev/lirc0", O_RDWR);

mode = LIRC_MODE_SCANCODE;
if (ioctl(fd, LIRC_SET_SEND_MODE, )) {
// kernel too old or lirc does not support transmit
}
struct lirc_scancode scancode = {
.scancode = 0x1e3d,
.rc_proto = RC_PROTO_RC5,
};
write(fd, , sizeof(scancode));
close(fd);
}

The other fields of lirc_scancode must be set to 0.

Note that toggle (rc5, rc6) and repeats (nec) are not implemented. Nor is
there a method for holding down a key for a period.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 99 +---
 drivers/media/rc/rc-core-priv.h  |  2 +-
 include/media/rc-map.h   | 54 +-
 include/uapi/linux/lirc.h| 82 +
 4 files changed, 156 insertions(+), 81 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 8f2f37412fc5..2c89b4474e31 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -107,7 +107,8 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
 {
struct lirc_codec *lirc;
struct rc_dev *dev;
-   unsigned int *txbuf; /* buffer with values to transmit */
+   unsigned int *txbuf = NULL;
+   struct ir_raw_event *raw = NULL;
ssize_t ret = -EINVAL;
size_t count;
ktime_t start;
@@ -121,16 +122,50 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (!lirc)
return -EFAULT;
 
-   if (n < sizeof(unsigned) || n % sizeof(unsigned))
-   return -EINVAL;
+   if (lirc->send_mode == LIRC_MODE_SCANCODE) {
+   struct lirc_scancode scan;
 
-   count = n / sizeof(unsigned);
-   if (count > LIRCBUF_SIZE || count % 2 == 0)
-   return -EINVAL;
+   if (n != sizeof(scan))
+   return -EINVAL;
 
-   txbuf = memdup_user(buf, n);
-   if (IS_ERR(txbuf))
-   return PTR_ERR(txbuf);
+   if (copy_from_user(, buf, sizeof(scan)))
+   return -EFAULT;
+
+   if (scan.flags || scan.keycode || scan.timestamp)
+   return -EINVAL;
+
+   raw = kmalloc_array(LIRCBUF_SIZE, sizeof(*raw), GFP_KERNEL);
+   if (!raw)
+   return -ENOMEM;
+
+   ret = ir_raw_encode_scancode(scan.rc_proto, scan.scancode,
+raw, LIRCBUF_SIZE);
+   if (ret < 0)
+   goto out;
+
+   count = ret;
+
+   txbuf = kmalloc_array(count, sizeof(unsigned int), GFP_KERNEL);
+   if (!txbuf) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   for (i = 0; i < count; i++)
+   /* Convert from NS to US */
+   txbuf[i] = DIV_ROUND_UP(raw[i].duration, 1000);
+   } else {
+   if (n < sizeof(unsigned int) || n % sizeof(unsigned int))
+   return -EINVAL;
+
+   count = n / sizeof(unsigned int);
+   if (count > LIRCBUF_SIZE || count % 2 == 0)
+   return -EINVAL;
+
+   txbuf = memdup_user(buf, n);
+   if (IS_ERR(txbuf))
+   return PTR_ERR(txbuf);
+   }
 
dev = lirc->dev;
if (!dev) {
@@ -156,24 +191,30 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (ret < 0)
goto out;
 
-   for (duration = i = 0; i < ret; i++)
-   duration += txbuf[i];
-
-   ret *= sizeof(unsigned int);
-
-   /*
-* The lircd gap calculation expects the write function to
-* wait for the actual IR signal to be transmitted before
-* returning.
-*/
-   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
-   if (towait > 0) {
-   set_current_state(TASK_INTERRUPTIBLE);
-   schedule_timeout(usecs_to_jiffies(towait));
+   if (lirc->send_mode == LIRC_MODE_SCANCODE) {
+   ret = n;
+   } else {
+   for (duration = i = 0; i < ret; i++)
+   duration += txbuf[i];
+
+   ret *= sizeof(unsigned int);
+
+   /*
+* The lircd gap calculation expects the write function to
+* wait for the actual IR signal to be transmitted before
+* returning.
+*/
+   towait = ktime_us_delta(ktime_add_us(start, duration),
+   ktime_get());
+   if 

[PATCH v3 04/26] media: lirc_zilog: remove receiver

[Sean Young]

The ir-kbd-i2c module already handles this very well.

Signed-off-by: Sean Young 
---
 drivers/staging/media/lirc/lirc_zilog.c | 901 +++-
 1 file changed, 76 insertions(+), 825 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index 6bd0717bf76e..757b3fc247ac 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -64,28 +64,7 @@
 /* Max transfer size done by I2C transfer functions */
 #define MAX_XFER_SIZE  64
 
-struct IR;
-
-struct IR_rx {
-   struct kref ref;
-   struct IR *ir;
-
-   /* RX device */
-   struct mutex client_lock;
-   struct i2c_client *c;
-
-   /* RX polling thread data */
-   struct task_struct *task;
-
-   /* RX read data */
-   unsigned char b[3];
-   bool hdpvr_data_fmt;
-};
-
 struct IR_tx {
-   struct kref ref;
-   struct IR *ir;
-
/* TX device */
struct mutex client_lock;
struct i2c_client *c;
@@ -93,39 +72,9 @@ struct IR_tx {
/* TX additional actions needed */
int need_boot;
bool post_tx_ready_poll;
-};
-
-struct IR {
-   struct kref ref;
-   struct list_head list;
-
-   /* FIXME spinlock access to l->features */
struct lirc_dev *l;
-   struct lirc_buffer rbuf;
-
-   struct mutex ir_lock;
-   atomic_t open_count;
-
-   struct device *dev;
-   struct i2c_adapter *adapter;
-
-   spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
-   struct IR_rx *rx;
-
-   spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
-   struct IR_tx *tx;
 };
 
-/* IR transceiver instance object list */
-/*
- * This lock is used for the following:
- * a. ir_devices_list access, insertions, deletions
- * b. struct IR kref get()s and put()s
- * c. serialization of ir_probe() for the two i2c_clients for a Z8
- */
-static DEFINE_MUTEX(ir_devices_lock);
-static LIST_HEAD(ir_devices_list);
-
 /* Block size for IR transmitter */
 #define TX_BLOCK_SIZE  99
 
@@ -153,348 +102,8 @@ struct tx_data_struct {
 static struct tx_data_struct *tx_data;
 static struct mutex tx_data_lock;
 
-
 /* module parameters */
 static bool debug; /* debug output */
-static bool tx_only;   /* only handle the IR Tx function */
-
-
-/* struct IR reference counting */
-static struct IR *get_ir_device(struct IR *ir, bool ir_devices_lock_held)
-{
-   if (ir_devices_lock_held) {
-   kref_get(>ref);
-   } else {
-   mutex_lock(_devices_lock);
-   kref_get(>ref);
-   mutex_unlock(_devices_lock);
-   }
-   return ir;
-}
-
-static void release_ir_device(struct kref *ref)
-{
-   struct IR *ir = container_of(ref, struct IR, ref);
-
-   /*
-* Things should be in this state by now:
-* ir->rx set to NULL and deallocated - happens before ir->rx->ir put()
-* ir->rx->task kthread stopped - happens before ir->rx->ir put()
-* ir->tx set to NULL and deallocated - happens before ir->tx->ir put()
-* ir->open_count ==  0 - happens on final close()
-* ir_lock, tx_ref_lock, rx_ref_lock, all released
-*/
-   if (ir->l)
-   lirc_unregister_device(ir->l);
-
-   if (kfifo_initialized(>rbuf.fifo))
-   lirc_buffer_free(>rbuf);
-   list_del(>list);
-   kfree(ir);
-}
-
-static int put_ir_device(struct IR *ir, bool ir_devices_lock_held)
-{
-   int released;
-
-   if (ir_devices_lock_held)
-   return kref_put(>ref, release_ir_device);
-
-   mutex_lock(_devices_lock);
-   released = kref_put(>ref, release_ir_device);
-   mutex_unlock(_devices_lock);
-
-   return released;
-}
-
-/* struct IR_rx reference counting */
-static struct IR_rx *get_ir_rx(struct IR *ir)
-{
-   struct IR_rx *rx;
-
-   spin_lock(>rx_ref_lock);
-   rx = ir->rx;
-   if (rx)
-   kref_get(>ref);
-   spin_unlock(>rx_ref_lock);
-   return rx;
-}
-
-static void destroy_rx_kthread(struct IR_rx *rx, bool ir_devices_lock_held)
-{
-   /* end up polling thread */
-   if (!IS_ERR_OR_NULL(rx->task)) {
-   kthread_stop(rx->task);
-   rx->task = NULL;
-   /* Put the ir ptr that ir_probe() gave to the rx poll thread */
-   put_ir_device(rx->ir, ir_devices_lock_held);
-   }
-}
-
-static void release_ir_rx(struct kref *ref)
-{
-   struct IR_rx *rx = container_of(ref, struct IR_rx, ref);
-   struct IR *ir = rx->ir;
-
-   /*
-* This release function can't do all the work, as we want
-* to keep the rx_ref_lock a spinlock, and killing the poll thread
-* and releasing the ir reference can cause a sleep.  That work is
-* performed by put_ir_rx()
-*/
-   ir->l->features &= ~LIRC_CAN_REC_LIRCCODE;
-   /* Don't put_ir_device(rx->ir) here; lock can't be freed 

[PATCH v3 00/26] lirc scancode interface, and more

[Sean Young]

Introduce lirc scancode mode, use that to port lirc_zilog to rc-core
using that interface, and then remove the lirc kernel api.

In summary:
 - This removes the lirc staging directory.
 - lirc IR TX can use in-kernel encoders for scancode encoding
 - lirc_zilog uses the same interface
 - lirc kapi (not uapi!) is gone
 - The reading lirc scancode gives more information (e.g. protocol,
   toggle, repeat). So you can determine what protocol variant a remotes uses
 - Line count is actually down and code cleaner (imo)

v2:
 - Add MAINTAINERS entries
 - Fixes for nec repeat
 - Validate scancode for tx
 - Minor bugfixes

v3:
 - Review comments from Hans Verkuil
 - Documented and fixed rc_validate_scancode()
 - Fix a bug in kfifo on arm 32-bit
 - this inferface won't be used for cec remote control passthrough

Sean Young (26):
  media: lirc: implement scancode sending
  media: lirc: use the correct carrier for scancode transmit
  media: rc: auto load encoder if necessary
  media: lirc_zilog: remove receiver
  media: lirc_zilog: fix variable types and other ugliness
  media: lirc_zilog: port to rc-core using scancode tx interface
  media: promote lirc_zilog out of staging
  media: lirc: remove LIRCCODE and LIRC_GET_LENGTH
  media: lirc: lirc interface should not be a raw decoder
  media: lirc: validate scancode for transmit
  media: rc: document and fix rc_validate_scancode()
  media: lirc: merge lirc_dev_fop_ioctl and ir_lirc_ioctl
  media: lirc: use kfifo rather than lirc_buffer for raw IR
  media: lirc: move lirc_dev->attached to rc_dev->registered
  media: lirc: do not call rc_close() on unregistered devices
  media: lirc: create rc-core open and close lirc functions
  media: lirc: remove name from lirc_dev
  media: lirc: remove last remnants of lirc kapi
  media: lirc: implement reading scancode
  media: rc: ensure lirc device receives nec repeats
  media: lirc: document LIRC_MODE_SCANCODE
  media: lirc: introduce LIRC_SET_POLL_MODES
  media: lirc: scancode rc devices should have a lirc device too
  media: MAINTAINERS: remove lirc staging area
  media: MAINTAINERS: add entry for zilog_ir
  kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

 Documentation/media/kapi/rc-core.rst   |5 -
 Documentation/media/lirc.h.rst.exceptions  |   31 +
 Documentation/media/uapi/rc/lirc-dev-intro.rst |   68 +-
 Documentation/media/uapi/rc/lirc-func.rst  |2 +-
 Documentation/media/uapi/rc/lirc-get-features.rst  |   17 +-
 Documentation/media/uapi/rc/lirc-get-length.rst|   44 -
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |5 +-
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |2 +-
 Documentation/media/uapi/rc/lirc-read.rst  |   15 +-
 .../media/uapi/rc/lirc-set-poll-modes.rst  |   52 +
 Documentation/media/uapi/rc/lirc-write.rst |   19 +-
 MAINTAINERS|   12 +-
 drivers/media/rc/Kconfig   |   41 +-
 drivers/media/rc/Makefile  |6 +-
 drivers/media/rc/ir-jvc-decoder.c  |1 +
 drivers/media/rc/ir-lirc-codec.c   |  566 ---
 drivers/media/rc/ir-mce_kbd-decoder.c  |   12 +-
 drivers/media/rc/ir-nec-decoder.c  |1 +
 drivers/media/rc/ir-rc5-decoder.c  |1 +
 drivers/media/rc/ir-rc6-decoder.c  |1 +
 drivers/media/rc/ir-sanyo-decoder.c|1 +
 drivers/media/rc/ir-sharp-decoder.c|1 +
 drivers/media/rc/ir-sony-decoder.c |1 +
 drivers/media/rc/lirc_dev.c|  489 +-
 drivers/media/rc/rc-core-priv.h|   54 +-
 drivers/media/rc/rc-ir-raw.c   |   56 +-
 drivers/media/rc/rc-main.c |  166 +-
 drivers/media/rc/zilog_ir.c|  742 +
 drivers/staging/media/Kconfig  |3 -
 drivers/staging/media/Makefile |1 -
 drivers/staging/media/lirc/Kconfig |   21 -
 drivers/staging/media/lirc/Makefile|6 -
 drivers/staging/media/lirc/TODO|   36 -
 drivers/staging/media/lirc/lirc_zilog.c| 1653 
 include/linux/kfifo.h  |3 +-
 include/media/lirc_dev.h   |  192 ---
 include/media/rc-core.h|   55 +-
 include/media/rc-map.h |   54 +-
 include/uapi/linux/lirc.h  |   91 ++
 39 files changed, 1734 insertions(+), 2792 deletions(-)
 delete mode 100644 Documentation/media/uapi/rc/lirc-get-length.rst
 create mode 100644 Documentation/media/uapi/rc/lirc-set-poll-modes.rst
 create mode 100644 drivers/media/rc/zilog_ir.c
 delete mode 100644 drivers/staging/media/lirc/Kconfig
 delete mode 100644 drivers/staging/media/lirc/Makefile
 delete mode 

Re: [PATCH] media: rc: ir-spi needs OF

[Andi Shyti]

On Mon, Oct 09, 2017 at 09:46:50AM +0100, Sean Young wrote:
> Without device tree, there is no way to use this driver.
> 
> Signed-off-by: Sean Young 

Thanks, Sean!

Acked-by: Andi Shyti 

Andi

> ---
>  drivers/media/rc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index bde3c271fb88..afb3456d4e20 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -286,6 +286,7 @@ config IR_REDRAT3
>  config IR_SPI
>   tristate "SPI connected IR LED"
>   depends on SPI && LIRC
> + depends on OF || COMPILE_TEST
>   ---help---
> Say Y if you want to use an IR LED connected through SPI bus.
>  
> -- 
> 2.13.6
> 
>