dib0700_core.c: uninitialized variable warning, not sure how to fix

[Hans Verkuil]

The daily build produces this compiler warning:

dib0700_core.c: In function 'dib0700_rc_urb_completion':
dib0700_core.c:787:2: warning: 'protocol' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  rc_keydown(d->rc_dev, protocol, keycode, toggle);
  ^~~~

This is indeed correct as there is a path in that function where protocol is
uninitialized, but I lack the knowledge how this should be fixed.

Mauro, can you take a look?

It goes wrong in the switch in case RC_BIT_NEC if the first 'if' is true.
Note that keycode is also uninitialized, but it is declared as 
uninitialized_var(),
although why you would want to do that instead of just initializing it to 0 or
something like that is a mystery to me.

Regards,

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

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Jacek Anaszewski]

On 11/09/2016 07:26 PM, Rob Herring wrote:

On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:

On 11/03/2016 11:10 AM, Andi Shyti wrote:

Hi Jacek,


Only DT bindings of LED class drivers should be placed in
Documentation/devicetree/bindings/leds. Please move it to the
media bindings.


that's where I placed it first, but Rob asked me to put it in the
LED directory and Cc the LED mailining list.

That's the discussion of the version 2:

https://lkml.org/lkml/2016/9/12/380

Rob, Jacek, could you please agree where I can put the binding?


I'm not sure if this is a good approach. I've noticed also that
backlight bindings have been moved to leds, whereas they don't look
similarly.

We have common.txt LED bindings, that all LED class drivers' bindings
have to follow. Neither backlight bindings nor these ones do that,
which introduces some mess.


And there are probably LED bindings that don't follow common.txt either.


Eventually adding a sub-directory, e.g. remote_control could make it
somehow logically justified, but still - shouldn't bindings be
placed in the documentation directory related to the subsystem of the
driver they are predestined to?


No. While binding directories often mirror the driver directories, they
are not the same. Bindings are grouped by types of h/w and IR LEDs are a
type of LED.

If you prefer a sub-dir, that is fine with me.


Fine. So how about sub-dir "ir" ?

--
Best regards,
Jacek Anaszewski
--
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] ir-kbd-i2c: fix uninitialized variable reference

[Hans Verkuil]

Fix compiler warning about uninitialized variable reference:

ir-kbd-i2c.c: In function 'get_key_haup_common.isra.3':
ir-kbd-i2c.c:62:2: warning: 'toggle' may be used uninitialized in this function 
[-Wmaybe-uninitialized]
  printk(KERN_DEBUG MODULE_NAME ": " fmt , ## arg)
  ^~
ir-kbd-i2c.c:70:20: note: 'toggle' was declared here
  int start, range, toggle, dev, code, ircode, vendor;
^~

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index f95a6bc..cede397 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
rc_type *protocol,
*protocol = RC_TYPE_RC6_MCE;
dev &= 0x7f;
dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d 
dev=%d code=%d\n",
-   toggle, vendor, dev, code);
+   *ptoggle, vendor, dev, code);
} else {
*ptoggle = 0;
*protocol = RC_TYPE_RC6_6A_32;
--
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: add index check in decoder vidioc_qbuf.

[Wu-Cheng Li]

From: Wu-Cheng Li 

vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.

Signed-off-by: Wu-Cheng Li 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
 
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+   if (buf->index >= vq->num_buffers) {
+   mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+   return -EINVAL;
+   }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
-- 
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

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf

[Wu-Cheng Li]

From: Wu-Cheng Li 

This patch adds a buffer index check in decoder vidioc_qbuf.

Wu-Cheng Li (1):
  mtk-vcodec: add index check in decoder vidioc_qbuf.

 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Thu Nov 10 05:00:15 CET 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash:   3e34e5f92881aa379635763ead549abd84480628
v4l-utils git hash: 788b674f3827607c09c31be11c91638f816aa6ae
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

[Tiffany Lin]

Hi Hans, Dan,

On Wed, 2016-11-09 at 14:45 +0100, Hans Verkuil wrote:
> On 11/09/16 14:28, Dan Carpenter wrote:
> > Hello Tiffany Lin,
> >
> > The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
> > Video Decoder Driver" from Sep 2, 2016, leads to the following static
> > checker warning:
> >
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 
> > vidioc_vdec_qbuf()
> > error: buffer overflow 'vq->bufs' 32 <= u32max
> >
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> >520  static int vidioc_vdec_qbuf(struct file *file, void *priv,
> >521  struct v4l2_buffer *buf)
> >522  {
> >523  struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >524  struct vb2_queue *vq;
> >525  struct vb2_buffer *vb;
> >526  struct mtk_video_dec_buf *mtkbuf;
> >527  struct vb2_v4l2_buffer  *vb2_v4l2;
> >528
> >529  if (ctx->state == MTK_STATE_ABORT) {
> >530  mtk_v4l2_err("[%d] Call on QBUF after unrecoverable 
> > error",
> >531  ctx->id);
> >532  return -EIO;
> >533  }
> >534
> >535  vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
> >536  vb = vq->bufs[buf->index];
> >
> > Smatch thinks that "buf->index" comes straight from the user without
> > being checked and that this is a buffer overflow.  It seems simple
> > enough to analyse the call tree.
> >
> > __video_do_ioctl()
> > ->  v4l_qbuf()
> >   -> vidioc_vdec_qbuf()
> >
> > It seems like Smatch is correct.  I looked at a different implementation
> > of this and that one wasn't checked either so maybe there is something
> > I am not seeing.
> >
> > This has obvious security implications.  Can someone take a look at
> > this?
> 
> This is indeed wrong.
> 
> The v4l2_m2m_qbuf() call at the end of this function calls in turn 
> vb2_qbuf which
> will check the index. But if you override vidioc_qbuf (or 
> vidioc_prepare), then
> you need to check the index value.
> 
> I double-checked all cases where vidioc_qbuf was set to a 
> driver-specific function
> and this is the only driver that doesn't check the index field. In all 
> other cases
> it is either checked, or it is not used before calling into the vb1/vb2 
> framework
> which checks this.
> 
> So luckily this only concerns this driver.

Thanks for point out this issue.
As Hans' mentioned, our driver access index field in v4l2_buffer before
framework check buffer index.
We will prepare patch for this issue.


best regards,
Tiffany


> 
> Regards,
> 
>   Hans
> 
> >
> >537  vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, 
> > vb2_buf);
> >538  mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, 
> > vb);
> >539
> >540  if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
> >541  (buf->m.planes[0].bytesused == 0)) {
> >542  mtkbuf->lastframe = true;
> >543  mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d 
> > (%d,%d, %d) vb=%p",
> >544   ctx->id, buf->type, buf->index,
> >545   mtkbuf->lastframe, buf->bytesused,
> >546   buf->m.planes[0].bytesused, buf->length,
> >547   vb);
> >548  }
> >549
> >550  return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
> >551  }
> >
> > regards,
> > dan carpenter
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >


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

Re: [PATCH 04/12] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM

[kbuild test robot]

Hi Ulf,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc4 next-20161109]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/media-Exynos-GScaller-driver-fixes/20161110-48
base:   git://linuxtv.org/media_tree.git master
config: openrisc-allyesconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

Note: the 
linux-review/Marek-Szyprowski/media-Exynos-GScaller-driver-fixes/20161110-48
 HEAD 92b20676ac75659d1ea1d83b00e8028f45ea84e9 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/media/platform/exynos-gsc/gsc-core.c: In function 'gsc_resume':
>> drivers/media/platform/exynos-gsc/gsc-core.c:1183:3: error: implicit 
>> declaration of function 'gsc_runtime_resume'
   drivers/media/platform/exynos-gsc/gsc-core.c: In function 'gsc_suspend':
>> drivers/media/platform/exynos-gsc/gsc-core.c:1198:3: error: implicit 
>> declaration of function 'gsc_runtime_suspend'

vim +/gsc_runtime_resume +1183 drivers/media/platform/exynos-gsc/gsc-core.c

89069699 Sungchun Kang 2012-07-31  1177 
spin_unlock_irqrestore(>slock, flags);
89069699 Sungchun Kang 2012-07-31  1178 return 0;
89069699 Sungchun Kang 2012-07-31  1179 }
89069699 Sungchun Kang 2012-07-31  1180 
spin_unlock_irqrestore(>slock, flags);
89069699 Sungchun Kang 2012-07-31  1181  
f9fa906f Prathyush K   2013-08-07  1182 if (!pm_runtime_suspended(dev))
f9fa906f Prathyush K   2013-08-07 @1183 return 
gsc_runtime_resume(dev);
f9fa906f Prathyush K   2013-08-07  1184  
f9fa906f Prathyush K   2013-08-07  1185 return 0;
89069699 Sungchun Kang 2012-07-31  1186  }
89069699 Sungchun Kang 2012-07-31  1187  
89069699 Sungchun Kang 2012-07-31  1188  static int gsc_suspend(struct device 
*dev)
89069699 Sungchun Kang 2012-07-31  1189  {
89069699 Sungchun Kang 2012-07-31  1190 struct gsc_dev *gsc = 
dev_get_drvdata(dev);
89069699 Sungchun Kang 2012-07-31  1191  
89069699 Sungchun Kang 2012-07-31  1192 pr_debug("gsc%d: state: 0x%lx", 
gsc->id, gsc->state);
89069699 Sungchun Kang 2012-07-31  1193  
89069699 Sungchun Kang 2012-07-31  1194 if 
(test_and_set_bit(ST_SUSPEND, >state))
89069699 Sungchun Kang 2012-07-31  1195 return 0;
89069699 Sungchun Kang 2012-07-31  1196  
f9fa906f Prathyush K   2013-08-07  1197 if (!pm_runtime_suspended(dev))
f9fa906f Prathyush K   2013-08-07 @1198 return 
gsc_runtime_suspend(dev);
f9fa906f Prathyush K   2013-08-07  1199  
f9fa906f Prathyush K   2013-08-07  1200 return 0;
89069699 Sungchun Kang 2012-07-31  1201  }

:: The code at line 1183 was first introduced by commit
:: f9fa906f00388bf326d010f36bc905cbd0b6554f [media] exynos-gsc: fix s2r 
functionality

:: TO: Prathyush K <prathyus...@samsung.com>
:: CC: Mauro Carvalho Chehab <m.che...@samsung.com>

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


.config.gz
Description: application/gzip

Re: [PATCH v3 8/9] media: venus: add Makefiles and Kconfig files

[Stephen Boyd]

On 11/07, Stanimir Varbanov wrote:
> diff --git a/drivers/media/platform/qcom/Kconfig 
> b/drivers/media/platform/qcom/Kconfig
> new file mode 100644
> index ..bf4d2fcce924
> --- /dev/null
> +++ b/drivers/media/platform/qcom/Kconfig
> @@ -0,0 +1,7 @@
> +
> +menuconfig VIDEO_QCOM_VENUS
> +tristate "Qualcomm Venus V4L2 encoder/decoder driver"
> +depends on ARCH_QCOM && VIDEO_V4L2
> +depends on IOMMU_DMA
> +depends on QCOM_VENUS_PIL
> +select VIDEOBUF2_DMA_SG

Can this have some help text?


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: Question about 2 gp8psk patches I noticed, and possible bug.

[VDR User]

>> (gdb) l *module_put+0x67
>> 0xc10a4b87 is in module_put (kernel/module.c:1108).
>> 1103int ret;
>> 1104
>> 1105if (module) {
>> 1106preempt_disable();
>> 1107ret = atomic_dec_if_positive(>refcnt);
>> 1108WARN_ON(ret < 0);   /* Failed to put refcount */
>> 1109trace_module_put(module, _RET_IP_);
>> 1110preempt_enable();
>> }
>> 1112}
>
> OK, I guess we've made progress. Please try the enclosed patch.
>
> Regards,
> Mauro
>
> [media] gp8psk: Fix DVB frontend attach
>
> it should be calling module_get() at attach, as otherwise
> module_put() will crash.
>
> Signed-off-by: Mauro Carvalho Chehab 

I think you forgot the patch. :)
--
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: [Ksummit-discuss] Including images on Sphinx documents

[Markus Heiser]

On 09.11.2016 12:58, Jani Nikula wrote:
> On Wed, 09 Nov 2016, Markus Heiser  wrote:
>> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
 So I vote for :

> 1) copy (or symlink) all rst files to Documentation/output (or to the
> build dir specified via O= directive) and generate the *.pdf there,
> and produce those converted images via Makefile.;
>>>
>>> We're supposed to solve problems, not create new ones.
>>
>> ... new ones? ...
>
> Handle in-tree builds without copying.
>
> Make dependency analysis with source rst and "intermediate" rst work.
>
> Make sure your copying gets the timestamps right.
>
> Make Sphinx dependency analysis look at the right copies depending on
> in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
> own dependency analysis.
>
> The stuff I didn't think of.

It might be easier than you think first.

> Sure, it's all supposed to be basic Makefile stuff, but don't make the mistake
> of thinking just one invocation of 'cp' will solve all the problems.

I act naif using 'cp -sa', see patch below.

> It all adds to the complexity we were trying to avoid when dumping DocBook. It
> adds to the complexity of debugging stuff. (And hey, there's still the one
> rebuilding-stuff-for-no-reason issue open.)

And hey ;-) I wrote you [1], this is a bug in Sphinx. Yes, I haven't had time
to send a bugfix to Sphinx, but this won't even help us (bugfixes in Sphinx will
only apply on top).

> If you want to keep the documentation build sane, try to avoid the Makefile
> preprocessing.

I'am just the one helping Mauro to be productive, if he needs preprocessing I
implement proposals. I know that you fear preprocessing since it tend to
fall-back, what we had with DocBook's build process.  We discussed this already,
it might better you unify this with Mauro and the other who need preprocessing.

> And same old story, if you fix this for real, even if as a Sphinx extension,
> *other* people than kernel developers will be interested, and *we* don't have
> to do so much ourselves.

I don't think so, this kind of parsing header files we have and the build of
content from MAINTAINERS, ABI, etc. is very kernel specific.

Anyway, back to my point 'copy (or symlink) all rst files'. Please take a look
at my patch below. Take in mind; its just a POC.

Could this POC persuade you, if so, I send a more elaborate RFC,
what do you think about?

[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07302.html

-- Markus --

> BR,
> Jani.
>>
 IMO placing 'sourcedir' to O= is more sane since this marries the
 Linux Makefile concept (relative to $PWD) with the sphinx concept
 (in or below 'sourcedir').
>>
>> -- Markus --
>

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index ec0c77d..8e904c1 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -13,6 +13,10 @@ BUILDDIR  = $(obj)/output
 PDFLATEX  = xelatex
 LATEXOPTS = -interaction=batchmode

+ifdef SPHINXDIRS
+else
+endif
+
 # User-friendly check for sphinx-build
 HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; 
else echo 0; fi)

@@ -50,30 +54,38 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 #* dest folder relative to $(BUILDDIR) and
 #* cache folder relative to $(BUILDDIR)/.doctrees
 # $4 dest subfolder e.g. "man" for man pages at media/man
-# $5 reST source folder relative to $(srctree)/$(src),
+# $5 reST source folder relative to $(obj),
 #e.g. "media" for the linux-tv book-set at ./Documentation/media

 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
-  cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media all;\
-   BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
+  cmd_sphinx = $(MAKE) BUILDDIR=$(BUILDDIR) $(build)=Documentation/media 
all;\
+   BUILDDIR=$(BUILDDIR) SPHINX_CONF=$(obj)/$5/$(SPHINX_CONF) \
$(SPHINXBUILD) \
-b $2 \
-   -c $(abspath $(srctree)/$(src)) \
-   -d $(abspath $(BUILDDIR)/.doctrees/$3) \
+   -c $(obj) \
+   -d $(obj)/.doctrees/$3 \
-D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
$(ALLSPHINXOPTS) \
-   $(abspath $(srctree)/$(src)/$5) \
-   $(abspath $(BUILDDIR)/$3/$4);
-
-htmldocs:
+   $(obj)/$5 \
+   $(BUILDDIR)/$3/$4;
+
+ifdef O
+sync:
+   rm -rf $(objtree)/$(obj)
+   cp -sa $(srctree)/$(obj) $(objtree)
+else
+sync:
+endif
+
+htmldocs: sync
@$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,html,$(var),,$(var)))

-latexdocs:
+latexdocs: sync
@$(foreach var,$(SPHINXDIRS),$(call 
loop_cmd,sphinx,latex,$(var),latex,$(var)))

 ifeq ($(HAVE_PDFLATEX),0)

-pdfdocs:
+pdfdocs: sync
$(warning The '$(PDFLATEX)' command was not found. Make sure you have 
it installed and in PATH to produce PDF output.)
@echo "  

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

[Mauro Carvalho Chehab]

Em Wed, 9 Nov 2016 19:57:58 +
Malcolm Priestley  escreveu:

> > Yeah, I avoided serializing the logic that detects if the firmware is
> > loaded, but forgot that the power control had the same issue. The
> > newer dvb usb drivers use the dvb-usb-v2, so I didn't touch this
> > code for a while.  
> 
> I think the problem is that the usb buffer has been put in struct 
> cinergyt2_state private area which has not been initialized for initial 
> usb probing.
> 
> That was one of the main reasons for porting drivers to dvb-usb-v2.

True, but converting to dvb-usb-v2, is more complex. In particular,
dib0700 and dib3000 drivers rely on some things that may not be ported
to dvb-usb-v2.

So, I don't think we should do such change during the -rc cycle.
Also, such change requires testing. So, one with those hardware should
help with it, or the developer willing to do the conversion would
need to get those old hardware in hands.

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: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

[Mauro Carvalho Chehab]

Em Wed, 9 Nov 2016 11:07:35 -0800
Linus Torvalds  escreveu:

> On Wed, Nov 9, 2016 at 3:09 AM, Jörg Otte  wrote:
> >
> > Tried patch with no success. Again a NULL ptr dereferece.  
> 
> That patch was pure garbage, I think. Pretty much all the other
> drivers that use the same approach will have the same issue. Adding
> that init function just for the semaphore is crazy.
> 
> I suspect a much simpler approach is to just miove the "data_mutex"
> away from the priv area and into "struct dvb_usb_device" and
> "dvb_usb_adapter". Sure, that grows those structures a tiny bit, and
> not every driver may need that mutex, but it simplifies things
> enormously. Mauro?

Yeah, makes sense.

I'll work on moving data_mutex to struct dvb_usb_device.

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

Re: [PATCH 2/2] exynos-gsc: Add support for Exynos5433 specific version

[Krzysztof Kozlowski]

On Wed, Nov 09, 2016 at 03:29:38PM +0100, Marek Szyprowski wrote:
> This patch add support for Exynos5433 specific version of GScaller module.
> The main difference is between Exynos 5433 and earlier is addition of
> new clocks that have to be controlled.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  .../devicetree/bindings/media/exynos5-gsc.txt  |  3 +-
>  drivers/media/platform/exynos-gsc/gsc-core.c   | 74 
> --
>  drivers/media/platform/exynos-gsc/gsc-core.h   |  6 +-
>  3 files changed, 62 insertions(+), 21 deletions(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 1/2] exynos-gsc: Enable driver on ARCH_EXYNOS

[Krzysztof Kozlowski]

On Wed, Nov 09, 2016 at 03:29:37PM +0100, Marek Szyprowski wrote:
> This driver can be also used on Exynos5433, which is ARM64-based
> platform, which selects only ARCH_EXYNOS symbol.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

[Linus Torvalds]

On Wed, Nov 9, 2016 at 3:09 AM, Jörg Otte  wrote:
>
> Tried patch with no success. Again a NULL ptr dereferece.

That patch was pure garbage, I think. Pretty much all the other
drivers that use the same approach will have the same issue. Adding
that init function just for the semaphore is crazy.

I suspect a much simpler approach is to just miove the "data_mutex"
away from the priv area and into "struct dvb_usb_device" and
"dvb_usb_adapter". Sure, that grows those structures a tiny bit, and
not every driver may need that mutex, but it simplifies things
enormously. Mauro?

 Linus
--
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 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Rob Herring]

On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:
> On 11/03/2016 11:10 AM, Andi Shyti wrote:
> > Hi Jacek,
> > 
> > > Only DT bindings of LED class drivers should be placed in
> > > Documentation/devicetree/bindings/leds. Please move it to the
> > > media bindings.
> > 
> > that's where I placed it first, but Rob asked me to put it in the
> > LED directory and Cc the LED mailining list.
> > 
> > That's the discussion of the version 2:
> > 
> > https://lkml.org/lkml/2016/9/12/380
> > 
> > Rob, Jacek, could you please agree where I can put the binding?
> 
> I'm not sure if this is a good approach. I've noticed also that
> backlight bindings have been moved to leds, whereas they don't look
> similarly.
> 
> We have common.txt LED bindings, that all LED class drivers' bindings
> have to follow. Neither backlight bindings nor these ones do that,
> which introduces some mess.

And there are probably LED bindings that don't follow common.txt either. 

> Eventually adding a sub-directory, e.g. remote_control could make it
> somehow logically justified, but still - shouldn't bindings be
> placed in the documentation directory related to the subsystem of the
> driver they are predestined to?

No. While binding directories often mirror the driver directories, they 
are not the same. Bindings are grouped by types of h/w and IR LEDs are a 
type of LED.

If you prefer a sub-dir, that is fine with me.

Rob
--
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] exynos-gsc: Enable driver on ARCH_EXYNOS

[Javier Martinez Canillas]

Hello Marek,

On 11/09/2016 11:29 AM, Marek Szyprowski wrote:
> This driver can be also used on Exynos5433, which is ARM64-based
> platform, which selects only ARCH_EXYNOS symbol.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 754edbf1..90ae790 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -266,7 +266,7 @@ config VIDEO_MX2_EMMAPRP
>  config VIDEO_SAMSUNG_EXYNOS_GSC
>   tristate "Samsung Exynos G-Scaler driver"
>   depends on VIDEO_DEV && VIDEO_V4L2
> - depends on ARCH_EXYNOS5 || COMPILE_TEST
> + depends on ARCH_EXYNOS || COMPILE_TEST
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> 

Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] exynos-gsc: Add support for Exynos5433 specific version

[Javier Martinez Canillas]

Hello Marek,

On 11/09/2016 11:29 AM, Marek Szyprowski wrote:
> This patch add support for Exynos5433 specific version of GScaller module.

s/GScaller/GScaler

> The main difference is between Exynos 5433 and earlier is addition of
> new clocks that have to be controlled.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  .../devicetree/bindings/media/exynos5-gsc.txt  |  3 +-
>  drivers/media/platform/exynos-gsc/gsc-core.c   | 74 
> --
>  drivers/media/platform/exynos-gsc/gsc-core.h   |  6 +-
>  3 files changed, 62 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt

Usually the DT changes go in a separate patch as documented in
Documentation/devicetree/bindings/submitting-patches.txt.

But I guess this is a too small change so is OK to squash it?

> index 5fe9372..26ca25b 100644
> --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> @@ -3,7 +3,8 @@
>  G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
>  
>  Required properties:
> -- compatible: should be "samsung,exynos5-gsc"
> +- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
> +   5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)

I would also add 5800 to the list.

Besides these minor comments, the patch looks good to me:

Reviewed-by: Javier Martinez Canillas 

And I've also tested in an Exynos5800 Peach Pi Chromebook:

Tested-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Mauro Carvalho Chehab]

Em Wed, 9 Nov 2016 10:00:58 -0700
Shuah Khan  escreveu:

> > Maybe we can get the Media Device Allocator API work in and then we can
> > get your RFC series in after that. Here is what I propose:
> > 
> > - Keep the fixes in 4.9

Fixes should always be kept. Reverting a fix is not an option.
Instead, do incremental patches on the top of it.

> > - Get Media Device Allocator API patches into 4.9.  
> 
> I meant 4.10 not 4.9
> 
> > - snd-usb-auido work go into 4.10

Sounds like a plan.

> > Then your RFC series could go in. I am looking at the RFC series and that
> > the drivers need to change as well, so this RFC work could take longer.
> > Since we have to make media_device sharable, it is necessary to have a
> > global list approach Media Device Allocator API takes. So it is possible
> > for your RFC series to go on top of the Media Device Allocator API.

Firstly, the RFC series should be converted into something that can
be applicable upstream, e. g.:

- doing the changes over the top of upstream, instead of needing to
  revert patches;

- change all drivers as the kAPI changes;

- be git bisectable, e. g. all patches should compile and run fine
  after each single patch, without introducing regressions.

That probably means that the series should be tested not only on
omap3, but also on some other device drivers.


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

[RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

[Jose Abreu]

Hi All,

This is a RFC patch for Synopsys Designware HDMI RX PHY e405.
This phy receives and decodes HDMI video that is delivered to
a controller. The controller bit is not yet ready for submission
but we are planning to submit it as soon as possible.

Main included features in this driver are:
- Equalizer algorithm that chooses phy best settings
according to detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz)

The driver was implemented as a V4L2 subdevice and the phy
interface with the controller was implemented using V4L2 ioctls.
I do not know if this is the best option but it is not possible
to use the existing API functions directly as we need specific
functions that will be called by the controller at specific
configuration stages. For example, we can only set scrambling
when the sink detects the corresponding bit set in SCDC.

Please notice that we plan to submit more phy drivers as they
are released, maintaining the newly created interface
(dw-phy-pdata.h) and using only one controller driver.

I realize that this code needs a lot of polishment, specially
the equalizer part so I would really apreciate some feedback.

Looking forward to your comments!

Best regards,
Jose Miguel Abreu

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: linux-ker...@vger.kernel.org
Cc: linux-media@vger.kernel.org
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/dw/Kconfig|   8 +
 drivers/media/platform/dw/Makefile   |   3 +
 drivers/media/platform/dw/dw-phy-e405.c  | 732 +++
 drivers/media/platform/dw/dw-phy-e405.h  |  48 ++
 drivers/media/platform/dw/dw-phy-pdata.h |  47 ++
 7 files changed, 841 insertions(+)
 create mode 100644 drivers/media/platform/dw/Kconfig
 create mode 100644 drivers/media/platform/dw/Makefile
 create mode 100644 drivers/media/platform/dw/dw-phy-e405.c
 create mode 100644 drivers/media/platform/dw/dw-phy-e405.h
 create mode 100644 drivers/media/platform/dw/dw-phy-pdata.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..9e8e67f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/dw/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..fb2cf01 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-y += dw/
diff --git a/drivers/media/platform/dw/Kconfig 
b/drivers/media/platform/dw/Kconfig
new file mode 100644
index 000..b3d7044
--- /dev/null
+++ b/drivers/media/platform/dw/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DW_PHY_E405
+   tristate "Synopsys Designware HDMI RX PHY e405 driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+  Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+  To compile this driver as a module, choose M here. The module
+  will be called dw-phy-e405.
diff --git a/drivers/media/platform/dw/Makefile 
b/drivers/media/platform/dw/Makefile
new file mode 100644
index 000..decc494
--- /dev/null
+++ b/drivers/media/platform/dw/Makefile
@@ -0,0 +1,3 @@
+# Makefile for Synopsys Designware HDMI RX
+
+obj-$(CONFIG_VIDEO_DW_PHY_E405) += dw-phy-e405.o
diff --git a/drivers/media/platform/dw/dw-phy-e405.c 
b/drivers/media/platform/dw/dw-phy-e405.c
new file mode 100644
index 000..e9c9cdf
--- /dev/null
+++ b/drivers/media/platform/dw/dw-phy-e405.c
@@ -0,0 +1,732 @@
+/*
+ * Synopsys Designware HDMI RX PHY e405 driver
+ *
+ * Copyright (C) 2016 Synopsys, Inc.
+ * Jose Abreu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dw-phy-e405.h"
+#include "dw-phy-pdata.h"
+
+MODULE_AUTHOR("Jose Abreu ");
+MODULE_DESCRIPTION("Designware HDMI RX PHY e405 driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:dw-phy-e405");
+
+#define PHY_EQ_WAIT_TIME_START 3
+#define PHY_EQ_SLEEP_TIME_CDR  30
+#define PHY_EQ_SLEEP_TIME_ACQ  1
+#define PHY_EQ_BOUNDSPREAD 

Re: Question about 2 gp8psk patches I noticed, and possible bug.

[Mauro Carvalho Chehab]

Em Wed, 9 Nov 2016 07:49:43 -0800
VDR User  escreveu:

> $ gdb /usr/src/linux/vmlinux
> GNU gdb (Debian 7.11.1-2) 7.11.1
> ...
> Reading symbols from /usr/src/linux/vmlinux...done.
> (gdb) l *module_put+0x67
> 0xc10a4b87 is in module_put (kernel/module.c:1108).
> 1103int ret;
> 1104
> 1105if (module) {
> 1106preempt_disable();
> 1107ret = atomic_dec_if_positive(>refcnt);
> 1108WARN_ON(ret < 0);   /* Failed to put refcount */
> 1109trace_module_put(module, _RET_IP_);
> 1110preempt_enable();
> }
> 1112}

OK, I guess we've made progress. Please try the enclosed patch.

Regards,
Mauro

[media] gp8psk: Fix DVB frontend attach

it should be calling module_get() at attach, as otherwise
module_put() will crash.

Signed-off-by: Mauro Carvalho Chehab 


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 00/12] media: Exynos GScaller driver fixes

[Javier Martinez Canillas]

Hello Marek,

On 11/09/2016 11:23 AM, Marek Szyprowski wrote:
> Hi!
> 
> This is a collection of various fixes and cleanups for Exynos GScaller
> media driver. Most of them comes from the forgotten patchset posted long
> time ago by Ulf Hansson:
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg80592.html
> 
> While testing and rebasing them, I added some more cleanups. Tested on
> Exynos5422-based Odroid XU3 board.
> 

I've tested this series on a Exynos5800-based Peach Pi Chromebook. The
patches were tested on top of Sylwester's for-v4.10/media/next branch:

git://linuxtv.org/snawrocki/samsung.git for-v4.10/media/next

So feel free to add for the whole series:

Tested-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 11/09/2016 09:49 AM, Shuah Khan wrote:
> On 11/08/2016 01:19 AM, Sakari Ailus wrote:
>> Hi Shuah,
>>
>> On Mon, Nov 07, 2016 at 01:16:45PM -0700, Shuah Khan wrote:
>>> Hi Sakari,
>>>
>>> On 08/26/2016 05:43 PM, Sakari Ailus wrote:
 Hi folks,

 This is the third version of the RFC set to fix referencing in media
 devices.

 The lifetime of the media device (and media devnode) is now bound to that
 of struct device embedded in it and its memory is only released once the
 last reference is gone: unregistering is simply unregistering, it no
 longer should release memory which could be further accessed.

  
 A video node or a sub-device node also gets a reference to the media
 device, i.e. the release function of the video device node will release
 its reference to the media device. The same goes for file handles to the
 media device.

  
 As a side effect of this is that the media device, it is allocate together
 with the media devnode. The driver may also rely its own resources to the
 media device. Alternatively there's also a priv field to hold drivers
 private pointer (for container_of() is an option in this case). We could
 drop one of these options but currently both are possible.

  
 I've tested this by manually unbinding the omap3isp platform device while
 streaming. Driver changes are required for this to work; by not using
 dynamic allocation (i.e. media_device_alloc()) the old behaviour is still
 supported. This is still unlikely to be a grave problem as there are not
 that many device drivers that support physically removable devices. We've
 had this problem for other devices for many years without paying much
 notice --- that doesn't mean I don't think at least drivers for removable
 devices shouldn't be changed as part of the set later on, I'd just like to
 get review comments on the approach first.

  
 The three patches that originally partially resolved some of these issues
 are reverted in the beginning of the set. I'm still posting this as an RFC
 mainly since the testing is somewhat limited so far.
>>>
>>> The main difference between the approach taken in these 3 reverted fixes and
>>> this RFC series is as follows:
>>>
>>> Reverted fixes:
>>> - Fix the lifetime problem with the media devnode by dynamically allocating
>>>   devnode instead of media_device. One of the main considerations to this
>>>   approach is to isolate the changes in media core and avoid changes to
>>>   drivers.
>>> - I tested these fixes extensively and added selftests and README file for
>>>   the regression tests. I haven't seen any problems after these fixes went
>>>   in while physically removing au0828 device, em028xx, and uvcvideo
>>
>> I'd rather call them workarounds, as they do work around the issues rather
>> than properly fixing them. This approach isn't really extensible to fix the
>> remaining problems either. It is true that *some* of the issues that were
>> present before these patches do not show up anymore with them, but we really
>> do need to fix all of these bugs.
>>
>> The underlying problem is that there may be opened file handles, references
>> from elsewhere in the kernel or such to in-memory objects that are not
>> refcounted properly: referencing released memory is a no-go in kernel.
>>
>>>
>>> This RFC series:
>>> - Dynamically allocates media_device
>>> - This approach requires changes to drivers. It would be wise to not require
>>>   churn to driver code and fix the problem in media-core.
>>>
>>> Do you have information on the problems that still remain with the above 
>>> fixes
>>> in place? These fixes went into 4.8 is I recall correctly. Could you please
>>> send us the list of problems and dmesg for the problems you found with the
>>> above fixes and how this RFC series addresses them.
>>
>> Just try removing a device when it's streaming. No more than that is needed.
>>
>> This is one of the bugs fixed by the patchset, albeit drivers do need to be
>> changed as well to benefit from the changes. 
>>
>>>
>>> Can these problems be fixed without needing to change the approach in the
>>> reverted patches?
>>
>> I don't think it's feasible, really. Besides, the workaround were rather
>> ugly and were merged only since there was a said urgency to have a partial
>> fix early. See above as well.
>>
>>>
>>> I have a patch series on top of the fixes this RFC series is reverting
>>> to allocate media_device only in the cases where sharing media device
>>> is necessary. e.g: au0828 and snd-usb-audio.
>>>
>>> Media Device Allocator 

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 11/08/2016 01:19 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Mon, Nov 07, 2016 at 01:16:45PM -0700, Shuah Khan wrote:
>> Hi Sakari,
>>
>> On 08/26/2016 05:43 PM, Sakari Ailus wrote:
>>> Hi folks,
>>>
>>> This is the third version of the RFC set to fix referencing in media
>>> devices.
>>>
>>> The lifetime of the media device (and media devnode) is now bound to that
>>> of struct device embedded in it and its memory is only released once the
>>> last reference is gone: unregistering is simply unregistering, it no
>>> longer should release memory which could be further accessed.
>>> 
>>> 
>>> A video node or a sub-device node also gets a reference to the media
>>> device, i.e. the release function of the video device node will release
>>> its reference to the media device. The same goes for file handles to the
>>> media device.
>>> 
>>> 
>>> As a side effect of this is that the media device, it is allocate together
>>> with the media devnode. The driver may also rely its own resources to the
>>> media device. Alternatively there's also a priv field to hold drivers
>>> private pointer (for container_of() is an option in this case). We could
>>> drop one of these options but currently both are possible.
>>> 
>>> 
>>> I've tested this by manually unbinding the omap3isp platform device while
>>> streaming. Driver changes are required for this to work; by not using
>>> dynamic allocation (i.e. media_device_alloc()) the old behaviour is still
>>> supported. This is still unlikely to be a grave problem as there are not
>>> that many device drivers that support physically removable devices. We've
>>> had this problem for other devices for many years without paying much
>>> notice --- that doesn't mean I don't think at least drivers for removable
>>> devices shouldn't be changed as part of the set later on, I'd just like to
>>> get review comments on the approach first.
>>> 
>>> 
>>> The three patches that originally partially resolved some of these issues
>>> are reverted in the beginning of the set. I'm still posting this as an RFC
>>> mainly since the testing is somewhat limited so far.
>>
>> The main difference between the approach taken in these 3 reverted fixes and
>> this RFC series is as follows:
>>
>> Reverted fixes:
>> - Fix the lifetime problem with the media devnode by dynamically allocating
>>   devnode instead of media_device. One of the main considerations to this
>>   approach is to isolate the changes in media core and avoid changes to
>>   drivers.
>> - I tested these fixes extensively and added selftests and README file for
>>   the regression tests. I haven't seen any problems after these fixes went
>>   in while physically removing au0828 device, em028xx, and uvcvideo
> 
> I'd rather call them workarounds, as they do work around the issues rather
> than properly fixing them. This approach isn't really extensible to fix the
> remaining problems either. It is true that *some* of the issues that were
> present before these patches do not show up anymore with them, but we really
> do need to fix all of these bugs.
> 
> The underlying problem is that there may be opened file handles, references
> from elsewhere in the kernel or such to in-memory objects that are not
> refcounted properly: referencing released memory is a no-go in kernel.
> 
>>
>> This RFC series:
>> - Dynamically allocates media_device
>> - This approach requires changes to drivers. It would be wise to not require
>>   churn to driver code and fix the problem in media-core.
>>
>> Do you have information on the problems that still remain with the above 
>> fixes
>> in place? These fixes went into 4.8 is I recall correctly. Could you please
>> send us the list of problems and dmesg for the problems you found with the
>> above fixes and how this RFC series addresses them.
> 
> Just try removing a device when it's streaming. No more than that is needed.
> 
> This is one of the bugs fixed by the patchset, albeit drivers do need to be
> changed as well to benefit from the changes. 
> 
>>
>> Can these problems be fixed without needing to change the approach in the
>> reverted patches?
> 
> I don't think it's feasible, really. Besides, the workaround were rather
> ugly and were merged only since there was a said urgency to have a partial
> fix early. See above as well.
> 
>>
>> I have a patch series on top of the fixes this RFC series is reverting
>> to allocate media_device only in the cases where sharing media device
>> is necessary. e.g: au0828 and snd-usb-audio.
>>
>> Media Device Allocator API
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg98793.html
>> 

[PATCH v4l-utils 3/3] ir-keytable: make it possible to select the rc5 streamzap variant

[Sean Young]

It was not possible to select the rc-5-sz protocol.

Signed-off-by: Sean Young 
---
 utils/keytable/keytable.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 3922ad2..202610a 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -123,6 +123,7 @@ const struct protocol_map_entry protocol_map[] = {
{ "rc5",NULL,   SYSFS_RC5   },
{ "rc-5x",  NULL,   SYSFS_INVALID   },
{ "rc5x",   NULL,   SYSFS_INVALID   },
+   { "rc-5-sz",NULL,   SYSFS_RC5_SZ},
{ "jvc","/jvc_decoder", SYSFS_JVC   },
{ "sony",   "/sony_decoder",SYSFS_SONY  },
{ "sony12", NULL,   SYSFS_INVALID   },
-- 
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 v4l-utils 1/3] ir-ctl: add ability to send scancodes in most protocols

[Sean Young]

Teach ir-ctl to send scancodes. This has a number of uses:

1. Controlling devices through IR transmission aka blasting
2. Testing the in-kernel software IR decoders (2 bugs uncovered so far)
3. Testing the capability of hardware IR decoders

All protocols supported by the kernel are supported except for XMP
and the MCE Keyboard.

Signed-off-by: Sean Young 
---
 utils/ir-ctl/Makefile.am |   2 +-
 utils/ir-ctl/ir-ctl.1.in |  82 ++---
 utils/ir-ctl/ir-ctl.c| 130 ++-
 utils/ir-ctl/ir-encode.c | 427 +++
 utils/ir-ctl/ir-encode.h |  35 
 5 files changed, 653 insertions(+), 23 deletions(-)
 create mode 100644 utils/ir-ctl/ir-encode.c
 create mode 100644 utils/ir-ctl/ir-encode.h

diff --git a/utils/ir-ctl/Makefile.am b/utils/ir-ctl/Makefile.am
index 9a1bfed..4c148e5 100644
--- a/utils/ir-ctl/Makefile.am
+++ b/utils/ir-ctl/Makefile.am
@@ -1,6 +1,6 @@
 bin_PROGRAMS = ir-ctl
 man_MANS = ir-ctl.1
 
-ir_ctl_SOURCES = ir-ctl.c
+ir_ctl_SOURCES = ir-ctl.c ir-encode.c
 ir_ctl_LDADD = @LIBINTL@
 ir_ctl_LDFLAGS = $(ARGP_LIBS)
diff --git a/utils/ir-ctl/ir-ctl.1.in b/utils/ir-ctl/ir-ctl.1.in
index 4bdf47e..2efe293 100644
--- a/utils/ir-ctl/ir-ctl.1.in
+++ b/utils/ir-ctl/ir-ctl.1.in
@@ -12,10 +12,13 @@ ir\-ctl \- a swiss\-knife tool to handle raw IR and to set 
lirc options
 [\fIOPTION\fR]... \fI\-\-send\fR [\fIpulse and space file to send\fR]
 .br
 .B ir\-ctl
+[\fIOPTION\fR]... \fI\-\-scancode\fR [\fIprotocol and scancode to send\fR]
+.br
+.B ir\-ctl
 [\fIOPTION\fR]... \fI\-\-record\fR [\fIsave to file\fR]
 .SH DESCRIPTION
 ir\-ctl is a tool that allows one to list the features of a lirc device,
-set its options, record raw IR and send raw IR.
+set its options, record raw IR, send raw IR or send complete IR scancodes.
 .PP
 Note: You need to have read or write permissions on the /dev/lirc device
 for options to work.
@@ -36,6 +39,10 @@ Send IR in text file. It must be in the format described 
below. If this
 option is specified multiple times, send all files in order with 125ms delay
 between them.
 .TP
+\fB-S\fR, \fB\-\-scancode\fR=\fIPROTOCOL:SCANCODE\fR
+Send the IR scancode in the protocol specified. The protocol must one of
+the protocols listed below, followed by a semicolon and the scancode number.
+.TP
 \fB\-1\fR, \fB\-\-oneshot\fR
 When recording, stop recording after the first message, i.e. after a space or
 timeout of more than 19ms is received.
@@ -106,43 +113,74 @@ by length in microseconds. The following is a rc-5 
encoded message:
 .PP
carrier 36000
 .br
-   pulse 920
+   pulse 940
+.br
+   space 860
+.br
+   pulse 1790
+.br
+   space 1750
+.br
+   pulse 880
 .br
-   space 110
+   space 880
 .br
-   pulse 270
+   pulse 900
 .br
-   space 380
+   space 890
 .br
-   pulse 1800
+   pulse 870
 .br
-   space 1560
+   space 900
 .br
-   pulse 1730
+   pulse 1750
 .br
-   space 1630
+   space 900
 .br
-   pulse 1730
+   pulse 890
 .br
-   space 1640
+   space 910
 .br
-   pulse 850
+   pulse 840
 .br
-   space 830
+   space 920
 .br
-   pulse 1690
+   pulse 870
 .br
-   space 820
+   space 920
 .br
-   pulse 860
+   pulse 840
 .br
-   space 1660
+   space 920
 .br
-   pulse 1690
+   pulse 870
 .br
-   space 830
+   space 1810
 .br
-   pulse 850
+   pulse 840
+.PP
+Rather than specifying the raw IR, you can also specify the scancode and
+protocol you want to send. This will also automatically set the correct
+carrier. The above can be written as:
+.PP
+   scancode rc5:0x1e01
+.PP
+Do not specify scancodes with different protocols in one file, as the
+carrier might differ and the transmitter cannot send this. Multiple
+scancodes can be specified in one file but ensure that the rules for the
+protocol are met by inserting an appropriate space between them. Also,
+there are limits to what lirc devices can send in one go.
+.PP
+.SS Supported Protocols
+A scancode with protocol can be specified on the command line or in the
+pulse and space file. The following protocols are supported:
+\fBrc5\fR, \fBrc5x\fR, \fBrc5_sz\fR, \fBjvc\fR, \fBsony12\fR, \fBsony\fB15\fR,
+\fBsony20\fR, \fBnec\fR, \fBnecx\fR, \fBnec32\fR, \fBsanyo\fR, \fBrc6_0\fR,
+\fBrc6_6a_20\fR, \fBrc6_6a_24\fR, \fBrc6_6a_32\fR, \fBrc6_mce\fR, \fBsharp\fR.
+If the scancode starts with 0x it will be interpreted as a
+hexidecimal number, and if it starts with 0 it will be interpreted as an
+octal number.
+.PP
 .SS Wideband and narrowband receiver
 Most IR receivers have a narrowband and wideband receiver. The narrowband
 receiver can receive over longer distances (usually around 10 metres without
@@ -178,6 +216,10 @@ To send the pulse and space file \fBplay\fR on emitter 3:
 .br
\fBir\-ctl \-e 3 \-\-send=play\fR
 .PP
+To send the rc-5 hauppuage '1' scancode:
+.br
+   \fBir\-ctl \-S rc5:0x1e01

[PATCH] [media] nec decoder: wrong bit order for nec32 protocol

[Sean Young]

The bits are sent in lsb first. Hardware decoders also send nec32
in this order (e.g. dib0700). This should be consistent, however
I have no way of knowing which order the LME2510 and Tivo keymaps
are (the only two kernel keymaps with NEC32).

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-nec-decoder.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 2a9d155..ba02d05 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -170,7 +170,10 @@ static int ir_nec_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
if (send_32bits) {
/* NEC transport, but modified protocol, used by at
 * least Apple and TiVo remotes */
-   scancode = data->bits;
+   scancode = address << 24 |
+  not_address << 16 |
+  command << 8 |
+  not_command;
IR_dprintk(1, "NEC (modified) scancode 0x%08x\n", 
scancode);
rc_type = RC_TYPE_NEC32;
} else if ((address ^ not_address) != 0xff) {
-- 
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] [media] sanyo decoder: address was being truncated

[Sean Young]

The address is 13 bits but it was stuffed in an u8, so 5 bits are
missing from the scancode.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-sanyo-decoder.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-sanyo-decoder.c 
b/drivers/media/rc/ir-sanyo-decoder.c
index 7331e5e7..b07d9ca 100644
--- a/drivers/media/rc/ir-sanyo-decoder.c
+++ b/drivers/media/rc/ir-sanyo-decoder.c
@@ -56,7 +56,8 @@ static int ir_sanyo_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
 {
struct sanyo_dec *data = >raw->sanyo;
u32 scancode;
-   u8 address, command, not_command;
+   u16 address;
+   u8 command, not_command;
 
if (!is_timing_event(ev)) {
if (ev.reset) {
-- 
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 v4l-utils 2/3] ir-ctl: add verbose option

[Sean Young]

This is useful to see what IR is actually being sent (e.g. after
scancode generation).

Signed-off-by: Sean Young 
---
 utils/ir-ctl/ir-ctl.1.in |  3 +++
 utils/ir-ctl/ir-ctl.c| 15 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.1.in b/utils/ir-ctl/ir-ctl.1.in
index 2efe293..a1d5aeb 100644
--- a/utils/ir-ctl/ir-ctl.1.in
+++ b/utils/ir-ctl/ir-ctl.1.in
@@ -99,6 +99,9 @@ Prints the help message
 \fB\-\-usage\fR
 Give a short usage message
 .TP
+\fB\-v\fR, \fB\-\-verbose\fR
+Verbose output; this prints the IR before sending.
+.TP
 \fB\-V\fR, \fB\-\-version\fR
 print the v4l2\-utils version
 .PP
diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index bdea741..f19bd05 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -65,6 +65,7 @@ struct arguments {
char *device;
bool features;
bool record;
+   bool verbose;
struct file *send;
bool oneshot;
char *savetofile;
@@ -85,6 +86,7 @@ static const struct argp_option options[] = {
{ "record", 'r',N_("FILE"), OPTION_ARG_OPTIONAL,
N_("record IR to stdout or file") },
{ "send",   's',N_("FILE"), 0,  N_("send IR pulse and 
space file") },
{ "scancode", 'S',  N_("SCANCODE"), 0,  N_("send IR scancode in 
protocol specified") },
+   { "verbose",'v',0,  0,  N_("verbose output") },
{ .doc = N_("Recording options:") },
{ "one-shot",   '1',0,  0,  N_("end recording after 
first message") },
{ "wideband",   'w',0,  0,  N_("use wideband 
receiver aka learning mode") },
@@ -397,6 +399,9 @@ static error_t parse_opt(int k, char *arg, struct 
argp_state *state)
case '1':
arguments->oneshot = true;
break;
+   case 'v':
+   arguments->verbose = true;
+   break;
case 'm':
if (arguments->carrier_reports == 2)
argp_error(state, _("cannot enable and disable carrier 
reports"));
@@ -515,7 +520,7 @@ static error_t parse_opt(int k, char *arg, struct 
argp_state *state)
return ARGP_ERR_UNKNOWN;
}
 
-   if (k != '1' && k != 'd')
+   if (k != '1' && k != 'd' && k != 'v')
arguments->work_to_do = true;
 
return 0;
@@ -739,6 +744,12 @@ static int lirc_send(struct arguments *args, int fd, 
unsigned features, struct f
lirc_set_send_carrier(fd, dev, features, f->carrier);
 
size_t size = f->len * sizeof(unsigned);
+   if (args->verbose) {
+   int i;
+   printf("Sending:\n");
+   for (i=0; ilen; i++)
+   printf("%s %u\n", i & 1 ? "space" : "pulse", f->buf[i]);
+   }
ssize_t ret = TEMP_FAILURE_RETRY(write(fd, f->buf, size));
if (ret < 0) {
fprintf(stderr, _("%s: failed to send: %m\n"), dev);
@@ -752,6 +763,8 @@ static int lirc_send(struct arguments *args, int fd, 
unsigned features, struct f
size / sizeof(unsigned));
return EX_IOERR;
}
+   if (args->verbose)
+   printf("Successfully sent\n");
 
return 0;
 }
-- 
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 5/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
device represents a channel and each channel can have one or two
sub-channels respectively depending on the target board.

DRIF supports only Rx functionality. It receives samples from a RF
frontend tuner chip it is interfaced with. The combination of DRIF and the
tuner device, which is registered as a sub-device, determines the receive
sample rate and format.

In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
the tuner device, which can be provided by a third party vendor. DRIF acts
as a slave device and the tuner device acts as a master transmitting the
samples. The driver allows asynchronous binding of a tuner device that
is registered as a v4l2 sub-device. The driver can learn about the tuner
it is interfaced with based on port endpoint properties of the device in
device tree. The V4L2 SDR device inherits the controls exposed by the
tuner device.

The device can also be configured to use either one or both of the data
pins at runtime based on the master (tuner) configuration.

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../devicetree/bindings/media/renesas,drif.txt |  136 ++
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1574 
 4 files changed, 1736 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
 create mode 100644 drivers/media/platform/rcar_drif.c

diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
b/Documentation/devicetree/bindings/media/renesas,drif.txt
new file mode 100644
index 000..d65368a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
@@ -0,0 +1,136 @@
+Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
+
+
+R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
+device as shown below
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+| |-SD0--->|D0   |
+| |-SD1--->|D1   |
++-++-+
+
+Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
+The sub-channels are like two individual channels in itself that share the
+common CLK & SYNC. Each sub-channel has it's own dedicated resources like
+irq, dma channels, address space & clock.
+
+The device tree model represents the channel and each of it's sub-channel
+as a separate node. The parent channel ties the sub-channels together with
+their phandles.
+
+Required properties of a sub-channel:
+-
+- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
SoC.
+ "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
device.
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+- reg: offset and length of that sub-channel.
+- interrupts: associated with that sub-channel.
+- clocks: phandle and clock specifier of that sub-channel.
+- clock-names: clock input name string: "fck".
+- dmas: phandles to the DMA channel of that sub-channel.
+- dma-names: names of the DMA channel: "rx".
+
+Optional properties of a sub-channel:
+-
+- power-domains: phandle to the respective power domain.
+
+Required properties of a channel:
+-
+- pinctrl-0: pin control group to be used for this channel.
+- pinctrl-names: must be "default".
+- sub-channels : phandles to the two sub-channels.
+
+Optional properties of a channel:
+-
+- port: child port node of a channel that defines the local and remote
+endpoints. The remote endpoint is assumed to be a tuner subdevice
+   endpoint.
+- renesas,syncmd   : sync mode
+0 (Frame start sync pulse mode. 1-bit width pulse
+   indicates start of a frame)
+1 (L/R sync or I2S mode) (default)
+- renesas,lsb-first: empty property indicates lsb bit is received first.
+When not defined msb bit is received first (default)
+- renesas,syncac-pol-high  : empty property indicates sync signal polarity.
+When defined, active high or high->low sync signal.
+When not defined, active low or low->high sync signal
+(default)
+- 

[PATCH 2/5] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../devicetree/bindings/media/i2c/max2175.txt  |   61 +
 drivers/media/i2c/Kconfig  |4 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/max2175/Kconfig  |8 +
 drivers/media/i2c/max2175/Makefile |4 +
 drivers/media/i2c/max2175/max2175.c| 1558 
 drivers/media/i2c/max2175/max2175.h|  108 ++
 7 files changed, 1745 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
 create mode 100644 drivers/media/i2c/max2175/Kconfig
 create mode 100644 drivers/media/i2c/max2175/Makefile
 create mode 100644 drivers/media/i2c/max2175/max2175.c
 create mode 100644 drivers/media/i2c/max2175/max2175.h

diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
b/Documentation/devicetree/bindings/media/i2c/max2175.txt
new file mode 100644
index 000..69f0dad
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
@@ -0,0 +1,61 @@
+Maxim Integrated MAX2175 RF to Bits tuner
+-
+
+The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
+RF to Bits® front-end designed for software-defined radio solutions.
+
+Required properties:
+
+- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
+- clocks: phandle to the fixed xtal clock.
+- clock-names: name of the fixed xtal clock.
+- port: child port node of a tuner that defines the local and remote
+  endpoints. The remote endpoint is assumed to be an SDR device
+  that is capable of receiving the digital samples from the tuner.
+
+Optional properties:
+
+- maxim,slave: empty property indicates this is a slave of
+   another master tuner. This is used to define two
+   tuners in diversity mode (1 master, 1 slave). By
+   default each tuner is an individual master.
+- maxim,refout-load-pF: load capacitance value (in pF) on reference
+   output drive level. The possible load values are
+0pF (default - refout disabled)
+   10pF
+   20pF
+   30pF
+   40pF
+   60pF
+   70pF
+- maxim,am-hiz   : empty property indicates AM Hi-Z filter path is
+   selected for AM antenna input. By default this
+   filter path is not used.
+
+Example:
+
+
+Board specific DTS file
+
+/* Fixed XTAL clock node */
+maxim_xtal: maximextal {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <36864000>;
+};
+
+/* A tuner device instance under i2c bus */
+max2175_0: tuner@60 {
+   compatible = "maxim,max2175";
+   reg = <0x60>;
+   clocks = <_xtal>;
+   clock-names = "xtal";
+   maxim,refout-load-pF = <10>;
+
+   port {
+   max2175_0_ep: endpoint {
+   remote-endpoint = <_rx_v4l2_sdr_device>;
+   };
+   };
+
+};
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..66c73b0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -749,6 +749,10 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+source "drivers/media/i2c/max2175/Kconfig"
+
 comment "Miscellaneous helper chips"
 
 config VIDEO_THS7303
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..cfae721 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -6,6 +6,8 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-y  += soc_camera/
 
+obj-$(CONFIG_SDR_MAX2175)  += max2175/
+
 obj-$(CONFIG_VIDEO_APTINA_PLL) += aptina-pll.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
diff --git a/drivers/media/i2c/max2175/Kconfig 
b/drivers/media/i2c/max2175/Kconfig
new file mode 100644
index 000..93a8f83
--- /dev/null
+++ b/drivers/media/i2c/max2175/Kconfig
@@ -0,0 +1,8 @@
+config SDR_MAX2175
+   tristate "Maxim 2175 RF to Bits tuner"
+   depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
+   ---help---
+ Support for Maxim 2175 tuner
+
+ To compile this driver as a module, choose M here; the
+ module will be called max2175.
diff --git a/drivers/media/i2c/max2175/Makefile 

[PATCH 1/5] media: v4l2-ctrls: Reserve controls for MAX217X

[Ramesh Shanmugasundaram]

Reserve controls for MAX217X RF to Bits tuner (family) chips. These hybrid
radio receiver chips are highly programmable and hence reserving 32
controls.

Signed-off-by: Ramesh Shanmugasundaram 
---
 include/uapi/linux/v4l2-controls.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index b6a357a..b7404c9 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -180,6 +180,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_TC358743_BASE(V4L2_CID_USER_BASE + 0x1080)
 
+/* The base for the max217x driver controls.
+ * We reserve 32 controls for this driver
+ */
+#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
1.9.1

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

[PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

This patch adds support for the three new SDR formats. These formats
were prefixed with "sliced" indicating I data constitutes the top half and
Q data constitutes the bottom half of the received buffer.

V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
inside 16-bit. V4L2 FourCC: SC16

V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
inside 18-bit. V4L2 FourCC: SC18

V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
inside 20-bit. V4L2 FourCC: SC20

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
 include/uapi/linux/videodev2.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 181381d..d36b386 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
+   case V4L2_SDR_FMT_SCU16BE:  descr = "Sliced Complex U16BE"; break;
+   case V4L2_SDR_FMT_SCU18BE:  descr = "Sliced Complex U18BE"; break;
+   case V4L2_SDR_FMT_SCU20BE:  descr = "Sliced Complex U20BE"; break;
case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4364ce6..34a9c30 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -666,6 +666,9 @@ struct v4l2_pix_format {
 #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /* complex 
s8 */
 #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /* complex 
s14le */
 #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /* real 
u12le */
+#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /* sliced 
complex u16be */
+#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /* sliced 
complex u18be */
+#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /* sliced 
complex u20be */
 
 /* Touch formats - used for Touch devices */
 #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 
16-bit signed deltas */
-- 
1.9.1

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

[PATCH 4/5] doc_rst: media: New SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_SCU16BE
V4L2_SDR_FMT_SCU18BE
V4L2_SDR_FMT_SCU20BE

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../media/uapi/v4l/pixfmt-sdr-scu16be.rst  | 80 ++
 .../media/uapi/v4l/pixfmt-sdr-scu18be.rst  | 80 ++
 .../media/uapi/v4l/pixfmt-sdr-scu20be.rst  | 80 ++
 Documentation/media/uapi/v4l/sdr-formats.rst   |  3 +
 4 files changed, 243 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
new file mode 100644
index 000..7525378
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
@@ -0,0 +1,80 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-SCU16BE:
+
+**
+V4L2_SDR_FMT_SCU16BE ('SC16')
+**
+
+Sliced complex unsigned 16-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 16 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+
+  -  Byte B0
+
+  -  Byte B1
+
+  -  Byte B2
+
+  -  Byte B3
+
+* -  start + 0:
+
+  -  I'\ :sub:`0[13:6]`
+
+  -  I'\ :sub:`0[5:0]; B1[1:0]=pad`
+
+  -  pad
+
+  -  pad
+
+* -  start + 4:
+
+  -  I'\ :sub:`1[13:6]`
+
+  -  I'\ :sub:`1[5:0]; B1[1:0]=pad`
+
+  -  pad
+
+  -  pad
+
+* -  ...
+
+* - start + offset:
+
+  -  Q'\ :sub:`0[13:6]`
+
+  -  Q'\ :sub:`0[5:0]; B1[1:0]=pad`
+
+  -  pad
+
+  -  pad
+
+* - start + offset + 4:
+
+  -  Q'\ :sub:`1[13:6]`
+
+  -  Q'\ :sub:`1[5:0]; B1[1:0]=pad`
+
+  -  pad
+
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
new file mode 100644
index 000..0ce714d
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
@@ -0,0 +1,80 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-SCU18BE:
+
+**
+V4L2_SDR_FMT_SCU18BE ('SC18')
+**
+
+Sliced complex unsigned 18-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 18 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+
+  -  Byte B0
+
+  -  Byte B1
+
+  -  Byte B2
+
+  -  Byte B3
+
+* -  start + 0:
+
+  -  I'\ :sub:`0[17:10]`
+
+  -  I'\ :sub:`0[9:2]`
+
+  -  I'\ :sub:`0[1:0]; B2[5:0]=pad`
+
+  -  pad
+
+* -  start + 4:
+
+  -  I'\ :sub:`1[17:10]`
+
+  -  I'\ :sub:`1[9:2]`
+
+  -  I'\ :sub:`1[1:0]; B2[5:0]=pad`
+
+  -  pad
+
+* -  ...
+
+* - start + offset:
+
+  -  Q'\ :sub:`0[17:10]`
+
+  -  Q'\ :sub:`0[9:2]`
+
+  -  Q'\ :sub:`0[1:0]; B2[5:0]=pad`
+
+  -  pad
+
+* - start + offset + 4:
+
+  -  Q'\ :sub:`1[17:10]`
+
+  -  Q'\ :sub:`1[9:2]`
+
+  -  Q'\ :sub:`1[1:0]; B2[5:0]=pad`
+
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
new file mode 100644
index 000..ff2fe51
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
@@ -0,0 +1,80 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-SCU20BE:
+
+**
+V4L2_SDR_FMT_SCU20BE ('SC20')
+**
+
+Sliced complex unsigned 20-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q 

[PATCH 0/5] Add V4L2 SDR (DRIF & MAX2175) driver

[Ramesh Shanmugasundaram]

Hi All,

This patch set contains two drivers
 - R-Car Digital Radio Interface (DRIF) driver
 - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media-next repo
commit: 778de01402328ca88cda84491d819bfc949935ff

These two drivers combined together expose a V4L2 SDR device that is compliant
with the V4L2 framework [1]. The RFC series of these two drivers were
published few weeks ago and the discussion thread is here [2]. Agreed review
comments are incorporated in this series.

Brief description of devices below

DRIF:
-
This is a receive only slave controller that receives data into a FIFO from a
master device and uses DMA engine to move it from device to memory. It is a
serial I/O like controller with a design goal to act as digital radio receiver
targeting SDR solutions.

MAX2175:

This is a RF front end tuner device that supports tuning to different bands &
frequency. It supports I2S output with programmable word lengths & single/dual
data lines usage based on selected receive mode. Each receive mode is
designated with a sample rate.

+-++-+
| |-SCK--->| |
| MAX2175 (master)|-SS>|  DRIF (slave)   |
| |-SD0--->| |
| |-SD1--->| |
+-++-+

New SDR formats:

The combined driver exposes new SDR formats. DRIF as such requires the receive
word length as the only programmable parameter in a normal case. Otherwise it is
agnostic of the tuner.

V4L2 framework requires publishing SDR formats about position of I & Q data
within the buffers. I have published three such formats to give an example. More
such formats are possible and will be added when needed.

References:

[1] v4l2-compliance test report

root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : 788b674f3827607c09c31be11c91638f816aa6ae

Driver Info:
Driver name   : rcar_drif
Card type : R-Car DRIF
Bus info  : platform:R-Car DRIF
Driver version: 4.9.0
Capabilities  : 0x8531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

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

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

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

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 4

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: 

Re: Question about 2 gp8psk patches I noticed, and possible bug.

[VDR User]

$ gdb /usr/src/linux/vmlinux
GNU gdb (Debian 7.11.1-2) 7.11.1
...
Reading symbols from /usr/src/linux/vmlinux...done.
(gdb) l *module_put+0x67
0xc10a4b87 is in module_put (kernel/module.c:1108).
1103int ret;
1104
1105if (module) {
1106preempt_disable();
1107ret = atomic_dec_if_positive(>refcnt);
1108WARN_ON(ret < 0);   /* Failed to put refcount */
1109trace_module_put(module, _RET_IP_);
1110preempt_enable();
}
1112}
--
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: Question about 2 gp8psk patches I noticed, and possible bug.

[VDR User]

Hi Mauro,

Here are the results after testing the latest patch:

[33922.643770] usbcore: deregistering interface driver dvb_usb_gp8psk
[33922.643789] gp8psk: unregistering fe0
[33922.643865] gp8psk: detaching fe0
[33922.643868] [ cut here ]
[33922.643875] WARNING: CPU: 1 PID: 8895 at kernel/module.c:1108
module_put+0x67/0x80
[33922.643876] Modules linked in: dvb_usb_gp8psk(O-) dvb_usb(O)
dvb_core(O) nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi
snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer
snd soundcore nvidia(PO) [last unloaded: dvb_core]
[33922.643890] CPU: 1 PID: 8895 Comm: rmmod Tainted: PWC O
4.8.4-build.2 #1
[33922.643891] Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
[33922.643893]   c12c15f0   c103fc7a c161ecc0
0001 22bf
[33922.643897]  c161e50f 0454 c10a4b87 c10a4b87 0009 f804fd80
 
[33922.643901]  f3cca000 c103fd43 0009   c10a4b87
f804e6e0 c10a58fa
[33922.643905] Call Trace:
[33922.643909]  [] ? dump_stack+0x44/0x64
[33922.643913]  [] ? __warn+0xfa/0x120
[33922.643915]  [] ? module_put+0x67/0x80
[33922.643917]  [] ? module_put+0x67/0x80
[33922.643919]  [] ? warn_slowpath_null+0x23/0x30
[33922.643921]  [] ? module_put+0x67/0x80
[33922.643924]  [] ? gp8psk_fe_set_frontend+0x460/0x460
[dvb_usb_gp8psk]
[33922.643927]  [] ? symbol_put_addr+0x2a/0x50
[33922.643929]  [] ? gp8psk_usb_disconnect+0xb9/0xd0 [dvb_usb_gp8psk]
[33922.643932]  [] ? usb_unbind_interface+0x62/0x250
[33922.643936]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
[33922.643939]  [] ? __pm_runtime_idle+0x44/0x70
[33922.643943]  [] ? __device_release_driver+0x78/0x120
[33922.643945]  [] ? driver_detach+0x87/0x90
[33922.643947]  [] ? bus_remove_driver+0x38/0x90
[33922.643949]  [] ? usb_deregister+0x58/0xb0
[33922.643951]  [] ? SyS_delete_module+0x130/0x1f0
[33922.643954]  [] ? __do_page_fault+0x1a0/0x440
[33922.643956]  [] ? exit_to_usermode_loop+0x85/0x90
[33922.643958]  [] ? do_fast_syscall_32+0x80/0x130
[33922.643961]  [] ? sysenter_past_esp+0x40/0x6a
[33922.643962] ---[ end trace a387b7eddb538bfe ]---
[33922.643963] gp8psk: calling dvb_usb_device_exit
[33922.646462] dvb-usb: Genpix SkyWalker-2 DVB-S receiver successfully
deinitialized and disconnected.

$ gdb /usr/src/linux/drivers/media/usb/dvb-usb/dvb-usb-gp8psk.ko
GNU gdb (Debian 7.11.1-2) 7.11.1
...
Reading symbols from
/usr/src/linux/drivers/media/usb/dvb-usb/dvb-usb-gp8psk.ko...done.
(gdb) l *gp8psk_fe_set_frontend+0x460
0x1710 is in gp8psk_fe_release (drivers/media/usb/dvb-usb/gp8psk-fe.c:325).
320 }
321
322 static void gp8psk_fe_release(struct dvb_frontend* fe)
323 {
324 struct gp8psk_fe_state *state = fe->demodulator_priv;
325 kfree(state);
326 }
327
328 static struct dvb_frontend_ops gp8psk_fe_ops;
329
(gdb) l *gp8psk_usb_disconnect+0xb9
0xe9 is in gp8psk_usb_disconnect (drivers/media/usb/dvb-usb/gp8psk.c:432).
427 for (; i >= 0; i--) {
428 if (adap->fe_adap[i].fe != NULL) {
429 printk("gp8psk: unregistering
fe%d\n", i);
430
dvb_unregister_frontend(adap->fe_adap[i].fe);
431 printk("gp8psk: detaching fe%d\n", i);
432
dvb_frontend_detach(adap->fe_adap[i].fe);
433 }
434 }
435 adap->num_frontends_initialized = 0;
436 }

Thanks,
Derek
--
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] cec: zero counters in cec_received_msg()

[Hans Verkuil]

Make sure the TX counters are zeroed in the cec_msg struct.
Non-zero TX counters make no sense when a message is received,
and applications should not see non-zero values here.

Signed-off-by: Hans Verkuil 
---
This sits on top of my earlier cec pull request that moves cec to the 
mainline.

---
 drivers/media/cec/cec-adap.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index ed76d70..d9c6f2c 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -874,6 +874,10 @@ void cec_received_msg(struct cec_adapter *adap, 
struct cec_msg *msg)

msg->sequence = msg->reply = msg->timeout = 0;
msg->tx_status = 0;
msg->tx_ts = 0;
+   msg->tx_arb_lost_cnt = 0;
+   msg->tx_nack_cnt = 0;
+   msg->tx_low_drive_cnt = 0;
+   msg->tx_error_cnt = 0;
msg->flags = 0;
memset(msg->msg + msg->len, 0, sizeof(msg->msg) - msg->len);

--
2.7.0

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

Re: [PATCH 09/12] exynos-gsc: Simplify system PM even more

[Ulf Hansson]

On 9 November 2016 at 15:23, Marek Szyprowski  wrote:
> System pm callbacks only ensures that device is runtime suspended/resumed,
> so remove them and use generic pm_runtime_force_suspend/resume helper.
>
> Signed-off-by: Marek Szyprowski 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 21 ++---
>  1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 4859727..1e8b216 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1166,26 +1166,9 @@ static int gsc_runtime_suspend(struct device *dev)
>  }
>  #endif
>
> -#ifdef CONFIG_PM_SLEEP
> -static int gsc_resume(struct device *dev)
> -{
> -   if (!pm_runtime_suspended(dev))
> -   return gsc_runtime_resume(dev);
> -
> -   return 0;
> -}
> -
> -static int gsc_suspend(struct device *dev)
> -{
> -   if (!pm_runtime_suspended(dev))
> -   return gsc_runtime_suspend(dev);
> -
> -   return 0;
> -}
> -#endif
> -
>  static const struct dev_pm_ops gsc_pm_ops = {
> -   SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
> +   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +   pm_runtime_force_resume)
> SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
>  };
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] media: Exynos GScaller: add support for Exynos 5433 SoC

[Marek Szyprowski]

Hi!

This patchset add support for Exynos 5433 SoC to Exynos GScaller driver.
This patchset requires fixes for Exynos GScaller driver posted
in the "[PATCH 00/12] media: Exynos GScaller driver fixes" thread.

Tested on Exynos5433-based TM2 board.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Patch summary:

Marek Szyprowski (2):
  exynos-gsc: Enable driver on ARCH_EXYNOS
  exynos-gsc: Add support for Exynos5433 specific version

 .../devicetree/bindings/media/exynos5-gsc.txt  |  3 +-
 drivers/media/platform/Kconfig |  2 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   | 74 --
 drivers/media/platform/exynos-gsc/gsc-core.h   |  6 +-
 4 files changed, 63 insertions(+), 22 deletions(-)

-- 
1.9.1

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

[PATCH 1/2] exynos-gsc: Enable driver on ARCH_EXYNOS

[Marek Szyprowski]

This driver can be also used on Exynos5433, which is ARM64-based
platform, which selects only ARCH_EXYNOS symbol.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..90ae790 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -266,7 +266,7 @@ config VIDEO_MX2_EMMAPRP
 config VIDEO_SAMSUNG_EXYNOS_GSC
tristate "Samsung Exynos G-Scaler driver"
depends on VIDEO_DEV && VIDEO_V4L2
-   depends on ARCH_EXYNOS5 || COMPILE_TEST
+   depends on ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-- 
1.9.1

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

[PATCH 2/2] exynos-gsc: Add support for Exynos5433 specific version

[Marek Szyprowski]

This patch add support for Exynos5433 specific version of GScaller module.
The main difference is between Exynos 5433 and earlier is addition of
new clocks that have to be controlled.

Signed-off-by: Marek Szyprowski 
---
 .../devicetree/bindings/media/exynos5-gsc.txt  |  3 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   | 74 --
 drivers/media/platform/exynos-gsc/gsc-core.h   |  6 +-
 3 files changed, 62 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 5fe9372..26ca25b 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,7 +3,8 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc"
+- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
+ 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 664398c..827c1bb 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -29,8 +29,6 @@
 
 #include "gsc-core.h"
 
-#define GSC_CLOCK_GATE_NAME"gscl"
-
 static const struct gsc_fmt gsc_formats[] = {
{
.name   = "RGB565",
@@ -965,6 +963,19 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
[3] = _v_100_variant,
},
.num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_5433_drvdata = {
+   .variant = {
+   [0] = _v_100_variant,
+   [1] = _v_100_variant,
+   [2] = _v_100_variant,
+   },
+   .num_entities = 3,
+   .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
+   .num_clocks = 4,
 };
 
 static const struct of_device_id exynos_gsc_match[] = {
@@ -972,6 +983,10 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.compatible = "samsung,exynos5-gsc",
.data = _v_100_drvdata,
},
+   {
+   .compatible = "samsung,exynos5433-gsc",
+   .data = _5433_drvdata,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_gsc_match);
@@ -983,6 +998,7 @@ static int gsc_probe(struct platform_device *pdev)
struct device *dev = >dev;
const struct gsc_driverdata *drv_data = of_device_get_match_data(dev);
int ret;
+   int i;
 
gsc = devm_kzalloc(dev, sizeof(struct gsc_dev), GFP_KERNEL);
if (!gsc)
@@ -998,6 +1014,7 @@ static int gsc_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   gsc->num_clocks = drv_data->num_clocks;
gsc->variant = drv_data->variant[gsc->id];
gsc->pdev = pdev;
 
@@ -1016,18 +1033,24 @@ static int gsc_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   gsc->clock = devm_clk_get(dev, GSC_CLOCK_GATE_NAME);
-   if (IS_ERR(gsc->clock)) {
-   dev_err(dev, "failed to get clock~~~: %s\n",
-   GSC_CLOCK_GATE_NAME);
-   return PTR_ERR(gsc->clock);
+   for (i = 0; i < gsc->num_clocks; i++) {
+   gsc->clock[i] = devm_clk_get(dev, drv_data->clk_names[i]);
+   if (IS_ERR(gsc->clock[i])) {
+   dev_err(dev, "failed to get clock: %s\n",
+   drv_data->clk_names[i]);
+   return PTR_ERR(gsc->clock[i]);
+   }
}
 
-   ret = clk_prepare_enable(gsc->clock);
-   if (ret) {
-   dev_err(>pdev->dev, "clock prepare failed for clock: %s\n",
-   GSC_CLOCK_GATE_NAME);
-   return ret;
+   for (i = 0; i < gsc->num_clocks; i++) {
+   ret = clk_prepare_enable(gsc->clock[i]);
+   if (ret) {
+   dev_err(dev, "clock prepare failed for clock: %s\n",
+   drv_data->clk_names[i]);
+   while (--i >= 0)
+   clk_disable_unprepare(gsc->clock[i]);
+   return ret;
+   }
}
 
ret = devm_request_irq(dev, res->start, gsc_irq_handler,
@@ -1062,13 +1085,15 @@ static int gsc_probe(struct platform_device *pdev)
 err_v4l2:
v4l2_device_unregister(>v4l2_dev);
 err_clk:
-   clk_disable_unprepare(gsc->clock);
+   for (i = gsc->num_clocks - 1; i >= 0; i--)
+   clk_disable_unprepare(gsc->clock[i]);
return ret;
 }
 
 static int gsc_remove(struct platform_device *pdev)
 {
struct gsc_dev 

[PATCH 06/12] exynos-gsc: Do full clock gating at runtime PM suspend

[Marek Szyprowski]

From: Ulf Hansson 

To potentially save more power in runtime PM suspend state, let's also
prepare/unprepare the clock from the runtime PM callbacks.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 1d3bde3..9ba1619 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1141,7 +1141,7 @@ static int gsc_runtime_resume(struct device *dev)
 
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
 
-   ret = clk_enable(gsc->clock);
+   ret = clk_prepare_enable(gsc->clock);
if (ret)
return ret;
 
@@ -1159,7 +1159,7 @@ static int gsc_runtime_suspend(struct device *dev)
 
ret = gsc_m2m_suspend(gsc);
if (!ret)
-   clk_disable(gsc->clock);
+   clk_disable_unprepare(gsc->clock);
 
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
return ret;
-- 
1.9.1

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

[PATCH 10/12] exynos-gsc: Remove unused lclk_freqency entry

[Marek Szyprowski]

Remove dead, unused code.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 1 -
 drivers/media/platform/exynos-gsc/gsc-core.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 1e8b216..ff35909 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -964,7 +964,6 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
[3] = _v_100_variant,
},
.num_entities = 4,
-   .lclk_frequency = 26600UL,
 };
 
 static const struct of_device_id exynos_gsc_match[] = {
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 8480aec..e5aa8f4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -303,12 +303,10 @@ struct gsc_variant {
  * struct gsc_driverdata - per device type driver data for init time.
  *
  * @variant: the variant information for this driver.
- * @lclk_frequency: G-Scaler clock frequency
  * @num_entities: the number of g-scalers
  */
 struct gsc_driverdata {
struct gsc_variant *variant[GSC_MAX_DEVS];
-   unsigned long   lclk_frequency;
int num_entities;
 };
 
-- 
1.9.1

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

[PATCH 12/12] exynos-gsc: Use of_device_get_match_data() helper

[Marek Szyprowski]

Replace open-coded driver data extraction code with generic helper.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index ac4c96c..664398c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "gsc-core.h"
@@ -975,24 +976,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 };
 MODULE_DEVICE_TABLE(of, exynos_gsc_match);
 
-static void *gsc_get_drv_data(struct platform_device *pdev)
-{
-   struct gsc_driverdata *driver_data = NULL;
-   const struct of_device_id *match;
-
-   match = of_match_node(exynos_gsc_match, pdev->dev.of_node);
-   if (match)
-   driver_data = (struct gsc_driverdata *)match->data;
-
-   return driver_data;
-}
-
 static int gsc_probe(struct platform_device *pdev)
 {
struct gsc_dev *gsc;
struct resource *res;
-   struct gsc_driverdata *drv_data = gsc_get_drv_data(pdev);
struct device *dev = >dev;
+   const struct gsc_driverdata *drv_data = of_device_get_match_data(dev);
int ret;
 
gsc = devm_kzalloc(dev, sizeof(struct gsc_dev), GFP_KERNEL);
-- 
1.9.1

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

[PATCH 08/12] exynos-gsc: Simplify system PM

[Marek Szyprowski]

From: Ulf Hansson 

It's not needed to keep a local flag about the current system PM state.
Let's just remove that code and the corresponding debug print.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 21 -
 drivers/media/platform/exynos-gsc/gsc-core.h |  3 ---
 2 files changed, 24 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index af6502c..4859727 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1169,20 +1169,6 @@ static int gsc_runtime_suspend(struct device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int gsc_resume(struct device *dev)
 {
-   struct gsc_dev *gsc = dev_get_drvdata(dev);
-   unsigned long flags;
-
-   pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
-   /* Do not resume if the device was idle before system suspend */
-   spin_lock_irqsave(>slock, flags);
-   if (!test_and_clear_bit(ST_SUSPEND, >state) ||
-   !gsc_m2m_opened(gsc)) {
-   spin_unlock_irqrestore(>slock, flags);
-   return 0;
-   }
-   spin_unlock_irqrestore(>slock, flags);
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_resume(dev);
 
@@ -1191,13 +1177,6 @@ static int gsc_resume(struct device *dev)
 
 static int gsc_suspend(struct device *dev)
 {
-   struct gsc_dev *gsc = dev_get_drvdata(dev);
-
-   pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
-   if (test_and_set_bit(ST_SUSPEND, >state))
-   return 0;
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_suspend(dev);
 
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 7ad7b9d..8480aec 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -48,9 +48,6 @@
 #defineGSC_CTX_ABORT   (1 << 7)
 
 enum gsc_dev_flags {
-   /* for global */
-   ST_SUSPEND,
-
/* for m2m node */
ST_M2M_OPEN,
ST_M2M_RUN,
-- 
1.9.1

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

[PATCH 01/12] exynos-gsc: Simplify clock management

[Marek Szyprowski]

From: Ulf Hansson 

Instead of having separate functions that fecthes, prepares and
unprepares the clock, let's encapsulate this code into ->probe().

This makes error handling easier and decreases the lines of code.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 49 
 1 file changed, 14 insertions(+), 35 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 787bd16..abebbdb 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -988,36 +988,6 @@ static void *gsc_get_drv_data(struct platform_device *pdev)
return driver_data;
 }
 
-static void gsc_clk_put(struct gsc_dev *gsc)
-{
-   if (!IS_ERR(gsc->clock))
-   clk_unprepare(gsc->clock);
-}
-
-static int gsc_clk_get(struct gsc_dev *gsc)
-{
-   int ret;
-
-   dev_dbg(>pdev->dev, "gsc_clk_get Called\n");
-
-   gsc->clock = devm_clk_get(>pdev->dev, GSC_CLOCK_GATE_NAME);
-   if (IS_ERR(gsc->clock)) {
-   dev_err(>pdev->dev, "failed to get clock~~~: %s\n",
-   GSC_CLOCK_GATE_NAME);
-   return PTR_ERR(gsc->clock);
-   }
-
-   ret = clk_prepare(gsc->clock);
-   if (ret < 0) {
-   dev_err(>pdev->dev, "clock prepare failed for clock: %s\n",
-   GSC_CLOCK_GATE_NAME);
-   gsc->clock = ERR_PTR(-EINVAL);
-   return ret;
-   }
-
-   return 0;
-}
-
 static int gsc_m2m_suspend(struct gsc_dev *gsc)
 {
unsigned long flags;
@@ -1085,7 +1055,6 @@ static int gsc_probe(struct platform_device *pdev)
init_waitqueue_head(>irq_queue);
spin_lock_init(>slock);
mutex_init(>lock);
-   gsc->clock = ERR_PTR(-EINVAL);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
gsc->regs = devm_ioremap_resource(dev, res);
@@ -1098,9 +1067,19 @@ static int gsc_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   ret = gsc_clk_get(gsc);
-   if (ret)
+   gsc->clock = devm_clk_get(dev, GSC_CLOCK_GATE_NAME);
+   if (IS_ERR(gsc->clock)) {
+   dev_err(dev, "failed to get clock~~~: %s\n",
+   GSC_CLOCK_GATE_NAME);
+   return PTR_ERR(gsc->clock);
+   }
+
+   ret = clk_prepare(gsc->clock);
+   if (ret) {
+   dev_err(>pdev->dev, "clock prepare failed for clock: %s\n",
+   GSC_CLOCK_GATE_NAME);
return ret;
+   }
 
ret = devm_request_irq(dev, res->start, gsc_irq_handler,
0, pdev->name, gsc);
@@ -1135,7 +1114,7 @@ static int gsc_probe(struct platform_device *pdev)
 err_v4l2:
v4l2_device_unregister(>v4l2_dev);
 err_clk:
-   gsc_clk_put(gsc);
+   clk_unprepare(gsc->clock);
return ret;
 }
 
@@ -1148,7 +1127,7 @@ static int gsc_remove(struct platform_device *pdev)
 
vb2_dma_contig_clear_max_seg_size(>dev);
pm_runtime_disable(>dev);
-   gsc_clk_put(gsc);
+   clk_unprepare(gsc->clock);
 
dev_dbg(>dev, "%s driver unloaded\n", pdev->name);
return 0;
-- 
1.9.1

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

[PATCH 11/12] exynos-gsc: Add missing newline char in debug messages

[Marek Szyprowski]

Fix missing newline char in debug messages.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index ff35909..ac4c96c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1138,7 +1138,7 @@ static int gsc_runtime_resume(struct device *dev)
struct gsc_dev *gsc = dev_get_drvdata(dev);
int ret = 0;
 
-   pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
+   pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
 
ret = clk_prepare_enable(gsc->clock);
if (ret)
@@ -1160,7 +1160,7 @@ static int gsc_runtime_suspend(struct device *dev)
if (!ret)
clk_disable_unprepare(gsc->clock);
 
-   pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
+   pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
return ret;
 }
 #endif
-- 
1.9.1

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

[PATCH 07/12] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP

[Marek Szyprowski]

From: Ulf Hansson 

There are no need to set up the system PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.

Silence the warnings by making them available for CONFIG_PM_SLEEP.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9ba1619..af6502c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1166,6 +1166,7 @@ static int gsc_runtime_suspend(struct device *dev)
 }
 #endif
 
+#ifdef CONFIG_PM_SLEEP
 static int gsc_resume(struct device *dev)
 {
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1202,10 +1203,10 @@ static int gsc_suspend(struct device *dev)
 
return 0;
 }
+#endif
 
 static const struct dev_pm_ops gsc_pm_ops = {
-   .suspend= gsc_suspend,
-   .resume = gsc_resume,
+   SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
 };
 
-- 
1.9.1

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

[PATCH 09/12] exynos-gsc: Simplify system PM even more

[Marek Szyprowski]

System pm callbacks only ensures that device is runtime suspended/resumed,
so remove them and use generic pm_runtime_force_suspend/resume helper.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4859727..1e8b216 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1166,26 +1166,9 @@ static int gsc_runtime_suspend(struct device *dev)
 }
 #endif
 
-#ifdef CONFIG_PM_SLEEP
-static int gsc_resume(struct device *dev)
-{
-   if (!pm_runtime_suspended(dev))
-   return gsc_runtime_resume(dev);
-
-   return 0;
-}
-
-static int gsc_suspend(struct device *dev)
-{
-   if (!pm_runtime_suspended(dev))
-   return gsc_runtime_suspend(dev);
-
-   return 0;
-}
-#endif
-
 static const struct dev_pm_ops gsc_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
 };
 
-- 
1.9.1

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

[PATCH 03/12] exynos-gsc: Make driver functional when CONFIG_PM is unset

[Marek Szyprowski]

From: Ulf Hansson 

The driver depended on CONFIG_PM to be functional. Let's remove that
dependency, by enable the runtime PM resourses during ->probe() and
update the device's runtime PM status to reflect this.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index cb4e8bd..b5a99af 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1072,7 +1072,7 @@ static int gsc_probe(struct platform_device *pdev)
return PTR_ERR(gsc->clock);
}
 
-   ret = clk_prepare(gsc->clock);
+   ret = clk_prepare_enable(gsc->clock);
if (ret) {
dev_err(>pdev->dev, "clock prepare failed for clock: %s\n",
GSC_CLOCK_GATE_NAME);
@@ -1095,24 +1095,23 @@ static int gsc_probe(struct platform_device *pdev)
goto err_v4l2;
 
platform_set_drvdata(pdev, gsc);
-   pm_runtime_enable(dev);
-   ret = pm_runtime_get_sync(>dev);
-   if (ret < 0)
-   goto err_m2m;
+
+   gsc_hw_set_sw_reset(gsc);
+   gsc_wait_reset(gsc);
 
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
dev_dbg(dev, "gsc-%d registered successfully\n", gsc->id);
 
-   pm_runtime_put(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
return 0;
 
-err_m2m:
-   gsc_unregister_m2m_device(gsc);
 err_v4l2:
v4l2_device_unregister(>v4l2_dev);
 err_clk:
-   clk_unprepare(gsc->clock);
+   clk_disable_unprepare(gsc->clock);
return ret;
 }
 
-- 
1.9.1

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

[PATCH 05/12] exynos-gsc: Fixup clock management at ->remove()

[Marek Szyprowski]

From: Ulf Hansson 

To make sure the clock is fully gated in ->remove(), we first need to
to bring the device into full power by invoking pm_runtime_get_sync().

Then, let's both unprepare and disable the clock.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 7e99fda..1d3bde3 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1082,12 +1082,15 @@ static int gsc_remove(struct platform_device *pdev)
 {
struct gsc_dev *gsc = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(>dev);
+
gsc_unregister_m2m_device(gsc);
v4l2_device_unregister(>v4l2_dev);
 
vb2_dma_contig_clear_max_seg_size(>dev);
-   pm_runtime_disable(>dev);
-   clk_unprepare(gsc->clock);
+   clk_disable_unprepare(gsc->clock);
+
+   pm_runtime_put_noidle(>dev);
 
dev_dbg(>dev, "%s driver unloaded\n", pdev->name);
return 0;
-- 
1.9.1

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

[PATCH 02/12] exynos-gsc: Convert gsc_m2m_resume() from int to void

[Marek Szyprowski]

From: Ulf Hansson 

Since gsc_m2m_resume() always returns 0, convert it to a void instead.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index abebbdb..cb4e8bd 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1010,7 +1010,7 @@ static int gsc_m2m_suspend(struct gsc_dev *gsc)
return timeout == 0 ? -EAGAIN : 0;
 }
 
-static int gsc_m2m_resume(struct gsc_dev *gsc)
+static void gsc_m2m_resume(struct gsc_dev *gsc)
 {
struct gsc_ctx *ctx;
unsigned long flags;
@@ -1023,8 +1023,6 @@ static int gsc_m2m_resume(struct gsc_dev *gsc)
 
if (test_and_clear_bit(ST_M2M_SUSPENDED, >state))
gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-
-   return 0;
 }
 
 static int gsc_probe(struct platform_device *pdev)
@@ -1146,8 +1144,9 @@ static int gsc_runtime_resume(struct device *dev)
 
gsc_hw_set_sw_reset(gsc);
gsc_wait_reset(gsc);
+   gsc_m2m_resume(gsc);
 
-   return gsc_m2m_resume(gsc);
+   return 0;
 }
 
 static int gsc_runtime_suspend(struct device *dev)
-- 
1.9.1

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

[PATCH 04/12] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM

[Marek Szyprowski]

From: Ulf Hansson 

There are no need to set up the runtime PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.

Silence the warnings by making them available for CONFIG_PM.

Signed-off-by: Ulf Hansson 
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 79 ++--
 1 file changed, 40 insertions(+), 39 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index b5a99af..7e99fda 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -988,43 +988,6 @@ static void *gsc_get_drv_data(struct platform_device *pdev)
return driver_data;
 }
 
-static int gsc_m2m_suspend(struct gsc_dev *gsc)
-{
-   unsigned long flags;
-   int timeout;
-
-   spin_lock_irqsave(>slock, flags);
-   if (!gsc_m2m_pending(gsc)) {
-   spin_unlock_irqrestore(>slock, flags);
-   return 0;
-   }
-   clear_bit(ST_M2M_SUSPENDED, >state);
-   set_bit(ST_M2M_SUSPENDING, >state);
-   spin_unlock_irqrestore(>slock, flags);
-
-   timeout = wait_event_timeout(gsc->irq_queue,
-test_bit(ST_M2M_SUSPENDED, >state),
-GSC_SHUTDOWN_TIMEOUT);
-
-   clear_bit(ST_M2M_SUSPENDING, >state);
-   return timeout == 0 ? -EAGAIN : 0;
-}
-
-static void gsc_m2m_resume(struct gsc_dev *gsc)
-{
-   struct gsc_ctx *ctx;
-   unsigned long flags;
-
-   spin_lock_irqsave(>slock, flags);
-   /* Clear for full H/W setup in first run after resume */
-   ctx = gsc->m2m.ctx;
-   gsc->m2m.ctx = NULL;
-   spin_unlock_irqrestore(>slock, flags);
-
-   if (test_and_clear_bit(ST_M2M_SUSPENDED, >state))
-   gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-}
-
 static int gsc_probe(struct platform_device *pdev)
 {
struct gsc_dev *gsc;
@@ -1130,6 +1093,44 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int gsc_m2m_suspend(struct gsc_dev *gsc)
+{
+   unsigned long flags;
+   int timeout;
+
+   spin_lock_irqsave(>slock, flags);
+   if (!gsc_m2m_pending(gsc)) {
+   spin_unlock_irqrestore(>slock, flags);
+   return 0;
+   }
+   clear_bit(ST_M2M_SUSPENDED, >state);
+   set_bit(ST_M2M_SUSPENDING, >state);
+   spin_unlock_irqrestore(>slock, flags);
+
+   timeout = wait_event_timeout(gsc->irq_queue,
+test_bit(ST_M2M_SUSPENDED, >state),
+GSC_SHUTDOWN_TIMEOUT);
+
+   clear_bit(ST_M2M_SUSPENDING, >state);
+   return timeout == 0 ? -EAGAIN : 0;
+}
+
+static void gsc_m2m_resume(struct gsc_dev *gsc)
+{
+   struct gsc_ctx *ctx;
+   unsigned long flags;
+
+   spin_lock_irqsave(>slock, flags);
+   /* Clear for full H/W setup in first run after resume */
+   ctx = gsc->m2m.ctx;
+   gsc->m2m.ctx = NULL;
+   spin_unlock_irqrestore(>slock, flags);
+
+   if (test_and_clear_bit(ST_M2M_SUSPENDED, >state))
+   gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
 static int gsc_runtime_resume(struct device *dev)
 {
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1160,6 +1161,7 @@ static int gsc_runtime_suspend(struct device *dev)
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
return ret;
 }
+#endif
 
 static int gsc_resume(struct device *dev)
 {
@@ -1201,8 +1203,7 @@ static int gsc_suspend(struct device *dev)
 static const struct dev_pm_ops gsc_pm_ops = {
.suspend= gsc_suspend,
.resume = gsc_resume,
-   .runtime_suspend= gsc_runtime_suspend,
-   .runtime_resume = gsc_runtime_resume,
+   SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
 };
 
 static struct platform_driver gsc_driver = {
-- 
1.9.1

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

[PATCH 00/12] media: Exynos GScaller driver fixes

[Marek Szyprowski]

Hi!

This is a collection of various fixes and cleanups for Exynos GScaller
media driver. Most of them comes from the forgotten patchset posted long
time ago by Ulf Hansson:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg80592.html

While testing and rebasing them, I added some more cleanups. Tested on
Exynos5422-based Odroid XU3 board.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Patch summary:

Marek Szyprowski (4):
  exynos-gsc: Simplify system PM even more
  exynos-gsc: Remove unused lclk_freqency entry
  exynos-gsc: Add missing newline char in debug messages
  exynos-gsc: Use of_device_get_match_data() helper

Ulf Hansson (8):
  exynos-gsc: Simplify clock management
  exynos-gsc: Convert gsc_m2m_resume() from int to void
  exynos-gsc: Make driver functional when CONFIG_PM is unset
  exynos-gsc: Make runtime PM callbacks available for CONFIG_PM
  exynos-gsc: Fixup clock management at ->remove()
  exynos-gsc: Do full clock gating at runtime PM suspend
  exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP
  exynos-gsc: Simplify system PM

 drivers/media/platform/exynos-gsc/gsc-core.c | 214 +--
 drivers/media/platform/exynos-gsc/gsc-core.h |   5 -
 2 files changed, 73 insertions(+), 146 deletions(-)

-- 
1.9.1

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

Re: [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

[Hans Verkuil]

On 11/09/16 14:28, Dan Carpenter wrote:

Hello Tiffany Lin,

The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 
vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
   520  static int vidioc_vdec_qbuf(struct file *file, void *priv,
   521  struct v4l2_buffer *buf)
   522  {
   523  struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
   524  struct vb2_queue *vq;
   525  struct vb2_buffer *vb;
   526  struct mtk_video_dec_buf *mtkbuf;
   527  struct vb2_v4l2_buffer  *vb2_v4l2;
   528
   529  if (ctx->state == MTK_STATE_ABORT) {
   530  mtk_v4l2_err("[%d] Call on QBUF after unrecoverable 
error",
   531  ctx->id);
   532  return -EIO;
   533  }
   534
   535  vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
   536  vb = vq->bufs[buf->index];

Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow.  It seems simple
enough to analyse the call tree.

__video_do_ioctl()
->  v4l_qbuf()
  -> vidioc_vdec_qbuf()

It seems like Smatch is correct.  I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.

This has obvious security implications.  Can someone take a look at
this?


This is indeed wrong.

The v4l2_m2m_qbuf() call at the end of this function calls in turn 
vb2_qbuf which
will check the index. But if you override vidioc_qbuf (or 
vidioc_prepare), then

you need to check the index value.

I double-checked all cases where vidioc_qbuf was set to a 
driver-specific function
and this is the only driver that doesn't check the index field. In all 
other cases
it is either checked, or it is not used before calling into the vb1/vb2 
framework

which checks this.

So luckily this only concerns this driver.

Regards,

Hans



   537  vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
   538  mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
   539
   540  if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
   541  (buf->m.planes[0].bytesused == 0)) {
   542  mtkbuf->lastframe = true;
   543  mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, %d) 
vb=%p",
   544   ctx->id, buf->type, buf->index,
   545   mtkbuf->lastframe, buf->bytesused,
   546   buf->m.planes[0].bytesused, buf->length,
   547   vb);
   548  }
   549
   550  return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
   551  }

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


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

[bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

[Dan Carpenter]

Hello Tiffany Lin,

The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 
vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
   520  static int vidioc_vdec_qbuf(struct file *file, void *priv,
   521  struct v4l2_buffer *buf)
   522  {
   523  struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
   524  struct vb2_queue *vq;
   525  struct vb2_buffer *vb;
   526  struct mtk_video_dec_buf *mtkbuf;
   527  struct vb2_v4l2_buffer  *vb2_v4l2;
   528  
   529  if (ctx->state == MTK_STATE_ABORT) {
   530  mtk_v4l2_err("[%d] Call on QBUF after unrecoverable 
error",
   531  ctx->id);
   532  return -EIO;
   533  }
   534  
   535  vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
   536  vb = vq->bufs[buf->index];

Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow.  It seems simple
enough to analyse the call tree.

__video_do_ioctl()
->  v4l_qbuf()
  -> vidioc_vdec_qbuf()

It seems like Smatch is correct.  I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.

This has obvious security implications.  Can someone take a look at
this?

   537  vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
   538  mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
   539  
   540  if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
   541  (buf->m.planes[0].bytesused == 0)) {
   542  mtkbuf->lastframe = true;
   543  mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, 
%d) vb=%p",
   544   ctx->id, buf->type, buf->index,
   545   mtkbuf->lastframe, buf->bytesused,
   546   buf->m.planes[0].bytesused, buf->length,
   547   vb);
   548  }
   549  
   550  return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
   551  }

regards,
dan carpenter
--
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: Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Mon, 07 Nov 2016 12:53:55 +0200
Jani Nikula  escreveu:

> On Mon, 07 Nov 2016, Mauro Carvalho Chehab  wrote:
> > Hi Jon,
> >
> > I'm trying to sort out the next steps to do after KS, with regards to
> > images included on RST files.
> >
> > The issue is that Sphinx image support highly depends on the output
> > format. Also, despite TexLive support for svg and png images[1], Sphinx
> > doesn't produce the right LaTeX commands to use svg[2]. On my tests
> > with PNG on my notebook, it also didn't seem to do the right thing for
> > PNG either. So, it seems that the only safe way to support images is
> > to convert all of them to PDF for latex/pdf build.
> >
> > [1] On Fedora, via texlive-dvipng and texlive-svg
> > [2] https://github.com/sphinx-doc/sphinx/issues/1907
> >
> > As far as I understand from KS, two decisions was taken:
> >
> > - We're not adding a sphinx extension to run generic commands;
> > - The PDF images should be build in runtime from their source files
> >   (either svg or bitmap), and not ship anymore the corresponding
> >   PDF files generated from its source.
> >
> > As you know, we use several images at the media documentation:
> > https://www.kernel.org/doc/html/latest/_images/
> >
> > Those images are tightly coupled with the explanation texts. So,
> > maintaining them away from the documentation is not an option.
> >
> > I was originally thinking that adding a graphviz extension would solve the
> > issue, but, in fact, most of the images aren't diagrams. Instead, there are 
> > several ones with images showing the result of passing certain parameters to
> > the ioctls, explaining things like scale and cropping and how bytes are
> > packed on some image formats.
> >
> > Linus proposed to call some image conversion tool like ImageMagick or
> > inkscape to convert them to PDF when building the pdfdocs or latexdocs
> > target at Makefile, but there's an issue with that: Sphinx doesn't read
> > files from Documentation/output, and writing them directly at the
> > source dir would be against what it is expected when the "O=" argument
> > is passed to make. 
> >
> > So, we have a few alternatives:
> >
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> >build dir specified via O= directive) and generate the *.pdf there,
> >and produce those converted images via Makefile.;
> >
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> >inkscape to convert the bitmap;
> >
> > 3) if possible, add an extension to trick Sphinx for it to consider the 
> >output dir as a source dir too.  
> 
> Looking at the available extensions, and the images to be displayed,
> seems to me making svg work, somehow, is the right approach. (As opposed
> to trying to represent the images in graphviz or whatnot.)

I guess answered this one already, but it got lost somehow...

The problem is not just with svg. Sphinx also do the wrong thing with
PNG, despite apparently generating the right LaTeX image include command.

> IIUC texlive supports displaying svg directly, but the problem is that
> Sphinx produces bad latex for that. Can we make it work by manually
> writing the latex? If yes, we wouldn't need to use an external tool to
> convert the svg to something else, but rather fix the latex. Thus:
> 
> 4a) See if this works:
> 
> .. only:: html
> 
>.. image:: foo.svg

We're currently using .. figure:: instead, as it allow optional caption
and legend, but I got the idea.

> .. raw:: latex
> 
>

That is a horrible hack, and will lose other attributes at
image:: (or figure::), like :align:

Also, it won't solve, as the images will need to be copied to the
build dir via Makefile, as Spinx only copies the images it recognizes.

So, in practice, the only difference is that Makefile would be calling
"cp" instead of "convert", plus we'll have to hack all ReST sources.

> 4b) Add a directive extension to make the above happen automatically.

If doable, I agree that this is the best solution. Any volunteers to write
such extension?

> Of course, the correct fix is to have this fixed in upstream Sphinx, but
> as a workaround an extension doing the above seems plausible, and not
> too much effort - provided that we can make the raw latex work.

Yeah, fixing it on Sphinx upstream would be the best, but we'll still
need to maintain the workaround for a while for the unpatched versions
of Sphinx.

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: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Markus Heiser  wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>>> So I vote for :
>>> 
 1) copy (or symlink) all rst files to Documentation/output (or to the
 build dir specified via O= directive) and generate the *.pdf there,
 and produce those converted images via Makefile.;
>> 
>> We're supposed to solve problems, not create new ones.
>
> ... new ones? ...

Handle in-tree builds without copying.

Make dependency analysis with source rst and "intermediate" rst work.

Make sure your copying gets the timestamps right.

Make Sphinx dependency analysis look at the right copies depending on
in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
own dependency analysis.

The stuff I didn't think of.

Sure, it's all supposed to be basic Makefile stuff, but don't make the
mistake of thinking just one invocation of 'cp' will solve all the
problems. It all adds to the complexity we were trying to avoid when
dumping DocBook. It adds to the complexity of debugging stuff. (And hey,
there's still the one rebuilding-stuff-for-no-reason issue open.)

If you want to keep the documentation build sane, try to avoid the
Makefile preprocessing. And same old story, if you fix this for real,
even if as a Sphinx extension, *other* people than kernel developers
will be interested, and *we* don't have to do so much ourselves.


BR,
Jani.



>
>>> IMO placing 'sourcedir' to O= is more sane since this marries the
>>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>>> (in or below 'sourcedir').
>
> -- Markus --

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Mauro Carvalho Chehab  wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula  escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> >>  build dir specified via O= directive) and generate the *.pdf there,
>> >>  and produce those converted images via Makefile.;  
>> 
>> We're supposed to solve problems, not create new ones.
>
> So, what's your proposal?

Second message in the thread,
http://lkml.kernel.org/r/87wpgf8ssc@intel.com

>
> Thanks,
> Mauro
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: [Ksummit-discuss] Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Wed, 09 Nov 2016 13:16:55 +0200
Jani Nikula  escreveu:

> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
> >>  build dir specified via O= directive) and generate the *.pdf there,
> >>  and produce those converted images via Makefile.;  
> 
> We're supposed to solve problems, not create new ones.

So, what's your proposal?

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: [Ksummit-discuss] Including images on Sphinx documents

[Markus Heiser]

Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>> So I vote for :
>> 
>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>> build dir specified via O= directive) and generate the *.pdf there,
>>> and produce those converted images via Makefile.;
> 
> We're supposed to solve problems, not create new ones.

... new ones? ...

>> IMO placing 'sourcedir' to O= is more sane since this marries the
>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>> (in or below 'sourcedir').

-- Markus --
--
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: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

[Jörg Otte]

2016-11-08 21:22 GMT+01:00 Mauro Carvalho Chehab :
> Em Tue, 8 Nov 2016 10:42:03 -0800
> Linus Torvalds  escreveu:
>
>> On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte  wrote:
>> > Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module.
>>
>> Looks like it's commit 5ef8ed0e5608f ("[media] cinergyT2-core: don't
>> do DMA on stack"), which movced the DMA data array from the stack to
>> the "private" pointer. In the process it also added serialization in
>> the form of "data_mutex", but and now it oopses on that mutex because
>> the private pointer is NULL.
>>
>> It looks like the "->private" pointer is allocated in dvb_usb_adapter_init()
>>
>> cinergyt2_usb_probe ->
>>   dvb_usb_device_init ->
>> dvb_usb_init() ->
>>   dvb_usb_adapter_init()
>>
>> but the dvb_usb_init() function calls dvb_usb_device_power_ctrl()
>> (which calls the "power_ctrl" function, which is
>> cinergyt2_power_ctrl() for that drive) *before* it initializes the
>> private field.
>>
>> Mauro, Patrick, could dvb_usb_adapter_init() be called earlier, perhaps?
>
> Calling it earlier won't work, as we need to load the firmware before
> sending the power control commands on some devices.
>
> Probably the best here is to pass an extra optional function parameter
> that will initialize the mutex before calling any functions.
>
> Btw, if it broke here, the DMA fixes will likely break on other drivers.
> So, after Jörg tests this patch, I'll work on a patch series addressing
> this issue on the other drivers I touched.
>
> Regards,
> Mauro
>
> -
>
> [PATCH RFC] cinergyT2-core: initialize the mutex early
>
> NOTE: don't merge this patch as-is... I actually folded two patches
> together here, in order to make easier to test, but the best is to
> place the changes at the core first, and then the changes at the
> drivers that would need an early init.
>
> The mutex used to protect the URB data buffer needs to be
> inialized early, as otherwise it will cause an OOPS:
>
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm 
> state.
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: [] __mutex_lock_slowpath+0x6f/0x100 PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: dvb_usb_cinergyT2(+) dvb_usb
> CPU: 0 PID: 2029 Comm: modprobe Not tainted 4.9.0-rc4-dvbmod #24
> Hardware name: FUJITSU LIFEBOOK A544/FJNBB35 , BIOS Version 1.17 05/09/2014
> task: 88020e943840 task.stack: 8801f36ec000
> RIP: 0010:[]  [] 
> __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:8801f36efb10  EFLAGS: 00010282
> RAX:  RBX: 88021509bdc8 RCX: c100
> RDX: 0001 RSI:  RDI: 88021509bdcc
> RBP: 8801f36efb58 R08: 88021f216320 R09: 0010
> R10: 88021f216320 R11: 0023fee6c5a1 R12: 88020e943840
> R13: 88021509bdcc R14:  R15: 88021509bdd0
> FS:  7f21adb86740() GS:88021f20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000215bce000 CR4: 001406f0
> Stack:
>  88021509bdd0   c0137c80
>  88021509bdc8 8801f5944000 0001 c0136b00
>  880213e52000 88021509bdc8 84661856 88021509bd80
> Call Trace:
>  [] ? mutex_lock+0x16/0x25
>  [] ? cinergyt2_power_ctrl+0x1f/0x60 [dvb_usb_cinergyT2]
>  [] ? dvb_usb_device_init+0x21e/0x5d0 [dvb_usb]
>  [] ? cinergyt2_usb_probe+0x21/0x50 [dvb_usb_cinergyT2]
>  [] ? usb_probe_interface+0xf3/0x2a0
>  [] ? driver_probe_device+0x208/0x2b0
>  [] ? __driver_attach+0x87/0x90
>  [] ? driver_probe_device+0x2b0/0x2b0
>  [] ? bus_for_each_dev+0x52/0x80
>  [] ? bus_add_driver+0x1a3/0x220
>  [] ? driver_register+0x56/0xd0
>  [] ? usb_register_driver+0x77/0x130
>  [] ? 0xc013a000
>  [] ? do_one_initcall+0x46/0x180
>  [] ? free_vmap_area_noflush+0x38/0x70
>  [] ? kmem_cache_alloc+0x84/0xc0
>  [] ? do_init_module+0x50/0x1be
>  [] ? load_module+0x1d8b/0x2100
>  [] ? find_symbol_in_section+0xa0/0xa0
>  [] ? SyS_finit_module+0x89/0x90
>  [] ? entry_SYSCALL_64_fastpath+0x13/0x94
> Code: e8 a7 1d 00 00 8b 03 83 f8 01 0f 84 97 00 00 00 48 8b 43 10 4c 8d 7b 08 
> 48 89 63 10 4c 89 3c 24 41 be ff ff ff ff 48 89 44 24 08 <48> 89 20 4c 89 64 
> 24 10 eb 1a 49 c7 44 24 08 02 00 00 00 c6 43 RIP  [] 
> __mutex_lock_slowpath+0x6f/0x100 RSP 
> CR2: 
>
> Reported-by: Jörg Otte 
> Fixes: 6679a901c380 ("[media] cinergyT2-core: don't do DMA on stack")
> Signed-off-by: Mauro Carvalho Chehab 
>
> From cbc7e48a86e8ffd16e49b10061120dfc417397f8 Mon Sep 17 00:00:00 2001
> From: Mauro Carvalho Chehab 
> Date: Tue, 8 Nov 2016 18:04:24 -0200
> Subject: [PATCH] [media] dvb-usb: allow early initialization of usb device
>  priv data
>
> On some drivers, we need to initialize a 

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Markus Heiser  wrote:
> Am 07.11.2016 um 18:01 schrieb Josh Triplett :
>
>> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>>>  inkscape to convert the bitmap;
>> 
>> This seems sensible; Sphinx should directly handle the source format we
>> want to use for images/diagrams.
>> 
>>> 3) if possible, add an extension to trick Sphinx for it to consider the 
>>>  output dir as a source dir too.
>> 
>> Or to provide an additional source path and point that at the output
>> directory.
>
> The sphinx-build command excepts only one 'sourcedir' argument. All
> reST files in this folder (and below) are parsed.
>
> Most (all?) directives which include content like images or literalinclude
> except only relative pathnames. Where *relative* means, relative to the
> reST file where the directive is used. For security reasons relative 
> pathnames outside 'sourcepath' are not excepted.
>
> So I vote for :
>
>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>  build dir specified via O= directive) and generate the *.pdf there,
>>  and produce those converted images via Makefile.;

We're supposed to solve problems, not create new ones.

> Placing reST files together with the *autogenerated* (intermediate) 
> content from
>
> * image conversions,
> * reST content build from MAINTAINERS,
> * reST content build for ABI
> * etc.
>
> has the nice side effect, that we can get rid of all theses BUILDDIR
> quirks in the Makefile.sphinx
>
> Additional, we can write Makefile targets to build the above listed
> intermediate content relative to the $PWD, which is what Linux's
> Makefiles usual do (instead of quirking with a BUILDDIR).
>
> E.g. with, we can also get rid of the 'kernel-include' directive 
> and replace it, with Sphinx's common 'literaliclude' and we do not
> need any extensions to include intermediate PDFs or whatever
> intermediate content we might want to generate. 

Well, kernel-include is a hack to make parse-headers.pl work, which is
also a hack that IMHO shouldn't exist...

> IMO placing 'sourcedir' to O= is more sane since this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Question about 2 gp8psk patches I noticed, and possible bug.

[Mauro Carvalho Chehab]

Em Tue, 8 Nov 2016 22:00:41 -0800
VDR User  escreveu:

> Hi Mauro,
> 
> Unfortunately the patch doesn't seem to have solved the problem. I do
> have the kernel recompiled with debug enabled though per your irc msg.
> dmesg gives me:
> 
> [   70.741073] usbcore: deregistering interface driver dvb_usb_gp8psk
> [   70.741165] [ cut here ]
> [   70.741172] WARNING: CPU: 1 PID: 2119 at kernel/module.c:1108
> module_put+0x67/0x80
> [   70.741174] Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core
> nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel
> snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore
> nvidia(PO)
> [   70.741186] CPU: 1 PID: 2119 Comm: rmmod Tainted: P   O
> 4.8.4-build.2 #1
> [   70.741187] Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
> [   70.741189]   c12c15f0   c103fc7a c161ecc0
> 0001 0847
> [   70.741194]  c161e50f 0454 c10a4b87 c10a4b87 0009 fb090cc0
>  
> [   70.741197]  f4e72000 c103fd43 0009   c10a4b87
> fb08f6a0 c10a58fa
> [   70.741202] Call Trace:
> [   70.741206]  [] ? dump_stack+0x44/0x64
> [   70.741209]  [] ? __warn+0xfa/0x120
> [   70.741211]  [] ? module_put+0x67/0x80
> [   70.741213]  [] ? module_put+0x67/0x80
> [   70.741215]  [] ? warn_slowpath_null+0x23/0x30
> [   70.741217]  [] ? module_put+0x67/0x80
> [   70.741221]  [] ? gp8psk_fe_set_frontend+0x460/0x460
> [dvb_usb_gp8psk]
> [   70.741223]  [] ? symbol_put_addr+0x2a/0x50
> [   70.741225]  [] ? gp8psk_usb_disconnect+0x4e/0x90 
> [dvb_usb_gp8psk]

Ok, it is running your new driver.

> [   70.741229]  [] ? usb_unbind_interface+0x62/0x250
> [   70.741233]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
> [   70.741235]  [] ? __pm_runtime_idle+0x44/0x70
> [   70.741239]  [] ? __device_release_driver+0x78/0x120
> [   70.741241]  [] ? driver_detach+0x87/0x90
> [   70.741243]  [] ? bus_remove_driver+0x38/0x90
> [   70.741245]  [] ? usb_deregister+0x58/0xb0
> [   70.741248]  [] ? SyS_delete_module+0x130/0x1f0
> [   70.741251]  [] ? __do_page_fault+0x1a0/0x440
> [   70.741253]  [] ? exit_to_usermode_loop+0x85/0x90
> [   70.741254]  [] ? do_fast_syscall_32+0x80/0x130
> [   70.741257]  [] ? sysenter_past_esp+0x40/0x6a
> [   70.741259] ---[ end trace a387b7eddb538bfb ]---
> [   70.743654] dvb-usb: Genpix SkyWalker-2 DVB-S receiver successfully
> deinitialized and disconnected.
> 
> 
> I read the Bug Hunting url but it's still not clear to me which line
> from that dmesg text I should be focused on. It would suggest the
> first line (dump_stack+0x44/0x64) but you pointed to
> gp8psk_fe_set_frontend so I'm not sure what to do next. 

I wrote some patches a few days ago improving bug hunting. Just updated
it at fedorapeople:

https://mchehab.fedorapeople.org/kernel_docs/admin-guide/bug-hunting.html

Basically, each line on the above is a function. dump_stack() is the one
that generates the above dump. So, not useful. Assuming that the driver
core at the Kernel is ok (with is usually a good assumption), we can
exclude __warn() and module_put(), warn_slowpath_null() and other similar
functions, focusing on the ones inside gp8psk module.

> When I go into
> gdb I see:
> 
> gdb $(find /lib/modules/$(uname -r) -name dvb-usb-gp8psk.ko)
> ...
> Reading symbols from
> /lib/modules/4.8.4-build.2/kernel/drivers/media/usb/dvb-usb/dvb-usb-gp8psk.ko...(no
> debugging symbols found)...done.
> (gdb)
> 
> gdb /usr/src/linux/vmlinux
> ...
> Reading symbols from /usr/src/linux/vmlinux...done.
> (gdb)
> (gdb)
> 
> "No debugging symbols found" doesn't sound good,

Yes. Clearly, it was unable to read the symbols. Depending on the
way you built the Kernel, though, the symbols may have been
stripped at the install dirs (using the strip command). Fedora builds do
that, placing the symbols on a separate package, that can be installed in
separate (kernel-debug).

The safest way to get the symbols is by loading 
dvb-usb-gp8psk.ko from the directory where you compiled the
Kernel, instead of from /lib/modules/.



> but DEBUG is enabled:
> 
> $ grep "^CONFIG_DEBUG" /usr/src/linux/.config
> CONFIG_DEBUG_RODATA=y
> CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_DEBUG_PREEMPT=y
> CONFIG_DEBUG_BUGVERBOSE=y

Yes, you should have symbols there.

What disturbs me is why gp8psk_fe_set_frontend() is on that stack trace.
It doesn't make much sense, except if you're trying to open the frontend
while removing the module. Anyway, I added a few printks and changed
something at the dvb_frontend core to test some things.

Please test the enclosed patch. It replaces the one I sent you before.

Thanks,
Mauro

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 98edf46b22d0..a43ac8f36895 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2726,6 +2726,9 @@ 

Re: [Ksummit-discuss] Including images on Sphinx documents

[Markus Heiser]

Am 07.11.2016 um 18:01 schrieb Josh Triplett :

> On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote:
>> 2) add an Sphinx extension that would internally call ImageMagick and/or
>>  inkscape to convert the bitmap;
> 
> This seems sensible; Sphinx should directly handle the source format we
> want to use for images/diagrams.
> 
>> 3) if possible, add an extension to trick Sphinx for it to consider the 
>>  output dir as a source dir too.
> 
> Or to provide an additional source path and point that at the output
> directory.

The sphinx-build command excepts only one 'sourcedir' argument. All
reST files in this folder (and below) are parsed.

Most (all?) directives which include content like images or literalinclude
except only relative pathnames. Where *relative* means, relative to the
reST file where the directive is used. For security reasons relative 
pathnames outside 'sourcepath' are not excepted.

So I vote for :

> 1) copy (or symlink) all rst files to Documentation/output (or to the
>  build dir specified via O= directive) and generate the *.pdf there,
>  and produce those converted images via Makefile.;

Placing reST files together with the *autogenerated* (intermediate) 
content from

* image conversions,
* reST content build from MAINTAINERS,
* reST content build for ABI
* etc.

has the nice side effect, that we can get rid of all theses BUILDDIR
quirks in the Makefile.sphinx

Additional, we can write Makefile targets to build the above listed
intermediate content relative to the $PWD, which is what Linux's
Makefiles usual do (instead of quirking with a BUILDDIR).

E.g. with, we can also get rid of the 'kernel-include' directive 
and replace it, with Sphinx's common 'literaliclude' and we do not
need any extensions to include intermediate PDFs or whatever
intermediate content we might want to generate. 

IMO placing 'sourcedir' to O= is more sane since this marries the
Linux Makefile concept (relative to $PWD) with the sphinx concept
(in or below 'sourcedir').


-- Markus --


--
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] control.rst: improve the queryctrl code examples

[Hans Verkuil]

The code examples on how to enumerate controls were really long in the
tooth. Update them.

Using FLAG_NEXT_CTRL is preferred these days, so give that example first.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/v4l/control.rst 
b/Documentation/media/uapi/v4l/control.rst
index d3f1450..51112ba 100644
--- a/Documentation/media/uapi/v4l/control.rst
+++ b/Documentation/media/uapi/v4l/control.rst
@@ -312,21 +312,20 @@ more menu type controls.

 .. _enum_all_controls:

-Example: Enumerating all user controls
-==
+Example: Enumerating all controls
+=

 .. code-block:: c

-
 struct v4l2_queryctrl queryctrl;
 struct v4l2_querymenu querymenu;

-static void enumerate_menu(void)
+static void enumerate_menu(__u32 id)
 {
printf("  Menu items:\\n");

memset(, 0, sizeof(querymenu));
-   querymenu.id = queryctrl.id;
+   querymenu.id = id;

for (querymenu.index = queryctrl.minimum;
 querymenu.index <= queryctrl.maximum;
@@ -339,6 +338,55 @@ Example: Enumerating all user controls

 memset(, 0, sizeof(queryctrl));

+queryctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL;
+while (0 == ioctl(fd, VIDIOC_QUERYCTRL, )) {
+   if (!(queryctrl.flags & V4L2_CTRL_FLAG_DISABLED)) {
+   printf("Control %s\\n", queryctrl.name);
+
+   if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
+   enumerate_menu(queryctrl.id);
+}
+
+   queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
+}
+if (errno != EINVAL) {
+   perror("VIDIOC_QUERYCTRL");
+   exit(EXIT_FAILURE);
+}
+
+Example: Enumerating all controls including compound controls
+=
+
+.. code-block:: c
+
+struct v4l2_query_ext_ctrl query_ext_ctrl;
+
+memset(_ext_ctrl, 0, sizeof(query_ext_ctrl));
+
+query_ext_ctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL | 
V4L2_CTRL_FLAG_NEXT_COMPOUND;
+while (0 == ioctl(fd, VIDIOC_QUERY_EXT_CTRL, _ext_ctrl)) {
+   if (!(query_ext_ctrl.flags & V4L2_CTRL_FLAG_DISABLED)) {
+   printf("Control %s\\n", query_ext_ctrl.name);
+
+   if (query_ext_ctrl.type == V4L2_CTRL_TYPE_MENU)
+   enumerate_menu(query_ext_ctrl.id);
+}
+
+   query_ext_ctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL | 
V4L2_CTRL_FLAG_NEXT_COMPOUND;
+}
+if (errno != EINVAL) {
+   perror("VIDIOC_QUERY_EXT_CTRL");
+   exit(EXIT_FAILURE);
+}
+
+Example: Enumerating all user controls (old style)
+==
+
+.. code-block:: c
+
+
+memset(, 0, sizeof(queryctrl));
+
 for (queryctrl.id = V4L2_CID_BASE;
 queryctrl.id < V4L2_CID_LASTP1;
 queryctrl.id++) {
@@ -349,7 +397,7 @@ Example: Enumerating all user controls
printf("Control %s\\n", queryctrl.name);

if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
-   enumerate_menu();
+   enumerate_menu(queryctrl.id);
} else {
if (errno == EINVAL)
continue;
@@ -368,7 +416,7 @@ Example: Enumerating all user controls
printf("Control %s\\n", queryctrl.name);

if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
-   enumerate_menu();
+   enumerate_menu(queryctrl.id);
} else {
if (errno == EINVAL)
break;
@@ -379,32 +427,6 @@ Example: Enumerating all user controls
 }


-Example: Enumerating all user controls (alternative)
-
-
-.. code-block:: c
-
-memset(, 0, sizeof(queryctrl));
-
-queryctrl.id = V4L2_CTRL_CLASS_USER | V4L2_CTRL_FLAG_NEXT_CTRL;
-while (0 == ioctl(fd, VIDIOC_QUERYCTRL, )) {
-   if (V4L2_CTRL_ID2CLASS(queryctrl.id) != V4L2_CTRL_CLASS_USER)
-   break;
-   if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED)
-   continue;
-
-   printf("Control %s\\n", queryctrl.name);
-
-   if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
-   enumerate_menu();
-
-   queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
-}
-if (errno != EINVAL) {
-   perror("VIDIOC_QUERYCTRL");
-   exit(EXIT_FAILURE);
-}
-
 Example: Changing controls
 ==

--
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] cec-core.rst: improve documentation

[Hans Verkuil]

Improve the internal CEC documentation. In particular add a section that 
specifies that
transmit-related interrupts should be processed before receive interrupts.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/kapi/cec-core.rst 
b/Documentation/media/kapi/cec-core.rst
index 88c33b5..8a88dd4 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -106,13 +106,13 @@ your driver:
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
  u32 signal_free_time, struct cec_msg 
*msg);
-   void (\*adap_log_status)(struct cec_adapter *adap);
+   void (*adap_status)(struct cec_adapter *adap, struct seq_file 
*file);

/* High-level callbacks */
...
};

-The three low-level ops deal with various aspects of controlling the CEC 
adapter
+The five low-level ops deal with various aspects of controlling the CEC adapter
 hardware:


@@ -238,6 +238,18 @@ When a CEC message was received:

 Speaks for itself.

+Implementing the interrupt handler
+--
+
+Typically the CEC hardware provides interrupts that signal when a transmit
+finished and whether it was successful or not, and it provides and interrupt
+when a CEC message was received.
+
+The CEC driver should always process the transmit interrupts first before
+handling the receive interrupt. The framework expects to see the 
cec_transmit_done
+call before the cec_received_msg call, otherwise it can get confused if the
+received message was in reply to the transmitted message.
+
 Implementing the High-Level CEC Adapter
 ---

@@ -247,11 +259,11 @@ CEC protocol driven. The following high-level callbacks 
are available:
 .. code-block:: none

struct cec_adap_ops {
-   /\* Low-level callbacks \*/
+   /* Low-level callbacks */
...

-   /\* High-level CEC message callback \*/
-   int (\*received)(struct cec_adapter \*adap, struct cec_msg 
\*msg);
+   /* High-level CEC message callback */
+   int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
};

 The received() callback allows the driver to optionally handle a newly
@@ -263,7 +275,7 @@ received CEC message
 If the driver wants to process a CEC message, then it can implement this
 callback. If it doesn't want to handle this message, then it should return
 -ENOMSG, otherwise the CEC framework assumes it processed this message and
-it will not no anything with it.
+it will not do anything with it.


 CEC framework functions
--
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