[PATCH 0/8] Fix sparse warnings/error
Another round of sparse fixes. After this there are two drivers that still have a lot of warnings: cx88 (caused by a sparse bug, I've reported this on the sparse mailinglist) and saa7164. 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
[PATCH 1/8] bttv: fix sparse warning
From: Hans Verkuil
bttv-cards.c:3874:55: warning: incorrect type in initializer (different base
types)
Also clean up the code a little by adding spaces.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/bt8xx/bttv-cards.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c
b/drivers/media/pci/bt8xx/bttv-cards.c
index d8ec583..4105560 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -3870,10 +3870,10 @@ static void osprey_eeprom(struct bttv *btv, const u8
ee[256])
} else {
unsigned short type;
- for (i = 4*16; i < 8*16; i += 16) {
- u16 checksum = ip_compute_csum(ee + i, 16);
+ for (i = 4 * 16; i < 8 * 16; i += 16) {
+ u16 checksum = (__force u16)ip_compute_csum(ee + i, 16);
- if ((checksum&0xff) + (checksum>>8) == 0xff)
+ if ((checksum & 0xff) + (checksum >> 8) == 0xff)
break;
}
if (i >= 8*16)
--
2.1.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/8] sp2: fix sparse warnings
From: Hans Verkuil
sp2.c:272:5: warning: symbol 'sp2_init' was not declared. Should it be static?
sp2.c:354:5: warning: symbol 'sp2_exit' was not declared. Should it be static?
Signed-off-by: Hans Verkuil
---
drivers/media/dvb-frontends/sp2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/sp2.c
b/drivers/media/dvb-frontends/sp2.c
index 320cbe9..cc1ef96 100644
--- a/drivers/media/dvb-frontends/sp2.c
+++ b/drivers/media/dvb-frontends/sp2.c
@@ -269,7 +269,7 @@ int sp2_ci_poll_slot_status(struct dvb_ca_en50221 *en50221,
return s->status;
}
-int sp2_init(struct sp2 *s)
+static int sp2_init(struct sp2 *s)
{
int ret = 0;
u8 buf;
@@ -351,7 +351,7 @@ err:
return ret;
}
-int sp2_exit(struct i2c_client *client)
+static int sp2_exit(struct i2c_client *client)
{
struct sp2 *s;
--
2.1.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/8] videobuf: fix sparse warnings
From: Hans Verkuil
videobuf-core.c:834:23: warning: Using plain integer as NULL pointer
videobuf-core.c:851:28: warning: Using plain integer as NULL pointer
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf-core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-core.c
b/drivers/media/v4l2-core/videobuf-core.c
index b91a266..926836d 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -51,6 +51,8 @@ MODULE_LICENSE("GPL");
#define CALL(q, f, arg...) \
((q->int_ops->f) ? q->int_ops->f(arg) : 0)
+#define CALLPTR(q, f, arg...) \
+ ((q->int_ops->f) ? q->int_ops->f(arg) : NULL)
struct videobuf_buffer *videobuf_alloc_vb(struct videobuf_queue *q)
{
@@ -831,7 +833,7 @@ static int __videobuf_copy_to_user(struct videobuf_queue *q,
char __user *data, size_t count,
int nonblocking)
{
- void *vaddr = CALL(q, vaddr, buf);
+ void *vaddr = CALLPTR(q, vaddr, buf);
/* copy to userspace */
if (count > buf->size - q->read_off)
@@ -848,7 +850,7 @@ static int __videobuf_copy_stream(struct videobuf_queue *q,
char __user *data, size_t count, size_t pos,
int vbihack, int nonblocking)
{
- unsigned int *fc = CALL(q, vaddr, buf);
+ unsigned int *fc = CALLPTR(q, vaddr, buf);
if (vbihack) {
/* dirty, undocumented hack -- pass the frame counter
--
2.1.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 5/8] stk1160: fix sparse warning
From: Hans Verkuil stk1160-v4l.c:478:49: warning: incorrect type in argument 3 (different base types) Signed-off-by: Hans Verkuil --- drivers/media/usb/stk1160/stk1160-v4l.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c b/drivers/media/usb/stk1160/stk1160-v4l.c index 2330543..a476291 100644 --- a/drivers/media/usb/stk1160/stk1160-v4l.c +++ b/drivers/media/usb/stk1160/stk1160-v4l.c @@ -475,7 +475,7 @@ static int vidioc_s_register(struct file *file, void *priv, struct stk1160 *dev = video_drvdata(file); /* Match host */ - return stk1160_write_reg(dev, reg->reg, cpu_to_le16(reg->val)); + return stk1160_write_reg(dev, reg->reg, reg->val); } #endif -- 2.1.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 7/8] s5p-mfc: fix sparse error
From: Hans Verkuil
s5p_mfc_enc.c:1178:25: error: incompatible types in conditional expression
(different base types)
Signed-off-by: Hans Verkuil
Cc: Kamil Debski
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 9391b8e..e7240cb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1175,7 +1175,7 @@ static int vidioc_reqbufs(struct file *file, void *priv,
if (reqbufs->count == 0) {
mfc_debug(2, "Freeing buffers\n");
ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
- s5p_mfc_hw_call(dev->mfc_ops, release_codec_buffers,
+ s5p_mfc_hw_call_void(dev->mfc_ops,
release_codec_buffers,
ctx);
ctx->output_state = QUEUE_FREE;
return ret;
--
2.1.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 6/8] cxusb: fix sparse warnings
From: Hans Verkuil
cxusb.c:1443:32: warning: restricted __le16 degrades to integer
cxusb.c:1487:32: warning: restricted __le16 degrades to integer
Signed-off-by: Hans Verkuil
---
drivers/media/usb/dvb-usb/cxusb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index 8925b3946..b46f84d 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1440,7 +1440,7 @@ static int cxusb_tt_ct2_4400_attach(struct
dvb_usb_adapter *adap)
si2168_config.ts_mode = SI2168_TS_PARALLEL;
/* CT2-4400v2 TS gets corrupted without this */
- if (d->udev->descriptor.idProduct ==
+ if (le16_to_cpu(d->udev->descriptor.idProduct) ==
USB_PID_TECHNOTREND_TVSTICK_CT2_4400)
si2168_config.ts_mode |= 0x40;
@@ -1484,7 +1484,7 @@ static int cxusb_tt_ct2_4400_attach(struct
dvb_usb_adapter *adap)
st->i2c_client_tuner = client_tuner;
/* initialize CI */
- if (d->udev->descriptor.idProduct ==
+ if (le16_to_cpu(d->udev->descriptor.idProduct) ==
USB_PID_TECHNOTREND_CONNECT_CT2_4650_CI) {
memcpy(o, "\xc0\x01", 2);
--
2.1.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/8] smipcie: fix sparse warnings
From: Hans Verkuil smipcie.c:950:31: warning: Using plain integer as NULL pointer smipcie.c:973:31: warning: Using plain integer as NULL pointer Signed-off-by: Hans Verkuil --- drivers/media/pci/smipcie/smipcie.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/pci/smipcie/smipcie.c b/drivers/media/pci/smipcie/smipcie.c index d1c1463..8dc6afa 100644 --- a/drivers/media/pci/smipcie/smipcie.c +++ b/drivers/media/pci/smipcie/smipcie.c @@ -947,7 +947,7 @@ err_del_i2c_adaptor: err_pci_iounmap: iounmap(dev->lmmio); err_kfree: - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); kfree(dev); err_pci_disable_device: pci_disable_device(pdev); @@ -970,7 +970,7 @@ static void smi_remove(struct pci_dev *pdev) smi_i2c_exit(dev); iounmap(dev->lmmio); - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); pci_disable_device(pdev); kfree(dev); } -- 2.1.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 8/8] ti-vpe: fix sparse warnings
From: Hans Verkuil
sc.c:303:26: warning: incorrect type in return expression (different address
spaces)
csc.c:188:27: warning: incorrect type in return expression (different address
spaces)
Signed-off-by: Hans Verkuil
---
drivers/media/platform/ti-vpe/csc.c | 2 +-
drivers/media/platform/ti-vpe/sc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/csc.c
b/drivers/media/platform/ti-vpe/csc.c
index 44fbf41..bec6749 100644
--- a/drivers/media/platform/ti-vpe/csc.c
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -185,7 +185,7 @@ struct csc_data *csc_create(struct platform_device *pdev)
csc->base = devm_ioremap_resource(&pdev->dev, csc->res);
if (IS_ERR(csc->base)) {
dev_err(&pdev->dev, "failed to ioremap\n");
- return csc->base;
+ return ERR_CAST(csc->base);
}
return csc;
diff --git a/drivers/media/platform/ti-vpe/sc.c
b/drivers/media/platform/ti-vpe/sc.c
index 1088381..f82d1c7 100644
--- a/drivers/media/platform/ti-vpe/sc.c
+++ b/drivers/media/platform/ti-vpe/sc.c
@@ -300,7 +300,7 @@ struct sc_data *sc_create(struct platform_device *pdev)
sc->base = devm_ioremap_resource(&pdev->dev, sc->res);
if (IS_ERR(sc->base)) {
dev_err(&pdev->dev, "failed to ioremap\n");
- return sc->base;
+ return ERR_CAST(sc->base);
}
return sc;
--
2.1.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: [PATCH] staging: media: lirc: replace dev_err by pr_err
On Wed, Nov 05, 2014 at 12:57:38PM +0530, Sudip Mukherjee wrote:
> On Tue, Nov 04, 2014 at 11:48:26PM +0200, Aya Mahfouz wrote:
> > On Tue, Nov 04, 2014 at 03:06:53PM +0530, Sudip Mukherjee wrote:
> > > On Tue, Nov 04, 2014 at 02:13:19AM +0200, Aya Mahfouz wrote:
> > > > This patch replaces dev_err by pr_err since the value
> > > > of ir is NULL when the message is displayed.
> > > >
> > > > Signed-off-by: Aya Mahfouz
> > > > ---
> > > > drivers/staging/media/lirc/lirc_zilog.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> > > > b/drivers/staging/media/lirc/lirc_zilog.c
> > > > index 11a7cb1..ecdd71e 100644
> > > > --- a/drivers/staging/media/lirc/lirc_zilog.c
> > > > +++ b/drivers/staging/media/lirc/lirc_zilog.c
> > > > @@ -1633,7 +1633,7 @@ out_put_xx:
> > > > out_put_ir:
> > > > put_ir_device(ir, true);
> > > > out_no_ir:
> > > > - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed
> > > > with %d\n",
> > > > + pr_err("%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> > > hi,
> > > instead of ir->l.dev , can you please try dev_err like this :
> > >
> > > dev_err(&client->dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> > > __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> > > ret);
> > >
> >
> > Thanks Sudip. It works. Please add the Reviewed-by tag to the newer
> > patch.
> >
> i think you forgot to add cc to the list and Greg K-H in your reply.
> Greg should know that this patch is now not required, otherwise he might
> apply it to his tree.
> so just replying to your mail while adding everyone else in the cc.
>
> thanks
> sudip
>
>
Apologies Sudip and thanks again!
Kind Regards,
Aya Saif El-yazal Mahfouz
> > > thanks
> > > sudip
> > >
> >
> > Kind Regards,
> > Aya Saif El-yazal Mahfouz
> > >
> > > > __func__, tx_probe ? "Tx" : "Rx", adap->name,
> > > > adap->nr,
> > > >ret);
> > > > mutex_unlock(&ir_devices_lock);
> > > > --
> > > > 1.9.3
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > > > in
> > > > the body of a message to majord...@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at http://www.tux.org/lkml/
--
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 4/8] sp2: fix sparse warnings
Em Wed, 5 Nov 2014 09:17:48 +0100
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> sp2.c:272:5: warning: symbol 'sp2_init' was not declared. Should it be static?
> sp2.c:354:5: warning: symbol 'sp2_exit' was not declared. Should it be static?
This one was fixed already (at fixes branch).
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/dvb-frontends/sp2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/sp2.c
> b/drivers/media/dvb-frontends/sp2.c
> index 320cbe9..cc1ef96 100644
> --- a/drivers/media/dvb-frontends/sp2.c
> +++ b/drivers/media/dvb-frontends/sp2.c
> @@ -269,7 +269,7 @@ int sp2_ci_poll_slot_status(struct dvb_ca_en50221
> *en50221,
> return s->status;
> }
>
> -int sp2_init(struct sp2 *s)
> +static int sp2_init(struct sp2 *s)
> {
> int ret = 0;
> u8 buf;
> @@ -351,7 +351,7 @@ err:
> return ret;
> }
>
> -int sp2_exit(struct i2c_client *client)
> +static int sp2_exit(struct i2c_client *client)
> {
> struct sp2 *s;
>
--
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/3] TBS USB drivers (DVB-S/S2) - basic driver
Hi Andreas, (c/c the others that are listed as the authors of the TBS driver) Em Wed, 26 Mar 2014 21:32:46 +0100 Andreas Steinmetz escreveu: > [Please CC me on replies, I'm not subscribed] > > The patch adds a driver for TBS USB DVB-S/S2 devices for which complete > GPLv2 code exists. Code was taken from: > > http://www.tbsdtv.com/download/ > https://bitbucket.org/CrazyCat/linux-tbs-drivers/ > https://bitbucket.org/updatelee/v4l-updatelee We have already a driver for the chipsets used on this driver. So, instead of adding a new driver, you should work on adding support on the existing ones. > > Supported devices: > -- > > TBS5980 - complete open source by manufacturer, current device > TBS5928 - complete open source by manufacturer, old device > TBS5920 - complete open source by manufacturer, old device > TBS5910 - complete open source by manufacturer, old device > TBS5925 - open source by manufacturer except 13V/18V control, > voltage switching of TBS5980 however works, > current device > TBS5921 - open source from CrazyCat's bitbucket repository, > old device > > Unsupported devices: > > > TBS5922 - mostly closed source, current device > TBS5990 - mostly closed source, current device > TBS with USB PID 0x2601 - very old device for which the actual > hardware used couldn't be determined. > > General: > > > I do not have any manufacturer relationship. I'm just a user of TBS5980 > and TBS5925 which work quite well as far as the hardware is concerned. > > I'm sufficiently annoyed, however, by the manufacturer's driver build > system which actually is an old v4l tree replacing the kernel's current > v4l tree. Thus I have reworked all available open source code for the > TBS USB DVB-S/S2 hardware into a combined driver that is working with > the current kernel. > > Testing: > > > TBS5925 gets used daily and is working fine. > TBS5980 gets used daily minus an actual CAM and is working fine without > a CAM. > > The old devices can't be tested by me, I don't own them and they are not > sold anymore. > > Maintenance: > > > As a TBS5925/TBS5980 user I'm willing to maintain the driver as far as > this is possible (see below). > > Regarding the older devices I'm willing to fix bugs for owners of these > devices as long as I did introduce them in my combined driver. > > What I cannot do for any device is to fix any problems that would > require manufacturer support or manufacturer documentation. > > As the TBS5980 manufacturer sources on which this driver is based didn't > change for more than one and a half years (since when I started to > collect manufacturer source archives) I'm quite confident that not much > maintenance will be necessary. > > Firmware: > - > > All required firmware except for the TBS5921 is available at > http://www.tbsdtv.com/download/ (manufacturer website). The tda10071 > firmware required additionally for the TBS5921 is already supported by > the get_dvb_firmware script of the kernel. > > Due to the way the manufacturer handles software distribution I can't > include the TBS firmware in the get_dvb_firmware script (no archive url, > archive files updated every few months under a different file name). > > Notes: > -- > > The ifdefs in the driver will go away by a followup patch after a > necessary patch to some frontends. > > Please go on easy with me. I'm usually not writing kernel drivers. And > I'm neither young nor healthy enough for flame wars. -- 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: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi, 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > Sakari Ailus wrote: >> yavta does, for example, print both the monotonic timestamp from the buffer >> and the time when the buffer has been dequeued: >> >> http://git.ideasonboard.org/yavta.git> >> >> $ yavta -c /dev/video0 >> >> should do it. The first timestamp is the buffer timestamp, and the latter is >> the one is taken when the buffer is dequeued (by yavta). I've done exaclty this with guvcview, and uvcvideo timestamps are completly unreliable, in some devices they may have just a bit of jitter, but in others, values go back and forth in time, making them totally unusable. Honestly I wouldn't trust device firmware to provide correct timestamps, or at least I would have the driver perform a couple of tests to make sure these are at least reasonable: within an expected interval (maybe comparing it to a reference monotonic clock) or at the very least making sure the current frame timestamp is not lower than the previous one. Regards, Paulo > > Removing the uvcvideo module and loading it again with trace=4096 before > capturing, and then kernel log would provide more useful information. > > -- > Sakari Ailus > sakari.ai...@iki.fi -- 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] staging: media: lirc: replace dev_err by pr_err
Em Tue, 4 Nov 2014 02:13:19 +0200
Aya Mahfouz escreveu:
> This patch replaces dev_err by pr_err since the value
> of ir is NULL when the message is displayed.
This one doesn't apply at the media tree:
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 1ccf6262ab36..babd6470f246 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -1636,7 +1636,11 @@ out_put_xx:
out_put_ir:
put_ir_device(ir, true);
out_no_ir:
+<<<
zilog_error("%s: probing IR %s on %s (i2c-%d) failed with %d\n",
+===
+ pr_err("%s: probing IR %s on %s (i2c-%d) failed with %d\n",
+>>>
__func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
ret);
mutex_unlock(&ir_devices_lock);
Perhaps it depends on some patch merged via Greg's tree?
Regards,
Mauro
>
> Signed-off-by: Aya Mahfouz
> ---
> drivers/staging/media/lirc/lirc_zilog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 11a7cb1..ecdd71e 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -1633,7 +1633,7 @@ out_put_xx:
> out_put_ir:
> put_ir_device(ir, true);
> out_no_ir:
> - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> + pr_err("%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> ret);
> mutex_unlock(&ir_devices_lock);
--
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] staging: media: lirc: modify print calls
Em Tue, 4 Nov 2014 23:43:07 +0200
Aya Mahfouz escreveu:
> This patches replaces one pr_debug call by dev_dbg and
> changes the device used by one of the dev_err calls.
Also doesn't apply. Probably made to apply on Greg's tree.
Regards,
Mauro
>
> Signed-off-by: Aya Mahfouz
> ---
> drivers/staging/media/lirc/lirc_zilog.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 52f8e91..dca806a 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -1447,7 +1447,7 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> int ret;
> bool tx_probe = false;
>
> - pr_debug("%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> + dev_dbg(&client->dev, "%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> __func__, id->name, adap->nr, adap->name, client->addr);
>
> /*
> @@ -1631,7 +1631,7 @@ out_put_xx:
> out_put_ir:
> put_ir_device(ir, true);
> out_no_ir:
> - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> + dev_err(&client->dev, "%s: probing IR %s on %s (i2c-%d) failed with
> %d\n",
> __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> ret);
> mutex_unlock(&ir_devices_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mem2mem changes
The following changes since commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b: [media] media/rc: Send sync space information on the lirc device (2014-11-04 20:41:42 -0200) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-3.19-2 for you to fetch changes up to 9a130b69b89ea646bcd44d415e286eaf899bc573: s5p-mfc: fix sparse error (2014-11-05 11:09:25 +0100) Hans Verkuil (1): s5p-mfc: fix sparse error Rasmus Villemoes (1): s5p_mfc: Remove redundant casts drivers/media/platform/s5p-mfc/s5p_mfc.c |4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.19] Sparse warning fixes
The following changes since commit 4895cc47a072dcb32d3300d0a46a251a8c6db5f1: [media] s5p-mfc: fix sparse error (2014-11-05 08:29:27 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git sparse for you to fetch changes up to acccdfd5898bfc3047febd3275015796874c760c: ti-vpe: fix sparse warnings (2014-11-05 11:32:58 +0100) Hans Verkuil (6): bttv: fix sparse warning videobuf: fix sparse warnings smipcie: fix sparse warnings stk1160: fix sparse warning cxusb: fix sparse warnings ti-vpe: fix sparse warnings drivers/media/pci/bt8xx/bttv-cards.c| 6 +++--- drivers/media/pci/smipcie/smipcie.c | 4 ++-- drivers/media/platform/ti-vpe/csc.c | 2 +- drivers/media/platform/ti-vpe/sc.c | 2 +- drivers/media/usb/dvb-usb/cxusb.c | 4 ++-- drivers/media/usb/stk1160/stk1160-v4l.c | 2 +- drivers/media/v4l2-core/videobuf-core.c | 6 -- 7 files changed, 14 insertions(+), 12 deletions(-) -- 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] stv090x: Fix delivery system setting
As sparse complains:
drivers/media/dvb-frontends/stv090x.c:3471:30: warning: mixing
different enum types
drivers/media/dvb-frontends/stv090x.c:3471:30: int enum
fe_delivery_system versus
drivers/media/dvb-frontends/stv090x.c:3471:30: int enum
stv090x_delsys
There's actually an error when setting the delivery system on
stv090x_search(): it is using the DVBv5 macros as if they were
the stv090x ones.
Instead, we should convert between the two namespaces, returning
an error if an unsupported delivery system is requested.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-frontends/stv090x.c
b/drivers/media/dvb-frontends/stv090x.c
index 93f4979ea6e9..f8050b984a8f 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -3468,7 +3468,20 @@ static enum dvbfe_search stv090x_search(struct
dvb_frontend *fe)
if (props->frequency == 0)
return DVBFE_ALGO_SEARCH_INVALID;
- state->delsys = props->delivery_system;
+ switch (props->delivery_system) {
+ case SYS_DSS:
+ state->delsys = STV090x_DSS;
+ break;
+ case SYS_DVBS:
+ state->delsys = STV090x_DVBS1;
+ break;
+ case SYS_DVBS2:
+ state->delsys = STV090x_DVBS2;
+ break;
+ default:
+ return DVBFE_ALGO_SEARCH_INVALID;
+ }
+
state->frequency = props->frequency;
state->srate = props->symbol_rate;
state->search_mode = STV090x_SEARCH_AUTO;
--
1.9.3
--
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] staging: media: lirc: modify print calls
On Tue, Nov 04, 2014 at 11:43:07PM +0200, Aya Mahfouz wrote:
> This patches replaces one pr_debug call by dev_dbg and
> changes the device used by one of the dev_err calls.
i think you should mention in the commit message why you are changing the
device.
and also for revised patch its better if you add version number in the subject.
like this is v2.
thanks
sudip
>
> Signed-off-by: Aya Mahfouz
> ---
> drivers/staging/media/lirc/lirc_zilog.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 52f8e91..dca806a 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -1447,7 +1447,7 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> int ret;
> bool tx_probe = false;
>
> - pr_debug("%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> + dev_dbg(&client->dev, "%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> __func__, id->name, adap->nr, adap->name, client->addr);
>
> /*
> @@ -1631,7 +1631,7 @@ out_put_xx:
> out_put_ir:
> put_ir_device(ir, true);
> out_no_ir:
> - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> + dev_err(&client->dev, "%s: probing IR %s on %s (i2c-%d) failed with
> %d\n",
> __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> ret);
> mutex_unlock(&ir_devices_lock);
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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] cx24110: Simplify error handling at cx24110_set_fec()
move the return to happen before the logic. This way, we can
avoid one extra identation.
This also fixes an identation issue on this function.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-frontends/cx24110.c
b/drivers/media/dvb-frontends/cx24110.c
index 5a31b3f59306..7b510f2ae20f 100644
--- a/drivers/media/dvb-frontends/cx24110.c
+++ b/drivers/media/dvb-frontends/cx24110.c
@@ -177,10 +177,8 @@ static int cx24110_set_inversion (struct cx24110_state*
state, fe_spectral_inver
return 0;
}
-static int cx24110_set_fec (struct cx24110_state* state, fe_code_rate_t fec)
+static int cx24110_set_fec(struct cx24110_state* state, fe_code_rate_t fec)
{
-/* fixme (low): error handling */
-
static const int rate[FEC_AUTO] = {-1,1,2,3,5,7,
-1};
static const int g1[FEC_AUTO] = {-1, 0x01, 0x02, 0x05, 0x15, 0x45,
-1};
static const int g2[FEC_AUTO] = {-1, 0x01, 0x03, 0x06, 0x1a, 0x7a,
-1};
@@ -208,16 +206,16 @@ static int cx24110_set_fec (struct cx24110_state* state,
fe_code_rate_t fec)
} else {
cx24110_writereg(state, 0x37, cx24110_readreg(state, 0x37) |
0x20);
/* set AcqVitDis bit */
- if (rate[fec] > 0) {
- cx24110_writereg(state, 0x05, (cx24110_readreg(state,
0x05) & 0xf0) | rate[fec]);
- /* set nominal Viterbi rate */
- cx24110_writereg(state, 0x22, (cx24110_readreg(state,
0x22) & 0xf0) | rate[fec]);
- /* set current Viterbi rate */
- cx24110_writereg(state, 0x1a, g1[fec]);
- cx24110_writereg(state, 0x1b, g2[fec]);
- /* not sure if this is the right way: I always used
AutoAcq mode */
- } else
- return -EINVAL;
+ if (rate[fec] < 0)
+ return -EINVAL;
+
+ cx24110_writereg(state, 0x05, (cx24110_readreg(state, 0x05) &
0xf0) | rate[fec]);
+ /* set nominal Viterbi rate */
+ cx24110_writereg(state, 0x22, (cx24110_readreg(state, 0x22) &
0xf0) | rate[fec]);
+ /* set current Viterbi rate */
+ cx24110_writereg(state, 0x1a, g1[fec]);
+ cx24110_writereg(state, 0x1b, g2[fec]);
+ /* not sure if this is the right way: I always used AutoAcq
mode */
}
return 0;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] [media] cx22700: Fix potential buffer overflow
As new FEC types were added, we need a check to avoid overflows: drivers/media/dvb-frontends/cx22700.c:172 cx22700_set_tps() error: buffer overflow 'fec_tab' 6 <= 6 drivers/media/dvb-frontends/cx22700.c:173 cx22700_set_tps() error: buffer overflow 'fec_tab' 6 <= 6 Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb-frontends/cx22700.c b/drivers/media/dvb-frontends/cx22700.c index 3d399d9a6343..86563260d0f2 100644 --- a/drivers/media/dvb-frontends/cx22700.c +++ b/drivers/media/dvb-frontends/cx22700.c @@ -169,6 +169,9 @@ static int cx22700_set_tps(struct cx22700_state *state, cx22700_writereg (state, 0x04, val); + if (p->code_rate_HP - FEC_1_2 >= sizeof(fec_tab) || + p->code_rate_LP - FEC_1_2 >= sizeof(fec_tab)) + return -EINVAL; val = fec_tab[p->code_rate_HP - FEC_1_2] << 3; val |= fec_tab[p->code_rate_LP - FEC_1_2]; -- 1.9.3 -- 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/5] [media] cx24110: Fix a spatch warning
This is actually a false positive:
drivers/media/dvb-frontends/cx24110.c:210 cx24110_set_fec() error:
buffer overflow 'rate' 7 <= 8
But fixing it is easy: just ensure that the table size will be
limited to FEC_AUTO.
While here, fix spacing on the affected lines.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-frontends/cx24110.c
b/drivers/media/dvb-frontends/cx24110.c
index 95b981cd7115..e78e7893e8aa 100644
--- a/drivers/media/dvb-frontends/cx24110.c
+++ b/drivers/media/dvb-frontends/cx24110.c
@@ -181,16 +181,16 @@ static int cx24110_set_fec (struct cx24110_state* state,
fe_code_rate_t fec)
{
/* fixme (low): error handling */
- static const int rate[]={-1,1,2,3,5,7,-1};
- static const int g1[]={-1,0x01,0x02,0x05,0x15,0x45,-1};
- static const int g2[]={-1,0x01,0x03,0x06,0x1a,0x7a,-1};
+ static const int rate[FEC_AUTO] = {-1,1,2,3,5,7,
-1};
+ static const int g1[FEC_AUTO] = {-1, 0x01, 0x02, 0x05, 0x15, 0x45,
-1};
+ static const int g2[FEC_AUTO] = {-1, 0x01, 0x03, 0x06, 0x1a, 0x7a,
-1};
/* Well, the AutoAcq engine of the cx24106 and 24110 automatically
searches all enabled viterbi rates, and can handle non-standard
rates as well. */
- if (fec>FEC_AUTO)
- fec=FEC_AUTO;
+ if (fec > FEC_AUTO)
+ fec = FEC_AUTO;
if (fec==FEC_AUTO) { /* (re-)establish AutoAcq behaviour */
cx24110_writereg(state,0x37,cx24110_readreg(state,0x37)&0xdf);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] [media] cx23110: Fix return code for cx24110_set_fec()
When a parameter is invalid, the right return code is -EINVAL. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb-frontends/cx24110.c b/drivers/media/dvb-frontends/cx24110.c index 4f5c992afe67..5a31b3f59306 100644 --- a/drivers/media/dvb-frontends/cx24110.c +++ b/drivers/media/dvb-frontends/cx24110.c @@ -217,8 +217,7 @@ static int cx24110_set_fec (struct cx24110_state* state, fe_code_rate_t fec) cx24110_writereg(state, 0x1b, g2[fec]); /* not sure if this is the right way: I always used AutoAcq mode */ } else - return -EOPNOTSUPP; -/* fixme (low): which is the correct return code? */ + return -EINVAL; } return 0; } -- 1.9.3 -- 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] cx24110: Fix whitespaces at cx24110_set_fec()
It is hard to read what's there, because it doesn't follow the
CodingStyle.
Add missing whitespaces to split function arguments.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-frontends/cx24110.c
b/drivers/media/dvb-frontends/cx24110.c
index e78e7893e8aa..4f5c992afe67 100644
--- a/drivers/media/dvb-frontends/cx24110.c
+++ b/drivers/media/dvb-frontends/cx24110.c
@@ -192,28 +192,29 @@ static int cx24110_set_fec (struct cx24110_state* state,
fe_code_rate_t fec)
if (fec > FEC_AUTO)
fec = FEC_AUTO;
- if (fec==FEC_AUTO) { /* (re-)establish AutoAcq behaviour */
- cx24110_writereg(state,0x37,cx24110_readreg(state,0x37)&0xdf);
+ if (fec == FEC_AUTO) { /* (re-)establish AutoAcq behaviour */
+ cx24110_writereg(state, 0x37, cx24110_readreg(state, 0x37) &
0xdf);
/* clear AcqVitDis bit */
- cx24110_writereg(state,0x18,0xae);
+ cx24110_writereg(state, 0x18, 0xae);
/* allow all DVB standard code rates */
-
cx24110_writereg(state,0x05,(cx24110_readreg(state,0x05)&0xf0)|0x3);
+ cx24110_writereg(state, 0x05, (cx24110_readreg(state, 0x05) &
0xf0) | 0x3);
/* set nominal Viterbi rate 3/4 */
-
cx24110_writereg(state,0x22,(cx24110_readreg(state,0x22)&0xf0)|0x3);
+ cx24110_writereg(state, 0x22, (cx24110_readreg(state, 0x22) &
0xf0) | 0x3);
/* set current Viterbi rate 3/4 */
- cx24110_writereg(state,0x1a,0x05);
cx24110_writereg(state,0x1b,0x06);
+ cx24110_writereg(state, 0x1a, 0x05);
+ cx24110_writereg(state, 0x1b, 0x06);
/* set the puncture registers for code rate 3/4 */
return 0;
} else {
- cx24110_writereg(state,0x37,cx24110_readreg(state,0x37)|0x20);
+ cx24110_writereg(state, 0x37, cx24110_readreg(state, 0x37) |
0x20);
/* set AcqVitDis bit */
- if(rate[fec]>0) {
-
cx24110_writereg(state,0x05,(cx24110_readreg(state,0x05)&0xf0)|rate[fec]);
+ if (rate[fec] > 0) {
+ cx24110_writereg(state, 0x05, (cx24110_readreg(state,
0x05) & 0xf0) | rate[fec]);
/* set nominal Viterbi rate */
-
cx24110_writereg(state,0x22,(cx24110_readreg(state,0x22)&0xf0)|rate[fec]);
+ cx24110_writereg(state, 0x22, (cx24110_readreg(state,
0x22) & 0xf0) | rate[fec]);
/* set current Viterbi rate */
- cx24110_writereg(state,0x1a,g1[fec]);
- cx24110_writereg(state,0x1b,g2[fec]);
+ cx24110_writereg(state, 0x1a, g1[fec]);
+ cx24110_writereg(state, 0x1b, g2[fec]);
/* not sure if this is the right way: I always used
AutoAcq mode */
} else
return -EOPNOTSUPP;
--
1.9.3
--
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/5] [media] cx24110: Fix a spatch warning
spatch or smatch? I assume smatch :-)
BTW, I've just added smatch support to the daily build.
Regards,
Hans
On 11/05/14 13:03, Mauro Carvalho Chehab wrote:
> This is actually a false positive:
> drivers/media/dvb-frontends/cx24110.c:210 cx24110_set_fec() error:
> buffer overflow 'rate' 7 <= 8
>
> But fixing it is easy: just ensure that the table size will be
> limited to FEC_AUTO.
>
> While here, fix spacing on the affected lines.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/dvb-frontends/cx24110.c
> b/drivers/media/dvb-frontends/cx24110.c
> index 95b981cd7115..e78e7893e8aa 100644
> --- a/drivers/media/dvb-frontends/cx24110.c
> +++ b/drivers/media/dvb-frontends/cx24110.c
> @@ -181,16 +181,16 @@ static int cx24110_set_fec (struct cx24110_state*
> state, fe_code_rate_t fec)
> {
> /* fixme (low): error handling */
>
> - static const int rate[]={-1,1,2,3,5,7,-1};
> - static const int g1[]={-1,0x01,0x02,0x05,0x15,0x45,-1};
> - static const int g2[]={-1,0x01,0x03,0x06,0x1a,0x7a,-1};
> + static const int rate[FEC_AUTO] = {-1,1,2,3,5,7,
> -1};
> + static const int g1[FEC_AUTO] = {-1, 0x01, 0x02, 0x05, 0x15, 0x45,
> -1};
> + static const int g2[FEC_AUTO] = {-1, 0x01, 0x03, 0x06, 0x1a, 0x7a,
> -1};
>
> /* Well, the AutoAcq engine of the cx24106 and 24110 automatically
> searches all enabled viterbi rates, and can handle non-standard
> rates as well. */
>
> - if (fec>FEC_AUTO)
> - fec=FEC_AUTO;
> + if (fec > FEC_AUTO)
> + fec = FEC_AUTO;
>
> if (fec==FEC_AUTO) { /* (re-)establish AutoAcq behaviour */
> cx24110_writereg(state,0x37,cx24110_readreg(state,0x37)&0xdf);
>
--
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] rc-main: Fix rc_type handling
As reported by smatch:
drivers/media/rc/rc-main.c:1426 rc_register_device() warn: should '1 <<
rc_map->rc_type' be a 64 bit type?
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 296de853a25d..66eabc5dd000 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1423,7 +1423,7 @@ int rc_register_device(struct rc_dev *dev)
}
if (dev->change_protocol) {
- u64 rc_type = (1 << rc_map->rc_type);
+ u64 rc_type = (1ll << rc_map->rc_type);
rc = dev->change_protocol(dev, &rc_type);
if (rc < 0)
goto out_raw;
--
1.9.3
--
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: [PATCHv2] [media] af0933: Don't go past arrays
Em Wed, 05 Nov 2014 04:44:22 +0200
Antti Palosaari escreveu:
> Acked-by: Antti Palosaari
> Reviewed-by: Antti Palosaari
>
> anyhow, I think these branches could never taken in real life.
Yes, probably this never happens with current code.
> But as a
> killing warnings and potential future changes I am pretty fine!
The main goal is to kill warnings, but it also prevents future
mistakes. It is a way better to have a warning printed than
to go past the buffer and get random errors.
Regards,
Mauro
>
> regards
> Antti
>
> On 11/04/2014 10:35 PM, Mauro Carvalho Chehab wrote:
> > Fixes the following sparse warnings:
> > drivers/media/dvb-frontends/af9033.c:295 af9033_init() error: buffer
> > overflow 'clock_adc_lut' 11 <= 11
> > drivers/media/dvb-frontends/af9033.c:300 af9033_init() error: buffer
> > overflow 'clock_adc_lut' 11 <= 11
> > drivers/media/dvb-frontends/af9033.c:584 af9033_set_frontend() error:
> > buffer overflow 'coeff_lut' 3 <= 3
> > drivers/media/dvb-frontends/af9033.c:595 af9033_set_frontend() error:
> > buffer overflow 'clock_adc_lut' 11 <= 11
> >
> > Signed-off-by: Mauro Carvalho Chehab
> >
> > -
> > v2: Only changed the patch subject, as it fixes occurrences on 3
> > different arrays.
> >
> > diff --git a/drivers/media/dvb-frontends/af9033.c
> > b/drivers/media/dvb-frontends/af9033.c
> > index c17e34fd0fb4..82ce47bdf5dc 100644
> > --- a/drivers/media/dvb-frontends/af9033.c
> > +++ b/drivers/media/dvb-frontends/af9033.c
> > @@ -291,6 +291,12 @@ static int af9033_init(struct dvb_frontend *fe)
> > if (clock_adc_lut[i].clock == dev->cfg.clock)
> > break;
> > }
> > + if (i == ARRAY_SIZE(clock_adc_lut)) {
> > + dev_err(&dev->client->dev,
> > + "Couldn't find ADC config for clock=%d\n",
> > + dev->cfg.clock);
> > + goto err;
> > + }
> >
> > adc_cw = af9033_div(dev, clock_adc_lut[i].adc, 100ul, 19ul);
> > buf[0] = (adc_cw >> 0) & 0xff;
> > @@ -580,7 +586,15 @@ static int af9033_set_frontend(struct dvb_frontend *fe)
> > break;
> > }
> > }
> > - ret = af9033_wr_regs(dev, 0x81,
> > + if (i == ARRAY_SIZE(coeff_lut)) {
> > + dev_err(&dev->client->dev,
> > + "Couldn't find LUT config for clock=%d\n",
> > + dev->cfg.clock);
> > + ret = -EINVAL;
> > + goto err;
> > + }
> > +
> > + ret = af9033_wr_regs(dev, 0x81,
> > coeff_lut[i].val, sizeof(coeff_lut[i].val));
> > }
> >
> > @@ -592,6 +606,13 @@ static int af9033_set_frontend(struct dvb_frontend *fe)
> > if (clock_adc_lut[i].clock == dev->cfg.clock)
> > break;
> > }
> > + if (i == ARRAY_SIZE(clock_adc_lut)) {
> > + dev_err(&dev->client->dev,
> > + "Couldn't find ADC clock for clock=%d\n",
> > + dev->cfg.clock);
> > + ret = -EINVAL;
> > + goto err;
> > + }
> > adc_freq = clock_adc_lut[i].adc;
> >
> > /* get used IF frequency */
> >
>
--
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/5] [media] cx24110: Fix a spatch warning
Em Wed, 05 Nov 2014 13:21:31 +0100
Hans Verkuil escreveu:
> spatch or smatch? I assume smatch :-)
Yeah, typo... both are tools used for static code analizers... very easy to
type it wrong ;)
>
> BTW, I've just added smatch support to the daily build.
Good!
I'll fix some more smatch errors today. There are some false positives
there, but some seems to be real issues.
>
> Regards,
>
> Hans
>
> On 11/05/14 13:03, Mauro Carvalho Chehab wrote:
> > This is actually a false positive:
> > drivers/media/dvb-frontends/cx24110.c:210 cx24110_set_fec() error:
> > buffer overflow 'rate' 7 <= 8
> >
> > But fixing it is easy: just ensure that the table size will be
> > limited to FEC_AUTO.
> >
> > While here, fix spacing on the affected lines.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> >
> > diff --git a/drivers/media/dvb-frontends/cx24110.c
> > b/drivers/media/dvb-frontends/cx24110.c
> > index 95b981cd7115..e78e7893e8aa 100644
> > --- a/drivers/media/dvb-frontends/cx24110.c
> > +++ b/drivers/media/dvb-frontends/cx24110.c
> > @@ -181,16 +181,16 @@ static int cx24110_set_fec (struct cx24110_state*
> > state, fe_code_rate_t fec)
> > {
> > /* fixme (low): error handling */
> >
> > - static const int rate[]={-1,1,2,3,5,7,-1};
> > - static const int g1[]={-1,0x01,0x02,0x05,0x15,0x45,-1};
> > - static const int g2[]={-1,0x01,0x03,0x06,0x1a,0x7a,-1};
> > + static const int rate[FEC_AUTO] = {-1,1,2,3,5,7,
> > -1};
> > + static const int g1[FEC_AUTO] = {-1, 0x01, 0x02, 0x05, 0x15, 0x45,
> > -1};
> > + static const int g2[FEC_AUTO] = {-1, 0x01, 0x03, 0x06, 0x1a, 0x7a,
> > -1};
> >
> > /* Well, the AutoAcq engine of the cx24106 and 24110 automatically
> >searches all enabled viterbi rates, and can handle non-standard
> >rates as well. */
> >
> > - if (fec>FEC_AUTO)
> > - fec=FEC_AUTO;
> > + if (fec > FEC_AUTO)
> > + fec = FEC_AUTO;
> >
> > if (fec==FEC_AUTO) { /* (re-)establish AutoAcq behaviour */
> > cx24110_writereg(state,0x37,cx24110_readreg(state,0x37)&0xdf);
> >
>
--
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] staging: media: lirc: modify print calls
On Wed, Nov 05, 2014 at 08:17:11AM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 4 Nov 2014 23:43:07 +0200
> Aya Mahfouz escreveu:
>
> > This patches replaces one pr_debug call by dev_dbg and
> > changes the device used by one of the dev_err calls.
>
> Also doesn't apply. Probably made to apply on Greg's tree.
>
> Regards,
> Mauro
>
Yes, I submit patches to Greg's tree. Should I clone your
tree?
Kind Regards,
Aya Saif El-yazal Mahfouz
> >
> > Signed-off-by: Aya Mahfouz
> > ---
> > drivers/staging/media/lirc/lirc_zilog.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> > b/drivers/staging/media/lirc/lirc_zilog.c
> > index 52f8e91..dca806a 100644
> > --- a/drivers/staging/media/lirc/lirc_zilog.c
> > +++ b/drivers/staging/media/lirc/lirc_zilog.c
> > @@ -1447,7 +1447,7 @@ static int ir_probe(struct i2c_client *client, const
> > struct i2c_device_id *id)
> > int ret;
> > bool tx_probe = false;
> >
> > - pr_debug("%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> > + dev_dbg(&client->dev, "%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> > __func__, id->name, adap->nr, adap->name, client->addr);
> >
> > /*
> > @@ -1631,7 +1631,7 @@ out_put_xx:
> > out_put_ir:
> > put_ir_device(ir, true);
> > out_no_ir:
> > - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> > + dev_err(&client->dev, "%s: probing IR %s on %s (i2c-%d) failed with
> > %d\n",
> > __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> >ret);
> > mutex_unlock(&ir_devices_lock);
--
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] staging: media: lirc: modify print calls
On Wed, Nov 05, 2014 at 04:59:15PM +0530, Sudip Mukherjee wrote:
> On Tue, Nov 04, 2014 at 11:43:07PM +0200, Aya Mahfouz wrote:
> > This patches replaces one pr_debug call by dev_dbg and
> > changes the device used by one of the dev_err calls.
>
> i think you should mention in the commit message why you are changing the
> device.
> and also for revised patch its better if you add version number in the
> subject.
> like this is v2.
>
> thanks
> sudip
>
Thanks Sudip for your feedback. I use versions if I keep the same subject.
Kind Regards,
Aya Saif El-yazal Mahfouz
> >
> > Signed-off-by: Aya Mahfouz
> > ---
> > drivers/staging/media/lirc/lirc_zilog.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> > b/drivers/staging/media/lirc/lirc_zilog.c
> > index 52f8e91..dca806a 100644
> > --- a/drivers/staging/media/lirc/lirc_zilog.c
> > +++ b/drivers/staging/media/lirc/lirc_zilog.c
> > @@ -1447,7 +1447,7 @@ static int ir_probe(struct i2c_client *client, const
> > struct i2c_device_id *id)
> > int ret;
> > bool tx_probe = false;
> >
> > - pr_debug("%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> > + dev_dbg(&client->dev, "%s: %s on i2c-%d (%s), client addr=0x%02x\n",
> > __func__, id->name, adap->nr, adap->name, client->addr);
> >
> > /*
> > @@ -1631,7 +1631,7 @@ out_put_xx:
> > out_put_ir:
> > put_ir_device(ir, true);
> > out_no_ir:
> > - dev_err(ir->l.dev, "%s: probing IR %s on %s (i2c-%d) failed with %d\n",
> > + dev_err(&client->dev, "%s: probing IR %s on %s (i2c-%d) failed with
> > %d\n",
> > __func__, tx_probe ? "Tx" : "Rx", adap->name, adap->nr,
> >ret);
> > mutex_unlock(&ir_devices_lock);
> > --
> > 1.9.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/13] media: entity: Document the media_entity_ops structure
On Sun, Nov 02, 2014 at 04:53:26PM +0200, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart
> ---
> include/media/media-entity.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index e004591..786906b 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -44,6 +44,15 @@ struct media_pad {
> unsigned long flags;/* Pad flags (MEDIA_PAD_FL_*) */
> };
>
> +/**
> + * struct media_entity_operations - Media entity operations
> + * @link_setup: Notify the entity of link changes. The
> operation can
> + * return an error, in which case link setup will be
> + * cancelled. Optional.
> + * @link_validate: Return whether a link is valid from the entity point of
> + * view. The media_entity_pipeline_start() function
> + * validates all links by calling this operation. Optional.
> + */
> struct media_entity_operations {
> int (*link_setup)(struct media_entity *entity,
> const struct media_pad *local,
Acked-by: Sakari Ailus
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values
Hi Boris,
On Tue, Nov 04, 2014 at 10:54:57AM +0100, Boris Brezillon wrote:
> In order to have subsytem agnostic media bus format definitions we've
> moved media bus definition to include/uapi/linux/media-bus-format.h and
> prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.
>
> Update the v4l documentation accordingly.
>
> Signed-off-by: Boris Brezillon
> ---
> Documentation/DocBook/media/Makefile | 2 +-
> Documentation/DocBook/media/v4l/subdev-formats.xml | 308
> ++---
> include/uapi/linux/v4l2-mediabus.h | 2 +
> 3 files changed, 157 insertions(+), 155 deletions(-)
>
...
> diff --git a/include/uapi/linux/v4l2-mediabus.h
> b/include/uapi/linux/v4l2-mediabus.h
> index f471064..9fbe891 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -32,6 +32,8 @@ enum v4l2_mbus_pixelcode {
> MEDIA_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
> MEDIA_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
> MEDIA_BUS_TO_V4L2_MBUS(ARGB_1X32),
> + MEDIA_BUS_TO_V4L2_MBUS(RGB444_1X12),
> + MEDIA_BUS_TO_V4L2_MBUS(RGB565_1X16),
Shouldn't this to go to a separate patch?
>
> MEDIA_BUS_TO_V4L2_MBUS(Y8_1X8),
> MEDIA_BUS_TO_V4L2_MBUS(UV8_1X8),
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] m88ds3103: change ts clock config for serial mode
1> When m88ds3103 works in serial ts mode, its serial ts clock is equal to ts
master clock and the clock divider is bypassed.
2> The serial ts clock is configed by the bridge driver just like parallel ts
clock.
Signed-off-by: Nibble Max
---
drivers/media/dvb-frontends/m88ds3103.c | 55 +++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index 621d20f..0cd445c 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -245,9 +245,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret, len;
const struct m88ds3103_reg_val *init;
- u8 u8tmp, u8tmp1, u8tmp2;
+ u8 u8tmp, u8tmp1 = 0, u8tmp2 = 0; /* silence compiler warning */
u8 buf[3];
- u16 u16tmp, divide_ratio;
+ u16 u16tmp, divide_ratio = 0;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
@@ -319,32 +319,29 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
/* set M88DS3103 mclk and ts mclk. */
priv->mclk_khz = 96000;
- if (c->delivery_system == SYS_DVBS)
- target_mclk = 96000;
- else {
- switch (priv->cfg->ts_mode) {
- case M88DS3103_TS_SERIAL:
- case M88DS3103_TS_SERIAL_D7:
- if (c->symbol_rate < 1800)
- target_mclk = 96000;
- else
- target_mclk = 144000;
- break;
- case M88DS3103_TS_PARALLEL:
- case M88DS3103_TS_CI:
+ switch (priv->cfg->ts_mode) {
+ case M88DS3103_TS_SERIAL:
+ case M88DS3103_TS_SERIAL_D7:
+ target_mclk = priv->cfg->ts_clk;
+ break;
+ case M88DS3103_TS_PARALLEL:
+ case M88DS3103_TS_CI:
+ if (c->delivery_system == SYS_DVBS)
+ target_mclk = 96000;
+ else {
if (c->symbol_rate < 1800)
target_mclk = 96000;
else if (c->symbol_rate < 2800)
target_mclk = 144000;
else
target_mclk = 192000;
- break;
- default:
- dev_dbg(&priv->i2c->dev, "%s: invalid
ts_mode\n",
- __func__);
- ret = -EINVAL;
- goto err;
}
+ break;
+ default:
+ dev_dbg(&priv->i2c->dev, "%s: invalid ts_mode\n",
+ __func__);
+ ret = -EINVAL;
+ goto err;
}
switch (target_mclk) {
@@ -434,7 +431,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
- u8tmp1 = 0; /* silence compiler warning */
switch (priv->cfg->ts_mode) {
case M88DS3103_TS_SERIAL:
u8tmp1 = 0x00;
@@ -470,16 +466,15 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
ret = m88ds3103_wr_reg_mask(priv, 0x29, u8tmp1, 0x20);
if (ret)
goto err;
- }
-
- if (priv->cfg->ts_clk) {
- divide_ratio = DIV_ROUND_UP(target_mclk, priv->cfg->ts_clk);
- u8tmp1 = divide_ratio / 2;
- u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
- } else {
- divide_ratio = 0;
u8tmp1 = 0;
u8tmp2 = 0;
+ break;
+ default:
+ if (priv->cfg->ts_clk) {
+ divide_ratio = DIV_ROUND_UP(target_mclk,
priv->cfg->ts_clk);
+ u8tmp1 = divide_ratio / 2;
+ u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
+ }
}
dev_dbg(&priv->i2c->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 1/3] cx23885: add DVBSky S950 support
DVBSky S950 dvb-s/s2 PCIe card:
1>dvb frontend: M88TS2022(tuner),M88DS3103(demod)
2>PCIe bridge: cx23885
3>rc: cx23885 integrated.
Signed-off-by: Nibble Max
---
drivers/media/pci/cx23885/cx23885-cards.c | 20
drivers/media/pci/cx23885/cx23885-dvb.c | 9 ++---
drivers/media/pci/cx23885/cx23885-input.c | 3 +++
drivers/media/pci/cx23885/cx23885.h | 1 +
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 9c7e8ac..4b9cb07 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -692,6 +692,10 @@ struct cx23885_board cx23885_boards[] = {
.name = "Technotrend TT-budget CT2-4500 CI",
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_DVBSKY_S950] = {
+ .name = "DVBSky S950",
+ .portb = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -963,6 +967,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x13c2,
.subdevice = 0x3013,
.card = CX23885_BOARD_TT_CT2_4500_CI,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0950,
+ .card = CX23885_BOARD_DVBSKY_S950,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1597,6 +1605,13 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
/* enable irq */
cx_write(GPIO_ISM, 0x); /* INTERRUPTS active low */
+ break;
+ case CX23885_BOARD_DVBSKY_S950:
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_clear(dev, GPIO_2);
+ msleep(100);
+ cx23885_gpio_set(dev, GPIO_2);
+ break;
}
}
@@ -1681,6 +1696,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
if (!enable_885_ir)
break;
dev->sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1731,6 +1747,7 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
cx23885_irq_remove(dev, PCI_MSK_AV_CORE);
/* sd_ir is a duplicate pointer to the AV Core, just clear it */
dev->sd_ir = NULL;
@@ -1782,6 +1799,7 @@ void cx23885_ir_pci_int_enable(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
if (dev->sd_ir)
cx23885_irq_add_enable(dev, PCI_MSK_AV_CORE);
break;
@@ -1888,6 +1906,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
ts1->gen_ctrl_val = 0x5; /* Parallel */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
@@ -2009,6 +2028,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 9da5cf3..3410ab8 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1672,6 +1672,7 @@ static int dvb_register(struct cx23885_tsport *port)
}
break;
case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S950:
i2c_bus = &dev->i2c_bus[0];
i2c_bus2 = &dev->i2c_bus[1];
switch (port->nr) {
@@ -1922,7 +1923,8 @@ static int dvb_register(struct cx23885_tsport *port)
memcpy(port->frontends.adapter.proposed_mac, eeprom + 0xa0, 6);
break;
}
- case CX23885_BOARD_DVBSKY_T9580: {
+ case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S950: {
u8 eeprom[256]; /* 24C02 i2c eeprom */
if (port->nr > 2)
@@ -1932,8 +1934,9 @@ static int dvb_register(struct cx23885_tsport *port)
[PATCH 2/3] cx23885: add DVBSky S952 support
DVBSky S952 dvb-s/s2 dual PCIe card:
1>dvb frontend: M88TS2022(tuner),M88DS3103(demod)
2>PCIe bridge: CX23885(port b: parallel mode, port c: serial mode)
3>rc: cx23885 integrated.
Signed-off-by: Nibble Max
---
drivers/media/pci/cx23885/cx23885-cards.c | 22 +++
drivers/media/pci/cx23885/cx23885-dvb.c | 99 ++-
drivers/media/pci/cx23885/cx23885-input.c | 3 +
drivers/media/pci/cx23885/cx23885.h | 1 +
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 4b9cb07..4bad27d 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -696,6 +696,11 @@ struct cx23885_board cx23885_boards[] = {
.name = "DVBSky S950",
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_DVBSKY_S952] = {
+ .name = "DVBSky S952",
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -971,6 +976,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x4254,
.subdevice = 0x0950,
.card = CX23885_BOARD_DVBSKY_S950,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0952,
+ .card = CX23885_BOARD_DVBSKY_S952,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1566,6 +1575,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
mdelay(60);
break;
case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S952:
/* enable GPIO3-18 pins */
cx_write(MC417_CTL, 0x0037);
cx23885_gpio_enable(dev, GPIO_2 | GPIO_11, 1);
@@ -1697,6 +1707,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
if (!enable_885_ir)
break;
dev->sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1748,6 +1759,7 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
cx23885_irq_remove(dev, PCI_MSK_AV_CORE);
/* sd_ir is a duplicate pointer to the AV Core, just clear it */
dev->sd_ir = NULL;
@@ -1800,6 +1812,7 @@ void cx23885_ir_pci_int_enable(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
if (dev->sd_ir)
cx23885_irq_add_enable(dev, PCI_MSK_AV_CORE);
break;
@@ -1962,6 +1975,14 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+ case CX23885_BOARD_DVBSKY_S952:
+ ts1->gen_ctrl_val = 0x5; /* Parallel */
+ ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ ts2->gen_ctrl_val = 0xe; /* Serial bus */
+ ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
@@ -2029,6 +2050,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 3410ab8..2457b64 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -617,6 +617,32 @@ static int dvbsky_t9580_set_voltage(struct dvb_frontend
*fe,
return 0;
}
+static int dvbsky_s952_portc_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
+{
+ struct cx23885_tsport *port = fe->dvb->priv;
+ struct cx23885_dev *dev = port->dev;
+
+ cx23885_gpio_enable(dev, GPIO_12 | GPIO_13, 1);
+
+ switch (voltage) {
+ case SE
Re: [PATCH 02/15] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values
Hi Sakari,
On Wed, 5 Nov 2014 16:57:27 +0200
Sakari Ailus wrote:
> Hi Boris,
>
> On Tue, Nov 04, 2014 at 10:54:57AM +0100, Boris Brezillon wrote:
> > In order to have subsytem agnostic media bus format definitions we've
> > moved media bus definition to include/uapi/linux/media-bus-format.h and
> > prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.
> >
> > Update the v4l documentation accordingly.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > Documentation/DocBook/media/Makefile | 2 +-
> > Documentation/DocBook/media/v4l/subdev-formats.xml | 308
> > ++---
> > include/uapi/linux/v4l2-mediabus.h | 2 +
> > 3 files changed, 157 insertions(+), 155 deletions(-)
> >
>
> ...
>
> > diff --git a/include/uapi/linux/v4l2-mediabus.h
> > b/include/uapi/linux/v4l2-mediabus.h
> > index f471064..9fbe891 100644
> > --- a/include/uapi/linux/v4l2-mediabus.h
> > +++ b/include/uapi/linux/v4l2-mediabus.h
> > @@ -32,6 +32,8 @@ enum v4l2_mbus_pixelcode {
> > MEDIA_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
> > MEDIA_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
> > MEDIA_BUS_TO_V4L2_MBUS(ARGB_1X32),
> > + MEDIA_BUS_TO_V4L2_MBUS(RGB444_1X12),
> > + MEDIA_BUS_TO_V4L2_MBUS(RGB565_1X16),
>
> Shouldn't this to go to a separate patch?
Absolutely, some changes from a different patch have slipped into this
one.
I'll fix that.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 01/15] [media] Move mediabus format definition to a more standard place
Hi, On Tue, Nov 04, 2014 at 12:09:59PM +0100, Hans Verkuil wrote: > Well, I gave two alternatives :-) > > Both are fine as far as I am concerned, but it would be nice to hear > what others think. In fact I think both are good options. :-) I'd perhaps lean towards the latter, for it has the benefit of pushing to use the new definitions and the old ones can be deprecated (and eventually removed in year 2030 or so ;)). Either way, preprocessor macros should be used instead of an enum since that way it's possible to figure out at that phase whether something is defined or not. There is for enums, too, but it results in a compilation error... -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] [media] Deprecate v4l2_mbus_pixelcode
Hi Boris, On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: > The v4l2_mbus_pixelcode enum (or its values) should be replaced by the > media_bus_format enum. > Keep this enum in v4l2-mediabus.h and create a new header containing > the v4l2_mbus_framefmt struct definition (which is not deprecated) so > that we can add a #warning statement in v4l2-mediabus.h and hopefully > encourage users to move to the new definitions. > > Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common headers > and update the documentation Makefile to parse v4l2-mbus.h instead of > v4l2-mediabus.h. > > Signed-off-by: Boris Brezillon > --- > Documentation/DocBook/media/Makefile | 2 +- > include/media/v4l2-mediabus.h| 2 +- > include/uapi/linux/Kbuild| 1 + > include/uapi/linux/v4l2-mbus.h | 35 +++ > include/uapi/linux/v4l2-mediabus.h | 26 -- I would keep the original file name, even if the compatibility definitions are there. I don't see any harm in having them around as well. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] [media] Deprecate v4l2_mbus_pixelcode
On Wed, 5 Nov 2014 17:08:15 +0200 Sakari Ailus wrote: > Hi Boris, > > On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: > > The v4l2_mbus_pixelcode enum (or its values) should be replaced by the > > media_bus_format enum. > > Keep this enum in v4l2-mediabus.h and create a new header containing > > the v4l2_mbus_framefmt struct definition (which is not deprecated) so > > that we can add a #warning statement in v4l2-mediabus.h and hopefully > > encourage users to move to the new definitions. > > > > Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common headers > > and update the documentation Makefile to parse v4l2-mbus.h instead of > > v4l2-mediabus.h. > > > > Signed-off-by: Boris Brezillon > > --- > > Documentation/DocBook/media/Makefile | 2 +- > > include/media/v4l2-mediabus.h| 2 +- > > include/uapi/linux/Kbuild| 1 + > > include/uapi/linux/v4l2-mbus.h | 35 > > +++ > > include/uapi/linux/v4l2-mediabus.h | 26 -- > > I would keep the original file name, even if the compatibility definitions > are there. I don't see any harm in having them around as well. > That's the part I was not sure about. The goal of this patch (and the following ones) is to deprecate v4l2_mbus_pixelcode enum and its values by adding a #warning when v4l2-mediabus.h file is included, thus encouraging people to use new definitions. Do you see another solution to generate such warnings at compilation time ? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 03/15] [media] Make use of the new media_bus_format definitions
On Tue, Nov 04, 2014 at 10:54:58AM +0100, Boris Brezillon wrote: > Replace references to the v4l2_mbus_pixelcode enum with the new > media_bus_format enum in all common headers. > > Signed-off-by: Boris Brezillon Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] [media] Deprecate v4l2_mbus_pixelcode
On 11/05/14 16:15, Boris Brezillon wrote: > On Wed, 5 Nov 2014 17:08:15 +0200 > Sakari Ailus wrote: > >> Hi Boris, >> >> On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: >>> The v4l2_mbus_pixelcode enum (or its values) should be replaced by the >>> media_bus_format enum. >>> Keep this enum in v4l2-mediabus.h and create a new header containing >>> the v4l2_mbus_framefmt struct definition (which is not deprecated) so >>> that we can add a #warning statement in v4l2-mediabus.h and hopefully >>> encourage users to move to the new definitions. >>> >>> Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common headers >>> and update the documentation Makefile to parse v4l2-mbus.h instead of >>> v4l2-mediabus.h. >>> >>> Signed-off-by: Boris Brezillon >>> --- >>> Documentation/DocBook/media/Makefile | 2 +- >>> include/media/v4l2-mediabus.h| 2 +- >>> include/uapi/linux/Kbuild| 1 + >>> include/uapi/linux/v4l2-mbus.h | 35 >>> +++ >>> include/uapi/linux/v4l2-mediabus.h | 26 -- >> >> I would keep the original file name, even if the compatibility definitions >> are there. I don't see any harm in having them around as well. >> > > That's the part I was not sure about. > The goal of this patch (and the following ones) is to deprecate > v4l2_mbus_pixelcode enum and its values by adding a #warning when > v4l2-mediabus.h file is included, thus encouraging people to use new > definitions. Since v4l2-mediabus.h contains struct v4l2_mbus_framefmt this header remains a legal header, so you can't use #warning here in any case. Regards, Hans > > Do you see another solution to generate such warnings at compilation > time ? > -- 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 11/15] [media] Deprecate v4l2_mbus_pixelcode
Hi Boris, On Wed, Nov 05, 2014 at 04:15:38PM +0100, Boris Brezillon wrote: > On Wed, 5 Nov 2014 17:08:15 +0200 > Sakari Ailus wrote: > > I would keep the original file name, even if the compatibility definitions > > are there. I don't see any harm in having them around as well. > > > > That's the part I was not sure about. > The goal of this patch (and the following ones) is to deprecate > v4l2_mbus_pixelcode enum and its values by adding a #warning when > v4l2-mediabus.h file is included, thus encouraging people to use new > definitions. > > Do you see another solution to generate such warnings at compilation > time ? Do you think we need a warning? In a general case we can't start renaming interface headers once the preferred interface changes, albeit in this case it would be a possibility. The presence of the formats defined from now on only in the new definitions should be good enough. There are many cases such as this in the V4L2 and other APIs. I wonder what others think. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] [media] Deprecate v4l2_mbus_pixelcode
On Wed, 05 Nov 2014 16:19:56 +0100 Hans Verkuil wrote: > > > On 11/05/14 16:15, Boris Brezillon wrote: > > On Wed, 5 Nov 2014 17:08:15 +0200 > > Sakari Ailus wrote: > > > >> Hi Boris, > >> > >> On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: > >>> The v4l2_mbus_pixelcode enum (or its values) should be replaced by the > >>> media_bus_format enum. > >>> Keep this enum in v4l2-mediabus.h and create a new header containing > >>> the v4l2_mbus_framefmt struct definition (which is not deprecated) so > >>> that we can add a #warning statement in v4l2-mediabus.h and hopefully > >>> encourage users to move to the new definitions. > >>> > >>> Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common > >>> headers > >>> and update the documentation Makefile to parse v4l2-mbus.h instead of > >>> v4l2-mediabus.h. > >>> > >>> Signed-off-by: Boris Brezillon > >>> --- > >>> Documentation/DocBook/media/Makefile | 2 +- > >>> include/media/v4l2-mediabus.h| 2 +- > >>> include/uapi/linux/Kbuild| 1 + > >>> include/uapi/linux/v4l2-mbus.h | 35 > >>> +++ > >>> include/uapi/linux/v4l2-mediabus.h | 26 -- > >> > >> I would keep the original file name, even if the compatibility definitions > >> are there. I don't see any harm in having them around as well. > >> > > > > That's the part I was not sure about. > > The goal of this patch (and the following ones) is to deprecate > > v4l2_mbus_pixelcode enum and its values by adding a #warning when > > v4l2-mediabus.h file is included, thus encouraging people to use new > > definitions. > > Since v4l2-mediabus.h contains struct v4l2_mbus_framefmt this header remains > a legal header, so you can't use #warning here in any case. > Actually this patch moves the struct v4l2_mbus_framefmt definition into another header before adding the warning statement. Anyway, this is really a detail, and if everybody agrees that we should just leave the old definition in place, I'm fine with that. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 01/15] [media] Move mediabus format definition to a more standard place
On Wed, 5 Nov 2014 17:00:25 +0200 Sakari Ailus wrote: > Hi, > > On Tue, Nov 04, 2014 at 12:09:59PM +0100, Hans Verkuil wrote: > > Well, I gave two alternatives :-) > > > > Both are fine as far as I am concerned, but it would be nice to hear > > what others think. > > In fact I think both are good options. :-) > > I'd perhaps lean towards the latter, for it has the benefit of pushing to > use the new definitions and the old ones can be deprecated (and eventually > removed in year 2030 or so ;)). > > Either way, preprocessor macros should be used instead of an enum since that > way it's possible to figure out at that phase whether something is defined > or not. There is for enums, too, but it results in a compilation error... > I don't get that last part :-). -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 11/15] [media] Deprecate v4l2_mbus_pixelcode
On 11/05/14 16:30, Boris Brezillon wrote: > On Wed, 05 Nov 2014 16:19:56 +0100 > Hans Verkuil wrote: > >> >> >> On 11/05/14 16:15, Boris Brezillon wrote: >>> On Wed, 5 Nov 2014 17:08:15 +0200 >>> Sakari Ailus wrote: >>> Hi Boris, On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: > The v4l2_mbus_pixelcode enum (or its values) should be replaced by the > media_bus_format enum. > Keep this enum in v4l2-mediabus.h and create a new header containing > the v4l2_mbus_framefmt struct definition (which is not deprecated) so > that we can add a #warning statement in v4l2-mediabus.h and hopefully > encourage users to move to the new definitions. > > Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common > headers > and update the documentation Makefile to parse v4l2-mbus.h instead of > v4l2-mediabus.h. > > Signed-off-by: Boris Brezillon > --- > Documentation/DocBook/media/Makefile | 2 +- > include/media/v4l2-mediabus.h| 2 +- > include/uapi/linux/Kbuild| 1 + > include/uapi/linux/v4l2-mbus.h | 35 > +++ > include/uapi/linux/v4l2-mediabus.h | 26 -- I would keep the original file name, even if the compatibility definitions are there. I don't see any harm in having them around as well. >>> >>> That's the part I was not sure about. >>> The goal of this patch (and the following ones) is to deprecate >>> v4l2_mbus_pixelcode enum and its values by adding a #warning when >>> v4l2-mediabus.h file is included, thus encouraging people to use new >>> definitions. >> >> Since v4l2-mediabus.h contains struct v4l2_mbus_framefmt this header remains >> a legal header, so you can't use #warning here in any case. >> > > Actually this patch moves the struct v4l2_mbus_framefmt definition into > another header before adding the warning statement. There is nothing wrong with keeping the struct in the header. Just keep it there. Hans > > Anyway, this is really a detail, and if everybody agrees that we should > just leave the old definition in place, I'm fine with that. -- 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: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi Paolo, On Wed, Nov 05, 2014 at 10:13:45AM +, Paulo Assis wrote: > Hi, > > 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > > Sakari Ailus wrote: > >> yavta does, for example, print both the monotonic timestamp from the buffer > >> and the time when the buffer has been dequeued: > >> > >> http://git.ideasonboard.org/yavta.git> > >> > >> $ yavta -c /dev/video0 > >> > >> should do it. The first timestamp is the buffer timestamp, and the latter > >> is > >> the one is taken when the buffer is dequeued (by yavta). > > I've done exaclty this with guvcview, and uvcvideo timestamps are > completly unreliable, in some devices they may have just a bit of > jitter, but in others, values go back and forth in time, making them > totally unusable. > Honestly I wouldn't trust device firmware to provide correct > timestamps, or at least I would have the driver perform a couple of > tests to make sure these are at least reasonable: within an expected > interval (maybe comparing it to a reference monotonic clock) or at the > very least making sure the current frame timestamp is not lower than > the previous one. Using the hardware timestamps provides much better accuracy than the software ones --- the real time capabilities of the USB aren't exactly the same as on some other busses. Freel free to try the follow-up patches; I've only compile tested them so far. It might be possible to add some heuristics to detect bad implementations but perhaps we could simply flag them for now. If heuristics would be used, then one would likely have a few bad timestamps every time the device is accessed the first time anyway. Besides, the timestamp type changes as a result. I wonder what Laurent thinks. :-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/2] uvc: Add a quirk flag for cameras that do not produce correct timestamps
The UVC devices do produce hardware timestamps according to the spec, but
not all cameras implement it or implement it correctly. Add a quirk flag for
such devices, and use monotonic timestamp from the end of the frame instead.
Signed-off-by: Sakari Ailus
---
drivers/media/usb/uvc/uvc_queue.c | 6 --
drivers/media/usb/uvc/uvc_video.c | 14 +-
drivers/media/usb/uvc/uvcvideo.h | 4 +++-
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index 6e92d20..3f6432f 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -141,7 +141,7 @@ static struct vb2_ops uvc_queue_qops = {
};
int uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
- int drop_corrupted)
+ bool drop_corrupted, bool tstamp_eof)
{
int ret;
@@ -152,7 +152,9 @@ int uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type,
queue->queue.ops = &uvc_queue_qops;
queue->queue.mem_ops = &vb2_vmalloc_memops;
queue->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC
- | V4L2_BUF_FLAG_TSTAMP_SRC_SOE;
+ | (tstamp_eof ? V4L2_BUF_FLAG_TSTAMP_SRC_EOF
+ : V4L2_BUF_FLAG_TSTAMP_SRC_SOE);
+
ret = vb2_queue_init(&queue->queue);
if (ret)
return ret;
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index df81b9c..f599112 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -382,6 +382,9 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct
uvc_buffer *buf,
u16 host_sof;
u16 dev_sof;
+ if (stream->dev->quirks & UVC_QUIRK_BAD_TIMESTAMP)
+ return;
+
switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
case UVC_STREAM_PTS | UVC_STREAM_SCR:
header_size = 12;
@@ -490,6 +493,9 @@ static int uvc_video_clock_init(struct uvc_streaming
*stream)
{
struct uvc_clock *clock = &stream->clock;
+ if (stream->dev->quirks & UVC_QUIRK_BAD_TIMESTAMP)
+ return 0;
+
spin_lock_init(&clock->lock);
clock->size = 32;
@@ -615,6 +621,11 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
u32 rem;
u64 y;
+ if (stream->dev->quirks & UVC_QUIRK_BAD_TIMESTAMP) {
+ v4l2_get_timestamp(&v4l2_buf->timestamp);
+ return;
+ }
+
spin_lock_irqsave(&clock->lock, flags);
if (clock->count < clock->size)
@@ -1779,7 +1790,8 @@ int uvc_video_init(struct uvc_streaming *stream)
atomic_set(&stream->active, 0);
/* Initialize the video buffers queue. */
- ret = uvc_queue_init(&stream->queue, stream->type, !uvc_no_drop_param);
+ ret = uvc_queue_init(&stream->queue, stream->type, !uvc_no_drop_param,
+stream->dev->quirks & UVC_QUIRK_BAD_TIMESTAMP);
if (ret)
return ret;
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 864ada7..89a638c 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -148,6 +148,7 @@
#define UVC_QUIRK_PROBE_DEF0x0100
#define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
#define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
+#define UVC_QUIRK_BAD_TIMESTAMP0x0800
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED0x0001
@@ -622,7 +623,8 @@ extern struct uvc_entity *uvc_entity_by_id(struct
uvc_device *dev, int id);
/* Video buffers queue management. */
extern int uvc_queue_init(struct uvc_video_queue *queue,
- enum v4l2_buf_type type, int drop_corrupted);
+ enum v4l2_buf_type type, bool drop_corrupted,
+ bool tstamp_eof);
extern int uvc_alloc_buffers(struct uvc_video_queue *queue,
struct v4l2_requestbuffers *rb);
extern void uvc_free_buffers(struct uvc_video_queue *queue);
--
2.1.0.231.g7484e3b
--
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 2/2] uvc: Use UVC_QUIRK_BAD_TIMESTAMP quirk flag for Logitech C920
Signed-off-by: Sakari Ailus
---
drivers/media/usb/uvc/uvc_driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 7c8322d..3908e2f 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2183,7 +2183,9 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceClass = USB_CLASS_VIDEO,
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
- .driver_info = UVC_QUIRK_RESTORE_CTRLS_ON_INIT },
+ .driver_info = UVC_QUIRK_RESTORE_CTRLS_ON_INIT
+ | UVC_QUIRK_BAD_TIMESTAMP
+ },
/* Chicony CNF7129 (Asus EEE 100HE) */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
2.1.0.231.g7484e3b
--
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] staging: media: lirc: modify print calls
On Wed, Nov 05, 2014 at 03:43:44PM +0200, Aya Mahfouz wrote: > On Wed, Nov 05, 2014 at 08:17:11AM -0200, Mauro Carvalho Chehab wrote: > > Em Tue, 4 Nov 2014 23:43:07 +0200 > > Aya Mahfouz escreveu: > > > > > This patches replaces one pr_debug call by dev_dbg and > > > changes the device used by one of the dev_err calls. > > > > Also doesn't apply. Probably made to apply on Greg's tree. > > > > Regards, > > Mauro > > > > Yes, I submit patches to Greg's tree. Should I clone your > tree? I'll take this one as it builds on a change in my tree. thanks, greg k-h -- 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/11] v4l: xilinx: Add Xilinx Video IP core
Hi Hans,
On Monday 03 November 2014 10:47:03 Hans Verkuil wrote:
> On 11/01/2014 02:24 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > Thank you for the review. I've fixed most of the issues you've pointed
> > out, please find my replies to the remaining ones below.
> >
> > On Tuesday 30 September 2014 16:03:34 Hans Verkuil wrote:
> >> On 09/29/14 22:27, Laurent Pinchart wrote:
> >>> Xilinx platforms have no hardwired video capture or video processing
> >>> interface. Users create capture and memory to memory processing
> >>> pipelines in the FPGA fabric to suit their particular needs, by
> >>> instantiating video IP cores from a large library.
> >>>
> >>> The Xilinx Video IP core is a framework that models a video pipeline
> >>> described in the device tree and expose the pipeline to userspace
> >>> through the media controller and V4L2 APIs.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>> Signed-off-by: Hyun Kwon
> >>> Signed-off-by: Radhey Shyam Pandey
> >>> Signed-off-by: Michal Simek
> >>> ---
> >>>
> >>> .../devicetree/bindings/media/xilinx/video.txt | 52 ++
> >>> .../bindings/media/xilinx/xlnx,video.txt | 55 ++
> >>> MAINTAINERS| 9 +
> >>> drivers/media/platform/Kconfig | 1 +
> >>> drivers/media/platform/Makefile| 2 +
> >>> drivers/media/platform/xilinx/Kconfig | 10 +
> >>> drivers/media/platform/xilinx/Makefile | 3 +
> >>> drivers/media/platform/xilinx/xilinx-dma.c | 995 ++
> >>> drivers/media/platform/xilinx/xilinx-dma.h | 109 +++
> >>> drivers/media/platform/xilinx/xilinx-vip.c | 269 ++
> >>> drivers/media/platform/xilinx/xilinx-vip.h | 227 +
> >>> drivers/media/platform/xilinx/xilinx-vipp.c| 666 ++
> >>> drivers/media/platform/xilinx/xilinx-vipp.h| 47 +
> >>> 13 files changed, 2445 insertions(+)
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/media/xilinx/video.txt
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt create
> >>> mode 100644 drivers/media/platform/xilinx/Kconfig
> >>> create mode 100644 drivers/media/platform/xilinx/Makefile
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-dma.c
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-dma.h
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-vip.c
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-vip.h
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-vipp.c
> >>> create mode 100644 drivers/media/platform/xilinx/xilinx-vipp.h
> >>>
> >>> Cc: devicet...@vger.kernel.org
> >
> > [snip]
> >
> >>> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> >>> b/drivers/media/platform/xilinx/xilinx-dma.c new file mode 100644
> >>> index 000..e09e8bd
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> >
> > [snip]
> >
> >>> +static void
> >>> +__xvip_dma_try_format(struct xvip_dma *dma, struct v4l2_pix_format
> >>> *pix,
> >>> + const struct xvip_video_format **fmtinfo)
> >>> +{
> >>> + const struct xvip_video_format *info;
> >>> + unsigned int min_width;
> >>> + unsigned int max_width;
> >>> + unsigned int min_bpl;
> >>> + unsigned int max_bpl;
> >>> + unsigned int width;
> >>> + unsigned int align;
> >>> + unsigned int bpl;
> >>> +
> >>> + /* Retrieve format information and select the default format if the
> >>> + * requested format isn't supported.
> >>> + */
> >>> + info = xvip_get_format_by_fourcc(pix->pixelformat);
> >>> + if (IS_ERR(info))
> >>> + info = xvip_get_format_by_fourcc(XVIP_DMA_DEF_FORMAT);
> >>> +
> >>> + pix->pixelformat = info->fourcc;
> >>> + pix->colorspace = V4L2_COLORSPACE_SRGB;
> >>
> >> Colorspace information can be tricky: for capture the colorspace should
> >> come from the subdevs (e.g. the HDMI receiver), for output the colorspace
> >> is set by the application and passed on to the transmitter.
> >
> > I agree with you. However, in the general case, this will be impossible to
> > implement.
> >
> > Imagine for instance a pipeline with two inputs, one from an HDMI decoder
> > and one from a sensor. They are both connected to a composing unit that
> > writes the resulting image to memory. The colorspace on the capture video
> > node is then undefined.
> >
> > Given that this driver is media controller based and relies on userspace
> > to propagate formats through the pipeline during configuration, I believe
> > it should also be userspace's responsibility to retrieve colorspace
> > information from the correct subdev(s).
>
> But so can your driver. The DMA engine is streaming from/to a subdev, so it
> should ask/set the colorspace from that subdev. This driver certainly does
> not know the colorspace, so setting it to some random value is simply
> wrong.
That's not how format propagation works
Re: [PATCH v2 11/13] v4l: xilinx: Add Xilinx Video IP core
Hi Hans, On Monday 03 November 2014 11:12:15 Hans Verkuil wrote: > Hi Laurent, > > Some small nitpicks... > > On 11/02/2014 03:53 PM, Laurent Pinchart wrote: > > Xilinx platforms have no hardwired video capture or video processing > > interface. Users create capture and memory to memory processing > > pipelines in the FPGA fabric to suit their particular needs, by > > instantiating video IP cores from a large library. > > > > The Xilinx Video IP core is a framework that models a video pipeline > > described in the device tree and expose the pipeline to userspace > > through the media controller and V4L2 APIs. > > > > Signed-off-by: Laurent Pinchart > > Signed-off-by: Hyun Kwon > > Signed-off-by: Radhey Shyam Pandey > > Signed-off-by: Michal Simek > > > > --- > > > > Cc: devicet...@vger.kernel.org > > > > Changes since v1: > > > > - Remove unnecessary fields from struct xvip_dma_buffer > > - Fix querycap capabilities and bus_info reporting > > - Refuse to set format when the queue is busy > > - Return buffers to vb2 when start_streaming fails > > - Use vb2 fops and ioctl ops > > > > v1 was made of the following individual patches. > > > > media: xilinx: vip: Add yuv444 and bayer formats > > media: xilinx: vip: Remove _TIMING_ from register definition > > media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback > > media: xilinx: dma: Fix alignments of xvip_dma_fops definition > > media: xilinx: dma: Workaround for bytesperline > > media: xilinx: vip: Add default min/max height/width definitions > > media: xilinx: vip: Add common sink/source pad IDs > > media: xilinx: vip: Add xvip_set_format_size() > > media: xilinx: vip: Add xvip_enum_mbus_code() > > media: xilinx: vip: Add xvip_enum_frame_size() > > media: xilinx: vip: Add register clear and set functions > > media: xilinx: vip: Add xvip_start() > > media: xilinx: vip: Add xvip_stop() > > media: xilinx: vip: Add xvip_set_frame_size() > > media: xilinx: vip: Add enable/disable reg update functions > > media: xilinx: vip: Add xvip_print_version() > > media: xilinx: vip: Add xvip_reset() > > media: xilinx: vip: Add xvip_get_frame_size() > > media: xilinx: vip: Add suspend/resume helper functions > > media: xilinx: vip: Change the return value of xvip_get_format_by_code() > > media: xilinx: vip: Change the return value of xvip_of_get_format() > > media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() > > media: xilinx: vipp: Remove of_match_ptr() > > media: xilinx: vipp: Add control to inherit subdevice controls > > media: xilinx: Make disconnected video nodes return -EPIPE at stream on > > media: xilinx: Make links configurable > > media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity > > media: xilinx: Rename xvip_pipeline to xvip_composite_device > > media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* > > media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* > > media: xilinx: Rename xvipp_* functions to xvip_composite_* > > media: xilinx: Move pipeline management code to xilinx-dma.c > > media: xilinx: Add missing mutex_destroy call > > media: xilinx: Create xvip_pipeline structure > > media: xilinx: Support more than two VDMAs in DT > > media: xilinx: dma: Change vdma configuration to cyclic-mode > > Revert "media: xilinx: dma: Workaround for bytesperline" > > media: xilinx: Added DMA error handling > > media: xilinx: Fix error handling > > media: xilinx: Reordered mutexes initialization > > media: xilinx: vipp: Add devicetree bindings documentation > > media: xilinx: Reordered mutexes initialization > > media: xilinx: Set format description in enum_fmt > > media: xilinx: Remove global control handler > > media: xilinx: dma: Use the interleaved dmaengine API > > xilinx: Remove .owner field for drivers > > v4l: xilinx: video: Rename compatible string to xlnx,video > > v4l: xilinx: Remove axi- prefix from DT properties > > v4l: xilinx: dma: Give back queued buffers at streamoff time > > --- > > > > .../devicetree/bindings/media/xilinx/video.txt | 52 ++ > > .../bindings/media/xilinx/xlnx,video.txt | 55 ++ > > MAINTAINERS| 9 + > > drivers/media/platform/Kconfig | 1 + > > drivers/media/platform/Makefile| 2 + > > drivers/media/platform/xilinx/Kconfig | 10 + > > drivers/media/platform/xilinx/Makefile | 3 + > > drivers/media/platform/xilinx/xilinx-dma.c | 770 > > drivers/media/platform/xilinx/xilinx-dma.h | 109 +++ > > drivers/media/platform/xilinx/xilinx-vip.c | 269 +++ > > drivers/media/platform/xilinx/xilinx-vip.h | 227 ++ > > drivers/media/platform/xilinx/xilinx-vipp.c| 669 > > drivers/media/platform/xilinx/xilinx-vipp.h| 49 ++ > > 13 files changed, 2225 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/media/xilinx/video.txt >
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi Paulo, On Wednesday 05 November 2014 10:13:45 Paulo Assis wrote: > 2014-11-04 23:32 GMT+00:00 Sakari Ailus : > > Sakari Ailus wrote: > >> yavta does, for example, print both the monotonic timestamp from the > >> buffer and the time when the buffer has been dequeued: > >> > >> http://git.ideasonboard.org/yavta.git> > >> > >> $ yavta -c /dev/video0 > >> > >> should do it. The first timestamp is the buffer timestamp, and the latter > >> is the one is taken when the buffer is dequeued (by yavta). > > I've done exaclty this with guvcview, and uvcvideo timestamps are completly > unreliable, in some devices they may have just a bit of jitter, but in > others, values go back and forth in time, making them totally unusable. > > Honestly I wouldn't trust device firmware to provide correct timestamps, or > at least I would have the driver perform a couple of tests to make sure > these are at least reasonable: within an expected interval (maybe comparing > it to a reference monotonic clock) or at the very least making sure the > current frame timestamp is not lower than the previous one. I can add that to the uvcvideo driver, but I'd first like to find out whether the device timestamps are really unreliable, or if the problem comes from a bug in the driver's timestamp conversion code. Could you capture images using yavta with an unreliable device, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. > > Removing the uvcvideo module and loading it again with trace=4096 before > > capturing, and then kernel log would provide more useful information. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Hi Rémi, On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: > Le mardi 04 novembre 2014, 15:42:37 Rémi Denis-Courmont a écrit : > > Le 2014-11-04 14:58, Sakari Ailus a écrit : > > >> > Have you tried with a different application to see if the problem > > >> > persists? > > >> > > >> Tried mplayer and cheese now, and it seems they are not affected, so > > >> it's an issue with vlc. I wonder why it doesn't like newer flags.. > > >> > > >> Ohwell, sorry for the noise. > > > > > > I guess the newer VLC could indeed pay attention to the monotonic > > > timestamp flag. Remi, any idea? > > > > VLC takes the kernel timestamp, if monotonic, since version 2.1. > > Otherwise, it generates its own inaccurate timestamp. So either that > > code is wrong, or the kernel timestamps are. > > From a quick check with C920, the timestamps from the kernel are quite > jittery, and but seem to follow a pattern. When requesting a 10 Hz frame > rate, I actually get a frame interval of about 8/9 (i.e. 89ms) jumping to > 1/3 every approximately 2 seconds. > > From my user-space point of view, this is a kernel issue. The problem > probably just manifests when both VLC and Linux versions support monotonic > timestamps. > > Whether the root cause is in the kernel, the device driver or the firmware, > I can´t say. Would you be able to capture images from the C920 using yavta, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/13] v4l: xilinx: Add Xilinx Video IP core
Xilinx platforms have no hardwired video capture or video processing interface. Users create capture and memory to memory processing pipelines in the FPGA fabric to suit their particular needs, by instantiating video IP cores from a large library. The Xilinx Video IP core is a framework that models a video pipeline described in the device tree and expose the pipeline to userspace through the media controller and V4L2 APIs. Signed-off-by: Laurent Pinchart Signed-off-by: Hyun Kwon Signed-off-by: Radhey Shyam Pandey Signed-off-by: Michal Simek --- I'd appreciate if DT reviewers could have a look at the xlnx,video-format and xlnx,video-width properties if nothing else. Changes since v2: - Remove explicit trailing \0 after snprintf - Don't hardcode colorspace Changes since v1: - Remove unnecessary fields from struct xvip_dma_buffer - Fix querycap capabilities and bus_info reporting - Refuse to set format when the queue is busy - Return buffers to vb2 when start_streaming fails - Use vb2 fops and ioctl ops v1 was made of the following individual patches. media: xilinx: vip: Add yuv444 and bayer formats media: xilinx: vip: Remove _TIMING_ from register definition media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback media: xilinx: dma: Fix alignments of xvip_dma_fops definition media: xilinx: dma: Workaround for bytesperline media: xilinx: vip: Add default min/max height/width definitions media: xilinx: vip: Add common sink/source pad IDs media: xilinx: vip: Add xvip_set_format_size() media: xilinx: vip: Add xvip_enum_mbus_code() media: xilinx: vip: Add xvip_enum_frame_size() media: xilinx: vip: Add register clear and set functions media: xilinx: vip: Add xvip_start() media: xilinx: vip: Add xvip_stop() media: xilinx: vip: Add xvip_set_frame_size() media: xilinx: vip: Add enable/disable reg update functions media: xilinx: vip: Add xvip_print_version() media: xilinx: vip: Add xvip_reset() media: xilinx: vip: Add xvip_get_frame_size() media: xilinx: vip: Add suspend/resume helper functions media: xilinx: vip: Change the return value of xvip_get_format_by_code() media: xilinx: vip: Change the return value of xvip_of_get_format() media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() media: xilinx: vipp: Remove of_match_ptr() media: xilinx: vipp: Add control to inherit subdevice controls media: xilinx: Make disconnected video nodes return -EPIPE at stream on media: xilinx: Make links configurable media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity media: xilinx: Rename xvip_pipeline to xvip_composite_device media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* media: xilinx: Rename xvipp_* functions to xvip_composite_* media: xilinx: Move pipeline management code to xilinx-dma.c media: xilinx: Add missing mutex_destroy call media: xilinx: Create xvip_pipeline structure media: xilinx: Support more than two VDMAs in DT media: xilinx: dma: Change vdma configuration to cyclic-mode Revert "media: xilinx: dma: Workaround for bytesperline" media: xilinx: Added DMA error handling media: xilinx: Fix error handling media: xilinx: Reordered mutexes initialization media: xilinx: vipp: Add devicetree bindings documentation media: xilinx: Reordered mutexes initialization media: xilinx: Set format description in enum_fmt media: xilinx: Remove global control handler media: xilinx: dma: Use the interleaved dmaengine API xilinx: Remove .owner field for drivers v4l: xilinx: video: Rename compatible string to xlnx,video v4l: xilinx: Remove axi- prefix from DT properties v4l: xilinx: dma: Give back queued buffers at streamoff time --- .../devicetree/bindings/media/xilinx/video.txt | 52 ++ .../bindings/media/xilinx/xlnx,video.txt | 55 ++ MAINTAINERS| 9 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/xilinx/Kconfig | 10 + drivers/media/platform/xilinx/Makefile | 3 + drivers/media/platform/xilinx/xilinx-dma.c | 769 + drivers/media/platform/xilinx/xilinx-dma.h | 109 +++ drivers/media/platform/xilinx/xilinx-vip.c | 269 +++ drivers/media/platform/xilinx/xilinx-vip.h | 227 ++ drivers/media/platform/xilinx/xilinx-vipp.c| 669 ++ drivers/media/platform/xilinx/xilinx-vipp.h| 49 ++ 13 files changed, 2224 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/xilinx/video.txt create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt create mode 100644 drivers/media/platform/xilinx/Kconfig create mode 100644 drivers/media/platform/xilinx/Makefile create mode 100644 drivers/media/platform/xilinx/xilinx-dma.c create mode 100644 drivers/media/platform/xilinx/xilinx-dma.h create mode 100644 driver
Payment
Dear Recipient, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds. Gloria Peter -- 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
issue with Hauppauge HVR 900
Dear all, please somebody could have a look at https://bugzilla.kernel.org/show_bug.cgi?id=87711 https://bugzilla.kernel.org/show_bug.cgi?id=62911 ? Thanks for interests to everyone, Michal -- 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: v4l2-ctl bug(?) printing ctrl payload array
More on the same topic.
I believe there's another bug on displaying of payload.
Let's say we have the same [45][45] array, and this is what is posted to it:
uint16_t buf[45 * 45] = {0, };
buf[0] = 1;
buf[1] = 2;
buf[45] = 3;
buf[45 * 45 - 1] = 0xff;
What is shown by v4l2-ctl you can see here:
https://dl.dropboxusercontent.com/u/43104344/v4l2-ctl_payload_bug.png
--
Andrey Utkin
--
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] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
which intends to make raising of motion events more "smooth"(?).
It made motion event never appear in my installation.
That code is complicated, so I couldn't figure out quickly how to fix
it, so dropping it seems better to me.
Another justification is that anyway application would implement
"motion signal stabilization" if required, it is not necessarily kernel
driver's job.
Signed-off-by: Andrey Utkin
---
drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-
drivers/media/pci/solo6x10/solo6x10.h | 2 --
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 30e09d9..866f7b3 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
return -EBUSY;
solo_enc->sequence = 0;
- solo_enc->motion_last_state = false;
- solo_enc->frames_since_last_motion = 0;
solo_dev->enc_bw_remain -= solo_enc->bw_weight;
if (solo_enc->type == SOLO_ENC_TYPE_EXT)
@@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
}
if (!ret) {
- bool send_event = false;
-
vb->v4l2_buf.sequence = solo_enc->sequence++;
vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
/* Check for motion flags */
- if (solo_is_motion_on(solo_enc)) {
- /* It takes a few frames for the hardware to detect
-* motion. Once it does it clears the motion detection
-* register and it takes again a few frames before
-* motion is seen. This means in practice that when the
-* motion field is 1, it will go back to 0 for the next
-* frame. This leads to motion detection event being
-* sent all the time, which is not what we want.
-* Instead wait a few frames before deciding that the
-* motion has halted. After some experimentation it
-* turns out that waiting for 5 frames works well.
-*/
- if (enc_buf->motion == 0 &&
- solo_enc->motion_last_state &&
- solo_enc->frames_since_last_motion++ > 5)
- send_event = true;
- else if (enc_buf->motion) {
- solo_enc->frames_since_last_motion = 0;
- send_event = !solo_enc->motion_last_state;
- }
- }
-
- if (send_event) {
+ if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
struct v4l2_event ev = {
.type = V4L2_EVENT_MOTION_DET,
.u.motion_det = {
@@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
},
};
- solo_enc->motion_last_state = enc_buf->motion;
- solo_enc->frames_since_last_motion = 0;
v4l2_event_queue(solo_enc->vfd, &ev);
}
}
diff --git a/drivers/media/pci/solo6x10/solo6x10.h
b/drivers/media/pci/solo6x10/solo6x10.h
index 72017b7..dc503fd 100644
--- a/drivers/media/pci/solo6x10/solo6x10.h
+++ b/drivers/media/pci/solo6x10/solo6x10.h
@@ -159,8 +159,6 @@ struct solo_enc_dev {
u16 motion_thresh;
boolmotion_global;
boolmotion_enabled;
- boolmotion_last_state;
- u8 frames_since_last_motion;
u16 width;
u16 height;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart wrote: > Hi Rémi, > > On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote: >> Le mardi 04 novembre 2014, 15:42:37 Rémi Denis-Courmont a écrit : >> > Le 2014-11-04 14:58, Sakari Ailus a écrit : >> > >> > Have you tried with a different application to see if the problem >> > >> > persists? >> > >> >> > >> Tried mplayer and cheese now, and it seems they are not affected, so >> > >> it's an issue with vlc. I wonder why it doesn't like newer flags.. >> > >> >> > >> Ohwell, sorry for the noise. >> > > >> > > I guess the newer VLC could indeed pay attention to the monotonic >> > > timestamp flag. Remi, any idea? >> > >> > VLC takes the kernel timestamp, if monotonic, since version 2.1. >> > Otherwise, it generates its own inaccurate timestamp. So either that >> > code is wrong, or the kernel timestamps are. >> >> From a quick check with C920, the timestamps from the kernel are quite >> jittery, and but seem to follow a pattern. When requesting a 10 Hz frame >> rate, I actually get a frame interval of about 8/9 (i.e. 89ms) jumping to >> 1/3 every approximately 2 seconds. >> >> From my user-space point of view, this is a kernel issue. The problem >> probably just manifests when both VLC and Linux versions support monotonic >> timestamps. >> >> Whether the root cause is in the kernel, the device driver or the firmware, >> I can´t say. > > Would you be able to capture images from the C920 using yavta, with the > uvcvideo trace parameter set to 4096, and send me both the yavta log and the > kernel log ? Let's start with a capture sequence of 50 to 100 images. I've done 2 captures, if that helps: http://notaz.gp2x.de/tmp/c920_yavta/ The second one was done using low exposure setting, which allows camera to achieve higher frame rate. -- Gražvydas -- 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: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Laurent, see below yavta output and matching syslog ./yavta -c -s 800x600 -t 1/30 -f mjpeg /dev/video0 Device /dev/video0 opened. Device `Logitech Webcam C930e' on `usb-:00:1a.7-1' is a video output (without mplanes) device. Video format set: MJPEG (47504a4d) 800x600 (stride 0) field none buffer size 96 Video format: MJPEG (47504a4d) 800x600 (stride 0) field none buffer size 96 Current frame rate: 1/30 Setting frame rate to: 1/30 Frame rate set: 1/30 8 buffers requested. length: 96 offset: 0 timestamp type/source: mono/SoE Buffer 0/0 mapped at address 0x7fa53d2a9000. length: 96 offset: 962560 timestamp type/source: mono/SoE Buffer 1/0 mapped at address 0x7fa53c8d6000. length: 96 offset: 1925120 timestamp type/source: mono/SoE Buffer 2/0 mapped at address 0x7fa53c7eb000. length: 96 offset: 2887680 timestamp type/source: mono/SoE Buffer 3/0 mapped at address 0x7fa53c70. length: 96 offset: 3850240 timestamp type/source: mono/SoE Buffer 4/0 mapped at address 0x7fa53c615000. length: 96 offset: 4812800 timestamp type/source: mono/SoE Buffer 5/0 mapped at address 0x7fa53c52a000. length: 96 offset: 5775360 timestamp type/source: mono/SoE Buffer 6/0 mapped at address 0x7fa53c43f000. length: 96 offset: 6737920 timestamp type/source: mono/SoE Buffer 7/0 mapped at address 0x7fa53c354000. 0 (0) [-] any 0 78126 B 1967.041984 1967.046007 199.243 fps ts mono/SoE 1 (1) [-] any 1 83867 B 1967.065982 1967.074017 41.670 fps ts mono/SoE 2 (2) [-] any 2 83019 B 1967.157974 1967.166002 10.871 fps ts mono/SoE 3 (3) [-] any 3 83772 B 1967.249978 1967.258003 10.869 fps ts mono/SoE 4 (4) [-] any 4 83973 B 1967.341976 1967.350002 10.870 fps ts mono/SoE 5 (5) [-] any 5 81903 B 1967.433974 1967.441996 10.870 fps ts mono/SoE 6 (6) [-] any 6 83112 B 1967.497976 1967.506003 15.625 fps ts mono/SoE 7 (7) [-] any 7 80714 B 1967.565975 1967.573998 14.706 fps ts mono/SoE 8 (0) [-] any 8 81568 B 1967.633973 1967.641990 14.706 fps ts mono/SoE 9 (1) [-] any 9 80797 B 1967.697971 1967.705999 15.625 fps ts mono/SoE 10 (2) [-] any 10 81242 B 1967.765972 1967.773996 14.706 fps ts mono/SoE 11 (3) [-] any 11 79881 B 1967.833971 1967.841984 14.706 fps ts mono/SoE 12 (4) [-] any 12 77947 B 1967.897969 1967.905998 15.625 fps ts mono/SoE 13 (5) [-] any 13 75779 B 1967.965969 1967.973987 14.706 fps ts mono/SoE 14 (6) [-] any 14 73720 B 1968.029969 1968.038008 15.625 fps ts mono/SoE 15 (7) [-] any 15 73671 B 1968.097969 1968.105995 14.706 fps ts mono/SoE 16 (0) [-] any 16 80507 B 1968.165969 1968.173989 14.706 fps ts mono/SoE 17 (1) [-] any 17 82505 B 1968.229969 1968.237999 15.625 fps ts mono/SoE 18 (2) [-] any 18 82640 B 1968.297966 1968.305990 14.707 fps ts mono/SoE 19 (3) [-] any 19 82676 B 1968.365969 1968.373987 14.705 fps ts mono/SoE 20 (4) [-] any 20 82802 B 1968.429967 1968.437996 15.625 fps ts mono/SoE 21 (5) [-] any 21 83523 B 1968.497967 1968.505992 14.706 fps ts mono/SoE 22 (6) [-] any 22 83774 B 1968.565964 1968.573980 14.707 fps ts mono/SoE 23 (7) [-] any 23 83678 B 1968.629966 1968.637992 15.625 fps ts mono/SoE 24 (0) [-] any 24 83627 B 1968.697964 1968.705985 14.706 fps ts mono/SoE 25 (1) [-] any 25 83675 B 1968.761965 1968.773978 15.625 fps ts mono/SoE 26 (2) [-] any 26 84022 B 1968.829965 1968.837991 14.706 fps ts mono/SoE 27 (3) [-] any 27 83861 B 1968.897963 1968.905984 14.706 fps ts mono/SoE 28 (4) [-] any 28 83859 B 1968.961962 1968.969995 15.625 fps ts mono/SoE 29 (5) [-] any 29 84127 B 1969.029964 1969.037988 14.705 fps ts mono/SoE 30 (6) [-] any 30 83975 B 1969.097963 1969.105980 14.706 fps ts mono/SoE 31 (7) [-] any 31 83942 B 1968.705930 1969.170007 -2.551 fps ts mono/SoE 32 (0) [-] any 32 84151 B 1966.942496 1969.238004 -0.567 fps ts mono/SoE 33 (1) [-] any 33 84063 B 1966.407386 1969.305995 -1.869 fps ts mono/SoE 34 (2) [-] any 34 83821 B 6363.417588 1969.370002 0.000 fps ts mono/SoE 35 (3) [-] any 35 83856 B 8999.957765 1969.437996 0.000 fps ts mono/SoE 36 (4) [-] any 36 83654 B 25405.275813 1969.505986 0.000 fps ts mono/SoE 37 (5) [-] any 37 83619 B 19546.239569 1969.570001 -0.000 fps ts mono/SoE 38 (6) [-] any 38 83257 B 19546.049575 1969.637995 -5.263 fps ts mono/SoE 39 (7) [-] any 39 83211 B 25405.475806 1969.702002 0.000 fps ts mono/SoE 40 (0) [-] any 40 83231 B 19546.310550 1969.769993 -0.000 fps ts mono/SoE 41 (1) [-] any 41 83172 B 19546.249539 1969.837989 -16.390 fps ts mono/SoE 42 (2) [-] any 42 83177 B 25405.504127 1969.901997 0.000 fps ts mono/SoE 43 (3) [-] any 43 83055 B 19546.510529 1969.969995 -0.000 fps ts mono/SoE 44 (4) [-] any 44 82520 B 19546.320540 1970.037985 -5.263 fps ts mono/SoE 45 (5) [-] any 45 80593 B 19546.771538 1970.101999 2.217 fps ts mono/SoE 46 (6) [-] any 46 77431 B 19546.710555 1970.169986 -16.398 fps ts mono/SoE 47 (7) [-] any 47 75963 B 25406.007835 1970.233994 0.000 fps ts mono/SoE 48 (0) [-] any 48 74591 B 19546.971544 1970.301993 -0.000 fps ts mono/SoE 49 (1) [-] any 49 74606 B 19546.781526 1970.369988 -5.263 fps ts mono/SoE 50 (2) [-] an
Re: [PATCH 1/3] cx23885: add DVBSky S950 support
Reviewed-by: Antti Palosaari
...but I really expect Olli did the better job. I simply don't know that
driver internals well enough. Patch looks 100% fine for my eyes.
regards
Antti
On 11/05/2014 04:58 PM, Nibble Max wrote:
DVBSky S950 dvb-s/s2 PCIe card:
1>dvb frontend: M88TS2022(tuner),M88DS3103(demod)
2>PCIe bridge: cx23885
3>rc: cx23885 integrated.
Signed-off-by: Nibble Max
---
drivers/media/pci/cx23885/cx23885-cards.c | 20
drivers/media/pci/cx23885/cx23885-dvb.c | 9 ++---
drivers/media/pci/cx23885/cx23885-input.c | 3 +++
drivers/media/pci/cx23885/cx23885.h | 1 +
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 9c7e8ac..4b9cb07 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -692,6 +692,10 @@ struct cx23885_board cx23885_boards[] = {
.name = "Technotrend TT-budget CT2-4500 CI",
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_DVBSKY_S950] = {
+ .name = "DVBSky S950",
+ .portb = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -963,6 +967,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x13c2,
.subdevice = 0x3013,
.card = CX23885_BOARD_TT_CT2_4500_CI,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0950,
+ .card = CX23885_BOARD_DVBSKY_S950,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1597,6 +1605,13 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
/* enable irq */
cx_write(GPIO_ISM, 0x); /* INTERRUPTS active low */
+ break;
+ case CX23885_BOARD_DVBSKY_S950:
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_clear(dev, GPIO_2);
+ msleep(100);
+ cx23885_gpio_set(dev, GPIO_2);
+ break;
}
}
@@ -1681,6 +1696,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
if (!enable_885_ir)
break;
dev->sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1731,6 +1747,7 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
cx23885_irq_remove(dev, PCI_MSK_AV_CORE);
/* sd_ir is a duplicate pointer to the AV Core, just clear it */
dev->sd_ir = NULL;
@@ -1782,6 +1799,7 @@ void cx23885_ir_pci_int_enable(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
if (dev->sd_ir)
cx23885_irq_add_enable(dev, PCI_MSK_AV_CORE);
break;
@@ -1888,6 +1906,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
ts1->gen_ctrl_val = 0x5; /* Parallel */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
@@ -2009,6 +2028,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_T980C:
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
+ case CX23885_BOARD_DVBSKY_S950:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 9da5cf3..3410ab8 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1672,6 +1672,7 @@ static int dvb_register(struct cx23885_tsport *port)
}
break;
case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S950:
i2c_bus = &dev->i2c_bus[0];
i2c_bus2 = &dev->i2c_bus[1];
switch (port->nr) {
@@ -1922,7 +1923,8 @@ static int dvb_register(struct cx23885_tsport *port)
memcpy(port->frontends.adapter.proposed_mac, eeprom + 0xa0, 6);
break;
}
- case CX23885_BOARD_DVBSKY_T9580: {
+ ca
Re: [PATCH 2/3] cx23885: add DVBSky S952 support
Reviewed-by: Antti Palosaari
Patch looks correct for my eyes, but I am not professional here, so lets
Olli make final decision.
regards
Antti
On 11/05/2014 04:58 PM, Nibble Max wrote:
DVBSky S952 dvb-s/s2 dual PCIe card:
1>dvb frontend: M88TS2022(tuner),M88DS3103(demod)
2>PCIe bridge: CX23885(port b: parallel mode, port c: serial mode)
3>rc: cx23885 integrated.
Signed-off-by: Nibble Max
---
drivers/media/pci/cx23885/cx23885-cards.c | 22 +++
drivers/media/pci/cx23885/cx23885-dvb.c | 99 ++-
drivers/media/pci/cx23885/cx23885-input.c | 3 +
drivers/media/pci/cx23885/cx23885.h | 1 +
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 4b9cb07..4bad27d 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -696,6 +696,11 @@ struct cx23885_board cx23885_boards[] = {
.name = "DVBSky S950",
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_DVBSKY_S952] = {
+ .name = "DVBSky S952",
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -971,6 +976,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x4254,
.subdevice = 0x0950,
.card = CX23885_BOARD_DVBSKY_S950,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0952,
+ .card = CX23885_BOARD_DVBSKY_S952,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1566,6 +1575,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
mdelay(60);
break;
case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S952:
/* enable GPIO3-18 pins */
cx_write(MC417_CTL, 0x0037);
cx23885_gpio_enable(dev, GPIO_2 | GPIO_11, 1);
@@ -1697,6 +1707,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
if (!enable_885_ir)
break;
dev->sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1748,6 +1759,7 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
cx23885_irq_remove(dev, PCI_MSK_AV_CORE);
/* sd_ir is a duplicate pointer to the AV Core, just clear it */
dev->sd_ir = NULL;
@@ -1800,6 +1812,7 @@ void cx23885_ir_pci_int_enable(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
if (dev->sd_ir)
cx23885_irq_add_enable(dev, PCI_MSK_AV_CORE);
break;
@@ -1962,6 +1975,14 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+ case CX23885_BOARD_DVBSKY_S952:
+ ts1->gen_ctrl_val = 0x5; /* Parallel */
+ ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ ts2->gen_ctrl_val = 0xe; /* Serial bus */
+ ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
@@ -2029,6 +2050,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S950C:
case CX23885_BOARD_TT_CT2_4500_CI:
case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 3410ab8..2457b64 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -617,6 +617,32 @@ static int dvbsky_t9580_set_voltage(struct dvb_frontend
*fe,
return 0;
}
+static int dvbsky_s952_portc_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
+{
Re: [PATCH 3/3] m88ds3103: change ts clock config for serial mode
Reviewed-by: Antti Palosaari
Antti
On 11/05/2014 04:59 PM, Nibble Max wrote:
1> When m88ds3103 works in serial ts mode, its serial ts clock is equal to ts
master clock and the clock divider is bypassed.
2> The serial ts clock is configed by the bridge driver just like parallel ts
clock.
Signed-off-by: Nibble Max
---
drivers/media/dvb-frontends/m88ds3103.c | 55 +++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index 621d20f..0cd445c 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -245,9 +245,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret, len;
const struct m88ds3103_reg_val *init;
- u8 u8tmp, u8tmp1, u8tmp2;
+ u8 u8tmp, u8tmp1 = 0, u8tmp2 = 0; /* silence compiler warning */
u8 buf[3];
- u16 u16tmp, divide_ratio;
+ u16 u16tmp, divide_ratio = 0;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
@@ -319,32 +319,29 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
/* set M88DS3103 mclk and ts mclk. */
priv->mclk_khz = 96000;
- if (c->delivery_system == SYS_DVBS)
- target_mclk = 96000;
- else {
- switch (priv->cfg->ts_mode) {
- case M88DS3103_TS_SERIAL:
- case M88DS3103_TS_SERIAL_D7:
- if (c->symbol_rate < 1800)
- target_mclk = 96000;
- else
- target_mclk = 144000;
- break;
- case M88DS3103_TS_PARALLEL:
- case M88DS3103_TS_CI:
+ switch (priv->cfg->ts_mode) {
+ case M88DS3103_TS_SERIAL:
+ case M88DS3103_TS_SERIAL_D7:
+ target_mclk = priv->cfg->ts_clk;
+ break;
+ case M88DS3103_TS_PARALLEL:
+ case M88DS3103_TS_CI:
+ if (c->delivery_system == SYS_DVBS)
+ target_mclk = 96000;
+ else {
if (c->symbol_rate < 1800)
target_mclk = 96000;
else if (c->symbol_rate < 2800)
target_mclk = 144000;
else
target_mclk = 192000;
- break;
- default:
- dev_dbg(&priv->i2c->dev, "%s: invalid
ts_mode\n",
- __func__);
- ret = -EINVAL;
- goto err;
}
+ break;
+ default:
+ dev_dbg(&priv->i2c->dev, "%s: invalid ts_mode\n",
+ __func__);
+ ret = -EINVAL;
+ goto err;
}
switch (target_mclk) {
@@ -434,7 +431,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
- u8tmp1 = 0; /* silence compiler warning */
switch (priv->cfg->ts_mode) {
case M88DS3103_TS_SERIAL:
u8tmp1 = 0x00;
@@ -470,16 +466,15 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
ret = m88ds3103_wr_reg_mask(priv, 0x29, u8tmp1, 0x20);
if (ret)
goto err;
- }
-
- if (priv->cfg->ts_clk) {
- divide_ratio = DIV_ROUND_UP(target_mclk, priv->cfg->ts_clk);
- u8tmp1 = divide_ratio / 2;
- u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
- } else {
- divide_ratio = 0;
u8tmp1 = 0;
u8tmp2 = 0;
+ break;
+ default:
+ if (priv->cfg->ts_clk) {
+ divide_ratio = DIV_ROUND_UP(target_mclk,
priv->cfg->ts_clk);
+ u8tmp1 = divide_ratio / 2;
+ u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
+ }
}
dev_dbg(&priv->i2c->dev,
--
http://palosaari.fi/
--
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 11/13] v4l: xilinx: Add Xilinx Video IP core
Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Wednesday, November 05, 2014 10:36 AM > To: linux-media@vger.kernel.org > Cc: Michal Simek; Chris Kohn; Hyun Kwon; devicet...@vger.kernel.org > Subject: [PATCH v3 11/13] v4l: xilinx: Add Xilinx Video IP core > > Xilinx platforms have no hardwired video capture or video processing > interface. Users create capture and memory to memory processing > pipelines in the FPGA fabric to suit their particular needs, by > instantiating video IP cores from a large library. > > The Xilinx Video IP core is a framework that models a video pipeline > described in the device tree and expose the pipeline to userspace > through the media controller and V4L2 APIs. > > Signed-off-by: Laurent Pinchart > Signed-off-by: Hyun Kwon > Signed-off-by: Radhey Shyam Pandey > Signed-off-by: Michal Simek > > --- > > I'd appreciate if DT reviewers could have a look at the xlnx,video-format and > xlnx,video-width properties if nothing else. > > Changes since v2: > > - Remove explicit trailing \0 after snprintf > - Don't hardcode colorspace I've split these two up based on the individual patches in the tree you pointed me to yesterday. The first one I squashed into v4l: xilinx: dma: Fix querycap capabilities and bus_info reporting for the colorspace I created a new patch. I don't want to take credit for it, so if you can send me a patch I'll apply it to my local branch. Other than that, it's working fine on my end. Cheers, Chris This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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: OK
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 6 04:00:16 CET 2014 git branch: test git hash: 4895cc47a072dcb32d3300d0a46a251a8c6db5f1 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: host hardware: x86_64 host os:3.17-2.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: 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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: OK apps: OK spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx: Hauppauge HVR 900 on 3.18.0-rc3
Hi,
analog TV on Hauppauge HVR 900 [2040:6500] - audio works correctly but
video stops after few samples, audio continues after video stop,
tested:
mplayer tv:// -tv
norm=PAL-BG:freq=687.5:input=0:device=/dev/video0:alsa:amode=1:adevice=hw.2,0:audiorate=48000:forceaudio:immediatemode=0
-hardframedrop -ao alsa -vo x11
mplayer output:
MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing tv://.
TV file format detected.
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski
comment: first try, more to come ;-)
Selected device: Hauppauge WinTV HVR 900
Tuner cap:
Tuner rxs:
Capabilities: video capture VBI capture device tuner audio
read/write streaming
supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR;
4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK;
10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; 15 =
SECAM-B; 16 = SECAM-G; 17 = SECAM-H; 18 = SECAM-DK; 19 = SECAM-L; 20 =
SECAM-Lc;
inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
Current input: 0
Current format: YUYV
v4l2: current audio mode is : STEREO
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
==
Opening video decoder: [raw] RAW Uncompressed Video
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is undefined - no prescaling applied.
[swscaler @ 0x13c7d40] BICUBIC scaler, from yuyv422 to bgra using MMX2
VO: [x11] 720x576 => 720x576 BGRA
Selected video codec: [rawyuy2] vfm: raw (RAW YUY2)
==
==
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
A: 3.1 V: 1.6 A-V: 1.447 ct: 0.165 92/ 92 0% 8% 28.8% 50 0
Your system is too SLOW to play this!
Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.
- Slow video output
- Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
- Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
- Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
- Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
- Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.
A: 11.7 V: 5.1 A-V: 6.636 ct: 0.250 308/308 0% 2% 12.9% 266 0
v4l2: 310 frames successfully processed, 0 frames dropped.
kernel output:
[ 427.441405] usb 3-13.5.5: new high-speed USB device number 9 using xhci_hcd
[ 427.534116] usb 3-13.5.5: New USB device found, idVendor=2040, idProduct=6500
[ 427.534126] usb 3-13.5.5: New USB device strings: Mfr=0, Product=1,
SerialNumber=2
[ 427.534131] usb 3-13.5.5: Product: WinTV HVR-900
[ 427.534136] usb 3-13.5.5: SerialNumber: 4026875858
[ 427.586621] media: Linux media interface: v0.10
[ 427.625926] Linux video capture interface: v2.00
[ 427.669943] em28xx: New device WinTV HVR-900 @ 480 Mbps
(2040:6500, interface 0, class 0)
[ 427.669945] em28xx: Video interface 0 found: isoc
[ 427.669946] em28xx: DVB interface 0 found: isoc
[ 427.669973] em28xx: chip ID is em2882/3
[ 427.838493] em2882/3 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x43a734dd
[ 427.838499] em2882/3 #0: EEPROM info:
[ 427.838503] em2882/3 #0: AC97 audio (5 sample rates)
[ 427.838506] em2882/3 #0: 500mA max power
[ 427.838510] em2882/3 #0: Table at offset 0x24, strings=0x1e82,
0x186a, 0x
[ 427.838515] em2882/3 #0: Identified as Hauppauge WinTV HVR 900 (card=10)
[ 427.840708] tveeprom 7-0050: Hauppauge model 65008, rev A1C0, serial# 344018
[ 427.840714] tveeprom 7-0050: tuner model is Xceive XC3028 (idx 120, type 71)
[ 427.840719] tveeprom 7-0050: TV standards PAL(B/G) PAL(I)
PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xd4)
[ 427.840722] tveeprom 7-0050: audio processor is None (idx 0)
[ 427.840725] tveeprom 7-0050: has radio
[ 427.840727]
