cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Apr 29 05:00:17 CEST 2017
media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa
media_build git hash:   1af19680bde3e227d64d99ff5fdc43eb343a3b28
v4l-utils git hash: 847bf8d62cd6b11defc1e4c3b30b68d3c66876e0
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
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-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: 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-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Mauro Carvalho Chehab]

Em Sat, 29 Apr 2017 00:00:05 +0200
Pavel Machek  escreveu:

> Hi!
> 
> > Hmm... if the idea is to have a control that doesn't do ringing
> > compensation, then it should be clear at the control's descriptions
> > that:
> > 
> > - V4L2_CID_FOCUS_ABSOLUTE should be used if the VCM has ringing
> >   compensation;
> > - V4L2_CID_VOICE_COIL_CURRENT and V4L2_CID_VOICE_COIL_RING_COMPENSATION
> >   should be used otherwise.
> > 
> > Btw, if the rationale for this patch is to support devices without
> > ring compensation, so, both controls and their descriptions should
> > be added at the same time, together with a patchset that would be
> > using both.
> >   
> > > How about adding such an explanation added to the commit message?  
> > 
> > It is not enough. Documentation should be clear that VCM devices
> > with ring compensation should use V4L2_CID_FOCUS_ABSOLUTE.  
> 
> Is ring compensation actually a big deal? We do not publish enough
> information to userland about how fast the autofocus system is,
> anyway, so it looks like userland can't depend on such details...

Well, I guess a V4L2 event could be used to identify the VCM's
current position and/or notify when the movement finished.

Anyway, the point is:

If V4L2_CID_VOICE_COIL_CURRENT would do the same as:
V4L2_CID_FOCUS_ABSOLUTE
or:
max - V4L2_CID_FOCUS_ABSOLUTE

there's no reason to create a new control, as the existing control
was already created to control the VCM current [1].

[1] Ok, we need to better document it, but that's a separate issue

We should create a new control only if it is doing something
different than the "standard" way of controlling a Voice Coil Motor.

On such case, the difference between controlling VCM via
V4L2_CID_VOICE_COIL_CURRENT or via V4L2_CID_FOCUS_ABSOLUTE should be 
clearly stated, as we expect that the other devices with the same need 
will implement the same control set and the same max/min convention
(e. g. max integer value meaning closest focus, min integer value
meaning infinite).

Thanks,
Mauro

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Jordan Crouse]

On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
> +int venus_boot(struct device *parent, struct device *fw_dev)
> +{
> + const struct firmware *mdt;
> + phys_addr_t mem_phys;
> + ssize_t fw_size;
> + size_t mem_size;
> + void *mem_va;
> + int ret;
> +
> + if (!qcom_scm_is_available())
> + return -EPROBE_DEFER;
> +
> + fw_dev->parent = parent;
> + fw_dev->release = device_release_dummy;
> +
> + ret = dev_set_name(fw_dev, "%s:%s", dev_name(parent), "firmware");
> + if (ret)
> + return ret;
> +
> + ret = device_register(fw_dev);
> + if (ret < 0)
> + return ret;
> +
> + ret = of_reserved_mem_device_init_by_idx(fw_dev, parent->of_node, 0);
> + if (ret)
> + goto err_unreg_device;
> +
> + mem_size = VENUS_FW_MEM_SIZE;
> +
> + mem_va = dmam_alloc_coherent(fw_dev, mem_size, _phys, GFP_KERNEL);
> + if (!mem_va) {
> + ret = -ENOMEM;
> + goto err_unreg_device;
> + }
> +
> + ret = request_firmware(, VENUS_FIRMWARE_NAME, fw_dev);
> + if (ret < 0)
> + goto err_unreg_device;
> +
> + fw_size = qcom_mdt_get_size(mdt);
> + if (fw_size < 0) {
> + ret = fw_size;
> + release_firmware(mdt);
> + goto err_unreg_device;
> + }
> +
> + ret = qcom_mdt_load(fw_dev, mdt, VENUS_FIRMWARE_NAME, VENUS_PAS_ID,
> + mem_va, mem_phys, mem_size);
> +
> + release_firmware(mdt);
> +
> + if (ret)
> + goto err_unreg_device;
> +
> + ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> + if (ret)
> + goto err_unreg_device;
> +
> + return 0;
> +
> +err_unreg_device:
> + device_unregister(fw_dev);
> + return ret;
> +}

Hey, this looks familiar - almost line for line identical to what we'll need to
do for GPU.

Bjorn - Is this enough to qualify for generic status in the mdt_loader code?
I know its just two consumers, but it would save 50 or 60 lines of code between
the two drivers and be easier to maintain.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Pavel Machek]

Hi!

> Hmm... if the idea is to have a control that doesn't do ringing
> compensation, then it should be clear at the control's descriptions
> that:
> 
> - V4L2_CID_FOCUS_ABSOLUTE should be used if the VCM has ringing
>   compensation;
> - V4L2_CID_VOICE_COIL_CURRENT and V4L2_CID_VOICE_COIL_RING_COMPENSATION
>   should be used otherwise.
> 
> Btw, if the rationale for this patch is to support devices without
> ring compensation, so, both controls and their descriptions should
> be added at the same time, together with a patchset that would be
> using both.
> 
> > How about adding such an explanation added to the commit message?
> 
> It is not enough. Documentation should be clear that VCM devices
> with ring compensation should use V4L2_CID_FOCUS_ABSOLUTE.

Is ring compensation actually a big deal? We do not publish enough
information to userland about how fast the autofocus system is,
anyway, so it looks like userland can't depend on such details...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl

[Sean Young]

On Fri, Apr 28, 2017 at 06:59:11PM +0200, David Härdeman wrote:
> On Fri, Apr 28, 2017 at 08:31:33AM -0300, Mauro Carvalho Chehab wrote:
> >Em Thu, 27 Apr 2017 22:34:23 +0200
> >David Härdeman  escreveu:
> ...
> >> This patch changes how the "input_keymap_entry" struct is interpreted
> >> by rc-core by casting it to "rc_keymap_entry":
> >> 
> >> struct rc_scancode {
> >>__u16 protocol;
> >>__u16 reserved[3];
> >>__u64 scancode;
> >> }
> >> 
> >> struct rc_keymap_entry {
> >>__u8  flags;
> >>__u8  len;
> >>__u16 index;
> >>__u32 keycode;
> >>union {
> >>struct rc_scancode rc;
> >>__u8 raw[32];
> >>};
> >> };
> >> 
> ...
> >
> >Nack.
> 
> That's not a very constructive approach. If you have a better approach
> in mind I'm all ears. Because you're surely not suggesting that we stay
> with the current protocol-less approach forever?

Well, what problem are we trying to solve actually?

Looking at the keymaps we have already, there are many scancodes which
overlap and only a few of them use a different protocol. So having this
feature will not suddenly make it possible to load all our keymaps, it
will just make it possible to simultaneously load a few more.

> >No userspace breakages are allowed.
> 
> That's a gross oversimplification.

This can be implemented without breaking userspace.


Sean

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

[Logan Gunthorpe]

On 28/04/17 11:51 AM, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 28/04/17 12:30 AM, Herbert Xu wrote:
>>> You are right.  Indeed the existing code looks buggy as they
>>> don't take sg->offset into account when doing the kmap.  Could
>>> you send me some patches that fix these problems first so that
>>> they can be easily backported?
>>
>> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
>> both do have the sg->offset accounted for. I'll send a patch for the
>> buggy one shortly.
> 
> I think they're all buggy when sg->offset is greater than PAGE_SIZE.

Yes, technically. But that's a _very_ common mistake. Pretty nearly
every case I looked at did not take that into account. I don't think
sg's that point to more than one continuous page are all that common.

Fixing all those cases without making a common function is a waste of
time IMO.

Logan

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Tony Lindgren]

* Sebastian Reichel  [170428 11:29]:
> Hi,
> 
> On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen  [170428 04:15]:
> > > On 14/04/17 13:25, Hans Verkuil wrote:
> > > > From: Hans Verkuil 
> > > > 
> > > > The CEC pin was always pulled up, making it impossible to use it.
> > > > 
> > > > Change to PIN_INPUT so it can be used by the new CEC support.
> > ...
> > 
> > > Reviewed-by: Tomi Valkeinen 
> > > 
> > > Tony, can you queue this? It's safe to apply separately from the rest of
> > > the HDMI CEC work.
> > 
> > Sure will do.
> 
> I guess the same patch should be applied to Droid 4?

I guess it depends if there is an external pull or not. If there's
an external pull, the internal pull needs to be disabled as otherwise
the resistors are parallel and pull value is much lower than intended.

Looks like on droid 4 we have:

$ grep 09a /sys/kernel/debug/pinctrl/4a100040.pinmux/pins
pin 45 (PIN45) 4a10009a 0118 pinctrl-single

$ grep PULL_ENA ./include/dt-bindings/pinctrl/omap.h
#define PULL_ENA(1 << 3)
...

So bit 3 is set and internal pull is enabled in pinmux_dss_hdmi_pins
for droid 4 also.

The pull seems to be enabled in the Android kernel too:

# rwmem -s16 0x4a10009a
0x4a10009a = 0x0118

So needs to be tested, what's the simplest test to check the CEC?

Hmm I wonder if disabling the internal pull also allows removing
the "regulator-always-on" hack for hdmi_regulator there? Without
regulator-always-on I noticed that HDMI panel resolutions are not
detected. This I can test easily..

Regards,

Tony

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

[Herbert Xu]

On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 28/04/17 12:30 AM, Herbert Xu wrote:
> > You are right.  Indeed the existing code looks buggy as they
> > don't take sg->offset into account when doing the kmap.  Could
> > you send me some patches that fix these problems first so that
> > they can be easily backported?
> 
> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
> both do have the sg->offset accounted for. I'll send a patch for the
> buggy one shortly.

I think they're all buggy when sg->offset is greater than PAGE_SIZE.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Sebastian Reichel]

Hi,

On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen  [170428 04:15]:
> > On 14/04/17 13:25, Hans Verkuil wrote:
> > > From: Hans Verkuil 
> > > 
> > > The CEC pin was always pulled up, making it impossible to use it.
> > > 
> > > Change to PIN_INPUT so it can be used by the new CEC support.
> ...
> 
> > Reviewed-by: Tomi Valkeinen 
> > 
> > Tony, can you queue this? It's safe to apply separately from the rest of
> > the HDMI CEC work.
> 
> Sure will do.

I guess the same patch should be applied to Droid 4?

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] ir-lirc-codec: let lirc_dev handle the lirc_buffer

[David Härdeman]

On Fri, Apr 28, 2017 at 07:04:09PM +0200, David Härdeman wrote:
>ir_lirc_register() currently creates its own lirc_buffer before
>passing the lirc_driver to lirc_register_driver().
>
>When a module is later unloaded, ir_lirc_unregister() gets called
>which performs a call to lirc_unregister_driver() and then free():s
>the lirc_buffer.
>
>The problem is that:
>
>a) there can still be a userspace app holding an open lirc fd
>   when lirc_unregister_driver() returns; and
>
>b) the lirc_buffer contains "wait_queue_head_t wait_poll" which
>   is potentially used as long as any userspace app is still around.
>
>The result is an oops which can be triggered quite easily by a
>userspace app monitoring its lirc fd using epoll() and not closing
>the fd promptly on device removal.
>
>The minimalistic fix is to let lirc_dev create the lirc_buffer since
>lirc_dev will then also free the buffer once it believes it is safe to
>do so.
>
>I'm pretty certain that any driver which creates its own lirc_buffer
>is quite likely to be buggy as well, but that seems to only concern
>staging.
>
>Signed-off-by: David Härdeman 

And there should probably be a CC: sta...@vger.kernel.org here...

>---
> drivers/media/rc/ir-lirc-codec.c |   23 +--
> 1 file changed, 5 insertions(+), 18 deletions(-)

[PATCH] ir-lirc-codec: let lirc_dev handle the lirc_buffer

[David Härdeman]

ir_lirc_register() currently creates its own lirc_buffer before
passing the lirc_driver to lirc_register_driver().

When a module is later unloaded, ir_lirc_unregister() gets called
which performs a call to lirc_unregister_driver() and then free():s
the lirc_buffer.

The problem is that:

a) there can still be a userspace app holding an open lirc fd
   when lirc_unregister_driver() returns; and

b) the lirc_buffer contains "wait_queue_head_t wait_poll" which
   is potentially used as long as any userspace app is still around.

The result is an oops which can be triggered quite easily by a
userspace app monitoring its lirc fd using epoll() and not closing
the fd promptly on device removal.

The minimalistic fix is to let lirc_dev create the lirc_buffer since
lirc_dev will then also free the buffer once it believes it is safe to
do so.

I'm pretty certain that any driver which creates its own lirc_buffer
is quite likely to be buggy as well, but that seems to only concern
staging.

Signed-off-by: David Härdeman 
---
 drivers/media/rc/ir-lirc-codec.c |   23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index de85f1d7ce43..7b961357d333 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -354,7 +354,6 @@ static const struct file_operations lirc_fops = {
 static int ir_lirc_register(struct rc_dev *dev)
 {
struct lirc_driver *drv;
-   struct lirc_buffer *rbuf;
int rc = -ENOMEM;
unsigned long features = 0;
 
@@ -362,19 +361,12 @@ static int ir_lirc_register(struct rc_dev *dev)
if (!drv)
return rc;
 
-   rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-   if (!rbuf)
-   goto rbuf_alloc_failed;
-
-   rc = lirc_buffer_init(rbuf, sizeof(int), LIRCBUF_SIZE);
-   if (rc)
-   goto rbuf_init_failed;
-
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_ir) {
features |= LIRC_CAN_SEND_PULSE;
if (dev->s_tx_mask)
@@ -403,7 +395,7 @@ static int ir_lirc_register(struct rc_dev *dev)
drv->minor = -1;
drv->features = features;
drv->data = >raw->lirc;
-   drv->rbuf = rbuf;
+   drv->rbuf = NULL;
drv->set_use_inc = _lirc_open;
drv->set_use_dec = _lirc_close;
drv->code_length = sizeof(struct ir_raw_event) * 8;
@@ -415,19 +407,15 @@ static int ir_lirc_register(struct rc_dev *dev)
drv->minor = lirc_register_driver(drv);
if (drv->minor < 0) {
rc = -ENODEV;
-   goto lirc_register_failed;
+   goto out;
}
 
dev->raw->lirc.drv = drv;
dev->raw->lirc.dev = dev;
return 0;
 
-lirc_register_failed:
-rbuf_init_failed:
-   kfree(rbuf);
-rbuf_alloc_failed:
+out:
kfree(drv);
-
return rc;
 }
 
@@ -436,9 +424,8 @@ static int ir_lirc_unregister(struct rc_dev *dev)
struct lirc_codec *lirc = >raw->lirc;
 
lirc_unregister_driver(lirc->drv->minor);
-   lirc_buffer_free(lirc->drv->rbuf);
-   kfree(lirc->drv->rbuf);
kfree(lirc->drv);
+   lirc->drv = NULL;
 
return 0;
 }

[PATCH] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl (alternative approach)

[David Härdeman]

It is currently impossible to distinguish between scancodes which have
been generated using different protocols (and scancodes can, and will,
overlap).

For example:
RC5 message to address 0x00, command 0x03 has scancode 0x0503
JVC message to address 0x00, command 0x03 has scancode 0x0503

It is only possible to distinguish (and parse) scancodes by knowing the
scancode *and* the protocol.

Setting and getting keycodes in the input subsystem used to be done via
the EVIOC[GS]KEYCODE ioctl and "unsigned int[2]" (one int for scancode
and one for the keycode).

The interface has now been extended to use the EVIOC[GS]KEYCODE_V2 ioctl
which uses the following struct:

struct input_keymap_entry {
__u8  flags;
__u8  len;
__u16 index;
__u32 keycode;
__u8  scancode[32];
};

(scancode can of course be even bigger, thanks to the len member).

This patch changes how the "input_keymap_entry" struct is interpreted
by rc-core by casting it to "rc_keymap_entry":

struct rc_scancode {
__u16 protocol;
__u16 reserved[3];
__u64 scancode;
}

struct rc_keymap_entry {
__u8  flags;
__u8  len;
__u16 index;
__u32 keycode;
union {
struct rc_scancode rc;
__u8 raw[32];
};
};

The u64 scancode member is large enough for all current protocols and it
would be possible to extend it in the future should it be necessary for
some exotic protocol.

The main advantage with this change is that the protocol is made explicit,
which means that we're not throwing away data (the protocol type).

This also means that struct rc_map no longer hardcodes the protocol, meaning
that keytables with mixed entries are possible.

Heuristics are also added to hopefully do the right thing with older
ioctls in order to preserve backwards compatibility.

This is an alternative approach to the other one that I posted here:
http://www.spinics.net/lists/linux-media/msg114898.html

It replaces patches 4-6 of that patchset.

The difference is that RC_TYPE_UNKNOWN is repurposed to serve as a marker
for ioctl() requests and keytable entries which lack protocol information.

ioctl():s which lack a protocol will match on any matching scancode,
regardless of protocol. Keytable entries of type RC_TYPE_UNKNOWN
will match on any protocol.

Note that these heuristics are also not 100% guaranteed to get things
right. For example, consider the following sequence of events:

EVIOCSKEYCODE_V2:  = KEY_NUMERIC_1
EVIOCSKEYCODE_V2:  = KEY_NUMERIC_2
EVIOCGKEYCODE: <0x01fe> = ?
EVIOCSKEYCODE: <0x01fe> = KEY_RESERVED
EVIOCGKEYCODE_V2:  = ?
EVIOCGKEYCODE_V2:  = ?

However, mixing and matching ioctl() types is a pretty pathological
case.

Also, that is somewhat mitigated by the fact that the "only"
userspace binary which might need to change is ir-keytable. Userspace
programs which simply consume input events (i.e. the vast majority)
won't have to change.

I haven't tested the patch yet, consider it a basis for discussion.

Signed-off-by: David Härdeman 
---
 drivers/media/rc/ati_remote.c |1 
 drivers/media/rc/imon.c   |7 +
 drivers/media/rc/rc-main.c|  219 -
 include/media/rc-core.h   |   26 -
 include/media/rc-map.h|5 +
 5 files changed, 202 insertions(+), 56 deletions(-)

diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 9cf3e69de16a..cc81b938471f 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -546,6 +546,7 @@ static void ati_remote_input_report(struct urb *urb)
 * set, assume this is a scrollwheel up/down event.
 */
wheel_keycode = rc_g_keycode_from_table(ati_remote->rdev,
+   RC_TYPE_OTHER,
scancode & 0x78);
 
if (wheel_keycode == KEY_RESERVED) {
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 3489010601b5..c724a1a5e9cd 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1274,14 +1274,15 @@ static u32 imon_remote_key_lookup(struct imon_context 
*ictx, u32 scancode)
bool is_release_code = false;
 
/* Look for the initial press of a button */
-   keycode = rc_g_keycode_from_table(ictx->rdev, scancode);
+   keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type, scancode);
ictx->rc_toggle = 0x0;
ictx->rc_scancode = scancode;
 
/* Look for the release of a button */
if (keycode == KEY_RESERVED) {
release = scancode & ~0x4000;
-   keycode = rc_g_keycode_from_table(ictx->rdev, release);
+   keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type,
+  

Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl

[David Härdeman]

On Fri, Apr 28, 2017 at 08:31:33AM -0300, Mauro Carvalho Chehab wrote:
>Em Thu, 27 Apr 2017 22:34:23 +0200
>David Härdeman  escreveu:
...
>> This patch changes how the "input_keymap_entry" struct is interpreted
>> by rc-core by casting it to "rc_keymap_entry":
>> 
>> struct rc_scancode {
>>  __u16 protocol;
>>  __u16 reserved[3];
>>  __u64 scancode;
>> }
>> 
>> struct rc_keymap_entry {
>>  __u8  flags;
>>  __u8  len;
>>  __u16 index;
>>  __u32 keycode;
>>  union {
>>  struct rc_scancode rc;
>>  __u8 raw[32];
>>  };
>> };
>> 
...
>
>Nack.

That's not a very constructive approach. If you have a better approach
in mind I'm all ears. Because you're surely not suggesting that we stay
with the current protocol-less approach forever?

>No userspace breakages are allowed.

That's a gross oversimplification. A cursory glance at the linux-api
mailing list shows plenty of examples of changes that might not be 100%
backwards-compatible. Here's an example:
http://marc.info/?l=linux-fsdevel=149089166918069

That's the kind of discussion we need to have - i.e. the best way to go
about this and to minimize the damage to userspace. In that vein, I'll
post an alternative approach shortly as the basis for further
discussion.

>There's no way to warrant that
>ir-keytable version is compatible with a certain Kernel version.

I know. But we know when an ioctl() is made whether it is a
protocol-aware one or not.

-- 
David Härdeman

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

[Logan Gunthorpe]

On 28/04/17 12:30 AM, Herbert Xu wrote:
> You are right.  Indeed the existing code looks buggy as they
> don't take sg->offset into account when doing the kmap.  Could
> you send me some patches that fix these problems first so that
> they can be easily backported?

Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
both do have the sg->offset accounted for. I'll send a patch for the
buggy one shortly.

Logan

Re: em28xx module: misidentified card

[Frank Schäfer]

Am 28.04.2017 um 13:22 schrieb Giuseppe Toscano:
> I am trying to use eMPIA Technology, Inc. GrabBeeX+ Video Encoder
> (card=21) but the em28xx driver erroneously identifies it as
> EM2860/SAA711X Reference Design (card = 19).
> Attached the output of lsusb and dmesg.
>
Card 21 is an em2800 device, while your device uses an em2710/em2820
(see log).
Card 19 should work. Did you test it ?

Regards,
Frank


> Best regards,
>
> Giuseppe Toscano

Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl

[David Härdeman]

On Fri, Apr 28, 2017 at 12:40:53PM +0100, Sean Young wrote:
>On Thu, Apr 27, 2017 at 10:34:23PM +0200, David Härdeman wrote:
...
>> This patch changes how the "input_keymap_entry" struct is interpreted
>> by rc-core by casting it to "rc_keymap_entry":
>> 
>> struct rc_scancode {
>>  __u16 protocol;
>>  __u16 reserved[3];
>>  __u64 scancode;
>> }
>> 
>> struct rc_keymap_entry {
>>  __u8  flags;
>>  __u8  len;
>>  __u16 index;
>>  __u32 keycode;
>>  union {
>>  struct rc_scancode rc;
>>  __u8 raw[32];
>>  };
>> };
>> 
>> The u64 scancode member is large enough for all current protocols and it
>> would be possible to extend it in the future should it be necessary for
>> some exotic protocol.
>> 
>> The main advantage with this change is that the protocol is made explicit,
>> which means that we're not throwing away data (the protocol type).
>> 
>> This also means that struct rc_map no longer hardcodes the protocol, meaning
>> that keytables with mixed entries are possible.
>> 
>> Heuristics are also added to hopefully do the right thing with older
>> ioctls in order to preserve backwards compatibility.
>
>The current ioctls do not provide any protocol information, so they should
>continue to match any protocol. Those heuristics aren't good enough.
>
>Another way of doing is to have a bitmask of protocols, and default to
>RC_BIT_ALL for current ioctls.

I've been mulling that approach as well, but slightly different. My
alternative approach is based on repurposing RC_TYPE_UNKNOWN as a kind
of catch-all which will match any scancode. I'll post a patch showing
the alternative approach straight away.

>> Note that the heuristics are not 100% guaranteed to get things right.
>> That is unavoidable since the protocol information simply isn't there
>> when userspace calls the previous ioctl() types.
>> 
>> However, that is somewhat mitigated by the fact that the "only"
>> userspace binary which might need to change is ir-keytable. Userspace
>> programs which simply consume input events (i.e. the vast majority)
>> won't have to change.
>
>For this to be accepted we would need ir-keytable changes too so it can
>be tested.

I know. But I'll postpone those patches until we have more of a
consensus on the right approach to take.

-- 
David Härdeman

Re: [PATCH 5/6] rc-core: use the full 32 bits for NEC scancodes

[David Härdeman]

On Fri, Apr 28, 2017 at 12:58:32PM +0100, Sean Young wrote:
>On Thu, Apr 27, 2017 at 10:34:18PM +0200, David Härdeman wrote:
>> Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
>> and the nec decoder without any loss of functionality. At the same time
>> it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and
>> removes lots of duplication (as you can see from the patch, the same NEC
>> disambiguation logic is contained in several different drivers).
>> 
>> Using NEC32 also removes ambiguity. For example, consider these two NEC
>> messages:
>> NEC16 message to address 0x05, command 0x03
>> NEC24 message to address 0x0005, command 0x03
>> 
>> They'll both have scancode 0x0503, and there's no way to tell which
>> message was received.
>
>It's not ambiguous, the protocol is different (RC_TYPE_NEC vs RC_TYPE_NECX).

It's ambigous in any context where the protocol is not known (e.g. when
old-style ioctl():s are performed) or in contexts where protocols are
bundled (i.e. when the only information about protocols come from the
sysfs file).

Anyway, I'm very open to leaving NEC well alone if that means we can
make some progress on the more important issue of protocol-enabled
keytables. :)

>> In order to maintain backwards compatibility, some heuristics are added
>> in rc-main.c to convert scancodes to NEC32 as necessary when userspace
>> adds entries to the keytable using the regular input ioctls. These
>> heuristics are essentially the same as the ones that are currently in
>> drivers/media/rc/img-ir/img-ir-nec.c (which are rendered unecessary
>> with this patch).
>
>There are issues with the patch which breaks userspace, as discussed
>in the previous patch. None of those issues have been addressed.

It is impossible to add protocol information without affecting
userspace, what we should be focusing on is the best way to ameliorate
the effects.

As a simple example, consider new-style ioctls doing:

EVIOCSKEYCODE_V2 (SONY, 0x001f) = KEY_NUMERIC_2
EVIOCSKEYCODE_V2 (SANYO, 0x001f) = KEY_NUMERIC_1

After that, what should these two ioctl():s perform/return?:

EVIOCGKEYCODE (0x001f) -> ?
EVIOCSKEYCODE (0x001f) = KEY_*

-- 
David Härdeman

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Tony Lindgren]

* Tomi Valkeinen  [170428 04:15]:
> On 14/04/17 13:25, Hans Verkuil wrote:
> > From: Hans Verkuil 
> > 
> > The CEC pin was always pulled up, making it impossible to use it.
> > 
> > Change to PIN_INPUT so it can be used by the new CEC support.
...

> Reviewed-by: Tomi Valkeinen 
> 
> Tony, can you queue this? It's safe to apply separately from the rest of
> the HDMI CEC work.

Sure will do.

Thanks,

Tony

[PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing

[Hugues Fruchet]

Stateless video decoders require explicit codec specific metadata
derived from video bitstream parsing.
This plugin aims to silently convert the user provided video bitstream
to a parsed video bitstream, ie the video bitstream itself + additional
parsing metadata which are given to the driver through the V4L2 extended
control framework.
This plugin can support several codec dependent parser backends, enabling
of the right parser is done by intercepting the pixel format information
negotiated between user and driver (enum_fmt/try_fmt/get_fmt/s_fmt).
This patchset provides a MPEG-2 parser backend using GStreamer
codecparsers library.
It has been tested with STMicroelectronics st-delta kernel driver.

===
= history =
===
version 2:
  - rebase linux headers based on st-delta mpeg2 v6 patchset:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html

version 1:
  - initial submission


Hugues Fruchet (3):
  v4l-utils: sync with kernel (parsed MPEG-2 support)
  add libv4l-codecparsers plugin for video bitstream parsing
  libv4l-codecparsers: add GStreamer mpeg2 parser

 configure.ac  |  23 ++
 include/linux/v4l2-controls.h |  93 +
 include/linux/videodev2.h |   8 +
 lib/Makefile.am   |   3 +-
 lib/libv4l-codecparsers/Makefile.am   |  21 +
 lib/libv4l-codecparsers/libv4l-codecparsers.pc.in |  12 +
 lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c   | 375 +
 lib/libv4l-codecparsers/libv4l-cparsers.c | 465 ++
 lib/libv4l-codecparsers/libv4l-cparsers.h | 101 +
 9 files changed, 1100 insertions(+), 1 deletion(-)
 create mode 100644 lib/libv4l-codecparsers/Makefile.am
 create mode 100644 lib/libv4l-codecparsers/libv4l-codecparsers.pc.in
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers.c
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers.h

-- 
1.9.1

[PATCH v2 3/3] libv4l-codecparsers: add GStreamer mpeg2 parser

[Hugues Fruchet]

Add the mpeg2 codecparser backend glue which will
call the GStreamer parsing functions.

Signed-off-by: Hugues Fruchet 
---
 configure.ac|  21 ++
 lib/libv4l-codecparsers/Makefile.am |  14 +-
 lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c | 375 
 lib/libv4l-codecparsers/libv4l-cparsers.c   |   4 +
 4 files changed, 413 insertions(+), 1 deletion(-)
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c

diff --git a/configure.ac b/configure.ac
index 9ce7392..ce43f18 100644
--- a/configure.ac
+++ b/configure.ac
@@ -273,6 +273,25 @@ fi
 
 AC_SUBST([JPEG_LIBS])
 
+# Check for GStreamer codecparsers
+
+gst_codecparsers_pkgconfig=false
+PKG_CHECK_MODULES([GST], [gstreamer-1.0 >= 1.8.0], [gst_pkgconfig=true], 
[gst_pkgconfig=false])
+if test "x$gst_pkgconfig" = "xfalse"; then
+   AC_MSG_WARN(GStreamer library is not available)
+else
+   PKG_CHECK_MODULES([GST_BASE], [gstreamer-base-1.0 >= 1.8.0], 
[gst_base_pkgconfig=true], [gst_base_pkgconfig=false])
+   if test "x$gst_base_pkgconfig" = "xfalse"; then
+  AC_MSG_WARN(GStreamer base library is not available)
+   else
+  PKG_CHECK_MODULES(GST_CODEC_PARSERS, [gstreamer-codecparsers-1.0 >= 
1.8.0], [gst_codecparsers_pkgconfig=true], [gst_codecparsers_pkgconfig=false])
+  if test "x$gst_codecparsers_pkgconfig" = "xfalse"; then
+ AC_MSG_WARN(GStreamer codecparser library is not available)
+  fi
+   fi
+fi
+AM_CONDITIONAL([HAVE_GST_CODEC_PARSERS], [test x$gst_codecparsers_pkgconfig = 
xtrue])
+
 # Check for pthread
 
 AS_IF([test x$enable_shared != xno],
@@ -477,6 +496,7 @@ AM_COND_IF([WITH_V4L2_CTL_LIBV4L], [USE_V4L2_CTL="yes"], 
[USE_V4L2_CTL="no"])
 AM_COND_IF([WITH_V4L2_CTL_STREAM_TO], [USE_V4L2_CTL="yes"], 
[USE_V4L2_CTL="no"])
 AM_COND_IF([WITH_V4L2_COMPLIANCE_LIBV4L], [USE_V4L2_COMPLIANCE="yes"], 
[USE_V4L2_COMPLIANCE="no"])
 AS_IF([test "x$alsa_pkgconfig" = "xtrue"], [USE_ALSA="yes"], [USE_ALSA="no"])
+AS_IF([test "x$gst_codecparsers_pkgconfig" = "xtrue"], 
[USE_GST_CODECPARSERS="yes"], [USE_GST_CODECPARSERS="no"])
 
 AC_OUTPUT
 
@@ -497,6 +517,7 @@ compile time options summary
 pthread : $have_pthread
 QT version  : $QT_VERSION
 ALSA support: $USE_ALSA
+GST codecparsers: $USE_GST_CODECPARSERS
 
 build dynamic libs  : $enable_shared
 build static libs   : $enable_static
diff --git a/lib/libv4l-codecparsers/Makefile.am 
b/lib/libv4l-codecparsers/Makefile.am
index a9d6c8b..61f4730 100644
--- a/lib/libv4l-codecparsers/Makefile.am
+++ b/lib/libv4l-codecparsers/Makefile.am
@@ -1,9 +1,21 @@
 if WITH_V4L_PLUGINS
+if HAVE_GST_CODEC_PARSERS
+
 libv4l2plugin_LTLIBRARIES = libv4l-codecparsers.la
-endif
 
 libv4l_codecparsers_la_SOURCES = libv4l-cparsers.c libv4l-cparsers.h
 
 libv4l_codecparsers_la_CPPFLAGS = $(CFLAG_VISIBILITY) 
-I$(top_srcdir)/lib/libv4l2/ -I$(top_srcdir)/lib/libv4lconvert/
 libv4l_codecparsers_la_LDFLAGS = -avoid-version -module -shared 
-export-dynamic -lpthread
 libv4l_codecparsers_la_LIBADD = ../libv4l2/libv4l2.la
+
+# GStreamer codecparsers library
+libv4l_codecparsers_la_CFLAGS = $(GST_CFLAGS) -DGST_USE_UNSTABLE_API
+libv4l_codecparsers_la_LDFLAGS += $(GST_LIB_LDFLAGS)
+libv4l_codecparsers_la_LIBADD += $(GLIB_LIBS) $(GST_LIBS) $(GST_BASE_LIBS) 
$(GST_CODEC_PARSERS_LIBS) $(NULL)
+
+# MPEG-2 parser back-end
+libv4l_codecparsers_la_SOURCES += libv4l-cparsers-mpeg2.c
+
+endif
+endif
diff --git a/lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c 
b/lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c
new file mode 100644
index 000..3456b73
--- /dev/null
+++ b/lib/libv4l-codecparsers/libv4l-cparsers-mpeg2.c
@@ -0,0 +1,375 @@
+/*
+ * libv4l-cparsers-mpeg2.c
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Hugues Fruchet 
+ *  Tifaine Inguere 
+ *  for STMicroelectronics.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA  02110-1335  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "libv4l2.h"
+#include "libv4l2-priv.h"
+#include "libv4l-cparsers.h"
+
+#include 
+#include 
+
+/*
+ * parsing metadata ids and their associated control ids.
+ * keep in sync both enum and array, this is used to index 

[PATCH v2 1/3] v4l-utils: sync with kernel (parsed MPEG-2 support)

[Hugues Fruchet]

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on OUTPUT queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

Change-Id: I60755685ccb41942574654f64632d1348b689033
Signed-off-by: Hugues Fruchet 
---
 include/linux/v4l2-controls.h | 93 +++
 include/linux/videodev2.h |  8 
 2 files changed, 101 insertions(+)

diff --git a/include/linux/v4l2-controls.h b/include/linux/v4l2-controls.h
index 0d2e1e0..d8ad718 100644
--- a/include/linux/v4l2-controls.h
+++ b/include/linux/v4l2-controls.h
@@ -547,6 +547,99 @@ enum v4l2_mpeg_video_mpeg4_profile {
 };
 #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPEG_BASE+407)
 
+/*
+ * parsed MPEG-2 controls
+ * (needed by stateless video decoders)
+ * Those controls have been defined based on MPEG-2 standard ISO/IEC 13818-2,
+ * and so derive directly from the MPEG-2 video bitstream syntax including
+ * how it is coded inside bitstream (enumeration values for ex.).
+ */
+#define MPEG2_QUANTISER_MATRIX_SIZE64
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR  (V4L2_CID_MPEG_BASE+450)
+struct v4l2_mpeg_video_mpeg2_seq_hdr {
+   __u16   width;
+   __u16   height;
+   __u8aspect_ratio_info;
+   __u8frame_rate_code;
+   __u16   vbv_buffer_size;
+   __u32   bitrate_value;
+   __u16   constrained_parameters_flag;
+   __u8load_intra_quantiser_matrix;
+   __u8load_non_intra_quantiser_matrix;
+   __u8intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+   __u8non_intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+   __u32   par_w;
+   __u32   par_h;
+   __u32   fps_n;
+   __u32   fps_d;
+   __u32   bitrate;
+};
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT  (V4L2_CID_MPEG_BASE+451)
+struct v4l2_mpeg_video_mpeg2_seq_ext {
+   __u8profile;
+   __u8level;
+   __u8progressive;
+   __u8chroma_format;
+   __u8horiz_size_ext;
+   __u8vert_size_ext;
+   __u16   bitrate_ext;
+   __u8vbv_buffer_size_ext;
+   __u8low_delay;
+   __u8fps_n_ext;
+   __u8fps_d_ext;
+};
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_DISPLAY_EXT  (V4L2_CID_MPEG_BASE+452)
+struct v4l2_mpeg_video_mpeg2_seq_display_ext {
+   __u16   display_horizontal_size;
+   __u16   display_vertical_size;
+   __u8video_format;
+   __u8colour_description_flag;
+   __u8colour_primaries;
+   __u8transfer_characteristics;
+   __u8matrix_coefficients;
+};
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_MATRIX_EXT   (V4L2_CID_MPEG_BASE+453)
+struct v4l2_mpeg_video_mpeg2_seq_matrix_ext {
+   __u8load_intra_quantiser_matrix;
+   __u8intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+   __u8load_non_intra_quantiser_matrix;
+   __u8non_intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+   __u8load_chroma_intra_quantiser_matrix;
+   __u8chroma_intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+   __u8load_chroma_non_intra_quantiser_matrix;
+   __u8chroma_non_intra_quantiser_matrix[MPEG2_QUANTISER_MATRIX_SIZE];
+};
+#define V4L2_CID_MPEG_VIDEO_MPEG2_PIC_HDR  (V4L2_CID_MPEG_BASE+454)
+struct v4l2_mpeg_video_mpeg2_pic_hdr {
+   __u32   offset;
+   __u16   tsn;
+   __u16   vbv_delay;
+   __u8pic_type;
+   __u8full_pel_forward_vector;
+   __u8full_pel_backward_vector;
+   __u8f_code[2][2];
+};
+#define V4L2_CID_MPEG_VIDEO_MPEG2_PIC_EXT  (V4L2_CID_MPEG_BASE+455)
+struct v4l2_mpeg_video_mpeg2_pic_ext {
+   __u8f_code[2][2];
+   __u8intra_dc_precision;
+   __u8picture_structure;
+   __u8top_field_first;
+   __u8frame_pred_frame_dct;
+   __u8concealment_motion_vectors;
+   __u8q_scale_type;
+   __u8intra_vlc_format;
+   __u8alternate_scan;
+   __u8repeat_first_field;
+   __u8chroma_420_type;
+   __u8progressive_frame;
+   __u8composite_display;
+   __u8v_axis;
+   __u8field_sequence;
+   __u8sub_carrier;
+   __u8burst_amplitude;
+   __u8sub_carrier_phase;
+};
 /*  Control IDs for VP8 streams
  *  Although VP8 is not part of MPEG we add these controls to the MPEG class
  *  as that class is already handling other video compression standards
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index b1e36ee..ec4344c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -618,7 +618,9 @@ struct v4l2_pix_format {
 #define 

[PATCH v2 2/3] add libv4l-codecparsers plugin for video bitstream parsing

[Hugues Fruchet]

Stateless video decoders require explicit codec specific
metadata derived from video bitstream parsing.
This plugin aims to silently convert the user provided video
bitstream to a parsed video bitstream, ie the video bitstream itself
+ additional parsing metadata which are given to the driver through the
V4L2 extended control framework.
This plugin supports several codec dependent parser backends.
Enabling of the right parser is done by intercepting the pixel format
information negotiated between user and driver (enum_fmt/try_fmt/get_fmt/s_fmt).

Signed-off-by: Hugues Fruchet 
---
 configure.ac  |   2 +
 lib/Makefile.am   |   3 +-
 lib/libv4l-codecparsers/Makefile.am   |   9 +
 lib/libv4l-codecparsers/libv4l-codecparsers.pc.in |  12 +
 lib/libv4l-codecparsers/libv4l-cparsers.c | 461 ++
 lib/libv4l-codecparsers/libv4l-cparsers.h | 101 +
 6 files changed, 587 insertions(+), 1 deletion(-)
 create mode 100644 lib/libv4l-codecparsers/Makefile.am
 create mode 100644 lib/libv4l-codecparsers/libv4l-codecparsers.pc.in
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers.c
 create mode 100644 lib/libv4l-codecparsers/libv4l-cparsers.h

diff --git a/configure.ac b/configure.ac
index dd29eda..9ce7392 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+   lib/libv4l-codecparsers/Makefile
 
utils/Makefile
utils/libv4l2util/Makefile
@@ -56,6 +57,7 @@ AC_CONFIG_FILES([Makefile
lib/libv4lconvert/libv4lconvert.pc
lib/libv4l1/libv4l1.pc
lib/libv4l2/libv4l2.pc
+   lib/libv4l-codecparsers/libv4l-codecparsers.pc
lib/libdvbv5/libdvbv5.pc
lib/libv4l2rds/libv4l2rds.pc
utils/media-ctl/libmediactl.pc
diff --git a/lib/Makefile.am b/lib/Makefile.am
index a105c95..3aa8564 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -3,7 +3,8 @@ SUBDIRS = \
libv4l2 \
libv4l1 \
libv4l2rds \
-   libv4l-mplane
+   libv4l-mplane \
+   libv4l-codecparsers
 
 if WITH_LIBDVBV5
 SUBDIRS += \
diff --git a/lib/libv4l-codecparsers/Makefile.am 
b/lib/libv4l-codecparsers/Makefile.am
new file mode 100644
index 000..a9d6c8b
--- /dev/null
+++ b/lib/libv4l-codecparsers/Makefile.am
@@ -0,0 +1,9 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-codecparsers.la
+endif
+
+libv4l_codecparsers_la_SOURCES = libv4l-cparsers.c libv4l-cparsers.h
+
+libv4l_codecparsers_la_CPPFLAGS = $(CFLAG_VISIBILITY) 
-I$(top_srcdir)/lib/libv4l2/ -I$(top_srcdir)/lib/libv4lconvert/
+libv4l_codecparsers_la_LDFLAGS = -avoid-version -module -shared 
-export-dynamic -lpthread
+libv4l_codecparsers_la_LIBADD = ../libv4l2/libv4l2.la
diff --git a/lib/libv4l-codecparsers/libv4l-codecparsers.pc.in 
b/lib/libv4l-codecparsers/libv4l-codecparsers.pc.in
new file mode 100644
index 000..ea367ee
--- /dev/null
+++ b/lib/libv4l-codecparsers/libv4l-codecparsers.pc.in
@@ -0,0 +1,12 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+includedir=@includedir@
+libdir=@libdir@
+
+Name: libv4l-codecparsers
+Description: v4l2 library to parse video bitstream, needed by stateless video 
decoders
+Version: @PACKAGE_VERSION@
+Requires.private: libv4l-gst
+Libs: -L${libdir} -lv4l2
+Libs.private: -lpthread
+Cflags: -I${includedir}
diff --git a/lib/libv4l-codecparsers/libv4l-cparsers.c 
b/lib/libv4l-codecparsers/libv4l-cparsers.c
new file mode 100644
index 000..af59f50
--- /dev/null
+++ b/lib/libv4l-codecparsers/libv4l-cparsers.c
@@ -0,0 +1,461 @@
+/*
+ * libv4l-cparsers.c
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Hugues Fruchet 
+ *  Tifaine Inguere 
+ *  for STMicroelectronics.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA  02110-1335  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libv4l2.h"
+#include "libv4l2-priv.h"
+#include "libv4l-plugin.h"
+#include "libv4lsyscall-priv.h"
+
+#include "libv4l-cparsers.h"
+
+#if HAVE_VISIBILITY
+#define PLUGIN_PUBLIC 

[PATCH 2/2] [media] platform: add video-multiplexer subdevice driver

[Philipp Zabel]

This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
This has been last sent as part of the i.MX media series.

Changes since https://patchwork.kernel.org/patch/9647869/:
 - Split out the actual mux operation to be provided by the mux controller
   framework [1]. GPIO and MMIO control can be provided by individual mux
   controller drivers [2][3].
   [1] https://patchwork.kernel.org/patch/9695837/
   [2] https://patchwork.kernel.org/patch/9695839/
   [3] https://patchwork.kernel.org/patch/9704509/
 - Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
   vidsw with video_mux.
 - Made the mux inactive by default, only activated by user interaction.
 - Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
 - Reuse subdev.entity.num_pads instead of keeping our own count.
 - Removed implicit link disabling. Instead, trying to enable a second
   sink pad link yields -EBUSY.
 - Merged _async_init into _probe.
 - Removed superfluous pad index check from _set_format.
 - Added is_source_pad helper to tell source and sink pads apart.
 - Removed test for status property in endpoint nodes. Disable the remote
   device or sever the endpoint link to disable a sink pad.
---
 drivers/media/platform/Kconfig |   6 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/video-mux.c | 341 +
 3 files changed, 349 insertions(+)
 create mode 100644 drivers/media/platform/video-mux.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e105baba..b046a6d39fee5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
  To compile this driver as a module, choose M here: the
  module will be called arv.
 
+config VIDEO_MUX
+   tristate "Video Multiplexer"
+   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
MULTIPLEXER
+   help
+ This driver provides support for N:1 video bus multiplexers.
+
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6a69da2..fd2735ca3ff75 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)+= sh_veu.o
 
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
+obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
+
 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
new file mode 100644
index 0..419541729f67e
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,341 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer 
+ * Copyright (C) 2016 Pengutronix, Philipp Zabel 
+ *
+ * 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.
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct video_mux {
+   struct v4l2_subdev subdev;
+   struct media_pad *pads;
+   struct v4l2_mbus_framefmt *format_mbus;
+   struct v4l2_of_endpoint *endpoint;
+   struct mux_control *mux;
+   int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev 
*sd)
+{
+   return container_of(sd, struct video_mux, subdev);
+}
+
+static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
+{
+   return pad == vmux->subdev.entity.num_pads - 1;
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+   const struct media_pad *local,
+   const struct media_pad *remote, u32 flags)
+{
+   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+   

[PATCH 1/2] [media] dt-bindings: Add bindings for video-multiplexer device

[Philipp Zabel]

Add bindings documentation for the video multiplexer device.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
This has been last sent as part of Steve's i.MX media series. Since the binding
changed, I've dropped Rob's ack.

Changes since https://patchwork.kernel.org/patch/9647951/:
 - Replaced re, bit-mask/shift, and gpios properties with a single mux-controls
   property, leaving the actual operation of the mux to a separate mux
   controller, as described by Peter's mux-controller bindings:
   https://patchwork.kernel.org/patch/9695835/
 - Shortened 'video-multiplexer' compatible to 'video-mux', aligning with the
   other mux bindings.
 - Added a comment about the optional ports node and a link to the OF graph
   bindings document.
---
 .../devicetree/bindings/media/video-mux.txt| 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt

diff --git a/Documentation/devicetree/bindings/media/video-mux.txt 
b/Documentation/devicetree/bindings/media/video-mux.txt
new file mode 100644
index 0..63b9dc913e456
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-mux.txt
@@ -0,0 +1,60 @@
+Video Multiplexer
+=
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding are controlled by a multiplexer controller that is described by
+the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
+
+Required properties:
+- compatible : should be "video-mux"
+- mux-controls : mux controller node to use for operating the mux
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+  source and sink devices according to of_graph bindings. The last port is
+  the output port, all others are inputs.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   video-mux {
+   compatible = "video-mux";
+   mux-controls = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mux_in0: endpoint {
+   remote-endpoint = <_source0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mux_in1: endpoint {
+   remote-endpoint = <_source1_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   mux_out: endpoint {
+   remote-endpoint = <_interface_in>;
+   };
+   };
+   };
+};
-- 
2.11.0

[GIT PULL FOR v4.12] Various fixes/regressions for 4.12.

[Hans Verkuil]

The following changes since commit 9eb9db3a0f92b75ec710066202e0b2accb45afa9:

  [media] atmel-isc: Fix the static checker warning (2017-04-19 09:02:47 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.12h

for you to fetch changes up to 82fd29fb6372a9d15c39e2bcf87768cb52aa9cba:

  vb2: Fix an off by one error in 'vb2_plane_vaddr' (2017-04-28 11:42:54 +0200)


Arnd Bergmann (3):
  rainshadow-cec: use strlcat instead of strncat
  rainshadow-cec: avoid -Wmaybe-uninitialized warning
  cec: improve MEDIA_CEC_RC dependencies

Christophe JAILLET (1):
  vb2: Fix an off by one error in 'vb2_plane_vaddr'

Petr Cvek (1):
  pxa_camera: fix module remove codepath for v4l2 clock

Wei Yongjun (2):
  rainshadow-cec: Fix missing spin_lock_init()
  s5p-cec: remove unused including 

 drivers/media/cec/Kconfig |  1 +
 drivers/media/platform/pxa_camera.c   | 14 +-
 drivers/media/platform/s5p-cec/s5p_cec.h  |  1 -
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c |  6 --
 drivers/media/v4l2-core/videobuf2-core.c  |  2 +-
 5 files changed, 19 insertions(+), 5 deletions(-)

[PATCH] staging/atomisp: fix && vs || typos

[Dan Carpenter]

These sanity checks don't work because they use && instead of ||.  It's
impossible to be both negative and greater than 5.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c 
b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
index a322539d2621..4b1fa9c7bb81 100644
--- a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
+++ b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
@@ -67,7 +67,7 @@ int vlv2_plat_set_clock_freq(int clk_num, int freq_type)
 {
void __iomem *addr;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num > MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -103,7 +103,7 @@ int vlv2_plat_get_clock_freq(int clk_num)
 {
u32 ret;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num > MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -133,7 +133,7 @@ int vlv2_plat_configure_clock(int clk_num, u32 conf)
 {
void __iomem *addr;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num > MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -169,7 +169,7 @@ int vlv2_plat_get_clock_status(int clk_num)
 {
int ret;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num > MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}

[PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues Fruchet]

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on output queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

Signed-off-by: Hugues Fruchet 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 363 +
 Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
 Documentation/media/uapi/v4l/vidioc-queryctrl.rst  |  38 ++-
 Documentation/media/videodev2.h.rst.exceptions |   6 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/uapi/linux/v4l2-controls.h |  94 ++
 include/uapi/linux/videodev2.h |   8 +
 8 files changed, 572 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..b48eac9 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type -
 not insert, 1 = insert packets.
 
 
+MPEG-2 Parsed Control Reference
+-
+
+The MPEG-2 parsed decoding controls are needed by stateless video decoders.
+Those decoders expose :ref:`Compressed formats ` 
:ref:`V4L2_PIX_FMT_MPEG1_PARSED` or 
:ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
+In order to decode the video bitstream chunk provided by user on output queue,
+stateless decoders require also some extra data resulting from this video
+bitstream chunk parsing. Those parsed extra data have to be set by user
+through control framework using the mpeg video extended controls defined
+in this section. Those controls have been defined based on MPEG-2 standard
+ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax
+including how it is coded inside bitstream (enumeration values for ex.).
+
+MPEG-2 Parsed Control IDs
+^^^
+
+.. _mpeg2-parsed-control-id:
+
+.. c:type:: V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u16
+  - ``width``
+  - Video width in pixels.
+* - __u16
+  - ``height``
+  - Video height in pixels.
+* - __u8
+  - ``aspect_ratio_info``
+  - Aspect ratio code as in the bitstream (1: 1:1 square pixels,
+2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display)
+* - __u8
+  - ``framerate code``
+  - Framerate code as in the bitstream
+(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0,
+4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0,
+8: 60.0)
+* - __u16
+  - ``vbv_buffer_size``
+  -  Video Buffering Verifier size, expressed in 16KBytes unit.
+* - __u32
+  - ``bitrate_value``
+  - Bitrate value as in the bitstream, expressed in 400bps unit
+* - __u16
+  - ``constrained_parameters_flag``
+  - Set to 1 if this bitstream uses constrained parameters.
+* - __u8
+  - ``load_intra_quantiser_matrix``
+  - If set to 1, ``intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``load_non_intra_quantiser_matrix``
+  - If set to 1, ``non_intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``intra_quantiser_matrix[64]``
+  - Intra quantization table, in zig-zag scan order.
+* - __u8
+  - ``non_intra_quantiser_matrix[64]``
+  - Non-intra quantization table, in zig-zag scan order.
+* - __u32
+  - ``par_w``
+  - Pixel aspect ratio width in pixels.
+* - __u32
+  - ``par_h``
+  - Pixel aspect ratio height in pixels.
+* - __u32
+  - ``fps_n``
+  - Framerate nominator.
+* - __u32
+  - ``fps_d``
+  - Framerate denominator.
+* - __u32
+  - ``bitrate``
+  - Bitrate in bps if constant bitrate, 0 otherwise.
+* - :cspan:`2`
+
+
+.. c:type:: V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_ext
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_ext
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``profile``
+  - Encoding profile used to encode this bitstream.
+(1: High Profile, 2: Spatially Scalable Profile,
+3: SNR Scalable Profile, 4: Main Profile, 5: Simple Profile).
+* - __u8
+  

[PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder

[Hugues Fruchet]

The patchset implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0] needed by stateless video decoders, ie decoders which requires
specific parsing metadata in addition to video bitstream chunk in order
to complete decoding.
A reference implementation using STMicroelectronics DELTA video decoder
is provided as initial support in this patchset.
In addition to this patchset, a libv4l plugin is also provided which convert
MPEG-2 video bitstream to "parsed MPEG-2" by parsing the user video bitstream
and filling accordingly the dedicated controls, doing so user code remains
unchanged whatever decoder is: stateless or not.

The first patch implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0]. A dedicated "parsed MPEG-2" pixel format has been introduced with
its related extended controls in order that user provides both video bitstream
chunk and the associated extra data resulting from this video bitstream chunk
parsing.

The second patch adds the support of "parsed" pixel format inside DELTA video
decoder including handling of the dedicated controls and setting of parsing
metadata required by decoder layer.
Please note that the current implementation has a restriction regarding
the atomicity of S_EXT_CTRL/QBUF that must be guaranteed by user.
This restriction will be removed when V4L2 request API will be implemented [1].
Please also note the failure in v4l2-compliance in controls section, related
to complex compound controls handling, to be discussed to find the right way
to fix it in v4l2-compliance.

The third patch adds the support of DELTA MPEG-2 stateless video decoder 
back-end.


This driver depends on:
  [PATCH v7 00/10] Add support for DELTA video decoder of STMicroelectronics 
STiH4xx SoC series https://patchwork.linuxtv.org/patch/39186/

References:
  [0] [RFC] V4L2 unified low-level decoder API 
https://www.spinics.net/lists/linux-media/msg107150.html
  [1] [ANN] Report of the V4L2 Request API brainstorm meeting 
https://www.spinics.net/lists/linux-media/msg106699.html

===
= history =
===
version 6:
  - patchset 5 review from Hans:
- revisit 32/64 bit compat in mpeg2 controls struct (using pahole utility)
  to avoid padding fields introduction
  - pass latest v4l2-compliance with compound controls fixes
- fix delta_subscribe_event() adding missing control event
  - fix warnings at documentation generation (add exceptions)

version 5:
  - patchset 4 review from Hans:
- fix 32/64 bit compat in mpeg2 controls struct (using pahole utility)
- fix upper case at begining of words in v4l2_ctrl_get_name()

version 4:
  - patchset 3 review from Nicolas Dufresne
- one attribute per line in structure
  - fix some multilines comments

version 3:
  - fix warning on parisc architecture

version 2:
  - rebase on top of DELTA v7, refer to [0]
  - change VIDEO_STI_DELTA_DRIVER to default=y as per Mauro recommendations

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report, v4l2-compliance has been build from SHA1:
847bf8d62cd6b11defc1e4c3b30b68d3c66876e0 v4l2/cec-compliance, cec-follower: use 
git -C $(srcdir) rev-parse HEAD

root@sti:~# v4l2-compliance -d /dev/video3
v4l2-compliance SHA   : 847bf8d62cd6b11defc1e4c3b30b68d3c66876e0

Driver Info:
Driver name   : st-delta
Card type : st-delta-21.1-3
Bus info  : platform:soc:delta0
Driver version: 4.10.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test 

[PATCH v6 2/3] [media] st-delta: add parsing metadata controls support

[Hugues Fruchet]

Install all metadata controls required by registered decoders.
Update the decoding context with the set of metadata received
from user through extended control.
Set the received metadata in access unit prior to call the
decoder decoding ops.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-v4l2.c | 127 +-
 drivers/media/platform/sti/delta/delta.h  |  34 +++
 2 files changed, 160 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
b/drivers/media/platform/sti/delta/delta-v4l2.c
index c6f2e24..228fe85 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -339,6 +339,30 @@ static void register_decoders(struct delta_dev *delta)
}
 }
 
+static void register_ctrls(struct delta_dev *delta)
+{
+   const struct delta_dec *dec;
+   unsigned int i, j;
+   u32 meta_cid;
+
+   /* decoders optional meta controls */
+   for (i = 0; i < delta->nb_of_decoders; i++) {
+   dec = delta->decoders[i];
+   if (!dec->meta_cids)
+   continue;
+
+   for (j = 0; j < dec->nb_of_metas; j++) {
+   meta_cid = dec->meta_cids[j];
+   if (!meta_cid)
+   continue;
+
+   delta->cids[delta->nb_of_ctrls++] = meta_cid;
+   }
+   }
+
+   /* add here additional controls if needed */
+}
+
 static void delta_lock(void *priv)
 {
struct delta_ctx *ctx = priv;
@@ -355,6 +379,79 @@ static void delta_unlock(void *priv)
mutex_unlock(>lock);
 }
 
+static int delta_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct delta_ctx *ctx =
+   container_of(ctrl->handler, struct delta_ctx, ctrl_handler);
+   struct delta_dev *delta = ctx->dev;
+
+   if (ctx->nb_of_metas >= DELTA_MAX_METAS) {
+   dev_err(delta->dev, "%s not enough room to set meta control\n",
+   ctx->name);
+   return -EINVAL;
+   }
+
+   dev_dbg(delta->dev, "%s set metas[%d] from control id=%d (%s)\n",
+   ctx->name, ctx->nb_of_metas, ctrl->id, ctrl->name);
+
+   ctx->metas[ctx->nb_of_metas].cid = ctrl->id;
+   ctx->metas[ctx->nb_of_metas].p = ctrl->p_new.p;
+   ctx->nb_of_metas++;
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops delta_ctrl_ops = {
+   .s_ctrl = delta_s_ctrl,
+};
+
+static int delta_ctrls_setup(struct delta_ctx *ctx)
+{
+   struct delta_dev *delta = ctx->dev;
+   struct v4l2_ctrl_handler *hdl = >ctrl_handler;
+   unsigned int i;
+
+   v4l2_ctrl_handler_init(hdl, delta->nb_of_ctrls);
+
+   for (i = 0; i < delta->nb_of_ctrls; i++) {
+   struct v4l2_ctrl *ctrl;
+   u32 cid = delta->cids[i];
+   struct v4l2_ctrl_config cfg;
+
+   /* override static config to set delta_ctrl_ops */
+   memset(, 0, sizeof(cfg));
+   cfg.id = cid;
+   cfg.ops = _ctrl_ops;
+
+   ctrl = v4l2_ctrl_new_custom(hdl, , NULL);
+   if (hdl->error) {
+   int err = hdl->error;
+
+   dev_err(delta->dev, "%s failed to setup control '%s' 
(id=%d, size=%d, err=%d)\n",
+   ctx->name, cfg.name, cfg.id,
+   cfg.elem_size, err);
+   v4l2_ctrl_handler_free(hdl);
+   return err;
+   }
+
+   /* force unconditional execution of s_ctrl() by
+* disabling control value evaluation in case of
+* meta control (passed by pointer)
+*/
+   if (ctrl->is_ptr)
+   ctrl->flags |= V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
+   }
+
+   v4l2_ctrl_handler_setup(hdl);
+   ctx->fh.ctrl_handler = hdl;
+
+   ctx->nb_of_metas = 0;
+   memset(ctx->metas, 0, sizeof(ctx->metas));
+
+   dev_dbg(delta->dev, "%s controls setup done\n", ctx->name);
+   return 0;
+}
+
 static int delta_open_decoder(struct delta_ctx *ctx, u32 streamformat,
  u32 pixelformat, const struct delta_dec **pdec)
 {
@@ -896,6 +993,8 @@ static int delta_subscribe_event(struct v4l2_fh *fh,
 const struct v4l2_event_subscription *sub)
 {
switch (sub->type) {
+   case V4L2_EVENT_CTRL:
+   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
default:
@@ -964,6 +1063,12 @@ static void delta_run_work(struct work_struct *work)
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = vbuf->vb2_buf.timestamp;
 
+   /* set access unit meta data in case of decoder requires it */
+   memcpy(au->metas, ctx->metas, ctx->nb_of_metas * 

[PATCH v6 3/3] [media] st-delta: add mpeg2 support

[Hugues Fruchet]

Adds support of DELTA MPEG-2 video decoder back-end,
implemented by calling MPEG2_TRANSFORMER0 firmware
using RPMSG IPC communication layer.
MPEG-2 decoder back-end is a stateless decoder which
require specific parsing metadata in access unit
in order to complete decoding.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig |   11 +-
 drivers/media/platform/sti/delta/Makefile  |3 +
 drivers/media/platform/sti/delta/delta-cfg.h   |5 +
 drivers/media/platform/sti/delta/delta-mpeg2-dec.c | 1401 
 drivers/media/platform/sti/delta/delta-mpeg2-fw.h  |  423 ++
 drivers/media/platform/sti/delta/delta-v4l2.c  |4 +
 6 files changed, 1845 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-fw.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..1571462 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -355,15 +355,22 @@ config VIDEO_STI_DELTA_MJPEG
To compile this driver as a module, choose M here:
the module will be called st-delta.
 
+config VIDEO_STI_DELTA_MPEG2
+   bool "STMicroelectronics DELTA MPEG2/MPEG1 support"
+   default y
+   help
+   Enables DELTA MPEG2 hardware support.
+
 config VIDEO_STI_DELTA_DRIVER
tristate
depends on VIDEO_STI_DELTA
-   depends on VIDEO_STI_DELTA_MJPEG
-   default VIDEO_STI_DELTA_MJPEG
+   depends on VIDEO_STI_DELTA_MJPEG || VIDEO_STI_DELTA_MPEG2
+   default y
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select RPMSG
 
+
 endif # VIDEO_STI_DELTA
 
 config VIDEO_SH_VEU
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index 8d032508..b18ed37 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -4,3 +4,6 @@ st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
 # MJPEG support
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
+
+# MPEG2 support
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MPEG2) += delta-mpeg2-dec.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
index c6388f5..bce2c74 100644
--- a/drivers/media/platform/sti/delta/delta-cfg.h
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -61,4 +61,9 @@
 extern const struct delta_dec mjpegdec;
 #endif
 
+#ifdef CONFIG_VIDEO_STI_DELTA_MPEG2
+extern const struct delta_dec mpeg2dec;
+extern const struct delta_dec mpeg1dec;
+#endif
+
 #endif /* DELTA_CFG_H */
diff --git a/drivers/media/platform/sti/delta/delta-mpeg2-dec.c 
b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
new file mode 100644
index 000..adb0300
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
@@ -0,0 +1,1401 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Chetan Nanda 
+ *  Jean-Christophe Trotin 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mem.h"
+#include "delta-mpeg2-fw.h"
+
+#define DELTA_MPEG2_MAX_RESO DELTA_MAX_RESO
+
+/* minimal number of frames for decoding = 1 dec + 2 refs frames */
+#define DELTA_MPEG2_DPB_FRAMES_NEEDED 3
+
+struct delta_mpeg2_ctx {
+   /* ipc */
+   void *ipc_hdl;
+   struct delta_buf *ipc_buf;
+
+   /* stream information */
+   struct delta_streaminfo streaminfo;
+
+   bool header_parsed;
+
+   /* reference frames mgt */
+   struct delta_mpeg2_frame *prev_ref;
+   struct delta_mpeg2_frame *next_ref;
+
+   /* output frames reordering management */
+   struct delta_frame *out_frame;
+   struct delta_frame *delayed_frame;
+
+   /* interlaced frame management */
+   struct delta_frame *last_frame;
+   enum mpeg2_picture_structure_t accumulated_picture_structure;
+
+   unsigned char str[3000];
+};
+
+/* codec specific frame struct */
+struct delta_mpeg2_frame {
+   struct delta_frame frame;
+   u32 tref;   /* temporal reference */
+   struct delta_buf omega_buf; /* 420mb buffer for decoding */
+};
+
+#define to_ctx(ctx) ((struct delta_mpeg2_ctx *)(ctx)->priv)
+#define to_mpeg2_frame(frame) ((struct delta_mpeg2_frame *)frame)
+#define to_frame(mpeg2_frame) ((struct delta_frame *)mpeg2_frame)
+
+/* default intra, zig-zag order */
+static u8 default_intra_matrix[] = {
+   8,
+   16, 16,
+   19, 16, 19,
+   22, 22, 22, 22,
+   22, 22, 26, 24, 26,
+   27, 27, 27, 26, 26, 26,
+   26, 27, 27, 27, 

Re: [PATCH 2/2] media: entity: Add media_entity_pad_from_dt_regs() function

[Sakari Ailus]

Hej, Niklas!

On Fri, Apr 28, 2017 at 02:04:15PM +0200, Niklas Söderlund wrote:
> Hej,
> 
> Thanks for your feedback.
> 
> On 2017-04-28 13:43:39 +0300, Sakari Ailus wrote:
> > Hejssan!!!
> > 
> > On Fri, Apr 28, 2017 at 12:33:23AM +0200, Niklas Söderlund wrote:
> > > This is a wrapper around the media entity pad_from_dt_regs operation.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  drivers/media/media-entity.c | 21 +
> > >  include/media/media-entity.h | 22 ++
> > >  2 files changed, 43 insertions(+)
> > > 
> > > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > > index 5640ca29da8c9bbc..6ef76186d552724e 100644
> > > --- a/drivers/media/media-entity.c
> > > +++ b/drivers/media/media-entity.c
> > > @@ -386,6 +386,27 @@ struct media_entity *media_graph_walk_next(struct 
> > > media_graph *graph)
> > >  }
> > >  EXPORT_SYMBOL_GPL(media_graph_walk_next);
> > >  
> > > +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> > > +   int port_reg, int reg, unsigned int *pad)
> > > +{
> > > + int ret;
> > > +
> > > + if (!entity->ops || !entity->ops->pad_from_dt_regs) {
> > > + *pad = port_reg;
> > 
> > I don't think we should bind the port number in firmware to a pad in V4L2
> > sub-device interface.
> > 
> > How about looking for a source pad in the entity instead? That's what some
> > drivers do.
> 
> Sure that sounds like a nice approach, will do this for next version.
> 
> Would it make sens to extend this operation with a 'direction' parameter 
> which could take either MEDIA_PAD_FL_SOURCE or MEDIA_PAD_FL_SINK and if 
> !entity->ops->pad_from_dt_regs find the first pad that matches this 
> 'direction' and if it do exist add a check to make sure the pad that is 
> return matches that 'direction'?

If you had a transmitter in the graph it'd obviously be needed. I'm not sure
if we have any now. I'm fine with direction though, it's logical to have it.

> 
> > 
> > > + return 0;
> > > + }
> > > +
> > > + ret = entity->ops->pad_from_dt_regs(port_reg, reg, pad);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (*pad >= entity->num_pads)
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(media_entity_pad_from_dt_regs);
> > > +
> > >  /* 
> > > -
> > >   * Pipeline management
> > >   */
> > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > > index 47efaf4d825e671b..c60a3713d0a21baf 100644
> > > --- a/include/media/media-entity.h
> > > +++ b/include/media/media-entity.h
> > > @@ -820,6 +820,28 @@ struct media_pad *media_entity_remote_pad(struct 
> > > media_pad *pad);
> > >  struct media_entity *media_entity_get(struct media_entity *entity);
> > >  
> > >  /**
> > > + * media_entity_pad_from_dt_regs - Get pad number from DT regs
> > > + *
> > > + * @entity: The entity
> > > + * @port_reg: DT port
> > > + * @reg: DT reg
> > > + * @pad: Pointer to pad which will be filled in
> > > + *
> > > + * This function can be used to resolve the media pad number from
> > > + * DT port and reg numbers. This is useful for devices which
> > > + * uses more complex mappings of media pads then that the
> > > + * DT port number is equivalent to the media pad number.
> > > + *
> > > + * If the entity do not implement the pad_from_dt_regs() operation
> > > + * this function assumes DT port is equivalent to media pad number
> > > + * and sets @pad to @port_reg.
> > > + *
> > > + * Return: 0 on success else -EINVAL.
> > 
> > -EINVAL suggests the user provided bad parameters, but this isn't the case
> > here. How about e.g. -ENXIO?
> 
> 
> I reasoned that if a port_reg and reg supplied did result in a  pad 
> match the user would have given pad parameters. But sure there might be 
> cases where that assumtion might not be true. So I see no problem of 
> changing this to -ENXIO in next version.

The only case -EINVAL is returned is when the driver specific function
returns a non-existent pad number. That's a driver bug, isn't it? We don't
have a specific error code for that though. :-)

> 
> > 
> > > + */
> > > +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> > > +   int port_reg, int reg, unsigned int *pad);
> > > +
> > > +/**
> > >   * media_graph_walk_init - Allocate resources used by graph walk.
> > >   *
> > >   * @graph: Media graph structure that will be used to walk the graph
> > 

-- 
Terveisin,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 1/2] media: entity: Add pad_from_dt_regs entity operation

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 01:57:52PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.
> 
> On 2017-04-28 13:32:57 +0300, Sakari Ailus wrote:
> > Hi Niklas,
> > 
> > On Fri, Apr 28, 2017 at 12:33:22AM +0200, Niklas Söderlund wrote:
> > > The optional operation can be used by entities to report how it maps its
> > > DT node ports and endpoints to media pad numbers. This is useful for
> > > devices which require more advanced mappings of pads then DT port
> > > number is equivalent with media port number.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  include/media/media-entity.h | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > > index c7c254c5bca1761b..47efaf4d825e671b 100644
> > > --- a/include/media/media-entity.h
> > > +++ b/include/media/media-entity.h
> > > @@ -171,6 +171,9 @@ struct media_pad {
> > >  
> > >  /**
> > >   * struct media_entity_operations - Media entity operations
> > > + * @pad_from_dt_regs:Return the pad number based on DT port and reg
> > > + *   properties. This operation can be used to map a
> > > + *   DT port and reg to a media pad number. Optional.
> > 
> > Don't you need to provide entity as an argument as well? The driver will be
> > a little bit loss due to lack of context. :-)
> 
> I'm not sure I understand you, this is a entity operation so the driver 
> will know for which entity the request is mad on. Or am I missing 
> something?

I actually came to think about the same thing after replying, but then
remembered something else: some drivers support multiple devices with
different capabilities. There could be a reason to know which piece of
hardware this is about.

Although that can always be added later on if needed. Up to you.

> 
> > 
> > How about using the endpoint's device node (or fwnode; you can get it using
> > of_fwnode_handle() soon) instead? You can always obtain the port node by
> > just getting the parent.
> 
> I did think about that but opted for port_reg and reg since it seemed 
> more simple.
> 
> But it might be better to base this work on top of your fwnode work,
> s/from_dt_regs/from_fwnode/ and use the of_fwnode_handle() as you 
> suggest here. Do you think this would be valuable and make this new 
> operation more useful?

The benefit is that it would also work on ACPI based systems, i.e. it is no
longer DT specific. I'd say it's a benefit. :-)

Yeah, I understand that you'd just use integers in the driver and then make
the decision based on them? Makes sense. How about the wrapper function,
should it take an fwnode handle pointer instead? The caller of that function
likely has an fwnode pointer to start with, found through iterating over the
endpoints.

> 
> > 
> > >   * @link_setup:  Notify the entity of link changes. The 
> > > operation can
> > >   *   return an error, in which case link setup will 
> > > be
> > >   *   cancelled. Optional.
> > > @@ -184,6 +187,7 @@ struct media_pad {
> > >   *mutex held.
> > >   */
> > >  struct media_entity_operations {
> > > + int (*pad_from_dt_regs)(int port_reg, int reg, unsigned int *pad);
> > >   int (*link_setup)(struct media_entity *entity,
> > > const struct media_pad *local,
> > > const struct media_pad *remote, u32 flags);
> > 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[PATCH 1/2] [media] dib0700: fix locking in dib0700_i2c_xfer_new()

[Dan Carpenter]

This patch mostly adds unlocks to error paths.  But one additional small
change is that I made the first "break;" a "goto unlock;" which means
that now we return failure instead of success on that path.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 08acdd32e412..4dea79718827 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -215,13 +215,14 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
 USB_CTRL_GET_TIMEOUT);
if (result < 0) {
deb_info("i2c read error (status = %d)\n", 
result);
-   break;
+   goto unlock;
}
 
if (msg[i].len > sizeof(st->buf)) {
deb_info("buffer too small to fit %d bytes\n",
 msg[i].len);
-   return -EIO;
+   result = -EIO;
+   goto unlock;
}
 
memcpy(msg[i].buf, st->buf, msg[i].len);
@@ -233,8 +234,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(>usb_mutex) < 0) {
err("could not acquire lock");
-   mutex_unlock(>i2c_mutex);
-   return -EINTR;
+   result = -EINTR;
+   goto unlock;
}
st->buf[0] = REQUEST_NEW_I2C_WRITE;
st->buf[1] = msg[i].addr << 1;
@@ -247,7 +248,9 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
if (msg[i].len > sizeof(st->buf) - 4) {
deb_info("i2c message to big: %d\n",
 msg[i].len);
-   return -EIO;
+   mutex_unlock(>usb_mutex);
+   result = -EIO;
+   goto unlock;
}
 
/* The Actual i2c payload */
@@ -269,8 +272,11 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
}
}
}
+   result = i;
+
+unlock:
mutex_unlock(>i2c_mutex);
-   return i;
+   return result;
 }
 
 /*

[PATCH 2/2] [media] dib0700: fix error handling in dib0700_i2c_xfer_legacy()

[Dan Carpenter]

Mostly this adds some unlocks to error paths.  But, if you see where
there were "break;" statements before, I changed those paths to return
error codes instead of returning success.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 4dea79718827..bea1b4764a66 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -287,7 +287,7 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
 {
struct dvb_usb_device *d = i2c_get_adapdata(adap);
struct dib0700_state *st = d->priv;
-   int i,len;
+   int i, len, result;
 
if (mutex_lock_interruptible(>i2c_mutex) < 0)
return -EINTR;
@@ -304,7 +304,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
if (msg[i].len > sizeof(st->buf) - 2) {
deb_info("i2c xfer to big: %d\n",
msg[i].len);
-   return -EIO;
+   result = -EIO;
+   goto unlock;
}
memcpy(>buf[2], msg[i].buf, msg[i].len);
 
@@ -319,13 +320,15 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter 
*adap,
if (len <= 0) {
deb_info("I2C read failed on address 0x%02x\n",
msg[i].addr);
-   break;
+   result = -EIO;
+   goto unlock;
}
 
if (msg[i + 1].len > sizeof(st->buf)) {
deb_info("i2c xfer buffer to small for %d\n",
msg[i].len);
-   return -EIO;
+   result = -EIO;
+   goto unlock;
}
memcpy(msg[i + 1].buf, st->buf, msg[i + 1].len);
 
@@ -334,14 +337,17 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter 
*adap,
i++;
} else {
st->buf[0] = REQUEST_I2C_WRITE;
-   if (dib0700_ctrl_wr(d, st->buf, msg[i].len + 2) < 0)
-   break;
+   result = dib0700_ctrl_wr(d, st->buf, msg[i].len + 2);
+   if (result < 0)
+   goto unlock;
}
}
+   result = i;
+unlock:
mutex_unlock(>usb_mutex);
mutex_unlock(>i2c_mutex);
 
-   return i;
+   return result;
 }
 
 static int dib0700_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,

From: Mr.David Owain

[Mr. David Owain]

Good Day,

Please accept my apologies for writing you a surprise letter.I am
Mr.David Owain, account Manager with an investment bank here in
Burkina Faso.I have a very important business I want to discuss with
you.There is a draft account opened in my firm by a long-time client
of our bank.I have the opportunity of transferring the left over fund
(15.8 Million UsDollars)Fiftheen Million Eight Hundred Thousand United
States of American Dollars of one of my Bank clients who died at the
collapsing of the world trade center at the United States on September
11th 2001.

I want to invest this funds and introduce you to our bank for this
deal.All I require is your honest co-operation and I guarantee you
that this will be executed under a legitimate arrangement that will
protect us from any breach of the law.I agree that 40% of this money
will be for you as my foreign partner,50% for me while 10% is for
establishing of foundation for the less privilleges in your country.If
you are really interested in my proposal further details of the
Transfer will be forwarded unto you as soon as I receive your
willingness mail for a successful transfer.

Yours Sincerely,
Mr.David Owain.

[PATCH 6/8] staging: atomisp: satm include directory is gone

[Alan Cox]

From: Arnd Bergmann 

After the satm kernel was removed, we should no longer add the directory
to the search path. This was found with a 'make W=1' warning:

cc1: error: 
drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/satm/: No such 
file or directory [-Werror=missing-include-dirs]

Fixes: 184f8e0981ef ("atomisp: remove satm kernel")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Alan Cox 
---
 .../staging/media/atomisp/pci/atomisp2/Makefile|1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 7417dbd..3fa7c1c 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -290,7 +290,6 @@ INCLUDES += \
-I$(atomisp)/css2400/isp/kernels/s3a/ \
-I$(atomisp)/css2400/isp/kernels/s3a/s3a_1.0/ \
-I$(atomisp)/css2400/isp/kernels/s3a_stat_ls/ \
-   -I$(atomisp)/css2400/isp/kernels/satm/ \
-I$(atomisp)/css2400/isp/kernels/scale/ \
-I$(atomisp)/css2400/isp/kernels/scale/scale_1.0/ \
-I$(atomisp)/css2400/isp/kernels/sc/ \

[PATCH 5/8] atomisp: remove some more unused files

[Alan Cox]

The extra list contains some which are used and some which are not. At this
point I think we can safely remove those that are simply not used.

Signed-off-by: Alan Cox 
---
 .../staging/media/atomisp/pci/atomisp2/Makefile|   11 -
 .../media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c|  333 
 .../media/atomisp/pci/atomisp2/hrt/device_access.c |  116 ---
 .../media/atomisp/pci/atomisp2/hrt/memory_access.c |  103 --
 4 files changed, 563 deletions(-)
 delete mode 100644 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
 delete mode 100644 
drivers/staging/media/atomisp/pci/atomisp2/hrt/device_access.c
 delete mode 100644 
drivers/staging/media/atomisp/pci/atomisp2/hrt/memory_access.c

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 96a7bd0..7417dbd 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -157,17 +157,6 @@ atomisp-objs += \
hrt/hive_isp_css_mm_hrt.o \
atomisp_v4l2.o

-extra= \
-   hrt/hive_isp_css_mm_hrt.o \
-   hrt/memory_access.o \
-   hrt/device_access.o \
-   hmm/hmm_dynamic_pool.o \
-   hmm/hmm_vm.o \
-   hmm/hmm_reserved_pool.o \
-   hmm/hmm_bo_dev.o \
-   hmm/hmm.o \
-   hmm/hmm_bo.o
-
 # These will be needed when clean merge CHT support nicely into the driver
 # Keep them here handy for when we get to that point
 #
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
deleted file mode 100644
index d22a2d2..000
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo_dev.c
+++ /dev/null
@@ -1,333 +0,0 @@
-/*
- * Support for Medifield PNW Camera Imaging ISP subsystem.
- *
- * Copyright (c) 2010 Intel Corporation. All Rights Reserved.
- *
- * Copyright (c) 2010 Silicon Hive www.siliconhive.com.
- *
- * 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.
- *
- * 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., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- *
- */
-#include 
-#include 
-#include 
-#include   /* for GFP_ATOMIC */
-#include /* for kmalloc */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_ION
-#include 
-#endif
-
-#include "atomisp_internal.h"
-#include "hmm/hmm_common.h"
-#include "hmm/hmm_bo_dev.h"
-#include "hmm/hmm_bo.h"
-
-/*
- * hmm_bo_device functions.
- */
-int hmm_bo_device_init(struct hmm_bo_device *bdev,
-  struct isp_mmu_client *mmu_driver,
-  unsigned int vaddr_start, unsigned int size)
-{
-   int ret;
-
-   check_bodev_null_return(bdev, -EINVAL);
-
-   ret = isp_mmu_init(>mmu, mmu_driver);
-   if (ret) {
-   dev_err(atomisp_dev, "isp_mmu_init failed.\n");
-   goto isp_mmu_init_err;
-   }
-
-   ret = hmm_vm_init(>vaddr_space, vaddr_start, size);
-   if (ret) {
-   dev_err(atomisp_dev, "hmm_vm_init failed. vaddr_start = 0x%x, 
size = %d\n",
-   vaddr_start, size);
-   goto vm_init_err;
-   }
-
-   INIT_LIST_HEAD(>free_bo_list);
-   INIT_LIST_HEAD(>active_bo_list);
-
-   spin_lock_init(>list_lock);
-#ifdef CONFIG_ION
-   /*
-* TODO:
-* The ion_dev should be defined by ION driver. But ION driver does
-* not implement it yet, will fix it when it is ready.
-*/
-   if (!ion_dev)
-   goto vm_init_err;
-
-   bdev->iclient = ion_client_create(ion_dev, "atomisp");
-   if (IS_ERR_OR_NULL(bdev->iclient)) {
-   ret = PTR_ERR(bdev->iclient);
-   if (!bdev->iclient)
-   ret = -EINVAL;
-   goto vm_init_err;
-   }
-#endif
-   bdev->flag = HMM_BO_DEVICE_INITED;
-
-   return 0;
-
-vm_init_err:
-   isp_mmu_exit(>mmu);
-isp_mmu_init_err:
-   return ret;
-}
-
-void hmm_bo_device_exit(struct hmm_bo_device *bdev)
-{
-   check_bodev_null_return_void(bdev);
-
-   /*
-* destroy all bos in the bo list, even they are in use.
-*/
-   if (!list_empty(>active_bo_list))
-   dev_warn(atomisp_dev,
-"there're still activated bo in use. "
-"force to free them.\n");
-
-   while (!list_empty(>active_bo_list))
-  

[PATCH 8/8] staging: media: atomisp: kmap() can't fail

[Alan Cox]

From: Fabian Frederick 

There's no need to check kmap() return value because it won't fail.
If it's highmem mapping, it will receive virtual address
or a new one; if it's lowmem, all kernel pages are already being mapped.

(Thanks to Jan Kara for explanations)

Signed-off-by: Fabian Frederick 
Signed-off-by: Alan Cox 
---
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |   19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 3588723..5729539 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -333,15 +333,7 @@ static int load_and_flush_by_kmap(ia_css_ptr virt, void 
*data, unsigned int byte
idx = (virt - bo->start) >> PAGE_SHIFT;
offset = (virt - bo->start) - (idx << PAGE_SHIFT);
 
-   src = (char *)kmap(bo->page_obj[idx].page);
-   if (!src) {
-   dev_err(atomisp_dev,
-   "kmap buffer object page failed: "
-   "pg_idx = %d\n", idx);
-   return -EINVAL;
-   }
-
-   src += offset;
+   src = (char *)kmap(bo->page_obj[idx].page) + offset;
 
if ((bytes + offset) >= PAGE_SIZE) {
len = PAGE_SIZE - offset;
@@ -538,14 +530,7 @@ int hmm_set(ia_css_ptr virt, int c, unsigned int bytes)
idx = (virt - bo->start) >> PAGE_SHIFT;
offset = (virt - bo->start) - (idx << PAGE_SHIFT);
 
-   des = (char *)kmap(bo->page_obj[idx].page);
-   if (!des) {
-   dev_err(atomisp_dev,
-   "kmap buffer object page failed: "
-   "pg_idx = %d\n", idx);
-   return -EINVAL;
-   }
-   des += offset;
+   des = (char *)kmap(bo->page_obj[idx].page) + offset;
 
if ((bytes + offset) >= PAGE_SIZE) {
len = PAGE_SIZE - offset;

[PATCH 7/8] staging: atomisp: remove #ifdef for runtime PM functions

[Alan Cox]

From: Arnd Bergmann 

The runtime power management functions are called from the reset handler even
if CONFIG_PM is disabled, leading to a link error:

drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd1c): undefined reference to `atomisp_runtime_suspend'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd3a): undefined reference to `atomisp_mrfld_power_down'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd58): undefined reference to `atomisp_mrfld_power_up'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd77): undefined reference to `atomisp_runtime_resume'

Removing the #ifdef around the PM functions avoids the problem, and
lets us simplify it further. The __maybe_unused annotation is needed
to ensure the compiler can silently drop the unused callbacks.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Alan Cox 
---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |   14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 35414c9..e3fdbdb 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -310,7 +310,6 @@ static int __maybe_unused atomisp_restore_iunit_reg(struct 
atomisp_device *isp)
return 0;
 }
 
-#ifdef CONFIG_PM
 static int atomisp_mrfld_pre_power_down(struct atomisp_device *isp)
 {
struct pci_dev *dev = isp->pdev;
@@ -550,7 +549,7 @@ int atomisp_runtime_resume(struct device *dev)
return 0;
 }
 
-static int atomisp_suspend(struct device *dev)
+static int __maybe_unused atomisp_suspend(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -588,7 +587,7 @@ static int atomisp_suspend(struct device *dev)
return atomisp_mrfld_power_down(isp);
 }
 
-static int atomisp_resume(struct device *dev)
+static int __maybe_unused atomisp_resume(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -614,7 +613,6 @@ static int atomisp_resume(struct device *dev)
atomisp_freq_scaling(isp, ATOMISP_DFS_MODE_LOW, true);
return 0;
 }
-#endif
 
 int atomisp_csi_lane_config(struct atomisp_device *isp)
 {
@@ -1576,7 +1574,6 @@ static const struct pci_device_id atomisp_pci_tbl[] = {
 
 MODULE_DEVICE_TABLE(pci, atomisp_pci_tbl);
 
-#ifdef CONFIG_PM
 static const struct dev_pm_ops atomisp_pm_ops = {
.runtime_suspend = atomisp_runtime_suspend,
.runtime_resume = atomisp_runtime_resume,
@@ -1584,14 +1581,9 @@ static const struct dev_pm_ops atomisp_pm_ops = {
.resume = atomisp_resume,
 };
 
-#define DEV_PM_OPS (_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif
-
 static struct pci_driver atomisp_pci_driver = {
.driver = {
-   .pm = DEV_PM_OPS,
+   .pm = _pm_ops,
},
.name = "atomisp-isp2",
.id_table = atomisp_pci_tbl,

[PATCH 4/8] atomisp: remove hmm_load/store/clear indirections

[Alan Cox]

We have a layer of un-needed wrapping here that can go. In addition there are
some functions that don't exist and one that isn't used which can also go.

Signed-off-by: Alan Cox 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |4 +--
 .../media/atomisp/pci/atomisp2/atomisp_fops.c  |4 +--
 .../pci/atomisp2/css2400/ia_css_memory_access.c|   15 ++-
 .../atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c |   27 
 .../atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.h |   20 ---
 .../media/atomisp/pci/atomisp2/hrt/memory_access.c |6 ++--
 6 files changed, 15 insertions(+), 61 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index a8614a9..97093ba 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -2922,7 +2922,7 @@ int atomisp_get_metadata(struct atomisp_sub_device *asd, 
int flag,
   md_buf->md_vptr,
   stream_info->metadata_info.size);
} else {
-   hrt_isp_css_mm_load(md_buf->metadata->address,
+   hmm_load(md_buf->metadata->address,
asd->params.metadata_user[md_type],
stream_info->metadata_info.size);
 
@@ -3005,7 +3005,7 @@ int atomisp_get_metadata_by_type(struct 
atomisp_sub_device *asd, int flag,
   md_buf->md_vptr,
   stream_info->metadata_info.size);
} else {
-   hrt_isp_css_mm_load(md_buf->metadata->address,
+   hmm_load(md_buf->metadata->address,
asd->params.metadata_user[md_type],
stream_info->metadata_info.size);
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
index e5a7407..7ce8803 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
@@ -1144,11 +1144,11 @@ static int remove_pad_from_frame(struct atomisp_device 
*isp,
 
load += ISP_LEFT_PAD;
for (i = 0; i < height; i++) {
-   ret = hrt_isp_css_mm_load(load, buffer, width*sizeof(load));
+   ret = hmm_load(load, buffer, width*sizeof(load));
if (ret < 0)
goto remove_pad_error;
 
-   ret = hrt_isp_css_mm_store(store, buffer, width*sizeof(store));
+   ret = hmm_store(store, buffer, width*sizeof(store));
if (ret < 0)
goto remove_pad_error;
 
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
index f8fc14c..2820759 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
@@ -52,22 +52,23 @@ mmgr_calloc(const size_t N, const size_t size)
return mmgr_alloc_attr(size * N, MMGR_ATTRIBUTE_CLEARED);
 }
 
-void
-mmgr_clear(hrt_vaddress vaddr, const size_t size)
+void mmgr_clear(hrt_vaddress vaddr, const size_t size)
 {
-   hrt_isp_css_mm_set(vaddr, 0, size);
+   if (vaddr)
+   hmm_set(vaddr, 0, size);
 }
 
-void
-mmgr_load(const hrt_vaddress vaddr, void *data, const size_t size)
+void mmgr_load(const hrt_vaddress vaddr, void *data, const size_t size)
 {
-   hrt_isp_css_mm_load(vaddr, data, size);
+   if (vaddr && data)
+   hmm_load(vaddr, data, size);
 }
 
 void
 mmgr_store(const hrt_vaddress vaddr, const void *data, const size_t size)
 {
-   hrt_isp_css_mm_store(vaddr, data, size);
+   if (vaddr && data)
+   hmm_store(vaddr, data, size);
 }
 
 hrt_vaddress
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
index 63904bc..7dff22f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
@@ -28,28 +28,6 @@
 
 #define __page_align(size) (((size) + (PAGE_SIZE-1)) & (~(PAGE_SIZE-1)))
 
-int hrt_isp_css_mm_set(ia_css_ptr virt_addr, int c, size_t bytes)
-{
-   if (virt_addr)
-   return hmm_set(virt_addr, c, bytes);
-
-   return -EFAULT;
-}
-
-int hrt_isp_css_mm_load(ia_css_ptr virt_addr, void *data, size_t bytes)
-{
-   if (virt_addr && data)
-   return hmm_load(virt_addr, data, bytes);
-   return -EFAULT;
-}
-
-int hrt_isp_css_mm_store(ia_css_ptr virt_addr, const void *data, size_t bytes)
-{
-   if (virt_addr && data)
-   return 

[PATCH 2/8] atomisp: clean up the hmm init/cleanup indirections

[Alan Cox]

We don't need any of these indirections as we only support one MMU type. Start
by getting rid of the init/clear/free ones. The init ordering check we already
pushed down in a previous patch.

The allocation side is more complicated so leave it for now.

Signed-off-by: Alan Cox 
---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |6 ++---
 .../pci/atomisp2/css2400/ia_css_memory_access.c|2 +-
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |4 ++-
 .../atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c |   26 
 .../atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.h |5 
 .../media/atomisp/pci/atomisp2/hrt/memory_access.c |4 ++-
 6 files changed, 8 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 9bd186b..35414c9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1454,7 +1454,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
}
 
/* Init ISP memory management */
-   hrt_isp_css_mm_init();
+   hmm_init();
 
err = devm_request_threaded_irq(>dev, dev->irq,
atomisp_isr, atomisp_isr_thread,
@@ -1486,7 +1486,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
 css_init_fail:
devm_free_irq(>dev, dev->irq, isp);
 request_irq_fail:
-   hrt_isp_css_mm_clear();
+   hmm_cleanup();
hmm_pool_unregister(HMM_POOL_TYPE_RESERVED);
 hmm_pool_fail:
destroy_workqueue(isp->wdt_work_queue);
@@ -1538,7 +1538,7 @@ static void atomisp_pci_remove(struct pci_dev *dev)
atomisp_acc_cleanup(isp);
 
atomisp_css_unload_firmware(isp);
-   hrt_isp_css_mm_clear();
+   hmm_cleanup();
 
pm_runtime_forbid(>dev);
pm_runtime_get_noresume(>dev);
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
index 1f6ae20..5b2bdfd 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_memory_access.c
@@ -55,7 +55,7 @@ mmgr_calloc(const size_t N, const size_t size)
 void
 mmgr_free(hrt_vaddress vaddr)
 {
-   hrt_isp_css_mm_free(vaddr);
+   hmm_free(vaddr);
 }
 
 void
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 14537ab..3588723 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -272,6 +272,8 @@ void hmm_free(ia_css_ptr virt)
 {
struct hmm_buffer_object *bo;
 
+   WARN_ON(!virt);
+
bo = hmm_bo_device_search_start(_device, (unsigned int)virt);
 
if (!bo) {
@@ -284,9 +286,7 @@ void hmm_free(ia_css_ptr virt)
hmm_mem_stat.tol_cnt -= bo->pgnr;
 
hmm_bo_unbind(bo);
-
hmm_bo_free_pages(bo);
-
hmm_bo_unref(bo);
 }
 
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
index 78b4709..63904bc 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hrt/hive_isp_css_mm_hrt.c
@@ -28,13 +28,6 @@
 
 #define __page_align(size) (((size) + (PAGE_SIZE-1)) & (~(PAGE_SIZE-1)))
 
-static unsigned init_done;
-void hrt_isp_css_mm_init(void)
-{
-   hmm_init();
-   init_done = 1;
-}
-
 int hrt_isp_css_mm_set(ia_css_ptr virt_addr, int c, size_t bytes)
 {
if (virt_addr)
@@ -57,20 +50,6 @@ int hrt_isp_css_mm_store(ia_css_ptr virt_addr, const void 
*data, size_t bytes)
return -EFAULT;
 }
 
-void hrt_isp_css_mm_free(ia_css_ptr virt_addr)
-{
-   if (virt_addr)
-   hmm_free(virt_addr);
-}
-
-void hrt_isp_css_mm_clear(void)
-{
-   if (init_done) {
-   hmm_cleanup();
-   init_done = 0;
-   }
-}
-
 static void *my_userptr;
 static unsigned my_num_pages;
 static enum hrt_userptr_type my_usr_type;
@@ -89,8 +68,6 @@ static ia_css_ptr __hrt_isp_css_mm_alloc(size_t bytes, void 
*userptr,
enum hrt_userptr_type type,
bool cached)
 {
-   if (!init_done)
-   hrt_isp_css_mm_init();
 #ifdef CONFIG_ION
if (type == HRT_USR_ION)
return hmm_alloc(bytes, HMM_BO_ION, 0,
@@ -138,9 +115,6 @@ ia_css_ptr hrt_isp_css_mm_alloc_user_ptr(size_t bytes, void 
*userptr,
 
 ia_css_ptr hrt_isp_css_mm_alloc_cached(size_t bytes)
 {
-   if (!init_done)
-   hrt_isp_css_mm_init();
-
if (my_userptr == NULL)
return hmm_alloc(bytes, HMM_BO_PRIVATE, 0, 0,
 

[PATCH 1/8] atomisp: handle allocation calls before init in the hmm layer

[Alan Cox]

Currently the code handles this in the abstraction above. We want to remove
that abstraction so begin by pushing down the sanity check. Unfortunately
at this point we can't simply fix the init order.

Signed-off-by: Alan Cox 
---
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 151abf0..14537ab 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -226,6 +226,11 @@ ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
struct hmm_buffer_object *bo;
int ret;
 
+   /* Check if we are initialized. In the ideal world we wouldn't need
+  this but we can tackle it once the driver is a lot cleaner */
+
+   if (!dummy_ptr)
+   hmm_init();
/*Get page number from size*/
pgnr = size_to_pgnr_ceil(bytes);
 

[PATCH 3/8] atomisp: kill off mmgr_free

[Alan Cox]

This is just another wrapper layer around hmm_free that servers no purpose
in this driver.

Signed-off-by: Alan Cox 
---
 .../media/atomisp/pci/atomisp2/atomisp_acc.c   |6 +++---
 .../atomisp2/css2400/base/refcount/src/refcount.c  |8 
 .../memory_access/memory_access.h  |   10 ++
 .../pci/atomisp2/css2400/ia_css_memory_access.c|6 --
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |2 +-
 .../isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c|2 +-
 .../atomisp2/css2400/runtime/binary/src/binary.c   |2 +-
 .../pci/atomisp2/css2400/runtime/frame/src/frame.c |2 +-
 .../css2400/runtime/isp_param/src/isp_param.c  |2 +-
 .../atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c  |6 +++---
 .../atomisp2/css2400/runtime/spctrl/src/spctrl.c   |6 +++---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|4 ++--
 .../atomisp/pci/atomisp2/css2400/sh_css_params.c   |   16 
 .../media/atomisp/pci/atomisp2/hrt/memory_access.c |7 ---
 14 files changed, 30 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
index 212e0a7..1eac329 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
@@ -136,7 +136,7 @@ void atomisp_acc_release(struct atomisp_sub_device *asd)
/* Free all mapped memory blocks */
list_for_each_entry_safe(atomisp_map, tm, >acc.memory_maps, list) {
list_del(_map->list);
-   mmgr_free(atomisp_map->ptr);
+   hmm_free(atomisp_map->ptr);
kfree(atomisp_map);
}
 }
@@ -374,7 +374,7 @@ int atomisp_acc_map(struct atomisp_sub_device *asd, struct 
atomisp_acc_map *map)
 
atomisp_map = kmalloc(sizeof(*atomisp_map), GFP_KERNEL);
if (!atomisp_map) {
-   mmgr_free(cssptr);
+   hmm_free(cssptr);
return -ENOMEM;
}
atomisp_map->ptr = cssptr;
@@ -399,7 +399,7 @@ int atomisp_acc_unmap(struct atomisp_sub_device *asd, 
struct atomisp_acc_map *ma
return -EINVAL;
 
list_del(_map->list);
-   mmgr_free(atomisp_map->ptr);
+   hmm_free(atomisp_map->ptr);
kfree(atomisp_map);
return 0;
 }
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/base/refcount/src/refcount.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/base/refcount/src/refcount.c
index 05e4bc3..6e3bd77 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/base/refcount/src/refcount.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/base/refcount/src/refcount.c
@@ -108,7 +108,7 @@ void ia_css_refcount_uninit(void)
/*  ia_css_debug_dtrace(IA_CSS_DBG_TRACE,
"ia_css_refcount_uninit: freeing (%x)\n",
entry->data);*/
-   mmgr_free(entry->data);
+   hmm_free(entry->data);
entry->data = mmgr_NULL;
entry->count = 0;
entry->id = 0;
@@ -181,7 +181,7 @@ bool ia_css_refcount_decrement(int32_t id, hrt_vaddress ptr)
if (entry->count == 0) {
/* ia_css_debug_dtrace(IA_CSS_DBEUG_TRACE,
   "ia_css_refcount_decrement: freeing\n");*/
-   mmgr_free(ptr);
+   hmm_free(ptr);
entry->data = mmgr_NULL;
entry->id = 0;
}
@@ -244,9 +244,9 @@ void ia_css_refcount_clear(int32_t id, clear_func 
clear_func_ptr)
} else {
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE,
"ia_css_refcount_clear: "
-   "using mmgr_free: "
+   "using hmm_free: "
"no clear_func\n");
-   mmgr_free(entry->data);
+   hmm_free(entry->data);
}
 #ifndef ISP2401
 
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/memory_access/memory_access.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/memory_access/memory_access.h
index 54ab3d9..195c4a5 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/memory_access/memory_access.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/memory_access/memory_access.h
@@ -59,6 +59,8 @@
  */
 #include "device_access.h"
 
+#include "hmm/hmm.h"
+
 /*!
  * \brief
  * Bit masks for 

Re: [PATCH 0/8] omapdrm: add OMAP4 CEC support

[Hans Verkuil]

On 28/04/17 13:52, Tomi Valkeinen wrote:
> On 14/04/17 13:25, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds support for the OMAP4 HDMI CEC IP core.
> 
> What is this series based on? It doesn't apply to drm-next, and:
> fatal: sha1 information is lacking or useless
> (drivers/gpu/drm/omapdrm/dss/hdmi4.c).

That patch series was based on the media_tree master since I needed the latest
CEC core code that supports CEC while HPD is down. I have rebased my series
to the latest media_tree version. It's available in my panda-cec branch from
my repo: git://linuxtv.org/hverkuil/media_tree.git.

As mentioned, once 4.12-rc1 has been released I'll rebase and repost.

Regards,

Hans

Re: [PATCH 2/2] media: entity: Add media_entity_pad_from_dt_regs() function

[Niklas Söderlund]

Hej,

Thanks for your feedback.

On 2017-04-28 13:43:39 +0300, Sakari Ailus wrote:
> Hejssan!!!
> 
> On Fri, Apr 28, 2017 at 12:33:23AM +0200, Niklas Söderlund wrote:
> > This is a wrapper around the media entity pad_from_dt_regs operation.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/media-entity.c | 21 +
> >  include/media/media-entity.h | 22 ++
> >  2 files changed, 43 insertions(+)
> > 
> > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > index 5640ca29da8c9bbc..6ef76186d552724e 100644
> > --- a/drivers/media/media-entity.c
> > +++ b/drivers/media/media-entity.c
> > @@ -386,6 +386,27 @@ struct media_entity *media_graph_walk_next(struct 
> > media_graph *graph)
> >  }
> >  EXPORT_SYMBOL_GPL(media_graph_walk_next);
> >  
> > +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> > + int port_reg, int reg, unsigned int *pad)
> > +{
> > +   int ret;
> > +
> > +   if (!entity->ops || !entity->ops->pad_from_dt_regs) {
> > +   *pad = port_reg;
> 
> I don't think we should bind the port number in firmware to a pad in V4L2
> sub-device interface.
> 
> How about looking for a source pad in the entity instead? That's what some
> drivers do.

Sure that sounds like a nice approach, will do this for next version.

Would it make sens to extend this operation with a 'direction' parameter 
which could take either MEDIA_PAD_FL_SOURCE or MEDIA_PAD_FL_SINK and if 
!entity->ops->pad_from_dt_regs find the first pad that matches this 
'direction' and if it do exist add a check to make sure the pad that is 
return matches that 'direction'?

> 
> > +   return 0;
> > +   }
> > +
> > +   ret = entity->ops->pad_from_dt_regs(port_reg, reg, pad);
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (*pad >= entity->num_pads)
> > +   return -EINVAL;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(media_entity_pad_from_dt_regs);
> > +
> >  /* 
> > -
> >   * Pipeline management
> >   */
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index 47efaf4d825e671b..c60a3713d0a21baf 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -820,6 +820,28 @@ struct media_pad *media_entity_remote_pad(struct 
> > media_pad *pad);
> >  struct media_entity *media_entity_get(struct media_entity *entity);
> >  
> >  /**
> > + * media_entity_pad_from_dt_regs - Get pad number from DT regs
> > + *
> > + * @entity: The entity
> > + * @port_reg: DT port
> > + * @reg: DT reg
> > + * @pad: Pointer to pad which will be filled in
> > + *
> > + * This function can be used to resolve the media pad number from
> > + * DT port and reg numbers. This is useful for devices which
> > + * uses more complex mappings of media pads then that the
> > + * DT port number is equivalent to the media pad number.
> > + *
> > + * If the entity do not implement the pad_from_dt_regs() operation
> > + * this function assumes DT port is equivalent to media pad number
> > + * and sets @pad to @port_reg.
> > + *
> > + * Return: 0 on success else -EINVAL.
> 
> -EINVAL suggests the user provided bad parameters, but this isn't the case
> here. How about e.g. -ENXIO?


I reasoned that if a port_reg and reg supplied did result in a  pad 
match the user would have given pad parameters. But sure there might be 
cases where that assumtion might not be true. So I see no problem of 
changing this to -ENXIO in next version.

> 
> > + */
> > +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> > + int port_reg, int reg, unsigned int *pad);
> > +
> > +/**
> >   * media_graph_walk_init - Allocate resources used by graph walk.
> >   *
> >   * @graph: Media graph structure that will be used to walk the graph
> 
> -- 
> Hälsningar,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

-- 
Regards,
Niklas Söderlund

Re: [PATCH 5/6] rc-core: use the full 32 bits for NEC scancodes

[Sean Young]

On Thu, Apr 27, 2017 at 10:34:18PM +0200, David Härdeman wrote:
> Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
> and the nec decoder without any loss of functionality. At the same time
> it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and
> removes lots of duplication (as you can see from the patch, the same NEC
> disambiguation logic is contained in several different drivers).
> 
> Using NEC32 also removes ambiguity. For example, consider these two NEC
> messages:
> NEC16 message to address 0x05, command 0x03
> NEC24 message to address 0x0005, command 0x03
> 
> They'll both have scancode 0x0503, and there's no way to tell which
> message was received.

It's not ambiguous, the protocol is different (RC_TYPE_NEC vs RC_TYPE_NECX).

> In order to maintain backwards compatibility, some heuristics are added
> in rc-main.c to convert scancodes to NEC32 as necessary when userspace
> adds entries to the keytable using the regular input ioctls. These
> heuristics are essentially the same as the ones that are currently in
> drivers/media/rc/img-ir/img-ir-nec.c (which are rendered unecessary
> with this patch).

There are issues with the patch which breaks userspace, as discussed
in the previous patch. None of those issues have been addressed.

In addition, I've read https://david.hardeman.nu/rccore/#problems-nec
There is nothing there what you have not stated before about nec being
"ambiguous", even though the protocol variant is different.


Sean

Re: [PATCH 1/2] media: entity: Add pad_from_dt_regs entity operation

[Niklas Söderlund]

Hi Sakari,

Thanks for your feedback.

On 2017-04-28 13:32:57 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> On Fri, Apr 28, 2017 at 12:33:22AM +0200, Niklas Söderlund wrote:
> > The optional operation can be used by entities to report how it maps its
> > DT node ports and endpoints to media pad numbers. This is useful for
> > devices which require more advanced mappings of pads then DT port
> > number is equivalent with media port number.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  include/media/media-entity.h | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index c7c254c5bca1761b..47efaf4d825e671b 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -171,6 +171,9 @@ struct media_pad {
> >  
> >  /**
> >   * struct media_entity_operations - Media entity operations
> > + * @pad_from_dt_regs:  Return the pad number based on DT port and reg
> > + * properties. This operation can be used to map a
> > + * DT port and reg to a media pad number. Optional.
> 
> Don't you need to provide entity as an argument as well? The driver will be
> a little bit loss due to lack of context. :-)

I'm not sure I understand you, this is a entity operation so the driver 
will know for which entity the request is mad on. Or am I missing 
something?

> 
> How about using the endpoint's device node (or fwnode; you can get it using
> of_fwnode_handle() soon) instead? You can always obtain the port node by
> just getting the parent.

I did think about that but opted for port_reg and reg since it seemed 
more simple.

But it might be better to base this work on top of your fwnode work,
s/from_dt_regs/from_fwnode/ and use the of_fwnode_handle() as you 
suggest here. Do you think this would be valuable and make this new 
operation more useful?

> 
> >   * @link_setup:Notify the entity of link changes. The 
> > operation can
> >   * return an error, in which case link setup will be
> >   * cancelled. Optional.
> > @@ -184,6 +187,7 @@ struct media_pad {
> >   *mutex held.
> >   */
> >  struct media_entity_operations {
> > +   int (*pad_from_dt_regs)(int port_reg, int reg, unsigned int *pad);
> > int (*link_setup)(struct media_entity *entity,
> >   const struct media_pad *local,
> >   const struct media_pad *remote, u32 flags);
> 
> -- 
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

-- 
Regards,
Niklas Söderlund

Re: [PATCH 0/8] omapdrm: add OMAP4 CEC support

[Tomi Valkeinen]

On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds support for the OMAP4 HDMI CEC IP core.

What is this series based on? It doesn't apply to drm-next, and:
fatal: sha1 information is lacking or useless
(drivers/gpu/drm/omapdrm/dss/hdmi4.c).

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] v4l2-async: add subnotifier registration for subdevices

[Niklas Söderlund]

Hi Sakari,

Thanks for your feedback.

On 2017-04-28 13:28:17 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> Do you happen to have a driver that would use this, to see some example of
> how the code is to be used?

Yes, the latest R-Car CSI-2 series make use of this, see:

https://www.spinics.net/lists/linux-renesas-soc/msg13693.html

> 
> Could you update the documentation in
> Documentation/media/kapi/v4l2-subdev.rst, too?

Yes will do so for the next version, thanks for reminding me.

> 
> On Fri, Apr 28, 2017 at 12:30:35AM +0200, Niklas Söderlund wrote:
> > When registered() of v4l2_subdev_internal_ops is called the subdevice
> > have access to the master devices v4l2_dev and it's called with the
> > async frameworks list_lock held. In this context the subdevice can
> > register its own notifiers to allow for incremental discovery of
> > subdevices.
> > 
> > The master device registers the subdevices closest to itself in its
> > notifier while the subdevice(s) themself register notifiers for there
> > closest neighboring devices when they are registered. Using this
> > incremental approach two problems can be solved.
> > 
> > 1. The master device no longer have to care how many subdevices exist in
> 
> s/subdevices/devices/ ?
> 
> A single sub-device driver can expose multiple sub-devices for a single
> device.

Thanks.

> 
> >the pipeline. It only needs to care about its closest subdevice and
> >arbitrary long pipelines can be created without having to adapt the
> >master device for each case.
> > 
> > 2. Subdevices which are represented as a single DT node but register
> >more then one subdevice can use this to further the pipeline
> >discovery. Since the subdevice driver is the only one who knows which
> >of its subdevices is linked with which subdevice of a neighboring DT
> >node.
> > 
> > To enable subdevices to register/unregister notifiers from the
> > registered()/unregistered() callback v4l2_async_subnotifier_register()
> > and v4l2_async_subnotifier_unregister() are added. These new notifier
> > register functions are similar to the master device equivalent functions
> > but run without taking the v4l2-async list_lock which already are held
> > when he registered()/unregistered() callbacks are called.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c | 91 
> > +---
> >  include/media/v4l2-async.h   | 22 +
> >  2 files changed, 95 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > b/drivers/media/v4l2-core/v4l2-async.c
> > index 96cc733f35ef72b0..d4a676a2935eb058 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -136,12 +136,13 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
> > sd->dev = NULL;
> >  }
> >  
> > -int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> > -struct v4l2_async_notifier *notifier)
> > +static int v4l2_async_do_notifier_register(struct v4l2_device *v4l2_dev,
> > +  struct v4l2_async_notifier *notifier,
> > +  bool subnotifier)
> >  {
> > struct v4l2_subdev *sd, *tmp;
> > struct v4l2_async_subdev *asd;
> > -   int i;
> > +   int found, i;
> 
> If you need a boolean value, you could use bool type.

Will update to use bool in next version.

> 
> >  
> > if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
> > return -EINVAL;
> > @@ -168,32 +169,69 @@ int v4l2_async_notifier_register(struct v4l2_device 
> > *v4l2_dev,
> > list_add_tail(>list, >waiting);
> > }
> >  
> > -   mutex_lock(_lock);
> > +   if (!subnotifier)
> > +   mutex_lock(_lock);
> 
> Just to be sure, I'd verify the mutex is indeed acquired.
> lockdep_assert_held(mutex) ?

Neat, was not aware of this function. Will use in next version.

> 
> > +
> > +   /*
> > +* This function can be called recursively so the list
> > +* might be modified in a recursive call. Start from the
> > +* top of the list each iteration.
> > +*/
> > +   found = 1;
> > +   while (found) {
> > +   found = 0;
> >  
> > -   list_for_each_entry_safe(sd, tmp, _list, async_list) {
> > -   int ret;
> > +   list_for_each_entry_safe(sd, tmp, _list, async_list) {
> > +   int ret;
> >  
> > -   asd = v4l2_async_belongs(notifier, sd);
> > -   if (!asd)
> > -   continue;
> > +   asd = v4l2_async_belongs(notifier, sd);
> > +   if (!asd)
> > +   continue;
> >  
> > -   ret = v4l2_async_test_notify(notifier, sd, asd);
> > -   if (ret < 0) {
> > -   mutex_unlock(_lock);
> > -   return ret;
> > 

Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl

[Sean Young]

On Thu, Apr 27, 2017 at 10:34:23PM +0200, David Härdeman wrote:
> It is currently impossible to distinguish between scancodes which have
> been generated using different protocols (and scancodes can, and will,
> overlap).
> 
> For example:
> RC5 message to address 0x00, command 0x03 has scancode 0x0503
> JVC message to address 0x00, command 0x03 has scancode 0x0503
> 
> It is only possible to distinguish (and parse) scancodes by known the
> scancode *and* the protocol.
> 
> Setting and getting keycodes in the input subsystem used to be done via
> the EVIOC[GS]KEYCODE ioctl and "unsigned int[2]" (one int for scancode
> and one for the keycode).
> 
> The interface has now been extended to use the EVIOC[GS]KEYCODE_V2 ioctl
> which uses the following struct:
> 
> struct input_keymap_entry {
>   __u8  flags;
>   __u8  len;
>   __u16 index;
>   __u32 keycode;
>   __u8  scancode[32];
> };
> 
> (scancode can of course be even bigger, thanks to the len member).
> 
> This patch changes how the "input_keymap_entry" struct is interpreted
> by rc-core by casting it to "rc_keymap_entry":
> 
> struct rc_scancode {
>   __u16 protocol;
>   __u16 reserved[3];
>   __u64 scancode;
> }
> 
> struct rc_keymap_entry {
>   __u8  flags;
>   __u8  len;
>   __u16 index;
>   __u32 keycode;
>   union {
>   struct rc_scancode rc;
>   __u8 raw[32];
>   };
> };
> 
> The u64 scancode member is large enough for all current protocols and it
> would be possible to extend it in the future should it be necessary for
> some exotic protocol.
> 
> The main advantage with this change is that the protocol is made explicit,
> which means that we're not throwing away data (the protocol type).
> 
> This also means that struct rc_map no longer hardcodes the protocol, meaning
> that keytables with mixed entries are possible.
> 
> Heuristics are also added to hopefully do the right thing with older
> ioctls in order to preserve backwards compatibility.

The current ioctls do not provide any protocol information, so they should
continue to match any protocol. Those heuristics aren't good enough.

Another way of doing is to have a bitmask of protocols, and default to
RC_BIT_ALL for current ioctls.
 
> Note that the heuristics are not 100% guaranteed to get things right.
> That is unavoidable since the protocol information simply isn't there
> when userspace calls the previous ioctl() types.
> 
> However, that is somewhat mitigated by the fact that the "only"
> userspace binary which might need to change is ir-keytable. Userspace
> programs which simply consume input events (i.e. the vast majority)
> won't have to change.

For this to be accepted we would need ir-keytable changes too so it can
be tested.

> 
> Signed-off-by: David Härdeman 
> ---
>  drivers/media/rc/ati_remote.c |1 
>  drivers/media/rc/imon.c   |7 +-
>  drivers/media/rc/rc-main.c|  188 
> +
>  include/media/rc-core.h   |   26 +-
>  include/media/rc-map.h|5 +
>  5 files changed, 165 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
> index 9cf3e69de16a..cc81b938471f 100644
> --- a/drivers/media/rc/ati_remote.c
> +++ b/drivers/media/rc/ati_remote.c
> @@ -546,6 +546,7 @@ static void ati_remote_input_report(struct urb *urb)
>* set, assume this is a scrollwheel up/down event.
>*/
>   wheel_keycode = rc_g_keycode_from_table(ati_remote->rdev,
> + RC_TYPE_OTHER,
>   scancode & 0x78);
>  
>   if (wheel_keycode == KEY_RESERVED) {
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index 3489010601b5..c724a1a5e9cd 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -1274,14 +1274,15 @@ static u32 imon_remote_key_lookup(struct imon_context 
> *ictx, u32 scancode)
>   bool is_release_code = false;
>  
>   /* Look for the initial press of a button */
> - keycode = rc_g_keycode_from_table(ictx->rdev, scancode);
> + keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type, scancode);
>   ictx->rc_toggle = 0x0;
>   ictx->rc_scancode = scancode;
>  
>   /* Look for the release of a button */
>   if (keycode == KEY_RESERVED) {
>   release = scancode & ~0x4000;
> - keycode = rc_g_keycode_from_table(ictx->rdev, release);
> + keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type,
> +   release);
>   if (keycode != KEY_RESERVED)
>   is_release_code = true;
>   }
> @@ -1310,7 +1311,7 @@ static u32 imon_mce_key_lookup(struct imon_context 
> *ictx, u32 scancode)
>   scancode = scancode | MCE_KEY_MASK | 

em28xx module: misidentified card

[Giuseppe Toscano]

I am trying to use eMPIA Technology, Inc. GrabBeeX+ Video Encoder 
(card=21) but the em28xx driver erroneously identifies it as 
EM2860/SAA711X Reference Design (card = 19).

Attached the output of lsusb and dmesg.

Best regards,

Giuseppe Toscano
--
Dipartimento di Ingegneria Chimica, dei Materiali e della Produzione
Industriale (DICMaPI)
Università degli Studi di Napoli Federico II
Piazzale Tecchio 80
I-80125 Napoli, Italy
tel. +39-081-76-82278
[0.00] Linux version 4.8.0-49-generic (buildd@lcy01-26) (gcc version 
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #52~16.04.1-Ubuntu SMP Thu Apr 
20 10:55:59 UTC 2017 (Ubuntu 4.8.0-49.52~16.04.1-generic 4.8.17)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-49-generic 
root=UUID=35ec5c90-3658-4eee-b92a-842317fe4870 ro quiet splash vt.handoff=7
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbfea] usable
[0.00] BIOS-e820: [mem 0xbfeb-0xbfec9fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbfeca000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013bff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Acer TravelMate 6592/TravelMate 6592, BIOS V1.4101/07/08
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0C000 mask FC000 uncachable
[0.00]   1 base 13C00 mask FFC00 uncachable
[0.00]   2 base 0 mask F write-back
[0.00]   3 base 1 mask FC000 write-back
[0.00]   4 base 0BFF0 mask 0 uncachable
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] total RAM covered: 4031M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 128Mnum_reg: 5  lose 
cover RAM: 0G
[0.00] e820: update [mem 0xbff0-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xbfeb0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f70e0-0x000f70ef] mapped at 
[a142800f70e0]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [a14280098000] 98000 size 24576
[0.00] BRK [0x2283b000, 0x2283bfff] PGTABLE
[0.00] BRK [0x2283c000, 0x2283cfff] PGTABLE
[0.00] BRK [0x2283d000, 0x2283dfff] PGTABLE
[0.00] BRK [0x2283e000, 0x2283efff] PGTABLE
[0.00] BRK [0x2283f000, 0x2283] PGTABLE
[0.00] RAMDISK: [mem 0x33302000-0x35978fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F7040 24 (v02 ACRSYS)
[0.00] ACPI: XSDT 0xBFEBCEC1 94 (v01 ACRSYS ACRPRDCT 
0604  LTP )
[0.00] ACPI: FACP 0xBFEC6B87 F4 (v03 INTEL  CRESTLNE 
0604 ALAN 0001)
[0.00] ACPI: DSDT 0xBFEBE3ED 008726 (v02 INTEL  CRESTLNE 
0604 INTL 20050624)
[0.00] ACPI: FACS 0xBFEC9FC0 40
[0.00] ACPI: FACS 0xBFEC9FC0 40
[0.00] ACPI: HPET 0xBFEC6C7B 38 (v01 INTEL  CRESTLNE 
0604 LOHR 005A)
[0.00] ACPI: MCFG 0xBFEC6CB3 3C (v01 INTEL  CRESTLNE 
0604 LOHR 

Re: [PATCH 2/8] omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled

[Tomi Valkeinen]

On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> When the OMAP4 CEC support is enabled the CEC pin should always
> be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC
> is set.
> 
> Background: even if the HPD is low it should still be possible
> to use CEC. Some displays will set the HPD low when they go into standby or
> when they switch to another input, but CEC is still available and able
> to wake up/change input for such a display.
> 
> This is explicitly allowed by the CEC standard.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
> b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> index 58276a48112e..757554e6d62f 100644
> --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> @@ -46,6 +46,9 @@ static int tpd_connect(struct omap_dss_device *dssdev,
>   dssdev->dst = dst;
>  
>   gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1);
> +#ifdef CONFIG_OMAP4_DSS_HDMI_CEC
> + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);
> +#endif
>   /* DC-DC converter needs at max 300us to get to 90% of 5V */
>   udelay(300);
>  
> @@ -64,6 +67,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
>   return;
>  
>   gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
> + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
>  
>   dst->src = NULL;
>   dssdev->dst = NULL;
> @@ -146,11 +150,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
>   if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
>   return -ENODEV;
>  
> +#ifndef CONFIG_OMAP4_DSS_HDMI_CEC
>   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);
> +#endif
>  
>   r = in->ops.hdmi->read_edid(in, edid, len);
>  
> +#ifndef CONFIG_OMAP4_DSS_HDMI_CEC
>   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
> +#endif
>  
>   return r;
>  }
> 

Optimally, we want to enable LS_OE only when needed, which would be when
reading EDID, using HDCP, or using CEC. But we don't have good means to
convey that information at the moment, and I'd rather leave it for later
when we have done the bigger restructuring of omapdrm.

For now, instead of the ifdef-confusion, I think we should just enable
the LS_OE in tpd_connect and be done with it.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 6/6] rc-core: add protocol to EVIOC[GS]KEYCODE_V2 ioctl

[Mauro Carvalho Chehab]

Em Thu, 27 Apr 2017 22:34:23 +0200
David Härdeman  escreveu:

> It is currently impossible to distinguish between scancodes which have
> been generated using different protocols (and scancodes can, and will,
> overlap).
> 
> For example:
> RC5 message to address 0x00, command 0x03 has scancode 0x0503
> JVC message to address 0x00, command 0x03 has scancode 0x0503
> 
> It is only possible to distinguish (and parse) scancodes by known the
> scancode *and* the protocol.
> 
> Setting and getting keycodes in the input subsystem used to be done via
> the EVIOC[GS]KEYCODE ioctl and "unsigned int[2]" (one int for scancode
> and one for the keycode).
> 
> The interface has now been extended to use the EVIOC[GS]KEYCODE_V2 ioctl
> which uses the following struct:
> 
> struct input_keymap_entry {
>   __u8  flags;
>   __u8  len;
>   __u16 index;
>   __u32 keycode;
>   __u8  scancode[32];
> };
> 
> (scancode can of course be even bigger, thanks to the len member).
> 
> This patch changes how the "input_keymap_entry" struct is interpreted
> by rc-core by casting it to "rc_keymap_entry":
> 
> struct rc_scancode {
>   __u16 protocol;
>   __u16 reserved[3];
>   __u64 scancode;
> }
> 
> struct rc_keymap_entry {
>   __u8  flags;
>   __u8  len;
>   __u16 index;
>   __u32 keycode;
>   union {
>   struct rc_scancode rc;
>   __u8 raw[32];
>   };
> };
> 
> The u64 scancode member is large enough for all current protocols and it
> would be possible to extend it in the future should it be necessary for
> some exotic protocol.
> 
> The main advantage with this change is that the protocol is made explicit,
> which means that we're not throwing away data (the protocol type).
> 
> This also means that struct rc_map no longer hardcodes the protocol, meaning
> that keytables with mixed entries are possible.
> 
> Heuristics are also added to hopefully do the right thing with older
> ioctls in order to preserve backwards compatibility.
> 
> Note that the heuristics are not 100% guaranteed to get things right.
> That is unavoidable since the protocol information simply isn't there
> when userspace calls the previous ioctl() types.
> 
> However, that is somewhat mitigated by the fact that the "only"
> userspace binary which might need to change is ir-keytable. Userspace
> programs which simply consume input events (i.e. the vast majority)
> won't have to change.

Nack.

No userspace breakages are allowed. There's no way to warrant that
ir-keytable version is compatible with a certain Kernel version.

Thanks,
Mauro

Re: [PATCH 6/8] omapdrm: hdmi4: refcount hdmi_power_on/off_core

[Tomi Valkeinen]

On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The hdmi_power_on/off_core functions can be called multiple times:
> when the HPD changes and when the HDMI CEC support needs to power
> the HDMI core.
> 
> So use a counter to know when to really power on or off the HDMI core.
> 
> Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to
> power up the HDMI core (needed for CEC).
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 4a164dc01f15..e371b47ff6ff 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device 
> *dssdev)
>  {
>   int r;
>  
> + if (hdmi.core.core_pwr_cnt++)
> + return 0;
> +

How's the locking between the CEC side and the DRM side? Normally these
functions are protected with the DRM modesetting locks, but CEC doesn't
come from there. We have the hdmi.lock, did you check that it's held
when CEC side calls shared functions?

>   r = regulator_enable(hdmi.vdda_reg);
>   if (r)
> - return r;
> + goto err_reg_enable;
>  
>   r = hdmi_runtime_get();
>   if (r)
>   goto err_runtime_get;
>  
> + hdmi4_core_powerdown_disable();

I'd like to have the powerdown_disable as a separate patch. Also, now
that you call it here, I believe it can be dropped from hdmi4_configure().

Hmm, but in hdmi4_configure we call hdmi_core_swreset_assert() before
hdmi4_core_powerdown_disable(). I wonder what exactly that does, and
whether we end up resetting also the CEC parts when we change the videomode.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/2] media: entity: add operation to help map DT node to media pad

[Mauro Carvalho Chehab]

Hi Niklas,

Em Fri, 28 Apr 2017 00:33:21 +0200
Niklas Söderlund  escreveu:

> Hi,
> 
> This small series add a new entity operation which will aid capture 
> drivers to map a port/endpoint in DT to a media graph pad. I looked 
> around and in my experience most drivers assume the DT port number is 
> the same as the media pad number.
> 
> This might be true for most devices but there are cases where this 
> mapping do not hold true. This series is implemented support to the 
> ongoing ADV748x work by Kieran Bingham, [1]. In his work he have a 
> driver which registers more then one subdevice. So when a driver finds 
> this subdevice it must be able to ask the subdevice itself which pad 
> number correspond to the DT endpoint the driver used to bind subdevice 
> in the first place.
> 
> I have updated my R-Car CSI-2 patch series to use this new function to 
> ask it's subdevice to resolve the media pad.

The problem of finding a PAD is not specific for DT-based devices.
So, what we need is a generic way to find a pad.

The non-DT based drivers usually don't implement subdev API. So, they
need to build the pipelines themselves. On such devices, there are
hundreds of different combinations of devices, and the main driver
needs to seek the hardware connected into it. Based on such
runtime knowledge, setup the pipelines.

One such example is em28xx with can use a wide range of different 
tuners, analog TV decoders and digital TV frontends.

The I2C devices like tuners and decoders have pads with different
signals:
- RF 
- digital video (encoded with ITU-R BT.656 or similar)
- audio IF signal
- chroma IF signal
- baseband signal
- luminance IF signal
- digital audio (using I2S)
- composite video
- ...

Right now, this is "solved" by using enums at include/media/v4l2-mc.h,
like this one:

enum tuner_pad_index {
TUNER_PAD_RF_INPUT,
TUNER_PAD_OUTPUT,
TUNER_PAD_AUD_OUT,
TUNER_NUM_PADS
};

That's not optimal, as even tuners that don't provide, for example,
an audio output pad need to have an unconnected TUNER_PAD_AUD_OUT
pad [1].

[1] With the current model, we're using TUNER_PAD_AUD_OUT for both
IF and digital audio - as currently - drivers don't need to distinguish
and we didn't want to have an excessive number of unconnected PADs.

So, what we really need is a way to represent a set of properties
associated with pads, and a function that would seek for a PAD that
matches a property set.

There is a proposal from Sakari to have a properties API that would
allow such kind of association (among others) and would even let
export such properties to userspace, but he never had time to send
us patches adding such functionality.

- 

IMHO, what we should do, instead of the approach you took, would be
to create a list of properties associated with each PAD (or, actually,
to any graph object, as we may want later to have properties also for
entities, interfaces and links). Something like:

enum media_property_type {
MEDIA_PROP_PAD_DT_PORT_REG, // not sure if this is the best name
MEDIA_PROP_PAD_DT_REG,  // not sure if this is the best name
MEDIA_PROP_PAD_SIGNAL_TYPE, // that's for the above example of 
identifying a pad based on the signal it carries: I2S, RF, IF, ...
...
};

struct media_properties {
enum media_property_type type;
int value;

struct list_head *list;
};

struct media_graph {
struct {
struct media_entity *entity;
struct list_head *link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];

struct media_entity_enum ent_enum;
int top;

struct list_head *props; /* head for struct media_properties */
};

and a generic media_find_property() function that would allow a
driver to seek for an specific set of properties, e. g.:

int find_find_property(struct media_properties *props, struct media_graph 
*gobj);

This way, if someone would need to seek for an specific set of
properties (like on your DT case), he could use a helper function like
(untested):

find_dt_reg(int _port_reg, int _reg, struct media_graph *gobj)
{
struct media_properties port_reg, reg;

port_reg.type = MEDIA_PROP_DT_PORT_REG;
port_reg.value = _port_reg;

reg.type = MEDIA_PROP_DT_REG;
reg.value = _reg;

INIT_LIST_HEAD(_reg->list);
list_add_tail(>list, );

find_find_property(_reg, gobj);
}


Thanks,
Mauro

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Tomi Valkeinen]

On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The CEC pin was always pulled up, making it impossible to use it.
> 
> Change to PIN_INPUT so it can be used by the new CEC support.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  arch/arm/boot/dts/omap4-panda-a4.dts | 2 +-
>  arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts 
> b/arch/arm/boot/dts/omap4-panda-a4.dts
> index 78d363177762..f1a6476af371 100644
> --- a/arch/arm/boot/dts/omap4-panda-a4.dts
> +++ b/arch/arm/boot/dts/omap4-panda-a4.dts
> @@ -13,7 +13,7 @@
>  /* Pandaboard Rev A4+ have external pullups on SCL & SDA */
>  _hdmi_pins {
>   pinctrl-single,pins = <
> - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
> hdmi_cec.hdmi_cec */
> + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_cec.hdmi_cec */
>   OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_scl.hdmi_scl */
>   OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_sda.hdmi_sda */
>   >;
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 119f8e657edc..940fe4f7c5f6 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,7 +34,7 @@
>  /* PandaboardES has external pullups on SCL & SDA */
>  _hdmi_pins {
>   pinctrl-single,pins = <
> - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
> hdmi_cec.hdmi_cec */
> + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_cec.hdmi_cec */
>   OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_scl.hdmi_scl */
>   OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
> hdmi_sda.hdmi_sda */
>   >;
> 

Reviewed-by: Tomi Valkeinen 

Tony, can you queue this? It's safe to apply separately from the rest of
the HDMI CEC work.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] media: entity: Add media_entity_pad_from_dt_regs() function

[Sakari Ailus]

Hejssan!!!

On Fri, Apr 28, 2017 at 12:33:23AM +0200, Niklas Söderlund wrote:
> This is a wrapper around the media entity pad_from_dt_regs operation.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/media-entity.c | 21 +
>  include/media/media-entity.h | 22 ++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 5640ca29da8c9bbc..6ef76186d552724e 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -386,6 +386,27 @@ struct media_entity *media_graph_walk_next(struct 
> media_graph *graph)
>  }
>  EXPORT_SYMBOL_GPL(media_graph_walk_next);
>  
> +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> +   int port_reg, int reg, unsigned int *pad)
> +{
> + int ret;
> +
> + if (!entity->ops || !entity->ops->pad_from_dt_regs) {
> + *pad = port_reg;

I don't think we should bind the port number in firmware to a pad in V4L2
sub-device interface.

How about looking for a source pad in the entity instead? That's what some
drivers do.

> + return 0;
> + }
> +
> + ret = entity->ops->pad_from_dt_regs(port_reg, reg, pad);
> + if (ret)
> + return ret;
> +
> + if (*pad >= entity->num_pads)
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(media_entity_pad_from_dt_regs);
> +
>  /* 
> -
>   * Pipeline management
>   */
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 47efaf4d825e671b..c60a3713d0a21baf 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -820,6 +820,28 @@ struct media_pad *media_entity_remote_pad(struct 
> media_pad *pad);
>  struct media_entity *media_entity_get(struct media_entity *entity);
>  
>  /**
> + * media_entity_pad_from_dt_regs - Get pad number from DT regs
> + *
> + * @entity: The entity
> + * @port_reg: DT port
> + * @reg: DT reg
> + * @pad: Pointer to pad which will be filled in
> + *
> + * This function can be used to resolve the media pad number from
> + * DT port and reg numbers. This is useful for devices which
> + * uses more complex mappings of media pads then that the
> + * DT port number is equivalent to the media pad number.
> + *
> + * If the entity do not implement the pad_from_dt_regs() operation
> + * this function assumes DT port is equivalent to media pad number
> + * and sets @pad to @port_reg.
> + *
> + * Return: 0 on success else -EINVAL.

-EINVAL suggests the user provided bad parameters, but this isn't the case
here. How about e.g. -ENXIO?

> + */
> +int media_entity_pad_from_dt_regs(struct media_entity *entity,
> +   int port_reg, int reg, unsigned int *pad);
> +
> +/**
>   * media_graph_walk_init - Allocate resources used by graph walk.
>   *
>   * @graph: Media graph structure that will be used to walk the graph

-- 
Hälsningar,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 1/2] media: entity: Add pad_from_dt_regs entity operation

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:33:22AM +0200, Niklas Söderlund wrote:
> The optional operation can be used by entities to report how it maps its
> DT node ports and endpoints to media pad numbers. This is useful for
> devices which require more advanced mappings of pads then DT port
> number is equivalent with media port number.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  include/media/media-entity.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index c7c254c5bca1761b..47efaf4d825e671b 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -171,6 +171,9 @@ struct media_pad {
>  
>  /**
>   * struct media_entity_operations - Media entity operations
> + * @pad_from_dt_regs:Return the pad number based on DT port and reg
> + *   properties. This operation can be used to map a
> + *   DT port and reg to a media pad number. Optional.

Don't you need to provide entity as an argument as well? The driver will be
a little bit loss due to lack of context. :-)

How about using the endpoint's device node (or fwnode; you can get it using
of_fwnode_handle() soon) instead? You can always obtain the port node by
just getting the parent.

>   * @link_setup:  Notify the entity of link changes. The 
> operation can
>   *   return an error, in which case link setup will be
>   *   cancelled. Optional.
> @@ -184,6 +187,7 @@ struct media_pad {
>   *mutex held.
>   */
>  struct media_entity_operations {
> + int (*pad_from_dt_regs)(int port_reg, int reg, unsigned int *pad);
>   int (*link_setup)(struct media_entity *entity,
> const struct media_pad *local,
> const struct media_pad *remote, u32 flags);

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] v4l2-async: add subnotifier registration for subdevices

[Sakari Ailus]

Hi Niklas,

Thank you for the patch.

Do you happen to have a driver that would use this, to see some example of
how the code is to be used?

Could you update the documentation in
Documentation/media/kapi/v4l2-subdev.rst, too?

On Fri, Apr 28, 2017 at 12:30:35AM +0200, Niklas Söderlund wrote:
> When registered() of v4l2_subdev_internal_ops is called the subdevice
> have access to the master devices v4l2_dev and it's called with the
> async frameworks list_lock held. In this context the subdevice can
> register its own notifiers to allow for incremental discovery of
> subdevices.
> 
> The master device registers the subdevices closest to itself in its
> notifier while the subdevice(s) themself register notifiers for there
> closest neighboring devices when they are registered. Using this
> incremental approach two problems can be solved.
> 
> 1. The master device no longer have to care how many subdevices exist in

s/subdevices/devices/ ?

A single sub-device driver can expose multiple sub-devices for a single
device.

>the pipeline. It only needs to care about its closest subdevice and
>arbitrary long pipelines can be created without having to adapt the
>master device for each case.
> 
> 2. Subdevices which are represented as a single DT node but register
>more then one subdevice can use this to further the pipeline
>discovery. Since the subdevice driver is the only one who knows which
>of its subdevices is linked with which subdevice of a neighboring DT
>node.
> 
> To enable subdevices to register/unregister notifiers from the
> registered()/unregistered() callback v4l2_async_subnotifier_register()
> and v4l2_async_subnotifier_unregister() are added. These new notifier
> register functions are similar to the master device equivalent functions
> but run without taking the v4l2-async list_lock which already are held
> when he registered()/unregistered() callbacks are called.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 91 
> +---
>  include/media/v4l2-async.h   | 22 +
>  2 files changed, 95 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 96cc733f35ef72b0..d4a676a2935eb058 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -136,12 +136,13 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
>   sd->dev = NULL;
>  }
>  
> -int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> -  struct v4l2_async_notifier *notifier)
> +static int v4l2_async_do_notifier_register(struct v4l2_device *v4l2_dev,
> +struct v4l2_async_notifier *notifier,
> +bool subnotifier)
>  {
>   struct v4l2_subdev *sd, *tmp;
>   struct v4l2_async_subdev *asd;
> - int i;
> + int found, i;

If you need a boolean value, you could use bool type.

>  
>   if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>   return -EINVAL;
> @@ -168,32 +169,69 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   list_add_tail(>list, >waiting);
>   }
>  
> - mutex_lock(_lock);
> + if (!subnotifier)
> + mutex_lock(_lock);

Just to be sure, I'd verify the mutex is indeed acquired.
lockdep_assert_held(mutex) ?

> +
> + /*
> +  * This function can be called recursively so the list
> +  * might be modified in a recursive call. Start from the
> +  * top of the list each iteration.
> +  */
> + found = 1;
> + while (found) {
> + found = 0;
>  
> - list_for_each_entry_safe(sd, tmp, _list, async_list) {
> - int ret;
> + list_for_each_entry_safe(sd, tmp, _list, async_list) {
> + int ret;
>  
> - asd = v4l2_async_belongs(notifier, sd);
> - if (!asd)
> - continue;
> + asd = v4l2_async_belongs(notifier, sd);
> + if (!asd)
> + continue;
>  
> - ret = v4l2_async_test_notify(notifier, sd, asd);
> - if (ret < 0) {
> - mutex_unlock(_lock);
> - return ret;
> + ret = v4l2_async_test_notify(notifier, sd, asd);
> + if (ret < 0) {
> + if (!subnotifier)
> + mutex_unlock(_lock);
> + return ret;
> + }
> +
> + found = 1;
> + break;
>   }
>   }
>  
>   /* Keep also completed notifiers on the list */
>   list_add(>list, _list);
>  
> - mutex_unlock(_lock);
> + if (!subnotifier)
> + 

Re: [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

[Kieran Bingham]

On 28/04/17 11:04, Geert Uytterhoeven wrote:
> On Fri, Apr 28, 2017 at 10:52 AM, Sergei Shtylyov
>  wrote:
>> On 4/27/2017 9:26 PM, Kieran Bingham wrote:
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>>
>> [...]
>>>
>>> @@ -387,6 +403,50 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   status = "okay";
>>> +
>>> +   clock-frequency = <10>;
>>> +
>>> +   video_receiver@70 {
>>
>>
>>Hyphens are preferred in the node names.
> 
> Definitely: make W=1 dtbs


Thanks guys, - I didn't know about that one.
I'll update my build script so it's always in place :)

--
Regards

Kieran


> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

[Geert Uytterhoeven]

On Fri, Apr 28, 2017 at 10:52 AM, Sergei Shtylyov
 wrote:
> On 4/27/2017 9:26 PM, Kieran Bingham wrote:
>> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>
> [...]
>>
>> @@ -387,6 +403,50 @@
>> };
>>  };
>>
>> + {
>> +   status = "okay";
>> +
>> +   clock-frequency = <10>;
>> +
>> +   video_receiver@70 {
>
>
>Hyphens are preferred in the node names.

Definitely: make W=1 dtbs

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 07/27] rcar-vin: change name of video device

[Kieran Bingham]

On 27/04/17 23:41, Niklas Söderlund wrote:
> The rcar-vin driver needs to be part of a media controller to support
> Gen3. Give each VIN instance a unique name so it can be referenced from
> userspace.
> 
> Signed-off-by: Niklas Söderlund 

Functional and tested.

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 1b364f359ff4b5ed..709ee828f2ac2173 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -915,7 +915,8 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
>   vdev->fops = _fops;
>   vdev->v4l2_dev = >v4l2_dev;
>   vdev->queue = >queue;
> - strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
> + snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
> +  dev_name(vin->dev));
>   vdev->release = video_device_release;
>   vdev->ioctl_ops = _ioctl_ops;
>   vdev->lock = >lock;
> 

lening bieden

[SAFETY NET CREDIT]

Goede dag,

 Dit is het beveiligingsnetwerk van de kredietverstrekking.

  SAFETY NET CREDIT biedt flexibele en betaalbare leningen voor elk doel om u 
te helpen uw doelen te bereiken. We lenen tegen een lage rente van 3%. Hier 
zijn enkele belangrijke kenmerken van de persoonlijke lening aangeboden door 
SAFETY NET CREDIT. Hier zijn de Lening Factoren die we samenwerken met de 
toonaangevende Britse makelaars die toegang hebben tot topleners en kunnen de 
beste financiële oplossing tegen een betaalbare prijs vinden. Als u 
geïnteresseerd bent, neem dan contact met ons op via deze e-mail: 
safetynetcredi...@gmail.com

Na de reactie ontvangt u een aanvraag voor leningsvulling. Geen sociale 
zekerheid en geen credit check, 100% gegarandeerd.

Het zal onze eer zijn als u ons toelaat om tot uw dienst te zijn.


INFORMATIE NODIG

Jullie namen
Adres: ...
Telefoon: ...
Bedrag nodig: 
Looptijd: ...
Beroep: ...
Maandelijks Inkomen Niveau: 
Geslacht: ...
Geboortedatum: 
Staat: ..
Land: ..
Doel: .

Het voldoen aan uw financiële behoeften is onze trots.


Dr.John Mahama.
_
This message is intended only for recipients who are authorized to receive it. 
It contains confidential and/ or legally privileged information belonging to PT 
SEMEN INDONESIA (Persero) Tbk, therefore the authorized recipients shall 
protect this confidential information disclosed pursuant to provisions of Semen 
Indonesia's policy. If you are not a valid recipient of this message, please 
delete it from your system and/ or destroy all of the tangible material 
produced from the information herein together with all copies or reproductions 
thereof and notify the sender immediately. Please also be notified that any 
disclosure, copying, distribution or taking any action based on the contents of 
this message is strictly prohibited and may be unlawful

[PATCH v8 02/10] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

[Stanimir Varbanov]

this add functions for:
  - remove buffers from src/dst queue by index
  - remove exact buffer from src/dst queue

also extends m2m API to iterate over a list of src/dst buffers
in safely and non-safely manner.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 37 ++
 include/media/v4l2-mem2mem.h   | 92 ++
 2 files changed, 129 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 6bc27e7b2a33..f62e68aa04c4 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -126,6 +126,43 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx *q_ctx)
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove);
 
+void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
+   struct vb2_v4l2_buffer *vbuf)
+{
+   struct v4l2_m2m_buffer *b;
+   unsigned long flags;
+
+   spin_lock_irqsave(_ctx->rdy_spinlock, flags);
+   b = container_of(vbuf, struct v4l2_m2m_buffer, vb);
+   list_del(>list);
+   q_ctx->num_rdy--;
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_buf);
+
+struct vb2_v4l2_buffer *
+v4l2_m2m_buf_remove_by_idx(struct v4l2_m2m_queue_ctx *q_ctx, unsigned int idx)
+
+{
+   struct v4l2_m2m_buffer *b, *tmp;
+   struct vb2_v4l2_buffer *ret = NULL;
+   unsigned long flags;
+
+   spin_lock_irqsave(_ctx->rdy_spinlock, flags);
+   list_for_each_entry_safe(b, tmp, _ctx->rdy_queue, list) {
+   if (b->vb.vb2_buf.index == idx) {
+   list_del(>list);
+   q_ctx->num_rdy--;
+   ret = >vb;
+   break;
+   }
+   }
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_idx);
+
 /*
  * Scheduling handlers
  */
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 3ccd01bd245e..e157d5c9b224 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -437,6 +437,47 @@ static inline void *v4l2_m2m_next_dst_buf(struct 
v4l2_m2m_ctx *m2m_ctx)
 }
 
 /**
+ * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready
+ * buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ */
+#define v4l2_m2m_for_each_dst_buf(m2m_ctx, b)  \
+   list_for_each_entry(b, _ctx->cap_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_src_buf() - iterate over a list of source ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ */
+#define v4l2_m2m_for_each_src_buf(m2m_ctx, b)  \
+   list_for_each_entry(b, _ctx->out_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_dst_buf_safe() - iterate over a list of destination ready
+ * buffers safely
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ * @n: used as temporary storage
+ */
+#define v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, b, n)  \
+   list_for_each_entry_safe(b, n, _ctx->cap_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_src_buf_safe() - iterate over a list of source ready
+ * buffers safely
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ * @n: used as temporary storage
+ */
+#define v4l2_m2m_for_each_src_buf_safe(m2m_ctx, b, n)  \
+   list_for_each_entry_safe(b, n, _ctx->out_q_ctx.rdy_queue, list)
+
+/**
  * v4l2_m2m_get_src_vq() - return vb2_queue for source buffers
  *
  * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
@@ -488,6 +529,57 @@ static inline void *v4l2_m2m_dst_buf_remove(struct 
v4l2_m2m_ctx *m2m_ctx)
return v4l2_m2m_buf_remove(_ctx->cap_q_ctx);
 }
 
+/**
+ * v4l2_m2m_buf_remove_by_buf() - take off exact buffer from the list of ready
+ * buffers
+ *
+ * @q_ctx: pointer to struct @v4l2_m2m_queue_ctx
+ * @vbuf: the buffer to be removed
+ */
+void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
+   struct vb2_v4l2_buffer *vbuf);
+
+/**
+ * v4l2_m2m_src_buf_remove_by_buf() - take off exact source buffer from the 
list
+ * of ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @vbuf: the buffer to be removed
+ */
+static inline void v4l2_m2m_src_buf_remove_by_buf(struct v4l2_m2m_ctx *m2m_ctx,
+ struct vb2_v4l2_buffer *vbuf)
+{
+   v4l2_m2m_buf_remove_by_buf(_ctx->out_q_ctx, vbuf);
+}
+
+/**
+ * v4l2_m2m_dst_buf_remove_by_buf() - take off exact destination buffer from 
the
+ * list of ready 

[PATCH v8 04/10] MAINTAINERS: Add Qualcomm Venus video accelerator driver

[Stanimir Varbanov]

Add an entry for Venus video encoder/decoder accelerator driver.

Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 45be5ef6056c..a3fadd61b835 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10603,6 +10603,14 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel.g
 S: Supported
 F: arch/hexagon/
 
+QUALCOMM VENUS VIDEO ACCELERATOR DRIVER
+M: Stanimir Varbanov 
+L: linux-media@vger.kernel.org
+L: linux-arm-...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/qcom/venus/
+
 QUALCOMM WCN36XX WIRELESS DRIVER
 M: Eugene Krasnikov 
 L: wcn3...@lists.infradead.org
-- 
2.7.4

[PATCH v8 00/10] Qualcomm video decoder/encoder driver

[Stanimir Varbanov]

Hi everyone,

The changes since v7 are:
  * fixed error path in recovery handler.
  * fixed the logic in helper_vb2_buf_prepare.
  * added comments over venus_format arrays why MPLANE formats are used.
  * added sequence for output queue as well.
  * added COMPILE_TEST Kconfig option for the venus driver. To make
  compile testing of the venus driver possible I had to create a patch
  01/10 which fixing the qcom SCM driver.

I have made various fixes and improvements of the decoder and encoder
to make them work on Venus hw versions 1xx & 3xx (Venus hw v.1xx is found
on SoC apq8016 / db410c SBC board, and Venus hw v.3xx on apq8096).
A brief of the changes:
  * implemented buffer reference handling. This is adding delayed process
  of the newly queued buffers until the firmware release them completely.
  With this in place now vidioc_create_bufs op works properly.
  * implemented vidioc_try_decoder_cmd and vidioc_decoder_cmd v4l2 ioctl
  ops.
  * cleanups and run checkpatch --strict

The patchset is based on next-20170426 and applies cleanly on media_tree
as well.

The report of v4l2-compliance is below patchset diff status.

regards,
Stan
  
Stanimir Varbanov (10):
  firmware: qcom_scm: Fix to allow COMPILE_TEST-ing
  media: v4l2-mem2mem: extend m2m APIs for more accurate buffer
management
  doc: DT: venus: binding document for Qualcomm video driver
  MAINTAINERS: Add Qualcomm Venus video accelerator driver
  media: venus: adding core part and helper functions
  media: venus: vdec: add video decoder files
  media: venus: venc: add video encoder files
  media: venus: hfi: add Host Firmware Interface (HFI)
  media: venus: hfi: add Venus HFI files
  media: venus: enable building of Venus video driver

 .../devicetree/bindings/media/qcom,venus.txt   |  107 ++
 MAINTAINERS|8 +
 drivers/firmware/Kconfig   |2 +-
 drivers/firmware/qcom_scm.h|   72 +-
 drivers/media/platform/Kconfig |   13 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/qcom/venus/Makefile |   11 +
 drivers/media/platform/qcom/venus/core.c   |  388 +
 drivers/media/platform/qcom/venus/core.h   |  323 
 drivers/media/platform/qcom/venus/firmware.c   |  107 ++
 drivers/media/platform/qcom/venus/firmware.h   |   22 +
 drivers/media/platform/qcom/venus/helpers.c|  725 +
 drivers/media/platform/qcom/venus/helpers.h|   44 +
 drivers/media/platform/qcom/venus/hfi.c|  522 +++
 drivers/media/platform/qcom/venus/hfi.h|  175 +++
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1255 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 
 drivers/media/platform/qcom/venus/hfi_helper.h | 1050 +
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1056 +
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 
 drivers/media/platform/qcom/venus/hfi_venus.c  | 1571 
 drivers/media/platform/qcom/venus/hfi_venus.h  |   23 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |  113 ++
 drivers/media/platform/qcom/venus/vdec.c   | 1152 ++
 drivers/media/platform/qcom/venus/vdec.h   |   23 +
 drivers/media/platform/qcom/venus/vdec_ctrls.c |  149 ++
 drivers/media/platform/qcom/venus/venc.c   | 1281 
 drivers/media/platform/qcom/venus/venc.h   |   23 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  269 
 drivers/media/v4l2-core/v4l2-mem2mem.c |   37 +
 include/linux/qcom_scm.h   |   32 -
 include/media/v4l2-mem2mem.h   |   92 ++
 32 files changed, 11190 insertions(+), 44 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
 create mode 100644 drivers/media/platform/qcom/venus/Makefile
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/firmware.c
 create mode 100644 drivers/media/platform/qcom/venus/firmware.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
 create mode 100644 

[PATCH v8 01/10] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing

[Stanimir Varbanov]

Unfortunatly previous attempt to allow consumer drivers to
use COMPILE_TEST option in Kconfig is not enough, because in the
past the consumer drivers used 'depends on' Kconfig option but
now they are using 'select' Kconfig option which means on non ARM
arch'es compilation is triggered. Thus we need to move the ifdefery
one level below by touching the private qcom_scm.h header.

To: Andy Gross 
Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Signed-off-by: Stanimir Varbanov 
---
 drivers/firmware/Kconfig|  2 +-
 drivers/firmware/qcom_scm.h | 72 ++---
 include/linux/qcom_scm.h| 32 
 3 files changed, 62 insertions(+), 44 deletions(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6e4ed5a9c6fd..480578c3691a 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -204,7 +204,7 @@ config FW_CFG_SYSFS_CMDLINE
 
 config QCOM_SCM
bool
-   depends on ARM || ARM64
+   depends on ARM || ARM64 || COMPILE_TEST
select RESET_CONTROLLER
 
 config QCOM_SCM_32
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 9bea691f30fb..d2b5723afb3f 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -12,6 +12,7 @@
 #ifndef __QCOM_SCM_INT_H
 #define __QCOM_SCM_INT_H
 
+#if IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64)
 #define QCOM_SCM_SVC_BOOT  0x1
 #define QCOM_SCM_BOOT_ADDR 0x1
 #define QCOM_SCM_BOOT_ADDR_MC  0x11
@@ -58,6 +59,66 @@ extern int  __qcom_scm_pas_auth_and_reset(struct device 
*dev, u32 peripheral);
 extern int  __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
 extern int  __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
 
+#define QCOM_SCM_SVC_MP0xc
+#define QCOM_SCM_RESTORE_SEC_CFG   2
+extern int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
+ u32 spare);
+#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE3
+#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT4
+extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+size_t *size);
+extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
+u32 size, u32 spare);
+#else
+static inline int __qcom_scm_set_remote_state(struct device *dev, u32 state,
+ u32 id)
+{ return -ENODEV; }
+static inline int __qcom_scm_set_warm_boot_addr(struct device *dev, void 
*entry,
+   const cpumask_t *cpus)
+{ return -ENODEV; }
+static inline int __qcom_scm_set_cold_boot_addr(void *entry,
+   const cpumask_t *cpus)
+{ return -ENODEV; }
+static inline void __qcom_scm_cpu_power_down(u32 flags) {}
+static inline int __qcom_scm_is_call_available(struct device *dev, u32 svc_id,
+  u32 cmd_id)
+{ return -ENODEV; }
+#define QCOM_SCM_SVC_HDCP  0x11
+#define QCOM_SCM_CMD_HDCP  0x01
+static inline int __qcom_scm_hdcp_req(struct device *dev,
+ struct qcom_scm_hdcp_req *req,
+ u32 req_cnt, u32 *resp)
+{ return -ENODEV; }
+static inline void __qcom_scm_init(void) {}
+#define QCOM_SCM_SVC_PIL   0x2
+#define QCOM_SCM_PAS_IS_SUPPORTED_CMD  0x7
+static inline bool __qcom_scm_pas_supported(struct device *dev, u32 peripheral)
+{ return false; }
+static inline int  __qcom_scm_pas_init_image(struct device *dev, u32 
peripheral,
+dma_addr_t metadata_phys)
+{ return -ENODEV; }
+static inline int  __qcom_scm_pas_mem_setup(struct device *dev, u32 peripheral,
+   phys_addr_t addr, phys_addr_t size)
+{ return -ENODEV; }
+static inline int  __qcom_scm_pas_auth_and_reset(struct device *dev,
+u32 peripheral)
+{ return -ENODEV; }
+static inline int  __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral)
+{ return -ENODEV; }
+static inline int  __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
+{ return -ENODEV; }
+static inline int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
+u32 spare)
+{ return -ENODEV; }
+extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+size_t *size)
+{ return -ENODEV; }
+static inline int __qcom_scm_iommu_secure_ptbl_init(struct device *dev,
+   u64 addr, u32 size,
+   u32 spare)
+{ return -ENODEV; }
+#endif
+
 /* common error codes 

[PATCH v8 06/10] media: venus: vdec: add video decoder files

[Stanimir Varbanov]

This consists of video decoder implementation plus decoder
controls.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c   | 1152 
 drivers/media/platform/qcom/venus/vdec.h   |   23 +
 drivers/media/platform/qcom/venus/vdec_ctrls.c |  149 +++
 3 files changed, 1324 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/vdec.c
 create mode 100644 drivers/media/platform/qcom/venus/vdec.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
new file mode 100644
index ..3e606b77c8fb
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -0,0 +1,1152 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hfi_venus_io.h"
+#include "core.h"
+#include "helpers.h"
+#include "vdec.h"
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+
+   return ALIGN(size, SZ_4K);
+}
+
+static u32 get_framesize_compressed(unsigned int width, unsigned int height)
+{
+   return ((width * height * 3 / 2) / 2) + 128;
+}
+
+/*
+ * Three resons to keep MPLANE formats (despite that the number of planes
+ * currently is one):
+ * - the MPLANE formats allow only one plane to be used
+ * - the downstream driver use MPLANE formats too
+ * - future firmware versions could add support for >1 planes
+ */
+static const struct venus_format vdec_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG2,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_G,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_L,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP9,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_XVID,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *find_format_by_index(int index, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   int i, k = 0;
+
+   if (index < 0 || index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+ 

Re: [PATCH v4 06/27] rcar-vin: move max width and height information to chip information

[Kieran Bingham]

Hi Niklas,

Another easy one.

On 27/04/17 23:41, Niklas Söderlund wrote:
> On Gen3 the max supported width and height will be different from Gen2.
> Move the limits to the struct rvin_info to prepare for Gen3 support.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
>  drivers/media/platform/rcar-vin/rcar-vin.h  | 6 ++
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index ec1eb723d401fda2..998617711f1ad045 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -257,14 +257,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
>  
>  static const struct rvin_info rcar_info_h1 = {
>   .chip = RCAR_H1,
> + .max_width = 2048,
> + .max_height = 2048,
>  };
>  
>  static const struct rvin_info rcar_info_m1 = {
>   .chip = RCAR_M1,
> + .max_width = 2048,
> + .max_height = 2048,
>  };
>  
>  static const struct rvin_info rcar_info_gen2 = {
>   .chip = RCAR_GEN2,
> + .max_width = 2048,
> + .max_height = 2048,
>  };
>  
>  static const struct of_device_id rvin_of_id_table[] = {
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 7deca15d22b4d6e3..1b364f359ff4b5ed 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,8 +23,6 @@
>  #include "rcar-vin.h"
>  
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> -#define RVIN_MAX_WIDTH   2048
> -#define RVIN_MAX_HEIGHT  2048
>  
>  /* 
> -
>   * Format Conversions
> @@ -264,8 +262,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
>  
>   /* Limit to VIN capabilities */
> - v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
> -   >height, 4, RVIN_MAX_HEIGHT, 2, 0);
> + v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> +   >height, 4, vin->info->max_height, 2, 0);
>  
>   pix->bytesperline = max_t(u32, pix->bytesperline,
> rvin_format_bytesperline(pix));
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index c07b4a6893440a6a..32d9d130dd6e2e44 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -91,9 +91,15 @@ struct rvin_graph_entity {
>  /**
>   * struct rvin_info- Information about the particular VIN implementation
>   * @chip:type of VIN chip
> + *
> + * max_width:max input width the VIN supports
> + * max_height:   max input height the VIN supports
>   */
>  struct rvin_info {
>   enum chip_id chip;
> +
> + unsigned int max_width;
> + unsigned int max_height;
>  };
>  
>  /**
> 

[PATCH v8 10/10] media: venus: enable building of Venus video driver

[Stanimir Varbanov]

This adds Venus driver Makefile and changes v4l2 platform
Makefile/Kconfig in order to enable building of the driver.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/Kconfig | 13 +
 drivers/media/platform/Makefile|  2 ++
 drivers/media/platform/qcom/venus/Makefile | 11 +++
 3 files changed, 26 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/Makefile

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee1ca07..570cb9ca7703 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -448,6 +448,19 @@ config VIDEO_TI_VPE_DEBUG
---help---
  Enable debug messages on VPE driver.
 
+config VIDEO_QCOM_VENUS
+   tristate "Qualcomm Venus V4L2 encoder/decoder driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+   select QCOM_MDT_LOADER
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for Qualcomm Venus video accelerator
+ hardware. It accelerates encoding and decoding operations
+ on various Qualcomm SoCs.
+ To compile this driver as a module choose m here.
+
 endif # V4L_MEM2MEM_DRIVERS
 
 # TI VIDEO PORT Helper Modules
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d63c64c..c49de824af16 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)   += mtk-vcodec/
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
diff --git a/drivers/media/platform/qcom/venus/Makefile 
b/drivers/media/platform/qcom/venus/Makefile
new file mode 100644
index ..0fe9afb83697
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/Makefile
@@ -0,0 +1,11 @@
+# Makefile for Qualcomm Venus driver
+
+venus-core-objs += core.o helpers.o firmware.o \
+  hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o
+
+venus-dec-objs += vdec.o vdec_ctrls.o
+venus-enc-objs += venc.o venc_ctrls.o
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-core.o
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-dec.o
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-enc.o
-- 
2.7.4

[PATCH v8 05/10] media: venus: adding core part and helper functions

[Stanimir Varbanov]

 * core.c has implemented the platform driver methods, file
operations and v4l2 registration.

 * helpers.c has implemented common helper functions for:
   - buffer management

   - vb2_ops and functions for format propagation,

   - functions for allocating and freeing buffers for
   internal usage. The buffer parameters describing internal
   buffers depends on current format, resolution and codec.

   - functions for calculation of current load of the
   hardware. Depending on the count of instances and
   resolutions it selects the best clock rate for the video
   core.

 * firmware loader

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.c | 388 ++
 drivers/media/platform/qcom/venus/core.h | 323 
 drivers/media/platform/qcom/venus/firmware.c | 107 
 drivers/media/platform/qcom/venus/firmware.h |  22 +
 drivers/media/platform/qcom/venus/helpers.c  | 725 +++
 drivers/media/platform/qcom/venus/helpers.h  |  44 ++
 6 files changed, 1609 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/firmware.c
 create mode 100644 drivers/media/platform/qcom/venus/firmware.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
new file mode 100644
index ..48391d87d5c3
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -0,0 +1,388 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "vdec.h"
+#include "venc.h"
+#include "firmware.h"
+
+static void venus_event_notify(struct venus_core *core, u32 event)
+{
+   struct venus_inst *inst;
+
+   switch (event) {
+   case EVT_SYS_WATCHDOG_TIMEOUT:
+   case EVT_SYS_ERROR:
+   break;
+   default:
+   return;
+   }
+
+   mutex_lock(>lock);
+   core->sys_error = true;
+   list_for_each_entry(inst, >instances, list)
+   inst->ops->event_notify(inst, EVT_SESSION_ERROR, NULL);
+   mutex_unlock(>lock);
+
+   disable_irq_nosync(core->irq);
+
+   /*
+* Delay recovery to ensure venus has completed any pending cache
+* operations. Without this sleep, we see device reset when firmware is
+* unloaded after a system error.
+*/
+   schedule_delayed_work(>work, msecs_to_jiffies(100));
+}
+
+static const struct hfi_core_ops venus_core_ops = {
+   .event_notify = venus_event_notify,
+};
+
+static void venus_sys_error_handler(struct work_struct *work)
+{
+   struct venus_core *core =
+   container_of(work, struct venus_core, work.work);
+   int ret = 0;
+
+   dev_warn(core->dev, "system error has occurred, starting recovery!\n");
+
+   pm_runtime_get_sync(core->dev);
+
+   hfi_core_deinit(core, true);
+   hfi_destroy(core);
+   mutex_lock(>lock);
+   venus_shutdown(>dev_fw);
+
+   pm_runtime_put_sync(core->dev);
+
+   ret |= hfi_create(core, _core_ops);
+
+   pm_runtime_get_sync(core->dev);
+
+   ret |= venus_boot(core->dev, >dev_fw);
+
+   ret |= hfi_core_resume(core, true);
+
+   enable_irq(core->irq);
+
+   mutex_unlock(>lock);
+
+   ret |= hfi_core_init(core);
+
+   pm_runtime_put_sync(core->dev);
+
+   if (ret) {
+   disable_irq_nosync(core->irq);
+   dev_warn(core->dev, "recovery failed (%d)\n", ret);
+   schedule_delayed_work(>work, msecs_to_jiffies(10));
+   return;
+   }
+
+   mutex_lock(>lock);
+   core->sys_error = false;
+   mutex_unlock(>lock);
+}
+
+static int venus_clks_get(struct venus_core *core)
+{
+   const struct venus_resources *res = core->res;
+   struct device *dev = core->dev;
+   unsigned int i;
+
+   for (i = 0; i < res->clks_num; i++) {
+   core->clks[i] = devm_clk_get(dev, res->clks[i]);
+   if (IS_ERR(core->clks[i]))
+   return PTR_ERR(core->clks[i]);
+   }
+
+   return 0;
+}
+

[PATCH v8 09/10] media: venus: hfi: add Venus HFI files

[Stanimir Varbanov]

Here is the implementation of Venus video accelerator low-level
functionality. It contanins code which setup the registers and
startup uthe processor, allocate and manipulates with the shared
memory used for sending commands and receiving messages.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_venus.c| 1571 ++
 drivers/media/platform/qcom/venus/hfi_venus.h|   23 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h |  113 ++
 3 files changed, 1707 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
new file mode 100644
index ..4104582dcd9b
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -0,0 +1,1571 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi_cmds.h"
+#include "hfi_msgs.h"
+#include "hfi_venus.h"
+#include "hfi_venus_io.h"
+
+#define HFI_MASK_QHDR_TX_TYPE  0xff00
+#define HFI_MASK_QHDR_RX_TYPE  0x00ff
+#define HFI_MASK_QHDR_PRI_TYPE 0xff00
+#define HFI_MASK_QHDR_ID_TYPE  0x00ff
+
+#define HFI_HOST_TO_CTRL_CMD_Q 0
+#define HFI_CTRL_TO_HOST_MSG_Q 1
+#define HFI_CTRL_TO_HOST_DBG_Q 2
+#define HFI_MASK_QHDR_STATUS   0x00ff
+
+#define IFACEQ_NUM 3
+#define IFACEQ_CMD_IDX 0
+#define IFACEQ_MSG_IDX 1
+#define IFACEQ_DBG_IDX 2
+#define IFACEQ_MAX_BUF_COUNT   50
+#define IFACEQ_MAX_PARALLEL_CLNTS  16
+#define IFACEQ_DFLT_QHDR   0x0101
+
+#define POLL_INTERVAL_US   50
+
+#define IFACEQ_MAX_PKT_SIZE1024
+#define IFACEQ_MED_PKT_SIZE768
+#define IFACEQ_MIN_PKT_SIZE8
+#define IFACEQ_VAR_SMALL_PKT_SIZE  100
+#define IFACEQ_VAR_LARGE_PKT_SIZE  512
+#define IFACEQ_VAR_HUGE_PKT_SIZE   (1024 * 12)
+
+enum tzbsp_video_state {
+   TZBSP_VIDEO_STATE_SUSPEND = 0,
+   TZBSP_VIDEO_STATE_RESUME
+};
+
+struct hfi_queue_table_header {
+   u32 version;
+   u32 size;
+   u32 qhdr0_offset;
+   u32 qhdr_size;
+   u32 num_q;
+   u32 num_active_q;
+};
+
+struct hfi_queue_header {
+   u32 status;
+   u32 start_addr;
+   u32 type;
+   u32 q_size;
+   u32 pkt_size;
+   u32 pkt_drop_cnt;
+   u32 rx_wm;
+   u32 tx_wm;
+   u32 rx_req;
+   u32 tx_req;
+   u32 rx_irq_status;
+   u32 tx_irq_status;
+   u32 read_idx;
+   u32 write_idx;
+};
+
+#define IFACEQ_TABLE_SIZE  \
+   (sizeof(struct hfi_queue_table_header) +\
+sizeof(struct hfi_queue_header) * IFACEQ_NUM)
+
+#define IFACEQ_QUEUE_SIZE  (IFACEQ_MAX_PKT_SIZE *  \
+   IFACEQ_MAX_BUF_COUNT * IFACEQ_MAX_PARALLEL_CLNTS)
+
+#define IFACEQ_GET_QHDR_START_ADDR(ptr, i) \
+   (void *)(((ptr) + sizeof(struct hfi_queue_table_header)) +  \
+   ((i) * sizeof(struct hfi_queue_header)))
+
+#define QDSS_SIZE  SZ_4K
+#define SFR_SIZE   SZ_4K
+#define QUEUE_SIZE \
+   (IFACEQ_TABLE_SIZE + (IFACEQ_QUEUE_SIZE * IFACEQ_NUM))
+
+#define ALIGNED_QDSS_SIZE  ALIGN(QDSS_SIZE, SZ_4K)
+#define ALIGNED_SFR_SIZE   ALIGN(SFR_SIZE, SZ_4K)
+#define ALIGNED_QUEUE_SIZE ALIGN(QUEUE_SIZE, SZ_4K)
+#define SHARED_QSIZE   ALIGN(ALIGNED_SFR_SIZE + ALIGNED_QUEUE_SIZE + \
+ ALIGNED_QDSS_SIZE, SZ_1M)
+
+struct mem_desc {
+   dma_addr_t da;  /* device address */
+   void *kva;  /* kernel virtual address */
+   u32 size;
+   unsigned long attrs;
+};
+
+struct iface_queue {
+   struct hfi_queue_header *qhdr;
+   struct mem_desc qmem;
+};
+
+enum venus_state {
+   VENUS_STATE_DEINIT = 1,
+   VENUS_STATE_INIT,
+};
+
+struct venus_hfi_device {
+   struct venus_core *core;
+   u32 irq_status;
+   u32 last_packet_type;
+   bool power_enabled;
+   bool suspended;
+   enum venus_state state;
+   /* serialize read / write to the shared memory */
+   struct mutex lock;

[PATCH v8 07/10] media: venus: venc: add video encoder files

[Stanimir Varbanov]

This adds encoder part of the driver plus encoder controls.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c   | 1281 
 drivers/media/platform/qcom/venus/venc.h   |   23 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  269 +
 3 files changed, 1573 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/venc.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.h
 create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
new file mode 100644
index ..bb558d408605
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -0,0 +1,1281 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hfi_venus_io.h"
+#include "core.h"
+#include "helpers.h"
+#include "venc.h"
+
+#define NUM_B_FRAMES_MAX   4
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+   size = ALIGN(size, SZ_4K);
+
+   return size;
+}
+
+static u32 get_framesize_compressed(u32 width, u32 height)
+{
+   u32 sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
+
+   return ALIGN(sz, SZ_4K);
+}
+
+/*
+ * Three resons to keep MPLANE formats (despite that the number of planes
+ * currently is one):
+ * - the MPLANE formats allow only one plane to be used
+ * - the downstream driver use MPLANE formats too
+ * - future firmware versions could add support for >1 planes
+ */
+static const struct venus_format venc_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP9,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, int type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *find_format_by_index(int index, int type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   int i, k = 0;
+
+   if (index < 0 || index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+   break;
+   k++;
+   }
+
+   if (i == size)
+   return NULL;
+
+   return [i];
+}
+
+static int venc_v4l2_to_hfi(int id, int value)
+{
+   switch (id) {
+   case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+   switch (value) {
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0:
+   default:
+   return HFI_MPEG4_LEVEL_0;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0B:
+   return HFI_MPEG4_LEVEL_0b;
+   case 

[PATCH v8 08/10] media: venus: hfi: add Host Firmware Interface (HFI)

[Stanimir Varbanov]

This is the implementation of HFI. It is charged with the
responsibility to comunicate with the firmware through an
interface commands and messages.

 - hfi.c has interface functions used by the core, decoder
and encoder parts to comunicate with the firmware. For example
there are functions for session and core initialisation.

 - hfi_cmds has packetization operations which preparing
packets to be send from host to firmware.

 - hfi_msgs takes care of messages sent from firmware to the
host.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.c|  522 ++
 drivers/media/platform/qcom/venus/hfi.h|  175 
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1255 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 ++
 drivers/media/platform/qcom/venus/hfi_helper.h | 1050 
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1056 
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 ++
 7 files changed, 4645 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h

diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
new file mode 100644
index ..20c9205fdbb4
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -0,0 +1,522 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi.h"
+#include "hfi_cmds.h"
+#include "hfi_venus.h"
+
+#define TIMEOUTmsecs_to_jiffies(1000)
+
+static u32 to_codec_type(u32 pixfmt)
+{
+   switch (pixfmt) {
+   case V4L2_PIX_FMT_H264:
+   case V4L2_PIX_FMT_H264_NO_SC:
+   return HFI_VIDEO_CODEC_H264;
+   case V4L2_PIX_FMT_H263:
+   return HFI_VIDEO_CODEC_H263;
+   case V4L2_PIX_FMT_MPEG1:
+   return HFI_VIDEO_CODEC_MPEG1;
+   case V4L2_PIX_FMT_MPEG2:
+   return HFI_VIDEO_CODEC_MPEG2;
+   case V4L2_PIX_FMT_MPEG4:
+   return HFI_VIDEO_CODEC_MPEG4;
+   case V4L2_PIX_FMT_VC1_ANNEX_G:
+   case V4L2_PIX_FMT_VC1_ANNEX_L:
+   return HFI_VIDEO_CODEC_VC1;
+   case V4L2_PIX_FMT_VP8:
+   return HFI_VIDEO_CODEC_VP8;
+   case V4L2_PIX_FMT_VP9:
+   return HFI_VIDEO_CODEC_VP9;
+   case V4L2_PIX_FMT_XVID:
+   return HFI_VIDEO_CODEC_DIVX;
+   default:
+   return 0;
+   }
+}
+
+int hfi_core_init(struct venus_core *core)
+{
+   int ret = 0;
+
+   mutex_lock(>lock);
+
+   if (core->state >= CORE_INIT)
+   goto unlock;
+
+   reinit_completion(>done);
+
+   ret = core->ops->core_init(core);
+   if (ret)
+   goto unlock;
+
+   ret = wait_for_completion_timeout(>done, TIMEOUT);
+   if (!ret) {
+   ret = -ETIMEDOUT;
+   goto unlock;
+   }
+
+   ret = 0;
+
+   if (core->error != HFI_ERR_NONE) {
+   ret = -EIO;
+   goto unlock;
+   }
+
+   core->state = CORE_INIT;
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+static int core_deinit_wait_atomic_t(atomic_t *p)
+{
+   schedule();
+   return 0;
+}
+
+int hfi_core_deinit(struct venus_core *core, bool blocking)
+{
+   int ret = 0, empty;
+
+   mutex_lock(>lock);
+
+   if (core->state == CORE_UNINIT)
+   goto unlock;
+
+   empty = list_empty(>instances);
+
+   if (!empty && !blocking) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   if (!empty) {
+   mutex_unlock(>lock);
+   wait_on_atomic_t(>insts_count, core_deinit_wait_atomic_t,
+TASK_UNINTERRUPTIBLE);
+   mutex_lock(>lock);
+   }
+
+   ret = core->ops->core_deinit(core);
+
+   if (!ret)
+   core->state = CORE_UNINIT;
+
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+int 

[PATCH v8 03/10] doc: DT: venus: binding document for Qualcomm video driver

[Stanimir Varbanov]

Add binding document for Venus video encoder/decoder driver

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Acked-by: Rob Herring 
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/media/qcom,venus.txt   | 107 +
 1 file changed, 107 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
b/Documentation/devicetree/bindings/media/qcom,venus.txt
new file mode 100644
index ..2693449daf73
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -0,0 +1,107 @@
+* Qualcomm Venus video encoder/decoder accelerators
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain one of:
+   - "qcom,msm8916-venus"
+   - "qcom,msm8996-venus"
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register base address and length of the register map.
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: Should contain interrupt line number.
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: A List of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required for msm8916
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Core video accelerator clock
+   - "iface"   Video accelerator AHB clock
+   - "bus" Video accelerator AXI clock
+- clock-names:
+   Usage: required for msm8996
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Core video accelerator clock
+   - "iface"   Video accelerator AHB clock
+   - "bus" Video accelerator AXI clock
+   - "mbus"Video MAXI clock
+- power-domains:
+   Usage: required
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral.
+- iommus:
+   Usage: required
+   Value type: 
+   Definition: A list of phandle and IOMMU specifier pairs.
+- memory-region:
+   Usage: required
+   Value type: 
+   Definition: reference to the reserved-memory for the firmware
+   memory region.
+
+* Subnodes
+The Venus video-codec node must contain two subnodes representing
+video-decoder and video-encoder.
+
+Every of video-encoder or video-decoder subnode should have:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain "venus-decoder" or "venus-encoder"
+- clocks:
+   Usage: required for msm8996
+   Value type: 
+   Definition: A List of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required for msm8996
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Subcore video accelerator clock
+
+- power-domains:
+   Usage: required for msm8996
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the subcore.
+
+* An Example
+   video-codec@1d0 {
+   compatible = "qcom,msm8916-venus";
+   reg = <0x01d0 0xff000>;
+   interrupts = ;
+   clocks = < GCC_VENUS0_VCODEC0_CLK>,
+< GCC_VENUS0_AHB_CLK>,
+< GCC_VENUS0_AXI_CLK>;
+   clock-names = "core", "iface", "bus";
+   power-domains = < VENUS_GDSC>;
+   iommus = <_iommu 5>;
+   memory-region = <_mem>;
+
+   video-decoder {
+   compatible = "venus-decoder";
+   clocks = < VIDEO_SUBCORE0_CLK>;
+   clock-names = "core";
+   power-domains = < VENUS_CORE0_GDSC>;
+   };
+
+   video-encoder {
+   compatible = "venus-encoder";
+   clocks = < VIDEO_SUBCORE1_CLK>;
+   clock-names = "core";
+   power-domains = < VENUS_CORE1_GDSC>;
+   };
+   };
-- 
2.7.4

Re: [PATCH v4 05/27] rcar-vin: move chip information to own struct

[Kieran Bingham]

Hi Niklas,

On 27/04/17 23:41, Niklas Söderlund wrote:
> When Gen3 support is added to the driver more then chip id will be
> different for the different Soc. To avoid a lot of if statements in the
> code create a struct chip_info to contain this information.
> 
> Signed-off-by: Niklas Söderlund 

This looks good to me

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 49 
> -
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  3 +-
>  drivers/media/platform/rcar-vin/rcar-vin.h  | 12 +--
>  3 files changed, 53 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index c4d4f112da0c9d45..ec1eb723d401fda2 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -255,14 +255,47 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
>   * Platform Device Driver
>   */
>  
> +static const struct rvin_info rcar_info_h1 = {
> + .chip = RCAR_H1,
> +};
> +
> +static const struct rvin_info rcar_info_m1 = {
> + .chip = RCAR_M1,
> +};
> +
> +static const struct rvin_info rcar_info_gen2 = {
> + .chip = RCAR_GEN2,
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
> - { .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
> - { .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
> - { .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
> - { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
> - { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
> - { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
> - { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
> + {
> + .compatible = "renesas,vin-r8a7794",
> + .data = _info_gen2,
> + },
> + {
> + .compatible = "renesas,vin-r8a7793",
> + .data = _info_gen2,
> + },
> + {
> + .compatible = "renesas,vin-r8a7791",
> + .data = _info_gen2,
> + },
> + {
> + .compatible = "renesas,vin-r8a7790",
> + .data = _info_gen2,
> + },
> + {
> + .compatible = "renesas,vin-r8a7779",
> + .data = _info_h1,
> + },
> + {
> + .compatible = "renesas,vin-r8a7778",
> + .data = _info_m1,
> + },
> + {
> + .compatible = "renesas,rcar-gen2-vin",
> + .data = _info_gen2,
> + },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);
> @@ -283,7 +316,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>   return -ENODEV;
>  
>   vin->dev = >dev;
> - vin->chip = (enum chip_id)match->data;
> + vin->info = match->data;
>  
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   if (mem == NULL)
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 27b7733e96afe3e9..7deca15d22b4d6e3 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -272,7 +272,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   pix->sizeimage = max_t(u32, pix->sizeimage,
>  rvin_format_sizeimage(pix));
>  
> - if (vin->chip == RCAR_M1 && pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> + if (vin->info->chip == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
>   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
>   return -EINVAL;
>   }
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 9454ef80bc2b3961..c07b4a6893440a6a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -89,10 +89,18 @@ struct rvin_graph_entity {
>  };
>  
>  /**
> + * struct rvin_info- Information about the particular VIN implementation
> + * @chip:type of VIN chip
> + */
> +struct rvin_info {
> + enum chip_id chip;
> +};
> +
> +/**
>   * struct rvin_dev - Renesas VIN device structure
>   * @dev: (OF) device
>   * @base:device I/O register space remapped to virtual memory
> - * @chip:type of VIN chip
> + * @info:info about VIN instance
>   *
>   * @vdev:V4L2 video device associated with VIN
>   * @v4l2_dev:V4L2 device
> @@ -120,7 +128,7 @@ struct rvin_graph_entity {
>  struct rvin_dev {
>   struct device *dev;
>   void __iomem *base;
> - enum chip_id chip;
> + const struct rvin_info *info;
>  
>   struct video_device *vdev;
>   struct v4l2_device v4l2_dev;
> 

Re: [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

[Sergei Shtylyov]

Hello!

On 4/27/2017 9:26 PM, Kieran Bingham wrote:


From: Kieran Bingham 

Provide bindings between the VIN, CSI and the ADV7482 on the r8a7795.

Signed-off-by: Kieran Bingham 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 129 +
 1 file changed, 129 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 27b9bae60dc0..a20623faa9d2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts

[...]

@@ -387,6 +403,50 @@
};
 };

+ {
+   status = "okay";
+
+   clock-frequency = <10>;
+
+   video_receiver@70 {


   Hyphens are preferred in the node names.

[...]

MBR, Sergei

Re: [PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

[Kieran Bingham]

Hi Simon,

On 28/04/17 08:09, Simon Horman wrote:
> On Thu, Apr 27, 2017 at 07:25:59PM +0100, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> This is an RFC for the Analog Devices ADV748x driver, and follows on from a
>> previous posting by Niklas Söderlund [0] of an earlier incarnation of this
>> driver.
> 
> ...
> 
>> This series presents the following patches:
>>
>>  [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous
>>  [PATCH 2/5] rcar-vin: Match sources against ports if specified.
>>  [PATCH 3/5] media: i2c: adv748x: add adv748x driver
>>  [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482
>>  [PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482
> 
> I am marking the above dts patches as "RFC" and do not plan to apply them
> unless you ping me or repost them.

Yes, sorry - the whole series was supposed to be marked as RFC, but I didn't
think about it - and apparently only applied the tag to the cover letter.

Apologies for any confusion.

> Assuming they don't cause any
> regressions I would be happy to consider applying them as soon as their
> dependencies are accepted.

Does that mean you've done a cursory glance over the content ? :-)

In this instance, the port numbers need to revert back to a zero-base, but I
would appreciate an eye on how and where I've put the representation of the
physical hdmi/cvbs connectors. Having modified plenty of DT, but not actually
submitted much - I still feel 'new' at it - so I'm sure I may not have followed
the standards quite right yet.

The dts patches are based heavily on the previous posting by Niklas, but I have
extended to put the extra hdmi and cvbs links in.

Regards
--
Kieran

Re: [PATCH v2 0/3] r8a7793 Gose video input support

[Laurent Pinchart]

Hi Simon,

On Friday 28 Apr 2017 07:16:24 Simon Horman wrote:
> On Wed, Apr 26, 2017 at 06:56:06PM +0300, Laurent Pinchart wrote:
> > On Tuesday 21 Feb 2017 01:42:15 Laurent Pinchart wrote:
> >> On Thursday 20 Oct 2016 10:49:11 Simon Horman wrote:
> >>> On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
>  Hi!
>  
>  This is a by-the-datasheet implementation of analog and digital video
>  input on the Gose board.
>  
>  I have tried to address all concerns raised by reviewers, with the
>  exception of the composite input patch, which has been left as is for
>  now.
>  
>  CU
>  Uli
>  
>  
>  Changes since v1:
>  - r8a7793.dtsi: added VIN2
>  - modeled HDMI decoder input/output and connector
>  - added "renesas,rcar-gen2-vin" compat strings
>  - removed unnecessary "remote" node and aliases
>  - set ADV7612 interrupt to GP4_2
>  
>  Ulrich Hecht (3):
>    ARM: dts: r8a7793: Enable VIN0-VIN2
> >>> 
> >>> I have queued up the above patch with Laurent and Geert's tags.
> >>> 
>    ARM: dts: gose: add HDMI input
>    ARM: dts: gose: add composite video input
> >>> 
> >>> Please address the review of the above two patches and repost.
> >> 
> >> Could you please do so ? Feedback on 2/3 should be easy to handle. For
> >> 3/3, you might need to ping the DT maintainers.
> > 
> > Ping. These are the only two patches that block
> > 
> > VIN,v4.12,public,ulrich,Gen2 VIN integration
> 
> Sorry, I'm unsure how these slipped through the cracks.
> I now have them queued up locally for v4.13 and I plan to push this morning.

Please don't, the ping was for Ulrich, he needs to address review comments on 
patches 2/3 and 3/3.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2] [media] vb2: Fix an off by one error in 'vb2_plane_vaddr'

[Sakari Ailus]

On Fri, Apr 28, 2017 at 06:51:40AM +0200, Christophe JAILLET wrote:
> We should ensure that 'plane_no' is '< vb->num_planes' as done in
> 'vb2_plane_cookie' just a few lines below.
> 
> Cc: sta...@vger.kernel.org
> Fixes: e23ccc0ad925 ("[media] v4l: add videobuf2 Video for Linux 2 driver 
> framework")
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: add CC and Fixes tags
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 94afbbf92807..c0175ea7e7ad 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -868,7 +868,7 @@ EXPORT_SYMBOL_GPL(vb2_core_create_bufs);
>  
>  void *vb2_plane_vaddr(struct vb2_buffer *vb, unsigned int plane_no)
>  {
> - if (plane_no > vb->num_planes || !vb->planes[plane_no].mem_priv)
> + if (plane_no >= vb->num_planes || !vb->planes[plane_no].mem_priv)
>   return NULL;
>  
>   return call_ptr_memop(vb, vaddr, vb->planes[plane_no].mem_priv);

Reviewed-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [bug] omap3isp: missing support for ENUM_FMT

[Sakari Ailus]

Hi Pavel,

On Wed, Apr 26, 2017 at 11:19:33PM +0200, Pavel Machek wrote:
> Hi!
> 
> Currently, ispvideo.c does not support enum_format. This causes
> problems for example for libv4l2.
> 
> Now, I'm pretty sure patch below is not the right fix. But it fixes
> libv4l2 problem for me.
> 
> Pointer to right solution welcome.

The issue with providing ENUM_FMT support on MC-enabled drivers is that the
media bus format has an effect to which pixel formats are available.

What has been discussed in the past but what remains unimplemented is to add
the media bus code to v4l2_fmtdesc for user to choose. That would allow
meaningful ENUM_FMT support.

For users such as libv4l2, i.e. code == 0 --- it should just tell the user
what it can do with the active media bus format.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

[Simon Horman]

On Thu, Apr 27, 2017 at 07:25:59PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> This is an RFC for the Analog Devices ADV748x driver, and follows on from a
> previous posting by Niklas Söderlund [0] of an earlier incarnation of this
> driver.

...

> This series presents the following patches:
> 
>  [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous
>  [PATCH 2/5] rcar-vin: Match sources against ports if specified.
>  [PATCH 3/5] media: i2c: adv748x: add adv748x driver
>  [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482
>  [PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482

I am marking the above dts patches as "RFC" and do not plan to apply them
unless you ping me or repost them. Assuming they don't cause any
regressions I would be happy to consider applying them as soon as their
dependencies are accepted.

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

[Herbert Xu]

On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 26/04/17 09:56 PM, Herbert Xu wrote:
> > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> >> Very straightforward conversion to the new function in the caam driver
> >> and shash library.
> >>
> >> Signed-off-by: Logan Gunthorpe 
> >> Cc: Herbert Xu 
> >> Cc: "David S. Miller" 
> >> ---
> >>  crypto/shash.c| 9 ++---
> >>  drivers/crypto/caam/caamalg.c | 8 +++-
> >>  2 files changed, 9 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/crypto/shash.c b/crypto/shash.c
> >> index 5e31c8d..5914881 100644
> >> --- a/crypto/shash.c
> >> +++ b/crypto/shash.c
> >> @@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, 
> >> struct shash_desc *desc)
> >>if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
> >>void *data;
> >>  
> >> -  data = kmap_atomic(sg_page(sg));
> >> -  err = crypto_shash_digest(desc, data + offset, nbytes,
> >> +  data = sg_map(sg, 0, SG_KMAP_ATOMIC);
> >> +  if (IS_ERR(data))
> >> +  return PTR_ERR(data);
> >> +
> >> +  err = crypto_shash_digest(desc, data, nbytes,
> >>  req->result);
> >> -  kunmap_atomic(data);
> >> +  sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);
> >>crypto_yield(desc->flags);
> >>} else
> >>err = crypto_shash_init(desc) ?:
> > 
> > Nack.  This is an optimisation for the special case of a single
> > SG list entry.  In fact in the common case the kmap_atomic should
> > disappear altogether in the no-highmem case.  So replacing it
> > with sg_map is not acceptable.
> 
> What you seem to have missed is that sg_map is just a thin wrapper
> around kmap_atomic. Perhaps with a future check for a mappable page.
> This change should have zero impact on performance.

You are right.  Indeed the existing code looks buggy as they
don't take sg->offset into account when doing the kmap.  Could
you send me some patches that fix these problems first so that
they can be easily backported?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] [media] pxa_camera: fix module remove codepath for v4l2 clock

[Robert Jarzmik]

Petr Cvek  writes:

> I will post some other bugfixes (and feature adding) for pxa_camera soon. Do 
> you wish to be CC'd? 
>
> P.S. Who is the the maintainer of pxa_camera BTW? Still Guennadi Liakhovetski?
Euh no, that's me.

I had submitted a patch for that here :
  https://patchwork.kernel.org/patch/9316499

Hans, do you want to pick it up ?

Cheers.

-- 
Robert