[PATCH] bdisp: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vdev list.So no need to call 
v4l2_fh_del(>fh)if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index 45f82b5..fbf302f 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -632,8 +632,8 @@ static int bdisp_open(struct file *file)
 
 error_ctrls:
bdisp_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(>fh);
+error_fh:
v4l2_fh_exit(>fh);
bdisp_hw_free_nodes(ctx);
 mem_ctx:
-- 
1.7.9.5

--
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] exynos-gsc: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vfd list.So no need to call
v4l2_fh_del(>fh) if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c 
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 9f03b79..5ea97c1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file)
 
 error_ctrls:
gsc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(>fh);
+error_fh:
v4l2_fh_exit(>fh);
kfree(ctx);
 unlock:
-- 
1.7.9.5

--
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] exynos4-is: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vfd list.So no need to call 
v4l2_fh_del(>fh) if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/exynos4-is/fimc-m2m.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c 
b/drivers/media/platform/exynos4-is/fimc-m2m.c
index 6028e4f..d8724fe 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -663,8 +663,8 @@ static int fimc_m2m_open(struct file *file)
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
 error_c:
fimc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(>fh);
+error_fh:
v4l2_fh_exit(>fh);
kfree(ctx);
 unlock:
-- 
1.7.9.5

--
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 v1] mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

[Wu-Cheng Li]

From: Tiffany Lin 

Also remove the code using size-0 OUTPUT buffer to flush.

Singed-off-by: Tiffany Lin 
Signed-off-by: Wu-Cheng Li 
Reviewed-by: Kuang-che Wu 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 151 ++---
 .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c |  14 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |   2 +
 3 files changed, 117 insertions(+), 50 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0746592..407c8ba 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -351,16 +351,6 @@ static void mtk_vdec_worker(struct work_struct *work)
dst_vb2_v4l2 = container_of(dst_buf, struct vb2_v4l2_buffer, vb2_buf);
dst_buf_info = container_of(dst_vb2_v4l2, struct mtk_video_dec_buf, vb);
 
-   buf.va = vb2_plane_vaddr(src_buf, 0);
-   buf.dma_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
-   buf.size = (size_t)src_buf->planes[0].bytesused;
-   if (!buf.va) {
-   v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
-   mtk_v4l2_err("[%d] id=%d src_addr is NULL!!",
-   ctx->id, src_buf->index);
-   return;
-   }
-
pfb = _buf_info->frame_buffer;
pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
@@ -371,8 +361,6 @@ static void mtk_vdec_worker(struct work_struct *work)
pfb->base_c.size = ctx->picinfo.c_bs_sz + ctx->picinfo.c_len_sz;
pfb->status = 0;
mtk_v4l2_debug(3, "===>[%d] vdec_if_decode() ===>", ctx->id);
-   mtk_v4l2_debug(3, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
-   ctx->id, buf.va, _addr, buf.size, src_buf);
 
mtk_v4l2_debug(3,
"id=%d Framebuf  pfb=%p VA=%p Y_DMA=%pad C_DMA=%pad 
Size=%zx",
@@ -381,24 +369,36 @@ static void mtk_vdec_worker(struct work_struct *work)
>base_c.dma_addr, pfb->base_y.size);
 
if (src_buf_info->lastframe) {
-   /* update src buf status */
+   mtk_v4l2_debug(1, "Got empty flush input buffer.");
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
-   src_buf_info->lastframe = false;
-   v4l2_m2m_buf_done(_buf_info->vb, VB2_BUF_STATE_DONE);
 
/* update dst buf status */
dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
+   mutex_lock(>lock);
dst_buf_info->used = false;
+   mutex_unlock(>lock);
 
vdec_if_decode(ctx, NULL, NULL, _chg);
clean_display_buffer(ctx);
vb2_set_plane_payload(_buf_info->vb.vb2_buf, 0, 0);
vb2_set_plane_payload(_buf_info->vb.vb2_buf, 1, 0);
+   dst_vb2_v4l2->flags |= V4L2_BUF_FLAG_LAST;
v4l2_m2m_buf_done(_buf_info->vb, VB2_BUF_STATE_DONE);
clean_free_buffer(ctx);
v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
return;
}
+   buf.va = vb2_plane_vaddr(src_buf, 0);
+   buf.dma_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
+   buf.size = (size_t)src_buf->planes[0].bytesused;
+   if (!buf.va) {
+   v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
+   mtk_v4l2_err("[%d] id=%d src_addr is NULL!!",
+   ctx->id, src_buf->index);
+   return;
+   }
+   mtk_v4l2_debug(3, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
+   ctx->id, buf.va, _addr, buf.size, src_buf);
dst_buf_info->vb.vb2_buf.timestamp
= src_buf_info->vb.vb2_buf.timestamp;
dst_buf_info->vb.timecode
@@ -412,10 +412,9 @@ static void mtk_vdec_worker(struct work_struct *work)
 
if (ret) {
mtk_v4l2_err(
-   " <===[%d], src_buf[%d]%d sz=0x%zx pts=%llu dst_buf[%d] 
vdec_if_decode() ret=%d res_chg=%d===>",
+   " <===[%d], src_buf[%d] sz=0x%zx pts=%llu dst_buf[%d] 
vdec_if_decode() ret=%d res_chg=%d===>",
ctx->id,
src_buf->index,
-   src_buf_info->lastframe,
buf.size,
src_buf_info->vb.vb2_buf.timestamp,
dst_buf->index,
@@ -456,6 +455,65 @@ static void mtk_vdec_worker(struct work_struct *work)
v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
 }
 
+static int vidioc_try_decoder_cmd(struct file *file, void *priv,
+   struct v4l2_decoder_cmd *cmd)
+{
+   switch (cmd->cmd) {
+   case V4L2_DEC_CMD_STOP:
+   case V4L2_DEC_CMD_START:
+ 

[PATCH v1] mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

[Wu-Cheng Li]

From: Wu-Cheng Li 

This patch uses V4L2_DEC_CMD_STOP to implement flush -- requesting
the remaining images to be returned to userspace. The old unofficial
way was to use a size-0 input buffer and the code is removed.

Tiffany Lin (1):
  mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 151 ++---
 .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c |  14 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |   2 +
 3 files changed, 117 insertions(+), 50 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

--
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 0/4] stk1160: Let the driver setup the device's internal AC97 codec

[Ezequiel Garcia]

On 27 November 2016 at 08:07, Marcel Hasler  wrote:
> This patchset is a result of my attempt to fix a bug 
> (https://bugzilla.kernel.org/show_bug.cgi?id=180071) that eventually turned 
> out to be caused by a missing quirk in snd-usb-audio. My idea was to remove 
> the AC97 interface and setup the codec using the same values and in the same 
> order as the Windows driver does, hoping there might be some "magic" sequence 
> that would make the sound work the way it should. Although this didn't help 
> to fix the problem, I found these changes to be useful nevertheless.
>
> IMHO, having all of the AC97 codec's channels exposed to userspace is 
> confusing since most of them have no meaning for this device anyway. Changing 
> these values in alsamixer has either no effect at all or may even reduce the 
> sound quality since it can actually increase the line-in DC offset (slightly).
>
> In addition, having to re-select the correct capture channel everytime the 
> device has been plugged in is annoying. At least on my systems the mixer 
> setup is only saved if the device is plugged in during shutdown/reboot. I 
> also get error messages in my kernel log when I unplug the device because 
> some process (probably the AC97 driver) ist trying to read from the device 
> after it has been removed. Either way the device should work out-of-the-box 
> without the need for the user to manually setup channels.
>
> The first patch in the set therefore removes the 'stk1160-mixer' and lets the 
> driver setup the AC97 codec using the same values as the Windows driver. 
> Although some of the values seem to be defaults I let the driver set them 
> either way, just to be sure.
>
> The second patch adds a check to determine whether the device is strapped to 
> use the internal 8-bit ADC or an external chip. There's currently no check in 
> place to determine whether the device uses AC-link or I2S, but then again I 
> haven't heard of any of these devices actually using an I2S chip. If the 
> device uses the internal ADC the AC97 setup can be skipped. I implemented the 
> check inside stk1160-ac97. It could just as well be in stk1160-core but this 
> way just seemed cleaner. If at some point the need arises to check other 
> power-on strap values, it might make sense to refactor this then.
>
> The third patch adds a new module parameter for setting the record gain 
> manually since the AC97 chip is no longer exposed to userspace. The Windows 
> driver doesn't allow this value to be changed but instead always sets it to 8 
> (of 15). While this should be fine for most users, some may prefer something 
> higher.
>
> The fourth patch addresses an issue when reading from the AC97 chip too soon, 
> resulting in corrupt data.
>
> Changes from version 2:
> * Added copyright notice
> * Added defines for POSVA bytes and bits
> * Added check for ACDOUT bit to determine whether audio is disabled completely
> * Removed info output for gain setting
> * Added fourth patch which had been submitted independently before
> * Expanded comment on AC97 read delay
>
> Marcel Hasler (4):
>   stk1160: Remove stk1160-mixer and setup internal AC97 codec automatically.
>   stk1160: Check whether to use AC97 codec.
>   stk1160: Add module param for setting the record gain.
>   stk1160: Give the chip some time to retrieve data from AC97 codec.
>

For the whole set:

Acked-by: Ezequiel Garcia 

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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] Doc: Correct typo, "Introdution" => "Introduction"

[Jonathan Corbet]

On Thu,  1 Dec 2016 23:36:00 +0800
Sanjeev  wrote:

> This corrects a set of spelling mistakes, probably from an
> automated conversion.

That does indeed seem worth fixing.  Applied to the docs tree, thanks.

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

Re: [PATCH 2/2] media: protect enable and disable source handler checks and calls

[Shuah Khan]

Hi Sakari,

On 12/01/2016 06:51 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Tue, Nov 29, 2016 at 10:41:51AM -0700, Shuah Khan wrote:
>> On 11/29/2016 02:22 AM, Sakari Ailus wrote:
>>> Hi Shuah,
>>>
>>> On Mon, Nov 28, 2016 at 07:15:14PM -0700, Shuah Khan wrote:
 Protect enable and disable source handler checks and calls from dvb-core
 and v4l2-core. Hold graph_mutex to check if enable and disable source
 handlers are present and invoke them while holding the mutex. This change
 ensures these handlers will not be removed while they are being checked
 and invoked.

 au08282 enable and disable source handlers are changed to not hold the
 graph_mutex.

 Signed-off-by: Shuah Khan 
 ---
  drivers/media/dvb-core/dvb_frontend.c  | 24 ++--
  drivers/media/usb/au0828/au0828-core.c | 17 +
  drivers/media/v4l2-core/v4l2-mc.c  | 26 ++
  3 files changed, 41 insertions(+), 26 deletions(-)

 diff --git a/drivers/media/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb-core/dvb_frontend.c
 index 01511e5..2f09c7e 100644
 --- a/drivers/media/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb-core/dvb_frontend.c
 @@ -2527,9 +2527,13 @@ static int dvb_frontend_open(struct inode *inode, 
 struct file *file)
fepriv->voltage = -1;
  
  #ifdef CONFIG_MEDIA_CONTROLLER_DVB
 -  if (fe->dvb->mdev && fe->dvb->mdev->enable_source) {
 -  ret = fe->dvb->mdev->enable_source(dvbdev->entity,
 +  if (fe->dvb->mdev) {
 +  mutex_lock(>dvb->mdev->graph_mutex);
 +  if (fe->dvb->mdev->enable_source)
 +  ret = fe->dvb->mdev->enable_source(
 + dvbdev->entity,
   >pipe);
 +  mutex_unlock(>dvb->mdev->graph_mutex);
>>>
>>> You have to make sure the media device actually will stay aronud while it is
>>> being accessed. In this case, when dvb_frontend_open() runs, it will proceed
>>> to access the media device without knowing whether it's going to stay around
>>> or not. Without doing so, it may well be in the process of being removed by
>>> au0828_unregister_media_device() at the same time.
>>
>> Right. What this is trying to protect is just the check for enable_source
>> and disable handlers before calling them.
> 
> Yes, but that's not enough.
> 
> The other handlers in the ops structure must stay there as long as the media
> device does. So we need to make sure it does. One, perhaps the only way to
> do that could be to obtain a reference to the device that first set those
> callbacks.
> 
>>
>>>
>>> The approach I took in my patchset was that the device that requires the
>>> media device will acquire a reference to it, this way the media device will
>>> stick around as long as other data structures have references to it. The
>>> current set did not yet implement this to dvb devices but I can add that.
>>> Then there's no even a need for the frontend driver to acquire the graph
>>> lock just to call the enable_source() callback.
>>
>> Taking reference to media_device alone will not solve this problem of enable
>> and disable handlers going away. au0828_unregister_media_device() will clear
>> the handlers and then call media_device_unregister() and it also does
>> media_device_cleanup(). Your patch set and media dev allocator api I did 
>> solve
> 
> Then, that should be applied to all the other callbacks in the ops structure
> as well. Not only to the callbacks that the au0828 driver needs. All the
> callbacks are really need to stay unchanged as long as the device may be in
> use.

I agree with you that media_device should stick around until all the users go
away. That is what the Media Dev Allocator API patch series does. When the
media_device shared across two drivers, We are looking at two different 
lifetimes.

media_device lufetimes (starts when the first driver creates it)

These handlers (enable_source and disable_source) are tied to au02828
driver (bridge driver) lifetime, not the media_device lifetime.

Hence, it is important for au0828 to clear them from the media_device when
au0828 is going away via unbind, so these become invalid and don't get run.
This similar to when the driver (au0828) goes away, it removes its graph
nodes. Hence, it makes sense to use graph_mutex for this part of cleanup
just like when a media graph node is deleted and/or added.

I think you might be thinking about a simpler scenario where media_device
lifetime is same as the driver lifetime + until the last app. released
media_device reference. When you have two drivers ion mix, we also have
lifetimes for graph nodes each driver owns as well as some handlers bridge
driver provides to manage the graph nodes. Here is a visual:

bridge 

[PATCH] Doc: Correct typo, "Introdution" => "Introduction"

[Sanjeev]

This corrects a set of spelling mistakes, probably from an
automated conversion.

Signed-off-by: Sanjeev Gupta 
---
 Documentation/admin-guide/unicode.rst | 4 ++--
 Documentation/media/dvb-drivers/intro.rst | 4 ++--
 Documentation/media/v4l-drivers/cafe_ccic.rst | 4 ++--
 Documentation/process/1.Intro.rst | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/admin-guide/unicode.rst 
b/Documentation/admin-guide/unicode.rst
index 4e5c3df..7425a33 100644
--- a/Documentation/admin-guide/unicode.rst
+++ b/Documentation/admin-guide/unicode.rst
@@ -9,8 +9,8 @@ The current version can be found at:
 
http://www.lanana.org/docs/unicode/admin-guide/unicode.rst
 
-Introdution

+Introduction
+
 
 The Linux kernel code has been rewritten to use Unicode to map
 characters to fonts.  By downloading a single Unicode-to-font table,
diff --git a/Documentation/media/dvb-drivers/intro.rst 
b/Documentation/media/dvb-drivers/intro.rst
index 7681835..d6eeb27 100644
--- a/Documentation/media/dvb-drivers/intro.rst
+++ b/Documentation/media/dvb-drivers/intro.rst
@@ -1,5 +1,5 @@
-Introdution
-===
+Introduction
+
 
 The main development site and GIT repository for these
 drivers is https://linuxtv.org.
diff --git a/Documentation/media/v4l-drivers/cafe_ccic.rst 
b/Documentation/media/v4l-drivers/cafe_ccic.rst
index b98eb3b..94f0f58 100644
--- a/Documentation/media/v4l-drivers/cafe_ccic.rst
+++ b/Documentation/media/v4l-drivers/cafe_ccic.rst
@@ -3,8 +3,8 @@ The cafe_ccic driver
 
 Author: Jonathan Corbet 
 
-Introdution

+Introduction
+
 
 "cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera
 controller.  This is the controller found in first-generation OLPC systems,
diff --git a/Documentation/process/1.Intro.rst 
b/Documentation/process/1.Intro.rst
index 22642b3..e782ae2 100644
--- a/Documentation/process/1.Intro.rst
+++ b/Documentation/process/1.Intro.rst
@@ -1,5 +1,5 @@
-Introdution
-===
+Introduction
+
 
 Executive summary
 -
-- 
2.10.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: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/

[Mauro Carvalho Chehab]

Em Thu, 01 Dec 2016 14:59:56 +
David Howells  escreveu:

> Mauro Carvalho Chehab  wrote:
> 
> > drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in 
> > function declarator  
> 
> Did you apply patch 1 first?  That defines module_param_hw*.

No. Applying it at the media upstream tree can be risky if it ends
by being merged with some changes.

On what tree do you intend patch 1 to be merged?

> 
> David



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

Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/

[David Howells]

Mauro Carvalho Chehab  wrote:

> drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in 
> function declarator

Did you apply patch 1 first?  That defines module_param_hw*.

David
--
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 29/39] Annotate hardware config module parameters in drivers/staging/media/

[Mauro Carvalho Chehab]

Em Thu, 01 Dec 2016 12:33:30 +
David Howells  escreveu:

> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
> 
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
> 
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
> 
> This patch annotates drivers in drivers/staging/media/.
> 
> Suggested-by: One Thousand Gnomes 
> Signed-off-by: David Howells 
> cc: Mauro Carvalho Chehab 
> cc: Greg Kroah-Hartman 
> cc: linux-media@vger.kernel.org
> cc: de...@driverdev.osuosl.org

Tried to apply here, but got some errors:


drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in 
function declarator
drivers/staging/media/lirc/lirc_parallel.c:728:19: error: got ,
drivers/staging/media/lirc/lirc_parallel.c:731:20: error: Expected ) in 
function declarator
drivers/staging/media/lirc/lirc_parallel.c:731:20: error: got ,
drivers/staging/media/lirc/lirc_sir.c:989:19: error: Expected ) in function 
declarator
drivers/staging/media/lirc/lirc_sir.c:989:19: error: got ,
drivers/staging/media/lirc/lirc_sir.c:992:20: error: Expected ) in function 
declarator
drivers/staging/media/lirc/lirc_sir.c:992:20: error: got ,
drivers/staging/media/lirc/lirc_sir.c:989:21: error: expected ')' before 'int'
 module_param_hw(io, int, ioport, S_IRUGO);
 ^~~
drivers/staging/media/lirc/lirc_sir.c:992:22: error: expected ')' before 'int'
 module_param_hw(irq, int, irq, S_IRUGO);
  ^~~
scripts/Makefile.build:293: recipe for target 
'drivers/staging/media/lirc/lirc_sir.o' failed
make[2]: *** [drivers/staging/media/lirc/lirc_sir.o] Error 1
make[2]: *** Waiting for unfinished jobs
drivers/staging/media/lirc/lirc_parallel.c:728:21: error: expected ')' before 
'int'
 module_param_hw(io, int, ioport, S_IRUGO);
 ^~~
drivers/staging/media/lirc/lirc_parallel.c:731:22: error: expected ')' before 
'int'
 module_param_hw(irq, int, irq, S_IRUGO);
  ^~~
scripts/Makefile.build:293: recipe for target 
'drivers/staging/media/lirc/lirc_parallel.o' failed
make[2]: *** [drivers/staging/media/lirc/lirc_parallel.o] Error 1
scripts/Makefile.build:544: recipe for target 'drivers/staging/media/lirc' 
failed
make[1]: *** [drivers/staging/media/lirc] Error 2
Makefile:1485: recipe for target '_module_drivers/staging/media' failed
make: *** [_module_drivers/staging/media] Error 2



> ---
> 
>  drivers/staging/media/lirc/lirc_parallel.c |4 ++--
>  drivers/staging/media/lirc/lirc_serial.c   |   10 +-

Btw, this got moved to another place, and had some patch getting rid
of those really ugly S_IRUGO & friend macros.

I rebased it to apply over the top of the media tree, but I suspect
it requires some other patch to be applied adding the new macro.

I'm enclosing the rebased patch as reference.

Regards,
Mauro

[PATCH] [media] Annotate hardware config module parameters in 
drivers/staging/media/

From: David Howells 

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/media/.

Re: [PATCH 2/2] media: protect enable and disable source handler checks and calls

[Sakari Ailus]

Hi Shuah,

On Tue, Nov 29, 2016 at 10:41:51AM -0700, Shuah Khan wrote:
> On 11/29/2016 02:22 AM, Sakari Ailus wrote:
> > Hi Shuah,
> > 
> > On Mon, Nov 28, 2016 at 07:15:14PM -0700, Shuah Khan wrote:
> >> Protect enable and disable source handler checks and calls from dvb-core
> >> and v4l2-core. Hold graph_mutex to check if enable and disable source
> >> handlers are present and invoke them while holding the mutex. This change
> >> ensures these handlers will not be removed while they are being checked
> >> and invoked.
> >>
> >> au08282 enable and disable source handlers are changed to not hold the
> >> graph_mutex.
> >>
> >> Signed-off-by: Shuah Khan 
> >> ---
> >>  drivers/media/dvb-core/dvb_frontend.c  | 24 ++--
> >>  drivers/media/usb/au0828/au0828-core.c | 17 +
> >>  drivers/media/v4l2-core/v4l2-mc.c  | 26 ++
> >>  3 files changed, 41 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> >> b/drivers/media/dvb-core/dvb_frontend.c
> >> index 01511e5..2f09c7e 100644
> >> --- a/drivers/media/dvb-core/dvb_frontend.c
> >> +++ b/drivers/media/dvb-core/dvb_frontend.c
> >> @@ -2527,9 +2527,13 @@ static int dvb_frontend_open(struct inode *inode, 
> >> struct file *file)
> >>fepriv->voltage = -1;
> >>  
> >>  #ifdef CONFIG_MEDIA_CONTROLLER_DVB
> >> -  if (fe->dvb->mdev && fe->dvb->mdev->enable_source) {
> >> -  ret = fe->dvb->mdev->enable_source(dvbdev->entity,
> >> +  if (fe->dvb->mdev) {
> >> +  mutex_lock(>dvb->mdev->graph_mutex);
> >> +  if (fe->dvb->mdev->enable_source)
> >> +  ret = fe->dvb->mdev->enable_source(
> >> + dvbdev->entity,
> >>   >pipe);
> >> +  mutex_unlock(>dvb->mdev->graph_mutex);
> > 
> > You have to make sure the media device actually will stay aronud while it is
> > being accessed. In this case, when dvb_frontend_open() runs, it will proceed
> > to access the media device without knowing whether it's going to stay around
> > or not. Without doing so, it may well be in the process of being removed by
> > au0828_unregister_media_device() at the same time.
> 
> Right. What this is trying to protect is just the check for enable_source
> and disable handlers before calling them.

Yes, but that's not enough.

The other handlers in the ops structure must stay there as long as the media
device does. So we need to make sure it does. One, perhaps the only way to
do that could be to obtain a reference to the device that first set those
callbacks.

> 
> > 
> > The approach I took in my patchset was that the device that requires the
> > media device will acquire a reference to it, this way the media device will
> > stick around as long as other data structures have references to it. The
> > current set did not yet implement this to dvb devices but I can add that.
> > Then there's no even a need for the frontend driver to acquire the graph
> > lock just to call the enable_source() callback.
> 
> Taking reference to media_device alone will not solve this problem of enable
> and disable handlers going away. au0828_unregister_media_device() will clear
> the handlers and then call media_device_unregister() and it also does
> media_device_cleanup(). Your patch set and media dev allocator api I did solve

Then, that should be applied to all the other callbacks in the ops structure
as well. Not only to the callbacks that the au0828 driver needs. All the
callbacks are really need to stay unchanged as long as the device may be in
use.

Acquiring the graph mutex is hardly a workable solution to fix this.

> the problem of media_device not going away, however, it doesn't fix this race
> where callers of enable and disable source handlers checking for them and 
> calling
> them while the driver might be clearing them.
> 
> So here is the scenario these patches fix. Say user app starts
> and during start of video streaming v4l2 checks to see if enable
> source handler is defined. This check is done without holding the
> graph_mutex. If unbind happens to be in progress, au0828 could
> clear enable and disable source handlers. So these could race.
> I am not how large this window is, but could happen.
> 
> If graph_mutex protects the check for enable source handler not
> being null, then it has to be released before calling enable source
> handler as shown below:
> 
> if (mdev) {
>   mutex_lock(>graph_mutex);
>   if (mdev->disable_source) {
>   mutex_unlock(>graph_mutex);
>   mdev->disable_source(>entity);
>   } else
>   mutex_unlock(>graph_mutex);
> }
> 
> The above will leave another window for handlers to be cleared.
> That is why it would make sense for the caller to hold the lock
> and the call enable and disable 

[PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/staging/media/.

Suggested-by: One Thousand Gnomes 
Signed-off-by: David Howells 
cc: Mauro Carvalho Chehab 
cc: Greg Kroah-Hartman 
cc: linux-media@vger.kernel.org
cc: de...@driverdev.osuosl.org
---

 drivers/staging/media/lirc/lirc_parallel.c |4 ++--
 drivers/staging/media/lirc/lirc_serial.c   |   10 +-
 drivers/staging/media/lirc/lirc_sir.c  |4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index bfb76a45bfbf..65530e0a6d99 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -725,10 +725,10 @@ MODULE_DESCRIPTION("Infrared receiver driver for parallel 
ports.");
 MODULE_AUTHOR("Christoph Bartelmus");
 MODULE_LICENSE("GPL");
 
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
 MODULE_PARM_DESC(io, "I/O address base (0x3bc, 0x378 or 0x278)");
 
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
 MODULE_PARM_DESC(irq, "Interrupt (7 or 5)");
 
 module_param(tx_mask, int, S_IRUGO);
diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index b798b311d32c..ea3f735a196d 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -1094,11 +1094,11 @@ MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 
= IRdeo,"
 " 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug,"
 " 5 = NSLU2 RX:CTS2/TX:GreenLED)");
 
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
 MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
 
 /* some architectures (e.g. intel xscale) have memory mapped registers */
-module_param(iommap, bool, S_IRUGO);
+module_param_hw(iommap, bool, other, S_IRUGO);
 MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O"
" (0 = no memory mapped io)");
 
@@ -1107,13 +1107,13 @@ MODULE_PARM_DESC(iommap, "physical base for memory 
mapped I/O"
  * on 32bit word boundaries.
  * See linux-kernel/drivers/tty/serial/8250/8250.c serial_in()/out()
  */
-module_param(ioshift, int, S_IRUGO);
+module_param_hw(ioshift, int, other, S_IRUGO);
 MODULE_PARM_DESC(ioshift, "shift I/O register offset (0 = no shift)");
 
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
 MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
 
-module_param(share_irq, bool, S_IRUGO);
+module_param_hw (share_irq, bool, other, S_IRUGO);
 MODULE_PARM_DESC(share_irq, "Share interrupts (0 = off, 1 = on)");
 
 module_param(sense, int, S_IRUGO);
diff --git a/drivers/staging/media/lirc/lirc_sir.c 
b/drivers/staging/media/lirc/lirc_sir.c
index 4f326e97ad75..e27842e01fba 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -986,10 +986,10 @@ MODULE_AUTHOR("Milan Pikula");
 #endif
 MODULE_LICENSE("GPL");
 
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
 MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
 
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
 MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
 
 module_param(threshold, int, S_IRUGO);

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

[PATCH 13/39] Annotate hardware config module parameters in drivers/media/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/media/.

Suggested-by: One Thousand Gnomes 
Signed-off-by: David Howells 
cc: Mauro Carvalho Chehab 
cc: mjpeg-us...@lists.sourceforge.net
cc: linux-media@vger.kernel.org
---

 drivers/media/pci/zoran/zoran_card.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/zoran/zoran_card.c 
b/drivers/media/pci/zoran/zoran_card.c
index 9d2697f5b455..3a03a0df7999 100644
--- a/drivers/media/pci/zoran/zoran_card.c
+++ b/drivers/media/pci/zoran/zoran_card.c
@@ -73,7 +73,7 @@ MODULE_PARM_DESC(card, "Card type");
  */
 
 static unsigned long vidmem;   /* default = 0 - Video memory base address */
-module_param(vidmem, ulong, 0444);
+module_param_hw(vidmem, ulong, iomem, 0444);
 MODULE_PARM_DESC(vidmem, "Default video memory base address");
 
 /*

--
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 1/2] mn88473: fix chip id check on probe

[Benjamin Larsson]

On 2016-12-01 01:29, Antti Palosaari wrote:

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")
Cc:  # v4.8+
Signed-off-by: Antti Palosaari 


I can confirm that I saw something with regards to this one time before.

MvH
Benjamin Larsson
--
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] Platform: vsp1: Clean up file handle in open() error path.

[Laurent Pinchart]

Hi Shailendra,

Thank you for the patch.

On Thursday 01 Dec 2016 10:20:18 Shailendra Verma wrote:
> v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition
> before returing from the function.
> 
> Signed-off-by: Shailendra Verma 

Reviewed-by: Laurent Pinchart 

and applied to my tree for v4.11.

> ---
>  drivers/media/platform/vsp1/vsp1_video.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c index d351b9c..cc58163 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -1044,6 +1044,7 @@ static int vsp1_video_open(struct file *file)
>   ret = vsp1_device_get(video->vsp1);
>   if (ret < 0) {
>   v4l2_fh_del(vfh);
> + v4l2_fh_exit(vfh);
>   kfree(vfh);
>   }

-- 
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] V4l: omap4iss: Clean up file handle in open() and release().

[Laurent Pinchart]

Hi Shailendra,

Thank you for the patch.

On Thursday 01 Dec 2016 10:22:52 Shailendra Verma wrote:
> Both functions initialize the file handle with v4l2_fh_init()
> and thus need to call clean up with v4l2_fh_exit() as appropriate.
> 
> Signed-off-by: Shailendra Verma 

Reviewed-by: Laurent Pinchart 

and applied to my tree for v4.11.

> ---
>  drivers/staging/media/omap4iss/iss_video.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..077c9f8 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -1141,6 +1141,7 @@ static int iss_video_open(struct file *file)
>  done:
>   if (ret < 0) {
>   v4l2_fh_del(>vfh);
> + v4l2_fh_exit(>vfh);
>   kfree(handle);
>   }
> 
> @@ -1162,6 +1163,7 @@ static int iss_video_release(struct file *file)
>   vb2_queue_release(>queue);
> 
>   v4l2_fh_del(vfh);
> + v4l2_fh_exit(vfh);
>   kfree(handle);
>   file->private_data = NULL;

-- 
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] V4l: omap3isp: Clean up file handle in open() and release().

[Laurent Pinchart]

Hi Shailendra,

Thank you for the patch.

On Thursday 01 Dec 2016 10:15:40 Shailendra Verma wrote:
> Both functions initialize the file handle with v4l2_fh_init()
> and thus need to call clean up with v4l2_fh_exit() as appropriate.
> 
> Signed-off-by: Shailendra Verma 

Reviewed-by: Laurent Pinchart 

and applied to my tree for v4.11.

> ---
>  drivers/media/platform/omap3isp/ispvideo.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index 7354469..9f966e8 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -1350,6 +1350,7 @@ static int isp_video_open(struct file *file)
>  done:
>   if (ret < 0) {
>   v4l2_fh_del(>vfh);
> + v4l2_fh_exit(>vfh);
>   kfree(handle);
>   }
> 
> @@ -1373,6 +1374,7 @@ static int isp_video_release(struct file *file)
> 
>   /* Release the file handle. */
>   v4l2_fh_del(vfh);
> + v4l2_fh_exit(vfh);
>   kfree(handle);
>   file->private_data = NULL;

-- 
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: [RFCv2 PATCH 1/5] video: add HDMI state notifier support

[Hans Verkuil]

On 11/14/16 16:22, Hans Verkuil wrote:

From: Hans Verkuil 

Add support for HDMI hotplug and EDID notifiers, which is used to convey
information from HDMI drivers to their CEC and audio counterparts.


I realized that the name 'HDMI notifier' isn't the best: the same mechanism
can be used with e.g. DisplayPort as well.

What would be a good alternative name?

"Video Notifier"?

Any objections to that? Or suggestions for a better name?

Regards,

Hans



Based on an earlier version from Russell King:

https://patchwork.kernel.org/patch/9277043/

The hdmi_notifier is a reference counted object containing the HDMI state
of an HDMI device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
---
 drivers/video/Kconfig |   3 +
 drivers/video/Makefile|   1 +
 drivers/video/hdmi-notifier.c | 136 ++
 include/linux/hdmi-notifier.h |  43 +
 4 files changed, 183 insertions(+)
 create mode 100644 drivers/video/hdmi-notifier.c
 create mode 100644 include/linux/hdmi-notifier.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..1ee7b9f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
 config HDMI
bool

+config HDMI_NOTIFIERS
+   bool
+
 if VT
source "drivers/video/console/Kconfig"
 endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..65f5649 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_VGASTATE)+= vgastate.o
 obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o

 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
new file mode 100644
index 000..c2a4f1b
--- /dev/null
+++ b/drivers/video/hdmi-notifier.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hdmi_notifiers {
+   struct list_head head;
+   struct device *dev;
+   struct hdmi_notifier *n;
+};
+
+static LIST_HEAD(hdmi_notifiers);
+static DEFINE_MUTEX(hdmi_notifiers_lock);
+
+struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
+{
+   struct hdmi_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(_notifiers_lock);
+   kref_get(>kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
+   kref_init(>kref);
+   list_add_tail(>head, _notifiers);
+unlock:
+   mutex_unlock(_notifiers_lock);
+   return n;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_get);
+
+static void hdmi_notifier_release(struct kref *kref)
+{
+   struct hdmi_notifier *n =
+   container_of(kref, struct hdmi_notifier, kref);
+
+   kfree(n->edid);
+   kfree(n);
+}
+
+void hdmi_notifier_put(struct hdmi_notifier *n)
+{
+   kref_put(>kref, hdmi_notifier_release);
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_put);
+
+int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
+{
+   int ret = blocking_notifier_chain_register(>notifiers, nb);
+
+   if (ret)
+   return ret;
+   kref_get(>kref);
+   mutex_lock(>lock);
+   if (n->connected) {
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   if (n->edid_size)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_EDID, n);
+   if (n->has_eld)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_ELD, n);
+   }
+   mutex_unlock(>lock);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_register);
+
+int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block 
*nb)
+{
+   int ret = blocking_notifier_chain_unregister(>notifiers, nb);
+
+   if (ret == 0)
+   hdmi_notifier_put(n);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
+
+void hdmi_event_connect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = true;
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_connect);
+
+void hdmi_event_disconnect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = false;
+   n->has_eld = false;
+   n->edid_size = 0;
+   blocking_notifier_call_chain(>notifiers, HDMI_DISCONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
+
+int 

Re: [PATCH] Platform: Sti: Bdisp: Clean up file handle in open() error path.

[Fabien DESSENNE]

Hi Shailendra


Thank you for the patch.


Could you please update the subject line (try to have it as short as 
possible):

- there is no need for the 'platform' keyword. This remark applies to 
your other patches.

- write all keywords in lower case (Bdisp -> bdisp). This remark applies 
also to your other patches.

- "sti" is not needed too

-> "bdisp: Clean up file handle in open() error path."

Sorry to bother you with such details, but I am sure this will not 
require a huge rework from you ;)


Fabien


On 12/01/2016 05:47 AM, Shailendra Verma wrote:
> The File handle is not yet added in the vdev list.So no need to call
> v4l2_fh_del(>fh)if it fails to create control.
>
> Signed-off-by: Shailendra Verma 
> ---
>   drivers/media/platform/sti/bdisp/bdisp-v4l2.c |2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
> b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> index 45f82b5..fbf302f 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> @@ -632,8 +632,8 @@ static int bdisp_open(struct file *file)
>   
>   error_ctrls:
>   bdisp_ctrls_delete(ctx);
> -error_fh:
>   v4l2_fh_del(>fh);
> +error_fh:
>   v4l2_fh_exit(>fh);
>   bdisp_hw_free_nodes(ctx);
>   mem_ctx:
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] [media] davinci: vpif_capture: get subdevs from DT

[Laurent Pinchart]

Hello,

On Thursday 01 Dec 2016 09:57:31 Sakari Ailus wrote:
> On Wed, Nov 30, 2016 at 04:14:11PM -0800, Kevin Hilman wrote:
> > Sakari Ailus  writes:
> >> On Wed, Nov 23, 2016 at 03:25:32PM -0800, Kevin Hilman wrote:
> >>> Sakari Ailus  writes:
>  On Tue, Nov 22, 2016 at 07:52:43AM -0800, Kevin Hilman wrote:
> > Allow getting of subdevs from DT ports and endpoints.
> > 
> > The _get_pdata() function was larely inspired by (i.e. stolen from)
> > am437x-vpfe.c
> > 
> > Signed-off-by: Kevin Hilman 
> > ---
> > 
> >  drivers/media/platform/davinci/vpif_capture.c | 130 +++-
> >  include/media/davinci/vpif_types.h 
> >|   9 +-
> >  2 files changed, 133 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/media/platform/davinci/vpif_capture.c
> > b/drivers/media/platform/davinci/vpif_capture.c index
> > 94ee6cf03f02..47a4699157e7 100644
> > --- a/drivers/media/platform/davinci/vpif_capture.c
> > +++ b/drivers/media/platform/davinci/vpif_capture.c
> > @@ -26,6 +26,8 @@
> >  #include 
> > 
> >  #include 
> > +#include 
> > +#include 
>  
>  Do you need this header?
> >>> 
> >>> Yes, based on discussion with Hans, since there is no DT binding for
> >>> selecting the input pins of the TVP514x, I have to select it in the
> >>> driver, so I need the defines from this header.  More on this below...

That's really ugly :-( The problem should be fixed properly instead of adding 
one more offender.

> >  #include "vpif.h"
> >  #include "vpif_capture.h"
> > @@ -650,6 +652,10 @@ static int vpif_input_to_subdev(
> > 
> > vpif_dbg(2, debug, "vpif_input_to_subdev\n");
> > 
> > +   if (!chan_cfg)
> > +   return -1;
> > +   if (input_index >= chan_cfg->input_count)
> > +   return -1;
> > subdev_name = chan_cfg->inputs[input_index].subdev_name;
> > if (subdev_name == NULL)
> > return -1;
> > @@ -657,7 +663,7 @@ static int vpif_input_to_subdev(
> > /* loop through the sub device list to get the sub device info
> > */
> > for (i = 0; i < vpif_cfg->subdev_count; i++) {
> > subdev_info = _cfg->subdev_info[i];
> > -   if (!strcmp(subdev_info->name, subdev_name))
> > +   if (subdev_info && !strcmp(subdev_info->name,
> > subdev_name))
> > return i;
> > }
> > return -1;
> > @@ -1327,6 +1333,21 @@ static int vpif_async_bound(struct
> > v4l2_async_notifier *notifier,> >> >> 
> >  {
> > int i;
> > 
> > +   for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
> > +   struct v4l2_async_subdev *_asd = vpif_obj.config
> > ->asd[i];
> > +   const struct device_node *node = _asd->match.of.node;
> > +
> > +   if (node == subdev->of_node) {
> > +   vpif_obj.sd[i] = subdev;
> > +   vpif_obj.config->chan_config
> > ->inputs[i].subdev_name =
> > +   (char *)subdev->of_node->full_name;

Can subdev_name be made const instead of blindly casting the full_name pointer 
? If not this is probably unsafe, and if yes it should be done :-)

> > +   vpif_dbg(2, debug,
> > +"%s: setting input %d subdev_name =
> > %s\n",
> > +__func__, i, subdev->of_node
> > ->full_name);
> > +   return 0;
> > +   }
> > +   }
> > +
> > for (i = 0; i < vpif_obj.config->subdev_count; i++)
> > if (!strcmp(vpif_obj.config->subdev_info[i].name,
> > subdev->name)) {
> > @@ -1422,6 +1443,110 @@ static int vpif_async_complete(struct
> > v4l2_async_notifier *notifier)
> > return vpif_probe_complete();
> >  }
> > 
> > +static struct vpif_capture_config *
> > +vpif_capture_get_pdata(struct platform_device *pdev)
> > +{
> > +   struct device_node *endpoint = NULL;
> > +   struct v4l2_of_endpoint bus_cfg;
> > +   struct vpif_capture_config *pdata;
> > +   struct vpif_subdev_info *sdinfo;
> > +   struct vpif_capture_chan_config *chan;
> > +   unsigned int i;
> > +
> > +   dev_dbg(>dev, "vpif_get_pdata\n");
> > +
> > +   if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
> > +   return pdev->dev.platform_data;
> > +
> > +   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> > +   if (!pdata)
> > +   return NULL;
> > +   pdata->subdev_info =
> > +   

[PATCH v4 5/9] media: venus: vdec: add video decoder files

[Stanimir Varbanov]

This consists of video decoder implementation plus decoder
controls.

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

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
new file mode 100644
index ..9f585a1e0ff1
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -0,0 +1,976 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "helpers.h"
+#include "vdec.h"
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+
+   return ALIGN(size, SZ_4K);
+}
+
+static u32 get_framesize_compressed(unsigned int width, unsigned int height)
+{
+   return ((width * height * 3 / 2) / 2) + 128;
+}
+
+static const struct venus_format vdec_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG2,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_G,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_L,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_XVID,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *find_format_by_index(int index, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   int i, k = 0;
+
+   if (index < 0 || index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+   break;
+   k++;
+   }
+
+   if (i == size)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *
+vdec_try_fmt_common(struct venus_inst *inst, struct v4l2_format *f)
+{
+   struct v4l2_pix_format_mplane *pixmp = >fmt.pix_mp;
+   struct v4l2_plane_pix_format *pfmt = pixmp->plane_fmt;
+   const struct venus_format *fmt;
+   unsigned int p;
+
+   memset(pfmt[0].reserved, 0, sizeof(pfmt[0].reserved));
+   

[PATCH v4 2/9] doc: DT: venus: binding document for Qualcomm video driver

[Stanimir Varbanov]

Add binding document for Venus video encoder/decoder driver

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Stanimir Varbanov 
---
Rob, I have removed vmem clocks, interrupts and reg properties
for vmem thing. Probably I will come with a separate platform
driver fro that and pass the video memory DT node as phandle.

 .../devicetree/bindings/media/qcom,venus.txt   | 82 ++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
b/Documentation/devicetree/bindings/media/qcom,venus.txt
new file mode 100644
index ..a64b4ea1ebba
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -0,0 +1,82 @@
+* Qualcomm Venus video encode/decode accelerator
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain one of:
+   - "qcom,msm8916-venus"
+   - "qcom,msm8996-venus"
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property.
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain following entries:
+   - "base"Venus register base
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: Should contain interrupts as listed in the interrupt-names
+   property.
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain following entries:
+   - "venus"   Venus interrupt line
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: A List of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Core video accelerator clock
+   - "iface"   Video accelerator AHB clock
+   - "bus" Video accelerator AXI clock
+- clock-names:
+   Usage: required for msm8996
+   Value type: 
+   Definition: Should contain the following entries:
+   - "subcore0"Subcore0 video accelerator clock
+   - "subcore1"Subcore1 video accelerator clock
+   - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
+   - "mmss_mmagic_iface"   Multimedia subsystem MMAGIC AHB clock
+   - "mmss_mmagic_mbus"Multimedia subsystem MMAGIC MAXI clock
+   - "mmagic_video_bus"MMAGIC video AXI clock
+   - "video_mbus"  Video MAXI clock
+- power-domains:
+   Usage: required
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral.
+- rproc:
+   Usage: required
+   Value type: 
+   Definition: A phandle to remote processor responsible for
+   firmware loading and processor booting.
+
+- iommus:
+   Usage: required
+   Value type: 
+   Definition: A list of phandle and IOMMU specifier pairs.
+
+* An Example
+   video-codec@1d0 {
+   compatible = "qcom,msm8916-venus";
+   reg = <0x01d0 0xff000>;
+   reg-names = "base";
+   interrupts = ;
+   interrupt-names = "venus";
+   clocks = < GCC_VENUS0_VCODEC0_CLK>,
+< GCC_VENUS0_AHB_CLK>,
+< GCC_VENUS0_AXI_CLK>;
+   clock-names = "core", "iface", "bus";
+   power-domains = < VENUS_GDSC>;
+   rproc = <_rproc>;
+   iommus = <_iommu 5>;
+   };
-- 
2.7.4

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

[PATCH v4 3/9] MAINTAINERS: Add Qualcomm Venus video accelerator driver

[Stanimir Varbanov]

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

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

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

--
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 v4 6/9] media: venus: venc: add video encoder files

[Stanimir Varbanov]

This adds encoder part of the driver plus encoder controls.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c   | 1099 
 drivers/media/platform/qcom/venus/venc.h   |   32 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  258 ++
 3 files changed, 1389 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/venc.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.h
 create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
new file mode 100644
index ..4cecaf386723
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -0,0 +1,1099 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "helpers.h"
+#include "venc.h"
+
+#define NUM_B_FRAMES_MAX   4
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+   size = ALIGN(size, SZ_4K);
+
+   return size;
+}
+
+static u32 get_framesize_compressed(u32 width, u32 height)
+{
+   u32 sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
+
+   return ALIGN(sz, SZ_4K);
+}
+
+static const struct venus_format venc_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, int type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *find_format_by_index(int index, int type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   int i, k = 0;
+
+   if (index < 0 || index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+   break;
+   k++;
+   }
+
+   if (i == size)
+   return NULL;
+
+   return [i];
+}
+
+static int venc_v4l2_to_hfi(int id, int value)
+{
+   switch (id) {
+   case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+   switch (value) {
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0:
+   default:
+   return HFI_MPEG4_LEVEL_0;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0B:
+   return HFI_MPEG4_LEVEL_0b;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_1:
+   return HFI_MPEG4_LEVEL_1;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_2:
+   return HFI_MPEG4_LEVEL_2;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_3:
+   return HFI_MPEG4_LEVEL_3;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_4:
+   return HFI_MPEG4_LEVEL_4;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_5:
+   return 

[PATCH v4 7/9] media: venus: hfi: add Host Firmware Interface (HFI)

[Stanimir Varbanov]

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

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

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

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

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.c|  492 ++
 drivers/media/platform/qcom/venus/hfi.h|  174 
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1256 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 ++
 drivers/media/platform/qcom/venus/hfi_helper.h | 1045 
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1054 
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 ++
 7 files changed, 4608 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h

diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
new file mode 100644
index ..95ee86aba864
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -0,0 +1,492 @@
+/*
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi.h"
+#include "hfi_cmds.h"
+#include "hfi_venus.h"
+
+#define TIMEOUTmsecs_to_jiffies(1000)
+
+static u32 to_codec_type(u32 pixfmt)
+{
+   switch (pixfmt) {
+   case V4L2_PIX_FMT_H264:
+   case V4L2_PIX_FMT_H264_NO_SC:
+   return HFI_VIDEO_CODEC_H264;
+   case V4L2_PIX_FMT_H263:
+   return HFI_VIDEO_CODEC_H263;
+   case V4L2_PIX_FMT_MPEG1:
+   return HFI_VIDEO_CODEC_MPEG1;
+   case V4L2_PIX_FMT_MPEG2:
+   return HFI_VIDEO_CODEC_MPEG2;
+   case V4L2_PIX_FMT_MPEG4:
+   return HFI_VIDEO_CODEC_MPEG4;
+   case V4L2_PIX_FMT_VC1_ANNEX_G:
+   case V4L2_PIX_FMT_VC1_ANNEX_L:
+   return HFI_VIDEO_CODEC_VC1;
+   case V4L2_PIX_FMT_VP8:
+   return HFI_VIDEO_CODEC_VP8;
+   case V4L2_PIX_FMT_XVID:
+   return HFI_VIDEO_CODEC_DIVX;
+   default:
+   return 0;
+   }
+}
+
+int hfi_core_init(struct venus_core *core)
+{
+   int ret = 0;
+
+   mutex_lock(>lock);
+
+   if (core->state >= CORE_INIT)
+   goto unlock;
+
+   reinit_completion(>done);
+
+   ret = core->ops->core_init(core);
+   if (ret)
+   goto unlock;
+
+   ret = wait_for_completion_timeout(>done, TIMEOUT);
+   if (!ret) {
+   ret = -ETIMEDOUT;
+   goto unlock;
+   }
+
+   ret = 0;
+
+   if (core->error != HFI_ERR_NONE) {
+   ret = -EIO;
+   goto unlock;
+   }
+
+   core->state = CORE_INIT;
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+int hfi_core_deinit(struct venus_core *core)
+{
+   struct device *dev = core->dev;
+   int ret = 0;
+
+   mutex_lock(>lock);
+
+   if (core->state == CORE_UNINIT)
+   goto unlock;
+
+   if (!list_empty(>instances)) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   ret = core->ops->core_deinit(core);
+   if (ret)
+   dev_err(dev, "core deinit failed: %d\n", ret);
+
+   core->state = CORE_UNINIT;
+
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+int hfi_core_suspend(struct venus_core *core)
+{
+   return core->ops->suspend(core);
+}
+
+int hfi_core_resume(struct venus_core *core)
+{
+   return core->ops->resume(core);
+}
+
+int hfi_core_trigger_ssr(struct venus_core *core, u32 type)
+{
+   return core->ops->core_trigger_ssr(core, type);
+}
+
+int hfi_core_ping(struct venus_core *core)
+{
+   int ret;
+
+   

[PATCH v4 0/9] Qualcomm video decoder/encoder driver

[Stanimir Varbanov]

Hi,

Here is version 4 of the Venus video driver.

The changes since v3 are:
  * the driver now use m2m APIs. In order to make possible to
use m2m I had to extend m2m APIs with few more helper functions
for buffer list manipulations.
  * addressed comments from Hans about buffer done on error path.
  * simplify s_selection in decoder.
  * avoid simple IRQ related wrappers in core.c and use HFI ones directly.
  * added kernel doc description of venus_core|inst structures.
  * replaced list_for_each_entry_safe with list_for_each_entry where
safer variants are not applicable.
  * revisit the locking per instance and come down to one lock per
instance.
  * added help text in the driver Kconfig option.
  * deleted custom venus_ctrl structure which duplicates v4l2_ctrl_config.
  * various cleanups on random places to avoid code duplications and
to reduce the code lines.
  * removed video memory (vmem) DT properties from binding document, this
will need more work.

The previous version can be found at https://lkml.org/lkml/2016/11/7/554

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

 .../devicetree/bindings/media/qcom,venus.txt   |   82 ++
 MAINTAINERS|8 +
 drivers/media/platform/Kconfig |   13 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/qcom/venus/Makefile |   14 +
 drivers/media/platform/qcom/venus/core.c   |  474 ++
 drivers/media/platform/qcom/venus/core.h   |  296 
 drivers/media/platform/qcom/venus/helpers.c|  621 
 drivers/media/platform/qcom/venus/helpers.h|   41 +
 drivers/media/platform/qcom/venus/hfi.c|  492 +++
 drivers/media/platform/qcom/venus/hfi.h|  174 +++
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1256 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 
 drivers/media/platform/qcom/venus/hfi_helper.h | 1045 ++
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1054 ++
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 
 drivers/media/platform/qcom/venus/hfi_venus.c  | 1508 
 drivers/media/platform/qcom/venus/hfi_venus.h  |   23 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |   98 ++
 drivers/media/platform/qcom/venus/vdec.c   |  976 +
 drivers/media/platform/qcom/venus/vdec.h   |   32 +
 drivers/media/platform/qcom/venus/vdec_ctrls.c |  149 ++
 drivers/media/platform/qcom/venus/venc.c   | 1099 ++
 drivers/media/platform/qcom/venus/venc.h   |   32 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  258 
 drivers/media/v4l2-core/v4l2-mem2mem.c |   37 +
 include/media/v4l2-mem2mem.h   |   83 ++
 27 files changed, 10454 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
 create mode 100644 drivers/media/platform/qcom/venus/Makefile
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec.c
 create mode 100644 drivers/media/platform/qcom/venus/vdec.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.h
 create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c

-- 
2.7.4

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

[PATCH v4 8/9] media: venus: hfi: add Venus HFI files

[Stanimir Varbanov]

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

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

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
new file mode 100644
index ..f004a9a80d85
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -0,0 +1,1508 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi_cmds.h"
+#include "hfi_msgs.h"
+#include "hfi_venus.h"
+#include "hfi_venus_io.h"
+
+#define HFI_MASK_QHDR_TX_TYPE  0xff00
+#define HFI_MASK_QHDR_RX_TYPE  0x00ff
+#define HFI_MASK_QHDR_PRI_TYPE 0xff00
+#define HFI_MASK_QHDR_ID_TYPE  0x00ff
+
+#define HFI_HOST_TO_CTRL_CMD_Q 0
+#define HFI_CTRL_TO_HOST_MSG_Q 1
+#define HFI_CTRL_TO_HOST_DBG_Q 2
+#define HFI_MASK_QHDR_STATUS   0x00ff
+
+#define IFACEQ_NUM 3
+#define IFACEQ_CMD_IDX 0
+#define IFACEQ_MSG_IDX 1
+#define IFACEQ_DBG_IDX 2
+#define IFACEQ_MAX_BUF_COUNT   50
+#define IFACEQ_MAX_PARALLEL_CLNTS  16
+#define IFACEQ_DFLT_QHDR   0x0101
+
+#define POLL_INTERVAL_US   50
+
+#define IFACEQ_MAX_PKT_SIZE1024
+#define IFACEQ_MED_PKT_SIZE768
+#define IFACEQ_MIN_PKT_SIZE8
+#define IFACEQ_VAR_SMALL_PKT_SIZE  100
+#define IFACEQ_VAR_LARGE_PKT_SIZE  512
+#define IFACEQ_VAR_HUGE_PKT_SIZE   (1024 * 12)
+
+enum tzbsp_video_state {
+   TZBSP_VIDEO_STATE_SUSPEND = 0,
+   TZBSP_VIDEO_STATE_RESUME
+};
+
+struct hfi_queue_table_header {
+   u32 version;
+   u32 size;
+   u32 qhdr0_offset;
+   u32 qhdr_size;
+   u32 num_q;
+   u32 num_active_q;
+};
+
+struct hfi_queue_header {
+   u32 status;
+   u32 start_addr;
+   u32 type;
+   u32 q_size;
+   u32 pkt_size;
+   u32 pkt_drop_cnt;
+   u32 rx_wm;
+   u32 tx_wm;
+   u32 rx_req;
+   u32 tx_req;
+   u32 rx_irq_status;
+   u32 tx_irq_status;
+   u32 read_idx;
+   u32 write_idx;
+};
+
+#define IFACEQ_TABLE_SIZE  \
+   (sizeof(struct hfi_queue_table_header) +\
+sizeof(struct hfi_queue_header) * IFACEQ_NUM)
+
+#define IFACEQ_QUEUE_SIZE  (IFACEQ_MAX_PKT_SIZE *  \
+   IFACEQ_MAX_BUF_COUNT * IFACEQ_MAX_PARALLEL_CLNTS)
+
+#define IFACEQ_GET_QHDR_START_ADDR(ptr, i) \
+   (void *)(((ptr) + sizeof(struct hfi_queue_table_header)) +  \
+   ((i) * sizeof(struct hfi_queue_header)))
+
+#define QDSS_SIZE  SZ_4K
+#define SFR_SIZE   SZ_4K
+#define QUEUE_SIZE \
+   (IFACEQ_TABLE_SIZE + (IFACEQ_QUEUE_SIZE * IFACEQ_NUM))
+
+#define ALIGNED_QDSS_SIZE  ALIGN(QDSS_SIZE, SZ_4K)
+#define ALIGNED_SFR_SIZE   ALIGN(SFR_SIZE, SZ_4K)
+#define ALIGNED_QUEUE_SIZE ALIGN(QUEUE_SIZE, SZ_4K)
+#define SHARED_QSIZE   ALIGN(ALIGNED_SFR_SIZE + ALIGNED_QUEUE_SIZE + \
+ ALIGNED_QDSS_SIZE, SZ_1M)
+
+struct mem_desc {
+   dma_addr_t da;  /* device address */
+   void *kva;  /* kernel virtual address */
+   u32 size;
+   unsigned long attrs;
+};
+
+struct iface_queue {
+   struct hfi_queue_header *qhdr;
+   struct mem_desc qmem;
+};
+
+enum venus_state {
+   VENUS_STATE_DEINIT = 1,
+   VENUS_STATE_INIT,
+};
+
+struct venus_hfi_device {
+   struct venus_core *core;
+   u32 irq_status;
+   u32 last_packet_type;
+   bool power_enabled;
+   bool suspended;
+   enum venus_state state;
+   struct mutex lock;
+   struct completion pwr_collapse_prep;
+   

[PATCH v4 4/9] media: venus: adding core part and helper functions

[Stanimir Varbanov]

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

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

   - vb2_ops and functions for format propagation,

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

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

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.c| 474 +
 drivers/media/platform/qcom/venus/core.h| 296 +
 drivers/media/platform/qcom/venus/helpers.c | 621 
 drivers/media/platform/qcom/venus/helpers.h |  41 ++
 4 files changed, 1432 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
new file mode 100644
index ..77fb77cadefe
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -0,0 +1,474 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "vdec.h"
+#include "venc.h"
+
+static void venus_sys_error_handler(struct work_struct *work)
+{
+   struct venus_core *core =
+   container_of(work, struct venus_core, work.work);
+   int ret;
+
+   hfi_core_deinit(core);
+
+   mutex_lock(>lock);
+
+   rproc_report_crash(core->rproc, RPROC_FATAL_ERROR);
+   rproc_shutdown(core->rproc);
+
+   ret = rproc_boot(core->rproc);
+   if (ret)
+   goto exit;
+
+   enable_irq(core->irq);
+
+   core->state = CORE_INIT;
+
+exit:
+   mutex_unlock(>lock);
+}
+
+static void venus_event_notify(struct venus_core *core, u32 event)
+{
+   struct venus_inst *inst;
+
+   switch (event) {
+   case EVT_SYS_WATCHDOG_TIMEOUT:
+   case EVT_SYS_ERROR:
+   break;
+   default:
+   return;
+   }
+
+   mutex_lock(>lock);
+   core->sys_error = true;
+   list_for_each_entry(inst, >instances, list)
+   inst->ops->event_notify(inst, EVT_SESSION_ERROR, NULL);
+   mutex_unlock(>lock);
+
+   disable_irq_nosync(core->irq);
+
+   /*
+* Sleep for 5 sec to ensure venus has completed any pending cache
+* operations. Without this sleep, we see device reset when firmware is
+* unloaded after a system error.
+*/
+   schedule_delayed_work(>work, msecs_to_jiffies(5000));
+}
+
+static const struct hfi_core_ops venus_core_ops = {
+   .event_notify = venus_event_notify,
+};
+
+static int venus_open(struct file *file)
+{
+   struct video_device *vdev = video_devdata(file);
+   struct venus_core *core = video_drvdata(file);
+   struct venus_inst *inst;
+   int ret;
+
+   inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+   if (!inst)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(>registeredbufs);
+   INIT_LIST_HEAD(>internalbufs);
+   INIT_LIST_HEAD(>list);
+   mutex_init(>lock);
+
+   inst->core = core;
+
+   if (vdev == core->vdev_dec) {
+   inst->session_type = VIDC_SESSION_TYPE_DEC;
+   ret = vdec_open(inst);
+   if (ret)
+   goto err_free_inst;
+   v4l2_fh_init(>fh, core->vdev_dec);
+   } else {
+   inst->session_type = VIDC_SESSION_TYPE_ENC;
+   ret = venc_open(inst);
+   if (ret)
+   goto err_free_inst;
+   v4l2_fh_init(>fh, core->vdev_enc);
+   }
+
+   inst->fh.ctrl_handler = >ctrl_handler;
+   v4l2_fh_add(>fh);
+   inst->fh.m2m_ctx = inst->m2m_ctx;
+   file->private_data = >fh;
+
+   return 0;
+
+err_free_inst:
+   kfree(inst);
+   return ret;
+}
+
+static int venus_close(struct file *file)
+{
+   struct 

[PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

[Stanimir Varbanov]

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

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

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

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

[PATCH v4 9/9] media: venus: enable building of Venus video driver

[Stanimir Varbanov]

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

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

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..2fc81dcbdb1f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -379,6 +379,19 @@ config VIDEO_TI_VPE_DEBUG
---help---
  Enable debug messages on VPE driver.
 
+config VIDEO_QCOM_VENUS
+   tristate "Qualcomm Venus V4L2 encoder/decoder driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on (ARCH_QCOM && OF) || COMPILE_TEST
+   depends on (IOMMU_DMA && QCOM_VENUS_PIL) || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for Qualcomm Venus video accelerator
+ hardware. It accelerates encoding and decoding operations
+ on various Qualcomm SoCs.
+ To compile this driver as a module choose m here.
+
 endif # V4L_MEM2MEM_DRIVERS
 
 # TI VIDEO PORT Helper Modules
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb271d2b8..d88a4e1eb850 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -69,3 +69,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
diff --git a/drivers/media/platform/qcom/venus/Makefile 
b/drivers/media/platform/qcom/venus/Makefile
new file mode 100644
index ..8c4ef27e30fe
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/Makefile
@@ -0,0 +1,14 @@
+# Makefile for Qualcomm Venus driver
+
+venus-objs +=  core.o \
+   helpers.o \
+   vdec.o \
+   vdec_ctrls.o \
+   venc.o \
+   venc_ctrls.o \
+   hfi_venus.o \
+   hfi_msgs.o \
+   hfi_cmds.o \
+   hfi.o \
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus.o
-- 
2.7.4

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

Re: [PATCH v3 4/4] [media] dt-bindings: add TI VPIF documentation

[Sakari Ailus]

Hi Kevin,

On Wed, Nov 30, 2016 at 03:48:51PM -0800, Kevin Hilman wrote:
> Sakari Ailus  writes:
> 
> > Hi Rob and Kevin,
> >
> > On Tue, Nov 29, 2016 at 08:41:44AM -0600, Rob Herring wrote:
> >> On Mon, Nov 28, 2016 at 4:30 PM, Kevin Hilman  wrote:
> >> > Hi Rob,
> >> >
> >> > Rob Herring  writes:
> >> >
> >> >> On Tue, Nov 22, 2016 at 07:52:44AM -0800, Kevin Hilman wrote:
> >> >>> Signed-off-by: Kevin Hilman 
> >> >>> ---
> >> >>>  .../bindings/media/ti,da850-vpif-capture.txt   | 65 
> >> >>> ++
> >> >>>  .../devicetree/bindings/media/ti,da850-vpif.txt|  8 +++
> >> >>>  2 files changed, 73 insertions(+)
> >> >>>  create mode 100644 
> >> >>> Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >> >>>  create mode 100644 
> >> >>> Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> >> >>>
> >> >>> diff --git 
> >> >>> a/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt 
> >> >>> b/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >> >>> new file mode 100644
> >> >>> index ..c447ac482c1d
> >> >>> --- /dev/null
> >> >>> +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif-capture.txt
> >> >>> @@ -0,0 +1,65 @@
> >> >>> +Texas Instruments VPIF Capture
> >> >>> +--
> >> >>> +
> >> >>> +The TI Video Port InterFace (VPIF) capture component is the primary
> >> >>> +component for video capture on the DA850 family of TI DaVinci SoCs.
> >> >>> +
> >> >>> +TI Document number reference: SPRUH82C
> >> >>> +
> >> >>> +Required properties:
> >> >>> +- compatible: must be "ti,da850-vpif-capture"
> >> >>> +- reg: physical base address and length of the registers set for the 
> >> >>> device;
> >> >>> +- interrupts: should contain IRQ line for the VPIF
> >> >>> +
> >> >>> +VPIF capture has a 16-bit parallel bus input, supporting 2 8-bit
> >> >>> +channels or a single 16-bit channel.  It should contain at least one
> >> >>> +port child node with child 'endpoint' node. Please refer to the
> >> >>> +bindings defined in
> >> >>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >> >>> +
> >> >>> +Example using 2 8-bit input channels, one of which is connected to an
> >> >>> +I2C-connected TVP5147 decoder:
> >> >>> +
> >> >>> +vpif_capture: video-capture@0x00217000 {
> >> >>> +reg = <0x00217000 0x1000>;
> >> >>> +interrupts = <92>;
> >> >>> +
> >> >>> +port {
> >> >>> +vpif_ch0: endpoint@0 {
> >> >>> +  reg = <0>;
> >> >>> +  bus-width = <8>;
> >> >>> +  remote-endpoint = <>;
> >> >>> +};
> >> >>> +
> >> >>> +vpif_ch1: endpoint@1 {
> >> >>
> >> >> I think probably channels here should be ports rather than endpoints.
> >> >> AIUI, having multiple endpoints is for cases like a mux or 1 to many
> >> >> connections. There's only one data flow, but multiple sources or sinks.
> >> >
> >> > Looking at this closer... , I used an endpoint because it's bascially a
> >> > 16-bit parallel bus, that can be configured as (up to) 2 8-bit
> >> > "channels.  So, based on the video-interfaces.txt doc, I configured this
> >> > as a single port, with (up to) 2 endpoints.  That also allows me to
> >> > connect output of the decoder directly, using the remote-endpoint
> >> > property.
> >> >
> >> > So I guess I'm not fully understanding your suggestion.
> >> 
> >> NM, looks like video-interfaces.txt actually spells out this case and
> >> defines doing it as you did.
> >
> > It's actually the first time I read that portion (at least so that I could
> > remember) of video-interfaces.txt. I'm not sure if anyone has implemented
> > that previously, nor how we ended up with the text. The list archive could
> > probably tell. Cc Guennadi who wrote it. :-) I couldn't immediately find DT
> > source with this arrangement.
> >
> > In case of splitting the port into two parallel interfaces, how do you
> > determine which wires belong to which endpoint? I guess they'd be particular
> > sets of wires but as there's just a single port it isn't defined by the
> > port.
> 
> Isn't that the point of data-shift?

Right.

> 
> e.g. it's a single 16-bit parallel bus, where the lower 8 bits are for
> channel 0 and the upper 8 bits are for channel 1.  Alternately, the port
> can also be configured as a single 16-bit channel (e.g. for raw
> capture.)
> 
> If you want more details on this hardware, it's pretty well described in
> Chapter 35 of http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf.
> 
> FWIW, I'm not really picky about how to do this.  I'm trying to learn
> "the right way" and am happy to do that, but the feedback so far has
> been confusing (at least for someone relatively new to the DT side of
> the media framework.)

I have to admit I'm more familiar with