Payment
Dear Recipient, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds. Gloria Peter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Tue Jan 20 04:00:16 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18-x86_64: ERRORS linux-3.19-rc4-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: i2c: add new driver for single string flash.
This patch adds the driver for the single string flash products of TI.
Several single string flash controllers of TI have similar register map
and bit data. This driver supports four products,lm3556, lm3561, lm3642
and lm3648.
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ti-ss-flash.c | 744 +++
include/media/ti-ss-flash.h | 33 ++
4 files changed, 787 insertions(+)
create mode 100644 drivers/media/i2c/ti-ss-flash.c
create mode 100644 include/media/ti-ss-flash.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 205d713..886c1fb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -638,6 +638,15 @@ config VIDEO_LM3646
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_TI_SS_FLASH
+ tristate TI Single String Flash driver support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the signle string flash controllers of TI.
+ It supports LM3556, LM3561, LM3642 and LM3648.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..0e523ec 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
+obj-$(CONFIG_VIDEO_TI_SS_FLASH)+= ti-ss-flash.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/ti-ss-flash.c b/drivers/media/i2c/ti-ss-flash.c
new file mode 100644
index 000..035aeba
--- /dev/null
+++ b/drivers/media/i2c/ti-ss-flash.c
@@ -0,0 +1,744 @@
+/*
+ * drivers/media/i2c/ti-ss-flash.c
+ * General device driver for Single String FLASH LED Drivers of TI
+ * It covers lm3556, lm3561, lm3642 and lm3648.
+ *
+ * Copyright (C) 2015 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * 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.
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/ti-ss-flash.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+/* operation mode */
+enum led_opmode {
+ OPMODE_SHDN = 0x0,
+ OPMODE_INDI_IR,
+ OPMODE_TORCH,
+ OPMODE_FLASH,
+};
+
+/*
+ * register data
+ * @reg : register
+ * @mask : mask bits
+ * @shift : bit shift of data
+ */
+struct ctrl_reg {
+ unsigned int reg;
+ unsigned int mask;
+ unsigned int shift;
+};
+
+/*
+ * unit data
+ * @min : min value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @step : step value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @knee: knee point of step of brightness/timeout
+ *brightness : uA
+ * timeout: ms
+ * @knee_step : step value of brightness or timeout after knee point
+ *brightness : uA
+ * timeout: ms
+ * @max : max value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @ctrl : register info to control brightness or timeout
+ */
+struct ssflash_config {
+ unsigned int min;
+ unsigned int step;
+ unsigned int knee;
+ unsigned int knee_step;
+ unsigned int max;
+ struct ctrl_reg ctrl;
+};
+
+/*
+ * @reg : fault register
+ * @mask : fault mask bit
+ * @v4l2_fault : bit mapping to V4L2_FLASH_FAULT_
+ * refer to include//uapi/linux/v4l2-controls.h
+ */
+struct ssflash_fault {
+ unsigned int reg;
+ unsigned int mask;
+ unsigned int v4l2_fault;
+};
+
+#define NUM_V4L2_FAULT 9
+
+/*
+ * ssflash data
+ * @name: device name
+ * @mode: operation mode control data
+ * @flash_br: flash brightness register and bit data
+ * @timeout: timeout control data
+ * @strobe: strobe control data
+ * @torch_br: torch brightness register and bit data
+ * @fault: fault data
+ * @func: initialize function
+ */
+struct ssflash_data {
+ char *name;
+ struct ctrl_reg mode;
+ struct ssflash_config flash_br;
+ struct ssflash_config timeout;
+ struct ctrl_reg strobe;
+
+ struct ssflash_config torch_br;
+ struct ssflash_fault fault[NUM_V4L2_FAULT];
+
+
Re: [media_build] commit 26052b8e1 (SMIAPP needs kernel 3.20 or up.)
On 01/19/2015 08:06 PM, Tycho Lürsen wrote: Hi Hans, tested this update in media_build against a Debian 3.16 kernel. It still tries to build SMIAPP. So sadly it still gives the same error. Try again. I missed a duplicate VIDEO_SMIAPP entry in versions.txt that is now deleted. I just tried it and it now builds fine for me. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] soc-camera: fix device capabilities in multiple camera host drivers
The V4L2 API requires both .capabilities and .device_caps fields of
struct v4l2_capability to be set. Otherwise the compliance checker
complains and since commit v4l2-ioctl: WARN_ON if querycap didn't fill
device_caps a compile-time warning is issued. Fix this non-compliance
in several soc-camera camera host drivers.
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Only compile tested on one platform. Would be nice to have a slightly
wider test coverage. I'll try to do some more verification too, then send
out as a fix for 3.19 in a day or two.
drivers/media/platform/soc_camera/atmel-isi.c| 5 +++--
drivers/media/platform/soc_camera/mx2_camera.c | 3 ++-
drivers/media/platform/soc_camera/mx3_camera.c | 3 ++-
drivers/media/platform/soc_camera/omap1_camera.c | 3 ++-
drivers/media/platform/soc_camera/pxa_camera.c | 3 ++-
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 4 +++-
6 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 8efe403..6d88523 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -760,8 +760,9 @@ static int isi_camera_querycap(struct soc_camera_host *ici,
{
strcpy(cap-driver, atmel-isi);
strcpy(cap-card, Atmel Image Sensor Interface);
- cap-capabilities = (V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_STREAMING);
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+
return 0;
}
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index ce72bd2..192377f 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1256,7 +1256,8 @@ static int mx2_camera_querycap(struct soc_camera_host
*ici,
{
/* cap-name is set by the friendly caller:- */
strlcpy(cap-card, MX2_CAM_DRIVER_DESCRIPTION, sizeof(cap-card));
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index a60c3bb..0b3299d 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -967,7 +967,8 @@ static int mx3_camera_querycap(struct soc_camera_host *ici,
{
/* cap-name is set by the firendly caller:- */
strlcpy(cap-card, i.MX3x Camera, sizeof(cap-card));
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c
b/drivers/media/platform/soc_camera/omap1_camera.c
index e6b9328..16f65ec 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1427,7 +1427,8 @@ static int omap1_cam_querycap(struct soc_camera_host *ici,
{
/* cap-name is set by the friendly caller:- */
strlcpy(cap-card, OMAP1 Camera, sizeof(cap-card));
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 951226a..8d6e343 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1576,7 +1576,8 @@ static int pxa_camera_querycap(struct soc_camera_host
*ici,
{
/* cap-name is set by the firendly caller:- */
strlcpy(cap-card, pxa_cam_driver_description, sizeof(cap-card));
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 8b27b3e..7178770 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -1652,7 +1652,9 @@ static int sh_mobile_ceu_querycap(struct soc_camera_host
*ici,
struct v4l2_capability *cap)
{
strlcpy(cap-card, SuperH_Mobile_CEU,
Re: [PATCH 2/3] mn88472: make sure the private data struct is nulled after free
On 12/06/2014 09:26 PM, Benjamin Larsson wrote: On 12/06/2014 07:37 PM, Antti Palosaari wrote: I do think it is good practice to set pointers to null generally as that would have saved me several days of work of whentracking down this bug. The current dvb framework contain several other cases where pointers are feed'd but not nulled. There is kzfree() for that, but still I am very unsure should we start zeroing memory upon release driver has allocated, or just relase it using kfree. regards Antti Well I guess I am biased as I have spent lots of time finding a bug that probably wouldn't exist if the policy was that drivers always should set their memory to zero before it is free'd. Just because you zero memory before it is freed doesn't mean it stays zeroed. As soon as it is freed some other process might take that memory and fill it up again. So zeroing is pointless and in fact will only *hide* bugs. The only reason I know of for zeroing memory before freeing is if that memory contains sensitive information and you want to make sure it is gone from memory. You can turn on the kmemcheck kernel option when compiling the kernel to test for accesses to uninitialized memory if you suspect you have a bug in that area. Anyway: Nacked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans Maybe we should have a compile time override so that all free calls zeroes the memory before the actual free? Maybe there already is this kind of feature? MvH Benjamin Larsson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/22] si2168: define symbol rate limits
On 01/19/2015 02:30 PM, Antti Palosaari wrote: Moikka! On 01/19/2015 03:24 PM, Hans Verkuil wrote: On 12/06/2014 10:34 PM, Antti Palosaari wrote: w_scan complains about missing symbol rate limits: This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org Chip supports 1 to 7.2 MSymbol/s on DVB-C. Signed-off-by: Antti Palosaari cr...@iki.fi Antti, Are you planning to make a pull request of this patch series? It looks good to me, so for this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com BTW, please add a cover letter whenever you post a patch series (git send-email --compose). It makes it easier to get an overview of what the patch series is all about. PULL request is here: https://patchwork.linuxtv.org/patch/27416/ I could send new one if needed, there is missing branch name (new Git version has started blaming it). It's probably wise to do that (and rebase at the same time). Are you applying these pull request now? I was expecting Mauro... I'm cleaning up patchwork, and your (very long) patch series were making it hard to work with patchwork. Regards, Hans 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: build failure on ubuntu 14.04.1 LTS
Hi Vincent, you may use this workaround, I have the same problem: https://github.com/ljalves/linux_media/issues/68 Reagrds Francesco 2015-01-19 13:32 GMT+01:00 Vincent McIntyre vincent.mcint...@gmail.com: Hi I am seeing build failures since 11 January. A build I did on 22 December worked fine. My build procedure and the error are shown below. $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS $ uname -a Linux ubuntu 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:30:01 UTC 2014 i686 i686 i686 GNU/Linux $ make distclean $ rm v4l/.config $ git pull $ git log |head commit de98549b53c938b44f578833fe8440b92f4a8c64 Author: Hans Verkuil hans.verk...@cisco.com Date: Mon Jan 12 10:53:27 2015 +0100 Update v3.11_dev_groups.patch Signed-off-by: Hans Verkuil hans.verk...@cisco.com commit 3886d538f89948d49b652465e0d52e6e9a7329ab Author: Hans Verkuil hans.verk...@cisco.com $ ./build --main-git ... CC [M] /home/me/git/clones/media_build/v4l/smiapp-core.o /home/me/git/clones/media_build/v4l/smiapp-core.c: In function 'smiapp_get_pdata': /home/me/git/clones/media_build/v4l/smiapp-core.c:3061:3: error: implicit declaration of function 'of_read_number' [-Werror=implicit-function-declaration] pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2); ^ cc1: some warnings being treated as errors make[3]: *** [/home/me/git/clones/media_build/v4l/smiapp-core.o] Error 1 make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-37-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/me/git/clones/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 491, IN line 4. $ grep -ilr implicit-function-declaration . |grep -v o.cmd ./media/tools/thermal/tmon/Makefile ./media/arch/parisc/math-emu/Makefile ./media/Makefile It's not clear to me whether this a problem with the media_tree code or the media_build code. media/Makefile contains this definition KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ -std=gnu89 Regards Vince -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller
Hi, On 19-01-15 15:10, Chen-Yu Tsai wrote: Hi, On Sat, Dec 20, 2014 at 6:20 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 19-12-14 19:17, Maxime Ripard wrote: Hi, On Thu, Dec 18, 2014 at 09:50:26AM +0100, Hans de Goede wrote: Hi, On 18-12-14 03:48, Chen-Yu Tsai wrote: Hi, On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote: On sun6i the cir block is attached to the reset controller, add support for de-asserting the reset if a reset controller is specified in dt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com --- .../devicetree/bindings/media/sunxi-ir.txt | 2 ++ drivers/media/rc/sunxi-cir.c | 25 -- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 23dd5ad..6b70b9b 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -10,6 +10,7 @@ Required properties: Optional properties: - linux,rc-map-name : Remote control map name. +- resets : phandle + reset specifier pair Should it be optional? Or should we use a sun6i compatible with a mandatory reset phandle? I mean, the driver/hardware is not going to work with the reset missing on sun6i. Seems we are doing it one way for some of our drivers, and the other (optional) way for more generic ones, like USB. I do not believe that we should add a new compatible just because the reset line of a block is hooked up differently. It is the exact same ip-block. Only now the reset is not controlled through the apb-gate, but controlled separately. He has a point though. Your driver might very well probe nicely and everything, but still wouldn't be functional at all because the reset line wouldn't have been specified in the DT. Right, just like other drivers we've, see e.g.: Documentation/devicetree/bindings/mmc/sunxi-mmc.txt Which is dealing with this in the same way. The easiest way to deal with that would be in the bindings doc to update it with a compatible for the A31, and mentionning that the reset property is mandatory there. No the easiest way to deal with this is to expect people writing the dts to know what they are doing, just like we do for a lot of the other blocks in sun6i. Maybe put a generic note somewhere that sun6i has a reset controller, and that for all the blocks with optional resets property it should be considered mandatory on sun6i ? I'm sorry but I'm not going to make this change for the ir bindings given that we've the same situation in a lot of other places. Consistency is important. Moreover I believe that having a sun6i specific compatible string is just wrong, since it is the exact same hardware block as on sun5i, just with its reset line routed differently, just like e.g. the mmc controller, the uarts or the gmac all of which also do not have a sun6i specific compatible to enforce reset controller usage. Regards, Hans Note that the code itself might not change at all though. I'd just like to avoid any potential breaking of the DT bindings themselves. If we further want to refine the code, we can do that however we want. I have a slight preference for a clean error if reset is missing, but I won't get in the way just for that. Seems this patch and the following patch were overlooked after the discussion. Any chance we could get this in? I'm a linux/media sub-maintainer, so I've already send a pull-req for these 2 to the linux/media maintainer, iow this is taken care of :) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/8] [media] exynos-gsc: Convert gsc_m2m_resume() from int to void
Since gsc_m2m_resume() always returns 0, convert it to a void instead.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index bd769d4..1865738 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1025,7 +1025,7 @@ static int gsc_m2m_suspend(struct gsc_dev *gsc)
return timeout == 0 ? -EAGAIN : 0;
}
-static int gsc_m2m_resume(struct gsc_dev *gsc)
+static void gsc_m2m_resume(struct gsc_dev *gsc)
{
struct gsc_ctx *ctx;
unsigned long flags;
@@ -1038,8 +1038,6 @@ static int gsc_m2m_resume(struct gsc_dev *gsc)
if (test_and_clear_bit(ST_M2M_SUSPENDED, gsc-state))
gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-
- return 0;
}
static int gsc_probe(struct platform_device *pdev)
@@ -1168,8 +1166,9 @@ static int gsc_runtime_resume(struct device *dev)
gsc_hw_set_sw_reset(gsc);
gsc_wait_reset(gsc);
+ gsc_m2m_resume(gsc);
- return gsc_m2m_resume(gsc);
+ return 0;
}
static int gsc_runtime_suspend(struct device *dev)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 5/8] [media] exynos-gsc: Fixup clock management at -remove()
To make sure the clock is fully gated in -remove(), we first need to
to bring the device into full power by invoking pm_runtime_get_sync().
Then, let's both unprepare and disable the clock.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index e84bc35..5d3cfe8 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1104,12 +1104,15 @@ static int gsc_remove(struct platform_device *pdev)
{
struct gsc_dev *gsc = platform_get_drvdata(pdev);
+ pm_runtime_get_sync(pdev-dev);
+
gsc_unregister_m2m_device(gsc);
v4l2_device_unregister(gsc-v4l2_dev);
-
vb2_dma_contig_cleanup_ctx(gsc-alloc_ctx);
+ clk_disable_unprepare(gsc-clock);
+
pm_runtime_disable(pdev-dev);
- clk_unprepare(gsc-clock);
+ pm_runtime_put_noidle(pdev-dev);
dev_dbg(pdev-dev, %s driver unloaded\n, pdev-name);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/8] [media] exynos-gsc: Simplify clock management
Instead of having separate functions that fecthes, prepares and
unprepares the clock, let's encapsulate this code into -probe().
This makes error handling easier and decreases the lines of code.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 49
1 file changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index fd2891c..bd769d4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1003,36 +1003,6 @@ static void *gsc_get_drv_data(struct platform_device
*pdev)
return driver_data;
}
-static void gsc_clk_put(struct gsc_dev *gsc)
-{
- if (!IS_ERR(gsc-clock))
- clk_unprepare(gsc-clock);
-}
-
-static int gsc_clk_get(struct gsc_dev *gsc)
-{
- int ret;
-
- dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
-
- gsc-clock = devm_clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc-clock)) {
- dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
- GSC_CLOCK_GATE_NAME);
- return PTR_ERR(gsc-clock);
- }
-
- ret = clk_prepare(gsc-clock);
- if (ret 0) {
- dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
- GSC_CLOCK_GATE_NAME);
- gsc-clock = ERR_PTR(-EINVAL);
- return ret;
- }
-
- return 0;
-}
-
static int gsc_m2m_suspend(struct gsc_dev *gsc)
{
unsigned long flags;
@@ -1101,7 +1071,6 @@ static int gsc_probe(struct platform_device *pdev)
init_waitqueue_head(gsc-irq_queue);
spin_lock_init(gsc-slock);
mutex_init(gsc-lock);
- gsc-clock = ERR_PTR(-EINVAL);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
gsc-regs = devm_ioremap_resource(dev, res);
@@ -1114,9 +1083,19 @@ static int gsc_probe(struct platform_device *pdev)
return -ENXIO;
}
- ret = gsc_clk_get(gsc);
- if (ret)
+ gsc-clock = devm_clk_get(dev, GSC_CLOCK_GATE_NAME);
+ if (IS_ERR(gsc-clock)) {
+ dev_err(dev, failed to get clock~~~: %s\n,
+ GSC_CLOCK_GATE_NAME);
+ return PTR_ERR(gsc-clock);
+ }
+
+ ret = clk_prepare(gsc-clock);
+ if (ret) {
+ dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
+ GSC_CLOCK_GATE_NAME);
return ret;
+ }
ret = devm_request_irq(dev, res-start, gsc_irq_handler,
0, pdev-name, gsc);
@@ -1157,7 +1136,7 @@ err_m2m:
err_v4l2:
v4l2_device_unregister(gsc-v4l2_dev);
err_clk:
- gsc_clk_put(gsc);
+ clk_unprepare(gsc-clock);
return ret;
}
@@ -1170,7 +1149,7 @@ static int gsc_remove(struct platform_device *pdev)
vb2_dma_contig_cleanup_ctx(gsc-alloc_ctx);
pm_runtime_disable(pdev-dev);
- gsc_clk_put(gsc);
+ clk_unprepare(gsc-clock);
dev_dbg(pdev-dev, %s driver unloaded\n, pdev-name);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/22] si2168: define symbol rate limits
On 12/06/2014 10:34 PM, Antti Palosaari wrote:
w_scan complains about missing symbol rate limits:
This dvb driver is *buggy*: the symbol rate limits are undefined - please
report to linuxtv.org
Chip supports 1 to 7.2 MSymbol/s on DVB-C.
Signed-off-by: Antti Palosaari cr...@iki.fi
Antti,
Are you planning to make a pull request of this patch series?
It looks good to me, so for this patch series:
Acked-by: Hans Verkuil hans.verk...@cisco.com
BTW, please add a cover letter whenever you post a patch series (git send-email
--compose).
It makes it easier to get an overview of what the patch series is all about.
Regards,
Hans
---
drivers/media/dvb-frontends/si2168.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..acf0fc3 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -635,6 +635,8 @@ static const struct dvb_frontend_ops si2168_ops = {
.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
.info = {
.name = Silicon Labs Si2168,
+ .symbol_rate_min = 100,
+ .symbol_rate_max = 720,
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
FE_CAN_FEC_3_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 01/22] si2168: define symbol rate limits
Moikka! On 01/19/2015 03:24 PM, Hans Verkuil wrote: On 12/06/2014 10:34 PM, Antti Palosaari wrote: w_scan complains about missing symbol rate limits: This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org Chip supports 1 to 7.2 MSymbol/s on DVB-C. Signed-off-by: Antti Palosaari cr...@iki.fi Antti, Are you planning to make a pull request of this patch series? It looks good to me, so for this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com BTW, please add a cover letter whenever you post a patch series (git send-email --compose). It makes it easier to get an overview of what the patch series is all about. PULL request is here: https://patchwork.linuxtv.org/patch/27416/ I could send new one if needed, there is missing branch name (new Git version has started blaming it). Are you applying these pull request now? I was expecting Mauro... 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 V2 3/8] [media] exynos-gsc: Make driver functional when CONFIG_PM is unset
The driver depended on CONFIG_PM to be functional. Let's remove that
dependency, by enable the runtime PM resourses during -probe() and
update the device's runtime PM status to reflect this.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 1865738..532daa8 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1088,7 +1088,7 @@ static int gsc_probe(struct platform_device *pdev)
return PTR_ERR(gsc-clock);
}
- ret = clk_prepare(gsc-clock);
+ ret = clk_prepare_enable(gsc-clock);
if (ret) {
dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
GSC_CLOCK_GATE_NAME);
@@ -,30 +,29 @@ static int gsc_probe(struct platform_device *pdev)
goto err_v4l2;
platform_set_drvdata(pdev, gsc);
- pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(pdev-dev);
- if (ret 0)
- goto err_m2m;
+
+ gsc_hw_set_sw_reset(gsc);
+ gsc_wait_reset(gsc);
/* Initialize continious memory allocator */
gsc-alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(gsc-alloc_ctx)) {
ret = PTR_ERR(gsc-alloc_ctx);
- goto err_pm;
+ goto err_m2m;
}
dev_dbg(dev, gsc-%d registered successfully\n, gsc-id);
- pm_runtime_put(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
return 0;
-err_pm:
- pm_runtime_put(dev);
err_m2m:
gsc_unregister_m2m_device(gsc);
err_v4l2:
v4l2_device_unregister(gsc-v4l2_dev);
err_clk:
- clk_unprepare(gsc-clock);
+ clk_disable_unprepare(gsc-clock);
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller
Hi, On Sat, Dec 20, 2014 at 6:20 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 19-12-14 19:17, Maxime Ripard wrote: Hi, On Thu, Dec 18, 2014 at 09:50:26AM +0100, Hans de Goede wrote: Hi, On 18-12-14 03:48, Chen-Yu Tsai wrote: Hi, On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote: On sun6i the cir block is attached to the reset controller, add support for de-asserting the reset if a reset controller is specified in dt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com --- .../devicetree/bindings/media/sunxi-ir.txt | 2 ++ drivers/media/rc/sunxi-cir.c | 25 -- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 23dd5ad..6b70b9b 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -10,6 +10,7 @@ Required properties: Optional properties: - linux,rc-map-name : Remote control map name. +- resets : phandle + reset specifier pair Should it be optional? Or should we use a sun6i compatible with a mandatory reset phandle? I mean, the driver/hardware is not going to work with the reset missing on sun6i. Seems we are doing it one way for some of our drivers, and the other (optional) way for more generic ones, like USB. I do not believe that we should add a new compatible just because the reset line of a block is hooked up differently. It is the exact same ip-block. Only now the reset is not controlled through the apb-gate, but controlled separately. He has a point though. Your driver might very well probe nicely and everything, but still wouldn't be functional at all because the reset line wouldn't have been specified in the DT. Right, just like other drivers we've, see e.g.: Documentation/devicetree/bindings/mmc/sunxi-mmc.txt Which is dealing with this in the same way. The easiest way to deal with that would be in the bindings doc to update it with a compatible for the A31, and mentionning that the reset property is mandatory there. No the easiest way to deal with this is to expect people writing the dts to know what they are doing, just like we do for a lot of the other blocks in sun6i. Maybe put a generic note somewhere that sun6i has a reset controller, and that for all the blocks with optional resets property it should be considered mandatory on sun6i ? I'm sorry but I'm not going to make this change for the ir bindings given that we've the same situation in a lot of other places. Consistency is important. Moreover I believe that having a sun6i specific compatible string is just wrong, since it is the exact same hardware block as on sun5i, just with its reset line routed differently, just like e.g. the mmc controller, the uarts or the gmac all of which also do not have a sun6i specific compatible to enforce reset controller usage. Regards, Hans Note that the code itself might not change at all though. I'd just like to avoid any potential breaking of the DT bindings themselves. If we further want to refine the code, we can do that however we want. I have a slight preference for a clean error if reset is missing, but I won't get in the way just for that. Seems this patch and the following patch were overlooked after the discussion. Any chance we could get this in? Hans has made a good argument, so I take back any doubts I raised. ChenYu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: Well, I thought that too. Will's submission from last week has that change: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009 Anyway, yes, that looks better! But I would still consider keeping buffers on the list in .buf_clean(), in which case you can remove it. And walk the list instead of the VB2 internal buffer array, as others have pointed out. Hi Guennadi, Thanks for the clarification. Ian (when he was with us) did say it was particularly difficult to understand WTH this driver was doing. Regarding your first point, if it's safe to skip the actions left in rcar_vin_videobuf_release() then I will do a further rework to remove it completely. Regarding your second, in the patchset Ben linked to above we think we have the appropriate loops: a for loop for queue_buf[], and list_for_each_safe() for anything left in priv-capture; this is consistent with rcar_vin_fill_hw_slot() setting up queue_buf[] with pointers unlinked from priv-capture. This in turn suggests that we are right not to call list_del_init() in both of rcar_vin_stop_streaming()'s loops ... as long as I've correctly interpreted the code and everyone's feedback thus far. Cheers, Wills. -- 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: build failure on ubuntu 14.04.1 LTS
On 01/19/2015 01:32 PM, Vincent McIntyre wrote: Hi I am seeing build failures since 11 January. A build I did on 22 December worked fine. My build procedure and the error are shown below. I've just updated media_build to stop compiling the smiapp driver for kernels 3.20. So if you do 'git pull' in your media_build directory and try again it should work. Regards, Hans $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS $ uname -a Linux ubuntu 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:30:01 UTC 2014 i686 i686 i686 GNU/Linux $ make distclean $ rm v4l/.config $ git pull $ git log |head commit de98549b53c938b44f578833fe8440b92f4a8c64 Author: Hans Verkuil hans.verk...@cisco.com Date: Mon Jan 12 10:53:27 2015 +0100 Update v3.11_dev_groups.patch Signed-off-by: Hans Verkuil hans.verk...@cisco.com commit 3886d538f89948d49b652465e0d52e6e9a7329ab Author: Hans Verkuil hans.verk...@cisco.com $ ./build --main-git ... CC [M] /home/me/git/clones/media_build/v4l/smiapp-core.o /home/me/git/clones/media_build/v4l/smiapp-core.c: In function 'smiapp_get_pdata': /home/me/git/clones/media_build/v4l/smiapp-core.c:3061:3: error: implicit declaration of function 'of_read_number' [-Werror=implicit-function-declaration] pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2); ^ cc1: some warnings being treated as errors make[3]: *** [/home/me/git/clones/media_build/v4l/smiapp-core.o] Error 1 make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-37-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/me/git/clones/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 491, IN line 4. $ grep -ilr implicit-function-declaration . |grep -v o.cmd ./media/tools/thermal/tmon/Makefile ./media/arch/parisc/math-emu/Makefile ./media/Makefile It's not clear to me whether this a problem with the media_tree code or the media_build code. media/Makefile contains this definition KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ -std=gnu89 Regards Vince -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/22] si2168: define symbol rate limits
On 01/19/2015 02:24 PM, Hans Verkuil wrote:
On 12/06/2014 10:34 PM, Antti Palosaari wrote:
w_scan complains about missing symbol rate limits:
This dvb driver is *buggy*: the symbol rate limits are undefined - please
report to linuxtv.org
Chip supports 1 to 7.2 MSymbol/s on DVB-C.
Signed-off-by: Antti Palosaari cr...@iki.fi
Antti,
Are you planning to make a pull request of this patch series?
Never mind, I found the pull request :-)
I'll mark these patches as accepted in patchwork, to keep patchwork clean.
Regards,
Hans
It looks good to me, so for this patch series:
Acked-by: Hans Verkuil hans.verk...@cisco.com
BTW, please add a cover letter whenever you post a patch series (git
send-email --compose).
It makes it easier to get an overview of what the patch series is all about.
Regards,
Hans
---
drivers/media/dvb-frontends/si2168.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..acf0fc3 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -635,6 +635,8 @@ static const struct dvb_frontend_ops si2168_ops = {
.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
.info = {
.name = Silicon Labs Si2168,
+.symbol_rate_min = 100,
+.symbol_rate_max = 720,
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
FE_CAN_FEC_3_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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
Hi,
On Mon, 19 Jan 2015, William Towle wrote:
On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote:
On Thu, 18 Dec 2014, Ben Hutchings wrote:
Well, I thought that too. Will's submission from last week has that
change:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009
Anyway, yes, that looks better! But I would still consider keeping buffers
on the list in .buf_clean(), in which case you can remove it. And walk the
list instead of the VB2 internal buffer array, as others have pointed out.
Hi Guennadi,
Thanks for the clarification. Ian (when he was with us) did say it
was particularly difficult to understand WTH this driver was doing.
Regarding your first point, if it's safe to skip the actions left
in rcar_vin_videobuf_release() then I will do a further rework to
remove it completely.
Regarding your second, in the patchset Ben linked to above we think
we have the appropriate loops: a for loop for queue_buf[], and
list_for_each_safe() for anything left in priv-capture; this is
consistent with rcar_vin_fill_hw_slot() setting up queue_buf[] with
pointers unlinked from priv-capture. This in turn suggests that we
are right not to call list_del_init() in both of
rcar_vin_stop_streaming()'s loops ... as long as I've correctly
interpreted the code and everyone's feedback thus far.
I'm referring to this comment by Hans Verkuil of 14 August last year:
I'm assuming all buffers that are queued to the driver via buf_queue() are
linked into priv-capture. So you would typically call vb2_buffer_done
when you are walking that list:
list_for_each_safe(buf_head, tmp, priv-capture) {
// usually you go from buf_head to the real buffer struct
// containing a vb2_buffer struct
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
list_del_init(buf_head);
}
Please use this rather than looking into internal vb2_queue
datastructures.
I think, that's the right way to implement that clean up loop.
Thanks
Guennadi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/66] dvb-usb-v2: add pointer to 'struct usb_interface' for driver usage
Hi Antti,
I'll mark this whole patch series as 'Accepted' in patchwork. It looks OK
to me, and that way patchwork is cleaned up with only your pull request
remaining.
For whatever it is worth:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
On 12/23/2014 09:48 PM, Antti Palosaari wrote:
Top level pointer on USB probe is struct usb_interface *. Add that
pointer to struct dvb_usb_device that drivers could use it, for
dev_* logging and more.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/dvb_usb.h | 2 ++
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
index 14e111e..41c6363 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
@@ -354,6 +354,7 @@ struct dvb_usb_adapter {
* @name: device name
* @rc_map: name of rc codes table
* @rc_polling_active: set when RC polling is active
+ * @intf: pointer to the device's struct usb_interface
* @udev: pointer to the device's struct usb_device
* @rc: remote controller configuration
* @powered: indicated whether the device is power or not
@@ -370,6 +371,7 @@ struct dvb_usb_device {
const char *name;
const char *rc_map;
bool rc_polling_active;
+ struct usb_interface *intf;
struct usb_device *udev;
struct dvb_usb_rc rc;
int powered;
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 1950f37..9913e0f 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -868,6 +868,7 @@ int dvb_usbv2_probe(struct usb_interface *intf,
goto err;
}
+ d-intf = intf;
d-name = driver_info-name;
d-rc_map = driver_info-rc_map;
d-udev = udev;
--
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 0/8] [media] exynos-gsc: Fixup PM support
Changes in v2: - Rebase patches. - Adapt to changes for the PM core. Especially, the Kconfig option for CONFIG_PM_RUNTIME has been removed and the runtime PM core is now build for CONFIG_PM. This patchset fixup the PM support and adds some minor improvements to potentially save some more power at runtime PM suspend. Ulf Hansson (8): [media] exynos-gsc: Simplify clock management [media] exynos-gsc: Convert gsc_m2m_resume() from int to void [media] exynos-gsc: Make driver functional when CONFIG_PM is unset [media] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM [media] exynos-gsc: Fixup clock management at -remove() [media] exynos-gsc: Do full clock gating at runtime PM suspend [media] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP [media] exynos-gsc: Simplify system PM drivers/media/platform/exynos-gsc/gsc-core.c | 183 +++ drivers/media/platform/exynos-gsc/gsc-core.h | 3 - 2 files changed, 72 insertions(+), 114 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 4/8] [media] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM
There are no need to set up the runtime PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.
Silence the warnings by making them available for CONFIG_PM.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 79 ++--
1 file changed, 40 insertions(+), 39 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 532daa8..e84bc35 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1003,43 +1003,6 @@ static void *gsc_get_drv_data(struct platform_device
*pdev)
return driver_data;
}
-static int gsc_m2m_suspend(struct gsc_dev *gsc)
-{
- unsigned long flags;
- int timeout;
-
- spin_lock_irqsave(gsc-slock, flags);
- if (!gsc_m2m_pending(gsc)) {
- spin_unlock_irqrestore(gsc-slock, flags);
- return 0;
- }
- clear_bit(ST_M2M_SUSPENDED, gsc-state);
- set_bit(ST_M2M_SUSPENDING, gsc-state);
- spin_unlock_irqrestore(gsc-slock, flags);
-
- timeout = wait_event_timeout(gsc-irq_queue,
-test_bit(ST_M2M_SUSPENDED, gsc-state),
-GSC_SHUTDOWN_TIMEOUT);
-
- clear_bit(ST_M2M_SUSPENDING, gsc-state);
- return timeout == 0 ? -EAGAIN : 0;
-}
-
-static void gsc_m2m_resume(struct gsc_dev *gsc)
-{
- struct gsc_ctx *ctx;
- unsigned long flags;
-
- spin_lock_irqsave(gsc-slock, flags);
- /* Clear for full H/W setup in first run after resume */
- ctx = gsc-m2m.ctx;
- gsc-m2m.ctx = NULL;
- spin_unlock_irqrestore(gsc-slock, flags);
-
- if (test_and_clear_bit(ST_M2M_SUSPENDED, gsc-state))
- gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-}
-
static int gsc_probe(struct platform_device *pdev)
{
struct gsc_dev *gsc;
@@ -1152,6 +1115,44 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gsc_m2m_suspend(struct gsc_dev *gsc)
+{
+ unsigned long flags;
+ int timeout;
+
+ spin_lock_irqsave(gsc-slock, flags);
+ if (!gsc_m2m_pending(gsc)) {
+ spin_unlock_irqrestore(gsc-slock, flags);
+ return 0;
+ }
+ clear_bit(ST_M2M_SUSPENDED, gsc-state);
+ set_bit(ST_M2M_SUSPENDING, gsc-state);
+ spin_unlock_irqrestore(gsc-slock, flags);
+
+ timeout = wait_event_timeout(gsc-irq_queue,
+test_bit(ST_M2M_SUSPENDED, gsc-state),
+GSC_SHUTDOWN_TIMEOUT);
+
+ clear_bit(ST_M2M_SUSPENDING, gsc-state);
+ return timeout == 0 ? -EAGAIN : 0;
+}
+
+static void gsc_m2m_resume(struct gsc_dev *gsc)
+{
+ struct gsc_ctx *ctx;
+ unsigned long flags;
+
+ spin_lock_irqsave(gsc-slock, flags);
+ /* Clear for full H/W setup in first run after resume */
+ ctx = gsc-m2m.ctx;
+ gsc-m2m.ctx = NULL;
+ spin_unlock_irqrestore(gsc-slock, flags);
+
+ if (test_and_clear_bit(ST_M2M_SUSPENDED, gsc-state))
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
static int gsc_runtime_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1182,6 +1183,7 @@ static int gsc_runtime_suspend(struct device *dev)
pr_debug(gsc%d: state: 0x%lx, gsc-id, gsc-state);
return ret;
}
+#endif
static int gsc_resume(struct device *dev)
{
@@ -1223,8 +1225,7 @@ static int gsc_suspend(struct device *dev)
static const struct dev_pm_ops gsc_pm_ops = {
.suspend= gsc_suspend,
.resume = gsc_resume,
- .runtime_suspend= gsc_runtime_suspend,
- .runtime_resume = gsc_runtime_resume,
+ SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
};
static struct platform_driver gsc_driver = {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 7/8] [media] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP
There are no need to set up the system PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.
Silence the warnings by making them available for CONFIG_PM_SLEEP.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 0b126eb..194f9fc 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1188,6 +1188,7 @@ static int gsc_runtime_suspend(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1224,10 +1225,10 @@ static int gsc_suspend(struct device *dev)
return 0;
}
+#endif
static const struct dev_pm_ops gsc_pm_ops = {
- .suspend= gsc_suspend,
- .resume = gsc_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 8/8] [media] exynos-gsc: Simplify system PM
It's not needed to keep a local flag about the current system PM state.
Let's just remove that code and the corresponding debug print.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 21 -
drivers/media/platform/exynos-gsc/gsc-core.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 194f9fc..71b227c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1191,20 +1191,6 @@ static int gsc_runtime_suspend(struct device *dev)
#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
- unsigned long flags;
-
- pr_debug(gsc%d: state: 0x%lx, gsc-id, gsc-state);
-
- /* Do not resume if the device was idle before system suspend */
- spin_lock_irqsave(gsc-slock, flags);
- if (!test_and_clear_bit(ST_SUSPEND, gsc-state) ||
- !gsc_m2m_opened(gsc)) {
- spin_unlock_irqrestore(gsc-slock, flags);
- return 0;
- }
- spin_unlock_irqrestore(gsc-slock, flags);
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_resume(dev);
@@ -1213,13 +1199,6 @@ static int gsc_resume(struct device *dev)
static int gsc_suspend(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
-
- pr_debug(gsc%d: state: 0x%lx, gsc-id, gsc-state);
-
- if (test_and_set_bit(ST_SUSPEND, gsc-state))
- return 0;
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_suspend(dev);
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h
b/drivers/media/platform/exynos-gsc/gsc-core.h
index fa572aa..2f62271 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -48,9 +48,6 @@
#defineGSC_CTX_ABORT (1 7)
enum gsc_dev_flags {
- /* for global */
- ST_SUSPEND,
-
/* for m2m node */
ST_M2M_OPEN,
ST_M2M_RUN,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 6/8] [media] exynos-gsc: Do full clock gating at runtime PM suspend
To potentially save more power in runtime PM suspend state, let's also prepare/unprepare the clock from the runtime PM callbacks. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/media/platform/exynos-gsc/gsc-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c index 5d3cfe8..0b126eb 100644 --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -1163,7 +1163,7 @@ static int gsc_runtime_resume(struct device *dev) pr_debug(gsc%d: state: 0x%lx, gsc-id, gsc-state); - ret = clk_enable(gsc-clock); + ret = clk_prepare_enable(gsc-clock); if (ret) return ret; @@ -1181,7 +1181,7 @@ static int gsc_runtime_suspend(struct device *dev) ret = gsc_m2m_suspend(gsc); if (!ret) - clk_disable(gsc-clock); + clk_disable_unprepare(gsc-clock); pr_debug(gsc%d: state: 0x%lx, gsc-id, gsc-state); return ret; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller
On Mon, Jan 19, 2015 at 10:17 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 19-01-15 15:10, Chen-Yu Tsai wrote: Hi, On Sat, Dec 20, 2014 at 6:20 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 19-12-14 19:17, Maxime Ripard wrote: Hi, On Thu, Dec 18, 2014 at 09:50:26AM +0100, Hans de Goede wrote: Hi, On 18-12-14 03:48, Chen-Yu Tsai wrote: Hi, On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote: On sun6i the cir block is attached to the reset controller, add support for de-asserting the reset if a reset controller is specified in dt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com --- .../devicetree/bindings/media/sunxi-ir.txt | 2 ++ drivers/media/rc/sunxi-cir.c | 25 -- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 23dd5ad..6b70b9b 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -10,6 +10,7 @@ Required properties: Optional properties: - linux,rc-map-name : Remote control map name. +- resets : phandle + reset specifier pair Should it be optional? Or should we use a sun6i compatible with a mandatory reset phandle? I mean, the driver/hardware is not going to work with the reset missing on sun6i. Seems we are doing it one way for some of our drivers, and the other (optional) way for more generic ones, like USB. I do not believe that we should add a new compatible just because the reset line of a block is hooked up differently. It is the exact same ip-block. Only now the reset is not controlled through the apb-gate, but controlled separately. He has a point though. Your driver might very well probe nicely and everything, but still wouldn't be functional at all because the reset line wouldn't have been specified in the DT. Right, just like other drivers we've, see e.g.: Documentation/devicetree/bindings/mmc/sunxi-mmc.txt Which is dealing with this in the same way. The easiest way to deal with that would be in the bindings doc to update it with a compatible for the A31, and mentionning that the reset property is mandatory there. No the easiest way to deal with this is to expect people writing the dts to know what they are doing, just like we do for a lot of the other blocks in sun6i. Maybe put a generic note somewhere that sun6i has a reset controller, and that for all the blocks with optional resets property it should be considered mandatory on sun6i ? I'm sorry but I'm not going to make this change for the ir bindings given that we've the same situation in a lot of other places. Consistency is important. Moreover I believe that having a sun6i specific compatible string is just wrong, since it is the exact same hardware block as on sun5i, just with its reset line routed differently, just like e.g. the mmc controller, the uarts or the gmac all of which also do not have a sun6i specific compatible to enforce reset controller usage. Regards, Hans Note that the code itself might not change at all though. I'd just like to avoid any potential breaking of the DT bindings themselves. If we further want to refine the code, we can do that however we want. I have a slight preference for a clean error if reset is missing, but I won't get in the way just for that. Seems this patch and the following patch were overlooked after the discussion. Any chance we could get this in? I'm a linux/media sub-maintainer, so I've already send a pull-req for these 2 to the linux/media maintainer, iow this is taken care of :) That's good to hear. I was going through the mainlining effort page, and couldn't find these 2 in linux-next. I'll mark them as planned for 3.20 then. Chen-Yu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
On 01/19/2015 03:11 PM, William Towle wrote: On Mon, 19 Jan 2015, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: Well, I thought that too. Will's submission from last week has that change: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009 Anyway, yes, that looks better! But I would still consider keeping buffers on the list in .buf_clean(), in which case you can remove it. And walk the list instead of the VB2 internal buffer array, as others have pointed out. Hi Guennadi, Thanks for the clarification. Ian (when he was with us) did say it was particularly difficult to understand WTH this driver was doing. Regarding your first point, if it's safe to skip the actions left in rcar_vin_videobuf_release() then I will do a further rework to remove it completely. Yes, that's safe. Just remove it altogether. The buf_init and buf_release ops are matching ops that are normally only used if you have to do per-buffer initialization and/or release. These are only called when the buffer memory changes. In most drivers including this one it's not needed at all. The same is true for rcar_vin_videobuf_init: it's pointless since the list initialization is done implicitly when you add the buffer to a list with list_add_tail(). Just drop the function. Regards, Hans Regarding your second, in the patchset Ben linked to above we think we have the appropriate loops: a for loop for queue_buf[], and list_for_each_safe() for anything left in priv-capture; this is consistent with rcar_vin_fill_hw_slot() setting up queue_buf[] with pointers unlinked from priv-capture. This in turn suggests that we are right not to call list_del_init() in both of rcar_vin_stop_streaming()'s loops ... as long as I've correctly interpreted the code and everyone's feedback thus far. Cheers, Wills. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] BLACKFIN MEDIA DRIVER: rewrite the blackfin style of read/write into common style
On 01/19/2015 04:13 AM, Hao Liang wrote:
Hi Hans,
Thank you for your reply.
This change comes largely from a non-blackfin architecture dsp processor of
ADI want to reuse this driver.
And i have tested common read/write function on blackfin board to ensure
usability and stability.
Well, looking at arch/blackfin/include/asm/def_LPBlackfin.h it seems that for
certain
blackfin variants the bfin_read/write functions insert an extra nop, so unless
you
test on one of those variants you wouldn't see any problems relating to this
change
(and possibly not even then if this is a rare race condition).
You will have to check this with the blackfin architecture maintainer, Steven
Miao
(added to the CC list). Without the OK of someone who actually understands that
architecture and the 'ANOMALY_05000198' issues I am not going to merge this.
If the bfin_read/write functions are really needed for the blackfin
architecture,
then you can always make ppi_read/write functions that check the architecture
and use
bfin_read/write if it is a blackfin and readw/writew otherwise.
That should be safe.
Regards,
Hans
BR
Hao
2015-01-16 19:34 GMT+08:00 Hans Verkuil hverk...@xs4all.nl
mailto:hverk...@xs4all.nl:
Hi Hao,
Why would you do this? read/writew() is AFAICT not the same as
bfin_read/write16
(defined in arch/blackfin/include/asm/def_LPBlackfin.h). And all other
blackfin
sources I've seen all use bfin_read/write.
So unless there is a good reason for this change I am not going to accept
this.
Regards,
Hans
On 01/14/2015 07:57 AM, Hao Liang wrote:
Signed-off-by: Hao Liang hliang1...@gmail.com
mailto:hliang1...@gmail.com
---
drivers/media/platform/blackfin/ppi.c | 72
-
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/blackfin/ppi.c
b/drivers/media/platform/blackfin/ppi.c
index cff63e5..de4b5c7 100644
--- a/drivers/media/platform/blackfin/ppi.c
+++ b/drivers/media/platform/blackfin/ppi.c
@@ -20,6 +20,7 @@
#include linux/module.h
#include linux/slab.h
#include linux/platform_device.h
+#include linux/io.h
#include asm/bfin_ppi.h
#include asm/blackfin.h
@@ -59,10 +60,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
/* register on bf561 is cleared when read
* others are W1C
*/
- status = bfin_read16(reg-status);
+ status = readw(reg-status);
if (status 0x3000)
ppi-err = true;
- bfin_write16(reg-status, 0xff00);
+ writew(0xff00, reg-status);
break;
}
case PPI_TYPE_EPPI:
@@ -70,10 +71,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
struct bfin_eppi_regs *reg = info-base;
unsigned short status;
- status = bfin_read16(reg-status);
+ status = readw(reg-status);
if (status 0x2)
ppi-err = true;
- bfin_write16(reg-status, 0x);
+ writew(0x, reg-status);
break;
}
case PPI_TYPE_EPPI3:
@@ -81,10 +82,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
struct bfin_eppi3_regs *reg = info-base;
unsigned long stat;
- stat = bfin_read32(reg-stat);
+ stat = readl(reg-stat);
if (stat 0x2)
ppi-err = true;
- bfin_write32(reg-stat, 0xc0ff);
+ writel(0xc0ff, reg-stat);
break;
}
default:
@@ -139,26 +140,25 @@ static int ppi_start(struct ppi_if *ppi)
case PPI_TYPE_PPI:
{
struct bfin_ppi_regs *reg = info-base;
- bfin_write16(reg-control, ppi-ppi_control);
+ writew(ppi-ppi_control, reg-control);
break;
}
case PPI_TYPE_EPPI:
{
struct bfin_eppi_regs *reg = info-base;
- bfin_write32(reg-control, ppi-ppi_control);
+ writel(ppi-ppi_control, reg-control);
break;
}
case PPI_TYPE_EPPI3:
{
struct bfin_eppi3_regs *reg = info-base;
- bfin_write32(reg-ctl, ppi-ppi_control);
+ writel(ppi-ppi_control, reg-ctl);
break;
}
default:
return -EINVAL;
}
- SSYNC();
return 0;
}
@@
[PATCH for v3.19] cx23885: fix free interrupt bug
First free the interrupt, then disable the PCI device. The other way around will lead to this warning: Jan 19 11:42:02 telek kernel: [ 1440.161234] WARNING: CPU: 0 PID: 2191 at kernel/irq/manage.c:1311 __free_irq+0x97/0x1f0() Jan 19 11:42:02 telek kernel: [ 1440.161236] Trying to free already-free IRQ 0 Jan 19 11:42:02 telek kernel: [ 1440.161237] Modules linked in: tda8290 tda10048 cx25840 cx23885(-) altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core v4l2_common videodev media nouveau x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci Jan 19 11:42:02 telek kernel: [ 1440.161266] CPU: 0 PID: 2191 Comm: rmmod Tainted: GW 3.19.0-rc1-telek #345 Jan 19 11:42:02 telek kernel: [ 1440.161268] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014 Jan 19 11:42:02 telek kernel: [ 1440.161270] 81bf1fce 8808958b7cc8 8194a97f Jan 19 11:42:02 telek kernel: [ 1440.161274] 8808958b7d18 8808958b7d08 810c56b0 0286 Jan 19 11:42:02 telek kernel: [ 1440.161279] 88089f808890 88089f808800 Jan 19 11:42:02 telek kernel: [ 1440.161284] Call Trace: Jan 19 11:42:02 telek kernel: [ 1440.161290] [8194a97f] dump_stack+0x4f/0x7b Jan 19 11:42:02 telek kernel: [ 1440.161295] [810c56b0] warn_slowpath_common+0x80/0xc0 Jan 19 11:42:02 telek kernel: [ 1440.161299] [810c5731] warn_slowpath_fmt+0x41/0x50 Jan 19 11:42:02 telek kernel: [ 1440.161303] [81955d36] ? _raw_spin_lock_irqsave+0x56/0x70 Jan 19 11:42:02 telek kernel: [ 1440.161307] [81114849] ? __free_irq+0x49/0x1f0 Jan 19 11:42:02 telek kernel: [ 1440.161311] [81114897] __free_irq+0x97/0x1f0 Jan 19 11:42:02 telek kernel: [ 1440.161316] [81114a88] free_irq+0x48/0xd0 Jan 19 11:42:02 telek kernel: [ 1440.161323] [a00e6deb] cx23885_finidev+0x4b/0x90 [cx23885] Jan 19 11:42:02 telek kernel: [ 1440.161329] [814529fa] pci_device_remove+0x3a/0xc0 Jan 19 11:42:02 telek kernel: [ 1440.161334] [8153b4ea] __device_release_driver+0x7a/0xf0 Jan 19 11:42:02 telek kernel: [ 1440.161338] [8153bc98] driver_detach+0xc8/0xd0 Jan 19 11:42:02 telek kernel: [ 1440.161341] [8153b1de] bus_remove_driver+0x4e/0xb0 Jan 19 11:42:02 telek kernel: [ 1440.161345] [8153c2eb] driver_unregister+0x2b/0x60 Jan 19 11:42:02 telek kernel: [ 1440.161349] [814525c5] pci_unregister_driver+0x25/0x70 Jan 19 11:42:02 telek kernel: [ 1440.161355] [a00f6ddc] cx23885_fini+0x10/0x12 [cx23885] Jan 19 11:42:02 telek kernel: [ 1440.161360] [81139a98] SyS_delete_module+0x1a8/0x1f0 Jan 19 11:42:02 telek kernel: [ 1440.161364] [819561a9] system_call_fastpath+0x12/0x17 Jan 19 11:42:02 telek kernel: [ 1440.161367] ---[ end trace a9c07cb5f3357020 ]--- Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/cx23885/cx23885-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/pci/cx23885/cx23885-core.c b/drivers/media/pci/cx23885/cx23885-core.c index 1d9d0f8..1ad4994 100644 --- a/drivers/media/pci/cx23885/cx23885-core.c +++ b/drivers/media/pci/cx23885/cx23885-core.c @@ -2049,11 +2049,11 @@ static void cx23885_finidev(struct pci_dev *pci_dev) cx23885_shutdown(dev); - pci_disable_device(pci_dev); - /* unregister stuff */ free_irq(pci_dev-irq, dev); + pci_disable_device(pci_dev); + cx23885_dev_unregister(dev); vb2_dma_sg_cleanup_ctx(dev-alloc_ctx); v4l2_ctrl_handler_free(dev-ctrl_handler); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: i2c: add new driver for single string flash.
On Mon, 2015-01-19 at 17:25 +0900, Daniel Jeong wrote:
This patch adds the driver for the single string flash products of TI.
Several single string flash controllers of TI have similar register map
and bit data. This driver supports four products,lm3556, lm3561, lm3642
and lm3648.
Why not to name it as lm3648 to be in align with other drivers?
Or even better solution (I suppose) to create a library and on top of
that one driver per each device?
Sakari, what do you think?
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ti-ss-flash.c | 744
+++
include/media/ti-ss-flash.h | 33 ++
4 files changed, 787 insertions(+)
create mode 100644 drivers/media/i2c/ti-ss-flash.c
create mode 100644 include/media/ti-ss-flash.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 205d713..886c1fb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -638,6 +638,15 @@ config VIDEO_LM3646
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_TI_SS_FLASH
+ tristate TI Single String Flash driver support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the signle string flash controllers of TI.
+ It supports LM3556, LM3561, LM3642 and LM3648.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..0e523ec 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
+obj-$(CONFIG_VIDEO_TI_SS_FLASH) += ti-ss-flash.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/ti-ss-flash.c b/drivers/media/i2c/ti-ss-flash.c
new file mode 100644
index 000..035aeba
--- /dev/null
+++ b/drivers/media/i2c/ti-ss-flash.c
@@ -0,0 +1,744 @@
+/*
+ * drivers/media/i2c/ti-ss-flash.c
+ * General device driver for Single String FLASH LED Drivers of TI
+ * It covers lm3556, lm3561, lm3642 and lm3648.
+ *
+ * Copyright (C) 2015 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * 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.
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/ti-ss-flash.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+/* operation mode */
+enum led_opmode {
+ OPMODE_SHDN = 0x0,
+ OPMODE_INDI_IR,
+ OPMODE_TORCH,
+ OPMODE_FLASH,
+};
+
+/*
+ * register data
+ * @reg : register
+ * @mask : mask bits
+ * @shift : bit shift of data
+ */
+struct ctrl_reg {
+ unsigned int reg;
+ unsigned int mask;
+ unsigned int shift;
+};
+
+/*
+ * unit data
+ * @min : min value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @step : step value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @knee: knee point of step of brightness/timeout
+ *brightness : uA
+ * timeout: ms
+ * @knee_step : step value of brightness or timeout after knee point
+ *brightness : uA
+ * timeout: ms
+ * @max : max value of brightness or timeout
+ *brightness : uA
+ * timeout: ms
+ * @ctrl : register info to control brightness or timeout
+ */
+struct ssflash_config {
+ unsigned int min;
+ unsigned int step;
+ unsigned int knee;
+ unsigned int knee_step;
+ unsigned int max;
+ struct ctrl_reg ctrl;
+};
+
+/*
+ * @reg : fault register
+ * @mask : fault mask bit
+ * @v4l2_fault : bit mapping to V4L2_FLASH_FAULT_
+ * refer to include//uapi/linux/v4l2-controls.h
+ */
+struct ssflash_fault {
+ unsigned int reg;
+ unsigned int mask;
+ unsigned int v4l2_fault;
+};
+
+#define NUM_V4L2_FAULT 9
+
+/*
+ * ssflash data
+ * @name: device name
+ * @mode: operation mode control data
+ * @flash_br: flash brightness register and bit data
+ * @timeout: timeout control data
+ * @strobe: strobe control data
+ * @torch_br: torch brightness register and bit data
+ *
Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
On Mon, 19 Jan 2015, Ben Hutchings wrote: On Sun, 2015-01-18 at 22:23 +0100, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and b) tracking of active-state buffers via priv-queue_buf[] is handled as early as is possible Huh... Sorry, patches 1, 2, 3, and 5 of this series look like a strange way to get from the present state to the destination. They all have to be merged IMHO. [...] Well, I thought that too. Will's submission from last week has that change: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009 Hm... interesting, why I didn't get those mails in my INBOX, although I do see myself in CC... Only got them from the list, and no, I don't have avoid copies enabled. Anyway, yes, that looks better! But I would still consider keeping buffers on the list in .buf_clean(), in which case you can remove it. And walk the list instead of the VB2 internal buffer array, as others have pointed out. Thanks Guennadi -- 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 for v3.19] pvrusb2: fix missing device_caps in querycap
The VIDIOC_QUERYCAP function should set device_caps, but this was missing.
In addition, it set the version field as well, but that should be done by
the core, not by the driver.
If a driver doesn't set device_caps the v4l2 core will issue a WARN_ON, so
it's important that this is set correctly.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index 422d79e..35e4ea5 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -89,16 +89,6 @@ static int vbi_nr[PVR_NUM] = {[0 ... PVR_NUM-1] = -1};
module_param_array(vbi_nr, int, NULL, 0444);
MODULE_PARM_DESC(vbi_nr, Offset for device's vbi dev minor);
-static struct v4l2_capability pvr_capability ={
- .driver = pvrusb2,
- .card = Hauppauge WinTV pvr-usb2,
- .bus_info = usb,
- .version= LINUX_VERSION_CODE,
- .capabilities = (V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_RADIO |
- V4L2_CAP_READWRITE),
-};
-
static struct v4l2_fmtdesc pvr_fmtdesc [] = {
{
.index = 0,
@@ -160,10 +150,22 @@ static int pvr2_querycap(struct file *file, void *priv,
struct v4l2_capability *
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
- memcpy(cap, pvr_capability, sizeof(struct v4l2_capability));
+ strlcpy(cap-driver, pvrusb2, sizeof(cap-driver));
strlcpy(cap-bus_info, pvr2_hdw_get_bus_info(hdw),
sizeof(cap-bus_info));
strlcpy(cap-card, pvr2_hdw_get_desc(hdw), sizeof(cap-card));
+ cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
+ V4L2_CAP_AUDIO | V4L2_CAP_RADIO |
+ V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS;
+ switch (fh-pdi-devbase.vfl_type) {
+ case VFL_TYPE_GRABBER:
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_AUDIO;
+ break;
+ case VFL_TYPE_RADIO:
+ cap-device_caps = V4L2_CAP_RADIO;
+ break;
+ }
+ cap-device_caps |= V4L2_CAP_TUNER | V4L2_CAP_READWRITE;
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hi Florian,
Sorry for the delay.
Several comments below...
On 01/07/2015 11:35 AM, Florian Echtler wrote:
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
As far as I can tell from looking through the usb core code it supports
scatter-gather DMA, so you should at least use dma-sg rather than dma-contig.
Physically contiguous memory should always be avoided.
I'm also missing a patch for the Kconfig that adds a dependency on
MEDIA_USB_SUPPORT
and that selects VIDEOBUF2_DMA_SG.
Signed-off-by: Florian Echtler f...@butterbrot.org
---
drivers/input/touchscreen/sur40.c | 423
--
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler f...@butterbrot.org
+ * Copyright (c) 2014 by Florian 'floe' Echtler f...@butterbrot.org
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty cha...@enac.fr
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include linux/input-polldev.h
#include linux/input/mt.h
#include linux/usb/input.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
/* read 512 bytes from endpoint 0x86 - get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 - get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* SUBF */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* epoch? always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT sur40
+#define DRIVER_LONGSamsung SUR40
#define DRIVER_AUTHOR Florian 'floe' Echtler f...@butterbrot.org
#define DRIVER_DESCSurface2.0/SUR40/PixelSense input driver
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used
USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct
Re: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
On Sun, 2015-01-18 at 22:23 +0100, Guennadi Liakhovetski wrote: On Thu, 18 Dec 2014, Ben Hutchings wrote: From: William Towle william.to...@codethink.co.uk Move the buffer state test in the .buf_cleanup handler into .stop_streaming so that a) the vb2_queue API is not subverted, and b) tracking of active-state buffers via priv-queue_buf[] is handled as early as is possible Huh... Sorry, patches 1, 2, 3, and 5 of this series look like a strange way to get from the present state to the destination. They all have to be merged IMHO. [...] Well, I thought that too. Will's submission from last week has that change: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009 Ben. -- 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
build failure on ubuntu 14.04.1 LTS
Hi I am seeing build failures since 11 January. A build I did on 22 December worked fine. My build procedure and the error are shown below. $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS $ uname -a Linux ubuntu 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:30:01 UTC 2014 i686 i686 i686 GNU/Linux $ make distclean $ rm v4l/.config $ git pull $ git log |head commit de98549b53c938b44f578833fe8440b92f4a8c64 Author: Hans Verkuil hans.verk...@cisco.com Date: Mon Jan 12 10:53:27 2015 +0100 Update v3.11_dev_groups.patch Signed-off-by: Hans Verkuil hans.verk...@cisco.com commit 3886d538f89948d49b652465e0d52e6e9a7329ab Author: Hans Verkuil hans.verk...@cisco.com $ ./build --main-git ... CC [M] /home/me/git/clones/media_build/v4l/smiapp-core.o /home/me/git/clones/media_build/v4l/smiapp-core.c: In function 'smiapp_get_pdata': /home/me/git/clones/media_build/v4l/smiapp-core.c:3061:3: error: implicit declaration of function 'of_read_number' [-Werror=implicit-function-declaration] pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2); ^ cc1: some warnings being treated as errors make[3]: *** [/home/me/git/clones/media_build/v4l/smiapp-core.o] Error 1 make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-37-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/me/git/clones/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 491, IN line 4. $ grep -ilr implicit-function-declaration . |grep -v o.cmd ./media/tools/thermal/tmon/Makefile ./media/arch/parisc/math-emu/Makefile ./media/Makefile It's not clear to me whether this a problem with the media_tree code or the media_build code. media/Makefile contains this definition KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ -std=gnu89 Regards Vince -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] media: au0828 change to not zero out fmt.pix.priv
On 01/12/2015 06:58 AM, Hans Verkuil wrote: My first code review of the new year, so let's start with a simple one to avoid taxing my brain cells (that are still in vacation mode) too much... On 12/18/2014 05:20 PM, Shuah Khan wrote: There is no need to zero out fmt.pix.priv in vidioc_g_fmt_vid_cap() vidioc_try_fmt_vid_cap(), and vidioc_s_fmt_vid_cap(). Remove it. Signed-off-by: Shuah Khan shua...@osg.samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com Happy New Year! Hans, Thanks. Just FYI, I dropped this patch from the patch v3 series since it has been Acked. Please note that that this version is what needs to be pulled in. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 FIXES FOR v3.19] Various fixes
Hi Mauro, This pull request fixes two cases of missing device_caps (3.19 warns about that now, so fix this before it's released), one cx23885 warning related to the incorrect freeing of an interrupt, and one important fix for vb2 thread race conditions. The last bug is responsible for various kernel warnings and oopses when using DVB and vb2. The last one is CC-ed to stable and should be applied to all kernels = 3.16. Regards, Hans The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA (2014-12-23 16:28:09 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19b for you to fetch changes up to b65558a8f31bcd585989a8259272f975d3236612: omap3isp: Correctly set QUERYCAP capabilities (2015-01-19 12:12:44 +0100) Hans Verkuil (3): vb2: fix vb2_thread_stop race conditions pvrusb2: fix missing device_caps in querycap cx23885: fix free interrupt bug Sakari Ailus (1): omap3isp: Correctly set QUERYCAP capabilities drivers/media/pci/cx23885/cx23885-core.c | 4 ++-- drivers/media/platform/omap3isp/ispvideo.c | 7 +-- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 24 +--- drivers/media/v4l2-core/videobuf2-core.c | 19 +-- 4 files changed, 29 insertions(+), 25 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 2/3] mn88472: make sure the private data struct is nulled after free
On 01/19/2015 02:15 PM, Hans Verkuil wrote: On 12/06/2014 09:26 PM, Benjamin Larsson wrote: Well I guess I am biased as I have spent lots of time finding a bug that probably wouldn't exist if the policy was that drivers always should set their memory to zero before it is free'd. Just because you zero memory before it is freed doesn't mean it stays zeroed. As soon as it is freed some other process might take that memory and fill it up again. So zeroing is pointless and in fact will only *hide* bugs. Well in this specific case NOT zeroing the memory it actually hid a use after free bug. So stating that it is pointless and that it will only hide bugs is not correct at least for this case. MvH Benjamin Larsson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media_build] commit 26052b8e1 (SMIAPP needs kernel 3.20 or up.)
Hi Hans, tested this update in media_build against a Debian 3.16 kernel. It still tries to build SMIAPP. So sadly it still gives the same error. Regards, Tycho. -- 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
