Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Laurent and Sylwester, My apologies for the late answer. On Fri, Jul 27, 2012 at 12:50:13AM +0200, Laurent Pinchart wrote: Hi Sylwester, On Thursday 26 July 2012 22:39:31 Sylwester Nawrocki wrote: On 07/26/2012 05:21 PM, Laurent Pinchart wrote: On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 + 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601; +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V); +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) + or 2.8V (2.5V to 3.1V); + +Optional properties: + +- clock-frequency : the IP's main (system bus) clock frequency in Hz, the default Is that the input clock frequency ? Can't it vary ? Instead of accessing the Yes, the description is incorrect in this patch, it should read: +- clock-frequency : the sensor's master clock frequency in Hz; and be a required property. As in this patch: https://github.com/snawrocki/linux/commit/e8a5f890dec0d7414b656bb1d1ac97d5e7 abe563 It could vary (as this is a PLL input frequency), so probably a range would be a better alternative. Given that host device won't always be able to set this exact value... A range sounds good, or perhaps a list of ranges. Sakari, what would you need for the SMIA++ driver ? Typically the sensor's external clock is derived from another clock using a divisor. This means there's usually quite limited selection of possible clock frequencies since the sensors usually have a small range of possible frequencies such as 6 -- 27 MHz or even less. Also it's important to choose the frequency in such a way that it doesn't interfere with other devices in the system. The frequency also must be picked so that one can achieve the desired highest data transfer rate. The sensors are also quite flexible in their internal clock tree configuration, but in the situation where the desired data rate is close to sensor limits there may be additional constraints. Still it's always possible to come up with a best value for the board while other values are inferior. For these reasons I see little point in providing anything else than just a single value for the external clock frequency. This value is board-specific. sensor clock frequency from the FIMC driver you should reference a clock in the sensor DT node. That obviously requires generic clock support, which might not be available for your platform yet (that's one of the reasons the OMAP3 ISP driver doesn't support DT yet). I agree it might be better, but waiting unknown number of kernel releases for the platforms to get converted to common clock API is not a good alternative either. I guess we could have some transitional solutions while other subsystems are getting adapted. I agree, we need an interim solution. The SMIA++ driver allows the platform data to have either the clock name or a function pointer to set the clock frequency. If the clock name is there it'll be used instead. The function pointer can be removed once it's no longer needed. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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] [media] winbond-cir: Fix initialization
+#ifdef CONFIG_SERIAL_8250
Coule be modular
+ if (!io) {
+ struct uart_port port = { .iobase = data-sbase };
+ int line = serial8250_find_port(port);
+ if (line = 0) {
+ serial8250_unregister_port(line);
Hmm... Not sure if it makes sense, but perhaps the unregistering code
should be reverting serial8250_unregister_port(line).
Can't do that anyway it may well be busy.
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -2914,6 +2914,7 @@ int serial8250_find_port(struct uart_port *p)
}
return -ENODEV;
}
+EXPORT_SYMBOL(serial8250_find_port);
No - this leaks all the uart internal abstractions into the tree. We
really don't want that happening.
The right way to fix this (and a couple of other uglies) is to make 8250
on x86 scan for PnP ports *before* generic ports and to make a note of
any ports to skip on the PnP scan (so that the port poking scan ignores
them too)
Alan
--
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 0/6] HID: picoLCD additional fixes + CIR support
Hi, This series fixes some race conditions in picoLCD driver during remove() and adds support for IR functionality. Repeatedly binding/unbinding device at hid-picolcd driver level or at usbhid level now works properly (except in rare occasions which trigger a paging error in interrupt context (memcopy) and seem to come from usbhid internals when usbhid gets interrupt between hid_hw_close() and hid_hw_stop()). CIR support is added using RC_CORE for the decoding and handling of IR-event stream and works for a Sony and a JVC remote. Bruno -- 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/6] HID: picoLCD: Add support for CIR
Implement support for picoLCD's CIR header using RC_CORE for decoding
the IR event stream.
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
drivers/hid/hid-picolcd.h |5 ++-
drivers/hid/hid-picolcd_cir.c | 95 +++-
drivers/hid/hid-picolcd_core.c |3 +-
3 files changed, 98 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-picolcd.h b/drivers/hid/hid-picolcd.h
index dc4c795..240eb1c 100644
--- a/drivers/hid/hid-picolcd.h
+++ b/drivers/hid/hid-picolcd.h
@@ -85,7 +85,9 @@ struct picolcd_data {
/* input stuff */
u8 pressed_keys[2];
struct input_dev *input_keys;
- struct input_dev *input_cir;
+#ifdef CONFIG_HID_PICOLCD_CIR
+ struct rc_dev *rc_dev;
+#endif
unsigned short keycode[PICOLCD_KEYS];
#ifdef CONFIG_HID_PICOLCD_FB
@@ -114,6 +116,7 @@ struct picolcd_data {
int status;
#define PICOLCD_BOOTLOADER 1
#define PICOLCD_FAILED 2
+#define PICOLCD_CIR_SHUN 4
};
#ifdef CONFIG_HID_PICOLCD_FB
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index dc632c3..f38af30 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -37,6 +37,7 @@
#include linux/completion.h
#include linux/uaccess.h
#include linux/module.h
+#include media/rc-core.h
#include hid-picolcd.h
@@ -44,18 +45,108 @@
int picolcd_raw_cir(struct picolcd_data *data,
struct hid_report *report, u8 *raw_data, int size)
{
- /* Need understanding of CIR data format to implement ... */
+ unsigned long flags;
+ int i, w, sz;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ /* ignore if rc_dev is NULL or status is shunned */
+ spin_lock_irqsave(data-lock, flags);
+ if (data-rc_dev (data-status PICOLCD_CIR_SHUN)) {
+ spin_unlock_irqrestore(data-lock, flags);
+ return 1;
+ }
+ spin_unlock_irqrestore(data-lock, flags);
+
+ /* PicoLCD USB packets contain 16-bit intervals in network order,
+* with value negated for pulse. Intervals are in microseconds.
+*
+* Note: some userspace LIRC code for PicoLCD says negated values
+* for space - is it a matter of IR chip? (pulse for my TSOP2236)
+*
+* In addition, the first interval seems to be around 15000 + base
+* interval for non-first report of IR data - thus the quirk below
+* to get RC_CODE to understand Sony and JVC remotes I have at hand
+*/
+ sz = size 0 ? min((int)raw_data[0], size-1) : 0;
+ for (i = 0; i+1 sz; i += 2) {
+ init_ir_raw_event(rawir);
+ w = (raw_data[i] 8) | (raw_data[i+1]);
+ rawir.pulse = !!(w 0x8000);
+ rawir.duration = US_TO_NS(rawir.pulse ? (65536 - w) : w);
+ /* Quirk!! - see above */
+ if (i == 0 rawir.duration 1500)
+ rawir.duration -= 1500;
+ ir_raw_event_store(data-rc_dev, rawir);
+ }
+ ir_raw_event_handle(data-rc_dev);
+
return 1;
}
+static int picolcd_cir_open(struct rc_dev *dev)
+{
+ struct picolcd_data *data = dev-priv;
+ unsigned long flags;
+
+ spin_lock_irqsave(data-lock, flags);
+ data-status = ~PICOLCD_CIR_SHUN;
+ spin_unlock_irqrestore(data-lock, flags);
+ return 0;
+}
+
+static void picolcd_cir_close(struct rc_dev *dev)
+{
+ struct picolcd_data *data = dev-priv;
+ unsigned long flags;
+
+ spin_lock_irqsave(data-lock, flags);
+ data-status |= PICOLCD_CIR_SHUN;
+ spin_unlock_irqrestore(data-lock, flags);
+}
+
/* initialize CIR input device */
int picolcd_init_cir(struct picolcd_data *data, struct hid_report *report)
{
- /* support not implemented yet */
+ struct rc_dev *rdev;
+ int ret = 0;
+
+ rdev = rc_allocate_device();
+ if (!rdev)
+ return -ENOMEM;
+
+ rdev-priv = data;
+ rdev-driver_type = RC_DRIVER_IR_RAW;
+ rdev-allowed_protos = RC_TYPE_ALL;
+ rdev-open = picolcd_cir_open;
+ rdev-close= picolcd_cir_close;
+ rdev-input_name = data-hdev-name;
+ rdev-input_phys = data-hdev-phys;
+ rdev-input_id.bustype = data-hdev-bus;
+ rdev-input_id.vendor = data-hdev-vendor;
+ rdev-input_id.product = data-hdev-product;
+ rdev-input_id.version = data-hdev-version;
+ rdev-dev.parent = data-hdev-dev;
+ rdev-driver_name = PICOLCD_NAME;
+ rdev-map_name = RC_MAP_RC6_MCE;
+ rdev-timeout = MS_TO_NS(100);
+ rdev-rx_resolution= US_TO_NS(1);
+
+ ret = rc_register_device(rdev);
+ if (ret)
+ goto err;
+ data-rc_dev = rdev;
return 0;
+
+err:
+ rc_free_device(rdev);
+ return ret;
}
void picolcd_exit_cir(struct picolcd_data *data)
{
+ struct
Re: [patch] [media] rc: divide by zero bugs in s_tx_carrier()
On Sat, 2012-08-18 at 18:58 +0300, Dan Carpenter wrote:
carrier comes from a get_user() in ir_lirc_ioctl(). We need to test
that it's not zero before using it as a divisor.
Other RC drivers seem to have the same problem, only more deeply buried.
I think it's better to put this check in ir_lirc_ioctl() instead,
consistent with LIRC_SET_REC_CARRIER.
Ben.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index 647dd95..d05ac15 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -881,10 +881,13 @@ static int ene_set_tx_mask(struct rc_dev *rdev, u32
tx_mask)
static int ene_set_tx_carrier(struct rc_dev *rdev, u32 carrier)
{
struct ene_device *dev = rdev-priv;
- u32 period = 200 / carrier;
+ u32 period;
dbg(TX: attempt to set tx carrier to %d kHz, carrier);
+ if (carrier == 0)
+ return -EINVAL;
+ period = 200 / carrier;
if (period (period ENE_CIRMOD_PRD_MAX ||
period ENE_CIRMOD_PRD_MIN)) {
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 699eef3..2ea913a 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -517,6 +517,9 @@ static int nvt_set_tx_carrier(struct rc_dev *dev, u32
carrier)
struct nvt_dev *nvt = dev-priv;
u16 val;
+ if (carrier == 0)
+ return -EINVAL;
+
nvt_cir_reg_write(nvt, 1, CIR_CP);
val = 300 / (carrier) - 1;
nvt_cir_reg_write(nvt, val 0xff, CIR_CC);
--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.
signature.asc
Description: This is a digitally signed message part
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:Sun Aug 19 19:00:23 CEST 2012 git hash:9b78c5a3007e10a172d4e83bea18509fdff2e8e3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: ERRORS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS
On Sun, Aug 19, 2012 at 10:54 PM, Hans Verkuil hverk...@xs4all.nl wrote: 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:Sun Aug 19 19:00:23 CEST 2012 git hash:9b78c5a3007e10a172d4e83bea18509fdff2e8e3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: ERRORS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS [snip] Can you add to your script notifications to the implied parties ? -- 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: cron job: media_tree daily build: ERRORS
On 08/19/2012 11:09 PM, Anca Emanuel wrote: On Sun, Aug 19, 2012 at 10:54 PM, Hans Verkuil hverk...@xs4all.nl wrote: 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:Sun Aug 19 19:00:23 CEST 2012 git hash:9b78c5a3007e10a172d4e83bea18509fdff2e8e3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: ERRORS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS [snip] Can you add to your script notifications to the implied parties ? +1. Could be good idea to kick driver author once per week or so. Likely those will be fixed more quickly. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 0e49c99..c06992e 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; signature.asc Description: This is a digitally signed message part
Re: [PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
Hi Sangwook, On 08/03/2012 04:24 PM, Sangwook Lee wrote: I was thinking about this, but this seems to be is a bit time-consuming because I have to do this just due to lack of s5k4ecgx hardware information. let me try it later once this patch is accepted. I've converted this driver to use function calls instead of the register arrays. It can be pulled, along with a couple of minor fixes/improvements, from following git tree: git://linuxtv.org/snawrocki/media.git s5k4ecgx (gitweb: http://git.linuxtv.org/snawrocki/media.git/s5k4ecgx) I don't own any Origen board thus it's untested. Could you give it a try ? The register write sequence should be identical as in the case of using the arrays. Regarding support for still (JPEG) capture features of S5K4ECGX, it should be possible to make this work with the mainline s5p-fimc driver, it supports V4L2_PIX_FMT_JPEG/V4L2_MBUS_FMT_JPEG_1X8 formats. There is only missing an API for preallocating proper memory buffer for the snapshot frame. Currently s5p-fimc calculates buffer's size from pixel resolution, using some fixed coefficient. I'm planning on adding new V4L2_CID_FRAMESIZE control that could be a replacement for V4L2_CID_CAM_JPEG_MEMSIZE, as found in this driver: https://android.googlesource.com/kernel/samsung.git/+/3b0c5d2887fca99cab7dd506817b1049d38198a1/drivers/media/video/s5k4ecgx.c Except that, there would be needed a new V4L2_CID_SNAPSHOT control in place of custom V4L2_CID_CAM_CAPTURE. I might try to add that and document in near future. You won't find much regarding the face detection features in V4L2, unfortunately. _Maybe_ I'll try to address this as well on some day, for now private controls might be your only solution. Unless you feel like adding face detection features support to V4L2.. ;) BTW, are your requirements to support both EVT1.0 and EVT1.1 S5K4ECGX revisions ? -- 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: TV Tuner dmesg errors
Latest error log is http://pastebin.com/rP5GMB6d -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- Unlike the previous version, this will apply cleanly to the media staging/for_v3.6 branch. Ben. drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 36fe5a3..24c77a4 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure3; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; signature.asc Description: This is a digitally signed message part
[PATCH 1/4] stk1160: Make kill/free urb debug message more verbose
This is just a cleaning patch to produce more useful
debug messages.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/usb/stk1160/stk1160-video.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-video.c
b/drivers/media/usb/stk1160/stk1160-video.c
index 3785269..022092a 100644
--- a/drivers/media/usb/stk1160/stk1160-video.c
+++ b/drivers/media/usb/stk1160/stk1160-video.c
@@ -342,18 +342,18 @@ static void stk1160_isoc_irq(struct urb *urb)
*/
void stk1160_cancel_isoc(struct stk1160 *dev)
{
- int i;
+ int i, num_bufs = dev-isoc_ctl.num_bufs;
/*
* This check is not necessary, but we add it
* to avoid a spurious debug message
*/
- if (!dev-isoc_ctl.num_bufs)
+ if (!num_bufs)
return;
- stk1160_dbg(killing urbs...\n);
+ stk1160_dbg(killing %d urbs...\n, num_bufs);
- for (i = 0; i dev-isoc_ctl.num_bufs; i++) {
+ for (i = 0; i num_bufs; i++) {
/*
* To kill urbs we can't be in atomic context.
@@ -373,11 +373,11 @@ void stk1160_cancel_isoc(struct stk1160 *dev)
void stk1160_free_isoc(struct stk1160 *dev)
{
struct urb *urb;
- int i;
+ int i, num_bufs = dev-isoc_ctl.num_bufs;
- stk1160_dbg(freeing urb buffers...\n);
+ stk1160_dbg(freeing %d urb buffers...\n, num_bufs);
- for (i = 0; i dev-isoc_ctl.num_bufs; i++) {
+ for (i = 0; i num_bufs; i++) {
urb = dev-isoc_ctl.urb[i];
if (urb) {
--
1.7.8.6
--
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/4] stk1160: Handle urb allocation failure condition properly
When an urb buffer can't be allocated, the currently allocated
buffer count must be saved so they can properly released.
Moreover, it's sufficient to call stk1160_free_isoc to have
all urb buffers released.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/usb/stk1160/stk1160-video.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-video.c
b/drivers/media/usb/stk1160/stk1160-video.c
index 022092a..8bdfb02 100644
--- a/drivers/media/usb/stk1160/stk1160-video.c
+++ b/drivers/media/usb/stk1160/stk1160-video.c
@@ -462,8 +462,7 @@ int stk1160_alloc_isoc(struct stk1160 *dev)
urb = usb_alloc_urb(max_packets, GFP_KERNEL);
if (!urb) {
stk1160_err(cannot alloc urb[%d]\n, i);
- stk1160_uninit_isoc(dev);
- return -ENOMEM;
+ goto free_i_bufs;
}
dev-isoc_ctl.urb[i] = urb;
@@ -474,10 +473,9 @@ int stk1160_alloc_isoc(struct stk1160 *dev)
dev-isoc_ctl.transfer_buffer[i] = kmalloc(sb_size, GFP_KERNEL);
#endif
if (!dev-isoc_ctl.transfer_buffer[i]) {
- stk1160_err(cannot alloc %d bytes for tx buffer\n,
- sb_size);
- stk1160_uninit_isoc(dev);
- return -ENOMEM;
+ stk1160_err(cannot alloc %d bytes for tx[%d] buffer\n,
+ sb_size, i);
+ goto free_i_bufs;
}
memset(dev-isoc_ctl.transfer_buffer[i], 0, sb_size);
@@ -514,5 +512,11 @@ int stk1160_alloc_isoc(struct stk1160 *dev)
dev-isoc_ctl.num_bufs = num_bufs;
return 0;
+
+free_i_bufs:
+ /* Save the allocated buffers so far, so we can properly free them */
+ dev-isoc_ctl.num_bufs = i+1;
+ stk1160_free_isoc(dev);
+ return -ENOMEM;
}
--
1.7.8.6
--
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/4] stk1160: Fix s_fmt and try_fmt implementation
The driver was expecting to get a valid pixelformat on s_fmt and try_fmt.
This is wrong, since the user may pass a bitmask and expect the driver
to change it, returning a valid (fourcc) pixelformat.
This problem was spotted by v4l2-compliance.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/usb/stk1160/stk1160-v4l.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c
b/drivers/media/usb/stk1160/stk1160-v4l.c
index 1ad4ac1..63c5832 100644
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -318,12 +318,6 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
{
struct stk1160 *dev = video_drvdata(file);
- if (f-fmt.pix.pixelformat != format[0].fourcc) {
- stk1160_err(fourcc format 0x%08x invalid\n,
- f-fmt.pix.pixelformat);
- return -EINVAL;
- }
-
/*
* User can't choose size at his own will,
* so we just return him the current size chosen
@@ -331,6 +325,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
* TODO: Implement frame scaling?
*/
+ f-fmt.pix.pixelformat = dev-fmt-fourcc;
f-fmt.pix.width = dev-width;
f-fmt.pix.height = dev-height;
f-fmt.pix.field = V4L2_FIELD_INTERLACED;
@@ -346,14 +341,11 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void
*priv,
{
struct stk1160 *dev = video_drvdata(file);
struct vb2_queue *q = dev-vb_vidq;
- int rc;
if (vb2_is_busy(q))
return -EBUSY;
- rc = vidioc_try_fmt_vid_cap(file, priv, f);
- if (rc 0)
- return rc;
+ vidioc_try_fmt_vid_cap(file, priv, f);
/* We don't support any format changes */
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] stk1160: Stop device and unqueue buffers when start_streaming() fails
If start_streaming() fails (e.g. out of memory) the driver needs to
rewind the start procedure. This implies possibly stopping the device
and clearing the buffer queue.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/usb/stk1160/stk1160-v4l.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c
b/drivers/media/usb/stk1160/stk1160-v4l.c
index 63c5832..cc5a95f 100644
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -184,7 +184,7 @@ static int stk1160_start_streaming(struct stk1160 *dev)
if (!dev-isoc_ctl.num_bufs || new_pkt_size) {
rc = stk1160_alloc_isoc(dev);
if (rc 0)
- goto out_unlock;
+ goto out_stop_hw;
}
/* submit urbs and enables IRQ */
@@ -192,8 +192,7 @@ static int stk1160_start_streaming(struct stk1160 *dev)
rc = usb_submit_urb(dev-isoc_ctl.urb[i], GFP_KERNEL);
if (rc) {
stk1160_err(cannot submit urb[%d] (%d)\n, i, rc);
- stk1160_uninit_isoc(dev);
- goto out_unlock;
+ goto out_uninit;
}
}
@@ -206,7 +205,16 @@ static int stk1160_start_streaming(struct stk1160 *dev)
stk1160_dbg(streaming started\n);
-out_unlock:
+ mutex_unlock(dev-v4l_lock);
+
+ return 0;
+
+out_uninit:
+ stk1160_uninit_isoc(dev);
+out_stop_hw:
+ usb_set_interface(dev-udev, 0, 0);
+ stk1160_clear_queue(dev);
+
mutex_unlock(dev-v4l_lock);
return rc;
--
1.7.8.6
--
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: [v7] media: coda: Add driver for Coda video codec.
Hi Javier, Did the patch get picked? I didn't see it on git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git Still, how did you test this v4l2 device? Thanks Richard On Fri, Aug 03, 2012 at 01:21:02PM +0200, javier Martin wrote: Hi Richard, thank you for your review. This patch has been reviewed and acked by several people: Reviewed-by: Philipp Zabelp.za...@pengutronix.de Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com For this reason a pull request has already been sent to Mauro recently: http://patchwork.linuxtv.org/patch/13483/ In this case I personally don't think it will be easier to read if this line is split up. My point here is checkpatch. total: 2 errors, 30 warnings, 2086 lines checked Thank you for noticing this. I have solved it in my tree so that Mauro can pull for 3.7. You can find it here: https://github.com/jmartinc/video_visstrim.git for_3.6 Regarding your i.MX6 question, maybe Philippe will be able to help you since I am only interested on i.MX27. However, the driver was developed considering much of his suggestions so that adding support for different chips later is as straightforward as possible. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
