Re: Keene
On Fri April 12 2013 02:11:41 Antti Palosaari wrote:
Hello Hans,
That device is working very, thank you for it. Anyhow, I noticed two things.
1) it does not start transmitting just after I plug it - I have to
retune it!
Output says it is tuned to 95.16 MHz by default, but it is not.
After I issue retune, just to same channel it starts working.
$ v4l2-ctl -d /dev/radio0 --set-freq=95.16
Can you try this patch:
diff --git a/drivers/media/radio/radio-keene.c
b/drivers/media/radio/radio-keene.c
index 4c9ae76..99da3d4 100644
--- a/drivers/media/radio/radio-keene.c
+++ b/drivers/media/radio/radio-keene.c
@@ -93,7 +93,7 @@ static int keene_cmd_main(struct keene_device *radio,
unsigned freq, bool play)
/* If bit 4 is set, then tune to the frequency.
If bit 3 is set, then unmute; if bit 2 is set, then mute.
If bit 1 is set, then enter idle mode; if bit 0 is set,
- then enter transit mode.
+ then enter transmit mode.
*/
radio-buffer[5] = (radio-muted ? 4 : 8) | (play ? 1 : 2) |
(freq ? 0x10 : 0);
@@ -350,7 +350,6 @@ static int usb_keene_probe(struct usb_interface *intf,
radio-pa = 118;
radio-tx = 0x32;
radio-stereo = true;
- radio-curfreq = 95.16 * FREQ_MUL;
if (hdl-error) {
retval = hdl-error;
@@ -383,6 +382,8 @@ static int usb_keene_probe(struct usb_interface *intf,
video_set_drvdata(radio-vdev, radio);
set_bit(V4L2_FL_USE_FH_PRIO, radio-vdev.flags);
+ keene_cmd_main(radio, 95.16 * FREQ_MUL, false);
+
retval = video_register_device(radio-vdev, VFL_TYPE_RADIO, -1);
if (retval 0) {
dev_err(intf-dev, could not register video device\n);
2) What is that log printing?
ALSA sound/usb/mixer.c:932 13:0: cannot get min/max values for control 2
(id 13)
usb 5-2: new full-speed USB device number 3 using ohci_hcd
usb 5-2: New USB device found, idVendor=046d, idProduct=0a0e
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2: Product: B-LINK USB Audio
usb 5-2: Manufacturer: HOLTEK
ALSA sound/usb/mixer.c:932 13:0: cannot get min/max values for control 2
(id 13)
radio-keene 5-2:1.2: V4L2 device registered as radio0
No idea, and I don't get that message either.
Regards,
Hans
$ v4l2-ctl -d /dev/radio0 --all -L
Driver Info (not using libv4l2):
Driver name : radio-keene
Card type : Keene FM Transmitter
Bus info : usb-:00:13.0-2
Driver version: 3.9.0
Capabilities : 0x800C
Modulator
Radio
Frequency: 1522560 (95.16 MHz)
Modulator:
Name : FM
Capabilities : 62.5 Hz stereo
Frequency range : 76.0 MHz - 108.0 MHz
Subchannel modulation: stereo
Priority: 2
User Controls
mute (bool) : default=0 value=0
FM Radio Modulator Controls
audio_compression_gain (int): min=-15 max=18 step=3
default=0 value=0 flags=slider
pre_emphasis (menu) : min=0 max=2 default=1 value=1
1: 50 Microseconds
2: 75 Microseconds
tune_power_level (int): min=84 max=118 step=1
default=118 value=118 flags=slider
regards
Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] Camera sensors patches
Hi Mauro, On Sunday 14 April 2013 16:59:58 Mauro Carvalho Chehab wrote: Em Fri, 12 Apr 2013 11:13:06 +0200 Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 81e096c8ac6a064854c2157e0bf802dc4906678c: [media] budget: Add support for Philips Semi Sylt PCI ref. design (2013-04-08 07:28:01 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git sensors/next for you to fetch changes up to c890926a06339944790c5c265e21e8547aa55e49: mt9p031: Use the common clock framework (2013-04-12 11:07:07 +0200) Laurent Pinchart (5): mt9m032: Fix PLL setup mt9m032: Define MT9M032_READ_MODE1 bits mt9p031: Use devm_* managed helpers mt9p031: Add support for regulators mt9p031: Use the common clock framework Hmm... It seems ugly to have regulators and clock framework and other SoC calls inside an i2c driver that can be used by a device that doesn't have regulators. I'm not sure what's the best solution for it, so, I'll be adding those two patches, but it seems that we'll need to restrict the usage of those calls only if the caller driver is a platform driver. The MT9P031 needs power supplies and a clock on all platforms, regardless of the bridge bus type. I suppose the use case that mostly concerns you here is USB webcams where the power supplies and the clock are controlled automatically by the device. If we ever need to support such a device in the future we can of course revisit the driver then, and one possible solution would be to register fixed voltage regulators and a fixed clock. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.10] cx25821: driver overhaul
Hi Mauro, This is the full pull request for all the cx25821 changes for 3.10. It's identical to the patch series posted Sunday, but adds one last patch removing cx25821-audio-upstream.c from the Makefile. Hopefully I can add that functionality back as a proper alsa device for 3.11 or 3.12 at the latest. For now we just want to get rid of the vfs abuse. Regards, Hans The following changes since commit 4c41dab4d69fb887884dc571fd70e4ddc41774fb: [media] rc: fix single line indentation of keymaps/Makefile (2013-04-14 22:51:41 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cx25821 for you to fetch changes up to 8081cd12560049ff97109f3e4eb3c8bd018e8f4c: cx25821: remove cx25821-audio-upstream.c from the Makefile. (2013-04-15 12:23:48 +0200) Hans Verkuil (31): cx25821: do not expose broken video output streams. cx25821: the audio channel was registered as a video node. cx25821: fix compiler warning cx25821: remove bogus radio/vbi/'video-ioctl' support. cx25821: remove unused fields, ioctls. cx25821: fix log_status, querycap. cx25821: make cx25821_sram_channels const. cx25821: remove unnecessary global devlist. cx25821: s_input didn't check for invalid input. cx25821: make lots of externals static. cx25821: remove cropping ioctls. cx25821: remove bogus dependencies. cx25821: embed video_device, clean up some kernel log spam cx25821: convert to the control framework. cx25821: remove TRUE/FALSE/STATUS_(UN)SUCCESSFUL defines. cx25821: remove unnecessary debug messages. cx25821: use core locking. cx25821: remove 'type' field from cx25821_fh. cx25821: move vidq from cx25821_fh to cx25821_channel. cx25821: replace resource management functions with fh ownership. cx25821: switch to v4l2_fh, add event and prio handling. cx25821: g/s/try/enum_fmt related fixes and cleanups. cx25821: remove custom ioctls that duplicate v4l2 ioctls. cx25821: remove references to subdevices that aren't there. cx25821: setup output nodes correctly. cx25821: group all fmt functions together. cx25821: prepare querycap for output support. cx25821: add output format ioctls. cx25821: drop cx25821-video-upstream-ch2.c/h. cx25821: replace custom ioctls with write() cx25821: remove cx25821-audio-upstream.c from the Makefile. drivers/media/pci/cx25821/Kconfig |7 +- drivers/media/pci/cx25821/Makefile |7 +- drivers/media/pci/cx25821/cx25821-alsa.c | 81 +-- drivers/media/pci/cx25821/cx25821-audio-upstream.c | 22 +- drivers/media/pci/cx25821/cx25821-cards.c | 23 - drivers/media/pci/cx25821/cx25821-core.c | 133 + drivers/media/pci/cx25821/cx25821-gpio.c |1 + drivers/media/pci/cx25821/cx25821-i2c.c|3 +- drivers/media/pci/cx25821/cx25821-medusa-video.c | 46 +- drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c | 800 --- drivers/media/pci/cx25821/cx25821-video-upstream-ch2.h | 138 - drivers/media/pci/cx25821/cx25821-video-upstream.c | 519 ++--- drivers/media/pci/cx25821/cx25821-video.c | 1834 - drivers/media/pci/cx25821/cx25821-video.h | 125 + drivers/media/pci/cx25821/cx25821.h| 304 +++--- 15 files changed, 790 insertions(+), 3253 deletions(-) delete mode 100644 drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c delete mode 100644 drivers/media/pci/cx25821/cx25821-video-upstream-ch2.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/7] V4L2 clock and async patches and soc-camera example
Hi, On Friday 12 April 2013 14:48:17 Sylwester Nawrocki wrote: On 04/12/2013 08:13 AM, Guennadi Liakhovetski wrote: On Thu, 11 Apr 2013, Sylwester Nawrocki wrote: On 04/11/2013 11:59 AM, Guennadi Liakhovetski wrote: On Mon, 8 Apr 2013, Guennadi Liakhovetski wrote: [snip] A significant blocking point IMHO is that this API is bound to the circular dependency issue between a sub-device and the host driver. I think we should have at least some specific ideas on how to resolve it before pushing the API upstream. Or are there any already ? Of course there is at least one. I wouldn't propose (soc-camera) patches, that lock modules hard into memory, once probing is complete. Alright then, maybe I should have more carefully analysed you last patch series. One of the ideas I had was to make a sub-device driver drop the reference it has to the clock provider module (the host) as soon as it gets registered to it. But it doesn't seem straightforward with the common clock API. It isn't. Other option is a sysfs attribute at a host driver that would allow to release its sub-device(s). But it sounds a bit strange to me to require userspace to touch some sysfs attributes before being able to remove some modules. Something probably needs to be changed at the high level design to avoid this circular dependency. Here's what I do in my soc-camera patches atm: holding a reference to a (V4L2) clock doesn't increment bridge driver's use-count (for this discussion I describe the combined soc-camera host and soc-camera core functionality as a bridge driver, because that's what most non soc-camera drivers will look like). So, it can be unloaded. Once unloaded, it unregisters its V4L2 async notifier. Inside that the v4l2-async framework first detaches the subdevice driver, then calls the notifier's .unbind() method, which should now unregister the clock. Then, back in v4l2_async_notifier_unregister() the subdevice driver is re-probed, this time with no clock available, so, it re-enters the deferred probing state. Ok, it looks better than I thought initially.. :) Still, aren't there races possible, when the host driver gets unregistered while subdev holds a reference to the clock, and before it gets registered to the host ? The likelihood of that seems very low, but I fail to find any prove it can't happen either. That was the concern I was about to raise as well, before reading your e-mail. Holding a reference to an object that can disappear at any time is asking for trouble. The method currently implemented should work, but is racy in my opinion. The bridge module could be unloaded after the subdev gets a reference to the clock but before it registers itself with v4l2_async_register_subdev(). The clock would then be freed by the bridge, resulting in a crash. I'm not sure if the circular dependency problem can be solved without an explicit way to break the dependency, possibly from userspace (although I'm not sure if that's the best solution). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.9] cx25821: do not expose broken video output streams
Hi Mauro, As requested: the cx25821 fix to prevent it exposing the broken video output streams posing a security risk. Regards, Hans The following changes since commit 4c41dab4d69fb887884dc571fd70e4ddc41774fb: [media] rc: fix single line indentation of keymaps/Makefile (2013-04-14 22:51:41 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cx25821-fix for you to fetch changes up to 7f7ae0c294ed718d4d0fe129518c6b144b68235d: cx25821: do not expose broken video output streams. (2013-04-15 12:23:45 +0200) Hans Verkuil (1): cx25821: do not expose broken video output streams. drivers/media/pci/cx25821/cx25821-video.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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 v9 02/20] V4L2: support asynchronous subdevice registration
Hi Guennadi,
On 04/12/2013 05:40 PM, Guennadi Liakhovetski wrote:
Currently bridge device drivers register devices for all subdevices
synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor
is attached to a video bridge device, the bridge driver will create an I2C
device and wait for the respective I2C driver to probe. This makes linking
of devices straight forward, but this approach cannot be used with
intrinsically asynchronous and unordered device registration systems like
the Flattened Device Tree. To support such systems this patch adds an
asynchronous subdevice registration framework to V4L2. To use it respective
(e.g. I2C) subdevice drivers must register themselves with the framework.
A bridge driver on the other hand must register notification callbacks,
that will be called upon various related events.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v9: addressed Laurent's comments (thanks)
1. moved valid hw-bus_type check
2. made v4l2_async_unregister() void
3. renamed struct v4l2_async_hw_device to struct v4l2_async_hw_info
4. merged struct v4l2_async_subdev_list into struct v4l2_subdev
5. fixed a typo
6. made subdev_num unsigned
drivers/media/v4l2-core/Makefile |3 +-
drivers/media/v4l2-core/v4l2-async.c | 284
++
include/media/v4l2-async.h | 99
include/media/v4l2-subdev.h | 10 ++
4 files changed, 395 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/v4l2-core/v4l2-async.c
create mode 100644 include/media/v4l2-async.h
diff --git a/drivers/media/v4l2-core/Makefile
b/drivers/media/v4l2-core/Makefile
index 628c630..4c33b8d6 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -5,7 +5,8 @@
tuner-objs := tuner-core.o
videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
\
- v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
+ v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
+ v4l2-async.o
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
new file mode 100644
index 000..98db2e0
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -0,0 +1,284 @@
+/*
+ * V4L2 asynchronous subdevice registration API
+ *
+ * Copyright (C) 2012-2013, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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.
+ */
+
[...]
+static void v4l2_async_cleanup(struct v4l2_async_subdev_list *asdl)
+{
+ struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
+
+ v4l2_device_unregister_subdev(sd);
+ /* Subdevice driver will reprobe and put asdl back onto the list */
+ list_del_init(asdl-list);
+ asdl-asd = NULL;
+ sd-dev = NULL;
+}
+
+static void v4l2_async_unregister(struct v4l2_async_subdev_list *asdl)
+{
+ struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
+
+ v4l2_async_cleanup(asdl);
+
+ /* If we handled USB devices, we'd have to lock the parent too */
+ device_release_driver(sd-dev);
+}
+
+int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
+ struct v4l2_async_notifier *notifier)
+{
+ struct v4l2_async_subdev_list *asdl, *tmp;
+ struct v4l2_async_subdev *asd;
+ int i;
+
+ notifier-v4l2_dev = v4l2_dev;
+ INIT_LIST_HEAD(notifier-waiting);
+ INIT_LIST_HEAD(notifier-done);
+
+ for (i = 0; i notifier-subdev_num; i++) {
+ asd = notifier-subdev[i];
+
+ switch (asd-hw.bus_type) {
+ case V4L2_ASYNC_BUS_CUSTOM:
+ case V4L2_ASYNC_BUS_PLATFORM:
+ case V4L2_ASYNC_BUS_I2C:
+ break;
+ default:
+ dev_err(notifier-v4l2_dev ? notifier-v4l2_dev-dev :
NULL,
+ Invalid bus-type %u on %p\n,
+ asd-hw.bus_type, asd);
+ return -EINVAL;
+ }
+ list_add_tail(asd-list, notifier-waiting);
+ }
+
+ mutex_lock(list_lock);
+
+ /* Keep also completed notifiers on the list */
+ list_add(notifier-list, notifier_list);
+
+ list_for_each_entry_safe(asdl, tmp, subdev_list, list) {
+ int ret;
+
+ asd = v4l2_async_belongs(notifier, asdl);
+ if (!asd)
+ continue;
+
+ ret = v4l2_async_test_notify(notifier, asdl, asd);
+ if (ret 0) {
+ mutex_unlock(list_lock);
+ return ret;
+ }
+ }
+
+
[PATCH 1/1] [media] exynos4-is: Fix potential null pointer dereferencing
If fimc-drv_data is NULL, then fimc-drv_data-num_entities would
cause NULL pointer dereferencing.
While at it also remove the check for fimc-id being negative as 'id' is
unsigned variable and can't be less than 0.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos4-is/fimc-core.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-core.c
index f25807d..d388832 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -953,10 +953,9 @@ static int fimc_probe(struct platform_device *pdev)
fimc-drv_data = fimc_get_drvdata(pdev);
fimc-id = pdev-id;
}
- if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities ||
- fimc-id 0) {
- dev_err(dev, Invalid driver data or device id (%d/%d)\n,
- fimc-id, fimc-drv_data-num_entities);
+ if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities) {
+ dev_err(dev, Invalid driver data or device id (%d)\n,
+ fimc-id);
return -EINVAL;
}
if (!dev-of_node)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] Camera sensors patches
Em Mon, 15 Apr 2013 12:19:23 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Hi Mauro, On Sunday 14 April 2013 16:59:58 Mauro Carvalho Chehab wrote: Em Fri, 12 Apr 2013 11:13:06 +0200 Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 81e096c8ac6a064854c2157e0bf802dc4906678c: [media] budget: Add support for Philips Semi Sylt PCI ref. design (2013-04-08 07:28:01 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git sensors/next for you to fetch changes up to c890926a06339944790c5c265e21e8547aa55e49: mt9p031: Use the common clock framework (2013-04-12 11:07:07 +0200) Laurent Pinchart (5): mt9m032: Fix PLL setup mt9m032: Define MT9M032_READ_MODE1 bits mt9p031: Use devm_* managed helpers mt9p031: Add support for regulators mt9p031: Use the common clock framework Hmm... It seems ugly to have regulators and clock framework and other SoC calls inside an i2c driver that can be used by a device that doesn't have regulators. I'm not sure what's the best solution for it, so, I'll be adding those two patches, but it seems that we'll need to restrict the usage of those calls only if the caller driver is a platform driver. The MT9P031 needs power supplies and a clock on all platforms, regardless of the bridge bus type. Well, all digital devices require clock and power. If power is either a simple electric circuit, a battery or a regulator, that depends on the board. I suppose the use case that mostly concerns you here is USB webcams Yes. where the power supplies and the clock are controlled automatically by the device. Or could be not controlled at all. It could be a simple XTAL attached to the sensor or a clock signal provided by the bridge obtained from a fixed XTAL, and a resistor bridge or a Zenner diode providing the needed power voltage. If we ever need to support such a device in the future we can of course revisit the driver then, and one possible solution would be to register fixed voltage regulators and a fixed clock. That is an overkill: devices were the power supply/xtal clock can't be controlled should not require extra software that pretend to control it. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Em Sun, 14 Apr 2013 22:35:05 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 20:08, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 19:46:20 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 17:33:28 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 11:48:39 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
The GPIO register tracking/caching code is partially broken, because
newer
devices provide more than one GPIO register and some of them are even
using
separate registers for read and write access.
Making it work would be too complicated.
It is also used nowhere and doesn't make sense in cases where input
lines are
connected to buttons etc.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12
drivers/media/usb/em28xx/em28xx-core.c | 27
++-
drivers/media/usb/em28xx/em28xx.h |6 --
3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-)
...
@@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16
reg, u8 val,
int oldval;
u8 newval;
- /* Uses cache for gpo/gpio registers */
- if (reg == dev-reg_gpo_num)
- oldval = dev-reg_gpo;
- else if (reg == dev-reg_gpio_num)
- oldval = dev-reg_gpio;
- else
- oldval = em28xx_read_reg(dev, reg);
-
+ oldval = em28xx_read_reg(dev, reg);
if (oldval 0)
return oldval;
That's plain wrong, as it will break GPIO input.
With GPIO, you can write either 0 or 1 to a GPIO output port. So, your
code works for output ports.
However, an input port requires an specific value (either 1 or 0
depending
on the GPIO circuitry). If the wrong value is written there, the input
port
will stop working.
So, you can't simply read a value from a GPIO input and write it. You
need
to shadow the GPIO write values instead.
I don't understand what you mean.
Why can I not read the value of a GPIO input and write it ?
Because, depending on the value you write, it can transform the input
into an
output port.
I don't get it.
We always write to the GPIO register. That's why these functions are
called em28xx_write_* ;)
Whether the write operation is sane or not (e.g. because it modifies the
bit corresponding to an input line) is not subject of these functions.
Writing is sane: GPIO input lines requires writing as well, in order to
set it to either pull-up or pull-down mode (not sure if em28xx supports
both ways).
So, the driver needs to know if it will write there a 0 or 1, and this is
part
of its GPIO configuration.
Let's assume that, on a certain device, you need to write 1 to enable that
input.
A read I/O to that port can return either 0 or 1.
Giving an hypothetical example, please assume this code:
static int write_gpio_bits(u32 out, u32 mask)
{
u32 gpio = (read_gpio_ports() ~mask) | (out mask);
write_gpio_ports(gpio);
}
...
/* Use bit 1 as input GPIO */
write_gpio_bits(1, 1);
/* send a reset via bit 2 GPIO */
write_gpio_bits(2, 2);
write_gpio_bits(0, 2);
write_gpio_bits(2, 2);
If, at the time the above code runs, the input bit 1 is at 0 state,
the subsequent calls will disable the input.
If, instead, only the write operations are cached like:
static int write_gpio_bits(u32 out, u32 mask)
{
static u32 shadow_cache;
shadow_cache = (shadow_cache ~mask) | (out mask);
write_gpio_ports(gpio);
}
there's no such risk, as it will keep using 1 for the input bit.
Hmm... ok, now I understand what you mean.
Are you sure the Empia chips are really working this way ?
Yes. It uses a pretty standard GPIO mechanism at register 0x08. I'm not
so sure about the GPO register 0x04, but using a shadow for it as
well won't hurt, and will reduce a little bit the USB bus traffic.
I checked the em25xx datasheet (excerpt) and it talks about separate
registers for GPIO configuration (unfortunately without explaining their
function in detail).
Interesting. There are several old designs (bttv, saa7134,...) that uses
a separate register for defining the input and the output pins.
I going to do some tests with the Laplace webcam, so far it seems to be
working fine without this caching stuff.
But the reverse-engineering possibilities are quite limited, so someone
with a detailed datasheet should really look this up.
Well, that will affect only devices with input pins connected.
If you test on a hardware without it, you won't notice any difference
at all.
Cheers,
Mauro
--
To unsubscribe from this list:
Re: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
On 04/15/2013 03:51 PM, Mauro Carvalho Chehab wrote: Em Sun, 14 Apr 2013 22:35:05 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: I checked the em25xx datasheet (excerpt) and it talks about separate registers for GPIO configuration (unfortunately without explaining their function in detail). Interesting. There are several old designs (bttv, saa7134,...) that uses a separate register for defining the input and the output pins. That's pretty usual way, likely most common, having separate GPIO configuration and GPIO value registers. If you has a port of GPIO values in one register, and you has configured those as 0-3 INPUT and 4-7 OUTPUT, then writing to that register does not make any changes to bits that are mapped as IN (are just discarded as don't care). In case a bit I/O (which is not not supported by Kernel) writing to input register could enable internal pull-up or pull-down resistor :) IIRC Atmel micro-controllers has such option. 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 v9 02/20] V4L2: support asynchronous subdevice registration
Hi Guennadi,
On Fri, Apr 12, 2013 at 9:10 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Currently bridge device drivers register devices for all subdevices
synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor
is attached to a video bridge device, the bridge driver will create an I2C
device and wait for the respective I2C driver to probe. This makes linking
of devices straight forward, but this approach cannot be used with
intrinsically asynchronous and unordered device registration systems like
the Flattened Device Tree. To support such systems this patch adds an
asynchronous subdevice registration framework to V4L2. To use it respective
(e.g. I2C) subdevice drivers must register themselves with the framework.
A bridge driver on the other hand must register notification callbacks,
that will be called upon various related events.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v9: addressed Laurent's comments (thanks)
1. moved valid hw-bus_type check
2. made v4l2_async_unregister() void
3. renamed struct v4l2_async_hw_device to struct v4l2_async_hw_info
4. merged struct v4l2_async_subdev_list into struct v4l2_subdev
5. fixed a typo
6. made subdev_num unsigned
drivers/media/v4l2-core/Makefile |3 +-
drivers/media/v4l2-core/v4l2-async.c | 284
++
include/media/v4l2-async.h | 99
include/media/v4l2-subdev.h | 10 ++
4 files changed, 395 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/v4l2-core/v4l2-async.c
create mode 100644 include/media/v4l2-async.h
Cant wait until its stable, so thought of fixing it!
Finally I removed some spare time to fix the issue which i was being
pointing from past so many versions.
What was happening is bound() callback was being called for the bridge driver
for every subdevice in the subdevlist. This should not happen the
bound callback in the
bridge driver should only be called only if the interested subdev is
present in subdev list.
Following is the fix for it.
Regards,
--Prabhakar Lad
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 98db2e0..d817cda 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -83,7 +83,20 @@ static int v4l2_async_test_notify(struct
v4l2_async_notifier *notifier,
struct v4l2_async_subdev_list *asdl,
struct v4l2_async_subdev *asd)
{
- int ret;
+ int ret, i, found = 0;
+
+ /* scan through the waiting list and see if the async
+* subdev is present in it.
+*/
+ for (i = 0; i notifier-subdev_num; i++) {
+ if (asd == notifier-subdev[i]) {
+ found = 1;
+ break;
+ }
+ }
+ /* The async subdev 'asd' is not intrseted by waiting list */
+ if (!found)
+ return 0;
/* Remove from the waiting list */
list_del(asd-list);
--
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 0/3] em28xx: clean up end extend the GPIO port handling
Em Sun, 14 Apr 2013 22:32:34 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/14/2013 04:32 AM, Mauro Carvalho Chehab wrote: Em Sat, 13 Apr 2013 17:37:26 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 05:25 PM, Mauro Carvalho Chehab wrote: Em Sat, 13 Apr 2013 16:15:39 +0300 Antti Palosaari cr...@iki.fi escreveu: On 04/13/2013 12:48 PM, Frank Schäfer wrote: Patch 1 removes the unneeded and broken gpio register caching code. Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x and patch 3 finally adds a new helper function for gpio ports with separate registers for read and write access. I have nothing to say directly about those patches - they looked good at the quick check. But I wonder if you have any idea if it is possible to use some existing Kernel GPIO functionality in order to provide standard interface (interface like I2C). I did some work last summer in order to use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled by default and due to that there is macros to disable LNA when GPIOLIB is not compiled. I noticed recently there is some ongoing development for Kernel GPIO. I haven't looked yet if it makes use of GPIO interface more common... I have conflicting opinions myself weather we should use gpiolib or not. I don't mind with the fact that GPIOLIB is disabled by default. If all media drivers start depending on it, distros will enable it to keep media support on it. I never took the time to take a look on what methods gpiolib provides. Maybe it will bring some benefits. I dunno. Compare to benefits of I2C bus. It offers standard interface. Also it offers userspace debug interface - like I2C also does. I2C benefit is that the same I2C driver can be used by several different drivers. GPIO code, on the other hand, is on most cases[1] specific to a given device. That is same for GPIO - it offers standard interface between modules for GPIO bus. I used it to control LNA, which is connected to demodulator (cxd2820r) GPIO. It is bridge which gets LNA API commands and GPIO is property of demod. Some interface is needed in order to deliver data between bridge and demod in that case. LNA control is device specific. I fail to see code optimization with any GPIO that it is used only as a simple switch. Ok, if you're doing something more complex at a GPIO, like implementing an UART protocol or I2C (cx231xx does I2C via GPIO), then I can see an advantage on using a library, as the UART/I2C code can be written on a very generic way, using the GPIOLIB to connect the generic code to the device specific GPIO. [1] Ok, if you're using a GPIO pin to carry some protocol inside it, like UART, RC, etc, then I can see a benefit on using a bus type of solution. Just looking at the existing drivers (almost all has some sort of GPIO config), GPIO is just a single register bitmask read/write. Most drivers need already bitmask read/write operations. So, in principle, I can't foresee any code simplification by using a library. Use of lib interface is not very practical inside of module, however it could be used. Again, as compared to I2C there is some bridge drivers which do some I2C access using I2C interface, even bridge could do it directly (as it offers I2C adapter). I think it is most common to do it directly to simplify things. Also, from a very pragmatic view, changing (almost) all existing drivers to use gpiolib is a big effort. It is not needed to implement for all driver as one go. However, for that to happen, one question should be answered: what benefits would be obtained by using gpiolib? Obtain GPIO access between modules using standard interface and offer handy debug interface to switch GPIOs from userspace. It is known that enabling both analog and digital demods at the same time can melt some devices. So, it is risky to allow userspace to touch the GPIOs that enable such chips. (ok, there are also other forms to melt such devices in userspace if the user has CAP_SYS_ADMIN) Do you need eyeglasses? I said it is debug interface. It needs root privileges in order to setup and use. I can say I could surely break more devices via I2C debug interface than GPIO debug interface in case both are implemented by every driver. Just sent garbage writes to well known eeprom addresses and kaboom. Your device is bricked. It is totally stupid to say you could brick your device using debug functionality - yes you can, but it is very unlikely someone does it as a mistake. There are lots of reported cases of devices that got their eeprom corrupted. We even wrote a tool to allow recovering such damaged eeproms. Yet, an eeprom data is something that can be recovered (if the dump of the old eeprom can be obtained from someone else or from
Re: [PATCH RFC] [media] blackfin: add video display driver
Hi Scott!
On Sat April 13 2013 01:52:58 Scott Jiang wrote:
This is a bridge driver for blackfin diplay device.
It can work with ppi or eppi interface. DV timings
are supported.
Thanks for the patch. There are a number of comments below. For the most
part you can save a lot of code by making a few fairly small changes.
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/platform/blackfin/Kconfig| 15 +-
drivers/media/platform/blackfin/Makefile |1 +
drivers/media/platform/blackfin/bfin_display.c | 1151
include/media/blackfin/bfin_display.h | 38 +
4 files changed, 1203 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/platform/blackfin/bfin_display.c
create mode 100644 include/media/blackfin/bfin_display.h
diff --git a/drivers/media/platform/blackfin/Kconfig
b/drivers/media/platform/blackfin/Kconfig
index cc23997..8a8fd75 100644
--- a/drivers/media/platform/blackfin/Kconfig
+++ b/drivers/media/platform/blackfin/Kconfig
@@ -9,7 +9,18 @@ config VIDEO_BLACKFIN_CAPTURE
To compile this driver as a module, choose M here: the
module will be called bfin_capture.
+config VIDEO_BLACKFIN_DISPLAY
+ tristate Blackfin Video Display Driver
+ depends on VIDEO_V4L2 BLACKFIN I2C
+ select VIDEOBUF2_DMA_CONTIG
+ help
+ V4L2 bridge driver for Blackfin video display device.
+ Choose PPI or EPPI as its interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bfin_display.
+
config VIDEO_BLACKFIN_PPI
tristate
- depends on VIDEO_BLACKFIN_CAPTURE
- default VIDEO_BLACKFIN_CAPTURE
+ depends on VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
+ default VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
diff --git a/drivers/media/platform/blackfin/Makefile
b/drivers/media/platform/blackfin/Makefile
index 30421bc..015c8f0 100644
--- a/drivers/media/platform/blackfin/Makefile
+++ b/drivers/media/platform/blackfin/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_VIDEO_BLACKFIN_CAPTURE) += bfin_capture.o
+obj-$(CONFIG_VIDEO_BLACKFIN_DISPLAY) += bfin_display.o
obj-$(CONFIG_VIDEO_BLACKFIN_PPI) += ppi.o
diff --git a/drivers/media/platform/blackfin/bfin_display.c
b/drivers/media/platform/blackfin/bfin_display.c
new file mode 100644
index 000..d971d7b
--- /dev/null
+++ b/drivers/media/platform/blackfin/bfin_display.c
@@ -0,0 +1,1151 @@
+/*
+ * Analog Devices video display driver
+ *
+ * Copyright (c) 2011 Analog Devices Inc.
Analog Devices? What has this to do with Analog Devices?
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/completion.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/types.h
+
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#include asm/dma.h
+
+#include media/blackfin/bfin_display.h
+#include media/blackfin/ppi.h
+
+#define DISPLAY_DRV_NAMEbfin_display
+#define DISP_MIN_NUM_BUF2
+
+struct disp_format {
+ char *desc;
+ u32 pixelformat;
+ enum v4l2_mbus_pixelcode mbus_code;
+ int bpp; /* bits per pixel */
+ int dlen; /* data length for ppi in bits */
+};
+
+struct disp_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+struct disp_device {
+ /* capture device instance */
+ struct v4l2_device v4l2_dev;
+ /* v4l2 control handler */
+ struct v4l2_ctrl_handler ctrl_handler;
+ /* device node data */
+ struct video_device *video_dev;
+ /* sub device instance */
+ struct v4l2_subdev *sd;
+ /* capture config */
+ struct bfin_display_config *cfg;
+ /* ppi interface */
+ struct ppi_if *ppi;
+ /* current output */
+ unsigned int cur_output;
+ /* current selected standard */
+ v4l2_std_id std;
+ /* current selected dv_timings */
+ struct v4l2_dv_timings dv_timings;
+ /* used to store pixel format */
+ struct v4l2_pix_format fmt;
+ /* bits per pixel*/
+ int bpp;
+ /* data length for ppi in bits */
+ int dlen;
+ /*
[GIT PULL FOR v3.10] Two bug fixes and a MAINTAINERS update
It makes sense to get this in 3.10. Regards, Hans The following changes since commit 4c41dab4d69fb887884dc571fd70e4ddc41774fb: [media] rc: fix single line indentation of keymaps/Makefile (2013-04-14 22:51:41 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.10 for you to fetch changes up to c25adc4458686bbdbd643f50ea51fe21e98433c0: cx88: Fix unsafe locking in suspend-resume (2013-04-15 17:10:58 +0200) Alexey Khoroshilov (1): cx88: Fix unsafe locking in suspend-resume Ismael Luceno (1): solo6x10: Update the encoder mode on VIDIOC_S_FMT Lad, Prabhakar (1): MAINTAINERS: change entry for davinci media driver MAINTAINERS|5 ++--- drivers/media/pci/cx88/cx88-mpeg.c | 10 ++ drivers/media/pci/cx88/cx88-video.c| 10 ++ drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c |1 + 4 files changed, 15 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] exynos4-is: Fix potential null pointer dereferencing
Hi Sachin,
On 04/15/2013 02:03 PM, Sachin Kamat wrote:
If fimc-drv_data is NULL, then fimc-drv_data-num_entities would
cause NULL pointer dereferencing.
While at it also remove the check for fimc-id being negative as 'id' is
unsigned variable and can't be less than 0.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos4-is/fimc-core.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-core.c
index f25807d..d388832 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -953,10 +953,9 @@ static int fimc_probe(struct platform_device *pdev)
fimc-drv_data = fimc_get_drvdata(pdev);
fimc-id = pdev-id;
}
- if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities ||
- fimc-id 0) {
- dev_err(dev, Invalid driver data or device id (%d/%d)\n,
- fimc-id, fimc-drv_data-num_entities);
+ if (!fimc-drv_data || fimc-id = fimc-drv_data-num_entities) {
+ dev_err(dev, Invalid driver data or device id (%d)\n,
+ fimc-id);
return -EINVAL;
Thanks for the patch. To make it more explicit I would prefer to change
id type to 'int', and to leave the check for negative value. There is
a similar issue in fimc-lite.c that could be addressed in same patch.
Could you also fix this and resend ?
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] em28xx: give up GPIO register tracking/caching
Am 15.04.2013 14:51, schrieb Mauro Carvalho Chehab:
Em Sun, 14 Apr 2013 22:35:05 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 20:08, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 19:46:20 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 17:33:28 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 11:48:39 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
The GPIO register tracking/caching code is partially broken, because
newer
devices provide more than one GPIO register and some of them are even
using
separate registers for read and write access.
Making it work would be too complicated.
It is also used nowhere and doesn't make sense in cases where input
lines are
connected to buttons etc.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12
drivers/media/usb/em28xx/em28xx-core.c | 27
++-
drivers/media/usb/em28xx/em28xx.h |6 --
3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-)
...
@@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16
reg, u8 val,
int oldval;
u8 newval;
- /* Uses cache for gpo/gpio registers */
- if (reg == dev-reg_gpo_num)
- oldval = dev-reg_gpo;
- else if (reg == dev-reg_gpio_num)
- oldval = dev-reg_gpio;
- else
- oldval = em28xx_read_reg(dev, reg);
-
+ oldval = em28xx_read_reg(dev, reg);
if (oldval 0)
return oldval;
That's plain wrong, as it will break GPIO input.
With GPIO, you can write either 0 or 1 to a GPIO output port. So, your
code works for output ports.
However, an input port requires an specific value (either 1 or 0
depending
on the GPIO circuitry). If the wrong value is written there, the input
port
will stop working.
So, you can't simply read a value from a GPIO input and write it. You
need
to shadow the GPIO write values instead.
I don't understand what you mean.
Why can I not read the value of a GPIO input and write it ?
Because, depending on the value you write, it can transform the input
into an
output port.
I don't get it.
We always write to the GPIO register. That's why these functions are
called em28xx_write_* ;)
Whether the write operation is sane or not (e.g. because it modifies the
bit corresponding to an input line) is not subject of these functions.
Writing is sane: GPIO input lines requires writing as well, in order to
set it to either pull-up or pull-down mode (not sure if em28xx supports
both ways).
So, the driver needs to know if it will write there a 0 or 1, and this is
part
of its GPIO configuration.
Let's assume that, on a certain device, you need to write 1 to enable that
input.
A read I/O to that port can return either 0 or 1.
Giving an hypothetical example, please assume this code:
static int write_gpio_bits(u32 out, u32 mask)
{
u32 gpio = (read_gpio_ports() ~mask) | (out mask);
write_gpio_ports(gpio);
}
...
/* Use bit 1 as input GPIO */
write_gpio_bits(1, 1);
/* send a reset via bit 2 GPIO */
write_gpio_bits(2, 2);
write_gpio_bits(0, 2);
write_gpio_bits(2, 2);
If, at the time the above code runs, the input bit 1 is at 0 state,
the subsequent calls will disable the input.
If, instead, only the write operations are cached like:
static int write_gpio_bits(u32 out, u32 mask)
{
static u32 shadow_cache;
shadow_cache = (shadow_cache ~mask) | (out mask);
write_gpio_ports(gpio);
}
there's no such risk, as it will keep using 1 for the input bit.
Hmm... ok, now I understand what you mean.
Are you sure the Empia chips are really working this way ?
Yes. It uses a pretty standard GPIO mechanism at register 0x08.
Ok, will try to find out how those 0x80...0x87 GPIO registers are working.
I'm not so sure about the GPO register 0x04,
Well, we don't need caching for output lines, just for input lines.
but using a shadow for it as
well won't hurt, and will reduce a little bit the USB bus traffic.
Sure, but the problem is that caching is getting complicated with the
newer devices.
The em2765 in the VAD Laplace webcam for example uses registers
0x80/0x84, 0x81/0x85, 0x83/0x87 and also at least register 0x08 for
GPIO. I don't not about about reg 0x04.
And its seems some bits of reg 0x0C are used for GPIO, too (current
snapshot button support uses bit 6).
Have fun. :(
I checked the em25xx datasheet (excerpt) and it talks about separate
registers for GPIO configuration (unfortunately without explaining their
function in detail).
Interesting. There are several old designs (bttv, saa7134,...) that uses
a separate register for defining the
Re: Patch update notification: 1 patch updated
Am 15.04.2013 17:23, schrieb Patchwork: Hello, The following patch (submitted by you) has been updated in patchwork: * em28xx: add basic support for the SpeedLink Vicious And Devine Laplace webcam - http://patchwork.linuxtv.org/patch/17928/ was: New now: Under Review This patch doesn't apply anymore as it requires 2 of the 3 em28xx GPIO patches that have been dropped. Regards, Frank -- 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
Patchwork and em28xx delegates
I've just noticed that my 2 pending em28xx patches have got delegate assigned: https://patchwork.linuxtv.org/patch/17834/ = delegated to mkrufky https://patchwork.linuxtv.org/patch/17928/ (Obsoleted) = delegated to hverkuil Ist this a patchwork failure or is the new submaintainers workflow the reason ? Regards, Frank -- 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: Patchwork and em28xx delegates
Em Mon, 15 Apr 2013 18:41:44 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: I've just noticed that my 2 pending em28xx patches have got delegate assigned: https://patchwork.linuxtv.org/patch/17834/ = delegated to mkrufky https://patchwork.linuxtv.org/patch/17928/ (Obsoleted) = delegated to hverkuil Ist this a patchwork failure or is the new submaintainers workflow the reason ? Sub-maintainers workflow. We expect that most patches will be applied via one of the sub-maintainers. That will likely improve Kernel's quality and help to reduce the maintainers overload. -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Apr 15 19:00:18 CEST 2013 git branch: test git hash: 4c41dab4d69fb887884dc571fd70e4ddc41774fb gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS 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: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-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: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/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] [media] uvcvideo: quirk PROBE_DEF for Dell Studio / OmniVision webcam
BugLink: https://bugs.launchpad.net/bugs/1168430
OminiVision webcam 0x05a9:0x264a (in Dell Studio Hybrid 140g) needs the
same UVC_QUIRK_PROBE_DEF as other OmniVision model to be recognized
consistently.
Signed-off-by: Kamal Mostafa ka...@canonical.com
---
drivers/media/usb/uvc/uvc_driver.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 5dbefa6..17bd48d 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2163,6 +2163,15 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_DEF },
+ /* Dell Studio Hybrid 140g (OmniVision webcam) */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x05a9,
+ .idProduct= 0x264a,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_PROBE_DEF },
/* Apple Built-In iSight */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
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
Re: [PATCH] bttv: Add CyberVision CV06
On Sunday 14 April 2013 23:26:21 Ondrej Zary wrote: Add CyberVision CV06 4-camera card (from CyberVision SV card kit): http://www.cybervision.com.tw/products-swcard_kits-sv.html There are some interesting things on the card but they're not supported: 4 LEDs, a connector with 4 IN and 4 OUT pins, RESET IN and RESET OUT connectors, a relay and CyberVision CV8088-SV16 chip As there's no documentation and even no driver for any OS available, I've measured the GPIO connections on the card: GPIO[00..11] - CV8088-SV16 (probably a relabelled MCU) GPIO[12..15] - VIN1..VIN4 odd/even field (probably for camera disconnect detection - detected by a LM1881 chip for each input) GPIO[16..19] - IN1..IN4 pins on connector GPIO[20..23] - OUT1..OUT4 pins on connector -- Ondrej Zary -- 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: Patchwork and em28xx delegates
Am 15.04.2013 18:50, schrieb Mauro Carvalho Chehab: Em Mon, 15 Apr 2013 18:41:44 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: I've just noticed that my 2 pending em28xx patches have got delegate assigned: https://patchwork.linuxtv.org/patch/17834/ = delegated to mkrufky https://patchwork.linuxtv.org/patch/17928/ (Obsoleted) = delegated to hverkuil Ist this a patchwork failure or is the new submaintainers workflow the reason ? Sub-maintainers workflow. We expect that most patches will be applied via one of the sub-maintainers. That will likely improve Kernel's quality and help to reduce the maintainers overload. How is the em28xx driver split betweend the submaintainers ? Where should I send em28xx patches in the future ? You are still the em28xx maintainer, right ? Regards, Frank -- 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 mceusb.c -- Kernel 3.9-rc6
Fix mceusb_cmdsize() which returns incorrect datasize=0 for sub-commands
MCE_RSP_GETPORTSTATUS, MCE_RSP_GETWAKESOURCE, MCE_RSP_EQDEVDETAILS,
MCE_RSP_EQEMVER, and MCE_RSP_EQIRNUMPORTS. Change mceusb_cmdsize() name to
reflect that it returns data size not cmd size.
Signed-off-by: William Steidtmann bills...@hbci.com
Acked-by:
--- a/drivers/media/rc/mceusb.c 2013-04-07 22:49:54.0 -0500
+++ b/drivers/media/rc/mceusb.c 2013-04-14 12:18:30.0 -0500
@@ -482,7 +482,7 @@ static char SET_RX_SENSOR[] = {MCE_CMD_P
MCE_RSP_EQIRRXPORTEN, 0x00};
*/
-static int mceusb_cmdsize(u8 cmd, u8 subcmd)
+static int mceusb_cmd_datasize(u8 cmd, u8 subcmd)
{
int datasize = 0;
@@ -493,6 +493,9 @@ static int mceusb_cmdsize(u8 cmd, u8 sub
break;
case MCE_CMD_PORT_SYS:
switch (subcmd) {
+ case MCE_RSP_GETPORTSTATUS:
+ datasize = 5;
+ break;
case MCE_RSP_EQWAKEVERSION:
datasize = 4;
break;
@@ -500,6 +503,9 @@ static int mceusb_cmdsize(u8 cmd, u8 sub
datasize = 2;
break;
case MCE_RSP_EQWAKESUPPORT:
+ case MCE_RSP_GETWAKESOURCE:
+ case MCE_RSP_EQDEVDETAILS:
+ case MCE_RSP_EQEMVER:
datasize = 1;
break;
}
@@ -509,6 +515,7 @@ static int mceusb_cmdsize(u8 cmd, u8 sub
case MCE_RSP_EQIRCFS:
case MCE_RSP_EQIRTIMEOUT:
case MCE_RSP_EQIRRXCFCNT:
+ case MCE_RSP_EQIRNUMPORTS:
datasize = 2;
break;
case MCE_CMD_SIG_END:
@@ -968,7 +975,7 @@ static void mceusb_process_ir_data(struc
for (; i buf_len; i++) {
switch (ir-parser_state) {
case SUBCMD:
- ir-rem = mceusb_cmdsize(ir-cmd, ir-buf_in[i]);
+ ir-rem = mceusb_cmd_datasize(ir-cmd, ir-buf_in[i]);
mceusb_dev_printdata(ir, ir-buf_in, i - 1,
ir-rem + 2, false);
mceusb_handle_command(ir, i);
--
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: Patchwork and em28xx delegates
Em Mon, 15 Apr 2013 23:02:51 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Am 15.04.2013 18:50, schrieb Mauro Carvalho Chehab: Em Mon, 15 Apr 2013 18:41:44 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: I've just noticed that my 2 pending em28xx patches have got delegate assigned: https://patchwork.linuxtv.org/patch/17834/ = delegated to mkrufky https://patchwork.linuxtv.org/patch/17928/ (Obsoleted) = delegated to hverkuil Ist this a patchwork failure or is the new submaintainers workflow the reason ? Sub-maintainers workflow. We expect that most patches will be applied via one of the sub-maintainers. That will likely improve Kernel's quality and help to reduce the maintainers overload. How is the em28xx driver split betweend the submaintainers ? Analog part = Hans Tuners, demods = Mkrufky Where should I send em28xx patches in the future ? To the same place: linux-media@vger.kernel.org. You are still the em28xx maintainer, right ? Currently, I only wear the driver maintainer's hat when there's no other people looking into it, or when the patches would affect something that I'm working with. The advantage is that a patch get more reviews, with is good. Btw, em28xx is not auto-delegated. If it was received such delegation, it is likely because either Hans or Michael (or both) decided to add reviewing your patches on their todo list. Of course, if are there any dependency between the three patches in this series, that means that the entire 3 patch series will needed to be merged into just one sub-maintainers tree. 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 1/3] em28xx: give up GPIO register tracking/caching
Em Mon, 15 Apr 2013 18:26:56 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 15.04.2013 14:51, schrieb Mauro Carvalho Chehab:
Em Sun, 14 Apr 2013 22:35:05 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 20:08, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 19:46:20 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 19:04, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 17:33:28 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.04.2013 16:41, schrieb Mauro Carvalho Chehab:
Em Sat, 13 Apr 2013 11:48:39 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
The GPIO register tracking/caching code is partially broken, because
newer
devices provide more than one GPIO register and some of them are
even using
separate registers for read and write access.
Making it work would be too complicated.
It is also used nowhere and doesn't make sense in cases where input
lines are
connected to buttons etc.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12
drivers/media/usb/em28xx/em28xx-core.c | 27
++-
drivers/media/usb/em28xx/em28xx.h |6 --
3 Dateien geändert, 2 Zeilen hinzugefügt(+), 43 Zeilen entfernt(-)
...
@@ -231,14 +215,7 @@ int em28xx_write_reg_bits(struct em28xx *dev,
u16 reg, u8 val,
int oldval;
u8 newval;
-/* Uses cache for gpo/gpio registers */
-if (reg == dev-reg_gpo_num)
-oldval = dev-reg_gpo;
-else if (reg == dev-reg_gpio_num)
-oldval = dev-reg_gpio;
-else
-oldval = em28xx_read_reg(dev, reg);
-
+oldval = em28xx_read_reg(dev, reg);
if (oldval 0)
return oldval;
That's plain wrong, as it will break GPIO input.
With GPIO, you can write either 0 or 1 to a GPIO output port. So, your
code works for output ports.
However, an input port requires an specific value (either 1 or 0
depending
on the GPIO circuitry). If the wrong value is written there, the
input port
will stop working.
So, you can't simply read a value from a GPIO input and write it. You
need
to shadow the GPIO write values instead.
I don't understand what you mean.
Why can I not read the value of a GPIO input and write it ?
Because, depending on the value you write, it can transform the input
into an
output port.
I don't get it.
We always write to the GPIO register. That's why these functions are
called em28xx_write_* ;)
Whether the write operation is sane or not (e.g. because it modifies the
bit corresponding to an input line) is not subject of these functions.
Writing is sane: GPIO input lines requires writing as well, in order to
set it to either pull-up or pull-down mode (not sure if em28xx supports
both ways).
So, the driver needs to know if it will write there a 0 or 1, and this is
part
of its GPIO configuration.
Let's assume that, on a certain device, you need to write 1 to enable
that
input.
A read I/O to that port can return either 0 or 1.
Giving an hypothetical example, please assume this code:
static int write_gpio_bits(u32 out, u32 mask)
{
u32 gpio = (read_gpio_ports() ~mask) | (out mask);
write_gpio_ports(gpio);
}
...
/* Use bit 1 as input GPIO */
write_gpio_bits(1, 1);
/* send a reset via bit 2 GPIO */
write_gpio_bits(2, 2);
write_gpio_bits(0, 2);
write_gpio_bits(2, 2);
If, at the time the above code runs, the input bit 1 is at 0 state,
the subsequent calls will disable the input.
If, instead, only the write operations are cached like:
static int write_gpio_bits(u32 out, u32 mask)
{
static u32 shadow_cache;
shadow_cache = (shadow_cache ~mask) | (out mask);
write_gpio_ports(gpio);
}
there's no such risk, as it will keep using 1 for the input bit.
Hmm... ok, now I understand what you mean.
Are you sure the Empia chips are really working this way ?
Yes. It uses a pretty standard GPIO mechanism at register 0x08.
Ok, will try to find out how those 0x80...0x87 GPIO registers are working.
Ok.
I'm not so sure about the GPO register 0x04,
Well, we don't need caching for output lines, just for input lines.
You understood me wrong: I mean that I'm not sure if register 0x04 is
only for output pins, or if then can also be used for input.
In doubt, better to cache.
but using a shadow for it as
well won't hurt, and will reduce a little bit the USB bus traffic.
Sure, but the problem is that caching is getting complicated with the
newer devices.
The em2765 in the VAD Laplace webcam for example uses registers
0x80/0x84, 0x81/0x85, 0x83/0x87 and also at least register 0x08 for
GPIO. I don't not about about reg 0x04.
And its seems some bits of reg 0x0C are used for
Re: [PATCH -next] media:
On Tue, 9 Apr 2013, Antti Palosaari wrote: On 04/08/2013 08:47 PM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix randconfig error when USB is not enabled: ERROR: usb_control_msg [drivers/media/common/cypress_firmware.ko] undefined! Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi --- drivers/media/common/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20130408.orig/drivers/media/common/Kconfig +++ linux-next-20130408/drivers/media/common/Kconfig @@ -18,6 +18,7 @@ config VIDEO_TVEEPROM config CYPRESS_FIRMWARE tristate Cypress firmware helper routines + depends on USB source drivers/media/common/b2c2/Kconfig source drivers/media/common/saa7146/Kconfig Mauro, this problem persists in linux-next seven days later, any chance we can get this fix from Randy merged? -- 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
