[PATCH 0/3] [media] ths8200 fixes
This patch series applies a few fixes for ths8200 from Cisco's internal tree. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] ths8200: Zero blanking level for RGB.
Currently only RGB444 input data is supported so set to zero. Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/i2c/ths8200.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c index 04139ee..5c7dca3 100644 --- a/drivers/media/i2c/ths8200.c +++ b/drivers/media/i2c/ths8200.c @@ -217,8 +217,8 @@ static void ths8200_core_init(struct v4l2_subdev *sd) /* Disable embedded syncs on the output by setting * the amplitude to zero for all channels. */ - ths8200_write(sd, THS8200_DTG1_Y_SYNC_MSB, 0x2a); - ths8200_write(sd, THS8200_DTG1_CBCR_SYNC_MSB, 0x2a); + ths8200_write(sd, THS8200_DTG1_Y_SYNC_MSB, 0x00); + ths8200_write(sd, THS8200_DTG1_CBCR_SYNC_MSB, 0x00); } static void ths8200_setup(struct v4l2_subdev *sd, struct v4l2_bt_timings *bt) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] ths8200: Format adjustment.
Closer inspection on excact transmitted format showed that
we needed to add 1 on vertical sync.
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/ths8200.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index bcacf52..f72561e 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -318,15 +318,15 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct
v4l2_bt_timings *bt)
(htotal(bt) 8) 0x1f);
ths8200_write(sd, THS8200_DTG2_HLENGTH_HDLY_LSB, htotal(bt));
- /* v sync width transmitted */
- ths8200_write(sd, THS8200_DTG2_VLENGTH1_LSB, (bt-vsync) 0xff);
+ /* v sync width transmitted (must add 1 to get correct output) */
+ ths8200_write(sd, THS8200_DTG2_VLENGTH1_LSB, (bt-vsync + 1) 0xff);
ths8200_write_and_or(sd, THS8200_DTG2_VLENGTH1_MSB_VDLY1_MSB, 0x3f,
-((bt-vsync) 2) 0xc0);
+((bt-vsync + 1) 2) 0xc0);
- /* The pixel value v sync is asserted on */
+ /* The pixel value v sync is asserted on (must add 1 to get correct
output) */
ths8200_write_and_or(sd, THS8200_DTG2_VLENGTH1_MSB_VDLY1_MSB, 0xf8,
-(vtotal(bt)8) 0x7);
- ths8200_write(sd, THS8200_DTG2_VDLY1_LSB, vtotal(bt));
+((vtotal(bt) + 1) 8) 0x7);
+ ths8200_write(sd, THS8200_DTG2_VDLY1_LSB, vtotal(bt) + 1);
/* For progressive video vlength2 must be set to all 0 and vdly2 must
* be set to all 1.
@@ -336,11 +336,11 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct
v4l2_bt_timings *bt)
ths8200_write(sd, THS8200_DTG2_VDLY2_LSB, 0xff);
/* Internal delay factors to synchronize the sync pulses and the data */
- /* Experimental values delays (hor 4, ver 1) */
- ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_MSB, (htotal(bt)8) 0x1f);
- ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_LSB, (htotal(bt) - 4) 0xff);
+ /* Experimental values delays (hor 0, ver 0) */
+ ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_MSB, 0);
+ ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_LSB, 0);
ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_MSB, 0);
- ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_LSB, 1);
+ ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_LSB, 0);
/* Polarity of received and transmitted sync signals */
if (bt-polarities V4L2_DV_HSYNC_POS_POL) {
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] ths8200: Corrected sync polarities setting.
HS_IN/VS_IN was always set to positive. Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/i2c/ths8200.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c index 5c7dca3..bcacf52 100644 --- a/drivers/media/i2c/ths8200.c +++ b/drivers/media/i2c/ths8200.c @@ -356,7 +356,7 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct v4l2_bt_timings *bt) /* Timing of video input bus is derived from HS, VS, and FID dedicated * inputs */ - ths8200_write(sd, THS8200_DTG2_CNTL, 0x47 | polarity); + ths8200_write(sd, THS8200_DTG2_CNTL, 0x44 | polarity); /* leave reset */ ths8200_s_stream(sd, true); -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/24] xc5000: properly report i2c write failures
Hi,
Sorry for response about the past post.
The logic as written would *never* actually return an error condition, since
the loop would run until the counter hit zero but the check was for a value
less than zero.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
---
drivers/media/common/tuners/xc5000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index f660e33..a7fa17e 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -341,7 +341,7 @@static int xc_write_reg(struct xc5000_priv *priv, u16
regAddr, u16 i2cData)
}
}
}
- if (WatchDogTimer 0)
+ if (WatchDogTimer = 0)
I can't load firmware like error of below link.
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/1263837
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/1263837
This error is related with this patch. This fix is right but above error
is created after this fix
because my device makes WatchDogTimer to 0 when load firmware.
Maybe it will be related with XREG_BUSY register but i can't check it.
I removed this fix, but i have faced at other error with xc5000: PLL
not running after fwload
So i have commented like below.
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
.name = XC5000A_FIRMWARE,
.size = 12401,
//.pll_reg = 0x806c,
};
Then, xc5000 device works well.
I don't have xc5000 datasheet so i can't debug xc5000 driver anymore.
Any help?
Thanks.
result = XC_RESULT_I2C_WRITE_FAILURE;
return result;
--
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 RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
I've chatted a bit with Hans Verkuil about this topic at fosdem and
apparently both v4l and alsa have something like this already in their
helper libraries. Adding more people as fyi in case they want to
switch to the new driver core stuff from Russell.
-Daniel
On Thu, Jan 2, 2014 at 10:27 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
The superdevice is declared into the component support, along with the
subcomponents. The superdevice receives callbacks to locate the
subcomponents, and identify when all components are present. At this
point, we bind the superdevice, which causes the appropriate subsystem
to be initialised in the conventional way.
When any of the components or superdevice are removed from the system,
we unbind the superdevice, thereby taking the subsystem down.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/base/Makefile |2 +-
drivers/base/component.c | 379
+
include/linux/component.h | 31
3 files changed, 411 insertions(+), 1 deletions(-)
create mode 100644 drivers/base/component.c
create mode 100644 include/linux/component.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 94e8a80e87f8..870ecfd503af 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -1,6 +1,6 @@
# Makefile for the Linux device tree
-obj-y := core.o bus.o dd.o syscore.o \
+obj-y := component.o core.o bus.o dd.o syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
diff --git a/drivers/base/component.c b/drivers/base/component.c
new file mode 100644
index ..5492cd8d2247
--- /dev/null
+++ b/drivers/base/component.c
@@ -0,0 +1,379 @@
+/*
+ * Componentized device handling.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This is work in progress. We gather up the component devices into a list,
+ * and bind them when instructed. At the moment, we're specific to the DRM
+ * subsystem, and only handles one master device, but this doesn't have to be
+ * the case.
+ */
+#include linux/component.h
+#include linux/device.h
+#include linux/kref.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/slab.h
+
+struct master {
+ struct list_head node;
+ struct list_head components;
+ bool bound;
+
+ const struct component_master_ops *ops;
+ struct device *dev;
+};
+
+struct component {
+ struct list_head node;
+ struct list_head master_node;
+ struct master *master;
+ bool bound;
+
+ const struct component_ops *ops;
+ struct device *dev;
+};
+
+static DEFINE_MUTEX(component_mutex);
+static LIST_HEAD(component_list);
+static LIST_HEAD(masters);
+
+static struct master *__master_find(struct device *dev, const struct
component_master_ops *ops)
+{
+ struct master *m;
+
+ list_for_each_entry(m, masters, node)
+ if (m-dev == dev (!ops || m-ops == ops))
+ return m;
+
+ return NULL;
+}
+
+/* Attach an unattached component to a master. */
+static void component_attach_master(struct master *master, struct component
*c)
+{
+ c-master = master;
+
+ list_add_tail(c-master_node, master-components);
+}
+
+/* Detach a component from a master. */
+static void component_detach_master(struct master *master, struct component
*c)
+{
+ list_del(c-master_node);
+
+ c-master = NULL;
+}
+
+int component_master_add_child(struct master *master,
+ int (*compare)(struct device *, void *), void *compare_data)
+{
+ struct component *c;
+ int ret = -ENXIO;
+
+ list_for_each_entry(c, component_list, node) {
+ if (c-master)
+ continue;
+
+ if (compare(c-dev, compare_data)) {
+ component_attach_master(master, c);
+ ret = 0;
+ break;
+ }
+ }
+
+ return ret;
+}
Re: [PATCH, RFC 08/30] [media] arv: fix sleep_on race
On 01/17/2014 11:51 AM, Hans Verkuil wrote: On 01/02/2014 01:07 PM, Arnd Bergmann wrote: interruptible_sleep_on is racy and going away. In the arv driver that race has probably never caused problems since it would require a whole video frame to be captured before the read function has a chance to go to sleep, but using wait_event_interruptible lets us kill off the old interface. In order to do this, we have to slightly adapt the meaning of the ar-start_capture field to distinguish between not having started a frame and having completed it. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org --- drivers/media/platform/arv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/arv.c b/drivers/media/platform/arv.c index e346d32d..32f6d70 100644 --- a/drivers/media/platform/arv.c +++ b/drivers/media/platform/arv.c @@ -307,11 +307,11 @@ static ssize_t ar_read(struct file *file, char *buf, size_t count, loff_t *ppos) /* * Okay, kick AR LSI to invoke an interrupt */ -ar-start_capture = 0; +ar-start_capture = -1; start_capture is defined as an unsigned. Can you make a new patch that changes the type of start_capture to int? Otherwise it looks fine. ping! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC 07/30] [media] radio-cadet: avoid interruptible_sleep_on race
Hi Arnd!
On 01/17/2014 03:28 PM, Arnd Bergmann wrote:
On Friday 17 January 2014, Hans Verkuil wrote:
@@ -323,25 +324,32 @@ static ssize_t cadet_read(struct file *file, char
__user *data, size_t count, lo
struct cadet *dev = video_drvdata(file);
unsigned char readbuf[RDS_BUFFER];
int i = 0;
+ DEFINE_WAIT(wait);
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (1) {
+ prepare_to_wait(dev-read_queue, wait, TASK_INTERRUPTIBLE);
+ if (dev-rdsin != dev-rdsout)
+ break;
+
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ schedule();
mutex_lock(dev-lock);
}
+
This seems overly complicated. Isn't it enough to replace
interruptible_sleep_on
by 'wait_event_interruptible(dev-read_queue, dev-rdsin != dev-rdsout);'?
Or am I missing something subtle?
The existing code sleeps with dev-lock released because the cadet_handler()
function needs to grab (and release) the same lock before it can wake up
the reader thread.
Doing the simple wait_event_interruptible() would result in a deadlock here.
I don't see it. I propose this patch:
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 545c04c..2f658c6 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -327,13 +327,15 @@ static ssize_t cadet_read(struct file *file, char __user
*data, size_t count, lo
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ if (wait_event_interruptible(dev-read_queue,
+dev-rdsin != dev-rdsout))
+ return -EINTR;
mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
Tested with my radio-cadet card.
This looks good to me. If I am still missing something, let me know!
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote: I've chatted a bit with Hans Verkuil about this topic at fosdem and apparently both v4l and alsa have something like this already in their helper libraries. Adding more people as fyi in case they want to switch to the new driver core stuff from Russell. It's not ALSA, but ASoC which has this. Mark is already aware of this and will be looking at it from an ASoC perspective. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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, RFC 07/30] [media] radio-cadet: avoid interruptible_sleep_on race
On 02/07/2014 10:32 AM, Hans Verkuil wrote:
Hi Arnd!
On 01/17/2014 03:28 PM, Arnd Bergmann wrote:
On Friday 17 January 2014, Hans Verkuil wrote:
@@ -323,25 +324,32 @@ static ssize_t cadet_read(struct file *file, char
__user *data, size_t count, lo
struct cadet *dev = video_drvdata(file);
unsigned char readbuf[RDS_BUFFER];
int i = 0;
+ DEFINE_WAIT(wait);
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (1) {
+ prepare_to_wait(dev-read_queue, wait, TASK_INTERRUPTIBLE);
+ if (dev-rdsin != dev-rdsout)
+ break;
+
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ schedule();
mutex_lock(dev-lock);
}
+
This seems overly complicated. Isn't it enough to replace
interruptible_sleep_on
by 'wait_event_interruptible(dev-read_queue, dev-rdsin != dev-rdsout);'?
Or am I missing something subtle?
The existing code sleeps with dev-lock released because the cadet_handler()
function needs to grab (and release) the same lock before it can wake up
the reader thread.
Doing the simple wait_event_interruptible() would result in a deadlock here.
I don't see it. I propose this patch:
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 545c04c..2f658c6 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -327,13 +327,15 @@ static ssize_t cadet_read(struct file *file, char
__user *data, size_t count, lo
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ if (wait_event_interruptible(dev-read_queue,
Oops, that's without an '' before dev-read_queue. I forgot to update my
patch before posting, sorry about that.
Hans
+ dev-rdsin != dev-rdsout))
+ return -EINTR;
mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
Tested with my radio-cadet card.
This looks good to me. If I am still missing something, let me know!
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
--
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, RFC 07/30] [media] radio-cadet: avoid interruptible_sleep_on race
On Friday 07 February 2014 10:32:28 Hans Verkuil wrote:
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ if (wait_event_interruptible(dev-read_queue,
+dev-rdsin != dev-rdsout))
+ return -EINTR;
mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
This will normally work, but now the mutex is no longer
protecting the shared access to the dev-rdsin and
dev-rdsout variables, which was evidently the intention
of the author of the original code.
AFAICT, the possible result is a similar race as before:
if once CPU changes dev-rdsin after the process in
cadet_read dropped the lock, the wakeup may get lost.
It's quite possible this race never happens in practice,
but the code is probably still wrong.
If you think we don't actually need the lock to check
dev-rdsin != dev-rdsout, the code can be simplified
further, to
if ((dev-rdsin == dev-rdsout) (file-f_flags O_NONBLOCK)) {
return -EWOULDBLOCK;
i = wait_event_interruptible(dev-read_queue, dev-rdsin !=
dev-rdsout);
if (i)
return i;
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: omap3isp device tree support
On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 09/01/2014 19:14, Enrico a écrit : On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a cat /dev/zero in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't propagate to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: a https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html I have had what looked a lot like these problems before and it was due to a wrong configuration of the ccdc cropping regarding to the blanking. Could you send me the configuration of the pipeline that you apply with media-ctl, just in case this is the same problem. i'm using: media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl --set-format 'tvp5150 2-005c:0 [UYVY 720x625]' And then capture with yavta -s 720x625 (or 720x576, can't remember right now). Thanks, Enrico I don't think this is sufficient, though I am no expert about omap3 isp, you should configure the format of the ccdc input and of the ccdc output too. When I had this problem, it was solved by adding cropping at the input of the CCDC, corresponding to the blanking period, which was : - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x576 (0,49/720x576)]' or - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x480 (0,45/720x480)]' respectively. I don't know if this can be of any help. Regards, Julien BERAUD It seems i can't set cropping at the CCDC input (sink), but i can on output (source): - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY2X8/720x576 crop.bounds:(0,0)/720x624 crop:(0,48)/720x576] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [fmt:unknown/720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] The strange thing is that with these settings the situation is even worse, i don't get any frames in yavta (while i see interrupts on omap3isp) even with the cat /dev/zero trick. So you are right, playing with cropping can make it work or not, are you sure you could set cropping at the ccdc input? Enrico Enrico, Sorry it didn't work. I just wanted to give a hint of what could be going wrong. I am sorry I don't have time to investigate, I am sure I could set the cropping at the input of ccdc, and that the result was to write register ISPCCDC_VERT_START in order to skip the vertical blanking period correctly. The branch I was on was a bit different though. If you want to investigate this issue, you will at least need to see what is written in the registers of the ISP. Regards, Julien I think i nailed down
Re: [PATCH 27/47] v4l: Add support for DV timings ioctls on subdev nodes
Hi Laurent, Thanks for the patch. On Wed, Feb 05, 2014 at 05:42:18PM +0100, Laurent Pinchart wrote: ... diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 996c248..0ccf9c8 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -354,6 +354,21 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) case VIDIOC_SUBDEV_S_EDID: return v4l2_subdev_call(sd, pad, set_edid, arg); + + case VIDIOC_SUBDEV_DV_TIMINGS_CAP: + return v4l2_subdev_call(sd, pad, dv_timings_cap, arg); + + case VIDIOC_SUBDEV_ENUM_DV_TIMINGS: + return v4l2_subdev_call(sd, pad, enum_dv_timings, arg); + + case VIDIOC_SUBDEV_QUERY_DV_TIMINGS: + return v4l2_subdev_call(sd, video, query_dv_timings, arg); + + case VIDIOC_SUBDEV_G_DV_TIMINGS: + return v4l2_subdev_call(sd, video, g_dv_timings, arg); + + case VIDIOC_SUBDEV_S_DV_TIMINGS: + return v4l2_subdev_call(sd, video, s_dv_timings, arg); Please validate the fields of the argument structs above you can. The pad field at least can be validated. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC 07/30] [media] radio-cadet: avoid interruptible_sleep_on race
On 02/07/2014 11:17 AM, Arnd Bergmann wrote:
On Friday 07 February 2014 10:32:28 Hans Verkuil wrote:
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
+ while (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
+ if (wait_event_interruptible(dev-read_queue,
+dev-rdsin != dev-rdsout))
+ return -EINTR;
mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
This will normally work, but now the mutex is no longer
protecting the shared access to the dev-rdsin and
dev-rdsout variables, which was evidently the intention
of the author of the original code.
AFAICT, the possible result is a similar race as before:
if once CPU changes dev-rdsin after the process in
cadet_read dropped the lock, the wakeup may get lost.
It's quite possible this race never happens in practice,
but the code is probably still wrong.
If you think we don't actually need the lock to check
dev-rdsin != dev-rdsout, the code can be simplified
further, to
if ((dev-rdsin == dev-rdsout) (file-f_flags O_NONBLOCK)) {
return -EWOULDBLOCK;
i = wait_event_interruptible(dev-read_queue, dev-rdsin !=
dev-rdsout);
if (i)
return i;
Arnd
OK, let's try again. This patch is getting bigger and bigger, but it is always
nice to know that your ISA card that almost no one else in the world has is
really,
really working well. :-)
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 545c04c..d27e8b2 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -270,6 +270,16 @@ reset_rds:
outb(inb(dev-io + 1) 0x7f, dev-io + 1);
}
+static bool cadet_has_rds_data(struct cadet *dev)
+{
+ bool result;
+
+ mutex_lock(dev-lock);
+ result = dev-rdsin != dev-rdsout;
+ mutex_unlock(dev-lock);
+ return result;
+}
+
static void cadet_handler(unsigned long data)
{
@@ -279,13 +289,12 @@ static void cadet_handler(unsigned long data)
if (mutex_trylock(dev-lock)) {
outb(0x3, dev-io); /* Select RDS Decoder Control */
if ((inb(dev-io + 1) 0x20) != 0)
- printk(KERN_CRIT cadet: RDS fifo overflow\n);
+ pr_err(cadet: RDS fifo overflow\n);
outb(0x80, dev-io); /* Select RDS fifo */
+
while ((inb(dev-io) 0x80) != 0) {
dev-rdsbuf[dev-rdsin] = inb(dev-io + 1);
- if (dev-rdsin + 1 == dev-rdsout)
- printk(KERN_WARNING cadet: RDS buffer
overflow\n);
- else
+ if (dev-rdsin + 1 != dev-rdsout)
dev-rdsin++;
}
mutex_unlock(dev-lock);
@@ -294,7 +303,7 @@ static void cadet_handler(unsigned long data)
/*
* Service pending read
*/
- if (dev-rdsin != dev-rdsout)
+ if (cadet_has_rds_data(dev))
wake_up_interruptible(dev-read_queue);
/*
@@ -327,22 +336,21 @@ static ssize_t cadet_read(struct file *file, char __user
*data, size_t count, lo
mutex_lock(dev-lock);
if (dev-rdsstat == 0)
cadet_start_rds(dev);
- if (dev-rdsin == dev-rdsout) {
- if (file-f_flags O_NONBLOCK) {
- i = -EWOULDBLOCK;
- goto unlock;
- }
- mutex_unlock(dev-lock);
- interruptible_sleep_on(dev-read_queue);
- mutex_lock(dev-lock);
- }
+ mutex_unlock(dev-lock);
+
+ if (!cadet_has_rds_data(dev) (file-f_flags O_NONBLOCK))
+ return -EWOULDBLOCK;
+ i = wait_event_interruptible(dev-read_queue, cadet_has_rds_data(dev));
+ if (i)
+ return i;
+
+ mutex_lock(dev-lock);
while (i count dev-rdsin != dev-rdsout)
readbuf[i++] = dev-rdsbuf[dev-rdsout++];
+ mutex_unlock(dev-lock);
if (i copy_to_user(data, readbuf, i))
- i = -EFAULT;
-unlock:
- mutex_unlock(dev-lock);
+ return -EFAULT;
return i;
}
@@ -352,7 +360,7 @@ static int vidioc_querycap(struct file *file, void *priv,
{
strlcpy(v-driver, ADS Cadet, sizeof(v-driver));
strlcpy(v-card, ADS Cadet, sizeof(v-card));
- strlcpy(v-bus_info, ISA, sizeof(v-bus_info));
+
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, 7 Feb 2014 09:46:56 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote: I've chatted a bit with Hans Verkuil about this topic at fosdem and apparently both v4l and alsa have something like this already in their helper libraries. Adding more people as fyi in case they want to switch to the new driver core stuff from Russell. It's not ALSA, but ASoC which has this. Mark is already aware of this and will be looking at it from an ASoC perspective. Russell, I started to use your code (which works fine, thanks), and it avoids a lot of problems, especially, about probe_defer in a DT context. I was wondering if your componentised mechanism could be extended to the devices defined by DT. In the DT, when a device_node is a phandle, this means it is referenced by some other device(s), and these device(s) will not start until the phandle device is registered. Then, the idea is to do a component_add() for such phandle devices in device_add() (device_register). Pratically, - the component_add() call in device_register would not include any bind/unbind callback function, so, this should be tested in component_bind/unbind(), - component_add would not be called if the device being added already called component_add in its probe function. A simple flag in the struct device_node should solve this problem. What do you think about this? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 0/7] si4713 enhancements, add miro RDS support
This patch series adds some missing RDS functionality to the si4713 driver. In addition it adds back support for RDS to the radio-miropcm20 driver that was dropped somewhere around the 2.6.2x timeframe. It's been tested with a miropcm20 board, an si4713 board and a si470x based usb stick. 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
[RFC PATCH 1/7] v4l2-ctrls: add new RDS TX controls
From: Hans Verkuil hans.verk...@cisco.com
The si4713 supports several RDS features not yet implemented in the driver.
This patch adds the missing RDS functionality to the list of RDS controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Eduardo Valentin edubez...@gmail.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 17 +
include/uapi/linux/v4l2-controls.h | 9 +
2 files changed, 26 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ff002b..66a2d0b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -794,6 +794,15 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_RDS_TX_PTY: return RDS Program Type;
case V4L2_CID_RDS_TX_PS_NAME: return RDS PS Name;
case V4L2_CID_RDS_TX_RADIO_TEXT:return RDS Radio Text;
+ case V4L2_CID_RDS_TX_MONO_STEREO: return RDS Stereo;
+ case V4L2_CID_RDS_TX_ARTIFICIAL_HEAD: return RDS Artificial Head;
+ case V4L2_CID_RDS_TX_COMPRESSED:return RDS Compressed;
+ case V4L2_CID_RDS_TX_DYNAMIC_PTY: return RDS Dynamic PTY;
+ case V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT: return RDS Traffic
Announcement;
+ case V4L2_CID_RDS_TX_TRAFFIC_PROGRAM: return RDS Traffic Program;
+ case V4L2_CID_RDS_TX_MUSIC_SPEECH: return RDS Music;
+ case V4L2_CID_RDS_TX_ALT_FREQ_ENABLE: return RDS Enable Alternate
Frequency;
+ case V4L2_CID_RDS_TX_ALT_FREQ: return RDS Alternate
Frequency;
case V4L2_CID_AUDIO_LIMITER_ENABLED:return Audio Limiter Feature
Enabled;
case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME: return Audio Limiter Release
Time;
case V4L2_CID_AUDIO_LIMITER_DEVIATION: return Audio Limiter
Deviation;
@@ -906,6 +915,14 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_RDS_RECEPTION:
+ case V4L2_CID_RDS_TX_MONO_STEREO:
+ case V4L2_CID_RDS_TX_ARTIFICIAL_HEAD:
+ case V4L2_CID_RDS_TX_COMPRESSED:
+ case V4L2_CID_RDS_TX_DYNAMIC_PTY:
+ case V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT:
+ case V4L2_CID_RDS_TX_TRAFFIC_PROGRAM:
+ case V4L2_CID_RDS_TX_MUSIC_SPEECH:
+ case V4L2_CID_RDS_TX_ALT_FREQ_ENABLE:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2cbe605..21abf77 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -753,6 +753,15 @@ enum v4l2_auto_focus_range {
#define V4L2_CID_RDS_TX_PTY(V4L2_CID_FM_TX_CLASS_BASE + 3)
#define V4L2_CID_RDS_TX_PS_NAME
(V4L2_CID_FM_TX_CLASS_BASE + 5)
#define V4L2_CID_RDS_TX_RADIO_TEXT (V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_RDS_TX_MONO_STEREO(V4L2_CID_FM_TX_CLASS_BASE + 7)
+#define V4L2_CID_RDS_TX_ARTIFICIAL_HEAD
(V4L2_CID_FM_TX_CLASS_BASE + 8)
+#define V4L2_CID_RDS_TX_COMPRESSED (V4L2_CID_FM_TX_CLASS_BASE + 9)
+#define V4L2_CID_RDS_TX_DYNAMIC_PTY(V4L2_CID_FM_TX_CLASS_BASE + 10)
+#define V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT (V4L2_CID_FM_TX_CLASS_BASE + 11)
+#define V4L2_CID_RDS_TX_TRAFFIC_PROGRAM
(V4L2_CID_FM_TX_CLASS_BASE + 12)
+#define V4L2_CID_RDS_TX_MUSIC_SPEECH (V4L2_CID_FM_TX_CLASS_BASE + 13)
+#define V4L2_CID_RDS_TX_ALT_FREQ_ENABLE
(V4L2_CID_FM_TX_CLASS_BASE + 14)
+#define V4L2_CID_RDS_TX_ALT_FREQ (V4L2_CID_FM_TX_CLASS_BASE + 15)
#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 64)
#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FM_TX_CLASS_BASE + 65)
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/7] si4713: add the missing RDS functionality.
From: Hans Verkuil hans.verk...@cisco.com
Not all the RDS features of the si4713 were supported. Add
the missing bits to fully support the hardware capabilities.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Eduardo Valentin edubez...@gmail.com
---
drivers/media/radio/si4713/si4713.c | 64 -
drivers/media/radio/si4713/si4713.h | 9 ++
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index 07d5153..741db93 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -957,6 +957,41 @@ static int si4713_choose_econtrol_action(struct
si4713_device *sdev, u32 id,
*bit = 5;
*mask = 0x1F 5;
break;
+ case V4L2_CID_RDS_TX_DYNAMIC_PTY:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 15;
+ *mask = 1 15;
+ break;
+ case V4L2_CID_RDS_TX_COMPRESSED:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 14;
+ *mask = 1 14;
+ break;
+ case V4L2_CID_RDS_TX_ARTIFICIAL_HEAD:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 13;
+ *mask = 1 13;
+ break;
+ case V4L2_CID_RDS_TX_MONO_STEREO:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 12;
+ *mask = 1 12;
+ break;
+ case V4L2_CID_RDS_TX_TRAFFIC_PROGRAM:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 10;
+ *mask = 1 10;
+ break;
+ case V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 4;
+ *mask = 1 4;
+ break;
+ case V4L2_CID_RDS_TX_MUSIC_SPEECH:
+ *property = SI4713_TX_RDS_PS_MISC;
+ *bit = 3;
+ *mask = 1 3;
+ break;
case V4L2_CID_AUDIO_LIMITER_ENABLED:
*property = SI4713_TX_ACOMP_ENABLE;
*bit = 1;
@@ -1122,6 +1157,15 @@ static int si4713_s_ctrl(struct v4l2_ctrl *ctrl)
}
break;
+ case V4L2_CID_RDS_TX_ALT_FREQ_ENABLE:
+ case V4L2_CID_RDS_TX_ALT_FREQ:
+ if (sdev-rds_alt_freq_enable-val)
+ val = sdev-rds_alt_freq-val / 100 - 876 +
0xe101;
+ else
+ val = 0xe0e0;
+ ret = si4713_write_property(sdev, SI4713_TX_RDS_PS_AF,
val);
+ break;
+
default:
ret = si4713_choose_econtrol_action(sdev, ctrl-id,
bit,
mask, property, mul, table, size);
@@ -1410,6 +1454,24 @@ static int si4713_probe(struct i2c_client *client,
V4L2_CID_RDS_TX_PI, 0, 0x, 1, DEFAULT_RDS_PI);
sdev-rds_pty = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
V4L2_CID_RDS_TX_PTY, 0, 31, 1, DEFAULT_RDS_PTY);
+ sdev-rds_compressed = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_COMPRESSED, 0, 1, 1, 0);
+ sdev-rds_art_head = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_ARTIFICIAL_HEAD, 0, 1, 1, 0);
+ sdev-rds_stereo = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_MONO_STEREO, 0, 1, 1, 1);
+ sdev-rds_tp = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_TRAFFIC_PROGRAM, 0, 1, 1, 0);
+ sdev-rds_ta = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT, 0, 1, 1, 0);
+ sdev-rds_ms = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_MUSIC_SPEECH, 0, 1, 1, 1);
+ sdev-rds_dyn_pty = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_DYNAMIC_PTY, 0, 1, 1, 0);
+ sdev-rds_alt_freq_enable = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_ALT_FREQ_ENABLE, 0, 1, 1, 0);
+ sdev-rds_alt_freq = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
+ V4L2_CID_RDS_TX_ALT_FREQ, 87600, 107900, 100, 87600);
sdev-rds_deviation = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
V4L2_CID_RDS_TX_DEVIATION, 0, MAX_RDS_DEVIATION,
10, DEFAULT_RDS_DEVIATION);
@@ -1476,7 +1538,7 @@ static int si4713_probe(struct i2c_client *client,
rval = hdl-error;
goto free_ctrls;
}
- v4l2_ctrl_cluster(20, sdev-mute);
+ v4l2_ctrl_cluster(29, sdev-mute);
sdev-sd.ctrl_handler = hdl;
if (client-irq) {
diff --git a/drivers/media/radio/si4713/si4713.h
[RFC PATCH 7/7] radio-miropcm20: add RDS support.
From: Hans Verkuil hans.verk...@cisco.com
Once upon a time the radio-miropcm20 driver had RDS support. However, after
some internal kernel changes that support was removed. Now that we have a
nice RDS API I have been working on adding back this support. It has been
tested with the si4713 RDS transmitter and it is working quite nicely.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-miropcm20.c | 303 --
1 file changed, 286 insertions(+), 17 deletions(-)
diff --git a/drivers/media/radio/radio-miropcm20.c
b/drivers/media/radio/radio-miropcm20.c
index a7e93d7..62cda88 100644
--- a/drivers/media/radio/radio-miropcm20.c
+++ b/drivers/media/radio/radio-miropcm20.c
@@ -1,20 +1,35 @@
-/* Miro PCM20 radio driver for Linux radio support
+/*
+ * Miro PCM20 radio driver for Linux radio support
* (c) 1998 Ruurd Reitsma r.a.reit...@wbmt.tudelft.nl
* Thanks to Norberto Pellici for the ACI device interface specification
* The API part is based on the radiotrack driver by M. Kirkwood
* This driver relies on the aci mixer provided by the snd-miro
* ALSA driver.
* Look there for further info...
- */
-
-/* What ever you think about the ACI, version 0x07 is not very well!
- * I can't get frequency, 'tuner status', 'tuner flags' or mute/mono
- * conditions...Robert
+ *
+ * From the original miro RDS sources:
+ *
+ * (c) 2001 Robert Siemer robert.sie...@gmx.de
+ *
+ * Many thanks to Fred Seidel sei...@metabox.de, the
+ * designer of the RDS decoder hardware. With his help
+ * I was able to code this driver.
+ * Thanks also to Norberto Pellicci, Dominic Mounteney
+ * dmounte...@pinnaclesys.com and www.teleauskunft.de
+ * for good hints on finding Fred. It was somewhat hard
+ * to locate him here in Germany... [:
+ *
+ * This code has been reintroduced and converted to use
+ * the new V4L2 RDS API by:
+ *
+ * Hans Verkuil hans.verk...@cisco.com
*/
#include linux/module.h
#include linux/init.h
+#include linux/delay.h
#include linux/videodev2.h
+#include linux/kthread.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
@@ -22,6 +37,22 @@
#include media/v4l2-event.h
#include sound/aci.h
+#define RDS_DATASHIFT 2 /* Bit 2 */
+#define RDS_DATAMASK(1 RDS_DATASHIFT)
+#define RDS_BUSYMASK0x10 /* Bit 4 */
+#define RDS_CLOCKMASK 0x08 /* Bit 3 */
+#define RDS_DATA(x) (((x) RDS_DATASHIFT) 1)
+
+#define RDS_STATUS 0x01
+#define RDS_STATIONNAME 0x02
+#define RDS_TEXT0x03
+#define RDS_ALTFREQ 0x04
+#define RDS_TIMEDATE0x05
+#define RDS_PI_CODE 0x06
+#define RDS_PTYTATP 0x07
+#define RDS_RESET 0x08
+#define RDS_RXVALUE 0x09
+
static int radio_nr = -1;
module_param(radio_nr, int, 0);
MODULE_PARM_DESC(radio_nr, Set radio device number (/dev/radioX). Default:
-1 (autodetect));
@@ -30,6 +61,14 @@ struct pcm20 {
struct v4l2_device v4l2_dev;
struct video_device vdev;
struct v4l2_ctrl_handler ctrl_handler;
+ struct v4l2_ctrl *rds_pty;
+ struct v4l2_ctrl *rds_ps_name;
+ struct v4l2_ctrl *rds_radio_test;
+ struct v4l2_ctrl *rds_ta;
+ struct v4l2_ctrl *rds_tp;
+ struct v4l2_ctrl *rds_ms;
+ /* thread for periodic RDS status checking */
+ struct task_struct *kthread;
unsigned long freq;
u32 audmode;
struct snd_miro_aci *aci;
@@ -41,6 +80,103 @@ static struct pcm20 pcm20_card = {
.audmode = V4L2_TUNER_MODE_STEREO,
};
+
+static int rds_waitread(struct snd_miro_aci *aci)
+{
+ u8 byte;
+ int i = 2000;
+
+ do {
+ byte = inb(aci-aci_port + ACI_REG_RDS);
+ i--;
+ } while ((byte RDS_BUSYMASK) i);
+
+ /*
+* It's magic, but without this the data that you read later on
+* is unreliable and full of bit errors. With this 1 usec delay
+* everything is fine.
+*/
+ udelay(1);
+ return i ? byte : -1;
+}
+
+static int rds_rawwrite(struct snd_miro_aci *aci, u8 byte)
+{
+ if (rds_waitread(aci) = 0) {
+ outb(byte, aci-aci_port + ACI_REG_RDS);
+ return 0;
+ }
+ return -1;
+}
+
+static int rds_write(struct snd_miro_aci *aci, u8 byte)
+{
+ u8 sendbuffer[8];
+ int i;
+
+ for (i = 7; i = 0; i--)
+ sendbuffer[7 - i] = (byte (1 i)) ? RDS_DATAMASK : 0;
+ sendbuffer[0] |= RDS_CLOCKMASK;
+
+ for (i = 0; i 8; i++)
+ rds_rawwrite(aci, sendbuffer[i]);
+ return 0;
+}
+
+static int rds_readcycle_nowait(struct snd_miro_aci *aci)
+{
+ outb(0, aci-aci_port + ACI_REG_RDS);
+ return rds_waitread(aci);
+}
+
+static int rds_readcycle(struct snd_miro_aci *aci)
+{
+ if (rds_rawwrite(aci, 0) 0)
+ return -1;
+ return rds_waitread(aci);
+}
+
+static int rds_ack(struct snd_miro_aci *aci)
+{
+ int i =
[RFC PATCH 5/7] DocBook/media: document the new RDS RX controls
From: Hans Verkuil hans.verk...@cisco.com Document the new RDS receiver controls. This will be used by the radio-miropcm20 driver. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/controls.xml | 51 1 file changed, 51 insertions(+) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 58fd169..29f7ffc 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4998,6 +4998,57 @@ description of this control class./entry /rowrowentry spanname=descrEnables/disables RDS reception by the radio tuner/entry /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrGets RDS Programme Type field. +This encodes up to 31 pre-defined programme types./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_PS_NAME/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrGets the Programme Service name (PS_NAME). +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. In Annex E of xref linkend=iec62106 /, the RDS specification, +there is a full description of the correct character encoding for Programme Service name strings. +Also from RDS specification, PS is usually a single eight character text. However, it is also possible +to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured +with steps of 8 characters. The result is it must always contain a string with size multiple of 8./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_RADIO_TEXT/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrGets the Radio Text info. It is a textual description of +what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names, +programme-related information or any other text. In these cases, RadioText can be used in addition to +constantV4L2_CID_RDS_RX_PS_NAME/constant. The encoding for Radio Text strings is also fully described +in Annex E of xref linkend=iec62106 /. The length of Radio Text strings depends on which RDS Block is being +used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible +to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured +with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. /entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then a traffic announcement is in progress./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_TRAFFIC_PROGRAM/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then the tuned programme carries traffic announcements./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RX_MUSIC_SPEECH/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then this channel broadcasts music. If cleared, then it +broadcasts speech. If the transmitter doesn't make this distinction, then it will be set./entry + /row row entry spanname=idconstantV4L2_CID_TUNE_DEEMPHASIS/constantnbsp;/entry entryenum v4l2_deemphasis/entry -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/7] DocBook/media: document the new RDS TX controls
From: Hans Verkuil hans.verk...@cisco.com Document the new RDS features that will be supported by the si4713 driver. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Cc: Eduardo Valentin edubez...@gmail.com --- Documentation/DocBook/media/v4l/controls.xml | 60 1 file changed, 60 insertions(+) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a5a3188..58fd169 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3980,6 +3980,66 @@ to find receivers which can scroll strings sized as 32 x N or 64 x N characters. with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. /entry /row row + entry spanname=idconstantV4L2_CID_RDS_TX_MONO_STEREO/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrSets the Mono/Stereo bit of the Decoder Identification code. If set, +then the audio was recorded as stereo./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_ARTIFICIAL_HEAD/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrSets the +ulink url=http://en.wikipedia.org/wiki/Artificial_head;Artificial Head/ulink bit of the Decoder +Identification code. If set, then the audio was recorded using an artificial head./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_COMPRESSED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrSets the Compressed bit of the Decoder Identification code. If set, +then the audio is compressed./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_DYNAMIC_PTY/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrSets the Dynamic PTY bit of the Decoder Identification code. If set, +then the PTY code is dynamically switched./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then a traffic announcement is in progress./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_TRAFFIC_PROGRAM/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then the tuned programme carries traffic announcements./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_MUSIC_SPEECH/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then this channel broadcasts music. If cleared, then it +broadcasts speech. If the transmitter doesn't make this distinction, then it should be set./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_ALT_FREQ_ENABLE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf set, then transmit alternate frequencies./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_FREQ/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrThe alternate frequency (in Hz)./entry + /row + row entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_ENABLED/constantnbsp;/entry entryboolean/entry /row -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/7] v4l2-ctrls: add support for setting string controls
From: Hans Verkuil hans.verk...@cisco.com
Rather than always having to use a v4l2_ext_control struct to set
a control value from within a driver, switch to just setting the
new value. This is faster and it makes it possible to set more
complex types such as a string control.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 46
include/media/v4l2-ctrls.h | 12 ++
2 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 7c138b5..2aad5c6 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2786,26 +2786,22 @@ static int set_ctrl(struct v4l2_fh *fh, struct
v4l2_ctrl *ctrl,
struct v4l2_ctrl *master = ctrl-cluster[0];
int i;
- /* String controls are not supported. The user_to_new() and
-* cur_to_user() calls below would need to be modified not to access
-* userspace memory when called from set_ctrl().
-*/
- if (ctrl-type == V4L2_CTRL_TYPE_STRING)
- return -EINVAL;
-
/* Reset the 'is_new' flags of the cluster */
for (i = 0; i master-ncontrols; i++)
if (master-cluster[i])
master-cluster[i]-is_new = 0;
+ if (c)
+ user_to_new(c, ctrl);
+
/* For autoclusters with volatiles that are switched from auto to
manual mode we have to update the current volatile values since
those will become the initial manual values after such a switch. */
if (master-is_auto master-has_volatiles ctrl == master
- !is_cur_manual(master) c-value == master-manual_mode_value)
+ !is_cur_manual(master) ctrl-val == master-manual_mode_value)
update_from_auto_cluster(master);
- user_to_new(c, ctrl);
+ ctrl-is_new = 1;
return try_or_set_cluster(fh, master, true, ch_flags);
}
@@ -2853,26 +2849,46 @@ EXPORT_SYMBOL(v4l2_subdev_s_ctrl);
int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val)
{
- struct v4l2_ext_control c;
+ int ret;
/* It's a driver bug if this happens. */
WARN_ON(!type_is_int(ctrl));
- c.value = val;
- return set_ctrl_lock(NULL, ctrl, c);
+ v4l2_ctrl_lock(ctrl);
+ ctrl-val = val;
+ ret = set_ctrl(NULL, ctrl, NULL, 0);
+ v4l2_ctrl_unlock(ctrl);
+ return ret;
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl);
int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 val)
{
- struct v4l2_ext_control c;
+ int ret;
/* It's a driver bug if this happens. */
WARN_ON(ctrl-type != V4L2_CTRL_TYPE_INTEGER64);
- c.value64 = val;
- return set_ctrl_lock(NULL, ctrl, c);
+ v4l2_ctrl_lock(ctrl);
+ ctrl-val64 = val;
+ ret = set_ctrl(NULL, ctrl, NULL, 0);
+ v4l2_ctrl_unlock(ctrl);
+ return ret;
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_int64);
+int v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const char *s)
+{
+ int ret;
+
+ /* It's a driver bug if this happens. */
+ WARN_ON(ctrl-type != V4L2_CTRL_TYPE_STRING);
+ v4l2_ctrl_lock(ctrl);
+ strlcpy(ctrl-string, s, ctrl-maximum + 1);
+ ret = set_ctrl(NULL, ctrl, NULL, 0);
+ v4l2_ctrl_unlock(ctrl);
+ return ret;
+}
+EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_string);
+
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify,
void *priv)
{
if (ctrl == NULL)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 16f7f26..ee00f11 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -640,6 +640,18 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl);
*/
int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 val);
+/** v4l2_ctrl_s_ctrl_string() - Helper function to set a control's string
value from within a driver.
+ * @ctrl: The control.
+ * @s:The new string.
+ *
+ * This set the control's new string safely by going through the control
+ * framework. This function will lock the control's handler, so it cannot be
+ * used from within the v4l2_ctrl_ops functions.
+ *
+ * This function is for string type controls only.
+ */
+int v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const char *s);
+
/* Internal helper functions that deal with control events. */
extern const struct v4l2_subscribed_event_ops v4l2_ctrl_sub_ev_ops;
void v4l2_ctrl_replace(struct v4l2_event *old, const struct v4l2_event *new);
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/7] v4l2-ctrls: add RX RDS controls.
From: Hans Verkuil hans.verk...@cisco.com
The radio-miropcm20 driver has firmware that decodes the RDS signals. So in that
case the RDS data becomes available in the form of controls.
Add support for these controls to the control framework, allowing the miro
driver
to use them.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 17 +
include/uapi/linux/v4l2-controls.h | 6 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 66a2d0b..7c138b5 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -866,6 +866,12 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FM_RX_CLASS: return FM Radio Receiver
Controls;
case V4L2_CID_TUNE_DEEMPHASIS: return De-Emphasis;
case V4L2_CID_RDS_RECEPTION:return RDS Reception;
+ case V4L2_CID_RDS_RX_PTY: return RDS Program Type;
+ case V4L2_CID_RDS_RX_PS_NAME: return RDS PS Name;
+ case V4L2_CID_RDS_RX_RADIO_TEXT:return RDS Radio Text;
+ case V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT: return RDS Traffic
Announcement;
+ case V4L2_CID_RDS_RX_TRAFFIC_PROGRAM: return RDS Traffic Program;
+ case V4L2_CID_RDS_RX_MUSIC_SPEECH: return RDS Music;
default:
return NULL;
}
@@ -923,6 +929,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_RDS_TX_TRAFFIC_PROGRAM:
case V4L2_CID_RDS_TX_MUSIC_SPEECH:
case V4L2_CID_RDS_TX_ALT_FREQ_ENABLE:
+ case V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT:
+ case V4L2_CID_RDS_RX_TRAFFIC_PROGRAM:
+ case V4L2_CID_RDS_RX_MUSIC_SPEECH:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -990,6 +999,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
break;
case V4L2_CID_RDS_TX_PS_NAME:
case V4L2_CID_RDS_TX_RADIO_TEXT:
+ case V4L2_CID_RDS_RX_PS_NAME:
+ case V4L2_CID_RDS_RX_RADIO_TEXT:
*type = V4L2_CTRL_TYPE_STRING;
break;
case V4L2_CID_ISO_SENSITIVITY:
@@ -1096,6 +1107,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DV_TX_RXSENSE:
case V4L2_CID_DV_TX_EDID_PRESENT:
case V4L2_CID_DV_RX_POWER_PRESENT:
+ case V4L2_CID_RDS_RX_PTY:
+ case V4L2_CID_RDS_RX_PS_NAME:
+ case V4L2_CID_RDS_RX_RADIO_TEXT:
+ case V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT:
+ case V4L2_CID_RDS_RX_TRAFFIC_PROGRAM:
+ case V4L2_CID_RDS_RX_MUSIC_SPEECH:
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
}
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 21abf77..52c9679 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -903,5 +903,11 @@ enum v4l2_deemphasis {
};
#define V4L2_CID_RDS_RECEPTION (V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_RX_PTY(V4L2_CID_FM_RX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_RX_PS_NAME
(V4L2_CID_FM_RX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RX_RADIO_TEXT (V4L2_CID_FM_RX_CLASS_BASE + 5)
+#define V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT (V4L2_CID_FM_RX_CLASS_BASE + 6)
+#define V4L2_CID_RDS_RX_TRAFFIC_PROGRAM
(V4L2_CID_FM_RX_CLASS_BASE + 7)
+#define V4L2_CID_RDS_RX_MUSIC_SPEECH (V4L2_CID_FM_RX_CLASS_BASE + 8)
#endif
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Feb 07, 2014 at 12:57:21PM +0100, Jean-Francois Moine wrote: I started to use your code (which works fine, thanks), and it avoids a lot of problems, especially, about probe_defer in a DT context. I was wondering if your componentised mechanism could be extended to the devices defined by DT. It was developed against imx-drm, which is purely DT based. I already have a solution for the cubox armada DRM. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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 07/24] xc5000: properly report i2c write failures
I can't load firmware like error of below link.
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/1263837
This error is related with this patch. This fix is right but above error is
created after this fix
because my device makes WatchDogTimer to 0 when load firmware.
Maybe it will be related with XREG_BUSY register but i can't check it.
I removed this fix, but i have faced at other error with xc5000: PLL not
running after fwload
So i have commented like below.
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
.name = XC5000A_FIRMWARE,
.size = 12401,
//.pll_reg = 0x806c,
};
Then, xc5000 device works well.
I don't have xc5000 datasheet so i can't debug xc5000 driver anymore.
Hi Joonyoung,
Assuming this is the DViCO FusionHDTV7 device that uses the
au0828/au8522, I suspect that what's happening here is your I2C
controller is not stable. The I2C clock stretching done by the xc5000
often exposed bugs in various bridge drivers and the au0828 was no
exception. I had to work around these hardware bugs in the au0828
driver but I made them specific to the HVR-950q since that was the
only device I could test with.
In other words, the xc5000 is most likely doing exactly what it is
supposed to, and the increased robustness of the tuner driver with
those two patches exposed intermittent I2C failures in au0828 that
were previously being silently discarded (resulting in indeterminate
behavior).
I would recommending looking at the changes in au0828-cards.c for the
HVR-950q and add the code necessary to make them also apply for the
DVICO device, and that should resolve your problems (in particular the
i2c_clk_divider field should be set).
Devin
--
Devin J. Heitmueller - 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
[GIT PULL for v3.14-rc2] media fixes
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
For a series of small fixes. Mostly driver ones. There is one core
regression fix on a patch that was meant to fix some race issues on
vb2, but that actually caused more harm than good. So, we're just
reverting it for now.
Thanks!
Mauro
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
for you to fetch changes up to 57f0547fbc1e925f5e58c76f311a6632c3f37740:
[media] adv7842: Composite free-run platfrom-data fix (2014-02-04 06:46:10
-0200)
Alexey Khoroshilov (1):
[media] go7007-loader: fix usb_dev leak
Andi Shyti (2):
[media] cx24117: remove dead code in always 'false' if statement
[media] cx24117: use a valid dev pointer for dev_err printout
Andrzej Hajda (1):
[media] s5k5baf: allow to handle arbitrary long i2c sequences
Antti Palosaari (1):
[media] af9035: add ID [2040:f900] Hauppauge WinTV-MiniStick 2
Dave Jones (2):
[media] mxl111sf: Fix unintentional garbage stack read
[media] mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset
Hans Verkuil (1):
[media] Revert [media] videobuf_vm_{open,close} race fixes
Jacek Anaszewski (1):
[media] s5p-jpeg: Fix wrong NV12 format parameters
Levente Kurusa (1):
[media] media: bt8xx: add missing put_device call
Martin Bugge (2):
[media] v4l2-dv-timings: fix GTF calculation
[media] adv7842: Composite free-run platfrom-data fix
Masanari Iida (1):
[media] hdpvr: Fix memory leak in debug
Mauro Carvalho Chehab (1):
Merge tag 'v3.14-rc1' into patchwork
Michael Krufky (1):
[media] update Michael Krufky's email address
Ricardo Ribalda (1):
[media] vb2: Check if there are buffers before streamon
Sylwester Nawrocki (3):
[media] exynos4-is: Fix error paths in probe() for !pm_runtime_enabled()
[media] exynos4-is: Compile in fimc runtime PM callbacks conditionally
[media] exynos4-is: Compile in fimc-lite runtime PM callbacks
conditionally
Documentation/dvb/contributors.txt| 2 +-
drivers/media/dvb-frontends/cx24117.c | 10 +
drivers/media/dvb-frontends/nxt200x.c | 2 +-
drivers/media/i2c/adv7842.c | 2 +-
drivers/media/i2c/s5k5baf.c | 30 +--
drivers/media/pci/bt8xx/bttv-cards.c | 2 +-
drivers/media/pci/bt8xx/bttv-gpio.c | 2 +-
drivers/media/pci/saa7134/saa7134-cards.c | 2 +-
drivers/media/platform/exynos4-is/fimc-core.c | 5 -
drivers/media/platform/exynos4-is/fimc-lite.c | 7 +--
drivers/media/platform/s5p-jpeg/jpeg-core.c | 8 +++
drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++
drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c | 4 ++--
drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-phy.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-reg.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c | 4 ++--
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h | 4 ++--
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 6 +++---
drivers/media/usb/dvb-usb-v2/mxl111sf.h | 2 +-
drivers/media/usb/hdpvr/hdpvr-core.c | 4 +++-
drivers/media/v4l2-core/v4l2-dv-timings.c | 1 +
drivers/media/v4l2-core/videobuf-dma-contig.c | 12 +--
drivers/media/v4l2-core/videobuf-dma-sg.c | 10 -
drivers/media/v4l2-core/videobuf-vmalloc.c| 10 -
drivers/media/v4l2-core/videobuf2-core.c | 5 +
drivers/staging/media/go7007/go7007-loader.c | 4 +++-
32 files changed, 84 insertions(+), 72 deletions(-)
--
Cheers,
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 23/52] v4l: add new tuner types for SDR
Em Sat, 25 Jan 2014 19:10:17 +0200
Antti Palosaari cr...@iki.fi escreveu:
Define tuner types V4L2_TUNER_ADC and V4L2_TUNER_RF for SDR usage.
ADC is used for setting sampling rate (sampling frequency) to SDR
device.
Another tuner type, named as V4L2_TUNER_RF, is possible RF tuner.
Is is used to down-convert RF frequency to range ADC could sample.
Having RF tuner is optional, whilst in practice it is almost always
there.
Also add checks to VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY and
VIDIOC_ENUM_FREQ_BANDS only allow these two tuner types when device
type is SDR (VFL_TYPE_SDR). For VIDIOC_G_FREQUENCY we do not check
tuner type, instead override type with V4L2_TUNER_ADC in every
case (requested by Hans in order to keep functionality in line with
existing tuners and existing API does not specify it).
Prohibit VIDIOC_S_HW_FREQ_SEEK explicitly when device type is SDR,
as device cannot do hardware seek without a hardware demodulator.
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ioctl.c | 39
++--
include/uapi/linux/videodev2.h | 2 ++
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 707aef7..15ab349 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1291,8 +1291,11 @@ static int v4l_g_frequency(const struct v4l2_ioctl_ops
*ops,
struct video_device *vfd = video_devdata(file);
struct v4l2_frequency *p = arg;
- p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ if (vfd-vfl_type == VFL_TYPE_SDR)
+ p-type = V4L2_TUNER_ADC;
+ else
+ p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
return ops-vidioc_g_frequency(file, fh, p);
}
@@ -1303,10 +1306,15 @@ static int v4l_s_frequency(const struct
v4l2_ioctl_ops *ops,
const struct v4l2_frequency *p = arg;
enum v4l2_tuner_type type;
- type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- if (p-type != type)
- return -EINVAL;
+ if (vfd-vfl_type == VFL_TYPE_SDR) {
+ if (p-type != V4L2_TUNER_ADC p-type != V4L2_TUNER_RF)
+ return -EINVAL;
+ } else {
+ type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ if (type != p-type)
+ return -EINVAL;
+ }
return ops-vidioc_s_frequency(file, fh, p);
}
@@ -1386,6 +1394,10 @@ static int v4l_s_hw_freq_seek(const struct
v4l2_ioctl_ops *ops,
struct v4l2_hw_freq_seek *p = arg;
enum v4l2_tuner_type type;
+ /* s_hw_freq_seek is not supported for SDR for now */
+ if (vfd-vfl_type == VFL_TYPE_SDR)
+ return -EINVAL;
A minor issue: return code here is IMHO wrong. It should be -ENOTTY.
It makes sense to add a printk_once() to warn about it, as, if we ever
need it for SDR, people could lose hours debugging why this is not work
until finally discovering that the Kernel is blocking such call.
In any case, I'll apply this patch. Please send a fix on a next series.
+
type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
if (p-type != type)
@@ -1885,11 +1897,16 @@ static int v4l_enum_freq_bands(const struct
v4l2_ioctl_ops *ops,
enum v4l2_tuner_type type;
int err;
- type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
-
- if (type != p-type)
- return -EINVAL;
+ if (vfd-vfl_type == VFL_TYPE_SDR) {
+ if (p-type != V4L2_TUNER_ADC p-type != V4L2_TUNER_RF)
+ return -EINVAL;
+ type = p-type;
+ } else {
+ type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ if (type != p-type)
+ return -EINVAL;
+ }
if (ops-vidioc_enum_freq_bands)
return ops-vidioc_enum_freq_bands(file, fh, p);
if (is_valid_ioctl(vfd, VIDIOC_G_TUNER)) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..9dc79d1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -159,6 +159,8 @@ enum v4l2_tuner_type {
V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2,
V4L2_TUNER_DIGITAL_TV= 3,
+ V4L2_TUNER_ADC = 4,
+ V4L2_TUNER_RF= 5,
};
enum v4l2_memory {
--
[PATCH v3] v4l2-subdev: Allow 32-bit compat ioctls
Add support for 32-bit ioctls with v4l-subdev device nodes.
Rather than keep adding new ioctls to the list in v4l2-compat-ioctl32.c, just
check
if the ioctl is a non-private V4L2 ioctl and if so, call the conversion code.
We keep forgetting to add new ioctls, so this is a more robust solution.
In addition extend the subdev API with support for a compat32 function to
convert custom v4l-subdev ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 8f7a6a4..1b18616 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -1006,103 +1006,14 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
int cmd, unsigned long arg)
if (!file-f_op-unlocked_ioctl)
return ret;
- switch (cmd) {
- case VIDIOC_QUERYCAP:
- case VIDIOC_RESERVED:
- case VIDIOC_ENUM_FMT:
- case VIDIOC_G_FMT32:
- case VIDIOC_S_FMT32:
- case VIDIOC_REQBUFS:
- case VIDIOC_QUERYBUF32:
- case VIDIOC_G_FBUF32:
- case VIDIOC_S_FBUF32:
- case VIDIOC_OVERLAY32:
- case VIDIOC_QBUF32:
- case VIDIOC_EXPBUF:
- case VIDIOC_DQBUF32:
- case VIDIOC_STREAMON32:
- case VIDIOC_STREAMOFF32:
- case VIDIOC_G_PARM:
- case VIDIOC_S_PARM:
- case VIDIOC_G_STD:
- case VIDIOC_S_STD:
- case VIDIOC_ENUMSTD32:
- case VIDIOC_ENUMINPUT32:
- case VIDIOC_G_CTRL:
- case VIDIOC_S_CTRL:
- case VIDIOC_G_TUNER:
- case VIDIOC_S_TUNER:
- case VIDIOC_G_AUDIO:
- case VIDIOC_S_AUDIO:
- case VIDIOC_QUERYCTRL:
- case VIDIOC_QUERYMENU:
- case VIDIOC_G_INPUT32:
- case VIDIOC_S_INPUT32:
- case VIDIOC_G_OUTPUT32:
- case VIDIOC_S_OUTPUT32:
- case VIDIOC_ENUMOUTPUT:
- case VIDIOC_G_AUDOUT:
- case VIDIOC_S_AUDOUT:
- case VIDIOC_G_MODULATOR:
- case VIDIOC_S_MODULATOR:
- case VIDIOC_S_FREQUENCY:
- case VIDIOC_G_FREQUENCY:
- case VIDIOC_CROPCAP:
- case VIDIOC_G_CROP:
- case VIDIOC_S_CROP:
- case VIDIOC_G_SELECTION:
- case VIDIOC_S_SELECTION:
- case VIDIOC_G_JPEGCOMP:
- case VIDIOC_S_JPEGCOMP:
- case VIDIOC_QUERYSTD:
- case VIDIOC_TRY_FMT32:
- case VIDIOC_ENUMAUDIO:
- case VIDIOC_ENUMAUDOUT:
- case VIDIOC_G_PRIORITY:
- case VIDIOC_S_PRIORITY:
- case VIDIOC_G_SLICED_VBI_CAP:
- case VIDIOC_LOG_STATUS:
- case VIDIOC_G_EXT_CTRLS32:
- case VIDIOC_S_EXT_CTRLS32:
- case VIDIOC_TRY_EXT_CTRLS32:
- case VIDIOC_ENUM_FRAMESIZES:
- case VIDIOC_ENUM_FRAMEINTERVALS:
- case VIDIOC_G_ENC_INDEX:
- case VIDIOC_ENCODER_CMD:
- case VIDIOC_TRY_ENCODER_CMD:
- case VIDIOC_DECODER_CMD:
- case VIDIOC_TRY_DECODER_CMD:
- case VIDIOC_DBG_S_REGISTER:
- case VIDIOC_DBG_G_REGISTER:
- case VIDIOC_S_HW_FREQ_SEEK:
- case VIDIOC_S_DV_TIMINGS:
- case VIDIOC_G_DV_TIMINGS:
- case VIDIOC_DQEVENT:
- case VIDIOC_DQEVENT32:
- case VIDIOC_SUBSCRIBE_EVENT:
- case VIDIOC_UNSUBSCRIBE_EVENT:
- case VIDIOC_CREATE_BUFS32:
- case VIDIOC_PREPARE_BUF32:
- case VIDIOC_ENUM_DV_TIMINGS:
- case VIDIOC_QUERY_DV_TIMINGS:
- case VIDIOC_DV_TIMINGS_CAP:
- case VIDIOC_ENUM_FREQ_BANDS:
- case VIDIOC_SUBDEV_G_EDID32:
- case VIDIOC_SUBDEV_S_EDID32:
+ if (_IOC_TYPE(cmd) == 'V' _IOC_NR(cmd) BASE_VIDIOC_PRIVATE)
ret = do_video_ioctl(file, cmd, arg);
- break;
+ else if (vdev-fops-compat_ioctl32)
+ ret = vdev-fops-compat_ioctl32(file, cmd, arg);
- default:
- if (vdev-fops-compat_ioctl32)
- ret = vdev-fops-compat_ioctl32(file, cmd, arg);
-
- if (ret == -ENOIOCTLCMD)
- printk(KERN_WARNING compat_ioctl32:
- unknown ioctl '%c', dir=%d, #%d (0x%08x)\n,
- _IOC_TYPE(cmd), _IOC_DIR(cmd), _IOC_NR(cmd),
- cmd);
- break;
- }
+ if (ret == -ENOIOCTLCMD)
+ pr_warn(compat_ioctl32: unknown ioctl '%c', dir=%d, #%d
(0x%08x)\n,
+ _IOC_TYPE(cmd), _IOC_DIR(cmd), _IOC_NR(cmd), cmd);
return ret;
}
EXPORT_SYMBOL_GPL(v4l2_compat_ioctl32);
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 996c248..60d2550 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -368,6 +368,17 @@ static long subdev_ioctl(struct file *file, unsigned int
cmd,
return video_usercopy(file, cmd, arg, subdev_do_ioctl);
}
+#ifdef CONFIG_COMPAT
+static long subdev_compat_ioctl32(struct file *file, unsigned int cmd,
+ unsigned long
[PATCH] Add Antti at the V4L2 revision list
Add SDR to V3.15 revlist, and add the credits to Antti. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- Documentation/DocBook/media/v4l/v4l2.xml | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index e826d1d5df08..61a7bb1faccf 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -107,6 +107,16 @@ Remote Controller chapter./contrib /address /affiliation /author + author + firstnameAntti/firstname + surnamePalosaari/surname + contribSDR API./contrib + affiliation + address + emailcr...@iki.fi/email + /address + /affiliation + /author /authorgroup copyright @@ -144,10 +154,10 @@ applications. -- revision revnumber3.15/revnumber date2014-02-03/date - authorinitialshv/authorinitials + authorinitialshv, ap/authorinitials revremarkUpdate several sections of Common API Elements: Opening and Closing Devices Querying Capabilities, Application Priority, Video Inputs and Outputs, Audio Inputs and Outputs -Tuners and Modulators, Video Standards and Digital Video (DV) Timings. +Tuners and Modulators, Video Standards and Digital Video (DV) Timings. Added SDR API. /revremark /revision -- 1.8.3.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
[git:media_tree/master] [media] media: rc: change 32bit NEC scancode format
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] media: rc: change 32bit NEC scancode format
Author: James Hogan james.ho...@imgtec.com
Date:Fri Jan 17 10:58:50 2014 -0300
Change 32bit NEC scancode format (used by Apple and TiVo remotes) to
encode the data with the correct bit order. Previously the raw bits were
used without being bit reversed, now each 16bit half is bit reversed
compared to before.
So for the raw NEC data:
(LSB/First) 0xAAaaCCcc (MSB/Last)
(where traditionally AA=address, aa=~address, CC=command, cc=~command)
We now generate the scancodes:
(MSB) 0xAACC (LSB) (normal NEC)
(MSB) 0x00AAaaCC (LSB) (extended NEC, address check wrong)
(MSB) 0xaaAAccCC (LSB) (32-bit NEC, command check wrong)
Note that the address byte order in 32-bit NEC scancodes is different to
that of the extended NEC scancodes. I chose this way as it maintains the
order of the bits in the address/command fields, and CC is clearly
intended to be the LSB of the command if the TiVo codes are anything to
go by so it makes sense for AA to also be the LSB.
The TiVo keymap is updated accordingly.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Jarod Wilson ja...@redhat.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
drivers/media/rc/ir-nec-decoder.c |5 ++-
drivers/media/rc/keymaps/rc-tivo.c | 86 ++--
2 files changed, 47 insertions(+), 44 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=18bc17448147e93f31cc9b1a83be49f1224657b2
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 9a90094..1bab7ea 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -172,7 +172,10 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
if (send_32bits) {
/* NEC transport, but modified protocol, used by at
* least Apple and TiVo remotes */
- scancode = data-bits;
+ scancode = not_address 24 |
+ address 16 |
+ not_command 8 |
+ command;
IR_dprintk(1, NEC (modified) scancode 0x%08x\n,
scancode);
} else if ((address ^ not_address) != 0xff) {
/* Extended NEC */
diff --git a/drivers/media/rc/keymaps/rc-tivo.c
b/drivers/media/rc/keymaps/rc-tivo.c
index 454e062..5cc1b45 100644
--- a/drivers/media/rc/keymaps/rc-tivo.c
+++ b/drivers/media/rc/keymaps/rc-tivo.c
@@ -15,62 +15,62 @@
* Initial mapping is for the TiVo remote included in the Nero LiquidTV bundle,
* which also ships with a TiVo-branded IR transceiver, supported by the mceusb
* driver. Note that the remote uses an NEC-ish protocol, but instead of having
- * a command/not_command pair, it has a vendor ID of 0xa10c, but some keys, the
+ * a command/not_command pair, it has a vendor ID of 0x3085, but some keys, the
* NEC extended checksums do pass, so the table presently has the intended
* values and the checksum-passed versions for those keys.
*/
static struct rc_map_table tivo[] = {
- { 0xa10c900f, KEY_MEDIA }, /* TiVo Button */
- { 0xa10c0807, KEY_POWER2 }, /* TV Power */
- { 0xa10c8807, KEY_TV }, /* Live TV/Swap */
- { 0xa10c2c03, KEY_VIDEO_NEXT }, /* TV Input */
- { 0xa10cc807, KEY_INFO },
- { 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
+ { 0x3085f009, KEY_MEDIA }, /* TiVo Button */
+ { 0x3085e010, KEY_POWER2 }, /* TV Power */
+ { 0x3085e011, KEY_TV }, /* Live TV/Swap */
+ { 0x3085c034, KEY_VIDEO_NEXT }, /* TV Input */
+ { 0x3085e013, KEY_INFO },
+ { 0x3085a05f, KEY_CYCLEWINDOWS }, /* Window */
{ 0x0085305f, KEY_CYCLEWINDOWS },
- { 0xa10c6c03, KEY_EPG },/* Guide */
+ { 0x3085c036, KEY_EPG },/* Guide */
- { 0xa10c2807, KEY_UP },
- { 0xa10c6807, KEY_DOWN },
- { 0xa10ce807, KEY_LEFT },
- { 0xa10ca807, KEY_RIGHT },
+ { 0x3085e014, KEY_UP },
+ { 0x3085e016, KEY_DOWN },
+ { 0x3085e017, KEY_LEFT },
+ { 0x3085e015, KEY_RIGHT },
- { 0xa10c1807, KEY_SCROLLDOWN }, /* Red Thumbs Down */
- { 0xa10c9807, KEY_SELECT },
- { 0xa10c5807, KEY_SCROLLUP }, /* Green Thumbs Up */
+ { 0x3085e018, KEY_SCROLLDOWN }, /* Red Thumbs Down */
+ { 0x3085e019, KEY_SELECT },
+ { 0x3085e01a, KEY_SCROLLUP }, /* Green Thumbs Up */
- { 0xa10c3807, KEY_VOLUMEUP },
- { 0xa10cb807, KEY_VOLUMEDOWN },
- { 0xa10cd807, KEY_MUTE },
- { 0xa10c040b, KEY_RECORD },
- { 0xa10c7807, KEY_CHANNELUP },
- {
[git:media_tree/master] [media] media: rc: add sysfs scancode filtering interface
This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] media: rc: add sysfs scancode filtering interface Author: James Hogan james.ho...@imgtec.com Date:Fri Jan 17 10:58:49 2014 -0300 Add and document a generic sysfs based scancode filtering interface for making use of IR data matching hardware to filter out uninteresting scancodes. Two filters exist, one for normal operation and one for filtering scancodes which are permitted to wake the system from suspend. The following files are added to /sys/class/rc/rc?/: - filter: normal scancode filter value - filter_mask: normal scancode filter mask - wakeup_filter: wakeup scancode filter value - wakeup_filter_mask: wakeup scancode filter mask A new s_filter() driver callback is added which must arrange for the specified filter to be applied at the right time. Drivers can convert the scancode filter into a raw IR data filter, which can be applied immediately or later (for wake up filters). Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Cc: Rob Landley r...@landley.net Cc: linux-...@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com Documentation/ABI/testing/sysfs-class-rc | 58 + drivers/media/rc/rc-main.c | 136 ++ include/media/rc-core.h | 29 +++ 3 files changed, 223 insertions(+), 0 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=00942d1a1bd93ac108c1b92d504c568a37be1833 diff --git a/Documentation/ABI/testing/sysfs-class-rc b/Documentation/ABI/testing/sysfs-class-rc index 52bc057..c0e1d14 100644 --- a/Documentation/ABI/testing/sysfs-class-rc +++ b/Documentation/ABI/testing/sysfs-class-rc @@ -32,3 +32,61 @@ Description: Writing none will disable all protocols. Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used. + +What: /sys/class/rc/rcN/filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab m.che...@samsung.com +Description: + Sets the scancode filter expected value. + Use in combination with /sys/class/rc/rcN/filter_mask to set the + expected value of the bits set in the filter mask. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab m.che...@samsung.com +Description: + Sets the scancode filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/filter to set the bits + of the scancode which should be compared against the expected + value. A value of 0 disables the filter to allow all valid + scancodes to be processed. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/wakeup_filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab m.che...@samsung.com +Description: + Sets the scancode wakeup filter expected value. + Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to + set the expected value of the bits set in the wakeup filter mask + to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise the write will fail with an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/wakeup_filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab m.che...@samsung.com +Description: + Sets the scancode wakeup filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/wakeup_filter to set + the bits of the scancode which should be compared against the + expected value to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise
Re: [PATCH v2 06/15] dt: binding: add binding for ImgTec IR block
On Thu, Feb 6, 2014 at 8:41 AM, James Hogan james.ho...@imgtec.com wrote: Hi Rob, On 06/02/14 14:33, Rob Herring wrote: On Fri, Jan 17, 2014 at 7:58 AM, James Hogan james.ho...@imgtec.com wrote: +Required properties: +- compatible: Should be img,ir1 Kind of short for a name. I don't have anything much better, but how about img,ir-rev1. Okay, that sounds reasonable. +Optional properties: +- clocks: List of clock specifiers as described in standard + clock bindings. +- clock-names: List of clock names corresponding to the clocks + specified in the clocks property. + Accepted clock names are: + core: Core clock (defaults to 32.768KHz if omitted). + sys: System side (fast) clock. + mod: Power modulation clock. You need to define the order of clocks including how they are interpreted with different number of clocks (not relying on the name). Would it be sufficient to specify that clock-names is required if clocks is provided (i.e. unnamed clocks aren't used), or is there some other reason that clock-names shouldn't be relied upon? irq-names, reg-names, clock-names, etc. are considered optional to their associated property and the order is supposed to be defined. clock-names is a bit different in that clk_get needs a name, so it effectively is required by Linux when there is more than 1 clock. Really, we should fix Linux. Regardless, my other point is still valid. A given h/w block has a fixed number of clocks. You may have them all connected to the same source in some cases, but that does not change the number of inputs. Defining what are the valid combinations needs to be done. Seems like this could be: none - default to 32KHz core - only a baud clock core, sys, mod - all clocks Rob -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/15] dt: binding: add binding for ImgTec IR block
Hi Rob, On Fri, Feb 07, 2014 at 02:33:27PM +, Rob Herring wrote: On Thu, Feb 6, 2014 at 8:41 AM, James Hogan james.ho...@imgtec.com wrote: Hi Rob, On 06/02/14 14:33, Rob Herring wrote: On Fri, Jan 17, 2014 at 7:58 AM, James Hogan james.ho...@imgtec.com wrote: +Required properties: +- compatible: Should be img,ir1 Kind of short for a name. I don't have anything much better, but how about img,ir-rev1. Okay, that sounds reasonable. +Optional properties: +- clocks: List of clock specifiers as described in standard + clock bindings. +- clock-names: List of clock names corresponding to the clocks + specified in the clocks property. + Accepted clock names are: + core: Core clock (defaults to 32.768KHz if omitted). + sys: System side (fast) clock. + mod: Power modulation clock. You need to define the order of clocks including how they are interpreted with different number of clocks (not relying on the name). Would it be sufficient to specify that clock-names is required if clocks is provided (i.e. unnamed clocks aren't used), or is there some other reason that clock-names shouldn't be relied upon? irq-names, reg-names, clock-names, etc. are considered optional to their associated property and the order is supposed to be defined. clock-names is a bit different in that clk_get needs a name, so it effectively is required by Linux when there is more than 1 clock. Really, we should fix Linux. If they're optional then you can't handle optional entries (i.e. when nothing's wired to an input), and this is counter to the style I've been recommending to people (defining clocks in terms of clock-names). I really don't see the point in any *-names property if they don't define the list and allow for optional / reordered lists. Why does the order have to be fixed rather than using the -names properties? It's already a de-facto standard. Regardless, my other point is still valid. A given h/w block has a fixed number of clocks. You may have them all connected to the same source in some cases, but that does not change the number of inputs. Defining what are the valid combinations needs to be done. Seems like this could be: none - default to 32KHz core - only a baud clock core, sys, mod - all clocks For more complex IP blocks you might have more inputs than you actually have clocks wired to. How do you handle an unwired input in the middle of the list, or a new revision of the IP block that got rid of the first clock input from the list but is otherwise compatible? I really don't think it makes sense to say that clock-names doesn't define the list. Thanks, Mark. -- 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
[linuxtv-media:sdr 488/499] drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value 'V4L2_TUNER_ADC' not handled in switch
tree: git://linuxtv.org/media_tree.git sdr
head: 11532660e6f5b6b3a74a03f999d878f35d2cc668
commit: 6b200814f9eaac45ad816da459e31534b576c37b [488/499] [media] v4l: add new
tuner types for SDR
config: make ARCH=powerpc allmodconfig
All warnings:
drivers/media/tuners/tuner-xc2028.c: In function 'generic_set_freq':
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value
'V4L2_TUNER_ADC' not handled in switch [-Wswitch]
switch (new_type) {
^
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value
'V4L2_TUNER_RF' not handled in switch [-Wswitch]
vim +/V4L2_TUNER_ADC +1037 drivers/media/tuners/tuner-xc2028.c
7e28adb2 drivers/media/video/tuner-xc2028.c Harvey Harrison
2008-04-08 1021 tuner_dbg(%s called\n, __func__);
215b95ba drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-23 1022
de3fe21b drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-24 1023 mutex_lock(priv-lock);
de3fe21b drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-24 1024
2ce4b3aa drivers/media/video/tuner-xc2028.c Chris Pascoe
2007-11-19 1025 tuner_dbg(should set frequency %d kHz\n, freq / 1000);
6cb45879 drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-02 1026
66c2d53d drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-25 1027 if (check_firmware(fe, type, std, int_freq) 0)
3b20532c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-09-27 1028 goto ret;
2e4160ca drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-07-18 1029
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1030 /* On some cases xc2028 can disable video output, if
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1031 * very weak signals are received. By sending a soft
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1032 * reset, this is re-enabled. So, it is better to always
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1033 * send a soft reset before changing channels, to be sure
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1034 * that xc2028 will be in a safe state.
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1035 * Maybe this might also be needed for DTV.
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1036 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 @1037 switch (new_type) {
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1038 case V4L2_TUNER_ANALOG_TV:
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1039 rc = send_seq(priv, {0x00, 0x00});
0a863975 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2009-06-01 1040
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1041 /* Analog mode requires offset = 0 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1042 break;
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1043 case V4L2_TUNER_RADIO:
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1044 /* Radio mode requires offset = 0 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1045 break;
:: The code at line 1037 was first introduced by commit
:: fd34cb08babcd898c6b0e30cd7d507ffa62685a1 [media] tuner/xc2028: Fix
frequency offset for radio mode
:: TO: Mauro Carvalho Chehab mche...@redhat.com
:: CC: Mauro Carvalho Chehab mche...@redhat.com
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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] v4l2-subdev: Allow 32-bit compat ioctls
Hi Hans,
Thanks for the update.
On Fri, Feb 07, 2014 at 03:10:34PM +0100, Hans Verkuil wrote:
...
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index d67210a..84b7cce 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -162,6 +162,9 @@ struct v4l2_subdev_core_ops {
int (*g_std)(struct v4l2_subdev *sd, v4l2_std_id *norm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+#ifdef CONFIG_COMPAT
+ long (*compat_ioctl32)(struct v4l2_subdev *sd, unsigned int cmd,
unsigned long arg);
I'd wrap this. I can understanding not wrapping lines in IOCTL definitions
but I see much less reason to do so here.
+#endif
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
int (*s_register)(struct v4l2_subdev *sd, const struct
v4l2_dbg_register *reg);
Tested-by: Sakari Ailus sakari.ai...@linux.intel.com
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/15] dt: binding: add binding for ImgTec IR block
Add device tree binding for ImgTec Consumer Infrared block, specifically
major revision 1 of the hardware.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: linux-media@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
Cc: Rob Landley r...@landley.net
Cc: linux-...@vger.kernel.org
Cc: Tomasz Figa tomasz.f...@gmail.com
---
v3:
- Rename compatible string to img,ir-rev1 (Rob Herring).
- Specify ordering of clocks explicitly (Rob Herring).
v2:
- Future proof compatible string from img,ir to img,ir1, where the 1
corresponds to the major revision number of the hardware (Tomasz
Figa).
- Added clock-names property and three specific clock names described in
the manual, only one of which is used by the current driver (Tomasz
Figa).
---
.../devicetree/bindings/media/img-ir-rev1.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/img-ir-rev1.txt
diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt
b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
new file mode 100644
index ..5434ce61b925
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
@@ -0,0 +1,34 @@
+* ImgTec Infrared (IR) decoder version 1
+
+This binding is for Imagination Technologies' Infrared decoder block,
+specifically major revision 1.
+
+Required properties:
+- compatible: Should be img,ir-rev1
+- reg: Physical base address of the controller and length of
+ memory mapped region.
+- interrupts: The interrupt specifier to the cpu.
+
+Optional properties:
+- clocks: List of clock specifiers as described in standard
+ clock bindings.
+ Up to 3 clocks may be specified in the following order:
+ 1st:Core clock (defaults to 32.768KHz if omitted).
+ 2nd:System side (fast) clock.
+ 3rd:Power modulation clock.
+- clock-names: List of clock names corresponding to the clocks
+ specified in the clocks property.
+ Accepted clock names are:
+ core: Core clock.
+ sys: System clock.
+ mod: Power modulation clock.
+
+Example:
+
+ ir@02006200 {
+ compatible = img,ir-rev1;
+ reg = 0x02006200 0x100;
+ interrupts = 29 4;
+ clocks = clk_32khz;
+ clock-names = core;
+ };
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/15] media: rc: img-ir: add base driver
Add base driver for the ImgTec Infrared decoder block. The driver is
split into separate components for raw (software) decode and hardware
decoder which are in following commits.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: linux-media@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring robh...@kernel.org
Cc: devicet...@vger.kernel.org
---
v3:
- Use new compatible string img,ir-rev1
v2:
- Use new DT binding, with a different compatibility string and get core
clock by name.
- Remove next pointer from struct img_ir_priv. This is related to the
removal of dynamic registration/unregistration of protocol decode
timings from later patches.
- Add io.h include to img-ir.h.
---
drivers/media/rc/img-ir/img-ir-core.c | 176 ++
drivers/media/rc/img-ir/img-ir.h | 166
2 files changed, 342 insertions(+)
create mode 100644 drivers/media/rc/img-ir/img-ir-core.c
create mode 100644 drivers/media/rc/img-ir/img-ir.h
diff --git a/drivers/media/rc/img-ir/img-ir-core.c
b/drivers/media/rc/img-ir/img-ir-core.c
new file mode 100644
index ..6b7834834fb8
--- /dev/null
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -0,0 +1,176 @@
+/*
+ * ImgTec IR Decoder found in PowerDown Controller.
+ *
+ * Copyright 2010-2014 Imagination Technologies Ltd.
+ *
+ * This contains core img-ir code for setting up the driver. The two interfaces
+ * (raw and hardware decode) are handled separately.
+ */
+
+#include linux/clk.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include img-ir.h
+
+static irqreturn_t img_ir_isr(int irq, void *dev_id)
+{
+ struct img_ir_priv *priv = dev_id;
+ u32 irq_status;
+
+ spin_lock(priv-lock);
+ /* we have to clear irqs before reading */
+ irq_status = img_ir_read(priv, IMG_IR_IRQ_STATUS);
+ img_ir_write(priv, IMG_IR_IRQ_CLEAR, irq_status);
+
+ /* don't handle valid data irqs if we're only interested in matches */
+ irq_status = img_ir_read(priv, IMG_IR_IRQ_ENABLE);
+
+ /* hand off edge interrupts to raw decode handler */
+ if (irq_status IMG_IR_IRQ_EDGE img_ir_raw_enabled(priv-raw))
+ img_ir_isr_raw(priv, irq_status);
+
+ /* hand off hardware match interrupts to hardware decode handler */
+ if (irq_status (IMG_IR_IRQ_DATA_MATCH |
+ IMG_IR_IRQ_DATA_VALID |
+ IMG_IR_IRQ_DATA2_VALID)
+ img_ir_hw_enabled(priv-hw))
+ img_ir_isr_hw(priv, irq_status);
+
+ spin_unlock(priv-lock);
+ return IRQ_HANDLED;
+}
+
+static void img_ir_setup(struct img_ir_priv *priv)
+{
+ /* start off with interrupts disabled */
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE, 0);
+
+ img_ir_setup_raw(priv);
+ img_ir_setup_hw(priv);
+
+ if (!IS_ERR(priv-clk))
+ clk_prepare_enable(priv-clk);
+}
+
+static void img_ir_ident(struct img_ir_priv *priv)
+{
+ u32 core_rev = img_ir_read(priv, IMG_IR_CORE_REV);
+
+ dev_info(priv-dev,
+IMG IR Decoder (%d.%d.%d.%d) probed successfully\n,
+(core_rev IMG_IR_DESIGNER) IMG_IR_DESIGNER_SHIFT,
+(core_rev IMG_IR_MAJOR_REV) IMG_IR_MAJOR_REV_SHIFT,
+(core_rev IMG_IR_MINOR_REV) IMG_IR_MINOR_REV_SHIFT,
+(core_rev IMG_IR_MAINT_REV) IMG_IR_MAINT_REV_SHIFT);
+ dev_info(priv-dev, Modes:%s%s\n,
+img_ir_hw_enabled(priv-hw) ? hardware : ,
+img_ir_raw_enabled(priv-raw) ? raw : );
+}
+
+static int img_ir_probe(struct platform_device *pdev)
+{
+ struct img_ir_priv *priv;
+ struct resource *res_regs;
+ int irq, error, error2;
+
+ /* Get resources from platform device */
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(pdev-dev, cannot find IRQ resource\n);
+ return irq;
+ }
+
+ /* Private driver data */
+ priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(pdev-dev, cannot allocate device data\n);
+ return -ENOMEM;
+ }
+ platform_set_drvdata(pdev, priv);
+ priv-dev = pdev-dev;
+ spin_lock_init(priv-lock);
+
+ /* Ioremap the registers */
+ res_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv-reg_base = devm_ioremap_resource(pdev-dev, res_regs);
+ if (IS_ERR(priv-reg_base))
+ return PTR_ERR(priv-reg_base);
+
+ /* Get core clock */
+ priv-clk = devm_clk_get(pdev-dev, core);
+ if (IS_ERR(priv-clk))
+ dev_warn(pdev-dev, cannot get core clock resource\n);
+ /*
+* The driver doesn't need to know about the system (sys) or
Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL
On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
dma_buf_map_attachment and dma_buf_vmap can return NULL or
ERR_PTR on a error. This encourages a common buggy pattern in
callers:
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt))
return PTR_ERR(sgt);
This causes the caller to return 0 on an error. IS_ERR_OR_NULL
is almost always a sign of poorly-defined error handling.
This patch converts dma_buf_map_attachment to always return
ERR_PTR, and fixes the callers that incorrectly handled NULL.
There are a few more callers that were not checking for NULL
at all, which would have dereferenced a NULL pointer later.
There are also a few more callers that correctly handled NULL
and ERR_PTR differently, I left those alone but they could also
be modified to delete the NULL check.
This patch also converts dma_buf_vmap to always return NULL.
All the callers to dma_buf_vmap only check for NULL, and would
have dereferenced an ERR_PTR and panic'd if one was ever
returned. This is not consistent with the rest of the dma buf
APIs, but matches the expectations of all of the callers.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..cfe1d8bc7bb8 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Returns struct dma_buf_attachment * for this attachment; may return
negative
- * error codes.
- *
+ * Returns struct dma_buf_attachment * for this attachment; returns
ERR_PTR on
+ * error.
*/
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
@@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
- * Returns sg_table containing the scatterlist to be returned; may return
NULL
- * or ERR_PTR.
- *
+ * Returns sg_table containing the scatterlist to be returned; returns
ERR_PTR
+ * on error.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)
@@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
return ERR_PTR(-EINVAL);
sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
return sg_table;
}
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these
interfaces.
+ *
+ * Returns NULL on error.
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
@@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
BUG_ON(dmabuf-vmap_ptr);
ptr = dmabuf-ops-vmap(dmabuf);
- if (IS_ERR_OR_NULL(ptr))
+ if (WARN_ON_ONCE(IS_ERR(ptr)))
since vmap is optional, the WARN_ON might be a bit strong.. although
it would be a bit strange for an exporter to supply a vmap fxn which
always returned NULL, not sure about that. Just thought I'd mention
it in case anyone else had an opinion about that.
Yeah, I don't like this, it could cause unnecessary reports of problems.
Care to fix it up?
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 RFC 0/2] drivers/base: simplify simple DT-based components
This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops drivers/base: declare phandle DT nodes as components drivers/base/component.c | 21 +++-- drivers/base/core.c | 18 ++ include/linux/of.h | 2 ++ 3 files changed, 39 insertions(+), 2 deletions(-) -- 1.9.rc1 -- 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 RFC 1/2] drivers/base: permit base components to omit the bind/unbind ops
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6..0a39d7a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
{
WARN_ON(!component-bound);
- component-ops-unbind(component-dev, master-dev, data);
+ if (component-ops)
+ component-ops-unbind(component-dev, master-dev, data);
component-bound = false;
/* Release all resources claimed in the binding of this component */
@@ -274,7 +275,11 @@ static int component_bind(struct component *component,
struct master *master,
dev_dbg(master-dev, binding %s (ops %ps)\n,
dev_name(component-dev), component-ops);
- ret = component-ops-bind(component-dev, master-dev, data);
+ if (component-ops)
+ ret = component-ops-bind(component-dev, master-dev, data);
+ else
+ ret = 0;
+
if (!ret) {
component-bound = true;
--
1.9.rc1
--
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/2] drivers/base: declare phandle DT nodes as components
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT. This permits simple devices to be part of complex
componentised subsystems without any specific code.
When created from DT, the device dependence is generally indicated by
phandle: a device which is pointed to by a phandle must be started
before the pointing device(s).
So, at device register time, the devices which are pointed to by a
phandle are declared as components, except when they declared
themselves as such in their probe function.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 12
drivers/base/core.c | 18 ++
include/linux/of.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 0a39d7a..3cab26b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/of.h
struct master {
struct list_head node;
@@ -336,6 +337,7 @@ EXPORT_SYMBOL_GPL(component_bind_all);
int component_add(struct device *dev, const struct component_ops *ops)
{
struct component *component;
+ struct device_node *np;
int ret;
component = kzalloc(sizeof(*component), GFP_KERNEL);
@@ -356,6 +358,11 @@ int component_add(struct device *dev, const struct
component_ops *ops)
kfree(component);
}
+
+ np = dev-of_node;
+ if (np)
+ np-_flags |= OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
return ret 0 ? ret : 0;
@@ -365,6 +372,7 @@ EXPORT_SYMBOL_GPL(component_add);
void component_del(struct device *dev, const struct component_ops *ops)
{
struct component *c, *component = NULL;
+ struct device_node *np;
mutex_lock(component_mutex);
list_for_each_entry(c, component_list, node)
@@ -377,6 +385,10 @@ void component_del(struct device *dev, const struct
component_ops *ops)
if (component component-master)
take_down_master(component-master);
+ np = dev-of_node;
+ if (np)
+ np-_flags = ~OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
WARN_ON(!component);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b56717..0517b91 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,6 +27,7 @@
#include linux/pm_runtime.h
#include linux/netdevice.h
#include linux/sysfs.h
+#include linux/component.h
#include base.h
#include power/power.h
@@ -980,6 +981,7 @@ int device_add(struct device *dev)
struct device *parent = NULL;
struct kobject *kobj;
struct class_interface *class_intf;
+ struct device_node *np;
int error = -EINVAL;
dev = get_device(dev);
@@ -1088,6 +1090,15 @@ int device_add(struct device *dev)
class_intf-add_dev(dev, class_intf);
mutex_unlock(dev-class-p-mutex);
}
+
+ /* if DT-created device referenced by phandle, create a component */
+ np = dev-of_node;
+ if (np np-phandle
+ !(np-_flags OF_DEV_COMPONENT)) {
+ component_add(dev, NULL);
+ np-_flags |= OF_DEV_IMPLICIT_COMPONENT;
+ }
+
done:
put_device(dev);
return error;
@@ -1189,10 +1200,17 @@ void device_del(struct device *dev)
{
struct device *parent = dev-parent;
struct class_interface *class_intf;
+ struct device_node *np;
/* Notify clients of device removal. This call must come
* before dpm_sysfs_remove().
*/
+ np = dev-of_node;
+ if (np (np-_flags OF_DEV_COMPONENT)) {
+ component_del(dev, NULL);
+ np-_flags = ~OF_DEV_IMPLICIT_COMPONENT;
+ }
+
if (dev-bus)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
BUS_NOTIFY_DEL_DEVICE, dev);
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..40f1c34 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -59,6 +59,8 @@ struct device_node {
struct proc_dir_entry *pde;/* this node's proc directory */
struct kref kref;
unsigned long _flags;
+#define OF_DEV_COMPONENT 1
+#define OF_DEV_IMPLICIT_COMPONENT 2
void*data;
#if defined(CONFIG_SPARC)
const char *path_component_name;
--
1.9.rc1
--
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 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops drivers/base: declare phandle DT nodes as components drivers/base/component.c | 21 +++-- drivers/base/core.c | 18 ++ include/linux/of.h | 2 ++ 3 files changed, 39 insertions(+), 2 deletions(-) -- 1.9.rc1 -- 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
video from USB DVB-T get damaged after some time
Hello, I have this: http://linuxtv.org/wiki/index.php/ITE_IT9135 with dvb-usb-it9135-02.fw (chip version 2) on U12.04 64b with compiled newest drivers from: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers. The problem is - after some time I receive a program (e.g. in Kaffeine, me-tv, vlc, ...) the program get more and more damaged and finely get lost at all. I happens quicker (+- after 10-20 minutes) on channels with lower signal. On stronger signals it happens after +- 30-100 minutes. The USB stick stays cool. I can switch to another frequency and back and it works again OK - for only the same while. Could that problem be in (or solvable by) FW/drivers or is it !absolutely certain! only HW problem ? In attachment is output from tzap - you can see the time point where the video TS gets damaged. Any suggestion ? Thanks --kapetr status 1f | signal 7fff | snr e780 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5bb | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e567 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e428 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e484 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4a6 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e639 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e606 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5aa | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e51b | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e69d | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e780 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5dc | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e591 | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4f1 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e534 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5bb | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e46b | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e702 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e6e9 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e649 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5fe | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4d8 | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e588 | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e50a | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e577 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e31b | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e3d4 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e26b | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e40e | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e452 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e3e5 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4bf | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e3fe | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e484 | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5a1 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e56f | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e639 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e6a6 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4e0 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e5e5 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4bf | ber 0006 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e641 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e7bb | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e6bf | ber 0006 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e6a6 | ber 0003 | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e513 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e406 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e262 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e4d0 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e273 | ber | unc 0016 | FE_HAS_LOCK status 1f | signal 7fff | snr e388 | ber 0003 | unc
[PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6..0a39d7a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
{
WARN_ON(!component-bound);
- component-ops-unbind(component-dev, master-dev, data);
+ if (component-ops)
+ component-ops-unbind(component-dev, master-dev, data);
component-bound = false;
/* Release all resources claimed in the binding of this component */
@@ -274,7 +275,11 @@ static int component_bind(struct component *component,
struct master *master,
dev_dbg(master-dev, binding %s (ops %ps)\n,
dev_name(component-dev), component-ops);
- ret = component-ops-bind(component-dev, master-dev, data);
+ if (component-ops)
+ ret = component-ops-bind(component-dev, master-dev, data);
+ else
+ ret = 0;
+
if (!ret) {
component-bound = true;
--
1.9.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] *** SUBJECT HERE ***
On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote: *** BLURB HERE *** Subject and BLURB forgotten? -- 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] dma-buf: avoid using IS_ERR_OR_NULL
On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
dma_buf_map_attachment and dma_buf_vmap can return NULL or
ERR_PTR on a error. This encourages a common buggy pattern in
callers:
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt))
return PTR_ERR(sgt);
This causes the caller to return 0 on an error. IS_ERR_OR_NULL
is almost always a sign of poorly-defined error handling.
This patch converts dma_buf_map_attachment to always return
ERR_PTR, and fixes the callers that incorrectly handled NULL.
There are a few more callers that were not checking for NULL
at all, which would have dereferenced a NULL pointer later.
There are also a few more callers that correctly handled NULL
and ERR_PTR differently, I left those alone but they could also
be modified to delete the NULL check.
This patch also converts dma_buf_vmap to always return NULL.
All the callers to dma_buf_vmap only check for NULL, and would
have dereferenced an ERR_PTR and panic'd if one was ever
returned. This is not consistent with the rest of the dma buf
APIs, but matches the expectations of all of the callers.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..cfe1d8bc7bb8 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Returns struct dma_buf_attachment * for this attachment; may return
negative
- * error codes.
- *
+ * Returns struct dma_buf_attachment * for this attachment; returns
ERR_PTR on
+ * error.
*/
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
@@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
- * Returns sg_table containing the scatterlist to be returned; may return
NULL
- * or ERR_PTR.
- *
+ * Returns sg_table containing the scatterlist to be returned; returns
ERR_PTR
+ * on error.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)
@@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
return ERR_PTR(-EINVAL);
sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
return sg_table;
}
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these
interfaces.
+ *
+ * Returns NULL on error.
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
@@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
BUG_ON(dmabuf-vmap_ptr);
ptr = dmabuf-ops-vmap(dmabuf);
- if (IS_ERR_OR_NULL(ptr))
+ if (WARN_ON_ONCE(IS_ERR(ptr)))
since vmap is optional, the WARN_ON might be a bit strong.. although
it would be a bit strange for an exporter to supply a vmap fxn which
always returned NULL, not sure about that. Just thought I'd mention
it in case anyone else had an opinion about that.
Yeah, I don't like this, it could cause unnecessary reports of problems.
The WARN_ON_ONCE is only if the vmap op returns ERR_PTR, not if it
returns NULL. This is designed to catch vmap ops that don't follow
the spec, so I would call them necessary reports, but I can take it
out if you still disagree.
--
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 RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote: This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. I wonder - I said earlier today that this works absolutely fine without modification with DT, so why are you messing about with it adding DT support? This is totally the wrong approach. The idea is that this deals with /devices/ and /devices/ only. It groups up /devices/. It's up to the add_component callback to the master device to decide how to deal with that. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops And this patch has me wondering if you even understand how to use this... The master bind/unbind callbacks are the ones which establish the card based context with the subsystem. Please, before buggering up this nicely designed implementation, please /first/ look at the imx-drm rework which was posted back in early January which illustrates how this is used in a DT context - which is something I've already pointed you at once today already. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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 RFC 2/2] drivers/base: declare phandle DT nodes as components
On Fri, Feb 07, 2014 at 05:53:27PM +0100, Jean-Francois Moine wrote: At system startup time, some devices depends on the availability of some other devices before starting. The infrastructure for componentised subsystems permits to handle this dependence, each driver defining its own role. This patch does an automatic creation of the lowest components in case of DT. This permits simple devices to be part of complex componentised subsystems without any specific code. A component with no operations makes precisely no sense - with that, there's no way for the component to be a stand-alone driver. Your approach forces your ideas onto every DT device that is referenced as a phandle. That's extremely restrictive. I don't want the component stuff knowing anything about OF. I don't want it knowing about driver matching. I don't want it knowing about ACPI either. That's the whole point behind it - it is 100% agnostic about how that stuff works. The model is quite simply this: - a master device is the covering component for the card - the master device knows what components to expect by some means. In the case of DT, that's by phandle references to the components. - the master device handles the component independent setup of the card, creating the common resources that are required. When it's ready, it asks for the components to be bound. - upon removal of any component, the master component is unbound, which triggers the removal of the card from the subsystem. - as part of the removal, sub-components are unbound. - the master device should have as /little/ knowledge about the components as possible to permit component re-use. - a component driver should be independent of it's master. - A component which is probed from the device model should simply register itself using component_add() with an appropriate operations structure, and a removal function which deletes itself. - When the driver is ready to be initialised (when the card level resources have been set in place) the bind method will be called. At this point, the component does everything that a classical driver model driver would do in it's probe callback. - unbind is the same as remove in the classical driver model. So, please, no DT stuff in the component support - it's simply not required. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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] bttv: Add support for Kworld V-Stream Xpert TV PVR878
From 27c5541a93bee007d41a70b393c97ea19c62ace2 Mon Sep 17 00:00:00 2001
From: POJAR GEORGE geoubu...@gmail.com
Date: Fri, 7 Feb 2014 19:34:41 +0200
Subject: [PATCH] bttv: Add support for Kworld V-Stream Xpert TV PVR878
Signed-off-by: POJAR GEORGE geoubu...@gmail.com
---
Documentation/video4linux/CARDLIST.bttv | 1 +
drivers/media/video/bt8xx/bttv-cards.c | 16
drivers/media/video/bt8xx/bttv-input.c | 1 +
drivers/media/video/bt8xx/bttv.h| 1 +
4 files changed, 19 insertions(+)
diff --git a/Documentation/video4linux/CARDLIST.bttv
b/Documentation/video4linux/CARDLIST.bttv
index 4739d56..0103fe4 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -158,3 +158,4 @@
157 - Geovision GV-800(S) (master) [800a:763d]
158 - Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d]
159 - ProVideo PV183
[1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
+160 - Kworld V-Stream Xpert TV PVR878
diff --git a/drivers/media/video/bt8xx/bttv-cards.c
b/drivers/media/video/bt8xx/bttv-cards.c
index 49efcf6..7e02b8e 100644
--- a/drivers/media/video/bt8xx/bttv-cards.c
+++ b/drivers/media/video/bt8xx/bttv-cards.c
@@ -2916,6 +2916,22 @@ struct tvcard bttv_tvcards[] = {
.tuner_type = TUNER_ABSENT,
.tuner_addr= ADDR_UNSET,
},
+[BTTV_BOARD_KWORLD_VSTREAM_XPERT] = {
+/* POJAR GEORGE geoubu...@gmail.com */
+.name = Kworld V-Stream Xpert TV PVR878,
+.video_inputs = 3,
+/* .audio_inputs= 1, */
+.svhs = 2,
+.gpiomask = 0x001c0007,
+.muxsel = MUXSEL(2, 3, 1, 1),
+.gpiomux= { 0, 1, 2, 2 },
+.gpiomute = 3,
+.pll= PLL_28,
+.tuner_type = TUNER_TENA_9533_DI,
+.tuner_addr= ADDR_UNSET,
+.has_remote = 1,
+.has_radio = 1,
+},
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index 6bf05a7..3af1e23 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -391,6 +391,7 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_ASKEY_CPH03X:
case BTTV_BOARD_CONCEPTRONIC_CTVFMI2:
case BTTV_BOARD_CONTVFMI:
+case BTTV_BOARD_KWORLD_VSTREAM_XPERT:
ir_codes = RC_MAP_PIXELVIEW;
ir-mask_keycode = 0x001F00;
ir-mask_keyup = 0x006000;
diff --git a/drivers/media/video/bt8xx/bttv.h
b/drivers/media/video/bt8xx/bttv.h
index 6fd2a8e..dd926d8 100644
--- a/drivers/media/video/bt8xx/bttv.h
+++ b/drivers/media/video/bt8xx/bttv.h
@@ -184,6 +184,7 @@
#define BTTV_BOARD_GEOVISION_GV800S 0x9d
#define BTTV_BOARD_GEOVISION_GV800S_SL 0x9e
#define BTTV_BOARD_PV183 0x9f
+#define BTTV_BOARD_KWORLD_VSTREAM_XPERT0xa0
/* more card-specific defines */
--
1.9.rc1
--
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 RFC 2/2] drivers/base: declare phandle DT nodes as components
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT. This permits simple devices to be part of complex
componentised subsystems without any specific code.
When created from DT, the device dependence is generally indicated by
phandle: a device which is pointed to by a phandle must be started
before the pointing device(s).
So, at device register time, the devices which are pointed to by a
phandle are declared as components, except when they declared
themselves as such in their probe function.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 12
drivers/base/core.c | 18 ++
include/linux/of.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 0a39d7a..3cab26b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/of.h
struct master {
struct list_head node;
@@ -336,6 +337,7 @@ EXPORT_SYMBOL_GPL(component_bind_all);
int component_add(struct device *dev, const struct component_ops *ops)
{
struct component *component;
+ struct device_node *np;
int ret;
component = kzalloc(sizeof(*component), GFP_KERNEL);
@@ -356,6 +358,11 @@ int component_add(struct device *dev, const struct
component_ops *ops)
kfree(component);
}
+
+ np = dev-of_node;
+ if (np)
+ np-_flags |= OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
return ret 0 ? ret : 0;
@@ -365,6 +372,7 @@ EXPORT_SYMBOL_GPL(component_add);
void component_del(struct device *dev, const struct component_ops *ops)
{
struct component *c, *component = NULL;
+ struct device_node *np;
mutex_lock(component_mutex);
list_for_each_entry(c, component_list, node)
@@ -377,6 +385,10 @@ void component_del(struct device *dev, const struct
component_ops *ops)
if (component component-master)
take_down_master(component-master);
+ np = dev-of_node;
+ if (np)
+ np-_flags = ~OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
WARN_ON(!component);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b56717..0517b91 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,6 +27,7 @@
#include linux/pm_runtime.h
#include linux/netdevice.h
#include linux/sysfs.h
+#include linux/component.h
#include base.h
#include power/power.h
@@ -980,6 +981,7 @@ int device_add(struct device *dev)
struct device *parent = NULL;
struct kobject *kobj;
struct class_interface *class_intf;
+ struct device_node *np;
int error = -EINVAL;
dev = get_device(dev);
@@ -1088,6 +1090,15 @@ int device_add(struct device *dev)
class_intf-add_dev(dev, class_intf);
mutex_unlock(dev-class-p-mutex);
}
+
+ /* if DT-created device referenced by phandle, create a component */
+ np = dev-of_node;
+ if (np np-phandle
+ !(np-_flags OF_DEV_COMPONENT)) {
+ component_add(dev, NULL);
+ np-_flags |= OF_DEV_IMPLICIT_COMPONENT;
+ }
+
done:
put_device(dev);
return error;
@@ -1189,10 +1200,17 @@ void device_del(struct device *dev)
{
struct device *parent = dev-parent;
struct class_interface *class_intf;
+ struct device_node *np;
/* Notify clients of device removal. This call must come
* before dpm_sysfs_remove().
*/
+ np = dev-of_node;
+ if (np (np-_flags OF_DEV_COMPONENT)) {
+ component_del(dev, NULL);
+ np-_flags = ~OF_DEV_IMPLICIT_COMPONENT;
+ }
+
if (dev-bus)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
BUS_NOTIFY_DEL_DEVICE, dev);
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..40f1c34 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -59,6 +59,8 @@ struct device_node {
struct proc_dir_entry *pde;/* this node's proc directory */
struct kref kref;
unsigned long _flags;
+#define OF_DEV_COMPONENT 1
+#define OF_DEV_IMPLICIT_COMPONENT 2
void*data;
#if defined(CONFIG_SPARC)
const char *path_component_name;
--
1.9.rc1
--
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] bttv: Add support for Kworld V-Stream Xpert TV PVR878
On 07.02.2014 19:56, GEORGE wrote:
From 27c5541a93bee007d41a70b393c97ea19c62ace2 Mon Sep 17 00:00:00 2001
From: POJAR GEORGE geoubu...@gmail.com
Date: Fri, 7 Feb 2014 19:34:41 +0200
Subject: [PATCH] bttv: Add support for Kworld V-Stream Xpert TV PVR878
Signed-off-by: POJAR GEORGE geoubu...@gmail.com
---
Documentation/video4linux/CARDLIST.bttv | 1 +
drivers/media/video/bt8xx/bttv-cards.c | 16
drivers/media/video/bt8xx/bttv-input.c | 1 +
drivers/media/video/bt8xx/bttv.h| 1 +
4 files changed, 19 insertions(+)
diff --git a/Documentation/video4linux/CARDLIST.bttv
b/Documentation/video4linux/CARDLIST.bttv
index 4739d56..0103fe4 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -158,3 +158,4 @@
157 - Geovision GV-800(S) (master) [800a:763d]
158 - Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d]
159 - ProVideo PV183
[1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
+160 - Kworld V-Stream Xpert TV PVR878
diff --git a/drivers/media/video/bt8xx/bttv-cards.c
b/drivers/media/video/bt8xx/bttv-cards.c
index 49efcf6..7e02b8e 100644
--- a/drivers/media/video/bt8xx/bttv-cards.c
+++ b/drivers/media/video/bt8xx/bttv-cards.c
@@ -2916,6 +2916,22 @@ struct tvcard bttv_tvcards[] = {
.tuner_type = TUNER_ABSENT,
.tuner_addr= ADDR_UNSET,
},
+[BTTV_BOARD_KWORLD_VSTREAM_XPERT] = {
+/* POJAR GEORGE geoubu...@gmail.com */
+.name = Kworld V-Stream Xpert TV PVR878,
+.video_inputs = 3,
+/* .audio_inputs= 1, */
+.svhs = 2,
+.gpiomask = 0x001c0007,
+.muxsel = MUXSEL(2, 3, 1, 1),
+.gpiomux= { 0, 1, 2, 2 },
+.gpiomute = 3,
+.pll= PLL_28,
+.tuner_type = TUNER_TENA_9533_DI,
+.tuner_addr= ADDR_UNSET,
+.has_remote = 1,
+.has_radio = 1,
+},
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index 6bf05a7..3af1e23 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -391,6 +391,7 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_ASKEY_CPH03X:
case BTTV_BOARD_CONCEPTRONIC_CTVFMI2:
case BTTV_BOARD_CONTVFMI:
+case BTTV_BOARD_KWORLD_VSTREAM_XPERT:
ir_codes = RC_MAP_PIXELVIEW;
ir-mask_keycode = 0x001F00;
ir-mask_keyup = 0x006000;
diff --git a/drivers/media/video/bt8xx/bttv.h
b/drivers/media/video/bt8xx/bttv.h
index 6fd2a8e..dd926d8 100644
--- a/drivers/media/video/bt8xx/bttv.h
+++ b/drivers/media/video/bt8xx/bttv.h
@@ -184,6 +184,7 @@
#define BTTV_BOARD_GEOVISION_GV800S 0x9d
#define BTTV_BOARD_GEOVISION_GV800S_SL 0x9e
#define BTTV_BOARD_PV183 0x9f
+#define BTTV_BOARD_KWORLD_VSTREAM_XPERT0xa0
/* more card-specific defines */
Update with INFO about this card
I have a tuner Kworld Xpert TV-PVR 878 [PCI, FM radio, BG + DK, conexant
878a].
When I try with options for card:
78 Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [0a01:17de],
can't find any channels, radio and remote not work, so I use btspy to make
a report:
General information:
Name:kworld 878a
Chip: Bt878 , Rev: 0x00
Subsystem: 0x
Vendor: Gammagraphx, Inc.
Values to MUTE audio:
Mute_GPOE : 0x1c0007
Mute_GPDATA: 0x01
Has TV Tuner: Yes
TV_Mux : 2
TV_GPOE : 0x1c0007
TV_GPDATA: 0x08
Number of Composite Ins: 1
Composite in 1
Composite1_Mux : 3
Composite1_GPOE : 0x1c0007
Composite1_GPDATA: 0x02
Has SVideo: Yes
SVideo_Mux : 1
SVideo_GPOE : 0x1c0007
SVideo_GPDATA: 0x02
Has Radio: Yes
Radio_GPOE : 0x1c0007
Radio_GPDATA: 0x01
and put this configuration:
options bttv card=78 tuner=38 gpiomask=0x1c0007
audiomux=0x08,0x01,0x08,0x08,0x01
With this configuration TV, radio and remote work fine.
So I make above patch to add full support for this card.
from.inf file:
Device ID List
ID Number Device
0x350 Bt848
0x351 Bt849
0x36E Bt878 (Video Section)
0x36F Bt879 (Video Section)
0x370 Bt880 (Video Section)
0x878 Bt878 (Audio Section)
0x879 Bt879 (Audio Section)
0x880 Bt880 (Audio Section)
with EEPROM
BT848.VideoDeviceDesc=BT848.PhilipsNTSC,
PCI\VEN_109EDEV_036ESUBSYS_087817DE
BT848.VideoDeviceDesc=BT848.PhilipsPAL,
PCI\VEN_109EDEV_036ESUBSYS_087917DE
BT848.VideoDeviceDesc=BT848.Philips4in1,
PCI\VEN_109EDEV_036ESUBSYS_087A17DE
BT848.VideoDeviceDesc=BT848.PhilTN5533,
PCI\VEN_109EDEV_036ESUBSYS_087B17DE
BT848.VideoDeviceDesc=BT848.PhilTN9533,
PCI\VEN_109EDEV_036ESUBSYS_087C17DE
without EEPROM
BT848.VideoDeviceDesc=BT848.PhilipsNTSC,PCI\VEN_109EDEV_036E
BT848.VideoDeviceDesc=BT848.PhilipsNTSC,
PCI\VEN_109EDEV_036ESUBSYS_
--
To
Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
Last May I started writing a driver for a KWorld UB435Q Version 3 tuner. I was able to make the kernel recognize the device, light it's LED, and try to enable the decoder and tuner. I was unable to locate any information for the tda18272 tuner chip until last week. I received an email at another address with a pointer to a GPL driver that used a tda18272 in a pcie based tuner. It appears that a bit of refactoring has been done to v4l2 since it was written. I want to try to incorporate it into the kernel tree properly while making the KWorld UB435Q Version 3 usable under linux. Would the tda18271 be a good model? The tda18271 organized with part in tuners and part in dvb-frontends. What is the dvb-frontends stuff used for? The tda18271 files in kernel are: ./media/tuners/tda18271-maps.c ./media/tuners/tda18271-fe.c ./media/tuners/tda18271.h ./media/tuners/tda18271-priv.h ./media/tuners/tda18271-common.c ./media/dvb-frontends/tda18271c2dd.c ./media/dvb-frontends/tda18271c2dd.h ./media/dvb-frontends/tda18271c2dd_maps.h The tda18272 files I located are: ./media/dvb/frontends/tda18272_reg.h ./media/dvb/frontends/tda18272.h ./media/dvb/frontends/tda18272.c The tuner is only used in digital mode with KWorld UB435Q Version 3. The tda18272 supports both digital and analog. Should I include the analog support in the tda18272 files without testing it? -- 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: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
On Fri, Feb 7, 2014 at 1:23 PM, The Bit Pit thebit...@earthlink.net wrote: Last May I started writing a driver for a KWorld UB435Q Version 3 tuner. I was able to make the kernel recognize the device, light it's LED, and try to enable the decoder and tuner. Slightly related I added support for the KWorld UB445-U2 ATSC/Analog stick the other day. It uses the cx231xx bridge, LG3305 and TDA18272 tuner. It was fairly simple to get running. Analog and digital TV work OK, the baseband inputs and alsa are running. No great shakes. Manu has a TDA18272 Linux tree if you google a little. - 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
Re: [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, 7 Feb 2014 17:33:26 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote: This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. I wonder - I said earlier today that this works absolutely fine without modification with DT, so why are you messing about with it adding DT support? This is totally the wrong approach. The idea is that this deals with /devices/ and /devices/ only. It groups up /devices/. It's up to the add_component callback to the master device to decide how to deal with that. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops And this patch has me wondering if you even understand how to use this... The master bind/unbind callbacks are the ones which establish the card based context with the subsystem. Please, before buggering up this nicely designed implementation, please /first/ look at the imx-drm rework which was posted back in early January which illustrates how this is used in a DT context - which is something I've already pointed you at once today already. As I told in a previous mail, your code works fine in my DT-based Cubox. I am rewriting the TDA988x as a normal encoder/connector, and, yes, the bind/unbind functions are useful in this case. But you opened a door. In a DT context, you know that the probe_defer mechanism does not work correctly. Your work permits to solve delicate cases: your component_add tells exactly when a device is available, and the master bind callback is the green signal for the device waiting for its resources. Indeed, your system was not created for such a usage, but it works as it is (anyway, the component bind/unbind functions may be empty...). -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, Feb 07, 2014 at 07:42:04PM +0100, Jean-Francois Moine wrote: On Fri, 7 Feb 2014 17:33:26 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote: This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. I wonder - I said earlier today that this works absolutely fine without modification with DT, so why are you messing about with it adding DT support? This is totally the wrong approach. The idea is that this deals with /devices/ and /devices/ only. It groups up /devices/. It's up to the add_component callback to the master device to decide how to deal with that. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops And this patch has me wondering if you even understand how to use this... The master bind/unbind callbacks are the ones which establish the card based context with the subsystem. Please, before buggering up this nicely designed implementation, please /first/ look at the imx-drm rework which was posted back in early January which illustrates how this is used in a DT context - which is something I've already pointed you at once today already. As I told in a previous mail, your code works fine in my DT-based Cubox. I am rewriting the TDA988x as a normal encoder/connector, and, yes, the bind/unbind functions are useful in this case. So, which bit of I've already got that was missed? But you opened a door. In a DT context, you know that the probe_defer mechanism does not work correctly. Your work permits to solve delicate cases: your component_add tells exactly when a device is available, and the master bind callback is the green signal for the device waiting for its resources. Indeed, your system was not created for such a usage, but it works as it is (anyway, the component bind/unbind functions may be empty...). Sorry. Deferred probe does work, it's been tested with imx-drm, not only from the master component but also the sub-components. There's no problem here. And no component bind/unbind function should ever be empty. Again, I put it to you that you don't understand this layer. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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] dma-buf: avoid using IS_ERR_OR_NULL
On Fri, Feb 07, 2014 at 09:22:37AM -0800, Colin Cross wrote:
On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
dma_buf_map_attachment and dma_buf_vmap can return NULL or
ERR_PTR on a error. This encourages a common buggy pattern in
callers:
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt))
return PTR_ERR(sgt);
This causes the caller to return 0 on an error. IS_ERR_OR_NULL
is almost always a sign of poorly-defined error handling.
This patch converts dma_buf_map_attachment to always return
ERR_PTR, and fixes the callers that incorrectly handled NULL.
There are a few more callers that were not checking for NULL
at all, which would have dereferenced a NULL pointer later.
There are also a few more callers that correctly handled NULL
and ERR_PTR differently, I left those alone but they could also
be modified to delete the NULL check.
This patch also converts dma_buf_vmap to always return NULL.
All the callers to dma_buf_vmap only check for NULL, and would
have dereferenced an ERR_PTR and panic'd if one was ever
returned. This is not consistent with the rest of the dma buf
APIs, but matches the expectations of all of the callers.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..cfe1d8bc7bb8 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Returns struct dma_buf_attachment * for this attachment; may return
negative
- * error codes.
- *
+ * Returns struct dma_buf_attachment * for this attachment; returns
ERR_PTR on
+ * error.
*/
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
@@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
- * Returns sg_table containing the scatterlist to be returned; may
return NULL
- * or ERR_PTR.
- *
+ * Returns sg_table containing the scatterlist to be returned; returns
ERR_PTR
+ * on error.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment
*attach,
enum dma_data_direction
direction)
@@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
return ERR_PTR(-EINVAL);
sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
return sg_table;
}
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these
interfaces.
+ *
+ * Returns NULL on error.
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
@@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
BUG_ON(dmabuf-vmap_ptr);
ptr = dmabuf-ops-vmap(dmabuf);
- if (IS_ERR_OR_NULL(ptr))
+ if (WARN_ON_ONCE(IS_ERR(ptr)))
since vmap is optional, the WARN_ON might be a bit strong.. although
it would be a bit strange for an exporter to supply a vmap fxn which
always returned NULL, not sure about that. Just thought I'd mention
it in case anyone else had an opinion about that.
Yeah, I don't like this, it could cause unnecessary reports of problems.
The WARN_ON_ONCE is only if the vmap op returns ERR_PTR, not if it
returns NULL. This is designed to catch vmap ops that don't follow
the spec, so I would call them necessary reports, but I can take it
out if you still disagree.
Ah, ok, that makes more sense. I'll queue this up.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
Thanks steve, Found it. Its the same files I found at a different place. I don't understand the way to do things. Last time I simply edited the kernel tree and supplied patches to get my changes in. The source for tda18272 is not in the kernel tree I 'git' following the instructions at linuxtv.org. It is in Manu's tree, but the directory structure is slightly different. I don't understand the current development process. Are the instructions at linuxtv.org out of date? In which tree should I edit the following and supply patches against: usb/em28xx/em28xx-cards.c usb/em28xx/em28xx-dvb.c usb/em28xx/em28xx.h On 02/07/2014 12:39 PM, Steven Toth wrote: On Fri, Feb 7, 2014 at 1:23 PM, The Bit Pit thebit...@earthlink.net wrote: Last May I started writing a driver for a KWorld UB435Q Version 3 tuner. I was able to make the kernel recognize the device, light it's LED, and try to enable the decoder and tuner. Slightly related I added support for the KWorld UB445-U2 ATSC/Analog stick the other day. It uses the cx231xx bridge, LG3305 and TDA18272 tuner. It was fairly simple to get running. Analog and digital TV work OK, the baseband inputs and alsa are running. No great shakes. Manu has a TDA18272 Linux tree if you google a little. - Steve -- 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 RFC 1/2] drivers/base: permit base components to omit the bind/unbind ops
On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6..0a39d7a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
{
WARN_ON(!component-bound);
- component-ops-unbind(component-dev, master-dev, data);
+ if (component-ops)
+ component-ops-unbind(component-dev, master-dev, data);
component-bound = false;
/* Release all resources claimed in the binding of this component */
@@ -274,7 +275,11 @@ static int component_bind(struct component *component,
struct master *master,
dev_dbg(master-dev, binding %s (ops %ps)\n,
dev_name(component-dev), component-ops);
- ret = component-ops-bind(component-dev, master-dev, data);
+ if (component-ops)
+ ret = component-ops-bind(component-dev, master-dev, data);
+ else
+ ret = 0;
+
NAK. If this is done, there's absolutely no point to this code.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
--
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: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
On Sat, Feb 8, 2014 at 12:09 AM, Steven Toth st...@kernellabs.com wrote: On Fri, Feb 7, 2014 at 1:23 PM, The Bit Pit thebit...@earthlink.net wrote: Last May I started writing a driver for a KWorld UB435Q Version 3 tuner. I was able to make the kernel recognize the device, light it's LED, and try to enable the decoder and tuner. Slightly related I added support for the KWorld UB445-U2 ATSC/Analog stick the other day. It uses the cx231xx bridge, LG3305 and TDA18272 tuner. It was fairly simple to get running. Analog and digital TV work OK, the baseband inputs and alsa are running. No great shakes. Manu has a TDA18272 Linux tree if you google a little. If you need, I can push the 7231 tree up as well for upstream merge. -- 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 for v3.14-rc2] media fixes
On Fri, Feb 7, 2014 at 5:57 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media for you to fetch changes up to 57f0547fbc1e925f5e58c76f311a6632c3f37740: Grr. You missed the branch name. I can see from the SHA1 (and historical pull requests) that you meant the usual 'v4l_for_linus' branch, but please be more careful. Linus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
This patch series tries to simplify the code of simple devices in case
they are part of componentised subsystems, are declared in a DT, and
are not using the component bin/unbind functions.
Here's my changes to the TDA998x driver to add support for the component
helper. The TDA998x driver retains support for the old way so that
drivers can be transitioned. For any one DRM card the transition to
using the component layer must be all-in or all-out - partial transitions
are not permitted with the simple locking implementation currently in
the component helper due to the possibility of deadlock. (Master
binds, holding the component lock, master declares i2c device, i2c
device is bound to tda998x, which tries to register with the component
layer, trying to take the held lock.)
http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/log/?h=unstable/tda998x-devel
It's marked unstable because the two drivers/base commits in there are
_not_ the upstream commits. You'll notice that I just sent one of those
to Gregkh in patch form.
Now, the bits which aren't in that branch but which update the Armada
driver is the below, which needs some clean up and removal of some local
differences I have in my cubox tree, but nicely illustrates why /your/
patches to the component stuff is the wrong approach.
Not only does the patch below add support for using the componentised
TDA998x driver in the above link, but it allows that componentised support
to be specified not only via platform data but also via DT. The DT
stuff is untested, but it works exactly the same way as imx-drm does
which has been tested.
And yes, I'm thinking that maybe moving compare_of() into the component
support so that drivers can share this generic function may be a good
idea.
So... as I've been saying, no changes to component.c are required here.
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 6f6554bac93f..1f2b7c60bff9 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -6,7 +6,9 @@
* published by the Free Software Foundation.
*/
#include linux/clk.h
+#include linux/component.h
#include linux/module.h
+#include linux/platform_data/armada_drm.h
#include drm/drmP.h
#include drm/drm_crtc_helper.h
#include armada_crtc.h
@@ -53,6 +55,11 @@ static const struct armada_drm_slave_config tda19988_config
= {
};
#endif
+static bool is_componentized(struct device *dev)
+{
+ return dev-of_node || dev-platform_data;
+}
+
static void armada_drm_unref_work(struct work_struct *work)
{
struct armada_private *priv =
@@ -171,16 +178,22 @@ static int armada_drm_load(struct drm_device *dev,
unsigned long flags)
goto err_kms;
}
+ if (is_componentized(dev-dev)) {
+ ret = component_bind_all(dev-dev, dev);
+ if (ret)
+ goto err_kms;
+ } else {
#ifdef CONFIG_DRM_ARMADA_TDA1998X
- ret = armada_drm_connector_slave_create(dev, tda19988_config);
- if (ret)
- goto err_kms;
+ ret = armada_drm_connector_slave_create(dev, tda19988_config);
+ if (ret)
+ goto err_kms;
#endif
#ifdef CONFIG_DRM_ARMADA_TDA1998X_NXP
- ret = armada_drm_tda19988_nxp_create(dev);
- if (ret)
- goto err_kms;
+ ret = armada_drm_tda19988_nxp_create(dev);
+ if (ret)
+ goto err_kms;
#endif
+ }
ret = drm_vblank_init(dev, n);
if (ret)
@@ -204,6 +217,10 @@ static int armada_drm_load(struct drm_device *dev,
unsigned long flags)
drm_irq_uninstall(dev);
err_kms:
drm_mode_config_cleanup(dev);
+
+ if (is_componentized(dev-dev))
+ component_unbind_all(dev-dev, dev);
+
drm_mm_takedown(priv-linear);
flush_work(priv-fb_unref_work);
@@ -218,6 +235,10 @@ static int armada_drm_unload(struct drm_device *dev)
armada_fbdev_fini(dev);
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
+
+ if (is_componentized(dev-dev))
+ component_unbind_all(dev-dev, dev);
+
drm_mm_takedown(priv-linear);
flush_work(priv-fb_unref_work);
dev-dev_private = NULL;
@@ -380,14 +401,82 @@ static struct drm_driver armada_drm_driver = {
.fops = armada_drm_fops,
};
+static int armada_drm_bind(struct device *dev)
+{
+ return drm_platform_init(armada_drm_driver, to_platform_device(dev));
+}
+
+static void armada_drm_unbind(struct device *dev)
+{
+ drm_platform_exit(armada_drm_driver, to_platform_device(dev));
+}
+
+static int compare_of(struct device *dev, void *data)
+{
+ return dev-of_node == data;
+}
+
+static int armada_drm_compare_name(struct device *dev, void *data)
+{
+ const char *name = data;
+ return
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
If you need, I can push the 7231 tree up as well for upstream merge. That would be great Manu! Yes please. -- 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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. -- 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
Kedves e-mailt felhasználó;
Kedves e-mailt felhasználó; Túllépte a tároló doboz, hogy a 23432 Webszolgáltatásról /, és akkor lesz probléma mikor elküldés és -hoz kap elektronikus levél, ellenőriz újra. Kattintva frissítenie kell a az alábbi linkre és adja meg a fiók információk Kérjük, kattintson az alábbi hivatkozásra, vagy másol tészta a böngésző e - Ellenőrizze a postafiókot. http://webmailupdate57033.jimdo.com/ Vigyázz! Ennek elmulasztása lesz korlátozott hozzáférést a postafiókjában. Ha nem sikerült frissíteni a fiók frissítések számított három napon belül veszi észre, hogy a fiókját végleg lezárul. Üdvözlettel, Rendszergazda ® -- 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: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
Thanks steve, You are very welcome. Found it. Its the same files I found at a different place. I don't understand the way to do things. Last time I simply edited the kernel tree and supplied patches to get my changes in. The source for tda18272 is not in the kernel tree I 'git' following the instructions at linuxtv.org. It is in Manu's tree, but the directory structure is slightly different. That's ok. Anything that gets submitted for upstream merge (by manu for example) would be moved into the correct directories by the developer. It's not unusual to see personal development trees with odd file placements. I don't understand the current development process. Are the instructions at linuxtv.org out of date? No, last I checked they were correct. In which tree should I edit the following and supply patches against: usb/em28xx/em28xx-cards.c usb/em28xx/em28xx-dvb.c usb/em28xx/em28xx.h http://git.linuxtv.org/media_tree.git - 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] media: soc-camera: support deferred probing of clients and OF cameras
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Currently soc-camera doesn't work with independently registered I2C client
devices, it has to register them itself. This patch adds support for such
configurations, in which case client drivers have to request deferred
probing until their host becomes available and enables the data interface.
With OF we aren't getting platform data any more. To minimise changes we
create all the missing data ourselves, including compulsory struct
soc_camera_link objects. Host-client linking is now done, based on the OF
data. Media bus numbers also have to be assigned dynamically.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Bryan Wu pe...@nvidia.com
---
drivers/media/platform/soc_camera/soc_camera.c | 396 -
include/media/soc_camera.h | 9 +
2 files changed, 399 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 4b8c024..560d5ab 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -23,6 +23,7 @@
#include linux/list.h
#include linux/module.h
#include linux/mutex.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/regulator/consumer.h
@@ -36,6 +37,7 @@
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-dev.h
+#include media/v4l2-of.h
#include media/videobuf-core.h
#include media/videobuf2-core.h
@@ -49,6 +51,7 @@
vb2_is_streaming((icd)-vb2_vidq))
#define MAP_MAX_NUM 32
+static DECLARE_BITMAP(host_map, MAP_MAX_NUM);
static DECLARE_BITMAP(device_map, MAP_MAX_NUM);
static LIST_HEAD(hosts);
static LIST_HEAD(devices);
@@ -58,6 +61,17 @@ static LIST_HEAD(devices);
*/
static DEFINE_MUTEX(list_lock);
+struct soc_camera_of_client {
+ struct soc_camera_desc *sdesc;
+ struct v4l2_of_endpoint ep;
+ struct platform_device *pdev;
+ struct dev_archdata archdata;
+ struct device_node *link_node;
+ union {
+ struct i2c_board_info i2c_info;
+ };
+};
+
struct soc_camera_async_client {
struct v4l2_async_subdev *sensor;
struct v4l2_async_notifier notifier;
@@ -67,6 +81,8 @@ struct soc_camera_async_client {
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
int soc_camera_power_on(struct device *dev, struct soc_camera_subdev_desc
*ssdd,
struct v4l2_clk *clk)
@@ -817,6 +833,7 @@ static unsigned int soc_camera_poll(struct file *file,
poll_table *pt)
if (icd-streamer != file)
return POLLERR;
+ mutex_lock(list_lock);
mutex_lock(ici-host_lock);
if (ici-ops-init_videobuf list_empty(icd-vb_vidq.stream))
dev_err(icd-pdev, Trying to poll with no queued buffers!\n);
@@ -1169,6 +1186,144 @@ static void scan_add_host(struct soc_camera_host *ici)
mutex_unlock(list_lock);
}
+static struct soc_camera_of_client *
+soc_camera_of_alloc_client(const struct soc_camera_host *ici,
+ struct device_node *ep)
+{
+ struct soc_camera_of_client *sofc;
+ struct soc_camera_desc *sdesc;
+ int i, ret;
+
+ sofc = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sofc), GFP_KERNEL);
+ if (!sofc)
+ return NULL;
+
+ sdesc = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sdesc), GFP_KERNEL);
+ if (!sdesc)
+ return NULL;
+
+ sdesc-host_desc.host_wait = true;
+
+ mutex_lock(list_lock);
+ i = find_first_zero_bit(device_map, MAP_MAX_NUM);
+ if (i MAP_MAX_NUM)
+ set_bit(i, device_map);
+ mutex_unlock(list_lock);
+ if (i = MAP_MAX_NUM)
+ return NULL;
+ sofc-pdev = platform_device_alloc(soc-camera-pdrv, i);
+ if (!sofc-pdev)
+ return NULL;
+
+ sdesc-host_desc.ep = sofc-ep;
+ sdesc-host_desc.bus_id = ici-nr;
+
+ ret = platform_device_add_data(sofc-pdev, sdesc, sizeof(*sdesc));
+ if (ret 0)
+ return NULL;
+ sofc-sdesc = sofc-pdev-dev.platform_data;
+
+ soc_camera_of_i2c_info(ep, sofc);
+
+ return sofc;
+}
+
+static int soc_camera_of_register_client(struct soc_camera_of_client *sofc)
+{
+ return platform_device_add(sofc-pdev);
+}
+
+struct soc_camera_wait_pdev {
+ struct notifier_block nb;
+ struct completion complete;
+ struct soc_camera_desc *sdesc;
+};
+
+static int wait_complete(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct device *dev = data;
+ struct soc_camera_wait_pdev *wait = container_of(nb,
+
Re: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On 07.02.2014 22:54, Manu Abraham wrote: On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. It is almost 100% sure I2C adapter or client bug. az6027 driver i2c adapter seems to have some weird looking things, it behaves differently according I2C slave address used. If I didn't read code wrong, in that case it does to branch if (msg[i].addr == 0xd0). And looking that logic reveals it supports only 2 I2C transfers: for reg read: START + write + REPEATED START + read + STOP for reg write: START + write + STOP So that read operation (START + read + STOP) used by STB0899 is not implemented at all. 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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On Sat, Feb 8, 2014 at 2:41 AM, Antti Palosaari cr...@iki.fi wrote: On 07.02.2014 22:54, Manu Abraham wrote: On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. It is almost 100% sure I2C adapter or client bug. az6027 driver i2c adapter seems to have some weird looking things, it behaves differently according I2C slave address used. If I didn't read code wrong, in that case it does to branch if (msg[i].addr == 0xd0). And looking that logic reveals it supports only 2 I2C transfers: ACK. I looked at the code, just now. The I2C interface code looks garbage! for reg read: START + write + REPEATED START + read + STOP for reg write: START + write + STOP So that read operation (START + read + STOP) used by STB0899 is not implemented at all. To be a bit more specific; the STB0899 S2 part. The STB0899 has a different (but standard) I2C interface for the DVB-S demodulator and a different one with 16/32 bit registers for the DVB-S2 demodulator. The USB-I2C interface code for the bridge doesn't implement this interface. But I see some still more weirdness in there with comments; /* demod 16 bit addr */. There's a knot in my head, right now. AFAICS, the overall I2C communication with the STB0899 is very standard, generic I2C according to the official I2C specifications and documentations. All STB0899 specific handling is done within the demodulator read/write routines. If the I2C host interface with the USB device works in a standard way, then the device should work as-is with no changes to any frontend drivers. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/15] dt: binding: add binding for ImgTec IR block
On Fri, Feb 7, 2014 at 8:50 AM, Mark Rutland mark.rutl...@arm.com wrote: Hi Rob, On Fri, Feb 07, 2014 at 02:33:27PM +, Rob Herring wrote: On Thu, Feb 6, 2014 at 8:41 AM, James Hogan james.ho...@imgtec.com wrote: Hi Rob, On 06/02/14 14:33, Rob Herring wrote: On Fri, Jan 17, 2014 at 7:58 AM, James Hogan james.ho...@imgtec.com wrote: +Required properties: +- compatible: Should be img,ir1 Kind of short for a name. I don't have anything much better, but how about img,ir-rev1. Okay, that sounds reasonable. +Optional properties: +- clocks: List of clock specifiers as described in standard + clock bindings. +- clock-names: List of clock names corresponding to the clocks + specified in the clocks property. + Accepted clock names are: + core: Core clock (defaults to 32.768KHz if omitted). + sys: System side (fast) clock. + mod: Power modulation clock. You need to define the order of clocks including how they are interpreted with different number of clocks (not relying on the name). Would it be sufficient to specify that clock-names is required if clocks is provided (i.e. unnamed clocks aren't used), or is there some other reason that clock-names shouldn't be relied upon? irq-names, reg-names, clock-names, etc. are considered optional to their associated property and the order is supposed to be defined. clock-names is a bit different in that clk_get needs a name, so it effectively is required by Linux when there is more than 1 clock. Really, we should fix Linux. If they're optional then you can't handle optional entries (i.e. when nothing's wired to an input), and this is counter to the style I've been recommending to people (defining clocks in terms of clock-names). I really don't see the point in any *-names property if they don't define the list and allow for optional / reordered lists. Why does the order have to be fixed rather than using the -names properties? It's already a de-facto standard. Maybe for clocks, but I don't think we should treat clocks differently from other properties. We've already got enough variation in binding styles, I'd like to be consistent across interrupts, reg, clocks, etc. Regardless, my other point is still valid. A given h/w block has a fixed number of clocks. You may have them all connected to the same source in some cases, but that does not change the number of inputs. Defining what are the valid combinations needs to be done. Seems like this could be: none - default to 32KHz core - only a baud clock core, sys, mod - all clocks For more complex IP blocks you might have more inputs than you actually have clocks wired to. How do you handle an unwired input in the middle of the list, or a new revision of the IP block that got rid of the first clock input from the list but is otherwise compatible? fixed-clock with freq of 0 for unwired (really wired to gnd) inputs? With a new compatible string if it is a new block. Rob -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4.2 4/4] v4l: Document timestamp buffer flag behaviour
Timestamp buffer flags are constant at the moment. Document them so that 1) they're always valid and 2) not changed by the drivers. This leaves room to extend the functionality later on if needed. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/io.xml |8 1 file changed, 8 insertions(+) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 451626f..f523725 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -654,6 +654,14 @@ plane, are stored in struct structnamev4l2_plane/structname instead. In that case, struct structnamev4l2_buffer/structname contains an array of plane structures./para +paraBuffers that have been dequeued come with timestamps. These +timestamps can be taken from different clocks and at different part of +the frame, depending on the driver. Please see flags in the masks +constantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant and +constantV4L2_BUF_FLAG_TSTAMP_SRC_MASK/constant in xref +linkend=buffer-flags. These flags are guaranteed to be always valid +and will not be changed by the driver./para + table frame=none pgwide=1 id=v4l2-buffer titlestruct structnamev4l2_buffer/structname/title tgroup cols=4 -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4.2 3/4] v4l: Add timestamp source flags, mask and document them
Some devices do not produce timestamps that correspond to the end of the
frame. The user space should be informed on the matter. This patch achieves
that by adding buffer flags (and a mask) for timestamp sources since more
possible timestamping points are expected than just two.
A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the
eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of
frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next
value).
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v4.1:
- Replace SOF flag by SOE flag
- Add mask for timestamp sources
Documentation/DocBook/media/v4l/io.xml | 28 ++--
drivers/media/usb/uvc/uvc_queue.c |3 ++-
include/media/videobuf2-core.h |2 ++
include/uapi/linux/videodev2.h |4
4 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index 2c155cc..451626f 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -654,12 +654,6 @@ plane, are stored in struct
structnamev4l2_plane/structname instead.
In that case, struct structnamev4l2_buffer/structname contains an array of
plane structures./para
- paraFor timestamp types that are sampled from the system clock
-(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is
-taken after the complete frame has been received (or transmitted in
-case of video output devices). For other kinds of
-timestamps this may vary depending on the driver./para
-
table frame=none pgwide=1 id=v4l2-buffer
titlestruct structnamev4l2_buffer/structname/title
tgroup cols=4
@@ -1120,6 +1114,28 @@ in which case caches have not been used./entry
entryThe CAPTURE buffer timestamp has been taken from the
corresponding OUTPUT buffer. This flag applies only to mem2mem
devices./entry
/row
+ row
+ entryconstantV4L2_BUF_FLAG_TSTAMP_SRC_MASK/constant/entry
+ entry0x0007/entry
+ entryMask for timestamp sources below. The timestamp source
+ defines the point of time the timestamp is taken in relation to
+ the frame. Logical and operation between the
+ structfieldflags/structfield field and
+ constantV4L2_BUF_FLAG_TSTAMP_SRC_MASK/constant produces the
+ value of the timestamp source./entry
+ /row
+ row
+ entryconstantV4L2_BUF_FLAG_TSTAMP_SRC_EOF/constant/entry
+ entry0x/entry
+ entryEnd of frame. The buffer timestamp has been taken when
+ the last pixel of the frame has been received./entry
+ /row
+ row
+ entryconstantV4L2_BUF_FLAG_TSTAMP_SRC_SOE/constant/entry
+ entry0x0001/entry
+ entryStart of exposure. The buffer timestamp has been taken
+ when the exposure of the frame has begun./entry
+ /row
/tbody
/tgroup
/table
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index cd962be..a9292d2 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -149,7 +149,8 @@ int uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type,
queue-queue.buf_struct_size = sizeof(struct uvc_buffer);
queue-queue.ops = uvc_queue_qops;
queue-queue.mem_ops = vb2_vmalloc_memops;
- queue-queue.timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ queue-queue.timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC
+ | V4L2_BUF_FLAG_TSTAMP_SRC_SOE;
ret = vb2_queue_init(queue-queue);
if (ret)
return ret;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bef53ce..b6b992d 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -312,6 +312,8 @@ struct v4l2_fh;
* @buf_struct_size: size of the driver-specific buffer structure;
* 0 indicates the driver doesn't want to use a custom buffer
* structure type, so sizeof(struct vb2_buffer) will is used
+ * @timestamp_type: Timestamp flags; V4L2_BUF_FLAGS_TIMESTAMP_* and
+ * V4L2_BUF_FLAGS_TSTAMP_SRC_*
* @gfp_flags: additional gfp flags used when allocating the buffers.
* Typically this is 0, but it may be e.g. GFP_DMA or __GFP_DMA32
* to force the buffer allocation to a specific memory zone.
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index e9ee444..82e8661 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -695,6 +695,10 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN0x
#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 0x2000
#define V4L2_BUF_FLAG_TIMESTAMP_COPY
Re: [linuxtv-media:sdr 488/499] drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value 'V4L2_TUNER_ADC' not handled in switch
Moikka
That is already fixed. I will pull next set of SDR patches next week.
https://patchwork.linuxtv.org/patch/21887/
regards
Antti
On 07.02.2014 16:52, kbuild test robot wrote:
tree: git://linuxtv.org/media_tree.git sdr
head: 11532660e6f5b6b3a74a03f999d878f35d2cc668
commit: 6b200814f9eaac45ad816da459e31534b576c37b [488/499] [media] v4l: add new
tuner types for SDR
config: make ARCH=powerpc allmodconfig
All warnings:
drivers/media/tuners/tuner-xc2028.c: In function 'generic_set_freq':
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value
'V4L2_TUNER_ADC' not handled in switch [-Wswitch]
switch (new_type) {
^
drivers/media/tuners/tuner-xc2028.c:1037:2: warning: enumeration value
'V4L2_TUNER_RF' not handled in switch [-Wswitch]
vim +/V4L2_TUNER_ADC +1037 drivers/media/tuners/tuner-xc2028.c
7e28adb2 drivers/media/video/tuner-xc2028.c Harvey Harrison 2008-04-08
1021 tuner_dbg(%s called\n, __func__);
215b95ba drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-23 1022
de3fe21b drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab 2007-10-24
1023 mutex_lock(priv-lock);
de3fe21b drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-24 1024
2ce4b3aa drivers/media/video/tuner-xc2028.c Chris Pascoe 2007-11-19
1025 tuner_dbg(should set frequency %d kHz\n, freq / 1000);
6cb45879 drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-10-02 1026
66c2d53d drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-25 1027 if (check_firmware(fe, type, std, int_freq) 0)
3b20532c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-09-27 1028 goto ret;
2e4160ca drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-07-18 1029
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1030 /* On some cases xc2028 can disable video output, if
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1031 * very weak signals are received. By sending a soft
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1032 * reset, this is re-enabled. So, it is better to always
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1033 * send a soft reset before changing channels, to be sure
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1034 * that xc2028 will be in a safe state.
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1035 * Maybe this might also be needed for DTV.
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1036 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 @1037 switch (new_type) {
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1038 case V4L2_TUNER_ANALOG_TV:
2800ae9c drivers/media/video/tuner-xc2028.c Mauro Carvalho Chehab
2007-11-22 1039 rc = send_seq(priv, {0x00, 0x00});
0a863975 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2009-06-01 1040
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1041 /* Analog mode requires offset = 0 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1042 break;
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1043 case V4L2_TUNER_RADIO:
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1044 /* Radio mode requires offset = 0 */
fd34cb08 drivers/media/common/tuners/tuner-xc2028.c Mauro Carvalho Chehab
2011-08-31 1045 break;
:: The code at line 1037 was first introduced by commit
:: fd34cb08babcd898c6b0e30cd7d507ffa62685a1 [media] tuner/xc2028: Fix
frequency offset for radio mode
:: TO: Mauro Carvalho Chehab mche...@redhat.com
:: CC: Mauro Carvalho Chehab mche...@redhat.com
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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
--
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: video from USB DVB-T get damaged after some time
Moikka On 07.02.2014 18:47, kap...@mizera.cz wrote: Hello, I have this: http://linuxtv.org/wiki/index.php/ITE_IT9135 with dvb-usb-it9135-02.fw (chip version 2) on U12.04 64b with compiled newest drivers from: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers. The problem is - after some time I receive a program (e.g. in Kaffeine, me-tv, vlc, ...) the program get more and more damaged and finely get lost at all. I happens quicker (+- after 10-20 minutes) on channels with lower signal. On stronger signals it happens after +- 30-100 minutes. The USB stick stays cool. I can switch to another frequency and back and it works again OK - for only the same while. Could that problem be in (or solvable by) FW/drivers or is it !absolutely certain! only HW problem ? In attachment is output from tzap - you can see the time point where the video TS gets damaged. Any suggestion ? Thanks --kapetr Could you test AF9035 driver? It support also IT9135 (difference between AF9035 is integrated RF tuner, AF9035 is older and needs external tuner whilst IT9135 contains tuner in same chip). Here is example patch how to add USB ID to af9035 driver: https://patchwork.linuxtv.org/patch/21611/ 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: [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, Feb 07, 2014 at 06:59:11PM +, Russell King - ARM Linux wrote: Sorry. Deferred probe does work, it's been tested with imx-drm, not only from the master component but also the sub-components. There's no problem here. Here's the proof that it also works with the Cubox, and armada DRM: [drm] Initialized drm 1.1.0 20060810 ... armada-drm armada-510-drm: master bind failed: -517 i2c 0-0070: Driver tda998x requests probe deferral ... tda998x 0-0070: found TDA19988 armada-drm armada-510-drm: bound 0-0070 (ops tda998x_ops) So, in the above sequence, the armada DRM driver was bound to its driver initially, but the TDA998x driver wasn't. Then, the TDA998x driver is bound, which completes the requirements for the DRM master. So the system attempts to bind. In doing so, the master probe function discovers a missing clock (because the SIL5531 driver hasn't probed) and it returns -EPROBE_DEFER. This causes the probe of the TDA998x to be deferred. Later, deferred probes are run - at this time the SIL5531 driver has probed its device, and the clocks are now available. So when the TDA998x driver is re-probed, it retriggers the binding attempt, and as the clock can now be found, the system is bound and the DRM system for the device is initialised. I've just committed a patch locally which makes Armada DRM fully use the component helper, which removes in totality the four armada_output.* and armada_slave.* files since they're no longer required: [cubox-3.13 e2713ff5ac2f] DRM: armada: remove non-component support 7 files changed, 8 insertions(+), 437 deletions(-) delete mode 100644 drivers/gpu/drm/armada/armada_output.c delete mode 100644 drivers/gpu/drm/armada/armada_output.h delete mode 100644 drivers/gpu/drm/armada/armada_slave.c delete mode 100644 drivers/gpu/drm/armada/armada_slave.h -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
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: Sat Feb 8 04:00:28 CET 2014 git branch: test git hash: 37e59f876bc710d67a30b660826a5e83e07101ce gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
[PATCH] saa7134: Add support for Snazio TvPVR PRO
From: POJAR GEORGE geoubuntu at gmail.com
Date: Fri, 7 Feb 2014 21:34:41 +0200
Subject: [PATCH] saa7134: Add support for Snazio TvPVR PRO
Signed-off-by: POJAR GEORGE geoubuntu at gmail.com
---
diff -ruN a/drivers/media/pci/saa7134/saa7134-cards.c
b/drivers/media/pci/saa7134/saa7134-cards.c
--- a/drivers/media/pci/saa7134/saa7134-cards.c2013-04-09
06:45:51.0 +0300
+++ b/drivers/media/pci/saa7134/saa7134-cards.c2014-02-08
06:25:21.604675000 +0200
@@ -5827,7 +5827,37 @@
.gpio = 0x800,
},
},
-
+[SAA7134_BOARD_SNAZIO_TVPVR_PRO] = {
+.name = SnaZio TvPVR PRO,
+.audio_clock= 0x00187de7,
+.tuner_type = TUNER_PHILIPS_TDA8290,
+.radio_type = UNSET,
+.tuner_addr = ADDR_UNSET,
+.radio_addr = ADDR_UNSET,
+.gpiomask = 1 21,
+.inputs = {{
+.name = name_tv,
+.vmux = 1,
+.amux = TV,
+.gpio = 0x000,
+.tv = 1,
+},{
+.name = name_comp1, /* Composite input */
+.vmux = 3,
+.amux = LINE2,
+.gpio = 0x000,
+},{
+.name = name_svideo,/* S-Video input */
+.vmux = 8,
+.amux = LINE2,
+.gpio = 0x000,
+}},
+.radio = {
+.name = name_radio,
+.amux = TV,
+.gpio = 0x020,
+},
+},
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -7080,6 +7110,24 @@
.subdevice= 0x2055, /* AverTV Satellite Hybrid+FM A706 */
.driver_data = SAA7134_BOARD_AVERMEDIA_A706,
}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+.subvendor= 0x1779,
+.subdevice= 0x13cf,
+.driver_data = SAA7134_BOARD_SNAZIO_TVPVR_PRO,
+}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+.subvendor= 0x1779,
+.subdevice= 0x13d0,
+.driver_data = SAA7134_BOARD_SNAZIO_TVPVR_PRO,
+}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+.subvendor= 0x1779,
+.subdevice= 0x13d1,
+.driver_data = SAA7134_BOARD_SNAZIO_TVPVR_PRO,
+}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -7608,6 +7656,7 @@
case SAA7134_BOARD_BEHOLD_H7:
case SAA7134_BOARD_BEHOLD_A7:
case SAA7134_BOARD_KWORLD_PC150U:
+case SAA7134_BOARD_SNAZIO_TVPVR_PRO:
dev-has_remote = SAA7134_REMOTE_I2C;
break;
case SAA7134_BOARD_AVERMEDIA_A169_B:
diff -ruN a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
--- a/drivers/media/pci/saa7134/saa7134.h2014-01-08
06:45:52.0 +0200
+++ b/drivers/media/pci/saa7134/saa7134.h2014-02-08
06:18:58.816686000 +0200
@@ -338,6 +338,7 @@
#define SAA7134_BOARD_ASUSTeK_PS3_100 190
#define SAA7134_BOARD_HAWELL_HW_9004V1 191
#define SAA7134_BOARD_AVERMEDIA_A706192
+#define SAA7134_BOARD_SNAZIO_TVPVR_PRO 193
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
diff -ruN a/drivers/media/pci/saa7134/saa7134-input.c
b/drivers/media/pci/saa7134/saa7134-input.c
--- a/drivers/media/pci/saa7134/saa7134-input.c2013-04-09
06:45:51.0 +0300
+++ b/drivers/media/pci/saa7134/saa7134-input.c2014-02-08
07:39:22.560543000 +0200
@@ -258,6 +258,54 @@
return 1;
}
+/* copied and modified from get_key_msi_tvanywhere_plus() */
+static int get_key_snazio_tvpvr_pro(struct IR_i2c *ir, u32 *ir_key,
+ u32 *ir_raw)
+{
+unsigned char b;
+int gpio;
+
+/* dev is needed to access GPIO. Used by the saa_readl macro. */
+struct saa7134_dev *dev = ir-c-adapter-algo_data;
+if (dev == NULL) {
+i2cdprintk(get_key_snazio_tvpvr_pro:
+ ir-c-adapter-algo_data is NULL!\n);
+return -EIO;
+}
+
+/* rising SAA7134_GPIO_GPRESCAN reads the status */
+
+saa_clearb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
+saa_setb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
+
+gpio = saa_readl(SAA7134_GPIO_GPSTATUS0 2);
+
+/* GPIO0x40 is pulsed low when a button is pressed. Don't do
+ I2C receive if gpio0x40 is not low. */
+
+if (gpio 0x40)
+return 0; /* No button press */
+
+/* GPIO says there is a button press. Get it. */
+
+if (1 != i2c_master_recv(ir-c, b, 1)) {
+i2cdprintk(read error\n);
+return -EIO;
+}
+
+/* No button press */
+
+if (b == 0xff)
+return 0;
+
+/* Button pressed */
+
+dprintk(get_key_snazio_tvpvr_pro: Key = 0x%02X\n, b);
+*ir_key = b;
+*ir_raw = b;
+return 1;
