[PATCH v3 1/3] media: soc_camera: rcar_vin: Add scaling support
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
Signed-off-by: Yoshihiro Kaneko
---
v3 [Yoshihiro Kaneko]
* no changes
v2 [Yoshihiro Kaneko]
* fixes as suggested by Geert Uytterhoeven
- change the struct name to lower case
- use u32 instead of unsigned long
- etc.
drivers/media/platform/soc_camera/rcar_vin.c | 453 ++-
1 file changed, 444 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 0f46f34..dd6daab 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -64,6 +64,30 @@
#define VNDMR_REG 0x58/* Video n Data Mode Register */
#define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */
#define VNUVAOF_REG0x60/* Video n UV Address Offset Register */
+#define VNC1A_REG 0x80/* Video n Coefficient Set C1A Register */
+#define VNC1B_REG 0x84/* Video n Coefficient Set C1B Register */
+#define VNC1C_REG 0x88/* Video n Coefficient Set C1C Register */
+#define VNC2A_REG 0x90/* Video n Coefficient Set C2A Register */
+#define VNC2B_REG 0x94/* Video n Coefficient Set C2B Register */
+#define VNC2C_REG 0x98/* Video n Coefficient Set C2C Register */
+#define VNC3A_REG 0xA0/* Video n Coefficient Set C3A Register */
+#define VNC3B_REG 0xA4/* Video n Coefficient Set C3B Register */
+#define VNC3C_REG 0xA8/* Video n Coefficient Set C3C Register */
+#define VNC4A_REG 0xB0/* Video n Coefficient Set C4A Register */
+#define VNC4B_REG 0xB4/* Video n Coefficient Set C4B Register */
+#define VNC4C_REG 0xB8/* Video n Coefficient Set C4C Register */
+#define VNC5A_REG 0xC0/* Video n Coefficient Set C5A Register */
+#define VNC5B_REG 0xC4/* Video n Coefficient Set C5B Register */
+#define VNC5C_REG 0xC8/* Video n Coefficient Set C5C Register */
+#define VNC6A_REG 0xD0/* Video n Coefficient Set C6A Register */
+#define VNC6B_REG 0xD4/* Video n Coefficient Set C6B Register */
+#define VNC6C_REG 0xD8/* Video n Coefficient Set C6C Register */
+#define VNC7A_REG 0xE0/* Video n Coefficient Set C7A Register */
+#define VNC7B_REG 0xE4/* Video n Coefficient Set C7B Register */
+#define VNC7C_REG 0xE8/* Video n Coefficient Set C7C Register */
+#define VNC8A_REG 0xF0/* Video n Coefficient Set C8A Register */
+#define VNC8B_REG 0xF4/* Video n Coefficient Set C8B Register */
+#define VNC8C_REG 0xF8/* Video n Coefficient Set C8C Register */
/* Register bit fields for R-Car VIN */
/* Video n Main Control Register bits */
@@ -119,6 +143,324 @@ enum chip_id {
RCAR_E1,
};
+struct vin_coeff {
+ unsigned short xs_value;
+ u32 coeff_set[24];
+};
+
+static const struct vin_coeff vin_coeff_set[] = {
+ { 0x, {
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x,
+ 0x, 0x, 0x },
+ },
+ { 0x1000, {
+ 0x000fa400, 0x000fa400, 0x09625902,
+ 0x03f8, 0x0403, 0x3de0d9f0,
+ 0x001fffed, 0x0804, 0x3cc1f9c3,
+ 0x001003de, 0x0c01, 0x3cb34d7f,
+ 0x002003d2, 0x0c00, 0x3d24a92d,
+ 0x00200bca, 0x0bff, 0x3df600d2,
+ 0x002013cc, 0x07ff, 0x3ed70c7e,
+ 0x00100fde, 0x, 0x3f87c036 },
+ },
+ { 0x1200, {
+ 0x0021, 0x0021, 0x02a0a9c8,
+ 0x002003e7, 0x001a, 0x000185bc,
+ 0x002007dc, 0x03ff, 0x3e52859c,
+ 0x00200bd4, 0x0002, 0x3d53996b,
+ 0x00100fd0, 0x0403, 0x3d04ad2d,
+ 0x0bd5, 0x0403, 0x3d35ace7,
+ 0x3ff003e4, 0x0801, 0x3dc674a1,
+ 0x3fffe800, 0x0800, 0x3e76f461 },
+ },
+ { 0x1400, {
+ 0x00100be3, 0x00100be3, 0x04d1359a,
+ 0x0fdb
[PATCH v3 3/3] media: soc_camera: rcar_vin: Add NV16 horizontal scaling-up support
From: Koji Matsuoka
Up until now scaling has been forbidden for the NV16 capture format.
This patch adds support for horizontal scaling-up for NV16. Vertical
scaling-up for NV16 is forbidden by the H/W specification.
Signed-off-by: Koji Matsuoka
Signed-off-by: Yoshihiro Kaneko
---
v3 [Yoshihiro Kaneko]
* no changes
v2 [Yoshihiro Kaneko]
* Updated change log text from Simon Horman
* Code-style fixes as suggested by Sergei Shtylyov
drivers/media/platform/soc_camera/rcar_vin.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index ecdbd48..fd2207a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -644,7 +644,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
/* output format */
switch (icd->current_fmt->host_fmt->fourcc) {
case V4L2_PIX_FMT_NV16:
- iowrite32(ALIGN(ALIGN(cam->width, 0x20) * cam->height, 0x80),
+ iowrite32(ALIGN((cam->out_width * cam->out_height), 0x80),
priv->base + VNUVAOF_REG);
dmr = VNDMR_DTMD_YCSEP;
output_is_yuv = true;
@@ -1614,9 +1614,17 @@ static int rcar_vin_set_fmt(struct soc_camera_device
*icd,
* At the time of NV16 capture format, the user has to specify the
* width of the multiple of 32 for H/W specification.
*/
- if ((pixfmt == V4L2_PIX_FMT_NV16) && (pix->width & 0x1F)) {
- dev_err(icd->parent, "Specified width error in NV16 format.\n");
- return -EINVAL;
+ if (pixfmt == V4L2_PIX_FMT_NV16) {
+ if (pix->width & 0x1F) {
+ dev_err(icd->parent,
+ "Specified width error in NV16 format. Please
specify the multiple of 32.\n");
+ return -EINVAL;
+ }
+ if (pix->height != cam->height) {
+ dev_err(icd->parent,
+ "Vertical scaling-up error in NV16 format.
Please specify input height size.\n");
+ return -EINVAL;
+ }
}
switch (pix->field) {
@@ -1661,6 +1669,7 @@ static int rcar_vin_set_fmt(struct soc_camera_device *icd,
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555X:
+ case V4L2_PIX_FMT_NV16: /* horizontal scaling-up only is supported */
can_scale = true;
break;
default:
--
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 v3 0/3] media: soc_camera: rcar_vin: Add scaling support
This series is against master branch of linuxtv.org/media_tree.git. Koji Matsuoka (3): media: soc_camera: rcar_vin: Add scaling support media: soc_camera: rcar_vin: Add capture width check for NV16 format media: soc_camera: rcar_vin: Add NV16 horizontal scaling-up support drivers/media/platform/soc_camera/rcar_vin.c | 478 ++- 1 file changed, 468 insertions(+), 10 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 v3 2/3] media: soc_camera: rcar_vin: Add capture width check for NV16 format
From: Koji Matsuoka
At the time of NV16 capture format, the user has to specify the
capture output width of the multiple of 32 for H/W specification.
At the time of using NV16 format by ioctl of VIDIOC_S_FMT,
this patch adds align check and the error handling to forbid
specification of the capture output width which is not a multiple of 32.
Signed-off-by: Koji Matsuoka
Signed-off-by: Yoshihiro Kaneko
---
v3 [Yoshihiro Kaneko]
* fixes some code-style and remove useless error flag as suggested by
Sergei Shtylyov
v2 [Yoshihiro Kaneko]
* use u32 instead of unsigned long
drivers/media/platform/soc_camera/rcar_vin.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index dd6daab..ecdbd48 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -644,7 +644,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
/* output format */
switch (icd->current_fmt->host_fmt->fourcc) {
case V4L2_PIX_FMT_NV16:
- iowrite32(ALIGN(cam->width * cam->height, 0x80),
+ iowrite32(ALIGN(ALIGN(cam->width, 0x20) * cam->height, 0x80),
priv->base + VNUVAOF_REG);
dmr = VNDMR_DTMD_YCSEP;
output_is_yuv = true;
@@ -1086,6 +1086,7 @@ static int rcar_vin_set_rect(struct soc_camera_device
*icd)
unsigned char dsize = 0;
struct v4l2_rect *cam_subrect = &cam->subrect;
u32 value;
+ u32 vnis;
dev_dbg(icd->parent, "Crop %ux%u@%u:%u\n",
icd->user_width, icd->user_height, cam->vin_left, cam->vin_top);
@@ -1163,7 +1164,11 @@ static int rcar_vin_set_rect(struct soc_camera_device
*icd)
break;
}
- iowrite32(ALIGN(cam->out_width, 0x10), priv->base + VNIS_REG);
+ if (icd->current_fmt->host_fmt->fourcc == V4L2_PIX_FMT_NV16)
+ vnis = ALIGN(cam->out_width, 0x20);
+ else
+ vnis = ALIGN(cam->out_width, 0x10);
+ iowrite32(vnis, priv->base + VNIS_REG);
return 0;
}
@@ -1605,6 +1610,15 @@ static int rcar_vin_set_fmt(struct soc_camera_device
*icd,
dev_dbg(dev, "S_FMT(pix=0x%x, %ux%u)\n",
pixfmt, pix->width, pix->height);
+ /*
+* At the time of NV16 capture format, the user has to specify the
+* width of the multiple of 32 for H/W specification.
+*/
+ if ((pixfmt == V4L2_PIX_FMT_NV16) && (pix->width & 0x1F)) {
+ dev_err(icd->parent, "Specified width error in NV16 format.\n");
+ return -EINVAL;
+ }
+
switch (pix->field) {
default:
pix->field = V4L2_FIELD_NONE;
--
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] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
Signed-off-by: Yoshihiro Kaneko
---
This patch is against master branch of linuxtv.org/media_tree.git.
v2 [Yoshihiro Kaneko]
* remove unused/useless definition as suggested by Sergei Shtylyov
drivers/media/platform/soc_camera/rcar_vin.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20defcb..cb5e682 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -74,6 +74,7 @@
#define VNMC_INF_YUV10_BT656 (2 << 16)
#define VNMC_INF_YUV10_BT601 (3 << 16)
#define VNMC_INF_YUV16 (5 << 16)
+#define VNMC_INF_RGB888(6 << 16)
#define VNMC_VUP (1 << 10)
#define VNMC_IM_ODD(0 << 3)
#define VNMC_IM_ODD_EVEN (1 << 3)
@@ -272,6 +273,10 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
/* input interface */
switch (icd->current_fmt->code) {
+ case V4L2_MBUS_FMT_RGB888_1X24:
+ /* BT.601/BT.709 24-bit RGB-888 */
+ vnmc |= VNMC_INF_RGB888;
+ break;
case V4L2_MBUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
if (output_is_yuv)
vnmc |= VNMC_BPS;
+ if (vnmc & VNMC_INF_RGB888)
+ vnmc ^= VNMC_BPS;
+
/* progressive or interlaced mode */
interrupts = progressive ? VNIE_FIE | VNIE_EFE : VNIE_EFE;
@@ -1013,6 +1021,7 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
case V4L2_MBUS_FMT_YUYV8_1X16:
case V4L2_MBUS_FMT_YUYV8_2X8:
case V4L2_MBUS_FMT_YUYV10_2X10:
+ case V4L2_MBUS_FMT_RGB888_1X24:
if (cam->extra_fmt)
break;
--
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] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode
Hello Sergei, Thank you for your comments. 2014-10-19 0:01 GMT+09:00 Sergei Shtylyov : > Hello. > > On 10/14/2014 10:25 AM, Yoshihiro Kaneko wrote: > >> From: Koji Matsuoka > > >> By applying this patch, it sets to VSYNC field toggle mode not only >> at the time of progressive mode but at the time of an interlace mode. > > >> Signed-off-by: Koji Matsuoka >> Signed-off-by: Yoshihiro Kaneko >> --- > > >> This patch is against master branch of linuxtv.org/media_tree.git. > > >> drivers/media/platform/soc_camera/rcar_vin.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > >> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c >> b/drivers/media/platform/soc_camera/rcar_vin.c >> index 5196c81..bf97ed6 100644 >> --- a/drivers/media/platform/soc_camera/rcar_vin.c >> +++ b/drivers/media/platform/soc_camera/rcar_vin.c >> @@ -108,6 +108,7 @@ >> #define VNDMR2_VPS(1 << 30) >> #define VNDMR2_HPS(1 << 29) >> #define VNDMR2_FTEV (1 << 17) >> +#define VNDMR2_VLV_1 (1 << 12) > > >Please instead do: > > #define VNDMR2_VLV(n) ((n & 0xf) << 12) It's unclear to me why the style of the new #define should differ from those of the existing ones. Thanks, Kaneko > > WBR, Sergei > -- 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: WARNINGS
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 Oct 21 04:00:32 CEST 2014 git branch: test git hash: cf3167cf1e969b17671a4d3d956d22718a8ceb85 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.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: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS 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
Re: [PATCH/RFC v6 2/3] leds: add API for setting torch brightness
On Mon, Sep 22, 2014 at 8:21 AM, Jacek Anaszewski
wrote:
> This patch prepares ground for addition of LED Flash Class extension to
> the LED subsystem. Since turning the torch on must have guaranteed
> immediate effect the brightness_set op can't be used for it. Drivers must
> schedule a work queue task in this op to be compatible with led-triggers,
> which call brightess_set from timer irqs. In order to address this
> limitation a torch_brightness_set op and led_set_torch_brightness API
> is introduced. Setting brightness sysfs attribute will result in calling
> brightness_set op for LED Class devices and torch_brightness_set op for
> LED Flash Class devices, whereas triggers will still call brightness
> op in both cases.
>
Although this torch API is for torch, but I think we can make it more
generic and other use case can benefit from this change.
What about this?
Add 2 flags:
1. SET_BRIGHTNESS_ASYNC
2. SET_BRIGHTNESS_SYNC
Then move old API to
__led_set_brightness(led_cdev, state);
led_set_brightness_async();
And add a new API like
led_set_bightness_sync();
Then for torch use case, we use led_set_brightness_sync() API.
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> drivers/leds/led-class.c |9 +++--
> drivers/leds/led-core.c | 14 ++
> include/linux/leds.h | 21 +
> 3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index a39ca8f..5a11a07 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -54,9 +54,14 @@ static ssize_t brightness_store(struct device *dev,
>
> if (state == LED_OFF)
> led_trigger_remove(led_cdev);
> - __led_set_brightness(led_cdev, state);
>
> - ret = size;
> + if (led_cdev->flags & LED_DEV_CAP_TORCH)
> + ret = led_set_torch_brightness(led_cdev, state);
> + else
> + __led_set_brightness(led_cdev, state);
> +
> + if (!ret)
> + ret = size;
> unlock:
> mutex_unlock(&led_cdev->led_access);
> return ret;
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index cca86ab..c6d8288 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -143,6 +143,20 @@ int led_update_brightness(struct led_classdev *led_cdev)
> }
> EXPORT_SYMBOL(led_update_brightness);
>
> +int led_set_torch_brightness(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + int ret = 0;
> +
> + led_cdev->brightness = min(brightness, led_cdev->max_brightness);
> +
> + if (!(led_cdev->flags & LED_SUSPENDED))
> + ret = led_cdev->torch_brightness_set(led_cdev,
> +led_cdev->brightness);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(led_set_torch_brightness);
> +
> /* Caller must ensure led_cdev->led_access held */
> void led_sysfs_disable(struct led_classdev *led_cdev)
> {
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 44c8a98..bc2a570 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -44,11 +44,21 @@ struct led_classdev {
> #define LED_BLINK_ONESHOT_STOP (1 << 18)
> #define LED_BLINK_INVERT (1 << 19)
> #define LED_SYSFS_DISABLE (1 << 20)
> +#define LED_DEV_CAP_TORCH (1 << 21)
>
> /* Set LED brightness level */
> /* Must not sleep, use a workqueue if needed */
> void(*brightness_set)(struct led_classdev *led_cdev,
> enum led_brightness brightness);
> + /*
> +* Set LED brightness immediately - it is required for flash led
> +* devices as they require setting torch brightness to have immediate
> +* effect. brightness_set op cannot be used for this purpose because
> +* the led drivers schedule a work queue task in it to allow for
> +* being called from led-triggers, i.e. from the timer irq context.
> +*/
> + int (*torch_brightness_set)(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> /* Get LED brightness level */
> enum led_brightness (*brightness_get)(struct led_classdev *led_cdev);
>
> @@ -157,6 +167,17 @@ extern void led_set_brightness(struct led_classdev
> *led_cdev,
> extern int led_update_brightness(struct led_classdev *led_cdev);
>
> /**
> + * led_set_torch_brightness - set torch LED brightness
> + * @led_cdev: the LED to set
> + * @brightness: the brightness to set it to
> + *
> + * Returns: 0 on success or negative error value on failure
> + *
> + * Set a torch LED's brightness.
> + */
> +extern int led_set_torch_brightness(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> +/**
> * led
Re: [PATCH/RFC v6 1/3] leds: implement sysfs interface locking mechanism
On Mon, Sep 22, 2014 at 8:21 AM, Jacek Anaszewski
wrote:
> Add a mechanism for locking LED subsystem sysfs interface.
> This patch prepares ground for addition of LED Flash Class
> extension, whose API will be integrated with V4L2 Flash API.
> Such a fusion enforces introducing a locking scheme, which
> will secure consistent access to the LED Flash Class device.
>
> The mechanism being introduced allows for disabling LED
> subsystem sysfs interface by calling led_sysfs_disable function
> and enabling it by calling led_sysfs_enable. The functions
> alter the LED_SYSFS_DISABLE flag state and must be called
> under mutex lock. The state of the lock is checked with use
> of led_sysfs_is_disabled function. Such a design allows for
> providing immediate feedback to the user space on whether
> the LED Flash Class device is available or is under V4L2 Flash
> sub-device control.
>
I'm good with this and will merge it soon.
Thanks,
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> drivers/leds/led-class.c| 19 ---
> drivers/leds/led-core.c | 18 ++
> drivers/leds/led-triggers.c | 16 +---
> include/linux/leds.h| 32
> 4 files changed, 79 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 2e124aa2..a39ca8f 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -39,17 +39,27 @@ static ssize_t brightness_store(struct device *dev,
> {
> struct led_classdev *led_cdev = dev_get_drvdata(dev);
> unsigned long state;
> - ssize_t ret = -EINVAL;
> + ssize_t ret;
> +
> + mutex_lock(&led_cdev->led_access);
> +
> + if (led_sysfs_is_disabled(led_cdev)) {
> + ret = -EBUSY;
> + goto unlock;
> + }
>
> ret = kstrtoul(buf, 10, &state);
> if (ret)
> - return ret;
> + goto unlock;
>
> if (state == LED_OFF)
> led_trigger_remove(led_cdev);
> __led_set_brightness(led_cdev, state);
>
> - return size;
> + ret = size;
> +unlock:
> + mutex_unlock(&led_cdev->led_access);
> + return ret;
> }
> static DEVICE_ATTR_RW(brightness);
>
> @@ -213,6 +223,7 @@ int led_classdev_register(struct device *parent, struct
> led_classdev *led_cdev)
> #ifdef CONFIG_LEDS_TRIGGERS
> init_rwsem(&led_cdev->trigger_lock);
> #endif
> + mutex_init(&led_cdev->led_access);
> /* add to the list of leds */
> down_write(&leds_list_lock);
> list_add_tail(&led_cdev->node, &leds_list);
> @@ -266,6 +277,8 @@ void led_classdev_unregister(struct led_classdev
> *led_cdev)
> down_write(&leds_list_lock);
> list_del(&led_cdev->node);
> up_write(&leds_list_lock);
> +
> + mutex_destroy(&led_cdev->led_access);
> }
> EXPORT_SYMBOL_GPL(led_classdev_unregister);
>
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index 0d15aa9..cca86ab 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -142,3 +142,21 @@ int led_update_brightness(struct led_classdev *led_cdev)
> return ret;
> }
> EXPORT_SYMBOL(led_update_brightness);
> +
> +/* Caller must ensure led_cdev->led_access held */
> +void led_sysfs_disable(struct led_classdev *led_cdev)
> +{
> + lockdep_assert_held(&led_cdev->led_access);
> +
> + led_cdev->flags |= LED_SYSFS_DISABLE;
> +}
> +EXPORT_SYMBOL_GPL(led_sysfs_disable);
> +
> +/* Caller must ensure led_cdev->led_access held */
> +void led_sysfs_enable(struct led_classdev *led_cdev)
> +{
> + lockdep_assert_held(&led_cdev->led_access);
> +
> + led_cdev->flags &= ~LED_SYSFS_DISABLE;
> +}
> +EXPORT_SYMBOL_GPL(led_sysfs_enable);
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index c3734f1..e8b1120 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -37,6 +37,14 @@ ssize_t led_trigger_store(struct device *dev, struct
> device_attribute *attr,
> char trigger_name[TRIG_NAME_MAX];
> struct led_trigger *trig;
> size_t len;
> + int ret = count;
> +
> + mutex_lock(&led_cdev->led_access);
> +
> + if (led_sysfs_is_disabled(led_cdev)) {
> + ret = -EBUSY;
> + goto unlock;
> + }
>
> trigger_name[sizeof(trigger_name) - 1] = '\0';
> strncpy(trigger_name, buf, sizeof(trigger_name) - 1);
> @@ -47,7 +55,7 @@ ssize_t led_trigger_store(struct device *dev, struct
> device_attribute *attr,
>
> if (!strcmp(trigger_name, "none")) {
> led_trigger_remove(led_cdev);
> - return count;
> + goto unlock;
> }
>
> down_read(&triggers_list_lock);
> @@ -58,12 +66,14 @@ ssize_t led_trigger_store(struct device *dev, struct
> device_attribute *at
Re: randconfig build error with next-20141020, in drivers/media/platform/marvell-ccic/mcam-core.c
Hi, after a lot of staring at the configuration it seems like this boils down to an issue within the Kconfig constraint description. Broken down to the important bits: - CONFIG_VIDEO_TW68 and CONFIG_VIDEO_SAA7134 *select* CONFIG_VIDEOBUF2_DMA_SG - Both of these options are set to "*m*" in the configuration provided, which means that CONFIG_VIDEOBUF2_DMA_SG will also be selected as "m". According to Documentation/kbuild/kconfig-language.txt, line 101, "m" is set as the minimal value for CONFIG_VIDEOBUF2_DMA_SG by the selects, and as no other options select it as "y", it stays "m". - CONFIG_VIDEO_CAFE_CCIC is set to "*y*". The header file at drivers/media/platform/marvell-ccic/mcam-core.h then sets an internal preprocessor variable in line 28: #if IS_ENABLED(CONFIG_VIDEOBUF2_DMA_SG) #define MCAM_MODE_DMA_SG 1 #endif The source code right around line 1299 in drivers/media/platform/marvell-ccic/mcam-core.c, where the undefined reference occurs, depends on MCAM_MODE_DMA_SG. This means that CONFIG_VIDEOBUF2_DMA_SG is compiled as an LKM, thus the reference for vb2_dma_sg_memops from mcam-core.c (which is statically compiled) can not be resolved in the builtin.o files and vmlinux. Unfortunately, I haven't got a solution on how to resolve that, but maybe this summary helps someone else to come up with one. Best regards, Andreas On 20.10.2014 19:52, Jim Davis wrote: > Building with the attached random configuration file, > > drivers/built-in.o: In function `mcam_setup_vb2': > /home/jim/linux/drivers/media/platform/marvell-ccic/mcam-core.c:1299: > undefined > reference to `vb2_dma_sg_memops' > make: *** [vmlinux] Error 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] [media] anysee: make sure loading modules is const
Make sure that loaded modules are const char strings so we don't
load arbitrary modules in the future, nor allow for format string
leaks in the module request call.
Signed-off-by: Kees Cook
---
drivers/media/usb/dvb-usb-v2/anysee.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c
b/drivers/media/usb/dvb-usb-v2/anysee.c
index d3c5f230e97a..ae917c042a52 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -630,8 +630,8 @@ error:
return ret;
}
-static int anysee_add_i2c_dev(struct dvb_usb_device *d, char *type, u8 addr,
- void *platform_data)
+static int anysee_add_i2c_dev(struct dvb_usb_device *d, const char *type,
+ u8 addr, void *platform_data)
{
int ret, num;
struct anysee_state *state = d_to_priv(d);
@@ -659,7 +659,7 @@ static int anysee_add_i2c_dev(struct dvb_usb_device *d,
char *type, u8 addr,
goto err;
}
- request_module(board_info.type);
+ request_module("%s", board_info.type);
/* register I2C device */
client = i2c_new_device(adapter, &board_info);
--
1.9.1
--
Kees Cook
Chrome OS Security
--
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] af9035: make sure loading modules is const
Make sure that loaded modules are const char strings so we don't
load arbitrary modules in the future, nor allow for format string
leaks in the module request call.
Signed-off-by: Kees Cook
---
drivers/media/usb/dvb-usb-v2/af9035.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 00758c83eec7..1896ab218b11 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -193,8 +193,8 @@ static int af9035_wr_reg_mask(struct dvb_usb_device *d, u32
reg, u8 val,
return af9035_wr_regs(d, reg, &val, 1);
}
-static int af9035_add_i2c_dev(struct dvb_usb_device *d, char *type, u8 addr,
- void *platform_data, struct i2c_adapter *adapter)
+static int af9035_add_i2c_dev(struct dvb_usb_device *d, const char *type,
+ u8 addr, void *platform_data, struct i2c_adapter *adapter)
{
int ret, num;
struct state *state = d_to_priv(d);
@@ -221,7 +221,7 @@ static int af9035_add_i2c_dev(struct dvb_usb_device *d,
char *type, u8 addr,
goto err;
}
- request_module(board_info.type);
+ request_module("%s", board_info.type);
/* register I2C device */
client = i2c_new_device(adapter, &board_info);
--
1.9.1
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/4] Add a media device configuration file parser.
Hi Jacek,
On Fri, Oct 17, 2014 at 04:54:39PM +0200, Jacek Anaszewski wrote:
> This patch adds a parser for a media device configuration
> file. The parser expects the configuration file containing
> links end v4l2-controls definitions as described in the
> header file being added. The links describe connections
> between media entities and v4l2-controls define the target
> sub-devices for particular user controls related ioctl calls.
>
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Mauro Carvalho Chehab
> Cc: Hans Verkuil
> ---
> lib/include/libv4l2-media-conf-parser.h | 148 +++
> lib/libv4l2/libv4l2-media-conf-parser.c | 441
> +++
> 2 files changed, 589 insertions(+)
> create mode 100644 lib/include/libv4l2-media-conf-parser.h
> create mode 100644 lib/libv4l2/libv4l2-media-conf-parser.c
>
> diff --git a/lib/include/libv4l2-media-conf-parser.h
> b/lib/include/libv4l2-media-conf-parser.h
> new file mode 100644
> index 000..b2dba3a
> --- /dev/null
> +++ b/lib/include/libv4l2-media-conf-parser.h
> @@ -0,0 +1,148 @@
> +/*
> + * Parser of media device configuration file.
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Author: Jacek Anaszewski
> + *
> + * The configuration file has to comply with following format:
> + *
> + * Link description entry format:
> + *
> + * link {
> + * source_entity:
> + * source_pad:
> + * sink_entity:
> + * sink_pad:
> + * }
Could you use the existing libmediactl format? The parser exists as well.
As a matter of fact, I have a few patches to make it easier to user in a
library.
libmediactl appears to be located under utils/media-ctl. Perhaps it's be
better placed under lib. Cc Laurent.
> + * The V4L2 control group format:
> + *
> + * v4l2-controls {
> + * :
> + * :
> + * ...
> + * :
> + * }
I didn't know you were working on this.
I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?
What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB new get info ioctl
Hi Michael, As you know, one of the topics discussed during the last Media Summit were about writing a new ioctl to replace FE_GET_INFO's fe_caps. The summary of our discussions follow bellow: (mental note: I should put the description below on our mini-summit notes): The main issue with fe_caps is that, currently, there are only two bits left, between: FE_HAS_EXTENDED_CAPS= 0x80, and FE_CAN_MULTISTREAM = 0x400, And this is not enough to represent the current capabilities of modern delivery system's frontends. As a few examples of missing things that we want to be able to report, we have: - Some DVB-C2 demods supports automatic symbol rate detection between a certain range (Ralph); - Some devices that only work on "auto" mode, sometimes being even unable to return what it was detected, even with the full specs (Ralph). - Complex delivery systems like ISDB-T have some combinations that aren't very common, and some chipset providers decided to not implement (Mauro). For example, mb86a20s frontend doesn't support guard interval equal to 1/32[1]. So, the agreeded strategy is to write a new ioctl that, once the delivery system is set, it will return what are the valid values/ranges that a given frontend property can support. In order to optimize the drivers, the core could pre-fill it with all that it is supported by a given delivery system, letting the driver to override it, disabling the features that aren't supported. Michael proposed to send RFCs for that. [1] Also, while double checking today at the code, it also doesn't support mode 1 (2K). That's what it was agreed during the meeting. After our discussions about a new ioctl that would be able to properly report the frontend capabilities for new standards, during the Media Summit, in order to be able to report the currently needs, I did some brainstorming about that. It come to me that the fe_caps replacement ioctl should need to return not only the valid values/ranges but also a flag that will indicate if: - The frontend supports auto-detecting the parameter (CAN_AUTO); - The frontend allows setting such parameter (CAN_SET) [2]; - The frontend can report the detected parameter (CAN_GET); - If the valid values comes on ranges (IS_RANGE), to be used by parameters like frequency and symbol rate. Btw, we have a problem with IS_RANGE for symbol rate: There are actually two ranges there: - The supported symbol rate range; - The auto-detected symbol rate range. Perhaps Ralph could shed us a light on it, but my understanding is that some devices might have a broader supported range than the one that the frontend can auto-detect. If so, the solution could be to add an extra property for the "autodetection symbol rate" range. [2] ISDB-S new Toshiba demod, for example, doesn't allow setting the modulation. This should always be auto-detected via TMCC table. Btw, this seems to be a requirement at the spec (but nothing prevents some vendor to not implement it). We've discussed in priv that we might report everything as ranges, but, on a second taught, I think that we should only use ranges for numeric values, and not for enums. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
randconfig build error with next-20141020, in drivers/media/platform/marvell-ccic/mcam-core.c
Building with the attached random configuration file, drivers/built-in.o: In function `mcam_setup_vb2': /home/jim/linux/drivers/media/platform/marvell-ccic/mcam-core.c:1299: undefined reference to `vb2_dma_sg_memops' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y # CONFIG_RD_XZ is not set CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_LTO_MENU is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y CONFIG_UID16=y # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_ADVISE_SYSCALLS=y # CONFIG_PCI_QUIRKS is not set CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y CONFIG_JUMP_LABEL=y CONFIG_OPTPROBES=y
[PATCH] [media] v4l: DocBook: fix media build error
Fix media DocBook build errors by re-adding the orderedlist tag and putting back the section tags lost during merge. Signed-off-by: Vincent Palatin --- Documentation/DocBook/media/v4l/compat.xml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 07ffc76..0a2debf 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2566,6 +2566,10 @@ fields changed from _s32 to _u32. Added compound control types and &VIDIOC-QUERY-EXT-CTRL;. + + + + V4L2 in Linux 3.18 -- 2.1.0.rc2.206.gedb03e5 -- 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] DocBook: fix media build error
On Mon, Oct 20, 2014 at 10:08 AM, Randy Dunlap wrote: > On 10/20/14 09:06, Vincent Palatin wrote: >> On Sun, Oct 19, 2014 at 7:39 PM, Randy Dunlap wrote: >>> From: Randy Dunlap >>> >>> Fix media DocBook build errors by making the orderedlist balanced. >>> >>> DOC1/Documentation/DocBook/compat.xml:2576: parser error : Opening and >>> ending tag mismatch: orderedlist line 2560 and section >>> DOC1/Documentation/DocBook/compat.xml:2726: parser error : Premature end of >>> data in tag section line 884 >>> DOC1/Documentation/DocBook/compat.xml:2726: parser error : chunk is not >>> well balanced >>> >>> Signed-off-by: Randy Dunlap >>> Cc: Vincent Palatin >>> --- >>> Documentation/DocBook/media/v4l/compat.xml |1 + >>> 1 file changed, 1 insertion(+) >>> >>> --- lnx-318-rc1.orig/Documentation/DocBook/media/v4l/compat.xml >>> +++ lnx-318-rc1/Documentation/DocBook/media/v4l/compat.xml >>> @@ -2566,6 +2566,7 @@ fields changed from _s32 to _u32. >>> Added compound control types and &VIDIOC-QUERY-EXT-CTRL;. >>> >>> >>> + >>>V4L2 in Linux 3.18 >>> >>> >> >> Compared to the original patch, it's actually also missing the >> >> >> >> which were lost in the merge. >> >> > > Would you please send a complete fix for it? > then Mauro can drop my patch. Sure, I will send it in 5 minutes, the docs are currently rebuilding with the patch ... -- Vincent -- 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] DocBook: fix media build error
On 10/20/14 09:06, Vincent Palatin wrote: > On Sun, Oct 19, 2014 at 7:39 PM, Randy Dunlap wrote: >> From: Randy Dunlap >> >> Fix media DocBook build errors by making the orderedlist balanced. >> >> DOC1/Documentation/DocBook/compat.xml:2576: parser error : Opening and >> ending tag mismatch: orderedlist line 2560 and section >> DOC1/Documentation/DocBook/compat.xml:2726: parser error : Premature end of >> data in tag section line 884 >> DOC1/Documentation/DocBook/compat.xml:2726: parser error : chunk is not well >> balanced >> >> Signed-off-by: Randy Dunlap >> Cc: Vincent Palatin >> --- >> Documentation/DocBook/media/v4l/compat.xml |1 + >> 1 file changed, 1 insertion(+) >> >> --- lnx-318-rc1.orig/Documentation/DocBook/media/v4l/compat.xml >> +++ lnx-318-rc1/Documentation/DocBook/media/v4l/compat.xml >> @@ -2566,6 +2566,7 @@ fields changed from _s32 to _u32. >> Added compound control types and &VIDIOC-QUERY-EXT-CTRL;. >> >> >> + >>V4L2 in Linux 3.18 >> >> > > Compared to the original patch, it's actually also missing the > > > > which were lost in the merge. > > Would you please send a complete fix for it? then Mauro can drop my patch. Thanks. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc_camera: rcar_vin: Add DT support for r8a7793 and r8a7794 SoCs
On Mon, Oct 20, 2014 at 11:51:29AM +0900, Yoshihiro Kaneko wrote:
> Based on platform device work by Matsuoka-san.
>
> Signed-off-by: Yoshihiro Kaneko
Acked-by: Simon Horman
> ---
>
> Compile tested only.
>
> This patch is against master branch of linuxtv.org/media_tree.git.
>
> Documentation/devicetree/bindings/media/rcar_vin.txt | 2 ++
> drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index ba61782..9dafe6b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and
> suppot one input
> channel which can be either RGB, YUYV or BT656.
>
> - compatible: Must be one of the following
> + - "renesas,vin-r8a7794" for the R8A7794 device
> + - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7791" for the R8A7791 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> b/drivers/media/platform/soc_camera/rcar_vin.c
> index 234cf86..c023aab 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -1871,6 +1871,8 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
>
> #ifdef CONFIG_OF
> static struct of_device_id rcar_vin_of_table[] = {
> + { .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
> + { .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
> { .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
> { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
> { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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] DocBook: fix media build error
On Sun, Oct 19, 2014 at 7:39 PM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix media DocBook build errors by making the orderedlist balanced. > > DOC1/Documentation/DocBook/compat.xml:2576: parser error : Opening and ending > tag mismatch: orderedlist line 2560 and section > DOC1/Documentation/DocBook/compat.xml:2726: parser error : Premature end of > data in tag section line 884 > DOC1/Documentation/DocBook/compat.xml:2726: parser error : chunk is not well > balanced > > Signed-off-by: Randy Dunlap > Cc: Vincent Palatin > --- > Documentation/DocBook/media/v4l/compat.xml |1 + > 1 file changed, 1 insertion(+) > > --- lnx-318-rc1.orig/Documentation/DocBook/media/v4l/compat.xml > +++ lnx-318-rc1/Documentation/DocBook/media/v4l/compat.xml > @@ -2566,6 +2566,7 @@ fields changed from _s32 to _u32. > Added compound control types and &VIDIOC-QUERY-EXT-CTRL;. > > > + >V4L2 in Linux 3.18 > > Compared to the original patch, it's actually also missing the which were lost in the merge. -- Vincent -- 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] DocBook: fix media build error
On Sun, 19 Oct 2014 19:39:17 -0700 Randy Dunlap wrote: > Fix media DocBook build errors by making the orderedlist balanced. That definitely makes things work better. Will send upward if need be. Thanks, jon -- 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/2] [media] rc-core: change enabled_protocol default setting
On 2014-10-19 12:21, Tomas Melin wrote: Change default setting for enabled protocols. Instead of enabling all protocols, disable all except lirc during registration. Reduces overhead since all protocols not handled by default. Protocol to use will be enabled when keycode table is written by userspace. I can see the appeal in this, but now you've disabled automatic decoding for the protocol specified by the keymap for raw drivers? So this would also be a change, right? I agree with Mauro that the "proper" long-term fix would be to teach the LIRC userspace daemon to enable the lirc protocol as/when necessary, but something similar to the patch below (but lirc + keymap protocol...if that's possible to implement in a non-intrusive manner, I haven't checked TBH) might be a good idea as an interim measure? Signed-off-by: Tomas Melin --- drivers/media/rc/rc-ir-raw.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c index a118539..63d23d0 100644 --- a/drivers/media/rc/rc-ir-raw.c +++ b/drivers/media/rc/rc-ir-raw.c @@ -256,7 +256,8 @@ int ir_raw_event_register(struct rc_dev *dev) return -ENOMEM; dev->raw->dev = dev; - dev->enabled_protocols = ~0; + /* by default, disable all but lirc*/ + dev->enabled_protocols = RC_BIT_LIRC; rc = kfifo_alloc(&dev->raw->kfifo, sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE, GFP_KERNEL); -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register
On 2014-10-19 12:21, Tomas Melin wrote:
IR reciever using nuvoton-cir and lirc was not working anymore after
upgrade from kernel 3.16 to 3.17-rcX.
Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
("[media] rc-core: simplify sysfs code").
FWIW, I think "not working" is slightly misleading. "Required additional
configuration steps" is a better description, isn't it?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] dvb-usb-dvbsky: add s960ci dvb-s/s2 usb ci box support
DVBSky s960ci dvb-s/s2 usb ci box:
1>dvb frontend: M88TS2022(tuner),M88DS3103(demod)
2>usb controller: CY7C86013A
3>ci controller: CIMAX SP2 or its clone.
Signed-off-by: Nibble Max
---
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/dvbsky.c | 188 ++
2 files changed, 189 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 5b34323..7423033 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -146,5 +146,6 @@ config DVB_USB_DVBSKY
depends on DVB_USB_V2
select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_M88TS2022 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_SP2 if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the USB receivers from DVBSky.
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 34688c8..e3439f6 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -21,6 +21,7 @@
#include "dvb_usb.h"
#include "m88ds3103.h"
#include "m88ts2022.h"
+#include "sp2.h"
#define DVBSKY_MSG_DELAY 0/*2000*/
#define DVBSKY_BUF_LEN 64
@@ -33,6 +34,7 @@ struct dvbsky_state {
u8 obuf[DVBSKY_BUF_LEN];
u8 last_lock;
struct i2c_client *i2c_client_tuner;
+ struct i2c_client *i2c_client_ci;
/* fe hook functions*/
int (*fe_set_voltage)(struct dvb_frontend *fe,
@@ -362,6 +364,157 @@ fail_attach:
return ret;
}
+static int dvbsky_usb_ci_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
+{
+ struct dvb_usb_device *d = fe_to_d(fe);
+ struct dvbsky_state *state = d_to_priv(d);
+ u8 value;
+
+ if (voltage == SEC_VOLTAGE_OFF)
+ value = 0;
+ else
+ value = 1;
+ dvbsky_gpio_ctrl(d, 0x00, value);
+
+ return state->fe_set_voltage(fe, voltage);
+}
+
+static int dvbsky_ci_ctrl(void *priv, u8 read, int addr,
+ u8 data, int *mem)
+{
+ struct dvb_usb_device *d = priv;
+ int ret = 0;
+ u8 command[4], respond[2], command_size, respond_size;
+
+ command[1] = (u8)((addr >> 8) & 0xff); /*high part of address*/
+ command[2] = (u8)(addr & 0xff); /*low part of address*/
+ if (read) {
+ command[0] = 0x71;
+ command_size = 3;
+ respond_size = 2;
+ } else {
+ command[0] = 0x70;
+ command[3] = data;
+ command_size = 4;
+ respond_size = 1;
+ }
+ ret = dvbsky_usb_generic_rw(d, command, command_size,
+ respond, respond_size);
+ if (ret)
+ goto err;
+ if (read)
+ *mem = respond[1];
+ return ret;
+err:
+ dev_err(&d->udev->dev, "ci control failed=%d\n", ret);
+ return ret;
+}
+
+static const struct m88ds3103_config dvbsky_s960c_m88ds3103_config = {
+ .i2c_addr = 0x68,
+ .clock = 2700,
+ .i2c_wr_max = 33,
+ .clock_out = 0,
+ .ts_mode = M88DS3103_TS_CI,
+ .ts_clk = 1,
+ .ts_clk_pol = 1,
+ .agc = 0x99,
+ .lnb_hv_pol = 0,
+ .lnb_en_pol = 1,
+};
+
+static int dvbsky_s960c_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvbsky_state *state = adap_to_priv(adap);
+ struct dvb_usb_device *d = adap_to_d(adap);
+ int ret = 0;
+ /* demod I2C adapter */
+ struct i2c_adapter *i2c_adapter;
+ struct i2c_client *client_tuner, *client_ci;
+ struct i2c_board_info info;
+ struct sp2_config sp2_config;
+ struct m88ts2022_config m88ts2022_config = {
+ .clock = 2700,
+ };
+ memset(&info, 0, sizeof(struct i2c_board_info));
+
+ /* attach demod */
+ adap->fe[0] = dvb_attach(m88ds3103_attach,
+ &dvbsky_s960c_m88ds3103_config,
+ &d->i2c_adap,
+ &i2c_adapter);
+ if (!adap->fe[0]) {
+ dev_err(&d->udev->dev, "dvbsky_s960ci_attach fail.\n");
+ ret = -ENODEV;
+ goto fail_attach;
+ }
+
+ /* attach tuner */
+ m88ts2022_config.fe = adap->fe[0];
+ strlcpy(info.type, "m88ts2022", I2C_NAME_SIZE);
+ info.addr = 0x60;
+ info.platform_data = &m88ts2022_config;
+ request_module("m88ts2022");
+ client_tuner = i2c_new_device(i2c_adapter, &info);
+ if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
+ ret = -ENODEV;
+ goto fail_tuner_device;
+ }
+
+ if (!try_module_get(client_tuner->dev.driver->owner)) {
+ ret = -ENODEV;
+ goto fail_tuner_module;
+ }
+
+ /* attach ci controller */
+ memset(&sp2_config, 0, sizeof(sp2_config));
+ sp
Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960
Hi, 2014-07-30 14:32 GMT+02:00 Philipp Zabel : > Am Mittwoch, den 30.07.2014, 20:16 +0800 schrieb Shawn Guo: >> On Tue, Jul 29, 2014 at 07:06:25PM +0200, Philipp Zabel wrote: >> > > I followed the step to generate the firmware v4l-coda960-imx6q, and >> > > tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960 >> > > VPU' applied on top of it. But I got the error of 'Wrong firmwarel' as >> > > below. >> > > >> > > [2.582837] coda 204.vpu: requesting firmware >> > > 'v4l-coda960-imx6q.bin' for CODA960 >> > > [2.593344] coda 204.vpu: Firmware code revision: 0 >> > > [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: >> > > (0x), Version: 0.0.0 >> > >> > I just tried with the same kernel, and the above download, converted >> > with the program in the referenced mail, and I get this: >> > >> > coda 204.vpu: Firmware code revision: 36350 >> > coda 204.vpu: Initialized CODA960. >> > coda 204.vpu: Unsupported firmware version: 2.1.9 >> > coda 204.vpu: codec registered as /dev/video0 >> >> Okay, the reason I'm running into the issue is that I'm using the FSL >> U-Boot which turns off VDDPU at initialization. > > In that case you need to also apply the "Generic Device Tree based power > domain look-up" and "i.MX6 PU power domain support series". I'll have to > check the current state of that. I am having the same issue with firmware 3.1.1 and can't find version 2.1.5. Is there a way to make it work ? Does anybody has news from Freescale and official support for firmwares in mainline ? This is (as Robert Schwebel said) unusable with a recent kernel, and that's a shame... Thx, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.18-rc1] media updates
Mauro,
On Thu, 2014-10-09 at 14:18 -0300, Mauro Carvalho Chehab wrote:
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> tags/media/v3.18-rc1
>
>[...]
>
> Mauro Carvalho Chehab (180):
> [...]
> [media] omap: be sure that MMU is there for COMPILE_TEST
This became commit 38a073116525 ("[media] omap: be sure that MMU is
there for COMPILE_TEST").
As I reported in
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/82299
it adds an (optional) test for a Kconfig symbol HAS_MMU. There's no such
symbol. So that test will always fail. Did you perhaps mean simply "MMU"?
Paul Bolle
--
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
