Re: [v4l-utils PATCH 1/1] Allow building static binaries

[Gregor Jasny]

Hello,

On 10/12/15 14:21, Sakari Ailus wrote:
> I discussed with Hans and he thought you'd be the best person to take a look
> at this.
> 
> The case is that I'd like to build static binaries and that doesn't seem to
> work with what's in Makefile.am for libv4l1 and libv4l2 at the moment.

Sorry for the late reply. Didi not notice this email earlier. Your patch
does not do what you'd like to achieve. Both v4l1compat and v4l2convert
are libraries which only purpose is to get preloaded by the loader. So
build them statically does not make sense. Instead they should not be
built at all. To achieve this the WITH_V4L_WRAPPERS variable should
evaluate to false. This is triggered by

AM_CONDITIONAL([WITH_V4L_WRAPPERS], [test x$enable_libv4l != xno -a
x$enable_shared != xno])

So changing

LDFLAGS="--static -static" ./configure --enable-static

to

LDFLAGS="--static -static" ./configure --enable-static --disabled-shared

should do the trick. Does this help?

Thanks,
Gregor


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

[PATCH] [media] media-entity: increase max number of PADs

[Mauro Carvalho Chehab]

The DVB drivers may have 257 PADs. Get the next power of two
that would accomodate that amount.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/media-entity.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d3160224db33..ae70b6f54b18 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -261,7 +261,7 @@ static struct media_entity *stack_pop(struct 
media_entity_graph *graph)
 /*
  * TODO: Get rid of this.
  */
-#define MEDIA_ENTITY_MAX_PADS  63
+#define MEDIA_ENTITY_MAX_PADS  512
 
 /**
  * media_entity_graph_walk_init - Allocate resources for graph walk
-- 
2.5.0

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

[PATCH] [media] media-entity: don't sleep at media_device_register_entity()

[Mauro Carvalho Chehab]

media_device_register_entity() is protected by a spin_lock.

Calling ida_pre_get() with GFP_KERNEL may put it to sleep,
with is a bad idea and causes this warning:

[ 8812.397195] BUG: sleeping function called from invalid context at 
mm/slub.c:1287
[ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe
[ 8812.397207] INFO: lockdep is turned off.
[ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: GB   
4.4.0-rc2+ #41
[ 8812.397218] Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 8812.397222]   880314c77268 818f8ba7 
8803b17dde00
[ 8812.397232]  880314c77290 811c2ee5 8803b17dde00 
8284dbc9
[ 8812.397241]  0507 880314c772d0 811c30d5 
41b58ab3
[ 8812.397250] Call Trace:
[ 8812.397258]  [] dump_stack+0x4b/0x64
[ 8812.397265]  [] ___might_sleep+0x245/0x3a0
[ 8812.397270]  [] __might_sleep+0x95/0x1a0
[ 8812.397276]  [] ? ida_pre_get+0x113/0x250
[ 8812.397282]  [] kmem_cache_alloc+0x197/0x250
[ 8812.397288]  [] ida_pre_get+0x113/0x250
[ 8812.397293]  [] ida_simple_get+0xa5/0x170
[ 8812.397298]  [] ? ida_pre_get+0x250/0x250
[ 8812.397306]  [] media_device_register_entity+0x171/0x420 
[media]
[ 8812.397318]  [] v4l2_device_register_subdev+0x34f/0x640 
[videodev]
[ 8812.397324]  [] v4l2_i2c_new_subdev_board+0x12a/0x250 
[v4l2_common]
[ 8812.397330]  [] v4l2_i2c_new_subdev+0xd7/0x110 
[v4l2_common]
[ 8812.397337]  [] ? v4l2_i2c_new_subdev_board+0x250/0x250 
[v4l2_common]
[ 8812.397347]  [] au0828_card_analog_fe_setup+0x2e6/0x3f0 
[au0828]
[ 8812.397352]  [] ? power_down+0xc4/0xc4
[ 8812.397361]  [] ? au0828_tuner_callback+0x160/0x160 
[au0828]
[ 8812.397370]  [] au0828_card_setup+0x11f/0x340 [au0828]
[ 8812.397378]  [] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 
[au0828]
[ 8812.397384]  [] ? msleep+0x7b/0xc0
[ 8812.397393]  [] au0828_usb_probe+0x679/0xcf0 [au0828]
[ 8812.397399]  [] usb_probe_interface+0x45d/0x940
[ 8812.397406]  [] driver_probe_device+0x454/0xd90
[ 8812.397411]  [] ? driver_probe_device+0xd90/0xd90
[ 8812.397417]  [] ? driver_probe_device+0xd90/0xd90
[ 8812.397422]  [] __driver_attach+0x121/0x160
[ 8812.397427]  [] bus_for_each_dev+0x11f/0x1a0
[ 8812.397433]  [] ? subsys_dev_iter_exit+0x10/0x10
[ 8812.397439]  [] ? _raw_spin_unlock+0x27/0x40
[ 8812.397445]  [] driver_attach+0x3d/0x50
[ 8812.397450]  [] bus_add_driver+0x4c9/0x770
[ 8812.397456]  [] driver_register+0x18c/0x3b0
[ 8812.397462]  [] ? __raw_spin_lock_init+0x32/0x100
[ 8812.397468]  [] usb_register_driver+0x1f8/0x440
[ 8812.397473]  [] ? 0xa0208000
[ 8812.397481]  [] au0828_init+0xb7/0x1000 [au0828]
[ 8812.397486]  [] do_one_initcall+0x141/0x300
[ 8812.397492]  [] ? try_to_run_init_process+0x40/0x40
[ 8812.397497]  [] ? trace_hardirqs_on_caller+0x16/0x590
[ 8812.397502]  [] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397507]  [] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397512]  [] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397517]  [] ? __asan_register_globals+0x87/0xa0
[ 8812.397524]  [] do_init_module+0x1d0/0x5a4
[ 8812.397530]  [] load_module+0x6648/0x9d70
[ 8812.397535]  [] ? symbol_put_addr+0x50/0x50
[ 8812.397546]  [] ? module_frob_arch_sections+0x20/0x20
[ 8812.397552]  [] ? open_exec+0x50/0x50
[ 8812.397559]  [] ? ns_capable+0x5b/0xd0
[ 8812.397565]  [] SyS_finit_module+0x108/0x130
[ 8812.397571]  [] ? SyS_init_module+0x1f0/0x1f0
[ 8812.397576]  [] ? lockdep_sys_exit_thunk+0x12/0x14
[ 8812.397582]  [] entry_SYSCALL_64_fastpath+0x16/0x7a

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/media-device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 3e0227555196..0ae58a17364b 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -554,7 +554,7 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
spin_lock(>lock);
 
entity->internal_idx = ida_simple_get(>entity_internal_idx, 1, 0,
- GFP_KERNEL);
+ GFP_ATOMIC);
if (entity->internal_idx < 0) {
spin_unlock(>lock);
return entity->internal_idx;
-- 
2.5.0

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

[PATCH 1/5] [media] move documentation to the header files

[Mauro Carvalho Chehab]

Some exported functions were still documented at the .c file,
instead of documenting at the .h one.

Move the documentation to the right place, as we only use headers
at media device-drivers.xml DocBook.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/media-device.c | 37 -
 drivers/media/media-entity.c | 13 -
 include/media/media-device.h |  6 ++
 include/media/media-entity.h | 18 --
 4 files changed, 22 insertions(+), 52 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 49dd41cd047f..3e0227555196 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -577,13 +577,6 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
 }
 EXPORT_SYMBOL_GPL(media_device_register_entity);
 
-/**
- * media_device_unregister_entity - Unregister an entity
- * @entity:The entity
- *
- * If the entity has never been registered this function will return
- * immediately.
- */
 static void __media_device_unregister_entity(struct media_entity *entity)
 {
struct media_device *mdev = entity->graph_obj.mdev;
@@ -627,17 +620,6 @@ void media_device_unregister_entity(struct media_entity 
*entity)
 }
 EXPORT_SYMBOL_GPL(media_device_unregister_entity);
 
-
-/**
- * media_device_init() - initialize a media device
- * @mdev:  The media device
- *
- * The caller is responsible for initializing the media device before
- * registration. The following fields must be set:
- *
- * - dev must point to the parent device
- * - model must be filled with the device model name
- */
 int __must_check media_device_init(struct media_device *mdev)
 {
if (WARN_ON(mdev->dev == NULL))
@@ -657,11 +639,6 @@ int __must_check media_device_init(struct media_device 
*mdev)
 }
 EXPORT_SYMBOL_GPL(media_device_init);
 
-/**
- * media_device_cleanup() - Cleanup a media device
- * @mdev:  The media device
- *
- */
 void media_device_cleanup(struct media_device *mdev)
 {
ida_destroy(>entity_internal_idx);
@@ -670,13 +647,6 @@ void media_device_cleanup(struct media_device *mdev)
 }
 EXPORT_SYMBOL_GPL(media_device_cleanup);
 
-/**
- * __media_device_register() - register a media device
- * @mdev:  The media device
- * @owner: The module owner
- *
- * returns zero on success or a negative error code.
- */
 int __must_check __media_device_register(struct media_device *mdev,
 struct module *owner)
 {
@@ -706,13 +676,6 @@ int __must_check __media_device_register(struct 
media_device *mdev,
 }
 EXPORT_SYMBOL_GPL(__media_device_register);
 
-/**
- * media_device_unregister - unregister a media device
- * @mdev:  The media device
- *
- * It is safe to call this function on an unregistered
- * (but initialised) media device.
- */
 void media_device_unregister(struct media_device *mdev)
 {
struct media_entity *entity;
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 32a5f8cae72d..a2d28162213e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -70,14 +70,6 @@ static inline const char *intf_type(struct media_interface 
*intf)
}
 };
 
-/**
- * __media_entity_enum_init - Initialise an entity enumeration
- *
- * @ent_enum: Entity enumeration to be initialised
- * @idx_max: Maximum number of entities in the enumeration
- *
- * Returns zero on success or a negative error code.
- */
 __must_check int __media_entity_enum_init(struct media_entity_enum *ent_enum,
  int idx_max)
 {
@@ -93,11 +85,6 @@ __must_check int __media_entity_enum_init(struct 
media_entity_enum *ent_enum,
 }
 EXPORT_SYMBOL_GPL(__media_entity_enum_init);
 
-/**
- * media_entity_enum_cleanup - Release resources of an entity enumeration
- *
- * @e: Entity enumeration to be released
- */
 void media_entity_enum_cleanup(struct media_entity_enum *ent_enum)
 {
kfree(ent_enum->bmap);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index ded71f60d193..4b900c9c5cdd 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -428,6 +428,8 @@ void media_device_cleanup(struct media_device *mdev);
  * a sysfs attribute.
  *
  * Unregistering a media device that hasn't been registered is *NOT* safe.
+ *
+ * Return: returns zero on success or a negative error code.
  */
 int __must_check __media_device_register(struct media_device *mdev,
 struct module *owner);
@@ -437,6 +439,10 @@ int __must_check __media_device_register(struct 
media_device *mdev,
  * __media_device_unregister() - Unegisters a media device element
  *
  * @mdev:  pointer to struct _device
+ *
+ *
+ * It is safe to call this function on an unregistered (but initialised)
+ * media device.
  */
 void media_device_unregister(struct media_device *mdev);
 
diff --git 

[PATCH 2/5] [media] DocBook: document media_entity_graph_walk_cleanup()

[Mauro Carvalho Chehab]

This function was added recently, but weren't documented.
Add documentation for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/media-entity.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c4aaeb85229c..f90ff56888d4 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -705,6 +705,12 @@ struct media_entity *media_entity_get(struct media_entity 
*entity);
 
 __must_check int media_entity_graph_walk_init(
struct media_entity_graph *graph, struct media_device *mdev);
+
+/**
+ * media_entity_graph_walk_cleanup - Release resources used by graph walk.
+ *
+ * @graph: Media graph structure that will be used to walk the graph
+ */
 void media_entity_graph_walk_cleanup(struct media_entity_graph *graph);
 
 /**
-- 
2.5.0

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

[PATCH 4/5] [media] au0828-core: fix compilation when !CONFIG_MEDIA_CONTROLLER

[Mauro Carvalho Chehab]

commit 1590ad7b52714 ("[media] media-device: split media initialization
and registration") moved the media controller register to a
separate function. That caused the following compilation issue,
if !CONFIG_MEDIA_CONTROLLER:

vim +445 drivers/media/usb/au0828/au0828-core.c

   439  if (retval) {
   440  pr_err("%s() au0282_dev_register failed to create 
graph\n",
   441 __func__);
   442  goto done;
   443  }
   444
 > 445  retval = media_device_register(dev->media_dev);
   446
   447  done:
   448  if (retval < 0)

Reported-by: kbuild test robot 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/au0828/au0828-core.c 
b/drivers/media/usb/au0828/au0828-core.c
index 2f91bbc633b4..101d32954fe8 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -458,7 +458,9 @@ static int au0828_usb_probe(struct usb_interface *interface,
goto done;
}
 
+#ifdef CONFIG_MEDIA_CONTROLLER
retval = media_device_register(dev->media_dev);
+#endif
 
 done:
if (retval < 0)
-- 
2.5.0

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

[PATCH 5/5] [media] media-device.h: use just one u64 counter for object ID

[Mauro Carvalho Chehab]

Instead of using one u32 counter per type for object IDs, use
just one counter, and move it to u64, in order to match the
changes at the userspace API.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/media-entity.c | 35 +++
 include/media/media-device.h | 10 ++
 include/media/media-entity.h | 27 +--
 3 files changed, 30 insertions(+), 42 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index a2d28162213e..d3160224db33 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -106,8 +106,8 @@ static void dev_dbg_obj(const char *event_name,  struct 
media_gobj *gobj)
switch (media_type(gobj)) {
case MEDIA_GRAPH_ENTITY:
dev_dbg(gobj->mdev->dev,
-   "%s: id 0x%08x entity#%d: '%s'\n",
-   event_name, gobj->id, media_localid(gobj),
+   "%s id %llu: entity '%s'\n",
+   event_name, media_id(gobj),
gobj_to_entity(gobj)->name);
break;
case MEDIA_GRAPH_LINK:
@@ -115,14 +115,12 @@ static void dev_dbg_obj(const char *event_name,  struct 
media_gobj *gobj)
struct media_link *link = gobj_to_link(gobj);
 
dev_dbg(gobj->mdev->dev,
-   "%s: id 0x%08x link#%d: %s#%d ==> %s#%d\n",
-   event_name, gobj->id, media_localid(gobj),
-
-   gobj_type(media_type(link->gobj0)),
-   media_localid(link->gobj0),
-
-   gobj_type(media_type(link->gobj1)),
-   media_localid(link->gobj1));
+   "%s id %llu: %s link id %llu ==> id %llu\n",
+   event_name, media_id(gobj),
+   media_type(link->gobj0) == MEDIA_GRAPH_PAD ?
+   "data" : "interface",
+   media_id(link->gobj0),
+   media_id(link->gobj1));
break;
}
case MEDIA_GRAPH_PAD:
@@ -130,11 +128,10 @@ static void dev_dbg_obj(const char *event_name,  struct 
media_gobj *gobj)
struct media_pad *pad = gobj_to_pad(gobj);
 
dev_dbg(gobj->mdev->dev,
-   "%s: id 0x%08x %s%spad#%d: '%s':%d\n",
-   event_name, gobj->id,
-   pad->flags & MEDIA_PAD_FL_SINK   ? "  sink " : "",
+   "%s id %llu: %s%spad '%s':%d\n",
+   event_name, media_id(gobj),
+   pad->flags & MEDIA_PAD_FL_SINK   ? "sink " : "",
pad->flags & MEDIA_PAD_FL_SOURCE ? "source " : "",
-   media_localid(gobj),
pad->entity->name, pad->index);
break;
}
@@ -144,8 +141,8 @@ static void dev_dbg_obj(const char *event_name,  struct 
media_gobj *gobj)
struct media_intf_devnode *devnode = intf_to_devnode(intf);
 
dev_dbg(gobj->mdev->dev,
-   "%s: id 0x%08x intf_devnode#%d: %s - major: %d, minor: 
%d\n",
-   event_name, gobj->id, media_localid(gobj),
+   "%s id %llu: intf_devnode %s - major: %d, minor: %d\n",
+   event_name, media_id(gobj),
intf_type(intf),
devnode->major, devnode->minor);
break;
@@ -163,21 +160,19 @@ void media_gobj_create(struct media_device *mdev,
gobj->mdev = mdev;
 
/* Create a per-type unique object ID */
+   gobj->id = media_gobj_gen_id(type, ++mdev->id);
+
switch (type) {
case MEDIA_GRAPH_ENTITY:
-   gobj->id = media_gobj_gen_id(type, ++mdev->entity_id);
list_add_tail(>list, >entities);
break;
case MEDIA_GRAPH_PAD:
-   gobj->id = media_gobj_gen_id(type, ++mdev->pad_id);
list_add_tail(>list, >pads);
break;
case MEDIA_GRAPH_LINK:
-   gobj->id = media_gobj_gen_id(type, ++mdev->link_id);
list_add_tail(>list, >links);
break;
case MEDIA_GRAPH_INTF_DEVNODE:
-   gobj->id = media_gobj_gen_id(type, ++mdev->intf_devnode_id);
list_add_tail(>list, >interfaces);
break;
}
diff --git a/include/media/media-device.h b/include/media/media-device.h
index aa8ec40c3a0e..b516c7b06e02 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -275,10 +275,7 @@ struct device;
  * @driver_version: Device driver version
  * @topology_version: Monotonic counter for storing the version of the graph
  * topology. Should be incremented each time the topology changes.
- * @entity_id: Unique ID used on the last entity registered
- * @pad_id:Unique ID used 

[PATCH 3/5] [media] media-entity.h fix documentation for several parameters

[Mauro Carvalho Chehab]

Several parameters added by the media_ent_enum patches
were declared with wrong argument names:
include/media/media-device.h:333: warning: No description found for 
parameter 'entity_internal_idx_max'
include/media/media-device.h:354: warning: No description found for 
parameter 'ent_enum'
include/media/media-device.h:354: warning: Excess function parameter 
'e' description in 'media_entity_enum_init'
include/media/media-device.h:333: warning: No description found for 
parameter 'entity_internal_idx_max'
include/media/media-device.h:354: warning: No description found for 
parameter 'ent_enum'
include/media/media-device.h:354: warning: Excess function parameter 
'e' description in 'media_entity_enum_init'
include/media/media-entity.h:397: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:397: warning: Excess function parameter 
'e' description in 'media_entity_enum_zero'
include/media/media-entity.h:409: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:409: warning: Excess function parameter 
'e' description in 'media_entity_enum_set'
include/media/media-entity.h:424: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:424: warning: Excess function parameter 
'e' description in 'media_entity_enum_clear'
include/media/media-entity.h:441: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:441: warning: Excess function parameter 
'e' description in 'media_entity_enum_test'
include/media/media-entity.h:458: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:458: warning: Excess function parameter 
'e' description in 'media_entity_enum_test_and_set'
include/media/media-entity.h:474: warning: No description found for 
parameter 'ent_enum'
include/media/media-entity.h:474: warning: Excess function parameter 
'e' description in 'media_entity_enum_empty'
include/media/media-entity.h:474: warning: Excess function parameter 
'entity' description in 'media_entity_enum_empty'
include/media/media-entity.h:489: warning: No description found for 
parameter 'ent_enum1'
include/media/media-entity.h:489: warning: No description found for 
parameter 'ent_enum2'
include/media/media-entity.h:489: warning: Excess function parameter 
'e' description in 'media_entity_enum_intersects'
include/media/media-entity.h:489: warning: Excess function parameter 
'f' description in 'media_entity_enum_intersects'

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/media-device.h |  6 --
 include/media/media-entity.h | 24 
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/include/media/media-device.h b/include/media/media-device.h
index 4b900c9c5cdd..aa8ec40c3a0e 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -279,7 +279,9 @@ struct device;
  * @pad_id:Unique ID used on the last pad registered
  * @link_id:   Unique ID used on the last link registered
  * @intf_devnode_id: Unique ID used on the last interface devnode registered
- * @entity_internal_idx: Allocated internal entity indices
+ * @entity_internal_idx: Unique internal entity ID used by the graph traversal
+ * algorithms
+ * @entity_internal_idx_max: Allocated internal entity indices
  * @entities:  List of registered entities
  * @interfaces:List of registered interfaces
  * @pads:  List of registered pads
@@ -344,7 +346,7 @@ struct media_device {
 /**
  * media_entity_enum_init - Initialise an entity enumeration
  *
- * @e: Entity enumeration to be initialised
+ * @ent_enum: Entity enumeration to be initialised
  * @mdev: The related media device
  *
  * Returns zero on success or a negative error code.
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index f90ff56888d4..855b47df6ed5 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -391,7 +391,7 @@ void media_entity_enum_cleanup(struct media_entity_enum 
*ent_enum);
 /**
  * media_entity_enum_zero - Clear the entire enum
  *
- * @e: Entity enumeration to be cleared
+ * @ent_enum: Entity enumeration to be cleared
  */
 static inline void media_entity_enum_zero(struct media_entity_enum *ent_enum)
 {
@@ -401,7 +401,7 @@ static inline void media_entity_enum_zero(struct 
media_entity_enum *ent_enum)
 /**
  * media_entity_enum_set - Mark a single entity in the enum
  *
- * @e: Entity enumeration
+ * @ent_enum: Entity enumeration
  * @entity: Entity to be marked
  */
 static inline void media_entity_enum_set(struct media_entity_enum *ent_enum,
@@ -416,7 +416,7 @@ static inline void media_entity_enum_set(struct 
media_entity_enum *ent_enum,
 /**
  * media_entity_enum_clear - Unmark a single 

Re: Media Controller patches

[Mauro Carvalho Chehab]

Em Sun, 13 Dec 2015 09:12:50 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 11 Dec 2015 19:05:22 -0200
> Mauro Carvalho Chehab  escreveu:
> 
> > Em Thu, 10 Dec 2015 18:34:11 -0200
> > Mauro Carvalho Chehab  escreveu:
> > 
> > > Hi,
> > > 
> > > I've been working during this week to address the issues pointed during
> > > the Media Controller really long review process. We should avoid taking
> > > so long to review patches in the future, as it is really painful to
> > > go back to the already done work 4/5/7 months after the patchsets
> > > (yes, there are patches here written 7 months ago that were only
> > > very recently reviewed!). Shame on us.
> > > 
> > > Anyway, The reviewed patches are now at the media-controller topic
> > > branch, at the main tree.
> > > 
> > > I took the care of recompiling and automatically doing runtime tests
> > > with KASAN enabled, patch by patch, in order to be sure that the
> > > MC is in a sane state. I also ran kmemleak, and was unable to identify
> > > any troubles associated with the MC next gen rework.
> > > 
> > > So, the media-controller topic branch looks sane to me. It should be
> > > noticed that there are several items on a TODO list to be addressed
> > > before being able to merge this branch back at the master branch.
> > > 
> > > Please notice that patch 22 was removed from this series:
> > >   Subject: [media] uapi/media.h: Declare interface types for ALSA
> > > 
> > > The idea is that this patch should be part of the patches that Shuah
> > > will submit and that requires review from the ALSA community before
> > > being merged.
> > > 
> > > Javier and me will start tomorrow on working on the pending items.
> > > 
> > > My goal is to have everything needed for Kernel 4.5 merge window
> > > done up to the next week.
> > > 
> > > ---
> > > 
> > > The current TODO list, based on the per-patch review is:
> > 
> > As far as I checked, all issues at the TODO for Kernel 4.5 were
> > already addressed, except for one item:
> > 
> > - Add documentation for the uAPI.
> 
> There are actually 3 other items that were not listed at the TODO:
> 
> - Merge of Sakari patches fixing media graph to work with entities
>   with ID > 64;

Done.

> 
> - Use just one counter for the graph ID range. This patch depends on
>   Sakari series;

Done.

> 
> - Merge of Javier patches that split media devnode register from the
>   media_device internal register. Not actually a requirement for
>   MC next gen, as it fixes an already existing race condition, but it
>   will allow almost for free to have topology_version = 0 as the
>   start version, with seems to be a good thing to drivers where the
>   topology is always static;

Done.

> 
> I reviewed both Sakari and Javier series this weekend with a few
> comments.
> 
> > 
> > I'll address this last item tomorrow.
> 
> Item addressed. I also sent some patches fixing some kernel-doc left overs.
> Now, there are only a few set of functions not documented at
> media-entity.h:
> 
> - the ones that will be touched by Sakari patches;
> - two ancillary functions that will be removed when we unify
>   the object ID numberspace.
> 
> I'll review those remaining items after merging Sakari's series.

Done.

As far as I know, all pending items for Kernel 4.5 merge are
complete. I should be moving the remaining patches from my
experimental tree:
git://linuxtv.org/mchehab/experimental.git media-controller-rc4

to the media-controller topic branch by the end of this week, if
nothing pops up.

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

[PATCH] [media] media-entity.h: document the remaining functions

[Mauro Carvalho Chehab]

There are two ancillary functions that are missing comments.

While those are used only internally at media-entity.c,
document them, for completeness.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/media-entity.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 73ab2bc6a1c9..db874439dcd6 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -301,11 +301,22 @@ static inline enum media_gobj_type media_type(struct 
media_gobj *gobj)
return gobj->id >> MEDIA_BITS_PER_ID;
 }
 
+/**
+ * media_id() - return the media object ID
+ *
+ * @gobj:  pointer to the media graph object
+ */
 static inline u64 media_id(struct media_gobj *gobj)
 {
return gobj->id & MEDIA_ID_MASK;
 }
 
+/**
+ * media_gobj_gen_id() - encapsulates type and ID on at the object ID
+ *
+ * @type:  object type as define at enum _gobj_type.
+ * @local_id:  next ID, from struct _device.@id.
+ */
 static inline u64 media_gobj_gen_id(enum media_gobj_type type, u64 local_id)
 {
u64 id;
-- 
2.5.0

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

Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Mauro Carvalho Chehab]

Em Wed, 16 Dec 2015 16:03:01 +0200
Sakari Ailus  escreveu:

> Hi Javier,
> 
> On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > This is the third version of the unrestricted media entity ID range
> > support set. I've taken Mauro's comments into account and fixed a number
> > of bugs as well (omap3isp memory leak and omap4iss stream start).

Patches merged on my experimental tree:

ssh://linuxtv.org/git/mchehab/experimental.git

branch media-controller-rc4

I had to do some rebase, as you were using some older changeset.
Also, several documentation tags were with troubles (renamed
vars not renamed there).

Next time, please check the documentation with:
make DOCBOOKS=device-drivers.xml htmldocs 2>&1

> Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> test the OMAP4 ISS with these patches?

As Sakari patches were rebased, it would be good to test them again
on omap3.

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

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Nicolas Dufresne]

Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit :
> > # [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
> > # [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
> > 
> > The video is stopped but I can see last frame on the screen although in 
> > qt application it should receive end-of-stream message and stop the 
> > video (resulting with black screen).
> 
> Looks like the coda driver is constantly fed empty buffers, which don't
> increase the bitstream payload level, and the PIC_RUN times out with a
> bitstream buffer underflow. What GStreamer version is this?

I believe this is side effect of how the MFC driver worked in it's
early stage. We had to keep pushing empty buffer to drain the driver.
So GStreamer still poll/queue/poll/queue/... until all capture buffers
are received. I notice recently that this behaviour can induce high CPU
load with some other drivers that don't do any active wait when a empty
buffer is queued. I would therefor suggest to change this code to only
push one empty buffer for your use case. An submitted patch to support
CMD_STOP can be found here, though is pending a re-submition by it's
author.

https://bugzilla.gnome.org/show_bug.cgi?id=733864

For proper EOS detection with CODA driver (using EPIPE return value),
you indeed need GStreamer 1.6+.

cheers,
Nicolas

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

[RFC/PATCH] v4l: vsp1: Configure device based on IP version

[Laurent Pinchart]

The IP version number carries enough information to identify the exact
device instance features. Drop the related DT properties and use the IP
version instead.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/media/renesas,vsp1.txt |  21 ---
 drivers/media/platform/vsp1/vsp1.h |   5 +-
 drivers/media/platform/vsp1/vsp1_bru.c |   2 +-
 drivers/media/platform/vsp1/vsp1_drm.c |   6 +-
 drivers/media/platform/vsp1/vsp1_drv.c | 173 -
 drivers/media/platform/vsp1/vsp1_entity.c  |   2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c|   6 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |   4 +-
 drivers/media/platform/vsp1/vsp1_sru.c |   4 +-
 drivers/media/platform/vsp1/vsp1_video.c   |   4 +-
 drivers/media/platform/vsp1/vsp1_wpf.c |   6 +-
 11 files changed, 116 insertions(+), 117 deletions(-)

This patch applies on top of the "[GIT PULL FOR v4.5] Renesas VSP1
improvements and fixes" pull request.

diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt 
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index fe74fb38e4d5..627405abd144 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -14,21 +14,6 @@ Required properties:
   - interrupts: VSP interrupt specifier.
   - clocks: A phandle + clock-specifier pair for the VSP functional clock.
 
-  - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP.
-  - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP.
-
-
-Optional properties:
-
-  - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP. Defaults
-to 0 if not present.
-  - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
-available.
-  - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
-available.
-  - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
-module is available.
-
 
 Example: R8A7790 (R-Car H2) VSP1-S node
 
@@ -37,10 +22,4 @@ Example: R8A7790 (R-Car H2) VSP1-S node
reg = <0 0xfe928000 0 0x8000>;
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_VSP1_S>;
-
-   renesas,has-lut;
-   renesas,has-sru;
-   renesas,#rpf = <5>;
-   renesas,#uds = <3>;
-   renesas,#wpf = <4>;
};
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 5b210b69f09c..910d6b8e8b50 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -47,7 +47,8 @@ struct vsp1_uds;
 #define VSP1_HAS_SRU   (1 << 2)
 #define VSP1_HAS_BRU   (1 << 3)
 
-struct vsp1_platform_data {
+struct vsp1_device_info {
+   u32 version;
unsigned int features;
unsigned int rpf_count;
unsigned int uds_count;
@@ -58,7 +59,7 @@ struct vsp1_platform_data {
 
 struct vsp1_device {
struct device *dev;
-   struct vsp1_platform_data pdata;
+   const struct vsp1_device_info *info;
 
void __iomem *mmio;
struct clk *clock;
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index 32e2009c215a..cb0dbc15ddad 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -416,7 +416,7 @@ struct vsp1_bru *vsp1_bru_create(struct vsp1_device *vsp1)
bru->entity.type = VSP1_ENTITY_BRU;
 
ret = vsp1_entity_init(vsp1, >entity,
-  vsp1->pdata.num_bru_inputs + 1);
+  vsp1->info->num_bru_inputs + 1);
if (ret < 0)
return ERR_PTR(ret);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 21ad0bb6d936..302d02a5c1c0 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -285,7 +285,7 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
rpf_index,
unsigned long flags;
int ret;
 
-   if (rpf_index >= vsp1->pdata.rpf_count)
+   if (rpf_index >= vsp1->info->rpf_count)
return -EINVAL;
 
rpf = vsp1->rpf[rpf_index];
@@ -519,7 +519,7 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (!vsp1->bru || !vsp1->lif)
return -ENXIO;
 
-   for (i = 0; i < vsp1->pdata.rpf_count; ++i) {
+   for (i = 0; i < vsp1->info->rpf_count; ++i) {
struct vsp1_rwpf *rpf = vsp1->rpf[i];
 
ret = media_entity_create_link(>entity.subdev.entity,
@@ -572,7 +572,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->frame_end = vsp1_drm_pipeline_frame_end;
 
/* The DRM pipeline is static, add entities manually. */

Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[tiffany lin]

On Wed, 2015-12-16 at 14:47 +0100, Hans Verkuil wrote:
> On 12/16/15 14:17, tiffany lin wrote:
> > Hi Hans,
> > 
> > 
> > On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
> >>
> >> On 12/15/15 14:51, tiffany lin wrote:
> >>> We are not familiar with v4l2-compliance utility, we will check how to
> >>> use it.
> >>
> >> It's part of v4l-utils.git (http://git.linuxtv.org/v4l-utils.git/). There 
> >> is a
> >> fairly decent man page. It does exhaustive compliance tests for V4L2 
> >> devices.
> >>
> >> That said, the support for memory-to-memory codec devices is not great, so 
> >> I wouldn't
> >> trust any failures it reports when using the streaming tests (i.e. the 
> >> --stream*
> >> options). By default just run 'v4l2-compliance -d /dev/videoX' to do the 
> >> compliance
> >> test.
> >>
> >> Note: before I accept this driver I do want to see that compliance test 
> >> output!
> >>
> > Got it. We will provide it in next version.
> > Now our driver is developed and run base on kernel v3.18.
> > V4L2 and vb2 have some difference between Linux 4.4-rc1 and 3.18 kernel.
> > Is it ok we provided test output base on v3.18 or we need to base on
> > 4.4-rc1?
> 
> I'm actually not sure if the latest v4l2-compliance test suite will work with 
> a 3.18
> kernel. so either you have to go back to an older version of v4l2-compliance 
> that
> works with 3.18 (go back to commit 4a57509a8334aca6ca8e81cd3beb08d5be397dac, 
> that
> might do the trick) or (and that's what I recommend) go with the latest 
> kernel.
> 
> For the media tree that is http://git.linuxtv.org/media_tree.git/log/.
> 
> The final version of the patch has to be against that kernel anyway.
> 
Got it. Thanks for your help, we will try it. ^_^

> > +}
> > +
> > +int m2mctx_venc_queue_init(void *priv, struct vb2_queue *src_vq,
> > +  struct vb2_queue *dst_vq)
> > +{
> > +   struct mtk_vcodec_ctx *ctx = priv;
> > +   int ret;
> > +
> > +   src_vq->type= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> > +   src_vq->io_modes= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> 
>  You're using videobuf2-dma-contig, so VB2_USERPTR is generally useless 
>  in that
>  case. I would drop it.
> 
> >>> Sorry, I don't get it. 
> >>> We are using videobuf2-dma-contig, but we also using VB2_USERPTR.
> >>
> >>  In that case the user pointer you pass in must point to physically 
> >> contiguous
> >> memory. Which means you got it through some magic. Typically what should 
> >> be used
> >> are dmabuf handles to pass buffers around between different subsystems.
> >>
> >> The use of VB2_USERPTR for that purpose is deprecated.
> >>
> >> Or am I misunderstanding you as well?
> >>
> > Our encoder support all three modes.
> > In case that A driver + Encode driver flow, OUTPUT buffer will be
> > VB2_DMABUF from A driver.
> > In case that read YCbCr frame data from file and encode them to bit
> > stream flow, we use VB2_USERPTR and VB2_MMAP.
> > In VB2_USERPTR case, videobuf2-dma-contig will help us get continuous
> > dma address.
> > Our chip has IOMMU and M4U that help us get continuous phy address for
> > encode HW.
> > 
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html
> 
> Ah, OK. Have you tested this with malloc()ed buffers? Just asking :-)
> 
Yes. Actually we tested this with new()ed buffers. I think it default
call malloc.

> Regards,
> 
>   Hans

best regards,
Tiffany

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

Re: [PATCH v2 07/22] media: Amend media graph walk API by init and cleanup functions

[Mauro Carvalho Chehab]

Em Sun, 29 Nov 2015 21:20:08 +0200
Sakari Ailus  escreveu:

> Add media_entity_graph_walk_init() and media_entity_graph_walk_cleanup()
> functions in order to dynamically allocate memory for the graph. This is
> not done in media_entity_graph_walk_start() as there are situations where
> e.g. correct error handling, that itself may not fail, requires successful
> graph walk.

Looks ok to me.


> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/media-entity.c | 39 ++-
>  include/media/media-entity.h |  5 -
>  2 files changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 667ab32..bf3c31f 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -353,14 +353,44 @@ static struct media_entity *stack_pop(struct 
> media_entity_graph *graph)
>  #define stack_top(en)((en)->stack[(en)->top].entity)
>  
>  /**
> + * media_entity_graph_walk_init - Allocate resources for graph walk
> + * @graph: Media graph structure that will be used to walk the graph
> + * @mdev: Media device
> + *
> + * Reserve resources for graph walk in media device's current
> + * state. The memory must be released using
> + * media_entity_graph_walk_free().
> + *
> + * Returns error on failure, zero on success.
> + */
> +__must_check int media_entity_graph_walk_init(
> + struct media_entity_graph *graph, struct media_device *mdev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(media_entity_graph_walk_init);
> +
> +/**
> + * media_entity_graph_walk_cleanup - Release resources related to graph 
> walking
> + * @graph: Media graph structure that was used to walk the graph
> + */
> +void media_entity_graph_walk_cleanup(struct media_entity_graph *graph)
> +{
> +}
> +EXPORT_SYMBOL_GPL(media_entity_graph_walk_cleanup);
> +
> +/**
>   * media_entity_graph_walk_start - Start walking the media graph at a given 
> entity
>   * @graph: Media graph structure that will be used to walk the graph
>   * @entity: Starting entity
>   *
> - * This function initializes the graph traversal structure to walk the 
> entities
> - * graph starting at the given entity. The traversal structure must not be
> - * modified by the caller during graph traversal. When done the structure can
> - * safely be freed.
> + * Before using this function, media_entity_graph_walk_init() must be
> + * used to allocate resources used for walking the graph. This
> + * function initializes the graph traversal structure to walk the
> + * entities graph starting at the given entity. The traversal
> + * structure must not be modified by the caller during graph
> + * traversal. After the graph walk, the resources must be released
> + * using media_entity_graph_walk_cleanup().
>   */
>  void media_entity_graph_walk_start(struct media_entity_graph *graph,
>  struct media_entity *entity)
> @@ -377,7 +407,6 @@ void media_entity_graph_walk_start(struct 
> media_entity_graph *graph,
>  }
>  EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
>  
> -
>  /**
>   * media_entity_graph_walk_next - Get the next entity in the graph
>   * @graph: Media graph structure
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 4b5ca39..f0652e2 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -506,8 +506,11 @@ struct media_pad *media_entity_remote_pad(struct 
> media_pad *pad);
>  struct media_entity *media_entity_get(struct media_entity *entity);
>  void media_entity_put(struct media_entity *entity);
>  
> +__must_check int media_entity_graph_walk_init(
> + struct media_entity_graph *graph, struct media_device *mdev);
> +void media_entity_graph_walk_cleanup(struct media_entity_graph *graph);
>  void media_entity_graph_walk_start(struct media_entity_graph *graph,
> - struct media_entity *entity);
> +struct media_entity *entity);
>  struct media_entity *
>  media_entity_graph_walk_next(struct media_entity_graph *graph);
>  __must_check int media_entity_pipeline_start(struct media_entity *entity,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media Controller patches

[Mauro Carvalho Chehab]

Em Wed, 16 Dec 2015 18:12:58 -0700
Shuah Khan  escreveu:

> On 12/16/2015 10:43 AM, Mauro Carvalho Chehab wrote:
> > Em Sun, 13 Dec 2015 09:12:50 -0200
> > Mauro Carvalho Chehab  escreveu:
> > 
> 
> > 
> > As far as I know, all pending items for Kernel 4.5 merge are
> > complete. I should be moving the remaining patches from my
> > experimental tree:
> > git://linuxtv.org/mchehab/experimental.git media-controller-rc4
> > 
> > to the media-controller topic branch by the end of this week, if
> > nothing pops up.
> 
> Hi Mauro,
> 
> I don't like the flat graph I am seeing on experimental rc4
> with all the pending patches for 4.5. I am attaching two
> media graphs generated on au0828 on rc3 and rc4. Something
> is off with rc4.  I used the latest mc_nextgen_test tool
> to generate the graphs.

I guess this problem is due to the patch changed the object ID 
to use a single number range:

http://git.linuxtv.org/mchehab/experimental.git/commit/?h=media-controller-rc4=9c04bcb45824fd8e5231f6f26269b57830c1f34d

We likely need to change the userspace tool due to that, but I'll
take a look on it tomorrow.

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

cron job: media_tree daily build: WARNINGS

[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:   Thu Dec 17 04:00:18 CET 2015
git branch: test
git hash:   52d60eb7e6d6429a766ea1b8f67e01c3b2dcd3c5
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3202-g618e15b
host hardware:  x86_64
host os:4.2.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: 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.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-rc1-i686: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Hans Verkuil]

On 12/16/15 14:17, tiffany lin wrote:
> Hi Hans,
> 
> 
> On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
>>
>> On 12/15/15 14:51, tiffany lin wrote:
>>> We are not familiar with v4l2-compliance utility, we will check how to
>>> use it.
>>
>> It's part of v4l-utils.git (http://git.linuxtv.org/v4l-utils.git/). There is 
>> a
>> fairly decent man page. It does exhaustive compliance tests for V4L2 devices.
>>
>> That said, the support for memory-to-memory codec devices is not great, so I 
>> wouldn't
>> trust any failures it reports when using the streaming tests (i.e. the 
>> --stream*
>> options). By default just run 'v4l2-compliance -d /dev/videoX' to do the 
>> compliance
>> test.
>>
>> Note: before I accept this driver I do want to see that compliance test 
>> output!
>>
> Got it. We will provide it in next version.
> Now our driver is developed and run base on kernel v3.18.
> V4L2 and vb2 have some difference between Linux 4.4-rc1 and 3.18 kernel.
> Is it ok we provided test output base on v3.18 or we need to base on
> 4.4-rc1?

I'm actually not sure if the latest v4l2-compliance test suite will work with a 
3.18
kernel. so either you have to go back to an older version of v4l2-compliance 
that
works with 3.18 (go back to commit 4a57509a8334aca6ca8e81cd3beb08d5be397dac, 
that
might do the trick) or (and that's what I recommend) go with the latest kernel.

For the media tree that is http://git.linuxtv.org/media_tree.git/log/.

The final version of the patch has to be against that kernel anyway.

> +}
> +
> +int m2mctx_venc_queue_init(void *priv, struct vb2_queue *src_vq,
> +struct vb2_queue *dst_vq)
> +{
> + struct mtk_vcodec_ctx *ctx = priv;
> + int ret;
> +
> + src_vq->type= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> + src_vq->io_modes= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;

 You're using videobuf2-dma-contig, so VB2_USERPTR is generally useless in 
 that
 case. I would drop it.

>>> Sorry, I don't get it. 
>>> We are using videobuf2-dma-contig, but we also using VB2_USERPTR.
>>
>>  In that case the user pointer you pass in must point to physically 
>> contiguous
>> memory. Which means you got it through some magic. Typically what should be 
>> used
>> are dmabuf handles to pass buffers around between different subsystems.
>>
>> The use of VB2_USERPTR for that purpose is deprecated.
>>
>> Or am I misunderstanding you as well?
>>
> Our encoder support all three modes.
> In case that A driver + Encode driver flow, OUTPUT buffer will be
> VB2_DMABUF from A driver.
> In case that read YCbCr frame data from file and encode them to bit
> stream flow, we use VB2_USERPTR and VB2_MMAP.
> In VB2_USERPTR case, videobuf2-dma-contig will help us get continuous
> dma address.
> Our chip has IOMMU and M4U that help us get continuous phy address for
> encode HW.
> 
> http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html

Ah, OK. Have you tested this with malloc()ed buffers? Just asking :-)

Regards,

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

problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Piotr Lewicki]

Hello,
I'm running an application that plays video on an embedded device. It 
uses Qt5.4 and qt-gstreamer plugin and it runs on imx6q processor with 
yocto based linux (kernel version 3.19.5).
When I built a sample from this qt-gstreamer package called qmlplayer2 
and used it to play video I came across following problem:


1. When video reaches it's end I start receiving kernel ringbuffer message:
# [ 1371.618854] coda 204.vpu: CODA PIC_RUN timeout
# [ 1372.618713] coda 204.vpu: CODA PIC_RUN timeout
# [ 1373.618653] coda 204.vpu: CODA PIC_RUN timeout
# [ 1374.618872] coda 204.vpu: CODA PIC_RUN timeout
# [ 1375.618712] coda 204.vpu: CODA PIC_RUN timeout
# [ 1376.618707] coda 204.vpu: CODA PIC_RUN timeout
# [ 1377.618860] coda 204.vpu: CODA PIC_RUN timeout
# [ 1378.738700] coda 204.vpu: CODA PIC_RUN timeout
# [ 1379.738632] coda 204.vpu: CODA PIC_RUN timeout
# [ 1380.828872] coda 204.vpu: CODA PIC_RUN timeout
# [ 1381.828697] coda 204.vpu: CODA PIC_RUN timeout
# [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
# [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout

The video is stopped but I can see last frame on the screen although in 
qt application it should receive end-of-stream message and stop the 
video (resulting with black screen).


2. If I don't terminate the application and several times press "stop" 
and "play" video I get message:


# [ 3041.650483] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3044.205362] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3044.214711] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3047.189317] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3047.196056] coda 204.vpu: dma_alloc_coherent of size 3133440 failed

and finally

# [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# "Failed to allocate required memory."

Video is not playing here and CODA PIC_RUN timeout message shows up 
every second.


- Depending on the type of video I'm playing the step 2 differs.
What I wrote above is true for playing matroska format (mkv) file.
When I use h264 I receive:

# [  322.610658] coda 204.vpu: Failed to allocate fb2 buffer of size 
537600

# [ 322.619083] coda 204.vpu: failed to allocate framebuffers

# [ 327.656542] coda 204.vpu: Failed to allocate fb0 buffer of size 
537600

# [ 327.663513] coda 204.vpu: failed to allocate framebuffers

Or

# [ 723.496813] coda 204.vpu: Failed to allocate workbuf buffer of 
size 606208

# [ 723.504122] coda 204.vpu: failed to allocate 0 byte context buffer

# [ 731.524607] coda 204.vpu: Failed to allocate slicebuf buffer of 
size 480512

# [ 731.532018] coda 204.vpu: failed to allocate 0 byte slice buffer

# [ 734.793931] coda 204.vpu: dma_alloc_coherent of size 462848 failed
# [ 734.800771] coda 204.vpu: dma_alloc_coherent of size 462848 failed
# "Failed to allocate required memory."

Or

# [ 2793.514984] coda 204.vpu: Failed to allocate fb0 buffer of size 
537600

# [ 2793.521961] coda 204.vpu: failed to allocate framebuffers
# [ 2793.596919] coda 204.vpu: failed to allocate bitstream ringbuffer

3. One more "stop" and "play" outputs with:
# [ 3050.530538] coda 204.vpu: failed to allocate bitstream ringbuffer

But here the video starts playing again and when it reaches the end- the 
end-of-stream message is received in the Qt application.


Ocasionally after playing many videos this way and shutting down the 
application I receive kernel oops or probable deadlock warning (both 
attached in this mail).




I'm pretty sure that the problem resides in the coda driver but 
unfortunately I'm newbie in kernel drivers development area and cannot 
resolve it myself.


Have you ever came across similar problem?
Do you think you could help me with that?

Best regards,
Piotr Lewicki


[ 1687.508917] ==
[ 1687.515103] [ INFO: possible circular locking dependency detected ]
[ 1687.521379] 3.19.5-iMX6-PD15.2.0 #1 Not tainted
[ 1687.525916] ---
[ 1687.532189] kworker/u8:2/74 is trying to acquire lock:
[ 1687.537333]  (>s_type->i_mutex_key){+.+.+.}, at: [<802748c8>] 
debugfs_remove+0x40/0x80
[ 1687.545691]
[ 1687.545691] but task is already holding lock:
[ 1687.551530]  (>coda_mutex){+.+.+.}, at: [<7f08903c>] 
coda_seq_end_work+0x38/0xf4 [coda]
[ 1687.560068]
[ 1687.560068] which lock already depends on the new lock.
[ 1687.560068]
[ 1687.568254]
[ 1687.568254] the existing dependency chain (in reverse order) is:
[ 1687.575742]
-> #3 (>coda_mutex){+.+.+.}:
[ 1687.580341][<806de3b8>] mutex_lock_nested+0x54/0x3e8
[ 1687.586037][<7f08b4cc>] coda_start_decoding+0x28/0x44 [coda]
[ 1687.592426][<7f08613c>] coda_start_streaming+0xac/0x20c [coda]
[ 1687.598981][<804dd6f4>] vb2_start_streaming+0x78/0x1c8
[ 1687.604840]  

[PATCH v3 04/23] media: Move struct media_entity_graph definition up

[Sakari Ailus]

It will be needed in struct media_pipeline shortly.

Signed-off-by: Sakari Ailus 
---
 include/media/media-entity.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 70803f7..4f789a4 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,6 +97,16 @@ struct media_entity_enum {
int idx_max;
 };
 
+struct media_entity_graph {
+   struct {
+   struct media_entity *entity;
+   struct list_head *link;
+   } stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
+
+   DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID);
+   int top;
+};
+
 struct media_pipeline {
 };
 
@@ -441,16 +451,6 @@ static inline bool media_entity_enum_intersects(
 min(ent_enum1->idx_max, ent_enum2->idx_max));
 }
 
-struct media_entity_graph {
-   struct {
-   struct media_entity *entity;
-   struct list_head *link;
-   } stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
-
-   DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID);
-   int top;
-};
-
 #define gobj_to_entity(gobj) \
container_of(gobj, struct media_entity, graph_obj)
 
-- 
2.1.4

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

[PATCH v3 13/23] media: Use entity enums in graph walk

[Sakari Ailus]

This will also mean that the necessary graph related data structures will
be allocated dynamically, removing the need for maximum ID checks.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 16 ++--
 include/media/media-entity.h |  4 ++--
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 2232cb3..2dd60d75 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -366,7 +366,7 @@ static struct media_entity *stack_pop(struct 
media_entity_graph *graph)
 __must_check int media_entity_graph_walk_init(
struct media_entity_graph *graph, struct media_device *mdev)
 {
-   return 0;
+   return media_entity_enum_init(>ent_enum, mdev);
 }
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_init);
 
@@ -376,6 +376,7 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_init);
  */
 void media_entity_graph_walk_cleanup(struct media_entity_graph *graph)
 {
+   media_entity_enum_cleanup(>ent_enum);
 }
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_cleanup);
 
@@ -395,14 +396,11 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_cleanup);
 void media_entity_graph_walk_start(struct media_entity_graph *graph,
   struct media_entity *entity)
 {
+   media_entity_enum_zero(>ent_enum);
+   media_entity_enum_set(>ent_enum, entity);
+
graph->top = 0;
graph->stack[graph->top].entity = NULL;
-   bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID);
-
-   if (WARN_ON(media_entity_id(entity) >= MEDIA_ENTITY_ENUM_MAX_ID))
-   return;
-
-   __set_bit(media_entity_id(entity), graph->entities);
stack_push(graph, entity);
 }
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
@@ -445,11 +443,9 @@ media_entity_graph_walk_next(struct media_entity_graph 
*graph)
 
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
-   if (WARN_ON(media_entity_id(next) >= MEDIA_ENTITY_ENUM_MAX_ID))
-   return NULL;
 
/* Has the entity already been visited? */
-   if (__test_and_set_bit(media_entity_id(next), graph->entities)) 
{
+   if (media_entity_enum_test_and_set(>ent_enum, next)) {
link_top(graph) = link_top(graph)->next;
continue;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index eaddcba..c29ddc2 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -103,7 +103,7 @@ struct media_entity_enum {
  * @stack: Graph traversal stack; the stack contains information
  * on the path the media entities to be walked and the
  * links through which they were reached.
- * @entities:  Visited entities
+ * @ent_enum:  Visited entities
  * @top:   The top of the stack
  */
 struct media_entity_graph {
@@ -112,7 +112,7 @@ struct media_entity_graph {
struct list_head *link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
 
-   DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID);
+   struct media_entity_enum ent_enum;
int top;
 };
 
-- 
2.1.4

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

[PATCH v3 17/23] staging: v4l: omap4iss: Fix sub-device power management code

[Sakari Ailus]

The same bug was present in the omap4iss driver as was in the omap3isp
driver. The code got copied to the omap4iss driver while broken. Fix the
omap4iss driver as well.

Signed-off-by: Sakari Ailus 
---
 drivers/staging/media/omap4iss/iss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index 076ddd4..c097fd5 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -533,14 +533,14 @@ static int iss_pipeline_link_notify(struct media_link 
*link, u32 flags,
int ret;
 
if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH &&
-   !(link->flags & MEDIA_LNK_FL_ENABLED)) {
+   !(flags & MEDIA_LNK_FL_ENABLED)) {
/* Powering off entities is assumed to never fail. */
iss_pipeline_pm_power(source, -sink_use);
iss_pipeline_pm_power(sink, -source_use);
return 0;
}
 
-   if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH &&
+   if (notification == MEDIA_DEV_NOTIFY_PRE_LINK_CH &&
(flags & MEDIA_LNK_FL_ENABLED)) {
ret = iss_pipeline_pm_power(source, sink_use);
if (ret < 0)
-- 
2.1.4

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

[PATCH v3 15/23] v4l: omap3isp: Use media entity enumeration interface

[Sakari Ailus]

From: Sakari Ailus 

Instead of using a bitmap directly in a driver, use the new media entity
enumeration interface to perform the same.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/isp.c  | 21 +
 drivers/media/platform/omap3isp/isp.h  |  5 +++--
 drivers/media/platform/omap3isp/ispccdc.c  |  2 +-
 drivers/media/platform/omap3isp/ispvideo.c | 20 ++--
 drivers/media/platform/omap3isp/ispvideo.h |  4 ++--
 5 files changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 4a01a36..939671d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -896,7 +896,7 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
 * starting entities if the pipeline won't start anyway (those entities
 * would then likely fail to stop, making the problem worse).
 */
-   if (pipe->entities & isp->crashed)
+   if (media_entity_enum_intersects(>ent_enum, >crashed))
return -EIO;
 
spin_lock_irqsave(>lock, flags);
@@ -989,7 +989,6 @@ static int isp_pipeline_disable(struct isp_pipeline *pipe)
struct v4l2_subdev *subdev;
int failure = 0;
int ret;
-   u32 id;
 
/*
 * We need to stop all the modules after CCDC first or they'll
@@ -1041,10 +1040,9 @@ static int isp_pipeline_disable(struct isp_pipeline 
*pipe)
if (ret) {
dev_info(isp->dev, "Unable to stop %s\n", subdev->name);
isp->stop_failure = true;
-   if (subdev == >isp_prev.subdev) {
-   id = media_entity_id(>entity);
-   isp->crashed |= 1U << id;
-   }
+   if (subdev == >isp_prev.subdev)
+   media_entity_enum_set(>crashed,
+ >entity);
failure = -ETIMEDOUT;
}
}
@@ -1250,7 +1248,7 @@ static int isp_reset(struct isp_device *isp)
}
 
isp->stop_failure = false;
-   isp->crashed = 0;
+   media_entity_enum_zero(>crashed);
return 0;
 }
 
@@ -1661,7 +1659,8 @@ static void __omap3isp_put(struct isp_device *isp, bool 
save_ctx)
/* Reset the ISP if an entity has failed to stop. This is the
 * only way to recover from such conditions.
 */
-   if (isp->crashed || isp->stop_failure)
+   if (!media_entity_enum_empty(>crashed) ||
+   isp->stop_failure)
isp_reset(isp);
isp_disable_clocks(isp);
}
@@ -2201,6 +2200,8 @@ static int isp_remove(struct platform_device *pdev)
isp_detach_iommu(isp);
__omap3isp_put(isp, false);
 
+   media_entity_enum_cleanup(>crashed);
+
return 0;
 }
 
@@ -2348,6 +2349,10 @@ static int isp_subdev_notifier_complete(struct 
v4l2_async_notifier *async)
struct isp_bus_cfg *bus;
int ret;
 
+   ret = media_entity_enum_init(>crashed, >media_dev);
+   if (ret)
+   return ret;
+
list_for_each_entry(sd, _dev->subdevs, list) {
/* Only try to link entities whose interface was set on bound */
if (sd->host_priv) {
diff --git a/drivers/media/platform/omap3isp/isp.h 
b/drivers/media/platform/omap3isp/isp.h
index b6f81f2..49b7f71 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -17,6 +17,7 @@
 #ifndef OMAP3_ISP_CORE_H
 #define OMAP3_ISP_CORE_H
 
+#include 
 #include 
 #include 
 #include 
@@ -152,7 +153,7 @@ struct isp_xclk {
  * @stat_lock: Spinlock for handling statistics
  * @isp_mutex: Mutex for serializing requests to ISP.
  * @stop_failure: Indicates that an entity failed to stop.
- * @crashed: Bitmask of crashed entities (indexed by entity ID)
+ * @crashed: Crashed ent_enum
  * @has_context: Context has been saved at least once and can be restored.
  * @ref_count: Reference count for handling multiple ISP requests.
  * @cam_ick: Pointer to camera interface clock structure.
@@ -195,7 +196,7 @@ struct isp_device {
spinlock_t stat_lock;   /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
bool stop_failure;
-   u32 crashed;
+   struct media_entity_enum crashed;
int has_context;
int ref_count;
unsigned int autoidle;
diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index f0e530c..80cf550 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1608,7 +1608,7 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)

[PATCH v3 23/23] media: Update media graph walk documentation for the changed API

[Sakari Ailus]

media_entity_graph_walk_init() and media_entity_graph_walk_cleanup() are
now mandatory.

Signed-off-by: Sakari Ailus 
---
 Documentation/media-framework.txt | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index b424de6..738a526 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -241,13 +241,22 @@ supported by the graph traversal API. To prevent infinite 
loops, the graph
 traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH,
 currently defined as 16.
 
-Drivers initiate a graph traversal by calling
+The graph traversal must be initialised calling
+
+   media_entity_graph_walk_init(struct media_entity_graph *graph);
+
+The return value of the function must be checked. Should the number of
+graph entities exceed the pre-allocated memory, it will also allocate
+memory for the enumeration.
+
+Once initialised, the graph walk may be started by calling
 
media_entity_graph_walk_start(struct media_entity_graph *graph,
  struct media_entity *entity);
 
-The graph structure, provided by the caller, is initialized to start graph
-traversal at the given entity.
+The graph structure, provided by the caller, is initialized to start
+graph traversal at the given entity. It is possible to start the graph
+walk multiple times using the same graph struct.
 
 Drivers can then retrieve the next entity by calling
 
@@ -255,8 +264,11 @@ Drivers can then retrieve the next entity by calling
 
 When the graph traversal is complete the function will return NULL.
 
-Graph traversal can be interrupted at any moment. No cleanup function call is
-required and the graph structure can be freed normally.
+Graph traversal can be interrupted at any moment. Once the graph
+structure is no longer needed, the resources that have been allocated
+by media_entity_graph_walk_init() are released using
+
+   media_entity_graph_walk_cleanup(struct media_entity_graph *graph);
 
 Helper functions can be used to find a link between two given pads, or a pad
 connected to another pad through an enabled link
-- 
2.1.4

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

[PATCH v3 19/23] staging: v4l: omap4iss: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
---
 drivers/staging/media/omap4iss/iss.c   | 59 +++---
 drivers/staging/media/omap4iss/iss.h   |  4 +-
 drivers/staging/media/omap4iss/iss_video.c | 33 +++--
 drivers/staging/media/omap4iss/iss_video.h |  1 +
 4 files changed, 70 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index 6738d01..d7eadc8 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -389,14 +389,14 @@ static irqreturn_t iss_isr(int irq, void *_iss)
  *
  * Return the total number of users of all video device nodes in the pipeline.
  */
-static int iss_pipeline_pm_use_count(struct media_entity *entity)
+static int iss_pipeline_pm_use_count(struct media_entity *entity,
+struct media_entity_graph *graph)
 {
-   struct media_entity_graph graph;
int use = 0;
 
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(graph, entity);
 
-   while ((entity = media_entity_graph_walk_next())) {
+   while ((entity = media_entity_graph_walk_next(graph))) {
if (is_media_entity_v4l2_io(entity))
use += entity->use_count;
}
@@ -449,27 +449,27 @@ static int iss_pipeline_pm_power_one(struct media_entity 
*entity, int change)
  *
  * Return 0 on success or a negative error code on failure.
  */
-static int iss_pipeline_pm_power(struct media_entity *entity, int change)
+static int iss_pipeline_pm_power(struct media_entity *entity, int change,
+struct media_entity_graph *graph)
 {
-   struct media_entity_graph graph;
struct media_entity *first = entity;
int ret = 0;
 
if (!change)
return 0;
 
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(graph, entity);
 
-   while (!ret && (entity = media_entity_graph_walk_next()))
+   while (!ret && (entity = media_entity_graph_walk_next(graph)))
if (is_media_entity_v4l2_subdev(entity))
ret = iss_pipeline_pm_power_one(entity, change);
 
if (!ret)
return 0;
 
-   media_entity_graph_walk_start(, first);
+   media_entity_graph_walk_start(graph, first);
 
-   while ((first = media_entity_graph_walk_next())
+   while ((first = media_entity_graph_walk_next(graph))
   && first != entity)
if (is_media_entity_v4l2_subdev(first))
iss_pipeline_pm_power_one(first, -change);
@@ -489,7 +489,8 @@ static int iss_pipeline_pm_power(struct media_entity 
*entity, int change)
  * off is assumed to never fail. No failure can occur when the use parameter is
  * set to 0.
  */
-int omap4iss_pipeline_pm_use(struct media_entity *entity, int use)
+int omap4iss_pipeline_pm_use(struct media_entity *entity, int use,
+struct media_entity_graph *graph)
 {
int change = use ? 1 : -1;
int ret;
@@ -501,7 +502,7 @@ int omap4iss_pipeline_pm_use(struct media_entity *entity, 
int use)
WARN_ON(entity->use_count < 0);
 
/* Apply power change to connected non-nodes. */
-   ret = iss_pipeline_pm_power(entity, change);
+   ret = iss_pipeline_pm_power(entity, change, graph);
if (ret < 0)
entity->use_count -= change;
 
@@ -526,34 +527,48 @@ int omap4iss_pipeline_pm_use(struct media_entity *entity, 
int use)
 static int iss_pipeline_link_notify(struct media_link *link, u32 flags,
unsigned int notification)
 {
+   struct media_entity_graph *graph =
+   _of(link->graph_obj.mdev, struct iss_device,
+ media_dev)->pm_count_graph;
struct media_entity *source = link->source->entity;
struct media_entity *sink = link->sink->entity;
-   int source_use = iss_pipeline_pm_use_count(source);
-   int sink_use = iss_pipeline_pm_use_count(sink);
+   int source_use;
+   int sink_use;
int ret;
 
+   if (notification == MEDIA_DEV_NOTIFY_PRE_LINK_CH) {
+   ret = media_entity_graph_walk_init(graph,
+  link->graph_obj.mdev);
+   if (ret)
+   return ret;
+   }
+
+   source_use = iss_pipeline_pm_use_count(source, graph);
+   sink_use = iss_pipeline_pm_use_count(sink, graph);
+
if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH &&
!(flags & MEDIA_LNK_FL_ENABLED)) {
/* Powering off entities is assumed to never fail. */
-   iss_pipeline_pm_power(source, -sink_use);
-   iss_pipeline_pm_power(sink, 

[PATCH v3 05/23] media: Add KernelDoc documentation for struct media_entity_graph

[Sakari Ailus]

KernelDoc doesn't appear to handle anonymous structs defined inside
another gracefully. As the struct is internal to the framework graph walk
algorithm, detailed documentation isn't seen very important.

Signed-off-by: Sakari Ailus 
---
 include/media/media-entity.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 4f789a4..3068c30 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,6 +97,15 @@ struct media_entity_enum {
int idx_max;
 };
 
+/**
+ * struct media_entity_graph - Media graph traversal state
+ *
+ * @stack: Graph traversal stack; the stack contains information
+ * on the path the media entities to be walked and the
+ * links through which they were reached.
+ * @entities:  Visited entities
+ * @top:   The top of the stack
+ */
 struct media_entity_graph {
struct {
struct media_entity *entity;
-- 
2.1.4

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

[PATCH v3 07/23] media: Amend media graph walk API by init and cleanup functions

[Sakari Ailus]

Add media_entity_graph_walk_init() and media_entity_graph_walk_cleanup()
functions in order to dynamically allocate memory for the graph. This is
not done in media_entity_graph_walk_start() as there are situations where
e.g. correct error handling, that itself may not fail, requires successful
graph walk.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 39 ++-
 include/media/media-entity.h |  5 -
 2 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 786a01f..d63204e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -353,14 +353,44 @@ static struct media_entity *stack_pop(struct 
media_entity_graph *graph)
 #define stack_top(en)  ((en)->stack[(en)->top].entity)
 
 /**
+ * media_entity_graph_walk_init - Allocate resources for graph walk
+ * @graph: Media graph structure that will be used to walk the graph
+ * @mdev: Media device
+ *
+ * Reserve resources for graph walk in media device's current
+ * state. The memory must be released using
+ * media_entity_graph_walk_free().
+ *
+ * Returns error on failure, zero on success.
+ */
+__must_check int media_entity_graph_walk_init(
+   struct media_entity_graph *graph, struct media_device *mdev)
+{
+   return 0;
+}
+EXPORT_SYMBOL_GPL(media_entity_graph_walk_init);
+
+/**
+ * media_entity_graph_walk_cleanup - Release resources related to graph walking
+ * @graph: Media graph structure that was used to walk the graph
+ */
+void media_entity_graph_walk_cleanup(struct media_entity_graph *graph)
+{
+}
+EXPORT_SYMBOL_GPL(media_entity_graph_walk_cleanup);
+
+/**
  * media_entity_graph_walk_start - Start walking the media graph at a given 
entity
  * @graph: Media graph structure that will be used to walk the graph
  * @entity: Starting entity
  *
- * This function initializes the graph traversal structure to walk the entities
- * graph starting at the given entity. The traversal structure must not be
- * modified by the caller during graph traversal. When done the structure can
- * safely be freed.
+ * Before using this function, media_entity_graph_walk_init() must be
+ * used to allocate resources used for walking the graph. This
+ * function initializes the graph traversal structure to walk the
+ * entities graph starting at the given entity. The traversal
+ * structure must not be modified by the caller during graph
+ * traversal. After the graph walk, the resources must be released
+ * using media_entity_graph_walk_cleanup().
  */
 void media_entity_graph_walk_start(struct media_entity_graph *graph,
   struct media_entity *entity)
@@ -377,7 +407,6 @@ void media_entity_graph_walk_start(struct 
media_entity_graph *graph,
 }
 EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
 
-
 /**
  * media_entity_graph_walk_next - Get the next entity in the graph
  * @graph: Media graph structure
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 9315158..eaddcba 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -511,8 +511,11 @@ struct media_pad *media_entity_remote_pad(struct media_pad 
*pad);
 struct media_entity *media_entity_get(struct media_entity *entity);
 void media_entity_put(struct media_entity *entity);
 
+__must_check int media_entity_graph_walk_init(
+   struct media_entity_graph *graph, struct media_device *mdev);
+void media_entity_graph_walk_cleanup(struct media_entity_graph *graph);
 void media_entity_graph_walk_start(struct media_entity_graph *graph,
-   struct media_entity *entity);
+  struct media_entity *entity);
 struct media_entity *
 media_entity_graph_walk_next(struct media_entity_graph *graph);
 __must_check int media_entity_pipeline_start(struct media_entity *entity,
-- 
2.1.4

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

[PATCH v3 12/23] v4l: vsp1: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/vsp1/vsp1_video.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index f741582..ce10d86 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -415,6 +415,12 @@ static int vsp1_pipeline_validate(struct vsp1_pipeline 
*pipe,
mutex_lock(>graph_mutex);
 
/* Walk the graph to locate the entities and video nodes. */
+   ret = media_entity_graph_walk_init(, mdev);
+   if (ret) {
+   mutex_unlock(>graph_mutex);
+   return ret;
+   }
+
media_entity_graph_walk_start(, entity);
 
while ((entity = media_entity_graph_walk_next())) {
@@ -448,6 +454,8 @@ static int vsp1_pipeline_validate(struct vsp1_pipeline 
*pipe,
 
mutex_unlock(>graph_mutex);
 
+   media_entity_graph_walk_cleanup();
+
/* We need one output and at least one input. */
if (pipe->num_inputs == 0 || !pipe->output) {
ret = -EPIPE;
-- 
2.1.4

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

[PATCH v3 14/23] media: Keep using the same graph walk object for a given pipeline

[Sakari Ailus]

Initialise a given graph walk object once, and then keep using it whilst
the same pipeline is running. Once the pipeline is stopped, release the
graph walk object.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 17 +++--
 include/media/media-entity.h |  4 +++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 2dd60d75..ddf3c23 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -488,10 +488,10 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
 
mutex_lock(>graph_mutex);
 
-   ret = media_entity_graph_walk_init(>graph, mdev);
-   if (ret) {
-   mutex_unlock(>graph_mutex);
-   return ret;
+   if (!pipe->streaming_count++) {
+   ret = media_entity_graph_walk_init(>graph, mdev);
+   if (ret)
+   goto error_graph_walk_start;
}
 
media_entity_graph_walk_start(>graph, entity);
@@ -592,7 +592,9 @@ error:
break;
}
 
-   media_entity_graph_walk_cleanup(graph);
+error_graph_walk_start:
+   if (!--pipe->streaming_count)
+   media_entity_graph_walk_cleanup(graph);
 
mutex_unlock(>graph_mutex);
 
@@ -616,9 +618,11 @@ void media_entity_pipeline_stop(struct media_entity 
*entity)
 {
struct media_device *mdev = entity->graph_obj.mdev;
struct media_entity_graph *graph = >pipe->graph;
+   struct media_pipeline *pipe = entity->pipe;
 
mutex_lock(>graph_mutex);
 
+   WARN_ON(!pipe->streaming_count);
media_entity_graph_walk_start(graph, entity);
 
while ((entity = media_entity_graph_walk_next(graph))) {
@@ -627,7 +631,8 @@ void media_entity_pipeline_stop(struct media_entity *entity)
entity->pipe = NULL;
}
 
-   media_entity_graph_walk_cleanup(graph);
+   if (!--pipe->streaming_count)
+   media_entity_graph_walk_cleanup(graph);
 
mutex_unlock(>graph_mutex);
 }
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c29ddc2..251eddf 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -119,9 +119,11 @@ struct media_entity_graph {
 /*
  * struct media_pipeline - Media pipeline related information
  *
- * @graph: Media graph walk during pipeline start / stop
+ * @streaming_count:   Streaming start count - streaming stop count
+ * @graph: Media graph walk during pipeline start / stop
  */
 struct media_pipeline {
+   int streaming_count;
struct media_entity_graph graph;
 };
 
-- 
2.1.4

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

[PATCH v3 22/23] media: Move MEDIA_ENTITY_MAX_PADS from media-entity.h to media-entity.c

[Sakari Ailus]

This isn't really a part of any interface drivers are expected to use. In
order to keep drivers from using it, hide it in media-entity.c. This was
always an arbitrary number and should be removed in the long run.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 5 +
 include/media/media-entity.h | 7 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index c799a4e..2e4ffaf 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -245,6 +245,11 @@ void media_entity_enum_cleanup(struct media_entity_enum 
*ent_enum)
 }
 EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
 
+/*
+ * TODO: Get rid of this.
+ */
+#define MEDIA_ENTITY_MAX_PADS  63
+
 /**
  * media_entity_init - Initialize a media entity
  *
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 034b9d7..d2d668a 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -73,13 +73,6 @@ struct media_gobj {
 
 #define MEDIA_ENTITY_ENUM_MAX_DEPTH16
 
-/*
- * The number of pads can't be bigger than the number of entities,
- * as the worse-case scenario is to have one entity linked up to
- * 63 entities.
- */
-#define MEDIA_ENTITY_MAX_PADS  63
-
 /**
  * struct media_entity_enum - An enumeration of media entities.
  *
-- 
2.1.4

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

[PATCH v3 16/23] v4l: vsp1: Use media entity enumeration interface

[Sakari Ailus]

From: Sakari Ailus 

Instead of using a bitmap directly in a driver, use the new media entity
enumeration interface to perform the same.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/vsp1/vsp1_video.c | 45 ++--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index ce10d86..58e6429 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -311,24 +311,35 @@ static int vsp1_pipeline_validate_branch(struct 
vsp1_pipeline *pipe,
 struct vsp1_rwpf *output)
 {
struct vsp1_entity *entity;
-   unsigned int entities = 0;
+   struct media_entity_enum ent_enum;
struct media_pad *pad;
+   int rval;
bool bru_found = false;
 
input->location.left = 0;
input->location.top = 0;
 
+   rval = media_entity_enum_init(
+   _enum, input->entity.pads[RWPF_PAD_SOURCE].graph_obj.mdev);
+   if (rval)
+   return rval;
+
pad = media_entity_remote_pad(>entity.pads[RWPF_PAD_SOURCE]);
 
while (1) {
-   if (pad == NULL)
-   return -EPIPE;
+   if (pad == NULL) {
+   rval = -EPIPE;
+   goto out;
+   }
 
/* We've reached a video node, that shouldn't have happened. */
-   if (!is_media_entity_v4l2_subdev(pad->entity))
-   return -EPIPE;
+   if (!is_media_entity_v4l2_subdev(pad->entity)) {
+   rval = -EPIPE;
+   goto out;
+   }
 
-   entity = 
to_vsp1_entity(media_entity_to_v4l2_subdev(pad->entity));
+   entity = to_vsp1_entity(
+   media_entity_to_v4l2_subdev(pad->entity));
 
/* A BRU is present in the pipeline, store the compose rectangle
 * location in the input RPF for use when configuring the RPF.
@@ -351,15 +362,18 @@ static int vsp1_pipeline_validate_branch(struct 
vsp1_pipeline *pipe,
break;
 
/* Ensure the branch has no loop. */
-   if (entities & (1 << media_entity_id(>subdev.entity)))
-   return -EPIPE;
-
-   entities |= 1 << media_entity_id(>subdev.entity);
+   if (media_entity_enum_test_and_set(_enum,
+  >subdev.entity)) {
+   rval = -EPIPE;
+   goto out;
+   }
 
/* UDS can't be chained. */
if (entity->type == VSP1_ENTITY_UDS) {
-   if (pipe->uds)
-   return -EPIPE;
+   if (pipe->uds) {
+   rval = -EPIPE;
+   goto out;
+   }
 
pipe->uds = entity;
pipe->uds_input = bru_found ? pipe->bru
@@ -377,9 +391,12 @@ static int vsp1_pipeline_validate_branch(struct 
vsp1_pipeline *pipe,
 
/* The last entity must be the output WPF. */
if (entity != >entity)
-   return -EPIPE;
+   rval = -EPIPE;
 
-   return 0;
+out:
+   media_entity_enum_cleanup(_enum);
+
+   return rval;
 }
 
 static void __vsp1_pipeline_cleanup(struct vsp1_pipeline *pipe)
-- 
2.1.4

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

[PATCH v3 02/23] media: Introduce internal index for media entities

[Sakari Ailus]

From: Sakari Ailus 

The internal index can be used internally by the framework in order to keep
track of entities for a purpose or another. The internal index is constant
while it's registered to a media device, but the same index may be re-used
once the entity having that index is unregistered.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 17 +
 include/media/media-device.h |  4 
 include/media/media-entity.h |  3 +++
 3 files changed, 24 insertions(+)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index c181758..ebb84cb 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -546,6 +547,7 @@ void media_device_init(struct media_device *mdev)
INIT_LIST_HEAD(>links);
spin_lock_init(>lock);
mutex_init(>graph_mutex);
+   ida_init(>entity_internal_idx);
 
dev_dbg(mdev->dev, "Media device initialized\n");
 }
@@ -558,6 +560,8 @@ EXPORT_SYMBOL_GPL(media_device_init);
  */
 void media_device_cleanup(struct media_device *mdev)
 {
+   ida_destroy(>entity_internal_idx);
+   mdev->entity_internal_idx_max = 0;
mutex_destroy(>graph_mutex);
 }
 EXPORT_SYMBOL_GPL(media_device_cleanup);
@@ -658,6 +662,17 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
INIT_LIST_HEAD(>links);
 
spin_lock(>lock);
+
+   entity->internal_idx = ida_simple_get(>entity_internal_idx, 1, 0,
+ GFP_KERNEL);
+   if (entity->internal_idx < 0) {
+   spin_unlock(>lock);
+   return entity->internal_idx;
+   }
+
+   mdev->entity_internal_idx_max =
+   max(mdev->entity_internal_idx_max, entity->internal_idx);
+
/* Initialize media_gobj embedded at the entity */
media_gobj_init(mdev, MEDIA_GRAPH_ENTITY, >graph_obj);
 
@@ -690,6 +705,8 @@ void media_device_unregister_entity(struct media_entity 
*entity)
 
spin_lock(>lock);
 
+   ida_simple_remove(>entity_internal_idx, entity->internal_idx);
+
/* Remove interface links with this entity on it */
list_for_each_entry_safe(link, tmp, >links, graph_obj.list) {
if (media_type(link->gobj1) == MEDIA_GRAPH_ENTITY
diff --git a/include/media/media-device.h b/include/media/media-device.h
index a2c7570..c0e1764 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 
+struct ida;
 struct device;
 
 /**
@@ -47,6 +48,7 @@ struct device;
  * @pad_id:Unique ID used on the last pad registered
  * @link_id:   Unique ID used on the last link registered
  * @intf_devnode_id: Unique ID used on the last interface devnode registered
+ * @entity_internal_idx: Allocated internal entity indices
  * @entities:  List of registered entities
  * @interfaces:List of registered interfaces
  * @pads:  List of registered pads
@@ -82,6 +84,8 @@ struct media_device {
u32 pad_id;
u32 link_id;
u32 intf_devnode_id;
+   struct ida entity_internal_idx;
+   int entity_internal_idx_max;
 
struct list_head entities;
struct list_head interfaces;
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index eebdd24..d3d3a39 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -159,6 +159,8 @@ struct media_entity_operations {
  * @num_pads:  Number of sink and source pads.
  * @num_links: Number of existing links, both enabled and disabled.
  * @num_backlinks: Number of backlinks
+ * @internal_idx: An unique internal entity specific number. The numbers are
+ * re-used if entities are unregistered or registered again.
  * @pads:  Pads array with the size defined by @num_pads.
  * @links: Linked list for the data links.
  * @ops:   Entity operations.
@@ -187,6 +189,7 @@ struct media_entity {
u16 num_pads;
u16 num_links;
u16 num_backlinks;
+   int internal_idx;
 
struct media_pad *pads;
struct list_head links;
-- 
2.1.4

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

[PATCH v3 18/23] staging: v4l: omap4iss: Use media entity enumeration interface

[Sakari Ailus]

From: Sakari Ailus 

Instead of using a bitmap directly in a driver, use the new media
entity enumeration interface to perform the same.

Signed-off-by: Sakari Ailus 
---
 drivers/staging/media/omap4iss/iss.c   | 15 +++
 drivers/staging/media/omap4iss/iss.h   |  4 ++--
 drivers/staging/media/omap4iss/iss_video.c | 23 ---
 drivers/staging/media/omap4iss/iss_video.h |  4 ++--
 4 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index c097fd5..6738d01 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -606,7 +606,7 @@ static int iss_pipeline_disable(struct iss_pipeline *pipe,
 * crashed. Mark it as such, the ISS will be reset when
 * applications will release it.
 */
-   iss->crashed |= 1U << media_entity_id(>entity);
+   media_entity_enum_set(>crashed, >entity);
failure = -ETIMEDOUT;
}
}
@@ -641,7 +641,7 @@ static int iss_pipeline_enable(struct iss_pipeline *pipe,
 * pipeline won't start anyway (those entities would then likely fail to
 * stop, making the problem worse).
 */
-   if (pipe->entities & iss->crashed)
+   if (media_entity_enum_intersects(>ent_enum, >crashed))
return -EIO;
 
spin_lock_irqsave(>lock, flags);
@@ -761,7 +761,8 @@ static int iss_reset(struct iss_device *iss)
return -ETIMEDOUT;
}
 
-   iss->crashed = 0;
+   media_entity_enum_zero(>crashed);
+
return 0;
 }
 
@@ -1090,7 +1091,7 @@ void omap4iss_put(struct iss_device *iss)
 * be worth investigating whether resetting the ISP only can't
 * fix the problem in some cases.
 */
-   if (iss->crashed)
+   if (!media_entity_enum_empty(>crashed))
iss_reset(iss);
iss_disable_clocks(iss);
}
@@ -1490,6 +1491,10 @@ static int iss_probe(struct platform_device *pdev)
if (ret < 0)
goto error_modules;
 
+   ret = media_entity_enum_init(>crashed, >media_dev);
+   if (ret)
+   goto error_entities;
+
ret = iss_create_pads_links(iss);
if (ret < 0)
goto error_entities;
@@ -1500,6 +1505,7 @@ static int iss_probe(struct platform_device *pdev)
 
 error_entities:
iss_unregister_entities(iss);
+   media_entity_enum_cleanup(>crashed);
 error_modules:
iss_cleanup_modules(iss);
 error_iss:
@@ -1517,6 +1523,7 @@ static int iss_remove(struct platform_device *pdev)
struct iss_device *iss = platform_get_drvdata(pdev);
 
iss_unregister_entities(iss);
+   media_entity_enum_cleanup(>crashed);
iss_cleanup_modules(iss);
 
return 0;
diff --git a/drivers/staging/media/omap4iss/iss.h 
b/drivers/staging/media/omap4iss/iss.h
index 35df8b4..5dd0d99 100644
--- a/drivers/staging/media/omap4iss/iss.h
+++ b/drivers/staging/media/omap4iss/iss.h
@@ -82,7 +82,7 @@ struct iss_reg {
 /*
  * struct iss_device - ISS device structure.
  * @syscon: Regmap for the syscon register space
- * @crashed: Bitmask of crashed entities (indexed by entity ID)
+ * @crashed: Crashed entities
  */
 struct iss_device {
struct v4l2_device v4l2_dev;
@@ -101,7 +101,7 @@ struct iss_device {
u64 raw_dmamask;
 
struct mutex iss_mutex; /* For handling ref_count field */
-   unsigned int crashed;
+   struct media_entity_enum crashed;
int has_context;
int ref_count;
 
diff --git a/drivers/staging/media/omap4iss/iss_video.c 
b/drivers/staging/media/omap4iss/iss_video.c
index cbe5783..4fd5fc8 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -751,7 +751,7 @@ iss_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct iss_video_fh *vfh = to_iss_video_fh(fh);
struct iss_video *video = video_drvdata(file);
struct media_entity_graph graph;
-   struct media_entity *entity;
+   struct media_entity *entity = >video.entity;
enum iss_pipeline_state state;
struct iss_pipeline *pipe;
struct iss_video *far_end;
@@ -766,24 +766,26 @@ iss_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
/* Start streaming on the pipeline. No link touching an entity in the
 * pipeline can be activated or deactivated once streaming is started.
 */
-   pipe = video->video.entity.pipe
-? to_iss_pipeline(>video.entity) : >pipe;
+   pipe = entity->pipe
+? to_iss_pipeline(entity) : >pipe;
pipe->external = NULL;
pipe->external_rate = 0;

[PATCH v3 03/23] media: Add an API to manage entity enumerations

[Sakari Ailus]

From: Sakari Ailus 

This is useful in e.g. knowing whether certain operations have already
been performed for an entity. The users include the framework itself (for
graph walking) and a number of drivers.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c |  39 
 include/media/media-device.h |  15 +
 include/media/media-entity.h | 140 ---
 3 files changed, 186 insertions(+), 8 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d11f440..67eebcb 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -213,6 +213,45 @@ void media_gobj_remove(struct media_gobj *gobj)
 }
 
 /**
+ * __media_entity_enum_init - Initialise an entity enumeration
+ *
+ * @ent_enum: Entity enumeration to be initialised
+ * @idx_max: Maximum number of entities in the enumeration
+ *
+ * Returns zero on success or a negative error code.
+ */
+int __media_entity_enum_init(struct media_entity_enum *ent_enum, int idx_max)
+{
+   if (idx_max > MEDIA_ENTITY_ENUM_MAX_ID) {
+   ent_enum->bmap = kcalloc(DIV_ROUND_UP(idx_max, BITS_PER_LONG),
+sizeof(long), GFP_KERNEL);
+   if (!ent_enum->bmap)
+   return -ENOMEM;
+   } else {
+   ent_enum->bmap = ent_enum->prealloc_bmap;
+   }
+
+   bitmap_zero(ent_enum->bmap, idx_max);
+   ent_enum->idx_max = idx_max;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__media_entity_enum_init);
+
+/**
+ * media_entity_enum_cleanup - Release resources of an entity enumeration
+ *
+ * @e: Entity enumeration to be released
+ */
+void media_entity_enum_cleanup(struct media_entity_enum *ent_enum)
+{
+   if (ent_enum->bmap != ent_enum->prealloc_bmap)
+   kfree(ent_enum->bmap);
+   ent_enum->bmap = NULL;
+}
+EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
+
+/**
  * media_entity_init - Initialize a media entity
  *
  * @num_pads: Total number of sink and source pads.
diff --git a/include/media/media-device.h b/include/media/media-device.h
index c0e1764..abf94b4 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -110,6 +110,21 @@ struct media_device {
 /* media_devnode to media_device */
 #define to_media_device(node) container_of(node, struct media_device, devnode)
 
+/**
+ * media_entity_enum_init - Initialise an entity enumeration
+ *
+ * @e: Entity enumeration to be initialised
+ * @mdev: The related media device
+ *
+ * Returns zero on success or a negative error code.
+ */
+static inline __must_check int media_entity_enum_init(
+   struct media_entity_enum *ent_enum, struct media_device *mdev)
+{
+   return __media_entity_enum_init(ent_enum,
+   mdev->entity_internal_idx_max + 1);
+}
+
 void media_device_init(struct media_device *mdev);
 void media_device_cleanup(struct media_device *mdev);
 int __must_check __media_device_register(struct media_device *mdev,
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index d3d3a39..70803f7 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -23,7 +23,7 @@
 #ifndef _MEDIA_ENTITY_H
 #define _MEDIA_ENTITY_H
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -71,6 +71,32 @@ struct media_gobj {
struct list_headlist;
 };
 
+#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
+#define MEDIA_ENTITY_ENUM_MAX_ID   64
+
+/*
+ * The number of pads can't be bigger than the number of entities,
+ * as the worse-case scenario is to have one entity linked up to
+ * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
+ */
+#define MEDIA_ENTITY_MAX_PADS  (MEDIA_ENTITY_ENUM_MAX_ID - 1)
+
+/**
+ * struct media_entity_enum - An enumeration of media entities.
+ *
+ * @prealloc_bmap: Pre-allocated space reserved for media entities if the
+ * total number of entities does not exceed
+ * MEDIA_ENTITY_ENUM_MAX_ID.
+ * @bmap:  Bit map in which each bit represents one entity at struct
+ * media_entity->internal_idx.
+ * @idx_max:   Number of bits in bmap
+ */
+struct media_entity_enum {
+   DECLARE_BITMAP(prealloc_bmap, MEDIA_ENTITY_ENUM_MAX_ID);
+   unsigned long *bmap;
+   int idx_max;
+};
+
 struct media_pipeline {
 };
 
@@ -307,15 +333,113 @@ static inline bool is_media_entity_v4l2_subdev(struct 
media_entity *entity)
}
 }
 
-#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
-#define MEDIA_ENTITY_ENUM_MAX_ID   64
+int __media_entity_enum_init(struct media_entity_enum *e, int idx_max);
+void media_entity_enum_cleanup(struct media_entity_enum *e);
 
-/*
- * The number of pads can't be bigger than the number of entities,
- * as the worse-case scenario is to have one entity linked up to
- * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
+/**
+ * media_entity_enum_zero - Clear the entire enum
+ *
+ * @e: 

[PATCH v3 20/23] staging: v4l: davinci_vpbe: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
Cc: Prabhakar Lad 
---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 37 ++---
 drivers/staging/media/davinci_vpfe/vpfe_video.h |  1 +
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c 
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 2dbf14b..1bacd19 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -127,13 +127,14 @@ __vpfe_video_get_format(struct vpfe_video_device *video,
 }
 
 /* make a note of pipeline details */
-static void vpfe_prepare_pipeline(struct vpfe_video_device *video)
+static int vpfe_prepare_pipeline(struct vpfe_video_device *video)
 {
+   struct media_entity_graph graph;
struct media_entity *entity = >video_dev.entity;
struct media_device *mdev = entity->graph_obj.mdev;
struct vpfe_pipeline *pipe = >pipe;
struct vpfe_video_device *far_end = NULL;
-   struct media_entity_graph graph;
+   int ret;
 
pipe->input_num = 0;
pipe->output_num = 0;
@@ -144,6 +145,11 @@ static void vpfe_prepare_pipeline(struct vpfe_video_device 
*video)
pipe->outputs[pipe->output_num++] = video;
 
mutex_lock(>graph_mutex);
+   ret = media_entity_graph_walk_init(, entity->graph_obj.mdev);
+   if (ret) {
+   mutex_unlock(>lock);
+   return -ENOMEM;
+   }
media_entity_graph_walk_start(, entity);
while ((entity = media_entity_graph_walk_next())) {
if (entity == >video_dev.entity)
@@ -156,7 +162,10 @@ static void vpfe_prepare_pipeline(struct vpfe_video_device 
*video)
else
pipe->outputs[pipe->output_num++] = far_end;
}
+   media_entity_graph_walk_cleanup();
mutex_unlock(>graph_mutex);
+
+   return 0;
 }
 
 /* update pipe state selected by user */
@@ -165,7 +174,9 @@ static int vpfe_update_pipe_state(struct vpfe_video_device 
*video)
struct vpfe_pipeline *pipe = >pipe;
int ret;
 
-   vpfe_prepare_pipeline(video);
+   ret = vpfe_prepare_pipeline(video);
+   if (ret)
+   return ret;
 
/* Find out if there is any input video
  if yes, it is single shot.
@@ -276,11 +287,10 @@ static int vpfe_video_validate_pipeline(struct 
vpfe_pipeline *pipe)
  */
 static int vpfe_pipeline_enable(struct vpfe_pipeline *pipe)
 {
-   struct media_entity_graph graph;
struct media_entity *entity;
struct v4l2_subdev *subdev;
struct media_device *mdev;
-   int ret = 0;
+   int ret;
 
if (pipe->state == VPFE_PIPELINE_STREAM_CONTINUOUS)
entity = vpfe_get_input_entity(pipe->outputs[0]);
@@ -289,8 +299,12 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline *pipe)
 
mdev = entity->graph_obj.mdev;
mutex_lock(>graph_mutex);
-   media_entity_graph_walk_start(, entity);
-   while ((entity = media_entity_graph_walk_next())) {
+   ret = media_entity_graph_walk_init(>graph,
+  entity->graph_obj.mdev);
+   if (ret)
+   goto out;
+   media_entity_graph_walk_start(>graph, entity);
+   while ((entity = media_entity_graph_walk_next(>graph))) {
 
if (!is_media_entity_v4l2_subdev(entity))
continue;
@@ -299,6 +313,9 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline *pipe)
if (ret < 0 && ret != -ENOIOCTLCMD)
break;
}
+out:
+   if (ret)
+   media_entity_graph_walk_cleanup(>graph);
mutex_unlock(>graph_mutex);
return ret;
 }
@@ -316,7 +333,6 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline *pipe)
  */
 static int vpfe_pipeline_disable(struct vpfe_pipeline *pipe)
 {
-   struct media_entity_graph graph;
struct media_entity *entity;
struct v4l2_subdev *subdev;
struct media_device *mdev;
@@ -329,9 +345,9 @@ static int vpfe_pipeline_disable(struct vpfe_pipeline *pipe)
 
mdev = entity->graph_obj.mdev;
mutex_lock(>graph_mutex);
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(>graph, entity);
 
-   while ((entity = media_entity_graph_walk_next())) {
+   while ((entity = media_entity_graph_walk_next(>graph))) {
 
if (!is_media_entity_v4l2_subdev(entity))
continue;
@@ -342,6 +358,7 @@ static int vpfe_pipeline_disable(struct vpfe_pipeline *pipe)
}
mutex_unlock(>graph_mutex);
 
+   media_entity_graph_walk_cleanup(>graph);
return ret ? -ETIMEDOUT : 0;
 }
 
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.h 

[PATCH v3 10/23] v4l: exynos4-is: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
Cc: Javier Martinez Canillas 
Cc: Kamil Debski 
Cc: Sylwester Nawrocki 
---
 drivers/media/platform/exynos4-is/media-dev.c | 31 +--
 drivers/media/platform/exynos4-is/media-dev.h |  1 +
 2 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index d55b4f3..704040c 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1046,10 +1046,10 @@ static int __fimc_md_modify_pipeline(struct 
media_entity *entity, bool enable)
 }
 
 /* Locking: called with entity->graph_obj.mdev->graph_mutex mutex held. */
-static int __fimc_md_modify_pipelines(struct media_entity *entity, bool enable)
+static int __fimc_md_modify_pipelines(struct media_entity *entity, bool enable,
+ struct media_entity_graph *graph)
 {
struct media_entity *entity_err = entity;
-   struct media_entity_graph graph;
int ret;
 
/*
@@ -1058,9 +1058,9 @@ static int __fimc_md_modify_pipelines(struct media_entity 
*entity, bool enable)
 * through active links. This is needed as we cannot power on/off the
 * subdevs in random order.
 */
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(graph, entity);
 
-   while ((entity = media_entity_graph_walk_next())) {
+   while ((entity = media_entity_graph_walk_next(graph))) {
if (!is_media_entity_v4l2_io(entity))
continue;
 
@@ -1071,10 +1071,11 @@ static int __fimc_md_modify_pipelines(struct 
media_entity *entity, bool enable)
}
 
return 0;
- err:
-   media_entity_graph_walk_start(, entity_err);
 
-   while ((entity_err = media_entity_graph_walk_next())) {
+err:
+   media_entity_graph_walk_start(graph, entity_err);
+
+   while ((entity_err = media_entity_graph_walk_next(graph))) {
if (!is_media_entity_v4l2_io(entity_err))
continue;
 
@@ -1090,21 +1091,29 @@ static int __fimc_md_modify_pipelines(struct 
media_entity *entity, bool enable)
 static int fimc_md_link_notify(struct media_link *link, unsigned int flags,
unsigned int notification)
 {
+   struct media_entity_graph *graph =
+   _of(link->graph_obj.mdev, struct fimc_md,
+ media_dev)->link_setup_graph;
struct media_entity *sink = link->sink->entity;
int ret = 0;
 
/* Before link disconnection */
if (notification == MEDIA_DEV_NOTIFY_PRE_LINK_CH) {
+   ret = media_entity_graph_walk_init(graph,
+  link->graph_obj.mdev);
+   if (ret)
+   return ret;
if (!(flags & MEDIA_LNK_FL_ENABLED))
-   ret = __fimc_md_modify_pipelines(sink, false);
+   ret = __fimc_md_modify_pipelines(sink, false, graph);
 #if 0
else
/* TODO: Link state change validation */
 #endif
/* After link activation */
-   } else if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH &&
-  (link->flags & MEDIA_LNK_FL_ENABLED)) {
-   ret = __fimc_md_modify_pipelines(sink, true);
+   } else if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH) {
+   if (link->flags & MEDIA_LNK_FL_ENABLED)
+   ret = __fimc_md_modify_pipelines(sink, true, graph);
+   media_entity_graph_walk_cleanup(graph);
}
 
return ret ? -EPIPE : 0;
diff --git a/drivers/media/platform/exynos4-is/media-dev.h 
b/drivers/media/platform/exynos4-is/media-dev.h
index 9a69913..e80c55d 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -154,6 +154,7 @@ struct fimc_md {
bool user_subdev_api;
spinlock_t slock;
struct list_head pipelines;
+   struct media_entity_graph link_setup_graph;
 };
 
 static inline
-- 
2.1.4

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

[PATCH v3 00/23] Unrestricted media entity ID range support

[Sakari Ailus]

Hello all,

This is the third version of the unrestricted media entity ID range
support set. I've taken Mauro's comments into account and fixed a number
of bugs as well (omap3isp memory leak and omap4iss stream start).

The more specific changes since v2 are here:

- Renamed struct media_entity_enum "entities" as ent_enum.

- Renamed struct media_entity_enum.e as bmap.

- Fix KernelDoc documentation

- Remove pre-allocated bitmap from entity enumerations. This is done in a
  separate patch due to API changes it necessitates. (Init may fail.)

- Drop MEDIA_ENTITY_ENUM_STACK_ALLOC. Move MEDIA_ENTITY_MAX_PADS to
  media-entity.c.

- Replace BUG_ON() in media_entity_pipeline_stop() by WARN_ON().

- Fix enumeration and graph walk init / cleanup in iss_video_streamon() in
  omap4iss driver.

v2 is available here:



The documentation remains unchanged so far.

-- 
Kind regards,
Sakari

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

[PATCH v3 11/23] v4l: xilinx: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
Cc: Hyun Kwon 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index bc244a0..0a19824 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -182,10 +182,17 @@ static int xvip_pipeline_validate(struct xvip_pipeline 
*pipe,
struct media_device *mdev = entity->graph_obj.mdev;
unsigned int num_inputs = 0;
unsigned int num_outputs = 0;
+   int ret;
 
mutex_lock(>graph_mutex);
 
/* Walk the graph to locate the video nodes. */
+   ret = media_entity_graph_walk_init(, entity->graph_obj.mdev);
+   if (ret) {
+   mutex_unlock(>graph_mutex);
+   return ret;
+   }
+
media_entity_graph_walk_start(, entity);
 
while ((entity = media_entity_graph_walk_next())) {
@@ -206,6 +213,8 @@ static int xvip_pipeline_validate(struct xvip_pipeline 
*pipe,
 
mutex_unlock(>graph_mutex);
 
+   media_entity_graph_walk_cleanup();
+
/* We need exactly one output and zero or one input. */
if (num_outputs != 1 || num_inputs > 1)
return -EPIPE;
-- 
2.1.4

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

[PATCH v3 06/23] media: Move media graph state for streamon/off to the pipeline

[Sakari Ailus]

The struct media_entity_graph was allocated in the stack, limiting the
number of entities that could be reasonably allocated. Instead, move the
struct to struct media_pipeline which is typically allocated using
kmalloc() instead.

The intent is to keep the enumeration around for later use for the
duration of the streaming. As streaming is eventually stopped, an
unfortunate memory allocation failure would prevent stopping the
streaming. As no memory will need to be allocated, the problem is avoided
altogether.

Signed-off-by: Sakari Ailus 
Reviewed-by: Mauro Carvalho Chehab 
---
 drivers/media/media-entity.c | 16 
 include/media/media-entity.h |  6 ++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 67eebcb..786a01f 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -456,16 +456,16 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
 struct media_pipeline *pipe)
 {
struct media_device *mdev = entity->graph_obj.mdev;
-   struct media_entity_graph graph;
+   struct media_entity_graph *graph = >graph;
struct media_entity *entity_err = entity;
struct media_link *link;
int ret;
 
mutex_lock(>graph_mutex);
 
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(graph, entity);
 
-   while ((entity = media_entity_graph_walk_next())) {
+   while ((entity = media_entity_graph_walk_next(graph))) {
DECLARE_BITMAP(active, MEDIA_ENTITY_MAX_PADS);
DECLARE_BITMAP(has_no_links, MEDIA_ENTITY_MAX_PADS);
 
@@ -546,9 +546,9 @@ error:
 * Link validation on graph failed. We revert what we did and
 * return the error.
 */
-   media_entity_graph_walk_start(, entity_err);
+   media_entity_graph_walk_start(graph, entity_err);
 
-   while ((entity_err = media_entity_graph_walk_next())) {
+   while ((entity_err = media_entity_graph_walk_next(graph))) {
entity_err->stream_count--;
if (entity_err->stream_count == 0)
entity_err->pipe = NULL;
@@ -582,13 +582,13 @@ EXPORT_SYMBOL_GPL(media_entity_pipeline_start);
 void media_entity_pipeline_stop(struct media_entity *entity)
 {
struct media_device *mdev = entity->graph_obj.mdev;
-   struct media_entity_graph graph;
+   struct media_entity_graph *graph = >pipe->graph;
 
mutex_lock(>graph_mutex);
 
-   media_entity_graph_walk_start(, entity);
+   media_entity_graph_walk_start(graph, entity);
 
-   while ((entity = media_entity_graph_walk_next())) {
+   while ((entity = media_entity_graph_walk_next(graph))) {
entity->stream_count--;
if (entity->stream_count == 0)
entity->pipe = NULL;
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 3068c30..9315158 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -116,7 +116,13 @@ struct media_entity_graph {
int top;
 };
 
+/*
+ * struct media_pipeline - Media pipeline related information
+ *
+ * @graph: Media graph walk during pipeline start / stop
+ */
 struct media_pipeline {
+   struct media_entity_graph graph;
 };
 
 /**
-- 
2.1.4

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

[PATCH v3 01/23] media: Enforce single entity->pipe in a pipeline

[Sakari Ailus]

If a different entity->pipe in a pipeline was encountered, a warning was
issued but the execution continued as if nothing had happened. Return an
error instead right there.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 66b8db0..d11f440 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -431,7 +431,12 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
DECLARE_BITMAP(has_no_links, MEDIA_ENTITY_MAX_PADS);
 
entity->stream_count++;
-   WARN_ON(entity->pipe && entity->pipe != pipe);
+
+   if (WARN_ON(entity->pipe && entity->pipe != pipe)) {
+   ret = -EBUSY;
+   goto error;
+   }
+
entity->pipe = pipe;
 
/* Already streaming --- no need to check. */
-- 
2.1.4

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

[PATCH v3 08/23] media: Use the new media graph walk interface

[Sakari Ailus]

The media graph walk requires initialisation and cleanup soon. Update the
users to perform the soon necessary API calls.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d63204e..2232cb3 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -492,7 +492,13 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
 
mutex_lock(>graph_mutex);
 
-   media_entity_graph_walk_start(graph, entity);
+   ret = media_entity_graph_walk_init(>graph, mdev);
+   if (ret) {
+   mutex_unlock(>graph_mutex);
+   return ret;
+   }
+
+   media_entity_graph_walk_start(>graph, entity);
 
while ((entity = media_entity_graph_walk_next(graph))) {
DECLARE_BITMAP(active, MEDIA_ENTITY_MAX_PADS);
@@ -590,6 +596,8 @@ error:
break;
}
 
+   media_entity_graph_walk_cleanup(graph);
+
mutex_unlock(>graph_mutex);
 
return ret;
@@ -623,6 +631,8 @@ void media_entity_pipeline_stop(struct media_entity *entity)
entity->pipe = NULL;
}
 
+   media_entity_graph_walk_cleanup(graph);
+
mutex_unlock(>graph_mutex);
 }
 EXPORT_SYMBOL_GPL(media_entity_pipeline_stop);
-- 
2.1.4

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

[PATCH v3 21/23] media: Remove pre-allocated entity enumeration bitmap

[Sakari Ailus]

The bitmaps for entity enumerations used to be statically allocated. Now
that the drivers have been converted to use the new interface which
explicitly initialises the enum objects, drop the pre-allocated bitmaps.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 16 +---
 include/media/media-entity.h |  9 ++---
 2 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index ddf3c23..c799a4e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -222,14 +222,10 @@ void media_gobj_remove(struct media_gobj *gobj)
  */
 int __media_entity_enum_init(struct media_entity_enum *ent_enum, int idx_max)
 {
-   if (idx_max > MEDIA_ENTITY_ENUM_MAX_ID) {
-   ent_enum->bmap = kcalloc(DIV_ROUND_UP(idx_max, BITS_PER_LONG),
-sizeof(long), GFP_KERNEL);
-   if (!ent_enum->bmap)
-   return -ENOMEM;
-   } else {
-   ent_enum->bmap = ent_enum->prealloc_bmap;
-   }
+   ent_enum->bmap = kcalloc(DIV_ROUND_UP(idx_max, BITS_PER_LONG),
+sizeof(long), GFP_KERNEL);
+   if (!ent_enum->bmap)
+   return -ENOMEM;
 
bitmap_zero(ent_enum->bmap, idx_max);
ent_enum->idx_max = idx_max;
@@ -245,9 +241,7 @@ EXPORT_SYMBOL_GPL(__media_entity_enum_init);
  */
 void media_entity_enum_cleanup(struct media_entity_enum *ent_enum)
 {
-   if (ent_enum->bmap != ent_enum->prealloc_bmap)
-   kfree(ent_enum->bmap);
-   ent_enum->bmap = NULL;
+   kfree(ent_enum->bmap);
 }
 EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
 
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 251eddf..034b9d7 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -72,27 +72,22 @@ struct media_gobj {
 };
 
 #define MEDIA_ENTITY_ENUM_MAX_DEPTH16
-#define MEDIA_ENTITY_ENUM_MAX_ID   64
 
 /*
  * The number of pads can't be bigger than the number of entities,
  * as the worse-case scenario is to have one entity linked up to
- * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
+ * 63 entities.
  */
-#define MEDIA_ENTITY_MAX_PADS  (MEDIA_ENTITY_ENUM_MAX_ID - 1)
+#define MEDIA_ENTITY_MAX_PADS  63
 
 /**
  * struct media_entity_enum - An enumeration of media entities.
  *
- * @prealloc_bmap: Pre-allocated space reserved for media entities if the
- * total number of entities does not exceed
- * MEDIA_ENTITY_ENUM_MAX_ID.
  * @bmap:  Bit map in which each bit represents one entity at struct
  * media_entity->internal_idx.
  * @idx_max:   Number of bits in bmap
  */
 struct media_entity_enum {
-   DECLARE_BITMAP(prealloc_bmap, MEDIA_ENTITY_ENUM_MAX_ID);
unsigned long *bmap;
int idx_max;
 };
-- 
2.1.4

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

[PATCH v3.1 03/23] media: Add an API to manage entity enumerations

[Sakari Ailus]

From: Sakari Ailus 

This is useful in e.g. knowing whether certain operations have already
been performed for an entity. The users include the framework itself (for
graph walking) and a number of drivers.

Signed-off-by: Sakari Ailus 
---
since v3:

- Also rename the argument "e" in the prototype of
  __media_entity_enum_init().

- Add __must_check modifier to __media_entity_enum_init().

 drivers/media/media-entity.c |  40 
 include/media/media-device.h |  15 +
 include/media/media-entity.h | 141 ---
 3 files changed, 188 insertions(+), 8 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d11f440..678cc57 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -213,6 +213,46 @@ void media_gobj_remove(struct media_gobj *gobj)
 }
 
 /**
+ * __media_entity_enum_init - Initialise an entity enumeration
+ *
+ * @ent_enum: Entity enumeration to be initialised
+ * @idx_max: Maximum number of entities in the enumeration
+ *
+ * Returns zero on success or a negative error code.
+ */
+__must_check int __media_entity_enum_init(struct media_entity_enum *ent_enum,
+ int idx_max)
+{
+   if (idx_max > MEDIA_ENTITY_ENUM_MAX_ID) {
+   ent_enum->bmap = kcalloc(DIV_ROUND_UP(idx_max, BITS_PER_LONG),
+sizeof(long), GFP_KERNEL);
+   if (!ent_enum->bmap)
+   return -ENOMEM;
+   } else {
+   ent_enum->bmap = ent_enum->prealloc_bmap;
+   }
+
+   bitmap_zero(ent_enum->bmap, idx_max);
+   ent_enum->idx_max = idx_max;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__media_entity_enum_init);
+
+/**
+ * media_entity_enum_cleanup - Release resources of an entity enumeration
+ *
+ * @e: Entity enumeration to be released
+ */
+void media_entity_enum_cleanup(struct media_entity_enum *ent_enum)
+{
+   if (ent_enum->bmap != ent_enum->prealloc_bmap)
+   kfree(ent_enum->bmap);
+   ent_enum->bmap = NULL;
+}
+EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
+
+/**
  * media_entity_init - Initialize a media entity
  *
  * @num_pads: Total number of sink and source pads.
diff --git a/include/media/media-device.h b/include/media/media-device.h
index c0e1764..abf94b4 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -110,6 +110,21 @@ struct media_device {
 /* media_devnode to media_device */
 #define to_media_device(node) container_of(node, struct media_device, devnode)
 
+/**
+ * media_entity_enum_init - Initialise an entity enumeration
+ *
+ * @e: Entity enumeration to be initialised
+ * @mdev: The related media device
+ *
+ * Returns zero on success or a negative error code.
+ */
+static inline __must_check int media_entity_enum_init(
+   struct media_entity_enum *ent_enum, struct media_device *mdev)
+{
+   return __media_entity_enum_init(ent_enum,
+   mdev->entity_internal_idx_max + 1);
+}
+
 void media_device_init(struct media_device *mdev);
 void media_device_cleanup(struct media_device *mdev);
 int __must_check __media_device_register(struct media_device *mdev,
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index d3d3a39..064cf73 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -23,7 +23,7 @@
 #ifndef _MEDIA_ENTITY_H
 #define _MEDIA_ENTITY_H
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -71,6 +71,32 @@ struct media_gobj {
struct list_headlist;
 };
 
+#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
+#define MEDIA_ENTITY_ENUM_MAX_ID   64
+
+/*
+ * The number of pads can't be bigger than the number of entities,
+ * as the worse-case scenario is to have one entity linked up to
+ * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
+ */
+#define MEDIA_ENTITY_MAX_PADS  (MEDIA_ENTITY_ENUM_MAX_ID - 1)
+
+/**
+ * struct media_entity_enum - An enumeration of media entities.
+ *
+ * @prealloc_bmap: Pre-allocated space reserved for media entities if the
+ * total number of entities does not exceed
+ * MEDIA_ENTITY_ENUM_MAX_ID.
+ * @bmap:  Bit map in which each bit represents one entity at struct
+ * media_entity->internal_idx.
+ * @idx_max:   Number of bits in bmap
+ */
+struct media_entity_enum {
+   DECLARE_BITMAP(prealloc_bmap, MEDIA_ENTITY_ENUM_MAX_ID);
+   unsigned long *bmap;
+   int idx_max;
+};
+
 struct media_pipeline {
 };
 
@@ -307,15 +333,114 @@ static inline bool is_media_entity_v4l2_subdev(struct 
media_entity *entity)
}
 }
 
-#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
-#define MEDIA_ENTITY_ENUM_MAX_ID   64
+__must_check int __media_entity_enum_init(struct media_entity_enum *ent_enum,
+ int idx_max);
+void media_entity_enum_cleanup(struct 

Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[tiffany lin]

Hi Hans,


On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
> 
> On 12/15/15 14:51, tiffany lin wrote:
> > Hi Hans,
> > 
> > Thanks for your time.
> > 
> > On Mon, 2015-12-14 at 13:50 +0100, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> My apologies for the long delay, but I finally have time to do a review of 
> >> this
> >> code.
> >>
> >> On 12/11/2015 10:55 AM, Tiffany Lin wrote:
> >>> From: Andrew-CT Chen 
> >>>
> >>> Add v4l2 layer encoder driver for MT8173
> >>>
> >>> Signed-off-by: Tiffany Lin 
> >>> ---
> >>>  drivers/media/platform/Kconfig |   11 +
> >>>  drivers/media/platform/Makefile|2 +
> >>>  drivers/media/platform/mtk-vcodec/Makefile |8 +
> >>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  412 +
> >>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1670 
> >>> 
> >>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   45 +
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  469 ++
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  122 ++
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|  102 ++
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   29 +
> >>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|  106 ++
> >>>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   85 +
> >>>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
> >>>  drivers/media/platform/mtk-vcodec/venc_drv_if.c|  102 ++
> >>>  drivers/media/platform/mtk-vcodec/venc_drv_if.h|  174 ++
> >>>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
> >>>  17 files changed, 3637 insertions(+)
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
> >>>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
> >>>
> >>
> >> 
> >>
> >>> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> >>> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> new file mode 100644
> >>> index 000..d59064d
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> @@ -0,0 +1,1670 @@
> >>> +/*
> >>> +* Copyright (c) 2015 MediaTek Inc.
> >>> +* Author: PC Chen 
> >>> +* Tiffany Lin 
> >>> +*
> >>> +* 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.
> >>> +*/
> >>> +
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +#include "mtk_vcodec_drv.h"
> >>> +#include "mtk_vcodec_enc.h"
> >>> +#include "mtk_vcodec_intr.h"
> >>> +#include "mtk_vcodec_util.h"
> >>> +#include "venc_drv_if.h"
> >>> +
> >>> +static void mtk_venc_worker(struct work_struct *work);
> >>> +
> >>> +static struct mtk_video_fmt mtk_video_formats[] = {
> >>> + {
> >>> + .name   = "4:2:0 3 Planes Y/Cb/Cr",
> >>
> >> Don't add the name. The v4l2 core will set that for you. This ensures that 
> >> the name is
> >> always the same for the format, instead of being driver dependent.
> >>
> > We will remove it in next version.
> > 
> >>> + .fourcc = V4L2_PIX_FMT_YUV420,
> >>> + .type   = MTK_FMT_FRAME,
> >>> + .num_planes = 3,
> >>> + },
> >>> + {
> >>> + .name   = "4:2:0 3 Planes Y/Cr/Cb",
> >>> + .fourcc = V4L2_PIX_FMT_YVU420,
> >>> + .type   = MTK_FMT_FRAME,
> >>> + .num_planes = 3,
> >>> + },
> >>> + {
> >>> +

Re: [PATCH v3 00/23] Unrestricted media entity ID range support

[Sakari Ailus]

Hi Javier,

On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> This is the third version of the unrestricted media entity ID range
> support set. I've taken Mauro's comments into account and fixed a number
> of bugs as well (omap3isp memory leak and omap4iss stream start).

Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
test the OMAP4 ISS with these patches?

Thanks.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Philipp Zabel]

Hi Piotr,

thank you for the report.

Am Mittwoch, den 16.12.2015, 14:09 +0100 schrieb Piotr Lewicki:
> Hello,
> I'm running an application that plays video on an embedded device. It 
> uses Qt5.4 and qt-gstreamer plugin and it runs on imx6q processor with 
> yocto based linux (kernel version 3.19.5).

First, could you repeat this using current versions of the coda driver
and GStreamer? There are about 60 coda patches in mainline between v3.19
and v4.3, and some of them are quite relevant for the end-of-stream and
buffer handling. I think the relevant GStreamer EOS change went into
1.5.2.

> When I built a sample from this qt-gstreamer package called qmlplayer2 
> and used it to play video I came across following problem:
> 
> 1. When video reaches it's end I start receiving kernel ringbuffer message:
> # [ 1371.618854] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1372.618713] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1373.618653] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1374.618872] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1375.618712] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1376.618707] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1377.618860] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1378.738700] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1379.738632] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1380.828872] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1381.828697] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
> 
> The video is stopped but I can see last frame on the screen although in 
> qt application it should receive end-of-stream message and stop the 
> video (resulting with black screen).

Looks like the coda driver is constantly fed empty buffers, which don't
increase the bitstream payload level, and the PIC_RUN times out with a
bitstream buffer underflow. What GStreamer version is this?

> 2. If I don't terminate the application and several times press "stop" 
> and "play" video I get message:
> 
> # [ 3041.650483] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3044.205362] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3044.214711] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3047.189317] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3047.196056] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> 
> and finally
> 
> # [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # "Failed to allocate required memory."

That shouldn't happen anymore in recent kernels. In the past, repeated
reqbufs calls would leak buffers because the cleanup was only done on
close.

Please let me know if you can reproduce any of the issues with more
recent kernels and GStreamer 1.6.

regards
Philipp

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

Re: [PATCH] android: fix warning when releasing active sync point

[Daniel Vetter]

On Tue, Dec 15, 2015 at 11:08:01AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan  wrote:
> > 2015-12-15 Daniel Vetter :
> >
> >> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> >> > Userspace can close the sync device while there are still active fence
> >> > points, in which case kernel produces the following warning:
> >> >
> >> > [   43.853176] [ cut here ]
> >> > [   43.857834] WARNING: CPU: 0 PID: 892 at 
> >> > /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
> >> >  android_fence_release+0x88/0x104()
> >> > [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> >> > 3.18.0-07661-g0550ce9 #1
> >> > [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> >> > [   43.885834] Call trace:
> >> > [   43.888294] [] dump_backtrace+0x0/0x10c
> >> > [   43.893697] [] show_stack+0x10/0x1c
> >> > [   43.898756] [] dump_stack+0x74/0xb8
> >> > [   43.903814] [] warn_slowpath_common+0x84/0xb0
> >> > [   43.909736] [] warn_slowpath_null+0x14/0x20
> >> > [   43.915482] [] android_fence_release+0x84/0x104
> >> > [   43.921582] [] fence_release+0x104/0x134
> >> > [   43.927066] [] sync_fence_free+0x74/0x9c
> >> > [   43.932552] [] sync_fence_release+0x34/0x48
> >> > [   43.938304] [] __fput+0x100/0x1b8
> >> > [   43.943185] [] fput+0x8/0x14
> >> > [   43.947982] [] task_work_run+0xb0/0xe4
> >> > [   43.953297] [] do_notify_resume+0x44/0x5c
> >> > [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
> >> >
> >> > Let's fix it by introducing a new optional callback (disable_signaling)
> >> > to fence operations so that drivers can do proper clean ups when we
> >> > remove last callback for given fence.
> >> >
> >> > Reviewed-by: Andrew Bresticker 
> >> > Signed-off-by: Dmitry Torokhov 
> >> > ---
> >> >  drivers/dma-buf/fence.c| 6 +-
> >> >  drivers/staging/android/sync.c | 8 
> >> >  include/linux/fence.h  | 2 ++
> >> >  3 files changed, 15 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
> >> > index 7b05dbe..0ed73ad 100644
> >> > --- a/drivers/dma-buf/fence.c
> >> > +++ b/drivers/dma-buf/fence.c
> >> > @@ -304,8 +304,12 @@ fence_remove_callback(struct fence *fence, struct 
> >> > fence_cb *cb)
> >> > spin_lock_irqsave(fence->lock, flags);
> >> >
> >> > ret = !list_empty(>node);
> >> > -   if (ret)
> >> > +   if (ret) {
> >> > list_del_init(>node);
> >> > +   if (list_empty(>cb_list))
> >> > +   if (fence->ops->disable_signaling)
> >> > +   fence->ops->disable_signaling(fence);
> >>
> >> What exactly is the bug here? A fence with no callbacks registered any
> >> more shouldn't have any problem. Why exactly does this blow up?
> >
> > The WARN_ON is probably this one:
> > https://android.googlesource.com/kernel/common/+/android-3.18/drivers/staging/android/sync.c#433
> >
> > I've been wondering in the last few days if this warning is really
> > necessary. If the user is closing a sync_timeline that has unsignalled
> > fences it should probably be aware of that already. Then I think it is
> > okay to remove the the sync_pt from the active_list at the release-time.
> > In fact I've already prepared a patch doing that. Thoughts?
> >
> 
> Maybe, but you need to make sure that you only affecting your fences.
> 
> My main objection is that still leaves fence_remove_callback() being
> not mirror image of fence_add_callback().

That's 100% intentional. I looked at the sync.c code a bit more and it
duplicates a bunch of the fence stuff still. We need to either merge that
code into the mainline struct fence logic, or remove it. There shouldn't
really be any need for the userspace ABI layer to keep track of active
fences at all. Worse, it means that you must use the sync_pt struct to be
able to export it to userspace, and can't just export any normal struct
fence object. That breaks the abstraction we're aiming for.

Imo just remove that WARN_ON for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Marek Szyprowski]

Add a helper function for device drivers to set DMA's max_seg_size.
Setting it to largest possible value lets DMA-mapping API always create
contiguous mappings in DMA address space. This is essential for all
devices, which use dma-contig videobuf2 memory allocator and shared
buffers.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 14 ++
 include/media/videobuf2-dma-contig.h   |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index c33127284cfe..bd893788d1ae 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -742,6 +742,20 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
 }
 EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
 
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {
+   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
+
 MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
 MODULE_AUTHOR("Pawel Osciak ");
 MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-dma-contig.h 
b/include/media/videobuf2-dma-contig.h
index c33dfa69d7ab..0e6ba644939e 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb, unsigned 
int plane_no)
 
 void *vb2_dma_contig_init_ctx(struct device *dev);
 void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);
 
 extern const struct vb2_mem_ops vb2_dma_contig_memops;
 
-- 
1.9.2

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

[PATCH v3 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support

[Marek Szyprowski]

Hello,

This patchset finally perform cleanup of custom code in s5p-mfc codec
driver. The first part is removal of custom, driver specific code for
intializing and handling of reserved memory. Instead, a generic code for
reserved memory regions is used. Then, once it is done, the proper setup
of DMA parameters (max segment size) is applied for all multimedia
devices found on Exynos SoCs to let them properly handle shared buffers
mapped into contiguous DMA address space. The last patch adds support
for IOMMU to MFC driver. Some additional code is needed because of
specific requirements of MFC device firmware (see patch 7 for more
details). When no IOMMU is available, the code fallbacks to generic
reserved memory regions.

After applying this patchset, MFC device works correctly when IOMMU is
either enabled or disabled.

Patches have been tested on top of linux-next from 20151207. I would
prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media
tree (there are no compile-time dependencies between patches 1-2 and
3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and
Odroid XU3 (Exynos 5422 based) boards.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:
v3:
- fixed issues pointed by Laurent Pinchart:
  - added documentation to memory-region-names property,
  - changed devm_kzalloc to kzalloc in vb2_dma_contig_set_max_seg_size() to
avoid access to freed memory after reloading driver module
- unified odroid mfc reserved memory configuration with other Exynos4 boards

v2: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97025
- reworked of_reserved_mem_init* functions on request from Rob Herring,
  added separate index and name based selection of reserved region
- adapted for of_reserved_mem_init* related changes

v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html
- initial version of another approach for this problem, rewrote driver code
  for new reserved memory bindings, which finally have been merged some
  time ago

v0: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.html
- old patchset solving the same problem, abandoned due to other tasks
  and long time of merging reserved memory bindings and support code for
  it

Patch summary:

Marek Szyprowski (7):
  ARM: Exynos: convert MFC device to generic reserved memory bindings
  ARM: dts: exynos4412-odroid*: enable MFC device
  of: reserved_mem: add support for named reserved mem nodes
  media: vb2-dma-contig: add helper for setting dma max seg size
  media: set proper max seg size for devices on Exynos SoCs
  media: s5p-mfc: replace custom reserved memory init code with generic
one
  media: s5p-mfc: add iommu support

 .../devicetree/bindings/media/s5p-mfc.txt  |  16 +--
 .../bindings/reserved-memory/reserved-memory.txt   |   2 +
 .../devicetree/bindings/resource-names.txt |   1 +
 arch/arm/boot/dts/exynos4210-origen.dts|  22 ++-
 arch/arm/boot/dts/exynos4210-smdkv310.dts  |  22 ++-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  24 
 arch/arm/boot/dts/exynos4412-origen.dts|  22 ++-
 arch/arm/boot/dts/exynos4412-smdk4412.dts  |  22 ++-
 arch/arm/boot/dts/exynos5250-arndale.dts   |  22 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |  22 ++-
 arch/arm/boot/dts/exynos5250-spring.dts|  22 ++-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  22 ++-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |  22 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  22 ++-
 arch/arm/mach-exynos/Makefile  |   2 -
 arch/arm/mach-exynos/exynos.c  |  19 ---
 arch/arm/mach-exynos/mfc.h |  16 ---
 arch/arm/mach-exynos/s5p-dev-mfc.c |  94 -
 drivers/media/platform/exynos-gsc/gsc-core.c   |   1 +
 drivers/media/platform/exynos4-is/fimc-core.c  |   1 +
 drivers/media/platform/exynos4-is/fimc-is.c|   1 +
 drivers/media/platform/exynos4-is/fimc-lite.c  |   1 +
 drivers/media/platform/s5p-g2d/g2d.c   |   1 +
 drivers/media/platform/s5p-jpeg/jpeg-core.c|   1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 153 -
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  79 +++
 drivers/media/platform/s5p-tv/mixer_video.c|   1 +
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  14 ++
 drivers/of/of_reserved_mem.c   | 104 +++---
 include/linux/of_reserved_mem.h|  31 -
 include/media/videobuf2-dma-contig.h   |   1 +
 31 files changed, 535 insertions(+), 248 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/mfc.h
 delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h

-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe 

[linuxtv-media:media-controller 2022/2026] drivers/media/usb/au0828/au0828-core.c:445:36: error: 'struct au0828_dev' has no member named 'media_dev'

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git media-controller
head:   0a3c36e2b81cf4fe4b6d094b27259716f0ed9a4d
commit: 1590ad7b52714fddc958189103c95541b49b1dae [2022/2026] [media] 
media-device: split media initialization and registration
config: x86_64-rhel (attached as .config)
reproduce:
git checkout 1590ad7b52714fddc958189103c95541b49b1dae
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/usb/au0828/au0828-core.c: In function 'au0828_usb_probe':
>> drivers/media/usb/au0828/au0828-core.c:445:36: error: 'struct au0828_dev' 
>> has no member named 'media_dev'
 retval = media_device_register(dev->media_dev);
   ^
--
   drivers/media/usb/cx231xx/cx231xx-cards.c: In function 'cx231xx_usb_probe':
>> drivers/media/usb/cx231xx/cx231xx-cards.c:1741:36: error: 'struct cx231xx' 
>> has no member named 'media_dev'
 retval = media_device_register(dev->media_dev);
   ^
--
   drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe':
>> drivers/media/usb/uvc/uvc_driver.c:1960:32: error: 'struct uvc_device' has 
>> no member named 'mdev'
 if (media_device_register(>mdev) < 0)
   ^

vim +445 drivers/media/usb/au0828/au0828-core.c

   439  if (retval) {
   440  pr_err("%s() au0282_dev_register failed to create 
graph\n",
   441 __func__);
   442  goto done;
   443  }
   444  
 > 445  retval = media_device_register(dev->media_dev);
   446  
   447  done:
   448  if (retval < 0)

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


.config.gz
Description: Binary data

Re: [PATCH] android: fix warning when releasing active sync point

[Daniel Vetter]

On Tue, Dec 15, 2015 at 09:22:56AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 5:30 AM, Gustavo Padovan  wrote:
> > 2015-12-14 Dmitry Torokhov :
> >
> >> Userspace can close the sync device while there are still active fence
> >> points, in which case kernel produces the following warning:
> >>
> >> [   43.853176] [ cut here ]
> >> [   43.857834] WARNING: CPU: 0 PID: 892 at 
> >> /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
> >>  android_fence_release+0x88/0x104()
> >> [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> >> 3.18.0-07661-g0550ce9 #1
> >> [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> >> [   43.885834] Call trace:
> >> [   43.888294] [] dump_backtrace+0x0/0x10c
> >> [   43.893697] [] show_stack+0x10/0x1c
> >> [   43.898756] [] dump_stack+0x74/0xb8
> >> [   43.903814] [] warn_slowpath_common+0x84/0xb0
> >> [   43.909736] [] warn_slowpath_null+0x14/0x20
> >> [   43.915482] [] android_fence_release+0x84/0x104
> >> [   43.921582] [] fence_release+0x104/0x134
> >> [   43.927066] [] sync_fence_free+0x74/0x9c
> >> [   43.932552] [] sync_fence_release+0x34/0x48
> >> [   43.938304] [] __fput+0x100/0x1b8
> >> [   43.943185] [] fput+0x8/0x14
> >> [   43.947982] [] task_work_run+0xb0/0xe4
> >> [   43.953297] [] do_notify_resume+0x44/0x5c
> >> [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
> >
> > This crash report seems to be for a 3.18 kernel. Can you reproduce it
> > on upstream kernel as well?
> 
> Unfortunately this board does not run upsrteam just yet, but looking
> at the sync driver and fence code we are pretty much in sync with
> upstream.

Just to check: Is that with a proper hw driver, or using SW_SYNC? The
later will get removed in upstream since it's a debug/validation only
interface. Well, removed for drivers and production systems, the
kselftests will use it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/7] media: set proper max seg size for devices on Exynos SoCs

[Marek Szyprowski]

All multimedia devices found on Exynos SoCs support only contiguous
buffers, so set DMA max segment size to DMA_BIT_MASK(32) to let memory
allocator to correctly create contiguous memory mappings.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c  | 1 +
 drivers/media/platform/exynos4-is/fimc-core.c | 1 +
 drivers/media/platform/exynos4-is/fimc-is.c   | 1 +
 drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
 drivers/media/platform/s5p-g2d/g2d.c  | 1 +
 drivers/media/platform/s5p-jpeg/jpeg-core.c   | 1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c  | 2 ++
 drivers/media/platform/s5p-tv/mixer_video.c   | 1 +
 8 files changed, 9 insertions(+)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9b9e423e4fc4..4f90be43b5a9 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1140,6 +1140,7 @@ static int gsc_probe(struct platform_device *pdev)
goto err_m2m;
 
/* Initialize continious memory allocator */
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(gsc->alloc_ctx)) {
ret = PTR_ERR(gsc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c 
b/drivers/media/platform/exynos4-is/fimc-core.c
index cef2a7f07cdb..368e19b50498 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1019,6 +1019,7 @@ static int fimc_probe(struct platform_device *pdev)
}
 
/* Initialize contiguous memory allocator */
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
b/drivers/media/platform/exynos4-is/fimc-is.c
index 49658ca39e51..123772fa0241 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -841,6 +841,7 @@ static int fimc_is_probe(struct platform_device *pdev)
if (ret < 0)
goto err_pm;
 
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
is->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(is->alloc_ctx)) {
ret = PTR_ERR(is->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 6f76afd909c4..9cfd2221f53d 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1564,6 +1564,7 @@ static int fimc_lite_probe(struct platform_device *pdev)
goto err_sd;
}
 
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
b/drivers/media/platform/s5p-g2d/g2d.c
index e1936d9d27da..31f6c233b146 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -681,6 +681,7 @@ static int g2d_probe(struct platform_device *pdev)
goto put_clk_gate;
}
 
+   vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
dev->alloc_ctx = vb2_dma_contig_init_ctx(>dev);
if (IS_ERR(dev->alloc_ctx)) {
ret = PTR_ERR(dev->alloc_ctx);
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 4a608cbe0fdb..6bd92f014a23 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2839,6 +2839,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
goto device_register_rollback;
}
 
+   vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
jpeg->alloc_ctx = vb2_dma_contig_init_ctx(>dev);
if (IS_ERR(jpeg->alloc_ctx)) {
v4l2_err(>v4l2_dev, "Failed to init memory allocator\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3ffe2ecfd5ef..3e9cdafe2168 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1143,11 +1143,13 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
}
 
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev_l, DMA_BIT_MASK(32));
dev->alloc_ctx[0] = vb2_dma_contig_init_ctx(dev->mem_dev_l);
if (IS_ERR(dev->alloc_ctx[0])) {
ret = PTR_ERR(dev->alloc_ctx[0]);
goto err_res;
}
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev_r, DMA_BIT_MASK(32));
dev->alloc_ctx[1] = 

[PATCH v3 7/7] media: s5p-mfc: add iommu support

[Marek Szyprowski]

This patch adds support for IOMMU to s5p-mfc device driver. MFC firmware
is limited and it cannot use the default configuration. If IOMMU is
available, the patch disables the default DMA address space
configuration and creates a new address space of size limited to 256M
and base address set to 0x2000.

For now the same address space is shared by both 'left' and 'right'
memory channels, because the DMA/IOMMU frameworks do not support
configuring them separately. This is not optimal, but besides limiting
total address space available has no other drawbacks (MFC firmware
supports 256M of address space per each channel).

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 24 
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 ++
 2 files changed, 103 insertions(+)
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 306344994c8e..bae7c0f7bfd4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_dec.h"
 #include "s5p_mfc_enc.h"
 #include "s5p_mfc_intr.h"
+#include "s5p_mfc_iommu.h"
 #include "s5p_mfc_opr.h"
 #include "s5p_mfc_cmd.h"
 #include "s5p_mfc_pm.h"
@@ -1061,6 +1062,22 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
struct device *dev = _dev->plat_dev->dev;
 
/*
+* When IOMMU is available, we cannot use the default configuration,
+* because of MFC firmware requirements: address space limited to
+* 256M and non-zero default start address.
+* This is still simplified, not optimal configuration, but for now
+* IOMMU core doesn't allow to configure device's IOMMUs channel
+* separately.
+*/
+   if (exynos_is_iommu_available(dev)) {
+   int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
+S5P_MFC_IOMMU_DMA_SIZE);
+   if (ret == 0)
+   mfc_dev->mem_dev_l = mfc_dev->mem_dev_r = dev;
+   return ret;
+   }
+
+   /*
 * Create and initialize virtual devices for accessing
 * reserved memory regions.
 */
@@ -1078,6 +1095,13 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 
 static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
 {
+   struct device *dev = _dev->plat_dev->dev;
+
+   if (exynos_is_iommu_available(dev)) {
+   exynos_unconfigure_iommu(dev);
+   return;
+   }
+
device_unregister(mfc_dev->mem_dev_l);
device_unregister(mfc_dev->mem_dev_r);
 }
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
new file mode 100644
index ..5d1d1c2922e8
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co.Ltd
+ * Authors: Marek Szyprowski 
+ *
+ * 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.
+ */
+
+#ifndef S5P_MFC_IOMMU_H_
+#define S5P_MFC_IOMMU_H_
+
+#define S5P_MFC_IOMMU_DMA_BASE 0x2000lu
+#define S5P_MFC_IOMMU_DMA_SIZE SZ_256M
+
+#ifdef CONFIG_EXYNOS_IOMMU
+
+#include 
+
+static inline bool exynos_is_iommu_available(struct device *dev)
+{
+   return dev->archdata.iommu != NULL;
+}
+
+static inline void exynos_unconfigure_iommu(struct device *dev)
+{
+   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+   arm_iommu_detach_device(dev);
+   arm_iommu_release_mapping(mapping);
+}
+
+static inline int exynos_configure_iommu(struct device *dev,
+unsigned int base, unsigned int size)
+{
+   struct dma_iommu_mapping *mapping = NULL;
+   int ret;
+
+   /* Disable the default mapping created by device core */
+   if (to_dma_iommu_mapping(dev))
+   exynos_unconfigure_iommu(dev);
+
+   mapping = arm_iommu_create_mapping(dev->bus, base, size);
+   if (IS_ERR(mapping)) {
+   pr_warn("Failed to create IOMMU mapping for device %s\n",
+   dev_name(dev));
+   return PTR_ERR(mapping);
+   }
+
+   ret = arm_iommu_attach_device(dev, mapping);
+   if (ret) {
+   pr_warn("Failed to attached device %s to IOMMU_mapping\n",
+   dev_name(dev));
+   arm_iommu_release_mapping(mapping);
+   return ret;
+   }
+
+   return 0;
+}
+
+#else
+
+static inline bool exynos_is_iommu_available(struct device 

[PATCH v3 3/7] of: reserved_mem: add support for named reserved mem nodes

[Marek Szyprowski]

This patch allows device drivers to initialize more than one reserved
memory region assigned to given device. When driver needs to use more
than one reserved memory region, it should allocate child devices and
initialize regions by index or name for each of its child devices.

Signed-off-by: Marek Szyprowski 
---
 .../bindings/reserved-memory/reserved-memory.txt   |   2 +
 .../devicetree/bindings/resource-names.txt |   1 +
 drivers/of/of_reserved_mem.c   | 104 +
 include/linux/of_reserved_mem.h|  31 +-
 4 files changed, 115 insertions(+), 23 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 3da0ebdba8d9..43a14957fd64 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -74,6 +74,8 @@ Regions in the /reserved-memory node may be referenced by 
other device
 nodes by adding a memory-region property to the device node.
 
 memory-region (optional) - phandle, specifier pairs to children of 
/reserved-memory
+memory-region-names (optional) - supplemental names property, provide array of
+names to identify memory regions
 
 Example
 ---
diff --git a/Documentation/devicetree/bindings/resource-names.txt 
b/Documentation/devicetree/bindings/resource-names.txt
index e280fef6f265..51823e99b983 100644
--- a/Documentation/devicetree/bindings/resource-names.txt
+++ b/Documentation/devicetree/bindings/resource-names.txt
@@ -12,6 +12,7 @@ Resource Property Supplemental Names Property
 regreg-names
 clocks clock-names
 interrupts interrupt-names
+memory-region  memory-region-names
 
 Usage:
 
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a3556a9e9ea..c58b362aaa63 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_RESERVED_REGIONS   16
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -287,53 +288,116 @@ static inline struct reserved_mem *__find_rmem(struct 
device_node *node)
return NULL;
 }
 
+struct rmem_assigned_device {
+   struct device *dev;
+   struct reserved_mem *rmem;
+   struct list_head list;
+};
+
+static LIST_HEAD(of_rmem_assigned_device_list);
+static DEFINE_MUTEX(of_rmem_assigned_device_mutex);
+
 /**
  * of_reserved_mem_device_init() - assign reserved memory region to given 
device
+ * @dev:   Pointer to the device to configure
+ * @np:Pointer to the device_node with 'reserved-memory' 
property
+ * @idx:   Index of selected region
+ *
+ * This function assigns respective DMA-mapping operations based on reserved
+ * memory region specified by 'memory-region' property in @np node to the @dev
+ * device. When driver needs to use more than one reserved memory region, it
+ * should allocate child devices and initialize regions by name for each of
+ * child device.
  *
- * This function assign memory region pointed by "memory-region" device tree
- * property to the given device.
+ * Returns error code or zero on success.
  */
-int of_reserved_mem_device_init(struct device *dev)
+int of_reserved_mem_init(struct device *dev, struct device_node *np, int idx)
 {
+   struct rmem_assigned_device *rd;
+   struct device_node *target;
struct reserved_mem *rmem;
-   struct device_node *np;
int ret;
 
-   np = of_parse_phandle(dev->of_node, "memory-region", 0);
-   if (!np)
-   return -ENODEV;
+   if (!np || !dev)
+   return -EINVAL;
+
+   target = of_parse_phandle(np, "memory-region", idx);
+   if (!target)
+   return -EINVAL;
 
-   rmem = __find_rmem(np);
-   of_node_put(np);
+   rmem = __find_rmem(target);
+   of_node_put(target);
 
if (!rmem || !rmem->ops || !rmem->ops->device_init)
return -EINVAL;
 
+   rd = kmalloc(sizeof(struct rmem_assigned_device), GFP_KERNEL);
+   if (!rd)
+   return -ENOMEM;
+
ret = rmem->ops->device_init(rmem, dev);
-   if (ret == 0)
+   if (ret == 0) {
+   rd->dev = dev;
+   rd->rmem = rmem;
+
+   mutex_lock(_rmem_assigned_device_mutex);
+   list_add(>list, _rmem_assigned_device_list);
+   mutex_unlock(_rmem_assigned_device_mutex);
+
dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
+   } else {
+   kfree(rd);
+   }
 
return ret;
 }
-EXPORT_SYMBOL_GPL(of_reserved_mem_device_init);
+EXPORT_SYMBOL_GPL(of_reserved_mem_init);
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given 

[PATCH v3 1/7] ARM: Exynos: convert MFC device to generic reserved memory bindings

[Marek Szyprowski]

This patch replaces custom properties for definining reserved memory
regions with generic reserved memory bindings. All custom code for
handling MFC-specific reserved memory can be now removed from Exynos-DT
generic board code.

Signed-off-by: Marek Szyprowski 
---
 .../devicetree/bindings/media/s5p-mfc.txt  | 16 ++--
 arch/arm/boot/dts/exynos4210-origen.dts| 22 -
 arch/arm/boot/dts/exynos4210-smdkv310.dts  | 22 -
 arch/arm/boot/dts/exynos4412-origen.dts| 22 -
 arch/arm/boot/dts/exynos4412-smdk4412.dts  | 22 -
 arch/arm/boot/dts/exynos5250-arndale.dts   | 22 -
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 22 -
 arch/arm/boot/dts/exynos5250-spring.dts| 22 -
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 22 -
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 22 -
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 -
 arch/arm/mach-exynos/Makefile  |  2 -
 arch/arm/mach-exynos/exynos.c  | 19 -
 arch/arm/mach-exynos/mfc.h | 16 
 arch/arm/mach-exynos/s5p-dev-mfc.c | 94 --
 15 files changed, 208 insertions(+), 159 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/mfc.h
 delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2d5787eac91a..4603673c593b 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -21,16 +21,16 @@ Required properties:
   - clock-names : from common clock binding: must contain "mfc",
  corresponding to entry in the clocks property.
 
-  - samsung,mfc-r : Base address of the first memory bank used by MFC
-   for DMA contiguous memory allocation and its size.
-
-  - samsung,mfc-l : Base address of the second memory bank used by MFC
-   for DMA contiguous memory allocation and its size.
-
 Optional properties:
   - power-domains : power-domain property defined with a phandle
   to respective power domain.
 
+  - memory-region : from reserved memory binding: phandles to two reserved
+   memory regions: accessed by "left" and "right" mfc memory bus
+   interfaces, used when no SYSMMU support is available
+  - memory-region-names : from reserved memory binding: must be "left"
+   and "right"
+
 Example:
 SoC specific DT entry:
 
@@ -46,6 +46,6 @@ mfc: codec@1340 {
 Board specific DT entry:
 
 codec@1340 {
-   samsung,mfc-r = <0x4300 0x80>;
-   samsung,mfc-l = <0x5100 0x80>;
+   memory-region = <_left>, <_right>;
+   memory-region-names = "left", "right";
 };
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index 5821ad87e32c..4b7637dfa392 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -30,6 +30,24 @@
   0x7000 0x1000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mfc_left: region@5100 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x5100 0x80>;
+   };
+
+   mfc_right: region@4300 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x4300 0x80>;
+   };
+   };
+
chosen {
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC2,115200 init=/linuxrc";
stdout-path = _2;
@@ -288,8 +306,8 @@
 };
 
  {
-   samsung,mfc-r = <0x4300 0x80>;
-   samsung,mfc-l = <0x5100 0x80>;
+   memory-region = <_left>, <_right>;
+   memory-region-names = "left", "right";
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 104cbb33d2bb..efafc5721817 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -26,6 +26,24 @@
reg = <0x4000 0x8000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mfc_left: region@5100 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x5100 0x80>;
+   };
+
+   mfc_right: region@4300 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x4300 

[PATCH v3 6/7] media: s5p-mfc: replace custom reserved memory init code with generic one

[Marek Szyprowski]

This patch removes custom code for initialization and handling of
reserved memory regions in s5p-mfc driver and replaces it with generic
named reserved memory regions specified in device tree.

s5p-mfc driver now handles two reserved memory regions: "left" and
"right", defined by generic reserved memory bindings. Support for non-dt
platform has been removed, because all supported platforms have been
converted to device tree.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 129 +++
 1 file changed, 62 insertions(+), 67 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3e9cdafe2168..306344994c8e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "s5p_mfc_common.h"
 #include "s5p_mfc_ctrl.h"
@@ -1022,55 +1023,67 @@ static const struct v4l2_file_operations s5p_mfc_fops = 
{
.mmap = s5p_mfc_mmap,
 };
 
-static int match_child(struct device *dev, void *data)
+/* DMA memory related helper functions */
+static void s5p_mfc_memdev_release(struct device *dev)
 {
-   if (!dev_name(dev))
-   return 0;
-   return !strcmp(dev_name(dev), (char *)data);
+   of_reserved_mem_device_release(dev);
 }
 
-static void *mfc_get_drv_data(struct platform_device *pdev);
-
-static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
+static struct device *s5p_mfc_alloc_memdev(struct device *dev, const char 
*name)
 {
-   unsigned int mem_info[2] = { };
+   struct device *child;
+   int ret;
 
-   dev->mem_dev_l = devm_kzalloc(>plat_dev->dev,
-   sizeof(struct device), GFP_KERNEL);
-   if (!dev->mem_dev_l) {
-   mfc_err("Not enough memory\n");
-   return -ENOMEM;
-   }
-   device_initialize(dev->mem_dev_l);
-   of_property_read_u32_array(dev->plat_dev->dev.of_node,
-   "samsung,mfc-l", mem_info, 2);
-   if (dma_declare_coherent_memory(dev->mem_dev_l, mem_info[0],
-   mem_info[0], mem_info[1],
-   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
-   mfc_err("Failed to declare coherent memory for\n"
-   "MFC device\n");
-   return -ENOMEM;
+   child = devm_kzalloc(dev, sizeof(struct device), GFP_KERNEL);
+   if (!child)
+   return NULL;
+
+   device_initialize(child);
+   dev_set_name(child, "%s:%s", dev_name(dev), name);
+   child->parent = dev;
+   child->bus = dev->bus;
+   child->coherent_dma_mask = dev->coherent_dma_mask;
+   child->dma_mask = dev->dma_mask;
+   child->release = s5p_mfc_memdev_release;
+
+   if (device_add(child) == 0) {
+   ret = of_reserved_mem_init_by_name(child, dev->of_node, name);
+   if (ret == 0)
+   return child;
}
 
-   dev->mem_dev_r = devm_kzalloc(>plat_dev->dev,
-   sizeof(struct device), GFP_KERNEL);
-   if (!dev->mem_dev_r) {
-   mfc_err("Not enough memory\n");
-   return -ENOMEM;
-   }
-   device_initialize(dev->mem_dev_r);
-   of_property_read_u32_array(dev->plat_dev->dev.of_node,
-   "samsung,mfc-r", mem_info, 2);
-   if (dma_declare_coherent_memory(dev->mem_dev_r, mem_info[0],
-   mem_info[0], mem_info[1],
-   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
-   pr_err("Failed to declare coherent memory for\n"
-   "MFC device\n");
-   return -ENOMEM;
+   put_device(child);
+   return NULL;
+}
+
+static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+   struct device *dev = _dev->plat_dev->dev;
+
+   /*
+* Create and initialize virtual devices for accessing
+* reserved memory regions.
+*/
+   mfc_dev->mem_dev_l = s5p_mfc_alloc_memdev(dev, "left");
+   if (!mfc_dev->mem_dev_l)
+   return -ENODEV;
+   mfc_dev->mem_dev_r = s5p_mfc_alloc_memdev(dev, "right");
+   if (!mfc_dev->mem_dev_r) {
+   device_unregister(mfc_dev->mem_dev_l);
+   return -ENODEV;
}
+
return 0;
 }
 
+static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+   device_unregister(mfc_dev->mem_dev_l);
+   device_unregister(mfc_dev->mem_dev_r);
+}
+
+static void *mfc_get_drv_data(struct platform_device *pdev);
+
 /* MFC probe function */
 static int s5p_mfc_probe(struct platform_device *pdev)
 {
@@ -1096,12 +1109,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
 
dev->variant = mfc_get_drv_data(pdev);
 
-   ret = s5p_mfc_init_pm(dev);
-   if (ret < 0) {
-   dev_err(>dev, 

[PATCH v3 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Marek Szyprowski]

Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
Odroid boards.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca9601e..349e6cc51283 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -18,6 +18,24 @@
stdout-path = _1;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mfc_left: region@5100 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x5100 0x80>;
+   };
+
+   mfc_right: region@4300 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x4300 0x80>;
+   };
+   };
+
firmware@0204F000 {
compatible = "samsung,secure-firmware";
reg = <0x0204F000 0x1000>;
@@ -447,6 +465,12 @@
clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
 };
 
+ {
+   memory-region = <_left>, <_right>;
+   memory-region-names = "left", "right";
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
1.9.2

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

Re: per-frame camera metadata (again)

[Guennadi Liakhovetski]

Hi Hans,

Thanks for your comments.

On Wed, 16 Dec 2015, Hans Verkuil wrote:

> On 12/16/15 10:37, Guennadi Liakhovetski wrote:
> > Hi all,
> > 
> > A project, I am currently working on, requires acquiringing per-frame 
> > metadata from the camera and passing it to user-space. This is not the 
> > first time this comes up and I know such discussions have been held 
> > before. A typical user is Android (also my case), where you have to 
> > provide parameter values, that have been used to capture a specific frame, 
> > to the user. I know Hans is working to handle one side of this process - 
> > sending per-request controls,
> 
> Actually, the request framework can do both sides of the equation: giving
> back meta data in read-only controls that are per-frame. While ideally the
> driver would extract the information from the binary blob and put it in
> nice controls, it is also possible to make a control that just contains the
> binary blob itself. Whether that's a good approach depends on many factors
> and that's another topic.

Yes, sorry, didn't mention this possibility. On the one hand I agree, that 
this would look nice and consistent - you send a bunch of controls down 
and you get them back in exactly the same way, nicely taken apart. OTOH 
there are some issues with that:

1. Metadata values can indeed come from the camera in a buffer, that's 
DMAed to a buffer by the bridge - we have such examples. In our use-cases 
those buffers are separate from main data, so, that the driver could 
allocate them itself, but can there be cases, in which those buffers have 
to be supplied by the user?

2. Size - not sure how large those control buffers can become, in 
use-cases, that I'm aware of we transfer up to 20 single-value parameters 
per frame.

3. With control values delivered per DMA, it's the bridge driver, that 
gets the data, but it's the sensor subdevice driver, that knows what that 
buffer contains. So, to deliver those parameters to the user, the sensor 
driver control processing routines will have to get access to that 
metadata buffer. This isn't supported so far even with the proposed 
request API?

> > but I'm not aware whether he or anyone else
> > is actively working on this already or is planning to do so in the near 
> > future? I also know, that several proprietary solutions have been 
> > developed and are in use in various projects.
> > 
> > I think a general agreement has been, that such data has to be passed via 
> > a buffer queue. But there are a few possibilities there too. Below are 
> > some:
> > 
> > 1. Multiplanar. A separate plane is dedicated to metadata. Pros: (a) 
> > metadata is already associated to specific frames, which they correspond 
> > to. Cons: (a) a correct implementation would specify image plane fourcc 
> > separately from any metadata plane format description, but we currently 
> > don't support per-plane format specification.
> 
> This only makes sense if the data actually comes in via DMA and if it is
> large enough to make it worth the effort of implementing this. As you say,
> it will require figuring out how to do per-frame fourcc.
> 
> It also only makes sense if the metadata comes in at the same time as the
> frame.
> 
> > 2. Separate buffer queues. Pros: (a) no need to extend multiplanar buffer 
> > implementation. Cons: (a) more difficult synchronisation with image 
> > frames, (b) still need to work out a way to specify the metadata version.
> > 
> > Any further options? Of the above my choice would go with (1) but with a 
> > dedicated metadata plane in struct vb2_buffer.
> 
> 3. Use the request framework and return the metadata as control(s). Since 
> controls
> can be associated with events when they change you can subscribe to such 
> events.
> Note: currently I haven't implemented such events for request controls since 
> I am
> not certainly how it would be used, but this would be a good test case.
> 
> Pros: (a) no need to extend multiplanar buffer implementation, (b) syncing up
> with the image frames should be easy (both use the same request ID), (c) a lot
> of freedom on how to export the metadata. Cons: (a) request framework is still
> work in progress (currently worked on by Laurent), (b) probably too slow for
> really large amounts of metadata, you'll need proper DMA handling for that in
> which case I would go for 2.

For (2) (separate buffer queue) would we have to extend VIDIOC_DQBUF to 
select a specific buffer queue?

> > In either of the above options we also need a way to tell the user what is 
> > in the metadata buffer, its format. We could create new FOURCC codes for 
> > them, perhaps as V4L2_META_FMT_... or the user space could identify the 
> > metadata format based on the camera model and an opaque type (metadata 
> > version code) value. Since metadata formats seem to be extremely camera- 
> > specific, I'd go with the latter option.
> > 
> > Comments extremely welcome.
> 
> What I like about the request framework is 

per-frame camera metadata (again)

[Guennadi Liakhovetski]

Hi all,

A project, I am currently working on, requires acquiringing per-frame 
metadata from the camera and passing it to user-space. This is not the 
first time this comes up and I know such discussions have been held 
before. A typical user is Android (also my case), where you have to 
provide parameter values, that have been used to capture a specific frame, 
to the user. I know Hans is working to handle one side of this process - 
sending per-request controls, but I'm not aware whether he or anyone else 
is actively working on this already or is planning to do so in the near 
future? I also know, that several proprietary solutions have been 
developed and are in use in various projects.

I think a general agreement has been, that such data has to be passed via 
a buffer queue. But there are a few possibilities there too. Below are 
some:

1. Multiplanar. A separate plane is dedicated to metadata. Pros: (a) 
metadata is already associated to specific frames, which they correspond 
to. Cons: (a) a correct implementation would specify image plane fourcc 
separately from any metadata plane format description, but we currently 
don't support per-plane format specification.

2. Separate buffer queues. Pros: (a) no need to extend multiplanar buffer 
implementation. Cons: (a) more difficult synchronisation with image 
frames, (b) still need to work out a way to specify the metadata version.

Any further options? Of the above my choice would go with (1) but with a 
dedicated metadata plane in struct vb2_buffer.

In either of the above options we also need a way to tell the user what is 
in the metadata buffer, its format. We could create new FOURCC codes for 
them, perhaps as V4L2_META_FMT_... or the user space could identify the 
metadata format based on the camera model and an opaque type (metadata 
version code) value. Since metadata formats seem to be extremely camera- 
specific, I'd go with the latter option.

Comments extremely welcome.

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

[GIT PULL FOR v4.5] uvcvideo fixes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 991ce92f8de24cde063d531246602b6e14d3fef2:

  [media] use https://linuxtv.org for LinuxTV URLs (2015-12-04 10:38:59 -0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git uvc/next

for you to fetch changes up to 0f7c221741d0bd27aa658604fa5e1a660de87115:

  uvcvideo: small cleanup in uvc_video_clock_update() (2015-12-14 04:00:19 
+0200)


Anton V. Shokurov (1):
  uvcvideo: Fix reading the current exposure value of UVC

Dan Carpenter (1):
  uvcvideo: small cleanup in uvc_video_clock_update()

 drivers/media/usb/uvc/uvc_ctrl.c  | 3 ++-
 drivers/media/usb/uvc/uvc_video.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] android: fix warning when releasing active sync point

[Maarten Lankhorst]

Op 15-12-15 om 18:19 schreef Dmitry Torokhov:
> On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst
>  wrote:
>> Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
>>> Userspace can close the sync device while there are still active fence
>>> points, in which case kernel produces the following warning:
>>>
>>> [   43.853176] [ cut here ]
>>> [   43.857834] WARNING: CPU: 0 PID: 892 at 
>>> /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
>>>  android_fence_release+0x88/0x104()
>>> [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
>>> 3.18.0-07661-g0550ce9 #1
>>> [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
>>> [   43.885834] Call trace:
>>> [   43.888294] [] dump_backtrace+0x0/0x10c
>>> [   43.893697] [] show_stack+0x10/0x1c
>>> [   43.898756] [] dump_stack+0x74/0xb8
>>> [   43.903814] [] warn_slowpath_common+0x84/0xb0
>>> [   43.909736] [] warn_slowpath_null+0x14/0x20
>>> [   43.915482] [] android_fence_release+0x84/0x104
>>> [   43.921582] [] fence_release+0x104/0x134
>>> [   43.927066] [] sync_fence_free+0x74/0x9c
>>> [   43.932552] [] sync_fence_release+0x34/0x48
>>> [   43.938304] [] __fput+0x100/0x1b8
>>> [   43.943185] [] fput+0x8/0x14
>>> [   43.947982] [] task_work_run+0xb0/0xe4
>>> [   43.953297] [] do_notify_resume+0x44/0x5c
>>> [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
>>>
>>> Let's fix it by introducing a new optional callback (disable_signaling)
>>> to fence operations so that drivers can do proper clean ups when we
>>> remove last callback for given fence.
>>>
>>> Reviewed-by: Andrew Bresticker 
>>> Signed-off-by: Dmitry Torokhov 
>>>
>> NACK! There's no way to do this race free.
> Can you please explain the race because as far as I can see there is not one.\
The entire code in fence.c assumes that a fence can only go from not 
enable_signaling to .enable_signaling. .enable_signaling is not refcounted so 2 
calls to .enable_disabling and 1 to .disable_signaling would mess up.
Furthermore we try to make sure that fence_signal doesn't take locks if its 
unneeded. With a disable_signaling callback you would always need locks.

To get rid of these warnings make sure that there's a refcount on the fence 
until it's signaled.
>> The driver should hold a refcount until fence is signaled.
> If we are no longer interested in fence why do we need to wait for the
> fence to be signaled?
It's the part of the design. A driver tracks its outstanding requests and 
submissions, and every submission has its own fence. Before the driver releases 
its final ref the request should be completed or aborted. In either case it 
must call fence_signal.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/32] VSP: Add R-Car Gen3 support

[Geert Uytterhoeven]

Hi Laurent,

On Sat, Dec 5, 2015 at 11:54 PM, Laurent Pinchart
 wrote:
> On Saturday 05 December 2015 11:57:49 Geert Uytterhoeven wrote:
>> As http://git.linuxtv.org/pinchartl/media.git/tag/?id=vsp1-kms-20151112 is
>> getting old, and has lots of conflicts with recent -next, do you plan to
>> publish this in a branch, and a separate branch for integration, to ease
>> integration in renesas-drivers?
>>
>> Alternatively, I can just import the series you posted, but having the
>> broken-out integration part would be nice.
>
> The issue I'm facing is that there's more than just two series. Beside the
> base VSP patches from this series, I have a series of DRM patches that depend
> on this one, a series of V4L2 core patches, another series of VSP patches that
> I still need to finish and a bunch of integration patches. As some of these
> have dependencies on H3 CCF support that hasn't landed in Simon's tree yet, I
> have merged your topic/cpg-mssr-v6 and topic/r8a7795-drivers-sh-v1 branches
> into my tree for development.
>
> I could keep all series in separate branches and merge the two topic branches
> last, but that's not very handy during development when I have to continuously
> rebase my patches. Is there a way I could handle this that would make your
> life easier while not making mine more difficult ?

I feel your pain...

For development, committing to a single branch and rebasing interactively is
also my workflow. But after a few 100 commits, rebasing takes a long time.
And you can't publish that tree.

I started moving "finished" stuff to separate topic branches (this is the
stuff published/imported into renesas-drivers topic branches, or kept in
private branches for the parts I don't want to publish it yet), and merging
them early on.
Actual development is still done on top with frequent rebasing.

The problem starts when updating that. Instead of a simple rebase -i, it now
involves:
  - Duplicating the old topic branch, version number increased,
  - Interactively rebasing the new topic branch, including/squashing commits
from recent development,
  - Merging in the new topic branch "early on", and rebasing all other private
development on top of that.
For "big" changes that's OK. For adding a bunch of Acked-by's it's a lot of
work.

> In the meantime I've pushed vsp1-kms-20151206 to
> git://linuxtv.org/pinchartl/media.git.

Hadn't thanked you yet for that: Thanks!

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.5] Renesas VSP1 improvements and fixes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 52d60eb7e6d6429a766ea1b8f67e01c3b2dcd3c5:

  Revert "[media] UVC: Add support for ds4 depth camera" (2015-12-12 08:10:40 
-0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git vsp1/next

for you to fetch changes up to 41db244b5b484f3f2afc1834552d6771f05c2ebe:

  v4l: vsp1: Add display list support (2015-12-16 10:37:47 +0200)


Laurent Pinchart (31):
  v4l: vsp1: Change the type of the rwpf field in struct vsp1_video
  v4l: vsp1: Store the memory format in struct vsp1_rwpf
  v4l: vsp1: Move video operations to vsp1_rwpf
  v4l: vsp1: Rename vsp1_video_buffer to vsp1_vb2_buffer
  v4l: vsp1: Move video device out of struct vsp1_rwpf
  v4l: vsp1: Make rwpf operations independent of video device
  v4l: vsp1: Support VSP1 instances without any UDS
  v4l: vsp1: Move vsp1_video pointer from vsp1_entity to vsp1_rwpf
  v4l: vsp1: Remove struct vsp1_pipeline num_video field
  v4l: vsp1: Decouple pipeline end of frame processing from vsp1_video
  v4l: vsp1: Split pipeline management code from vsp1_video.c
  v4l: vsp1: Rename video pipeline functions to use vsp1_video prefix
  v4l: vsp1: Extract pipeline initialization code into a function
  v4l: vsp1: Reuse local variable instead of recomputing it
  v4l: vsp1: Extract link creation to separate function
  v4l: vsp1: Document the vsp1_pipeline structure
  v4l: vsp1: Fix typo in VI6_DISP_IRQ_STA_DST register bit name
  v4l: vsp1: Set the SRU CTRL0 register when starting the stream
  v4l: vsp1: Remove unused module read functions
  v4l: vsp1: Move entity route setup function to vsp1_entity.c
  v4l: vsp1: Make number of BRU inputs configurable
  v4l: vsp1: Make the BRU optional
  v4l: vsp1: Move format info to vsp1_pipe.c
  v4l: vsp1: Make the userspace API optional
  v4l: vsp1: Make pipeline inputs array index by RPF index
  v4l: vsp1: Set the alpha value manually in RPF and WPF s_stream handlers
  v4l: vsp1: Don't validate links when the userspace API is disabled
  v4l: vsp1: Add VSP+DU support
  v4l: vsp1: Disconnect unused RPFs from the DRM pipeline
  v4l: vsp1: Implement atomic update for the DRM driver
  v4l: vsp1: Add support for the R-Car Gen3 VSP2

Takashi Saito (1):
  v4l: vsp1: Add display list support

 .../devicetree/bindings/media/renesas,vsp1.txt  |  21 +-
 drivers/media/platform/vsp1/Makefile|   3 +-
 drivers/media/platform/vsp1/vsp1.h  |  24 +
 drivers/media/platform/vsp1/vsp1_bru.c  |  33 +-
 drivers/media/platform/vsp1/vsp1_bru.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_dl.c   | 304 
 drivers/media/platform/vsp1/vsp1_dl.h   |  42 ++
 drivers/media/platform/vsp1/vsp1_drm.c  | 597 +++
 drivers/media/platform/vsp1/vsp1_drm.h  |  38 ++
 drivers/media/platform/vsp1/vsp1_drv.c  | 254 --
 drivers/media/platform/vsp1/vsp1_entity.c   |  31 +-
 drivers/media/platform/vsp1/vsp1_entity.h   |  14 +-
 drivers/media/platform/vsp1/vsp1_hsit.c |   2 +-
 drivers/media/platform/vsp1/vsp1_lif.c  |  11 +-
 drivers/media/platform/vsp1/vsp1_lut.c  |   7 +-
 drivers/media/platform/vsp1/vsp1_pipe.c | 405 ++
 drivers/media/platform/vsp1/vsp1_pipe.h | 134 ++
 drivers/media/platform/vsp1/vsp1_regs.h |  32 +-
 drivers/media/platform/vsp1/vsp1_rpf.c  |  77 ++-
 drivers/media/platform/vsp1/vsp1_rwpf.h |  24 +-
 drivers/media/platform/vsp1/vsp1_sru.c  |   9 +-
 drivers/media/platform/vsp1/vsp1_uds.c  |   8 +-
 drivers/media/platform/vsp1/vsp1_video.c| 516 +++
 drivers/media/platform/vsp1/vsp1_video.h| 111 +
 drivers/media/platform/vsp1/vsp1_wpf.c  |  88 ++--
 include/media/vsp1.h|  33 ++
 26 files changed, 2071 insertions(+), 750 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_dl.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_dl.h
 create mode 100644 drivers/media/platform/vsp1/vsp1_drm.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_drm.h
 create mode 100644 drivers/media/platform/vsp1/vsp1_pipe.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_pipe.h

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 03/22] media: Add an API to manage entity enumerations

[Mauro Carvalho Chehab]

Em Wed, 16 Dec 2015 01:16:30 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Sun, Dec 13, 2015 at 10:54:57PM -0200, Mauro Carvalho Chehab wrote:
> > > >> +  e->idx_max = idx_max;
> > > >> +
> > > >> +  return 0;
> > > >> +}
> > > >> +EXPORT_SYMBOL_GPL(__media_entity_enum_init);
> > > >> +
> > > >> +/**
> > > >> + * media_entity_enum_cleanup - Release resources of an entity 
> > > >> enumeration
> > > >> + *
> > > >> + * @e: Entity enumeration to be released
> > > >> + */
> > > >> +void media_entity_enum_cleanup(struct media_entity_enum *e)
> > > >> +{
> > > >> +  if (e->e != e->__e)
> > > >> +  kfree(e->e);
> > > >> +  e->e = NULL;
> > > >> +}
> > > >> +EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
> > > >> +
> > > >> +/**
> > > >>   * media_entity_init - Initialize a media entity
> > > >>   *
> > > >>   * @num_pads: Total number of sink and source pads.
> > > >> diff --git a/include/media/media-device.h 
> > > >> b/include/media/media-device.h
> > > >> index c0e1764..2d46c66 100644
> > > >> --- a/include/media/media-device.h
> > > >> +++ b/include/media/media-device.h
> > > >> @@ -110,6 +110,20 @@ struct media_device {
> > > >>  /* media_devnode to media_device */
> > > >>  #define to_media_device(node) container_of(node, struct media_device, 
> > > >> devnode)
> > > >>  
> > > >> +/**
> > > >> + * media_entity_enum_init - Initialise an entity enumeration
> > > >> + *
> > > >> + * @e: Entity enumeration to be initialised
> > > >> + * @mdev: The related media device
> > > >> + *
> > > >> + * Returns zero on success or a negative error code.
> > > >> + */
> > > >> +static inline __must_check int media_entity_enum_init(
> > > >> +  struct media_entity_enum *e, struct media_device *mdev)
> > > >> +{
> > > >> +  return __media_entity_enum_init(e, 
> > > >> mdev->entity_internal_idx_max + 1);
> > > >> +}
> > > >> +
> > > >>  void media_device_init(struct media_device *mdev);
> > > >>  void media_device_cleanup(struct media_device *mdev);
> > > >>  int __must_check __media_device_register(struct media_device *mdev,
> > > >> diff --git a/include/media/media-entity.h 
> > > >> b/include/media/media-entity.h
> > > >> index d3d3a39..5a0339a 100644
> > > >> --- a/include/media/media-entity.h
> > > >> +++ b/include/media/media-entity.h
> > > >> @@ -23,7 +23,7 @@
> > > >>  #ifndef _MEDIA_ENTITY_H
> > > >>  #define _MEDIA_ENTITY_H
> > > >>  
> > > >> -#include 
> > > >> +#include 
> > > >>  #include 
> > > >>  #include 
> > > >>  #include 
> > > >> @@ -71,6 +71,30 @@ struct media_gobj {
> > > >>struct list_headlist;
> > > >>  };
> > > >>  
> > > >> +#define MEDIA_ENTITY_ENUM_MAX_DEPTH   16
> > > >> +#define MEDIA_ENTITY_ENUM_MAX_ID  64
> > > >> +
> > > >> +/*
> > > >> + * The number of pads can't be bigger than the number of entities,
> > > >> + * as the worse-case scenario is to have one entity linked up to
> > > >> + * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
> > > >> + */
> > > >> +#define MEDIA_ENTITY_MAX_PADS (MEDIA_ENTITY_ENUM_MAX_ID - 1)
> > > >> +
> > > >> +/* struct media_entity_enum - An enumeration of media entities.
> > > >> + *
> > > >> + * @__e:  Pre-allocated space reserved for media entities if the 
> > > >> total
> > > >> + *number of entities  does not exceed 
> > > >> MEDIA_ENTITY_ENUM_MAX_ID.
> > > >> + * @e:Bit mask in which each bit represents one 
> > > >> entity at struct
> > > >> + *media_entity->internal_idx.
> > > >> + * @idx_max:  Number of bits in the enum.
> > > >> + */
> > > >> +struct media_entity_enum {
> > > >> +  DECLARE_BITMAP(__e, MEDIA_ENTITY_ENUM_MAX_ID);
> > > >> +  unsigned long *e;
> > > > 
> > > > As mentioned before, don't use single letter names, specially inside
> > > > publicly used structures. There's no good reason for that, and the
> > > > code become really obscure.
> > > > 
> > > > Also, just declare one bitmap. having a "pre-allocated" hardcoded
> > > > one here is very confusing.
> > > 
> > > I prefer to keep it as allocating a few bytes of memory is silly. In the
> > > vast majority of the cases the pre-allocated array will be sufficient.
> > 
> > "vast majority" actually depends on the driver/subsystem. The fact that
> > right now most drivers work fine with < 64 entities may not be
> > true in the future.
> 
> One reason the pre-allocated bitmap shouldn't be removed yet is that by
> doing that, i.e. allocating memory in media_entity_enum_init(), the user
> must check the return code. The further patches in the set make drivers do
> that add __must_check modifier to the prototype.
> 
> I will thus add another patch near the top to remove the pre-allocated
> bitmap.

Works for me.

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

Re: per-frame camera metadata (again)

[Hans Verkuil]

On 12/16/15 10:37, Guennadi Liakhovetski wrote:
> Hi all,
> 
> A project, I am currently working on, requires acquiringing per-frame 
> metadata from the camera and passing it to user-space. This is not the 
> first time this comes up and I know such discussions have been held 
> before. A typical user is Android (also my case), where you have to 
> provide parameter values, that have been used to capture a specific frame, 
> to the user. I know Hans is working to handle one side of this process - 
> sending per-request controls,

Actually, the request framework can do both sides of the equation: giving
back meta data in read-only controls that are per-frame. While ideally the
driver would extract the information from the binary blob and put it in
nice controls, it is also possible to make a control that just contains the
binary blob itself. Whether that's a good approach depends on many factors
and that's another topic.

> but I'm not aware whether he or anyone else
> is actively working on this already or is planning to do so in the near 
> future? I also know, that several proprietary solutions have been 
> developed and are in use in various projects.
> 
> I think a general agreement has been, that such data has to be passed via 
> a buffer queue. But there are a few possibilities there too. Below are 
> some:
> 
> 1. Multiplanar. A separate plane is dedicated to metadata. Pros: (a) 
> metadata is already associated to specific frames, which they correspond 
> to. Cons: (a) a correct implementation would specify image plane fourcc 
> separately from any metadata plane format description, but we currently 
> don't support per-plane format specification.

This only makes sense if the data actually comes in via DMA and if it is
large enough to make it worth the effort of implementing this. As you say,
it will require figuring out how to do per-frame fourcc.

It also only makes sense if the metadata comes in at the same time as the
frame.

> 2. Separate buffer queues. Pros: (a) no need to extend multiplanar buffer 
> implementation. Cons: (a) more difficult synchronisation with image 
> frames, (b) still need to work out a way to specify the metadata version.
> 
> Any further options? Of the above my choice would go with (1) but with a 
> dedicated metadata plane in struct vb2_buffer.

3. Use the request framework and return the metadata as control(s). Since 
controls
can be associated with events when they change you can subscribe to such events.
Note: currently I haven't implemented such events for request controls since I 
am
not certainly how it would be used, but this would be a good test case.

Pros: (a) no need to extend multiplanar buffer implementation, (b) syncing up
with the image frames should be easy (both use the same request ID), (c) a lot
of freedom on how to export the metadata. Cons: (a) request framework is still
work in progress (currently worked on by Laurent), (b) probably too slow for
really large amounts of metadata, you'll need proper DMA handling for that in
which case I would go for 2.

> 
> In either of the above options we also need a way to tell the user what is 
> in the metadata buffer, its format. We could create new FOURCC codes for 
> them, perhaps as V4L2_META_FMT_... or the user space could identify the 
> metadata format based on the camera model and an opaque type (metadata 
> version code) value. Since metadata formats seem to be extremely camera- 
> specific, I'd go with the latter option.
> 
> Comments extremely welcome.

What I like about the request framework is that the driver can pick apart
the metadata and turn it into well-defined controls. So the knowledge how
to do that is in the place where it belongs. In cases where the meta data
is simple too large for that to be feasible, then I don't have much of an
opinion. Camera + version could be enough. Although the same can just as
easily be encoded as a fourcc (V4L2_META_FMT_OV_V1, _V2, etc). A fourcc
is more consistent with the current API.

Regards,

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

Re: [PATCH v2 3/3] [media] mt9v032: Add V4L2 controls for AEC and AGC

[Markus Pargmann]

Hi Laurent,

On Wednesday 16 December 2015 09:47:58 Laurent Pinchart wrote:
> Hi Markus,
> 
> Thank you for the patch.
> 
> On Monday 14 December 2015 15:41:53 Markus Pargmann wrote:
> > This patch adds V4L2 controls for Auto Exposure Control and Auto Gain
> > Control settings. These settings include low pass filter, update
> > frequency of these settings and the update interval for those units.
> > 
> > Signed-off-by: Markus Pargmann 
> 
> Please see below for a few comments. If you agree about them there's no need 
> to resubmit, I'll fix the patch when applying.

Most of them are fine, I commented on the open ones.

> 
> > ---
> >  drivers/media/i2c/mt9v032.c | 153 -
> >  1 file changed, 152 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> > index cc16acf001de..6cbc3b87eda9 100644
> > --- a/drivers/media/i2c/mt9v032.c
> > +++ b/drivers/media/i2c/mt9v032.c
> 
> [snip]
> 
> >  enum mt9v032_model {
> > @@ -162,6 +169,8 @@ struct mt9v032_model_data {
> > unsigned int min_shutter;
> > unsigned int max_shutter;
> > unsigned int pclk_reg;
> > +   unsigned int aec_max_shutter_reg;
> > +   const struct v4l2_ctrl_config * const aec_max_shutter_v4l2_ctrl;
> >  };
> > 
> >  struct mt9v032_model_info {
> > @@ -175,6 +184,9 @@ static const struct mt9v032_model_version
> > mt9v032_versions[] = { { MT9V034_CHIP_ID_REV1, "MT9V024/MT9V034 rev1" },
> >  };
> > 
> > +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width;
> > +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width;
> 
> We can avoid forward declarations by moving the mt9v032_model_data array 
> further down in the driver.
> 
> >  static const struct mt9v032_model_data mt9v032_model_data[] = {
> > {
> > /* MT9V022, MT9V032 revisions 1/2/3 */
> 
> [snip]
> 
> > @@ 647,6 +663,33 @@ static int mt9v032_set_selection(struct v4l2_subdev
> > *subdev, */
> > 
> >  #define V4L2_CID_TEST_PATTERN_COLOR(V4L2_CID_USER_BASE | 0x1001)
> > +/*
> > + * Value between 1 and 64 to set the desired bin. This is effectively a
> > measure + * of how bright the image is supposed to be. Both AGC and AEC try
> > to reach + * this.
> > + */
> > +#define V4L2_CID_AEGC_DESIRED_BIN  (V4L2_CID_USER_BASE | 0x1002)
> > +/*
> > + * LPF is the low pass filter capability of the chip. Both AEC and AGC have
> > + * this setting. This limits the speed in which AGC/AEC adjust their
> > settings.
> > + * Possible values are 0-2. 0 means no LPF. For 1 and 2 this equation is
> > used:
> > + * if |(Calculated new exp - current exp)| > (current exp / 4)
> > + * next exp = Calculated new exp
> > + * else
> > + * next exp = Current exp + ((Calculated new exp - current 
> > exp) / 
> 2^LPF)
> 
> Over 80 columns, you can fix it by just reducing the indentation by one tab.
> 
> > + */
> > +#define V4L2_CID_AEC_LPF   (V4L2_CID_USER_BASE | 0x1003)
> > +#define V4L2_CID_AGC_LPF   (V4L2_CID_USER_BASE | 0x1004)
> > +/*
> > + * Value between 0 and 15. This is the number of frames being skipped
> > before
> > + * updating the auto exposure/gain.
> > + */
> > +#define V4L2_CID_AEC_UPDATE_INTERVAL   (V4L2_CID_USER_BASE | 0x1005)
> > +#define V4L2_CID_AGC_UPDATE_INTERVAL   (V4L2_CID_USER_BASE | 0x1006)
> > +/*
> > + * Maximum shutter width used for AEC.
> > + */
> > +#define V4L2_CID_AEC_MAX_SHUTTER_WIDTH (V4L2_CID_USER_BASE | 0x1007)
> 
> [snip]
> 
> > @@ -745,6 +810,84 @@ static const struct v4l2_ctrl_config
> > mt9v032_test_pattern_color = { .flags   = 0,
> >  };
> > 
> > +static const struct v4l2_ctrl_config mt9v032_aegc_controls[] = {
> > +   {
> > +   .ops= _ctrl_ops,
> > +   .id = V4L2_CID_AEGC_DESIRED_BIN,
> > +   .type   = V4L2_CTRL_TYPE_INTEGER,
> > +   .name   = "aec_agc_desired_bin",
> 
> I forgot to reply to your e-mail asking what proper controls names would be, 
> sorry.
> 
> V4L2 control names contain spaces and use uppercase as needed. This one could 
> be "AEC/AGC Desired Bin" for instance.

Ah I see. I was just wondering as v4l2-ctl showed everything with lowercase
letters and underscores. But with a closer look it seems something between
driver and v4l2-ctl translates them from uppercase/spaces to
lowercase/underscores. So yes that's fine then and makes sense.

> 
> > +   .min= 1,
> > +   .max= 64,
> > +   .step   = 1,
> > +   .def= 58,
> > +   .flags  = 0,
> > +   }, {
> > +   .ops= _ctrl_ops,
> > +   .id = V4L2_CID_AEC_LPF,
> > +   .type   = V4L2_CTRL_TYPE_INTEGER,
> > +   .name   = "aec_lpf",
> > +   .min= 0,
> > +   .max= 2,
> > +   .step   

Re: [PATCH v2 00/32] VSP: Add R-Car Gen3 support

[Laurent Pinchart]

Hi Geert,

On Wednesday 16 December 2015 09:39:29 Geert Uytterhoeven wrote:
> On Sat, Dec 5, 2015 at 11:54 PM, Laurent Pinchart wrote:
> > On Saturday 05 December 2015 11:57:49 Geert Uytterhoeven wrote:
> >> As http://git.linuxtv.org/pinchartl/media.git/tag/?id=vsp1-kms-20151112
> >> is getting old, and has lots of conflicts with recent -next, do you plan
> >> to publish this in a branch, and a separate branch for integration, to
> >> ease integration in renesas-drivers?
> >> 
> >> Alternatively, I can just import the series you posted, but having the
> >> broken-out integration part would be nice.
> > 
> > The issue I'm facing is that there's more than just two series. Beside the
> > base VSP patches from this series, I have a series of DRM patches that
> > depend on this one, a series of V4L2 core patches, another series of VSP
> > patches that I still need to finish and a bunch of integration patches.
> > As some of these have dependencies on H3 CCF support that hasn't landed
> > in Simon's tree yet, I have merged your topic/cpg-mssr-v6 and
> > topic/r8a7795-drivers-sh-v1 branches into my tree for development.
> > 
> > I could keep all series in separate branches and merge the two topic
> > branches last, but that's not very handy during development when I have
> > to continuously rebase my patches. Is there a way I could handle this
> > that would make your life easier while not making mine more difficult ?
> 
> I feel your pain...
> 
> For development, committing to a single branch and rebasing interactively is
> also my workflow. But after a few 100 commits, rebasing takes a long time.
> And you can't publish that tree.
> 
> I started moving "finished" stuff to separate topic branches (this is the
> stuff published/imported into renesas-drivers topic branches, or kept in
> private branches for the parts I don't want to publish it yet), and merging
> them early on.

The issue here is that there is only a single batch of patches I consider as 
finished, and those are already present in a branch based directly on top of 
linuxtv/master that I then merge into my working branches. On a side note I've 
now sent a pull request for that.

The rest is not considered finished yet, I've modified the oldest branches no 
later than today. The code is stabilizing though, and I expect to send a pull 
request for a first batch of DU patches after the v4.5 merge window closes.

> Actual development is still done on top with frequent rebasing.
> 
> The problem starts when updating that. Instead of a simple rebase -i, it now
> involves:
>   - Duplicating the old topic branch, version number increased,
>   - Interactively rebasing the new topic branch, including/squashing commits
> from recent development,
>   - Merging in the new topic branch "early on", and rebasing all other
> private development on top of that.
> For "big" changes that's OK. For adding a bunch of Acked-by's it's a lot of
> work.
> 
> > In the meantime I've pushed vsp1-kms-20151206 to
> > git://linuxtv.org/pinchartl/media.git.
> 
> Hadn't thanked you yet for that: Thanks!

You're welcome, and there's now vsp1-kms-20151216 :-)

-- 
Regards,

Laurent Pinchart

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