Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On 02/18/2015 11:47 PM, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write Here it should be 'read only', to be fixed. + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? Yes. What prevents space or dot in led name? Space can be forbidden by defining naming convention. The name comes from the DT binding 'label' property and I don't see any problem in forbidding space in it. A dot in the name does not introduce parsing problems - simply the first dot after digits separates led id from led name. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] mn88472: reduce firmware download chunk size
It seems that currently the firmware download on the mn88472 is
somehow wrong for my Astrometa HD-901T2.
Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2
makes the firmware download consistently succeed.
Any larger value causes the download to always fail:
[7.671482] mn88472 7-0018: downloading firmware from file
'dvb-demod-mn88472-02.fw'
[8.206960] mn88472 7-0018: firmware download failed=-32
[8.208610] rtl2832 7-0010: i2c reg write failed -32
[8.208620] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83
[8.210459] rtl2832 7-0010: i2c reg write failed -32
[8.212038] rtl2832 7-0010: i2c reg write failed -32
I'm obviously not too happy about this patch as it slows down the
firmware download but I have not found a way to keep larger chunks in
place and have a working firmware download at the same time.
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index d88f799..3c5c6f9 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -865,7 +865,7 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
struct mn88472_config mn88472_config = {};
mn88472_config.fe = adap-fe[1];
- mn88472_config.i2c_wr_max = 22,
+ mn88472_config.i2c_wr_max = 2,
strlcpy(info.type, mn88472, I2C_NAME_SIZE);
mn88472_config.xtal = 2050;
info.addr = 0x18;
--
2.0.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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. -- 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: [RFC PATCH] mn88472: reduce firmware download chunk size
On 02/19/2015 08:42 PM, Antti Seppälä wrote: On 19 February 2015 at 18:14, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 06:01 PM, Antti Seppälä wrote: On 19 February 2015 at 17:38, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 12:21 PM, Antti Seppälä wrote: On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Could you disable whole IR polling and test modprobe dvb_usb_v2 disable_rc_polling=1 It is funny that *increasing* RC polling makes things better, though... Hi. I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? IR polling does not use I2C but some own commands. Could you make more tests. Use rtl28xxu module parameter to disable IR and test. It will disable both IR interrupts and polling. Then make some tests with different IR polling intervals to see how it behaves. Hi Antti. I made some further tests for you. Here are the results: dvb_usb_v2 disable_rc_polling=1: firmware download FAILED dvb_usb_rtl28xxu disable_rc=1: firmware download FAILED Then I restored the module parameters to default values and tested with various rc-interval values: interval = 800: firmware download FAILED interval = 600: firmware download FAILED interval = 400: firmware download FAILED interval = 300: firmware download SUCCESS but I2C errors from tuner could be sometimes observed interval = 200: firmware download SUCCESS interval = 100: firmware download SUCCESS So somehow higher rc polling rate makes the firmware download succeed. This could indeed be some locking/timing related bug. Please let me know if there is something else I can test. Sure you could do. Play with I2C settings. Test few values to I2C bus speed / clock is good start. Put oscilloscope to I2C bus and look what there happens on error cases. There is also 2 different I2C commands, test if there is any difference. And so. Increasing polling interval to something between 250-300 does not sound very bad, though. regards Antti -- 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: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
Em Wed, 18 Feb 2015 22:48:04 +
Lad, Prabhakar prabhakar.cse...@gmail.com escreveu:
Hi Mauro,
Thanks for the patch.
Thanks for the review.
On Fri, Feb 13, 2015 at 10:57 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
Instead of keeping the media controller entity not initialized,
fill it and create the pads for cx25840.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index 573e08826b9b..bdb5bb6b58da 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client,
int default_volume;
u32 id;
u16 device_id;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int ret;
+#endif
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client-adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
@@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client,
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, cx25840_ops);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ /* TODO: need to represent analog inputs too */
+ state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */
+ state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */
+ state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */
Macros for 0,1,2 would make it more readable.
I was in doubt, on weather use a macro or not for it. I ended by
deciding to not use because the code shouldn't assume a particular order
for the pads. Also, I'm not sure if is there a way to taint a PAD for
VBI or Video, or if it is worth or not do do it.
So, the comments there are more a reminder than anything else.
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+
+ ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
+ state-pads, 0);
+ if (ret 0) {
+ v4l_info(client, failed to initialize media entity!\n);
+ kfree(state);
not needed as state is allocated using devm_kzalloc()
+ return -ENODEV;
return ret instead ?
Yeah, both comments make sense. I'll write a patch changing it.
+ }
+#endif
switch (id) {
case CX23885_AV:
diff --git a/drivers/media/i2c/cx25840/cx25840-core.h
b/drivers/media/i2c/cx25840/cx25840-core.h
index 37bc04217c44..17b409f55445 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.h
+++ b/drivers/media/i2c/cx25840/cx25840-core.h
@@ -64,6 +64,9 @@ struct cx25840_state {
wait_queue_head_t fw_wait;/* wake up when the fw load is
finished */
struct work_struct fw_work; /* work entry for fw load */
struct cx25840_ir_state *ir_state;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpads[3];
Macro for 3 ?
Not much sense, as this is used only here. Ok, if we're adding an
enum (or defines) for the pads, then it makes sense to have an alias
for the number of pads.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] cx25840: fix return logic when media entity init fails
There's no need to free state, as it was allocated via devm_kzalloc().
Also, let's return the error code, instead of something else.
Reported-by: Prabhakar Lad prabhakar.cse...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
drivers/media/i2c/cx25840/cx25840-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index cb4e03de9b75..185cb55253c9 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5205,8 +5205,7 @@ static int cx25840_probe(struct i2c_client *client,
state-pads, 0);
if (ret 0) {
v4l_info(client, failed to initialize media entity!\n);
- kfree(state);
- return -ENODEV;
+ return ret;
}
#endif
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] [media] dvb core: rename the media controller entities
Em Wed, 18 Feb 2015 16:37:38 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, On 02/18/2015 04:29 PM, Mauro Carvalho Chehab wrote: Prefix all DVB media controller entities with dvb- and use dash instead of underline at the names. Requested-by: Hans Verkuil hverk...@xs4all.nl ^^ For these foo-by lines please keep my hans.verk...@cisco.com email. It's my way of thanking Cisco for allowing me to do this work. Not a big deal, but if you can change that before committing? Acked-by: Hans Verkuil hans.verk...@cisco.com Sure, I'll run a git filter-branch -f --msg-filter 'cat |sed s,hverk...@xs4all.nl,hans.verk...@cisco.com,' origin.. To replace the e-mail on this series. Next time, it would be better if you could reply using your @cisco email on your From: if you want me to use it, as I generally just cut-and-paste whatever e-mail used at the replies ;) Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] media mini-summit on March, 26 in San Jose together with ELC
As discussed on our IRC #v4l channels and on the media ML, most of the core developers will be again this year in San Jose - CA - USA for the Embedded Linux Conference. There are several subjects that we've been discussing those days that require a face to face meeting. So, We'll be doing a media mini-summit on March, 26 (Thursday) at the Marriott San Jose. This time, Linux Foundation will be handling the subscriptions for the event, via their registering site: https://www.regonline.com/register/login.aspx?eventID=1623927MethodId=0EventsessionId= So, you need to register for an add-on option as shown below: [ ] Linux Media Summit: Please click here if you would like to attend Linux Media Summit. Media Summit is the premier forum to discuss the Linux multimedia development for webcams, audio and video streaming devices and analog/digital TV support at the Linux Kernel and its userspace APIs. Date: Thursday, March 26, 2015 9:00 AM - 6:00 PM (Pacific Time) If you're already subscribed to the event, you can login using the same URL, select your register and register for the Media Summit. I hope to see you there! Ah, as usual, we'll be using the media-works...@linuxtv.org ML for specific discussions about that, so the ones interested on participate are requested to subscribe it, and to submit themes of interest to the mailing lists. Regards! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] media mini-summit on March, 26 in San Jose together with ELC
Em Thu, 19 Feb 2015 18:05:25 -0200 Mauro Carvalho Chehab m.che...@samsung.com escreveu: As discussed on our IRC #v4l channels and on the media ML, most of the core developers will be again this year in San Jose - CA - USA for the Embedded Linux Conference. There are several subjects that we've been discussing those days that require a face to face meeting. So, We'll be doing a media mini-summit on March, 26 (Thursday) at the Marriott San Jose. This time, Linux Foundation will be handling the subscriptions for the event, via their registering site: https://www.regonline.com/register/login.aspx?eventID=1623927MethodId=0EventsessionId= So, you need to register for an add-on option as shown below: [ ] Linux Media Summit: Please click here if you would like to attend Linux Media Summit. Media Summit is the premier forum to discuss the Linux multimedia development for webcams, audio and video streaming devices and analog/digital TV support at the Linux Kernel and its userspace APIs. Date: Thursday, March 26, 2015 9:00 AM - 6:00 PM (Pacific Time) If you're already subscribed to the event, you can login using the same URL, select your register and register for the Media Summit. Forgot to mention, but if if you are already subscribed at the ELC, please also go to the personal information on your registration, as there are two additional information there that are related to the Linux Media Summit. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors
On 2014-12-06 01:25, Benjamin Larsson wrote: The Astrometa device has issues with i2c transfers. Lowering the poll time somehow makes these errors disappear. Signed-off-by: Benjamin Larsson benja...@southpole.se --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 705c6c3..9ec4223 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -1567,7 +1567,7 @@ static int rtl2832u_get_rc_config(struct dvb_usb_device *d, rc-allowed_protos = RC_BIT_ALL; rc-driver_type = RC_DRIVER_IR_RAW; rc-query = rtl2832u_rc_query; - rc-interval = 400; + rc-interval = 200; return 0; } Ping, can I get an ack or nack on this ? MvH Benjamin Larsson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 2015-02-19 11:21, Antti Seppälä wrote:
On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote:
On 2015-02-19 10:13, Antti Seppälä wrote:
It seems that currently the firmware download on the mn88472 is
somehow wrong for my Astrometa HD-901T2.
Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2
makes the firmware download consistently succeed.
Hi, try adding the workaround patch I sent for this.
[PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors
I now see that it hasn't been merged. But I have been running with this
patch for a few months now without any major issues.
The patch really did improve firmware loading. Weird...
Even with it I still get occasional i2c errors from r820t:
[ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da
[ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00
len=4: 69 74 e6 df
[ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00
len=4: 69 74 e6 df
These errors seem to appear more often if I'm reading the signal
strength values using e.g. femon.
Br,
-Antti
This patch implements a retry logic. If a transfer fails it will convert
it to 1 byte transfers. This will not work when loading the nm88472
firmware as everything is loaded through the 0xf6 register.
I think we might need something like this to get the Astrometa working
reliably.
Based on usb logs from the windows driver one can see that they only
send 1 byte at a time so they can retry all transfers. So this issue
seems to be related to the rtl2832p bridge chip and how much i2c traffic
is generated.
MvH
Benjamin Larsson
From 5962cf8fafdfe98138fd69beb4d0b5d2a7af5732 Mon Sep 17 00:00:00 2001
From: Benjamin Larsson benja...@southpole.se
Date: Thu, 20 Nov 2014 00:50:02 +0100
Subject: [PATCH] rtl28xxu: implement i2c transfer retry logic
Cc: Linux Media Mailing List linux-media@vger.kernel.org
This is needed for Astrometa hardware. Retry counts up to 6 has been
observered before the i2c transfer succeded.
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 4af8a61..4d321ae 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -185,6 +185,8 @@ static int rtl28xxu_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
struct dvb_usb_device *d = i2c_get_adapdata(adap);
struct rtl28xxu_priv *priv = d-priv;
struct rtl28xxu_req req;
+ u8 rb_buf[2];
+ int i, retry_cnt;
/*
* It is not known which are real I2C bus xfer limits, but testing
@@ -273,6 +275,33 @@ static int rtl28xxu_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
req.size = msg[0].len-1;
req.data = msg[0].buf[1];
ret = rtl28xxu_ctrl_msg(d, req);
+
+ /* Astrometa hardware needs a retry for some failed transfers.
+ * Just send one byte at the time.
+ * Retry max 10 times for each transfer.
+ */
+ if (ret) {
+req.size = 1;
+req.data = rb_buf;
+
+dev_dbg(d-udev-dev, %s: transfer of %d bytes failed\n, __func__, msg[0].len-1);
+rb_buf[0] = msg[0].buf[0];
+
+for (i=0 ; imsg[0].len-1 ; i++) {
+ retry_cnt = 0;
+ req.value = ((msg[0].buf[0]+i) 8) | (msg[0].addr 1);
+ rb_buf[0] = msg[0].buf[i+1];
+
+ do {
+ dev_dbg(d-udev-dev, %s: byte: %d retry: %d\n, __func__, i, retry_cnt);
+ ret = rtl28xxu_ctrl_msg(d, req);
+ retry_cnt++;
+ if (retry_cnt 10)
+ goto err_mutex_unlock;
+
+ } while (ret);
+}
+ }
} else {
/* method 3 - new I2C */
req.value = (msg[0].addr 1);
--
1.9.1
[PATCH v3 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 15 +--
include/media/videobuf2-core.h | 16
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..62531956 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3029,11 +3032,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
* Queue next buffer if required.
*/
if (buf-pos == buf-size ||
- (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ (!read (fileio-write_immediately))) {
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
+ if (read (fileio-read_once)
fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..1346693 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -347,6 +336,7 @@ struct v4l2_fh;
* @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes: supported io methods (see vb2_io_modes enum)
* @io_flags: additional io flags (see vb2_fileio_flags enum)
+ * XXX
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 29 +++--
include/media/videobuf2-core.h |1 +
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 62531956..487e31f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1276,13 +1276,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+*
+* Some drivers, e.g. old codec drivers, use bytesused
+* == 0 as a way to indicate that streaming is finished.
+* In that case, the driver should use the
+* allow_zero_bytesused flag to keep old userspace
+* applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1304,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+*
+* Some drivers, e.g. old codec drivers, use bytesused * == 0 as
+* a way to indicate that streaming is finished. In that case,
+* the driver should use the allow_zero_bytesused flag to keep
+* old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1320,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
+ else
+ v4l2_planes[0].bytesused = b-bytesused ?
+ b-bytesused : v4l2_planes[0].length;
+ } else
v4l2_planes[0].bytesused = 0;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 1346693..50111bd573 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -388,6 +388,7 @@ struct vb2_queue {
unsigned intio_modes;
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
+ unsignedallow_zero_bytesused:1;
struct mutex*lock;
struct v4l2_fh *owner;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..2d23f9a 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq-lock = ctx-dev-dev_mutex; + /* One of means to indicate end-of-stream for coda is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag, so +* that videobuf2 will keep the value of bytesused intact. +*/ + vq-allow_zero_bytesused = 1; return vb2_queue_init(vq); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..6b08488 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One of means to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
On 02/19/15 11:11, Kamil Debski wrote:
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 29 +++--
include/media/videobuf2-core.h |1 +
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 62531956..487e31f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1276,13 +1276,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused
+ * == 0 as a way to indicate that streaming is finished.
+ * In that case, the driver should use the
+ * allow_zero_bytesused flag to keep old userspace
+ * applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1304,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused * == 0 as
+ * a way to indicate that streaming is finished. In that case,
+ * the driver should use the allow_zero_bytesused flag to keep
+ * old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1320,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
+ else
+ v4l2_planes[0].bytesused = b-bytesused ?
+ b-bytesused : v4l2_planes[0].length;
+ } else
v4l2_planes[0].bytesused = 0;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 1346693..50111bd573 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -388,6 +388,7 @@ struct vb2_queue {
unsigned intio_modes;
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
+ unsignedallow_zero_bytesused:1;
Needs to be documentation in the struct vb2_queue comments.
Regards,
Hans
struct mutex*lock;
struct v4l2_fh *owner;
--
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
Re: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote:
This patch adds support for the Vortex 1 PCIe card from Prospero
Technologies Ltd. The Vortex 1 supports up to 8 tuner modules and
currently ships with 8xDibcom 7090p tuners. The card also has raw
infra-red support and a hardware demuxer.
-snip-
diff --git a/drivers/media/pci/prospero/prospero_ir.c
b/drivers/media/pci/prospero/prospero_ir.c
new file mode 100644
index 000..01e5204
--- /dev/null
+++ b/drivers/media/pci/prospero/prospero_ir.c
@@ -0,0 +1,150 @@
+/*
+ * Infra-red driver for PCIe DVB cards from Prospero Technology Ltd.
+ *
+ * Copyright Prospero Technology Ltd. 2014
+ * Written/Maintained by Philip Downer
+ * Contact: pdow...@prospero-tech.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include media/rc-core.h
+#include prospero_ir.h
+
+#define DURATION_MASK 0x7
+#define PULSE_MASK 0x100
+#define FIFO_FILL_MASK 0xFF
+
+#define FIFO_FILL 0x60
+#define FIFO 0x64
+
+struct prospero_IR {
+ struct prospero_device *pdev;
+ struct rc_dev *dev;
+
+ int users;
The users field is never used.
+
+ char name[32];
+ char phys[32];
+};
+
+static int prospero_ir_open(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users++;
+ return 0;
+
+}
+
+static void prospero_ir_close(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users--;
+
+}
Since the users field is never read these functions are unnecessary and
can be removed.
+
+void ir_interrupt(struct prospero_pci *p_pci)
+{
+
+ struct prospero_device *p = p_pci-p_dev;
+ struct prospero_IR *ir = p-ir;
+ struct ir_raw_event ev;
+ int tmp = 0;
+ int fill = 0;
+ int pulse = 0;
+ int duration = 0;
+
+ pr_debug(Infra: Interrupt!\n);
+
+ tmp = ioread32(p_pci-io_mem + FIFO_FILL);
+ fill = tmp FIFO_FILL_MASK;
+
+ init_ir_raw_event(ev);
+
+ while (fill 0) {
+
+ pr_debug(Infra: fifo fill = %d\n, fill);
+
+ tmp = ioread32(p_pci-io_mem + FIFO);
+ pr_debug(Infra: raw dump = 0x%x\n, tmp);
+ pulse = (tmp PULSE_MASK) 24;
+ duration = (tmp DURATION_MASK) * 1000;/* Convert uS
to nS */
+
+ pr_debug(Infra: pulse = %d; duration = %d\n, pulse, duration);
+
+ ev.pulse = pulse;
+ ev.duration = duration;
+ ir_raw_event_store_with_filter(ir-dev, ev);
+ fill--;
+ }
+ ir_raw_event_handle(ir-dev);
+
+}
+
+int prospero_ir_init(struct prospero_device *p)
+{
+
+ struct prospero_pci *p_pci = p-bus_specific;
+ struct pci_dev *pci = p_pci-pcidev;
+ struct prospero_IR *ir;
+ struct rc_dev *dev;
+ int err = -ENOMEM;
+
+ ir = kzalloc(sizeof(*ir), GFP_KERNEL);
+
+ dev = rc_allocate_device();
+
+ if (!ir || !dev)
+ goto err_out_free;
+
+ ir-dev = dev;
+
+ snprintf(ir-name, sizeof(ir-name), prospero IR);
+ snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci));
+
+ dev-input_name = ir-name;
+ dev-input_phys = ir-phys;
+ dev-input_id.bustype = BUS_PCI;
+ dev-input_id.version = 1;
+ dev-input_id.vendor = pci-vendor;
+ dev-input_id.product = pci-device;
+
+ dev-dev.parent = pci-dev;
+ dev-map_name = RC_MAP_LIRC;
+
+ dev-driver_name = prospero;
+ dev-priv = p;
+ dev-open = prospero_ir_open;
+ dev-close = prospero_ir_close;
+ dev-driver_type = RC_DRIVER_IR_RAW;
+ dev-timeout = 10 * 1000 * 1000;
If you know the rx_resolution, please provide it. The lirc interface
can query it.
+
+ iowrite32(0x12000, p_pci-io_mem + FIFO_FILL);
+
+ ir-pdev = p;
+ p-ir = ir;
+
+ err = rc_register_device(dev);
+ if (err)
+ goto err_out_free;
+
+ return 0;
+
+ err_out_free:
+ rc_free_device(dev);
+ p-ir = NULL;
+ kfree(ir);
+ return -ENOMEM;
+
+}
Thanks
Sean
--
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] [media] soc-camera: Remove bogus devm_kfree() in soc_of_bind()
Hi Guennadi,
On Wed, Feb 18, 2015 at 10:16 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Wed, 18 Feb 2015, Sergei Shtylyov wrote:
On 02/18/2015 07:32 PM, Geert Uytterhoeven wrote:
Unlike scan_async_group(), soc_of_bind() doesn't allocate its
soc_camera_async_client structure using devm_kzalloc(), but has it
embedded inside the soc_of_info structure. Hence on failure, it must
not free it using devm_kfree(), as this will cause a warning, and may
cause slab corruption:
[...]
Fixes: 1ddc6a6caa94e1e1 ([media] soc_camera: add support for dt binding
soc_camera drivers)
Cc: sta...@vger.kernel.org
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
Triggered with shmobile-defconfig on r8a7791/koelsch.
---
drivers/media/platform/soc_camera/soc_camera.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index cee7b56f84049944..d8a072fe46035821 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1665,7 +1665,6 @@ eclkreg:
eaddpdev:
platform_device_put(sasc-pdev);
eallocpdev:
- devm_kfree(ici-v4l2_dev.dev, sasc);
Perhaps Ben meant 'info' ISO 'sasc'? This way it would make more sense.
Agree. Geert, could you double-check and respin?
Sergei is right. Will update and resend.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] vb2: split the io_flags member of vb2_queue into a bit field
On 02/19/15 11:11, Kamil Debski wrote:
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 15 +--
include/media/videobuf2-core.h | 16
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..62531956 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3029,11 +3032,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue
*q, char __user *data, size_
* Queue next buffer if required.
*/
if (buf-pos == buf-size ||
-(!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+(!read (fileio-write_immediately))) {
No need for the parenthesis around fileio-write_immediately.
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
+ if (read (fileio-read_once)
Ditto for fileio-read_once.
fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..1346693 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io
emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE:report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY:queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED: buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -347,6 +336,7 @@ struct v4l2_fh;
* @type:queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes:supported io methods (see vb2_io_modes enum)
* @io_flags:additional io flags (see vb2_fileio_flags enum)
io_flags no longer exists.
+ * XXX
Same question as before: XXX
I assume the intention was to replace XXX with the documentation of the
new bitfields which is now lost after removing the enum vb2_fileio_flags.
* @lock:pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
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 v2] [media] soc-camera: Fix devm_kfree() in soc_of_bind()
Unlike scan_async_group(), soc_of_bind() doesn't allocate its soc_camera_async_client structure using devm_kzalloc(), but has it embedded inside the soc_of_info structure. Hence on failure, it must free the whole soc_of_info structure, and not just the embedded soc_camera_async_client structure, as the latter causes a warning, and may cause slab corruption: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 [ cut here ] WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:887 devm_kfree+0x30/0x40() CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-shmobile-08386-g37feb0d093cb2d8e #128 Hardware name: Generic R8A7791 (Flattened Device Tree) Backtrace: [c0011e7c] (dump_backtrace) from [c0012024] (show_stack+0x18/0x1c) r6:c05a923b r5:0009 r4: r3:00204140 [c001200c] (show_stack) from [c048ed30] (dump_stack+0x78/0x94) [c048ecb8] (dump_stack) from [c002687c] (warn_slowpath_common+0x8c/0xb8) r4: r3: [c00267f0] (warn_slowpath_common) from [c0026980] (warn_slowpath_null+0x24/0x2c) r8:ee7d8214 r7:ed83b810 r6:ed83bc20 r5:fffa r4:ed83e510 [c002695c] (warn_slowpath_null) from [c025e0cc] (devm_kfree+0x30/0x40) [c025e09c] (devm_kfree) from [c032bbf4] (soc_of_bind.isra.14+0x194/0x1d4) [c032ba60] (soc_of_bind.isra.14) from [c032c6b8] (soc_camera_host_register+0x208/0x31c) r9:0070 r8:ee7e05d0 r7:ee153210 r6: r5:ee7e0218 r4:ed83bc20 [c032c4b0] (soc_camera_host_register) from [c032e80c] (rcar_vin_probe+0x1f4/0x238) r8:ee153200 r7:0008 r6:ee153210 r5:ed83bc10 r4:c066319c r3:00c0 [c032e618] (rcar_vin_probe) from [c025c334] (platform_drv_probe+0x50/0xa0) r10: r9:c0662fa8 r8: r7:c06a3700 r6:c0662fa8 r5:ee153210 r4: [c025c2e4] (platform_drv_probe) from [c025af08] (driver_probe_device+0xc4/0x208) r6:c06a36f4 r5: r4:ee153210 r3:c025c2e4 [c025ae44] (driver_probe_device) from [c025b108] (__driver_attach+0x70/0x94) r9:c066f9c0 r8:c0624a98 r7:c065b790 r6:c0662fa8 r5:ee153244 r4:ee153210 [c025b098] (__driver_attach) from [c025984c] (bus_for_each_dev+0x74/0x98) r6:c025b098 r5:c0662fa8 r4: r3:0001 [c02597d8] (bus_for_each_dev) from [c025b1dc] (driver_attach+0x20/0x28) r6:ed83c200 r5: r4:c0662fa8 [c025b1bc] (driver_attach) from [c025a00c] (bus_add_driver+0xdc/0x1c4) [c0259f30] (bus_add_driver) from [c025b8f4] (driver_register+0xa4/0xe8) r7:c0624a98 r6: r5:c060b010 r4:c0662fa8 [c025b850] (driver_register) from [c025ccd0] (__platform_driver_register+0x50/0x64) r5:c060b010 r4:ed8394c0 [c025cc80] (__platform_driver_register) from [c060b028] (rcar_vin_driver_init+0x18/0x20) [c060b010] (rcar_vin_driver_init) from [c05edde8] (do_one_initcall+0x108/0x1b8) [c05edce0] (do_one_initcall) from [c05edfb4] (kernel_init_freeable+0x11c/0x1e4) r9:c066f9c0 r8:c066f9c0 r7:c062eab0 r6:c06252c4 r5:00ad r4:0006 [c05ede98] (kernel_init_freeable) from [c048c3d0] (kernel_init+0x10/0xec) r9: r8: r7: r6: r5:c048c3c0 r4: [c048c3c0] (kernel_init) from [c000eba0] (ret_from_fork+0x14/0x34) r4: r3:ee04e000 ---[ end trace e3a984cc0335c8a0 ]--- rcar_vin e6ef1000.video: group probe failed: -6 Fixes: 1ddc6a6caa94e1e1 ([media] soc_camera: add support for dt binding soc_camera drivers) Cc: sta...@vger.kernel.org Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- Triggered with shmobile-defconfig on r8a7791/koelsch. v2: - Free info instead of removing the call to devm_kfree(), as suggested by Sergei --- drivers/media/platform/soc_camera/soc_camera.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index cee7b56f84049944..66634b469c9899f0 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -1665,7 +1665,7 @@ eclkreg: eaddpdev: platform_device_put(sasc-pdev); eallocpdev: - devm_kfree(ici-v4l2_dev.dev, sasc); + devm_kfree(ici-v4l2_dev.dev, info); dev_err(ici-v4l2_dev.dev, group probe failed: %d\n, ret); return ret; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. MvH Benjamin Larsson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Br, -Antti -- 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] [media] [kbuild] Add and use IS_REACHABLE macro
On 2015-02-18 18:12, Arnd Bergmann wrote: In the media drivers, the v4l2 core knows about all submodules and calls into them from a common function. However this cannot work if the modules that get called are loadable and the core is built-in. In that case we get drivers/built-in.o: In function `set_type': drivers/media/v4l2-core/tuner-core.c:301: undefined reference to `tea5767_attach' drivers/media/v4l2-core/tuner-core.c:307: undefined reference to `tea5761_attach' drivers/media/v4l2-core/tuner-core.c:349: undefined reference to `tda9887_attach' drivers/media/v4l2-core/tuner-core.c:405: undefined reference to `xc4000_attach' [...] Ideally Kconfig would be used to avoid the case of a broken dependency, or the code restructured in a way to turn around the dependency, but either way would require much larger changes here. What can be done without extending kbuild is to accept CONFIG_VIDEO_TUNER=y and CONFIG_MEDIA_TUNER_FOO=m, but build both into the kernel, e.g. diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig index 42e5a01..d2c7e89 100644 --- a/drivers/media/tuners/Kconfig +++ b/drivers/media/tuners/Kconfig @@ -71,6 +71,11 @@ config MEDIA_TUNER_TEA5767 help Say Y here to include support for the Philips TEA5767 radio tuner. +config MEDIA_TUNER_TEA5767_BUILD + tristate + default VIDEO_TUNER || MEDIA_TUNER_TEA5767 + depends on MEDIA_TUNER_TEA5767!=n + config MEDIA_TUNER_MSI001 tristate Mirics MSi001 depends on MEDIA_SUPPORT SPI VIDEO_V4L2 Actually, I have hard time coming up with a kconfig syntactic sugar to express such dependency. If I understand it correctly, the valid configurations in this case are MEDIA_TUNER_TEA5767 n m y VIDEO_TUNER n x x x m x x x y x x I.e. only VIDEO_TUNER=y and MEDIA_TUNER_TEA5767=m is incorrect, isn't it? Thanks, 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: Using the coda driver with Gstreamer
Le 2015-02-19 02:24, Zahari Doychev a écrit : So can you tell me if there are some drivers and plugins that can do this in efficient way. Is there some work going on in this directions. I suppose glimagesink maybe will be a good way to go. There is a lot of work happening, you should notice by searching this mailing list archive. The most promising seems to be the one targeting Wayland and DMABUF. On the GST side, there is experimental patches to handle DMABUF import and render queue, these are not yet fully merged into Wayland protocol and Weston. Weston can import DMABUF of various format and do the colorspace conversion using shaders. This can compensate the lack of hw color converter if your GPU is fast and precise enough. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
On Wed, Feb 18, 2015 at 11:04 PM, David Harty d...@dharty.com wrote: On 02/17/2015 04:47 AM, dCrypt wrote: So the PCI Express change hasn't seemed to help either. Any other ideas? David -- My system stops working at least once a day. Does anyone have any suggestions to try? latest module builds? other firmwares? I notice there are several up on the http://www.steventoth.net/linux/hvr22xx/ site, would any of those work better? Is there a better card to use? the HVR-2200 and saa7164 are effectively unusable at this point. I'm planning to release an updated saa7164 driver shortly, with support for the HVR2205 and the HVR2255. Additionally, it contains a fix (which for some people) has significantly reduced the I2C Timeout related errors. (Technically the risc processor crashes on the card, leading to all firmware commands timing out). I'll post a notice to this list once the driver is ready for download. Shortly, I hope. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.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
[PATCH] DocBook media: fix xvYCC601 documentation
The documentation of the xvYCC601 Y'CbCr encoding was part of the SMPTE 170M (SDTV) colorspace, but it should have been part of the Rec. 709 (HDTV) colorspace as per the xvYCC standard. This change only affects the documentation and not any code. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 5e0352c..a3dfc32 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -666,8 +666,7 @@ as the SMPTE C set, so this colorspace is sometimes called SMPTE C as well./par variablelist varlistentry termThe transfer function defined for SMPTE 170M is the same as the -one defined in Rec. 709. Normally L is in the range [0hellip;1], but for the extended -gamut xvYCC encoding values outside that range are allowed./term +one defined in Rec. 709./term listitem paraL' = -1.099(-L)superscript0.45/superscriptnbsp;+nbsp;0.099nbsp;fornbsp;Lnbsp;le;nbsp;-0.018/para paraL' = 4.5Lnbsp;fornbsp;-0.018nbsp;lt;nbsp;Lnbsp;lt;nbsp;0.018/para @@ -702,25 +701,6 @@ defined in the xref linkend=itu601 / standard and this colorspace is sometim though BT.601 does not mention any color primaries./para paraThe default quantization is limited range, but full range is possible although rarely seen./para - paraThe constantV4L2_YCBCR_ENC_601/constant encoding as described above is the -default for this colorspace, but it can be overridden with constantV4L2_YCBCR_ENC_709/constant, -in which case the Rec. 709 Y'CbCr encoding is used./para - variablelist - varlistentry - termThe xvYCC 601 encoding (constantV4L2_YCBCR_ENC_XV601/constant, xref linkend=xvycc /) is similar -to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range -[0hellip;1]. The resulting Y', Cb and Cr values are scaled and offset:/term - listitem - paraY'nbsp;=nbsp;(219nbsp;/nbsp;255)nbsp;*nbsp;(0.299R'nbsp;+nbsp;0.587G'nbsp;+nbsp;0.114B')nbsp;+nbsp;(16nbsp;/nbsp;255)/para - paraCbnbsp;=nbsp;(224nbsp;/nbsp;255)nbsp;*nbsp;(-0.169R'nbsp;-nbsp;0.331G'nbsp;+nbsp;0.5B')/para - paraCrnbsp;=nbsp;(224nbsp;/nbsp;255)nbsp;*nbsp;(0.5R'nbsp;-nbsp;0.419G'nbsp;-nbsp;0.081B')/para - /listitem - /varlistentry - /variablelist - paraY' is clamped to the range [0hellip;1] and Cb and Cr are clamped -to the range [-0.5hellip;0.5]. The non-standard xvYCC 709 encoding can also be used by selecting -constantV4L2_YCBCR_ENC_XV709/constant. The xvYCC encodings always use full range -quantization./para /section section @@ -803,6 +783,7 @@ rarely seen./para paraThe constantV4L2_YCBCR_ENC_709/constant encoding described above is the default for this colorspace, but it can be overridden with constantV4L2_YCBCR_ENC_601/constant, in which case the BT.601 Y'CbCr encoding is used./para + paraTwo additional extended gamut Y'CbCr encodings are also possible with this colorspace:/para variablelist varlistentry termThe xvYCC 709 encoding (constantV4L2_YCBCR_ENC_XV709/constant, xref linkend=xvycc /) @@ -815,10 +796,22 @@ is similar to the Rec. 709 encoding, but it allows for R', G' and B' values that /listitem /varlistentry /variablelist + variablelist + varlistentry + termThe xvYCC 601 encoding (constantV4L2_YCBCR_ENC_XV601/constant, xref linkend=xvycc /) is similar +to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range +[0hellip;1]. The resulting Y', Cb and Cr values are scaled and offset:/term + listitem + paraY'nbsp;=nbsp;(219nbsp;/nbsp;255)nbsp;*nbsp;(0.299R'nbsp;+nbsp;0.587G'nbsp;+nbsp;0.114B')nbsp;+nbsp;(16nbsp;/nbsp;255)/para + paraCbnbsp;=nbsp;(224nbsp;/nbsp;255)nbsp;*nbsp;(-0.169R'nbsp;-nbsp;0.331G'nbsp;+nbsp;0.5B')/para + paraCrnbsp;=nbsp;(224nbsp;/nbsp;255)nbsp;*nbsp;(0.5R'nbsp;-nbsp;0.419G'nbsp;-nbsp;0.081B')/para + /listitem + /varlistentry + /variablelist paraY' is clamped to the range [0hellip;1] and Cb and Cr are clamped -to the range [-0.5hellip;0.5]. The non-standard xvYCC 601 encoding can also be used by -selecting constantV4L2_YCBCR_ENC_XV601/constant. The xvYCC encodings always use full -range quantization./para +to the range [-0.5hellip;0.5]. The non-standard xvYCC 709 or xvYCC 601 encodings can be used by +selecting constantV4L2_YCBCR_ENC_XV709/constant or constantV4L2_YCBCR_ENC_XV601/constant. +The xvYCC encodings always use full range quantization./para /section section -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Thu, Feb 19, 2015 at 11:06 AM, Sean Young s...@mess.org wrote:
On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote:
This patch adds support for the Vortex 1 PCIe card from Prospero
Technologies Ltd. The Vortex 1 supports up to 8 tuner modules and
currently ships with 8xDibcom 7090p tuners. The card also has raw
infra-red support and a hardware demuxer.
-snip-
diff --git a/drivers/media/pci/prospero/prospero_ir.c
b/drivers/media/pci/prospero/prospero_ir.c
new file mode 100644
index 000..01e5204
--- /dev/null
+++ b/drivers/media/pci/prospero/prospero_ir.c
@@ -0,0 +1,150 @@
+/*
+ * Infra-red driver for PCIe DVB cards from Prospero Technology Ltd.
+ *
+ * Copyright Prospero Technology Ltd. 2014
+ * Written/Maintained by Philip Downer
+ * Contact: pdow...@prospero-tech.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include media/rc-core.h
+#include prospero_ir.h
+
+#define DURATION_MASK 0x7
+#define PULSE_MASK 0x100
+#define FIFO_FILL_MASK 0xFF
+
+#define FIFO_FILL 0x60
+#define FIFO 0x64
+
+struct prospero_IR {
+ struct prospero_device *pdev;
+ struct rc_dev *dev;
+
+ int users;
The users field is never used.
+
+ char name[32];
+ char phys[32];
+};
+
+static int prospero_ir_open(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users++;
+ return 0;
+
+}
+
+static void prospero_ir_close(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users--;
+
+}
Since the users field is never read these functions are unnecessary and
can be removed.
+
+void ir_interrupt(struct prospero_pci *p_pci)
+{
+
+ struct prospero_device *p = p_pci-p_dev;
+ struct prospero_IR *ir = p-ir;
+ struct ir_raw_event ev;
+ int tmp = 0;
+ int fill = 0;
+ int pulse = 0;
+ int duration = 0;
+
+ pr_debug(Infra: Interrupt!\n);
+
+ tmp = ioread32(p_pci-io_mem + FIFO_FILL);
+ fill = tmp FIFO_FILL_MASK;
+
+ init_ir_raw_event(ev);
+
+ while (fill 0) {
+
+ pr_debug(Infra: fifo fill = %d\n, fill);
+
+ tmp = ioread32(p_pci-io_mem + FIFO);
+ pr_debug(Infra: raw dump = 0x%x\n, tmp);
+ pulse = (tmp PULSE_MASK) 24;
+ duration = (tmp DURATION_MASK) * 1000;/* Convert uS
to nS */
+
+ pr_debug(Infra: pulse = %d; duration = %d\n, pulse,
duration);
+
+ ev.pulse = pulse;
+ ev.duration = duration;
+ ir_raw_event_store_with_filter(ir-dev, ev);
+ fill--;
+ }
+ ir_raw_event_handle(ir-dev);
+
+}
+
+int prospero_ir_init(struct prospero_device *p)
+{
+
+ struct prospero_pci *p_pci = p-bus_specific;
+ struct pci_dev *pci = p_pci-pcidev;
+ struct prospero_IR *ir;
+ struct rc_dev *dev;
+ int err = -ENOMEM;
+
+ ir = kzalloc(sizeof(*ir), GFP_KERNEL);
+
+ dev = rc_allocate_device();
+
+ if (!ir || !dev)
+ goto err_out_free;
+
+ ir-dev = dev;
+
+ snprintf(ir-name, sizeof(ir-name), prospero IR);
+ snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci));
+
+ dev-input_name = ir-name;
+ dev-input_phys = ir-phys;
+ dev-input_id.bustype = BUS_PCI;
+ dev-input_id.version = 1;
+ dev-input_id.vendor = pci-vendor;
+ dev-input_id.product = pci-device;
+
+ dev-dev.parent = pci-dev;
+ dev-map_name = RC_MAP_LIRC;
+
+ dev-driver_name = prospero;
+ dev-priv = p;
+ dev-open = prospero_ir_open;
+ dev-close = prospero_ir_close;
+ dev-driver_type = RC_DRIVER_IR_RAW;
+ dev-timeout = 10 * 1000 * 1000;
If you know the rx_resolution, please provide it. The lirc interface
can query it.
+
+ iowrite32(0x12000, p_pci-io_mem + FIFO_FILL);
+
+ ir-pdev = p;
+ p-ir = ir;
+
+ err = rc_register_device(dev);
+ if (err)
+ goto err_out_free;
+
+ return 0;
+
+ err_out_free:
+ rc_free_device(dev);
+ p-ir = NULL;
+ kfree(ir);
+ return -ENOMEM;
+
+}
Thanks For your feedback Sean, I'll make those changes.
regards,
--
Philip Downer
pdow...@prospero-tech.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: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote: -snip- + dev = rc_allocate_device(); + + if (!ir || !dev) + goto err_out_free; + + ir-dev = dev; + + snprintf(ir-name, sizeof(ir-name), prospero IR); + snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci)); + + dev-input_name = ir-name; + dev-input_phys = ir-phys; + dev-input_id.bustype = BUS_PCI; + dev-input_id.version = 1; + dev-input_id.vendor = pci-vendor; + dev-input_id.product = pci-device; + + dev-dev.parent = pci-dev; + dev-map_name = RC_MAP_LIRC; RC_MAP_LIRC isn't really a useful default; no remote will work with that. Other drivers default to RC_MAP_RC6_MCE if no remote was provided with the product. I don't know if this is good choice, but at least it is consistent. + + dev-driver_name = prospero; + dev-priv = p; + dev-open = prospero_ir_open; + dev-close = prospero_ir_close; + dev-driver_type = RC_DRIVER_IR_RAW; + dev-timeout = 10 * 1000 * 1000; There is a MS_TO_NS() macro for this. Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 17 +
include/media/videobuf2-core.h | 18 +-
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..5cd60bf 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
/*
* Queue next buffer if required.
*/
- if (buf-pos == buf-size ||
- (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ if (buf-pos == buf-size || (!read fileio-write_immediately)) {
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
- fileio-dq_count == 1) {
+ if (read fileio-read_once fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..e49dc6b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -346,7 +335,8 @@ struct v4l2_fh;
*
* @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes: supported io methods (see vb2_io_modes enum)
- * @io_flags: additional io flags (see vb2_fileio_flags enum)
+ * @fileio_read_once: report EOF after reading the first buffer
+ * @fileio_write_immediately: queue buffer after each write() call
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 02/19/2015 12:21 PM, Antti Seppälä wrote: On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Could you disable whole IR polling and test modprobe dvb_usb_v2 disable_rc_polling=1 It is funny that *increasing* RC polling makes things better, though... regards Antti -- 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
[PATCH v4 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 29 +++--
include/media/videobuf2-core.h |2 ++
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5cd60bf..b8a30d5 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1276,13 +1276,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+*
+* Some drivers, e.g. old codec drivers, use bytesused
+* == 0 as a way to indicate that streaming is finished.
+* In that case, the driver should use the
+* allow_zero_bytesused flag to keep old userspace
+* applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1304,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+*
+* Some drivers, e.g. old codec drivers, use bytesused * == 0 as
+* a way to indicate that streaming is finished. In that case,
+* the driver should use the allow_zero_bytesused flag to keep
+* old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1320,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
+ else
+ v4l2_planes[0].bytesused = b-bytesused ?
+ b-bytesused : v4l2_planes[0].length;
+ } else
v4l2_planes[0].bytesused = 0;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index e49dc6b..a5790fd 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -337,6 +337,7 @@ struct v4l2_fh;
* @io_modes: supported io methods (see vb2_io_modes enum)
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
+ * @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -388,6 +389,7 @@ struct vb2_queue {
unsigned intio_modes;
unsigned
[PATCH v4 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..2d23f9a 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq-lock = ctx-dev-dev_mutex; + /* One of means to indicate end-of-stream for coda is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag, so +* that videobuf2 will keep the value of bytesused intact. +*/ + vq-allow_zero_bytesused = 1; return vb2_queue_init(vq); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..6b08488 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One of means to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] vb2: split the io_flags member of vb2_queue into a bit field
Hi,
Thank you for the review!
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, February 19, 2015 11:41 AM
On 02/19/15 11:11, Kamil Debski wrote:
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 15 +--
include/media/videobuf2-core.h | 16
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..62531956 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue
*q, int read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver @@ -3029,11
+3032,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
* Queue next buffer if required.
*/
if (buf-pos == buf-size ||
- (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ (!read (fileio-write_immediately))) {
No need for the parenthesis around fileio-write_immediately.
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
+ if (read (fileio-read_once)
Ditto for fileio-read_once.
fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
diff --git a/include/media/videobuf2-core.h
b/include/media/videobuf2-core.h index bd2cec2..1346693 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes { };
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io
emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each
write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -347,6 +336,7 @@ struct v4l2_fh;
* @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes: supported io methods (see vb2_io_modes enum)
* @io_flags: additional io flags (see vb2_fileio_flags enum)
io_flags no longer exists.
+ * XXX
Same question as before: XXX
I assume the intention was to replace XXX with the documentation of the
new bitfields which is now lost after removing the enum
vb2_fileio_flags.
The lack of morning coffee is here to blame. Sorry, I'll post an fix in a
moment.
* @lock: pointer to a mutex that protects the vb2_queue
struct. The
* driver can set this to a mutex to let the v4l2 core
serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
Regards,
Hans
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 19 February 2015 at 18:14, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 06:01 PM, Antti Seppälä wrote: On 19 February 2015 at 17:38, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 12:21 PM, Antti Seppälä wrote: On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Could you disable whole IR polling and test modprobe dvb_usb_v2 disable_rc_polling=1 It is funny that *increasing* RC polling makes things better, though... Hi. I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? IR polling does not use I2C but some own commands. Could you make more tests. Use rtl28xxu module parameter to disable IR and test. It will disable both IR interrupts and polling. Then make some tests with different IR polling intervals to see how it behaves. Hi Antti. I made some further tests for you. Here are the results: dvb_usb_v2 disable_rc_polling=1: firmware download FAILED dvb_usb_rtl28xxu disable_rc=1: firmware download FAILED Then I restored the module parameters to default values and tested with various rc-interval values: interval = 800: firmware download FAILED interval = 600: firmware download FAILED interval = 400: firmware download FAILED interval = 300: firmware download SUCCESS but I2C errors from tuner could be sometimes observed interval = 200: firmware download SUCCESS interval = 100: firmware download SUCCESS So somehow higher rc polling rate makes the firmware download succeed. This could indeed be some locking/timing related bug. Please let me know if there is something else I can test. -Antti -- 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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What:/sys/class/leds/led/available_sync_leds +Date:February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. 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
[PATCH] [media] cx25840: better document the media pads
Use an enum to better document the media pads.
No functional changes.
Suggested-by: Prabhakar Lad prabhakar.cse...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index 185cb55253c9..bd496447749a 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5196,9 +5196,9 @@ static int cx25840_probe(struct i2c_client *client,
* However, at least for now, there's no much gain on modelling
* those extra inputs. So, let's add it only when needed.
*/
- state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */
- state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */
- state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */
+ state-pads[CX25840_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
+ state-pads[CX25840_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
+ state-pads[CX25840_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
diff --git a/drivers/media/i2c/cx25840/cx25840-core.h
b/drivers/media/i2c/cx25840/cx25840-core.h
index 17b409f55445..fdea48ce0c03 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.h
+++ b/drivers/media/i2c/cx25840/cx25840-core.h
@@ -41,6 +41,14 @@ enum cx25840_model {
CX25837,
};
+enum cx25840_media_pads {
+ CX25840_PAD_INPUT,
+ CX25840_PAD_VID_OUT,
+ CX25840_PAD_VBI_OUT,
+
+ CX25840_NUM_PADS
+};
+
struct cx25840_state {
struct i2c_client *c;
struct v4l2_subdev sd;
@@ -65,7 +73,7 @@ struct cx25840_state {
struct work_struct fw_work; /* work entry for fw load */
struct cx25840_ir_state *ir_state;
#if defined(CONFIG_MEDIA_CONTROLLER)
- struct media_padpads[3];
+ struct media_padpads[CX25840_NUM_PADS];
#endif
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
Em Thu, 19 Feb 2015 17:50:07 -0200 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu: Em Wed, 18 Feb 2015 22:48:04 + Lad, Prabhakar prabhakar.cse...@gmail.com escreveu: Hi Mauro, Thanks for the patch. Thanks for the review. On Fri, Feb 13, 2015 at 10:57 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Instead of keeping the media controller entity not initialized, fill it and create the pads for cx25840. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c index 573e08826b9b..bdb5bb6b58da 100644 --- a/drivers/media/i2c/cx25840/cx25840-core.c +++ b/drivers/media/i2c/cx25840/cx25840-core.c @@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client, int default_volume; u32 id; u16 device_id; +#if defined(CONFIG_MEDIA_CONTROLLER) + int ret; +#endif /* Check if the adapter supports the needed features */ if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA)) @@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client, sd = state-sd; v4l2_i2c_subdev_init(sd, client, cx25840_ops); +#if defined(CONFIG_MEDIA_CONTROLLER) + /* TODO: need to represent analog inputs too */ + state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */ + state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */ + state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */ Macros for 0,1,2 would make it more readable. I was in doubt, on weather use a macro or not for it. I ended by deciding to not use because the code shouldn't assume a particular order for the pads. Also, I'm not sure if is there a way to taint a PAD for VBI or Video, or if it is worth or not do do it. So, the comments there are more a reminder than anything else. On a second thought, indeed it seems better to use an enum here. Just sent the patch. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] siano: add support for the media controller at USB driver
Adding support for the media controller for a pure DVB device
is simple: just create a struct media_device and add it to the
dvb adapter. After creating all DVB devices, we need to call
the DVB core, for it to create the media graph.
More work is needed for pure DVB tuners, but this is hidden
at the Siano driver, just like several others non-hybrid
devices. So, this is streight forward.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
-
v2: add a logic to unregister the media device and rebase over the
last version of the media controller patches.
diff --git a/drivers/media/common/siano/smscoreapi.h
b/drivers/media/common/siano/smscoreapi.h
index 9c9063cd3208..efe4ab090aec 100644
--- a/drivers/media/common/siano/smscoreapi.h
+++ b/drivers/media/common/siano/smscoreapi.h
@@ -31,6 +31,8 @@ along with this program. If not, see
http://www.gnu.org/licenses/.
#include linux/wait.h
#include linux/timer.h
+#include media/media-device.h
+
#include asm/page.h
#include smsir.h
@@ -215,6 +217,10 @@ struct smscore_device_t {
bool is_usb_device;
int led_state;
+
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ struct media_device *media_dev;
+#endif
};
/* GPIO definitions for antenna frequency domain control (SMS8021) */
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index 85151efdd94c..042515915e20 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -613,6 +613,19 @@ static int smsdvb_onresponse(void *context, struct
smscore_buffer_t *cb)
return 0;
}
+static void smsdvb_media_device_unregister(struct smsdvb_client_t *client)
+{
+ struct smscore_device_t *coredev = client-coredev;
+
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
+ if (!coredev-media_dev)
+ return;
+ media_device_unregister(coredev-media_dev);
+ kfree(coredev-media_dev);
+ coredev-media_dev = NULL;
+#endif
+}
+
static void smsdvb_unregister_client(struct smsdvb_client_t *client)
{
/* must be called under clientslock */
@@ -624,6 +637,7 @@ static void smsdvb_unregister_client(struct smsdvb_client_t
*client)
dvb_unregister_frontend(client-frontend);
dvb_dmxdev_release(client-dmxdev);
dvb_dmx_release(client-demux);
+ smsdvb_media_device_unregister(client);
dvb_unregister_adapter(client-adapter);
kfree(client);
}
@@ -1096,6 +1110,9 @@ static int smsdvb_hotplug(struct smscore_device_t
*coredev,
sms_err(dvb_register_adapter() failed %d, rc);
goto adapter_error;
}
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
+ client-adapter.mdev = coredev-media_dev;
+#endif
/* init dvb demux */
client-demux.dmx.capabilities = DMX_TS_FILTERING;
@@ -1175,6 +1192,8 @@ static int smsdvb_hotplug(struct smscore_device_t
*coredev,
if (smsdvb_debugfs_create(client) 0)
sms_info(failed to create debugfs node);
+ dvb_create_media_graph(coredev-media_dev);
+
return 0;
client_error:
@@ -1187,6 +1206,7 @@ dmxdev_error:
dvb_dmx_release(client-demux);
dvbdmx_error:
+ smsdvb_media_device_unregister(client);
dvb_unregister_adapter(client-adapter);
adapter_error:
diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index 94e10b10b66e..4b6db7557e33 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -346,6 +346,42 @@ static void smsusb_term_device(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
}
+static void siano_media_device_register(struct smsusb_device_t *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
+ struct media_device *mdev;
+ struct usb_device *udev = dev-udev;
+ int board_id = smscore_get_board_id(dev-coredev);
+ struct sms_board *board = sms_get_board(board_id);
+ int ret;
+
+ mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+ if (!mdev)
+ return;
+
+ mdev-dev = udev-dev;
+ strlcpy(mdev-model, board-name, sizeof(mdev-model));
+ if (udev-serial)
+ strlcpy(mdev-serial, udev-serial, sizeof(mdev-serial));
+ strcpy(mdev-bus_info, udev-devpath);
+ mdev-hw_revision = le16_to_cpu(udev-descriptor.bcdDevice);
+ mdev-driver_version = LINUX_VERSION_CODE;
+
+ ret = media_device_register(mdev);
+ if (ret) {
+ sms_err(Couldn't create a media device. Error: %d\n,
+ ret);
+ kfree(mdev);
+ return;
+ }
+
+ dev-coredev-media_dev = mdev;
+
+ sms_info(media controller created);
+
+#endif
+}
+
static int smsusb_init_device(struct usb_interface *intf, int board_id)
{
struct smsdevice_params_t params;
@@ -439,6 +475,7 @@ static int smsusb_init_device(struct usb_interface *intf,
int board_id)
}
sms_info(device 0x%p created, dev);
Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On 02/19/2015 10:40 PM, Greg KH wrote: On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. If we are to stick tightly to the one-value-per-file rule, then how we should approach flash_faults case? Should the separate file be dynamically created for each reported fault? -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ABI WARNING
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: Fri Feb 20 04:00:17 CET 2015 git branch: test git hash: 135f9be9194cf7778eb73594aa55791b229cf27c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS 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: WARNINGS 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: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-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: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK apps: OK spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3.19] si2168 fix
Mauro Did that patch went to stable? I see you have committed original patch from patchwork, but there is no stable tag. On 01/22/2015 12:11 PM, Antti Palosaari wrote: That patch must go also stable v3.16+ as tagged Cc. regards Antti The following changes since commit 2c0108e1c02f9fc95f465adc4d2ce1ad8688290a: [media] omap3isp: Correctly set QUERYCAP capabilities (2015-01-21 21:09:11 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git si2168_fix for you to fetch changes up to a85385413c60602b529a1555146c4e81a5935e98: si2168: increase timeout to fix firmware loading (2015-01-22 12:06:20 +0200) Jurgen Kramer (1): si2168: increase timeout to fix firmware loading drivers/media/dvb-frontends/si2168.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://patchwork.linuxtv.org/patch/27382/ commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Antti -- 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: [GIT PULL 3.19] si2168 fix
On 02/20/2015 03:36 AM, Mauro Carvalho Chehab wrote: Em Fri, 20 Feb 2015 02:47:44 +0200 Antti Palosaari cr...@iki.fi escreveu: Mauro Did that patch went to stable? I see you have committed original patch from patchwork, but there is no stable tag. It went upstream, but I'm unsure if it arrived for 3.19 or 3.20. That's the upstream changeset: $ git show 551c33e729f6 commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Weird, it is missing the Cc tag on its commit message. I double-checked re-applying it on a scratch branch: my scripts are properly recognizing the Cc tag. I've no idea what happened. Perhaps you've added this patch on some other branch that you asked me to pull? Anyway, now the proper solution is to send this patch directly to sta...@vger.kernel.org, C/C the mailing list. I added proper stable tag to patchwork and then waited looong time you pick it from patchwork. After a month or so, I picked whole patch from patchwork to my tree, yet again added proper stable tags and made PULL-request. So there is stable tag on both patchwork and PULL-request. You applied patchwork - but without stable tag So I am very surprised to see original patch applied to master, but without stable tag. Si2168: increase timeout to fix firmware loading https://patchwork.linuxtv.org/patch/27382/ [GIT PULL 3.19] si2168 fix http://www.spinics.net/lists/linux-media/msg85713.html Antti Regards, Mauro On 01/22/2015 12:11 PM, Antti Palosaari wrote: That patch must go also stable v3.16+ as tagged Cc. regards Antti The following changes since commit 2c0108e1c02f9fc95f465adc4d2ce1ad8688290a: [media] omap3isp: Correctly set QUERYCAP capabilities (2015-01-21 21:09:11 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git si2168_fix for you to fetch changes up to a85385413c60602b529a1555146c4e81a5935e98: si2168: increase timeout to fix firmware loading (2015-01-22 12:06:20 +0200) Jurgen Kramer (1): si2168: increase timeout to fix firmware loading drivers/media/dvb-frontends/si2168.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://patchwork.linuxtv.org/patch/27382/ commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Antti -- 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: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Thu, Feb 19, 2015 at 12:40 PM, Sean Young s...@mess.org wrote: On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote: -snip- + dev = rc_allocate_device(); + + if (!ir || !dev) + goto err_out_free; + + ir-dev = dev; + + snprintf(ir-name, sizeof(ir-name), prospero IR); + snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci)); + + dev-input_name = ir-name; + dev-input_phys = ir-phys; + dev-input_id.bustype = BUS_PCI; + dev-input_id.version = 1; + dev-input_id.vendor = pci-vendor; + dev-input_id.product = pci-device; + + dev-dev.parent = pci-dev; + dev-map_name = RC_MAP_LIRC; RC_MAP_LIRC isn't really a useful default; no remote will work with that. Other drivers default to RC_MAP_RC6_MCE if no remote was provided with the product. I don't know if this is good choice, but at least it is consistent. + + dev-driver_name = prospero; + dev-priv = p; + dev-open = prospero_ir_open; + dev-close = prospero_ir_close; + dev-driver_type = RC_DRIVER_IR_RAW; + dev-timeout = 10 * 1000 * 1000; There is a MS_TO_NS() macro for this. Ok, thanks Sean, those changes have been made and will be included when I submit the next RFC patch. Thanks again, -- Philip Downer +44 (0)7879 470 969 pdow...@prospero-tech.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: [RFC PATCH] mn88472: reduce firmware download chunk size
I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? IR polling does not use I2C but some own commands. Could you make more tests. Use rtl28xxu module parameter to disable IR and test. It will disable both IR interrupts and polling. Then make some tests with different IR polling intervals to see how it behaves. I have 3 mn88472 and 1 mn88473 device and all those seems to work fine for me. I don't care to buy anymore devices to find out one which does not work. Somehow root of cause should be find - it is not proper fix to repeat or break I2C messages to multiple smaller ones. Ack. Its the job of the I2C controller to manage the I2C bus implementation, including any fragmentation needs, not the tuner/demod/other driver. Find and fix the resource contention bug in the bridge and the mn88472 will work as is. I suspect something is broken with I2C locking. -- Steven Toth - Kernel Labs http://www.kernellabs.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: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
On 02/19/2015 05:22 AM, Steven Toth wrote: I'll post a notice to this list once the driver is ready for download That sounds great. Let me know if/how I can help in any way. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 02/19/2015 06:25 PM, Steven Toth wrote: I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? IR polling does not use I2C but some own commands. Could you make more tests. Use rtl28xxu module parameter to disable IR and test. It will disable both IR interrupts and polling. Then make some tests with different IR polling intervals to see how it behaves. I have 3 mn88472 and 1 mn88473 device and all those seems to work fine for me. I don't care to buy anymore devices to find out one which does not work. Somehow root of cause should be find - it is not proper fix to repeat or break I2C messages to multiple smaller ones. Ack. Its the job of the I2C controller to manage the I2C bus implementation, including any fragmentation needs, not the tuner/demod/other driver. Find and fix the resource contention bug in the bridge and the mn88472 will work as is. I suspect something is broken with I2C locking. It uses i2c control messages - single message per single operation. You will need lock control message when it is done using multiple messages, very typically two bulk message one for request and one for reply - but that's not the case. Anyhow, it is possible firmware rtl2832u firmware does not like some large (larger than single message) operation is interrupted... regards Antti -- 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: [RFC PATCH] mn88472: reduce firmware download chunk size
On 19 February 2015 at 17:38, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 12:21 PM, Antti Seppälä wrote: On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Could you disable whole IR polling and test modprobe dvb_usb_v2 disable_rc_polling=1 It is funny that *increasing* RC polling makes things better, though... Hi. I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? -Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mn88472: reduce firmware download chunk size
On 02/19/2015 06:01 PM, Antti Seppälä wrote: On 19 February 2015 at 17:38, Antti Palosaari cr...@iki.fi wrote: On 02/19/2015 12:21 PM, Antti Seppälä wrote: On 19 February 2015 at 11:43, Benjamin Larsson benja...@southpole.se wrote: On 2015-02-19 10:13, Antti Seppälä wrote: It seems that currently the firmware download on the mn88472 is somehow wrong for my Astrometa HD-901T2. Reducing the download chunk size (mn88472_config.i2c_wr_max) to 2 makes the firmware download consistently succeed. Hi, try adding the workaround patch I sent for this. [PATCH 1/3] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors I now see that it hasn't been merged. But I have been running with this patch for a few months now without any major issues. The patch really did improve firmware loading. Weird... Even with it I still get occasional i2c errors from r820t: [ 15.874402] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=0a len=1: da [ 81.455517] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df [ 99.949702] r820t 8-003a: r820t_read: i2c rd failed=-32 reg=00 len=4: 69 74 e6 df These errors seem to appear more often if I'm reading the signal strength values using e.g. femon. Could you disable whole IR polling and test modprobe dvb_usb_v2 disable_rc_polling=1 It is funny that *increasing* RC polling makes things better, though... Hi. I tried loading the driver with polling disabled and it fails completely: [ 5526.693563] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw' [ 5527.032209] mn88472 7-0018: firmware download failed=-32 [ 5527.033864] rtl2832 7-0010: i2c reg write failed -32 [ 5527.033874] r820t 8-003a: r820t_write: i2c wr failed=-32 reg=05 len=1: 83 [ 5527.036014] rtl2832 7-0010: i2c reg write failed -32 I have no idea why the device behaves so counter-intuitively. Is there maybe some sorf of internal power-save mode the device enters when there is no i2c traffic for a while or something? IR polling does not use I2C but some own commands. Could you make more tests. Use rtl28xxu module parameter to disable IR and test. It will disable both IR interrupts and polling. Then make some tests with different IR polling intervals to see how it behaves. I have 3 mn88472 and 1 mn88473 device and all those seems to work fine for me. I don't care to buy anymore devices to find out one which does not work. Somehow root of cause should be find - it is not proper fix to repeat or break I2C messages to multiple smaller ones. Antti -- 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] [media] [kbuild] Add and use IS_REACHABLE macro
On Thursday 19 February 2015 13:11:07 Michal Marek wrote: On 2015-02-18 18:12, Arnd Bergmann wrote: In the media drivers, the v4l2 core knows about all submodules and calls into them from a common function. However this cannot work if the modules that get called are loadable and the core is built-in. In that case we get drivers/built-in.o: In function `set_type': drivers/media/v4l2-core/tuner-core.c:301: undefined reference to `tea5767_attach' drivers/media/v4l2-core/tuner-core.c:307: undefined reference to `tea5761_attach' drivers/media/v4l2-core/tuner-core.c:349: undefined reference to `tda9887_attach' drivers/media/v4l2-core/tuner-core.c:405: undefined reference to `xc4000_attach' [...] Ideally Kconfig would be used to avoid the case of a broken dependency, or the code restructured in a way to turn around the dependency, but either way would require much larger changes here. What can be done without extending kbuild is to accept CONFIG_VIDEO_TUNER=y and CONFIG_MEDIA_TUNER_FOO=m, but build both into the kernel, e.g. Right, but diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig index 42e5a01..d2c7e89 100644 --- a/drivers/media/tuners/Kconfig +++ b/drivers/media/tuners/Kconfig @@ -71,6 +71,11 @@ config MEDIA_TUNER_TEA5767 help Say Y here to include support for the Philips TEA5767 radio tuner. +config MEDIA_TUNER_TEA5767_BUILD + tristate + default VIDEO_TUNER || MEDIA_TUNER_TEA5767 + depends on MEDIA_TUNER_TEA5767!=n + config MEDIA_TUNER_MSI001 tristate Mirics MSi001 depends on MEDIA_SUPPORT SPI VIDEO_V4L2 We'd then have to do the same for each tuner driver that we have in the kernel or that gets added later. My patch was intended to just restore the previous behavior that was accidentally changed as part of a misguided cleanup. Actually, I have hard time coming up with a kconfig syntactic sugar to express such dependency. If I understand it correctly, the valid configurations in this case are MEDIA_TUNER_TEA5767 n m y VIDEO_TUNER n x x x m x x x y x x I.e. only VIDEO_TUNER=y and MEDIA_TUNER_TEA5767=m is incorrect, isn't it? Yes, I think that is correct. We have similar problems in other areas of the kernel. In theory, we could enforce the VIDEO_TUNER driver to be modular here by adding lots of dependencies to it: config VIDEO_TUNER tristate depends on MEDIA_TUNER_TEA5761 || !MEDIA_TUNER_TEA5761 depends on MEDIA_TUNER_TEA5767 || !MEDIA_TUNER_TEA5767 depends on MEDIA_TUNER_MSI001 || !MEDIA_TUNER_MSI001 but that would also soon get out of hand, and we probably need another indirection here too, for each symbol that selects VIDEO_TUNER. Arnd -- 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] [media] [kbuild] Add and use IS_REACHABLE macro
Dne 19.2.2015 v 15:53 Arnd Bergmann napsal(a): On Thursday 19 February 2015 13:11:07 Michal Marek wrote: On 2015-02-18 18:12, Arnd Bergmann wrote: In the media drivers, the v4l2 core knows about all submodules and calls into them from a common function. However this cannot work if the modules that get called are loadable and the core is built-in. In that case we get drivers/built-in.o: In function `set_type': drivers/media/v4l2-core/tuner-core.c:301: undefined reference to `tea5767_attach' drivers/media/v4l2-core/tuner-core.c:307: undefined reference to `tea5761_attach' drivers/media/v4l2-core/tuner-core.c:349: undefined reference to `tda9887_attach' drivers/media/v4l2-core/tuner-core.c:405: undefined reference to `xc4000_attach' [...] Ideally Kconfig would be used to avoid the case of a broken dependency, or the code restructured in a way to turn around the dependency, but either way would require much larger changes here. What can be done without extending kbuild is to accept CONFIG_VIDEO_TUNER=y and CONFIG_MEDIA_TUNER_FOO=m, but build both into the kernel, e.g. Right, but diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig index 42e5a01..d2c7e89 100644 --- a/drivers/media/tuners/Kconfig +++ b/drivers/media/tuners/Kconfig @@ -71,6 +71,11 @@ config MEDIA_TUNER_TEA5767 help Say Y here to include support for the Philips TEA5767 radio tuner. +config MEDIA_TUNER_TEA5767_BUILD + tristate + default VIDEO_TUNER || MEDIA_TUNER_TEA5767 + depends on MEDIA_TUNER_TEA5767!=n + config MEDIA_TUNER_MSI001 tristate Mirics MSi001 depends on MEDIA_SUPPORT SPI VIDEO_V4L2 We'd then have to do the same for each tuner driver that we have in the kernel or that gets added later. Yes :-(. Actually, I have hard time coming up with a kconfig syntactic sugar to express such dependency. If I understand it correctly, the valid configurations in this case are MEDIA_TUNER_TEA5767 n m y VIDEO_TUNER n x x x m x x x y x x I.e. only VIDEO_TUNER=y and MEDIA_TUNER_TEA5767=m is incorrect, isn't it? Yes, I think that is correct. OK. In this case, a kconfig extension would be really too specific: if set, set to at least X but only if X is set as well. We have similar problems in other areas of the kernel. In theory, we could enforce the VIDEO_TUNER driver to be modular here by adding lots of dependencies to it: config VIDEO_TUNER tristate depends on MEDIA_TUNER_TEA5761 || !MEDIA_TUNER_TEA5761 depends on MEDIA_TUNER_TEA5767 || !MEDIA_TUNER_TEA5767 depends on MEDIA_TUNER_MSI001 || !MEDIA_TUNER_MSI001 Nah, that's even uglier. I suggest to merge your IS_REACHABLE patch. 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
DVBSky T982 (Si2168) Questions/Issues/Request
Hi. I have a couple of issues with the si2168.c dvb-frontend in kernel v 3.19.0. To get the firnware to load I've had to increase the #define TIMEOUT to 150 from 50. I read another post (http://www.spinics.net/lists/linux-media/msg84198.html) where another user had to do the same modification. @ Antti Palosaari: Since the 50ms value you came up with was just based on some trail and error, would it be possible to submit a change upstream to increase this timeout since it's likely others are going to encounter this issue? The second issue I have is that where I am based (UK) we have both DVB-T and DVB-T2 muxes and I can't get a single tuner to be able to tune to both transports, but looking through the Si2168.c code, I'm having trouble working out how (if at all) this is achieved? It's not the case where we can only tune to DVB-T OR DVB-T2 is it? If so, that's far from ideal... Are there any workarounds if true? Best regards. Sean. -- 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: DVBSky T982 (Si2168) Questions/Issues/Request
Moi On 02/20/2015 01:33 AM, Eponymous - wrote: Hi. I have a couple of issues with the si2168.c dvb-frontend in kernel v 3.19.0. To get the firnware to load I've had to increase the #define TIMEOUT to 150 from 50. I read another post (http://www.spinics.net/lists/linux-media/msg84198.html) where another user had to do the same modification. @ Antti Palosaari: Since the 50ms value you came up with was just based on some trail and error, would it be possible to submit a change upstream to increase this timeout since it's likely others are going to encounter this issue? It is increased to 70 ms already, commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading If it is not enough, then send patch which increased it even more. Have to check if that fix never applied to stable, as there is no Cc stable I added Mauro has applied patch from patchwork, not from pull request I made: https://patchwork.linuxtv.org/patch/27960/ http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=si2168_fix The second issue I have is that where I am based (UK) we have both DVB-T and DVB-T2 muxes and I can't get a single tuner to be able to tune to both transports, but looking through the Si2168.c code, I'm having trouble working out how (if at all) this is achieved? It's not the case where we can only tune to DVB-T OR DVB-T2 is it? If so, that's far from ideal... Are there any workarounds if true? I don't understand what you mean. Likely you are not understanding how DVB-T and DVB-T2 works. There is transmitter which uses DVB-T or DVB-T2, not both standards same time. You have to select used standard according to transmitter specs and make proper tuning request. Driver could do DVB-T, DVB-T2 and DVB-C, but only one transmission is possible to receive as once per tuner. regards Antti -- 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
Problem
I am trying to get my Hauppauge USB-Live2 to capture VHS recordings using VLC Player. My computer will recognize the USB-Live2 but nothing shows on the screen when using VLC Player. Any suggestions? Thank You jeffrey@jeffrey-HP-2000-Notebook-PC:~$ git clone git://linuxtv.org/media_build.git Cloning into 'media_build'... remote: Counting objects: 2699, done. remote: Compressing objects: 100% (1082/1082), done. remote: Total 2699 (delta 1895), reused 2258 (delta 1577) Receiving objects: 100% (2699/2699), 526.94 KiB | 38.00 KiB/s, done. Resolving deltas: 100% (1895/1895), done. Checking connectivity... done. jeffrey@jeffrey-HP-2000-Notebook-PC:~$ cd media_build jeffrey@jeffrey-HP-2000-Notebook-PC:~/media_build$ ./build Checking if the needed tools for Zorin OS 9 are available ERROR: please install Proc::ProcessTable, otherwise, build won't work. I don't know distro Zorin OS 9. So, I can't provide you a hint with the package names. Be welcome to contribute with a patch for media-build, by submitting a distro-specific hint to linux-media@vger.kernel.org Build can't procceed as 1 dependency is missing at ./build line 266. jeffrey@jeffrey-HP-2000-Notebook-PC:~/media_build$ -- 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: [GIT PULL 3.19] si2168 fix
Em Fri, 20 Feb 2015 02:47:44 +0200 Antti Palosaari cr...@iki.fi escreveu: Mauro Did that patch went to stable? I see you have committed original patch from patchwork, but there is no stable tag. It went upstream, but I'm unsure if it arrived for 3.19 or 3.20. That's the upstream changeset: $ git show 551c33e729f6 commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Weird, it is missing the Cc tag on its commit message. I double-checked re-applying it on a scratch branch: my scripts are properly recognizing the Cc tag. I've no idea what happened. Perhaps you've added this patch on some other branch that you asked me to pull? Anyway, now the proper solution is to send this patch directly to sta...@vger.kernel.org, C/C the mailing list. Regards, Mauro On 01/22/2015 12:11 PM, Antti Palosaari wrote: That patch must go also stable v3.16+ as tagged Cc. regards Antti The following changes since commit 2c0108e1c02f9fc95f465adc4d2ce1ad8688290a: [media] omap3isp: Correctly set QUERYCAP capabilities (2015-01-21 21:09:11 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git si2168_fix for you to fetch changes up to a85385413c60602b529a1555146c4e81a5935e98: si2168: increase timeout to fix firmware loading (2015-01-22 12:06:20 +0200) Jurgen Kramer (1): si2168: increase timeout to fix firmware loading drivers/media/dvb-frontends/si2168.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://patchwork.linuxtv.org/patch/27382/ commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Antti -- 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
