[PATCH 1/2] media: imx319: fix wrong order in test pattern menus
From: Bingbu Cao
current imx319 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx319.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 0d3e27812b93..acd988d2d7f1 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1648,8 +1648,8 @@ struct imx319 {
static const char * const imx319_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
--
1.9.1
[PATCH 2/2] media: imx355: fix wrong order in test pattern menus
From: Bingbu Cao
current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx355.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
static const char * const imx355_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
--
1.9.1
Re: [PATCH v3.16 2/2] v4l: event: Add subscription to list before calling "add" operation
On Thu, Nov 08, 2018 at 02:03:50PM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
>
> Patch ad608fbcf166 changed how events were subscribed to address an issue
> elsewhere. As a side effect of that change, the "add" callback was called
> before the event subscription was added to the list of subscribed events,
> causing the first event queued by the add callback (and possibly other
> events arriving soon afterwards) to be lost.
>
> Fix this by adding the subscription to the list before calling the "add"
> callback, and clean up afterwards if that fails.
>
> Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions
> while accessed")
Now applied, thanks.
greg k-h
Re: [PATCH v3.16 1/2] v4l: event: Prevent freeing event subscriptions while accessed
On Thu, Nov 08, 2018 at 02:03:49PM +0200, Sakari Ailus wrote: > [ upstream commit ad608fbcf166fec809e402d548761768f602702c ] This is already in 3.18.124. thanks, greg k-h
Re: [PATCH v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation
On Thu, Nov 08, 2018 at 01:46:32PM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
>
> Patch ad608fbcf166 changed how events were subscribed to address an issue
> elsewhere. As a side effect of that change, the "add" callback was called
> before the event subscription was added to the list of subscribed events,
> causing the first event queued by the add callback (and possibly other
> events arriving soon afterwards) to be lost.
>
> Fix this by adding the subscription to the list before calling the "add"
> callback, and clean up afterwards if that fails.
>
> Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions
> while accessed")
>
> Reported-by: Dave Stevenson
> Signed-off-by: Sakari Ailus
> Tested-by: Dave Stevenson
> Reviewed-by: Hans Verkuil
> Tested-by: Hans Verkuil
> Cc: sta...@vger.kernel.org (for 4.14 and up)
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/v4l2-core/v4l2-event.c | 43
>
> 1 file changed, 24 insertions(+), 19 deletions(-)
Now applied, thanks.
greg k-h
Re: [PATCH v2 for v4.9 1/1] v4l: event: Add subscription to list before calling "add" operation
On Wed, Nov 14, 2018 at 11:37:53AM +0200, Sakari Ailus wrote:
> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
>
> Patch ad608fbcf166 changed how events were subscribed to address an issue
> elsewhere. As a side effect of that change, the "add" callback was called
> before the event subscription was added to the list of subscribed events,
> causing the first event queued by the add callback (and possibly other
> events arriving soon afterwards) to be lost.
>
> Fix this by adding the subscription to the list before calling the "add"
> callback, and clean up afterwards if that fails.
>
> Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions
> while accessed")
>
> Reported-by: Dave Stevenson
> Signed-off-by: Sakari Ailus
> Tested-by: Dave Stevenson
> Reviewed-by: Hans Verkuil
> Tested-by: Hans Verkuil
> Signed-off-by: Mauro Carvalho Chehab
> [Sakari Ailus: Backported to v4.9 stable]
> Signed-off-by: Sakari Ailus
> ---
> since v1 (as requested by Sasha):
>
> - Add my final SoB
> - Indicate specifically this is a backport
> - Remove the extra cc stable
Now queued up, thanks.
greg k-h
Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation
On Mon, Nov 26, 2018 at 08:27:59AM +0100, Greg Kroah-Hartman wrote: > On Thu, Nov 22, 2018 at 01:33:33PM +0200, Sakari Ailus wrote: > > On Tue, Nov 20, 2018 at 09:21:50AM -0200, Mauro Carvalho Chehab wrote: > > > Em Tue, 20 Nov 2018 12:49:46 +0200 > > > Sakari Ailus escreveu: > > > > > > > Hi Greg, > > > > > > > > On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote: > > > > > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote: > > > > > > Hi Greg, > > > > > > > > > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote: > > > > > > > > > > > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote: > > > > > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ] > > > > > > > > > > > > > > There is no such git commit id in Linus's tree :( > > > > > > > > > > > > Right. At the moment it's in the media tree only. I expect it'll > > > > > > end up to > > > > > > Linus's tree once Mauro will send the next pull request from the > > > > > > media tree > > > > > > to Linus. > > > > > > > > > > Ok, please do not send requests for stable tree inclusion until > > > > > _AFTER_ > > > > > the patch is in Linus's tree, otherwise it just wastes the stable tree > > > > > maintainer's time :( > > > > > > > > Apologies for the noise. I'll send you a note once the patches are in > > > > Linus's tree. > > > > > > Btw, just sent a pull request with this patch. > > > > > > I wanted to send this two weeks ago, but I had to do two trips > > > (the final one to be at KS/LPC). This ended by delaying the pull request. > > > > The patch is in Linus's tree now. > > And what is the git commit id? Nevermind, I see it...
Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation
On Thu, Nov 22, 2018 at 01:33:33PM +0200, Sakari Ailus wrote: > On Tue, Nov 20, 2018 at 09:21:50AM -0200, Mauro Carvalho Chehab wrote: > > Em Tue, 20 Nov 2018 12:49:46 +0200 > > Sakari Ailus escreveu: > > > > > Hi Greg, > > > > > > On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote: > > > > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote: > > > > > Hi Greg, > > > > > > > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote: > > > > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote: > > > > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ] > > > > > > > > > > > > There is no such git commit id in Linus's tree :( > > > > > > > > > > Right. At the moment it's in the media tree only. I expect it'll end > > > > > up to > > > > > Linus's tree once Mauro will send the next pull request from the > > > > > media tree > > > > > to Linus. > > > > > > > > Ok, please do not send requests for stable tree inclusion until _AFTER_ > > > > the patch is in Linus's tree, otherwise it just wastes the stable tree > > > > maintainer's time :( > > > > > > Apologies for the noise. I'll send you a note once the patches are in > > > Linus's tree. > > > > Btw, just sent a pull request with this patch. > > > > I wanted to send this two weeks ago, but I had to do two trips > > (the final one to be at KS/LPC). This ended by delaying the pull request. > > The patch is in Linus's tree now. And what is the git commit id? thanks, gre k-h
cron job: media_tree daily build: ERRORS
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: Mon Nov 26 05:00:10 CET 2018 media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0 media_build git hash: a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1 v4l-utils git hash: cdc046863805b3a3082890ce91f71538e0dbf88c edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: OK linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.74-i686: ERRORS linux-4.14.74-x86_64: ERRORS linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH] v4l2-ioctl: Zero v4l2_pix_format_mplane reserved fields
Hi Ezequiel,
On Sat, Nov 24, 2018 at 2:20 AM Ezequiel Garcia wrote:
>
> Make the core set the reserved fields to zero in
> v4l2_pix_format_mplane and v4l2_plane_pix_format structs,
> for _MPLANE queue types.
>
> Moving this to the core avoids having to do so in each
> and every driver.
>
> Suggested-by: Tomasz Figa
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 51
> 1 file changed, 45 insertions(+), 6 deletions(-)
>
Thanks for the patch. Please see my comments inline.
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 10b862dcbd86..3858fffc3e68 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1420,6 +1420,7 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
> {
> struct v4l2_format *p = arg;
> int ret = check_fmt(file, p->type);
> + int i;
>
> if (ret)
> return ret;
> @@ -1458,7 +1459,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
> p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> return ret;
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - return ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> + ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> + memset(p->fmt.pix_mp.reserved, 0,
> + sizeof(p->fmt.pix_mp.reserved));
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> + sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> + return ret;
> case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> return ops->vidioc_g_fmt_vid_overlay(file, fh, arg);
> case V4L2_BUF_TYPE_VBI_CAPTURE:
> @@ -1474,7 +1481,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
> p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> return ret;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - return ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> + ret = ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> + memset(p->fmt.pix_mp.reserved, 0,
> + sizeof(p->fmt.pix_mp.reserved));
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> + sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> + return ret;
I wonder if we need this for G_FMT. The driver can just memset() the
whole struct itself and then just initialize the fields it cares
about, but actually in many cases the driver will just include an
instance of the pix_fmt(_mp) struct in its internal state (which has
the reserved fields already zeroed) and just copy it to the target
struct in the callback.
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
> return ops->vidioc_g_fmt_vid_out_overlay(file, fh, arg);
> case V4L2_BUF_TYPE_VBI_OUTPUT:
> @@ -1512,6 +1525,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> struct v4l2_format *p = arg;
> struct video_device *vfd = video_devdata(file);
> int ret = check_fmt(file, p->type);
> + int i;
>
> if (ret)
> return ret;
> @@ -1536,7 +1550,13 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> - return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
> + ret = ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
> + memset(p->fmt.pix_mp.reserved, 0,
> + sizeof(p->fmt.pix_mp.reserved));
Note that we're already zeroing this field before calling driver's callback.
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> + sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
Should we use the CLEAR_AFTER_FIELD() macro? Also, should we do before
calling the driver, as with pix_mp.reserved?
> + return ret;
> case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
> break;
> @@ -1564,7 +1584,13 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> - return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
> + ret = ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
> + memset(p->fmt.pix_mp.reserved, 0,
> +
[PATCH] media: saa7134: rc-core maintains users count, no need to duplicate
This simplifies the code a little. Tested with suspend and resume.
Signed-off-by: Sean Young
---
drivers/media/pci/saa7134/saa7134-core.c | 8 +--
drivers/media/pci/saa7134/saa7134-input.c | 68 ---
drivers/media/pci/saa7134/saa7134.h | 9 ++-
3 files changed, 18 insertions(+), 67 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers/media/pci/saa7134/saa7134-core.c
index 8984b1bf57a5..aa98ea49558c 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -1419,8 +1419,8 @@ static int saa7134_suspend(struct pci_dev *pci_dev ,
pm_message_t state)
del_timer(>vbi_q.timeout);
del_timer(>ts_q.timeout);
- if (dev->remote)
- saa7134_ir_stop(dev);
+ if (dev->remote && dev->remote->dev->users)
+ saa7134_ir_close(dev->remote->dev);
pci_save_state(pci_dev);
pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
@@ -1447,8 +1447,8 @@ static int saa7134_resume(struct pci_dev *pci_dev)
saa7134_videoport_init(dev);
if (card_has_mpeg(dev))
saa7134_ts_init_hw(dev);
- if (dev->remote)
- saa7134_ir_start(dev);
+ if (dev->remote && dev->remote->dev->users)
+ saa7134_ir_open(dev->remote->dev);
saa7134_hw_enable1(dev);
msleep(100);
diff --git a/drivers/media/pci/saa7134/saa7134-input.c
b/drivers/media/pci/saa7134/saa7134-input.c
index bc1ed7798d21..35884d5b8337 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -448,17 +448,10 @@ static void saa7134_input_timer(struct timer_list *t)
mod_timer(>timer, jiffies + msecs_to_jiffies(ir->polling));
}
-static int __saa7134_ir_start(void *priv)
+int saa7134_ir_open(struct rc_dev *rc)
{
- struct saa7134_dev *dev = priv;
- struct saa7134_card_ir *ir;
-
- if (!dev || !dev->remote)
- return -EINVAL;
-
- ir = dev->remote;
- if (ir->running)
- return 0;
+ struct saa7134_dev *dev = rc->priv;
+ struct saa7134_card_ir *ir = dev->remote;
/* Moved here from saa7134_input_init1() because the latter
* is not called on device resume */
@@ -507,55 +500,15 @@ static int __saa7134_ir_start(void *priv)
return 0;
}
-static void __saa7134_ir_stop(void *priv)
+void saa7134_ir_close(struct rc_dev *rc)
{
- struct saa7134_dev *dev = priv;
- struct saa7134_card_ir *ir;
-
- if (!dev || !dev->remote)
- return;
-
- ir = dev->remote;
- if (!ir->running)
- return;
+ struct saa7134_dev *dev = rc->priv;
+ struct saa7134_card_ir *ir = dev->remote;
if (ir->polling)
del_timer_sync(>timer);
ir->running = false;
-
- return;
-}
-
-int saa7134_ir_start(struct saa7134_dev *dev)
-{
- if (dev->remote->users)
- return __saa7134_ir_start(dev);
-
- return 0;
-}
-
-void saa7134_ir_stop(struct saa7134_dev *dev)
-{
- if (dev->remote->users)
- __saa7134_ir_stop(dev);
-}
-
-static int saa7134_ir_open(struct rc_dev *rc)
-{
- struct saa7134_dev *dev = rc->priv;
-
- dev->remote->users++;
- return __saa7134_ir_start(dev);
-}
-
-static void saa7134_ir_close(struct rc_dev *rc)
-{
- struct saa7134_dev *dev = rc->priv;
-
- dev->remote->users--;
- if (!dev->remote->users)
- __saa7134_ir_stop(dev);
}
int saa7134_input_init1(struct saa7134_dev *dev)
@@ -624,7 +577,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
mask_keycode = 0x0007C8;
mask_keydown = 0x10;
polling = 50; // ms
- /* GPIO stuff moved to __saa7134_ir_start() */
+ /* GPIO stuff moved to saa7134_ir_open() */
break;
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A;
@@ -646,14 +599,14 @@ int saa7134_input_init1(struct saa7134_dev *dev)
mask_keycode = 0x02F200;
mask_keydown = 0x000400;
polling = 50; // ms
- /* GPIO stuff moved to __saa7134_ir_start() */
+ /* GPIO stuff moved to saa7134_ir_open() */
break;
case SAA7134_BOARD_AVERMEDIA_A16D:
ir_codes = RC_MAP_AVERMEDIA_A16D;
mask_keycode = 0x02F200;
mask_keydown = 0x000400;
polling = 50; /* ms */
- /* GPIO stuff moved to __saa7134_ir_start() */
+ /* GPIO stuff moved to saa7134_ir_open() */
break;
case SAA7134_BOARD_KWORLD_TERMINATOR:
ir_codes = RC_MAP_PIXELVIEW;
@@ -705,7 +658,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
mask_keycode = 0x0003CC;
cx23885 crash when 2 or more OTA PCIE tuners installed
Hi. I found your email in dmesg for bug reports. I’m using Hauppauge quadHD PCIE tuner, recently bought a second one and I’ve installed them in the same PC, running Ubuntu 18. After 5-10 minutes, PC became slow and I have found a flooding messages in sysclog, indicating a driver from “mediatree” crashed. If I take out one tuner, it’s stable. Can’t work with 2 or more. I’ve reached out to Hauppauge, but they say that it’s not their responsibility and I have to let the developer know. Please fix it. Thank you. Victor. Nov 24 17:41:02 tvbuntu kernel: [4.10] WARNING: You are using an experimental version of the media stack. Nov 24 17:41:02 tvbuntu kernel: [4.10] As the driver is backported to an older kernel, it doesn't offer Nov 24 17:41:02 tvbuntu kernel: [4.10] enough quality for its usage in production. Nov 24 17:41:02 tvbuntu kernel: [4.10] Use it with care. Nov 24 17:41:02 tvbuntu kernel: [4.10] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): Nov 24 17:41:02 tvbuntu kernel: [4.10] 3c4a737267e89aafa6308c6c456d2ebea3fcd085 media: ov5640: fix frame interval enumeration Nov 24 17:41:02 tvbuntu kernel: [4.10] 2bbc46e811f0d40ed92ff9c104fce6618049f726 media: v4l-common: Make v4l2_find_nearest_size more sparse-friendly Nov 24 17:41:02 tvbuntu kernel: [4.10] 41cb1c739dcddf9905a5a3e3da9429b89cd5c616 media: ov5640: adjust xclk_max Nov 24 17:41:02 tvbuntu kernel: [5.032595] rndis_host 2-1.4:1.0 enx000dfe7e332b: renamed from eth1 Nov 24 17:41:02 tvbuntu kernel: [5.040854] cx23885: cx23885 driver version 0.0.4 loaded Nov 24 17:41:02 tvbuntu kernel: [5.040978] cx23885: CORE cx23885[0]: subsystem: 0070:6a18, board: Hauppauge WinTV-QuadHD-ATSC [card=57,autodetected] Nov 24 17:41:02 tvbuntu kernel: [5.148258] rndis_host 2-1.5:1.0 enx000dfe7e3315: renamed from eth2 Nov 24 17:41:02 tvbuntu kernel: [5.180294] rndis_host 2-1.3:1.0 enx000dfe7e3173: renamed from eth0 Nov 24 17:41:02 tvbuntu kernel: [5.386530] tveeprom: Hauppauge model 165100, rev B4I6, serial# 4036040101 Nov 24 17:41:02 tvbuntu kernel: [5.386531] tveeprom: MAC address is 00:0d:fe:91:15:a5 Nov 24 17:41:02 tvbuntu kernel: [5.386532] tveeprom: tuner model is SiLabs Si2157 (idx 186, type 4) Nov 24 17:41:02 tvbuntu kernel: [5.386533] tveeprom: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) Nov 24 17:41:02 tvbuntu kernel: [5.386533] tveeprom: audio processor is CX23888 (idx 40) Nov 24 17:41:02 tvbuntu kernel: [5.386534] tveeprom: decoder processor is CX23888 (idx 34) Nov 24 17:41:02 tvbuntu kernel: [5.386535] tveeprom: has no radio, has IR receiver, has no IR transmitter Nov 24 17:41:02 tvbuntu kernel: [5.386535] cx23885: cx23885[0]: hauppauge eeprom: model=165100 Nov 24 17:41:02 tvbuntu kernel: [5.402647] cx25840 9-0044: cx23888 A/V decoder found @ 0x88 (cx23885[0]) Nov 24 17:41:02 tvbuntu kernel: [6.090478] cx25840 9-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) Nov 24 17:41:02 tvbuntu kernel: [6.181943] cx23885: cx23885[0]: registered device video0 [v4l2] Nov 24 17:41:02 tvbuntu kernel: [6.181980] cx23885: cx23885[0]: registered device vbi0 Nov 24 17:41:02 tvbuntu kernel: [6.182063] cx23885: cx23885[0]: alsa: registered ALSA audio device Nov 24 17:41:02 tvbuntu kernel: [6.182065] cx23885: cx23885_dvb_register() allocating 1 frontend(s) Nov 24 17:41:02 tvbuntu kernel: [6.182066] cx23885: cx23885[0]: cx23885 based dvb card Nov 24 17:41:02 tvbuntu kernel: [6.182067] cx23885: dvb_register(): board=57 port=1 Nov 24 17:41:03 tvbuntu kernel: [6.433222] cx23885: dvb_register(): QUADHD_ATSC analog setup Nov 24 17:41:03 tvbuntu kernel: [6.433224] dvbdev: DVB: registering new adapter (cx23885[0]) Nov 24 17:41:03 tvbuntu kernel: [6.433226] cx23885 :03:00.0: DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3306A VSB/QAM Frontend)... Nov 24 17:41:03 tvbuntu kernel: [6.433441] cx23885: cx23885_dvb_register() allocating 1 frontend(s) Nov 24 17:41:03 tvbuntu kernel: [6.433442] cx23885: cx23885[0]: cx23885 based dvb card Nov 24 17:41:03 tvbuntu kernel: [6.433443] cx23885: dvb_register(): board=57 port=2 Nov 24 17:41:03 tvbuntu kernel: [6.440395] si2157 8-0062: Silicon Labs Si2147/2148/2157/2158 successfully attached Nov 24 17:41:03 tvbuntu kernel: [6.440408] dvbdev: DVB: registering new adapter (cx23885[0]) Nov 24 17:41:03 tvbuntu kernel: [6.440410] cx23885 :03:00.0: DVB: registering adapter 1 frontend 0 (LG Electronics LGDT3306A VSB/QAM Frontend)... Nov 24 17:41:03 tvbuntu kernel: [6.440626] cx23885: cx23885_dev_checkrevision() Hardware revision = 0xd0 Nov 24 17:41:03 tvbuntu kernel: [6.440631] cx23885: cx23885[0]/0: found at :03:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xe160 Nov 24 17:41:03 tvbuntu kernel: [6.440760] cx23885: CORE cx23885[1]:
Re: [PATCH v3] media: video-i2c: check if chip struct has set_power function
Hi Matt,
On Sat, Nov 24, 2018 at 02:03:23PM -0800, Matt Ranostay wrote:
> Not all future supported video chips will always have power management
> support, and so it is important to check before calling set_power() is
> defined.
>
> Cc: Sakari Ailus
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Cc: Akinobu Mita
> Signed-off-by: Matt Ranostay
> ---
>
> Changes from v2:
> - split out from mlx90640 patch series
> - added to Cc list
>
> Changes from v1:
> - none
>
> drivers/media/i2c/video-i2c.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index b6ebb8d53e90..01dcf179f203 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -736,9 +736,11 @@ static int video_i2c_probe(struct i2c_client *client,
> video_set_drvdata(>vdev, data);
> i2c_set_clientdata(client, data);
>
> - ret = data->chip->set_power(data, true);
> - if (ret)
> - goto error_unregister_device;
> + if (data->chip->set_power) {
> + ret = data->chip->set_power(data, true);
> + if (ret)
> + goto error_unregister_device;
> + }
How about adding a macro to call the op if it's set? It could be used to
call other ops when they're set, and ignore them when they're not. Just an
idea. See e.g. v4l2_subdev_call() in include/media/v4l2-subdev.h .
>
> pm_runtime_get_noresume(>dev);
> pm_runtime_set_active(>dev);
> @@ -767,7 +769,9 @@ static int video_i2c_probe(struct i2c_client *client,
> pm_runtime_disable(>dev);
> pm_runtime_set_suspended(>dev);
> pm_runtime_put_noidle(>dev);
> - data->chip->set_power(data, false);
> +
> + if (data->chip->set_power)
> + data->chip->set_power(data, false);
>
> error_unregister_device:
> v4l2_device_unregister(v4l2_dev);
> @@ -791,7 +795,9 @@ static int video_i2c_remove(struct i2c_client *client)
> pm_runtime_disable(>dev);
> pm_runtime_set_suspended(>dev);
> pm_runtime_put_noidle(>dev);
> - data->chip->set_power(data, false);
> +
> + if (data->chip->set_power)
> + data->chip->set_power(data, false);
>
> video_unregister_device(>vdev);
>
> @@ -804,6 +810,9 @@ static int video_i2c_pm_runtime_suspend(struct device
> *dev)
> {
> struct video_i2c_data *data = i2c_get_clientdata(to_i2c_client(dev));
>
> + if (!data->chip->set_power)
> + return 0;
> +
> return data->chip->set_power(data, false);
> }
>
> @@ -811,6 +820,9 @@ static int video_i2c_pm_runtime_resume(struct device *dev)
> {
> struct video_i2c_data *data = i2c_get_clientdata(to_i2c_client(dev));
>
> + if (!data->chip->set_power)
> + return 0;
> +
> return data->chip->set_power(data, true);
> }
>
> --
> 2.17.1
>
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH v3] media: video-i2c: check if chip struct has set_power function
2018年11月25日(日) 7:03 Matt Ranostay : > > Not all future supported video chips will always have power management > support, and so it is important to check before calling set_power() is > defined. > > Cc: Sakari Ailus > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab > Cc: Akinobu Mita > Signed-off-by: Matt Ranostay Looks good. Reviewed-by: Akinobu Mita
