[RFC] adp1653: Add device tree bindings for LED controller
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
I'll clean up driver code a bit more, remove the printks. Anything
else obviously wrong?
Signed-off-by: Pavel Machek pa...@ucw.cz
Thanks,
Pavel
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..ed0bfc1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -553,6 +561,18 @@
ti,usb-charger-detection = isp1704;
};
+
+ adp1653: adp1653@30 {
+ compatible = ad,adp1653;
+ reg = 0x30;
+
+ max-flash-timeout-usec = 50;
+ max-flash-intensity-uA= 32;
+ max-torch-intensity-uA = 5;
+ max-indicator-intensity-uA = 17500;
+
+ gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* Want 88 */
+ };
};
i2c3 {
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..e21ed02 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus sakari.ai...@iki.fi
* Tuukka Toivonen tuukka...@gmail.com
+ * Pavel Machek pa...@ucw.cz
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,9 +35,12 @@
#include linux/module.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/of_gpio.h
#include media/adp1653.h
#include media/v4l2-device.h
+#include linux/gpio.h
+
#define TIMEOUT_MAX82
#define TIMEOUT_STEP 54600
#define TIMEOUT_MIN(TIMEOUT_MAX - ADP1653_REG_CONFIG_TMR_SET_MAX \
@@ -308,7 +316,16 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
{
int ret;
- ret = flash-platform_data-power(flash-subdev, on);
+ if (flash-platform_data-power)
+ ret = flash-platform_data-power(flash-subdev, on);
+ else {
+ gpio_set_value(flash-platform_data-power_gpio, on);
+ if (on) {
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
+ }
+
if (ret 0)
return ret;
@@ -316,8 +333,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret 0)
+ if (ret = 0)
+ return ret;
+
+ if (flash-platform_data-power)
flash-platform_data-power(flash-subdev, 0);
+ else
+ gpio_set_value(flash-platform_data-power_gpio, 0);
return ret;
}
@@ -407,21 +429,87 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+
+
+
+
+
+
+
+
+
+
+
+
+
+static int adp1653_of_init(struct i2c_client *client, struct adp1653_flash
*flash,
+ struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!node)
+ return -EINVAL;
+
+ printk(adp1653: no platform data\n);
+ pd = devm_kzalloc(client-dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash-platform_data = pd;
+
+
+
+
+
+
+
+ if (of_property_read_u32(node, max-flash-timeout-usec, val)) return
-EINVAL;
+ pd-max_flash_timeout = val;
+ if (of_property_read_u32(node, max-flash-intensity-uA, val)) return
-EINVAL;
+ pd-max_flash_intensity = val/1000;
+ if (of_property_read_u32(node, max-torch-intensity-uA, val)) return
-EINVAL;
+ pd-max_torch_intensity = val/1000;
+ if (of_property_read_u32(node, max-indicator-intensity-uA, val))
return -EINVAL;
+ pd-max_indicator_intensity = val;
+
+ if (!of_find_property(node, gpios, NULL)) {
+ printk(No gpio node\n);
+ return -EINVAL;
+ }
+
+ gpio = of_get_gpio_flags(node, 0, flags);
+ if (gpio 0) {
+ printk(Error getting GPIO\n);
+ return -EINVAL;
+ }
+
+ pd-power_gpio = gpio;
+
+ return 0;
+}
+
+
static int adp1653_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
{
struct adp1653_flash *flash;
int ret;
- /* we couldn't work without platform data */
- if (client-dev.platform_data == NULL)
- return -ENODEV;
+ printk(adp1653: probe\n);
flash = devm_kzalloc(client-dev, sizeof(*flash), GFP_KERNEL);
if (flash == NULL)
return -ENOMEM;
- flash-platform_data = client-dev.platform_data;
+ /* we couldn't work without platform data */
+ if (client-dev.platform_data == NULL) {
+ ret =
Re: [RFC] adp1653: Add device tree bindings for LED controller
On 11/16/2014 08:59 AM, Pavel Machek wrote:
[...]
+ adp1653: adp1653@30 {
+ compatible = ad,adp1653;
The Analog Devices vendor prefix is adi.
--
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] Add RGB444_1X12 and RGB565_1X16 media bus formats
On Sat, 15 Nov 2014 16:49:33 +0200 Sakari Ailus sakari.ai...@iki.fi wrote: Hi Boris, Boris Brezillon wrote: Hi Sakari, On Fri, 14 Nov 2014 15:58:31 +0200 Sakari Ailus sakari.ai...@iki.fi wrote: Hi Boris, On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote: ... diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 23b4090..cc7b79e 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -33,7 +33,7 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x100e */ +/* RGB - next is 0x1010 */ #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE0x1003 @@ -47,6 +47,8 @@ #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c #define MEDIA_BUS_FMT_ARGB_1X32 0x100d +#define MEDIA_BUS_FMT_RGB444_1X120x100e +#define MEDIA_BUS_FMT_RGB565_1X160x100f I'd arrange these according to BPP and bits per sample, both in the header and documentation. I cannot keep both macro values and BPP/bits per sample in incrementing order. Are you sure you prefer to order macros in BPP/bits per sample order ? If you take a look elsewhere in the header, you'll notice that the ordering has preferred the BPP value (and other values with semantic significance) over the numeric value of the definition. I'd just prefer to keep it that way. This is also why the next is comments are there. My bad, I only had a look at RGB formats. I'll fix that. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Add RGB444_1X12 and RGB565_1X16 format definitions and update the documentation. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com --- Changes since v1: - keep BPP and bits per sample ordering Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++ include/uapi/linux/media-bus-format.h | 4 ++- 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 18730b9..0d6f731 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -176,6 +176,24 @@ /row /thead tbody valign=top + row id=MEDIA-BUS-FMT-RGB444-1X12 + entryMEDIA_BUS_FMT_RGB444_1X12/entry + entry0x100d/entry + entry/entry + dash-ent-20; + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry entry0x1001/entry @@ -288,6 +306,28 @@ entrygsubscript4/subscript/entry entrygsubscript3/subscript/entry /row + row id=MEDIA-BUS-FMT-RGB565-1X16 + entryMEDIA_BUS_FMT_RGB565_1X16/entry + entry0x100d/entry + entry/entry + dash-ent-16; + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row row id=MEDIA-BUS-FMT-BGR565-2X8-BE entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry entry0x1005/entry diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 23b4090..37091c6 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -33,11 +33,13 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x100e */ +/* RGB - next is 0x1010 */ +#define MEDIA_BUS_FMT_RGB444_1X12 0x100e #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 +#define MEDIA_BUS_FMT_RGB565_1X16 0x100f #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007 -- 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: [RFC] adp1653: Add device tree bindings for LED controller
On Sun 2014-11-16 09:11:04, Lars-Peter Clausen wrote:
On 11/16/2014 08:59 AM, Pavel Machek wrote:
[...]
+adp1653: adp1653@30 {
+compatible = ad,adp1653;
The Analog Devices vendor prefix is adi.
Thanks, will be fixed in next version.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] adp1653: Add device tree bindings for LED controller
Hi Pavel,
Am 16.11.2014 um 08:59 schrieb Pavel Machek:
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
[...]
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..ed0bfc1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -553,6 +561,18 @@
ti,usb-charger-detection = isp1704;
};
+
+ adp1653: adp1653@30 {
This should probably be led-controller@30 (a generic description not
specific to the model). The label name is fine.
+ compatible = ad,adp1653;
+ reg = 0x30;
+
+ max-flash-timeout-usec = 50;
+ max-flash-intensity-uA= 32;
+ max-torch-intensity-uA = 5;
+ max-indicator-intensity-uA = 17500;
+
+ gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* Want 88 */
At least to me, the meaning of Want 88 is not clear - drop or clarify?
+ };
};
i2c3 {
[snip]
Regards,
Andreas
--
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
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] adp1653: Add device tree bindings for LED controller
On Sun 2014-11-16 11:09:51, Andreas Färber wrote:
Hi Pavel,
Am 16.11.2014 um 08:59 schrieb Pavel Machek:
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
[...]
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..ed0bfc1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -553,6 +561,18 @@
ti,usb-charger-detection = isp1704;
};
+
+ adp1653: adp1653@30 {
This should probably be led-controller@30 (a generic description not
specific to the model). The label name is fine.
Thanks.
+ gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* Want 88 */
At least to me, the meaning of Want 88 is not clear - drop or clarify?
I changed it to /* 88 */ to match rest of code.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] staging: media: bcm2048: fix coding style error
Em Sat, 15 Nov 2014 13:25:03 -0800 Greg KH gre...@linuxfoundation.org escreveu: On Sat, Nov 15, 2014 at 09:59:34PM +0100, Pavel Machek wrote: On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote: On 11/15, Christian Resell wrote: Simple style fix (checkpatch.pl: space prohibited before that ','). For the eudyptula challenge (http://eudyptula-challenge.org/). Nice, however we do not need the information about the 'eudyptula challenge' in the commit message. If you want to include extra information please do it after the '---' line (just below the signed-off). You will find more details in the SubmittingPatches (chapter 15) of the kernel documentation. Greg is staging tree maintainer... And if single extra space is all you can fix in the driver, perhaps it is not worth the patch? I am not the maintainer of drivers/staging/media/ please look at MAINTAINERS before you make statements like that. And yes, one space fixes is just fine, that's why the code is in staging. Yes, space fixes is OK for staging. I'll apply this patch, removing the line that comments about the challenge, as we don't need to keep this information forever at the Kernel history. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] rtl2832: implement PIP mode
Em Sat, 15 Nov 2014 01:36:48 +0200 Antti Palosaari cr...@iki.fi escreveu: Moikka! On 11/14/2014 09:34 PM, Mauro Carvalho Chehab wrote: Em Wed, 12 Nov 2014 06:23:04 +0200 Antti Palosaari cr...@iki.fi escreveu: Implement PIP mode to stream from slave demodulator. PIP mode is enabled when .set_frontend is called with RF frequency 0, otherwise normal demod mode is enabled. This would be an API change, so, a DocBook patch is required. You are wrong. PIP mode is driver/device internal thing and will not be revealed to userspace. Anyway, using frequency=0 for PIP doesn't seem to be a good idea, as a read from GET_PROPERTY should override the cache with the real frequency. Yes, it is a hackish solution, used to put demod#0 on certain config when demod#1 is used. When PIP mode is set that demod#0 is totally useless as demod#1 is in use instead. Cache is garbage and no meaning at all. Also, someone came with me with a case where auto-frequency would be interesting, and proposed frequency=0. I was not convinced (and patches weren't sent), but using 0 for AUTO seems more appropriate, as we do the same for bandwidth (and may do the same for symbol_rate). I totally agree that is is hackish solution. That is called from rtl28xxu.c driver and I added already comment it is hackish solution, but you didn't apply that commit. So, the best seems to add a new property to enable PIP mode. No, no, no. It is like a PIP filter. It is actually special case of PID filter, having mux, to multiplex 2 TS interfaces to one (PIP = Picture in Picture). . . RTL2832P integrates RTL2832 demodulator . . . .| USB IF | | demod| . | demod| .|| || . || .| RTL2832P | | RTL2832 | . | MN88472 | .||TS bus|-/ -|-.---TS bus|| .|| || . || . So the basically both demod PID filters are now implemented in RTL2832 demod. Currently PIP mode is configured just to pass all the PIDs from MN88472 and reject RTL2832 PIDs. And when PIP mode is off, at pass all the PIDs from RTL2832, but rejects all PIDs from MN88472. Oh, I see. What demod(s) are exposed to userspace? both or just demod#1? If both are exposed, how userspace knows that demod#0 should not be used? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] rtl2832: implement PIP mode
On 11/16/2014 11:25 AM, Mauro Carvalho Chehab wrote: [...] What demod(s) are exposed to userspace? both or just demod#1? If both are exposed, how userspace knows that demod#0 should not be used? Regards, Mauro Currently both demods are exposed to userspace. While it is nice to have both I suggest that if a NM8847x demod is activated only expose that demod. That would remove the hack in master and would make it possible to faster move the NM8847x demods out of staging. The main reason for this hardware is the DVB-C and DVB-T2 support. Lets focus on getting that in an easy obtainable way. 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
Re: [PATCH] media: soc_camera: Fix VIDIOC_S_CROP ioctl miscalculation
Hi Kaneko-san,
Sorry for a long delay.
On Tue, 14 Oct 2014, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
This patch corrects the miscalculation of the capture buffer
size and clipping data update in VIDIOC_S_CROP sequence.
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
This patch is against master branch of linuxtv.org/media_tree.git.
drivers/media/platform/soc_camera/rcar_vin.c | 5 -
drivers/media/platform/soc_camera/soc_scale_crop.c | 6 --
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 61c36b0..5196c81 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1119,9 +1119,6 @@ static int rcar_vin_set_crop(struct soc_camera_device
*icd,
cam-width = mf.width;
cam-height = mf.height;
- icd-user_width = cam-width;
- icd-user_height = cam-height;
-
Why are you removing these two? Is this related to your other patch,
adding scaling to rcar_vin? If so, maybe this should go into that patch?
Or at least these two patches should be in a patch series, if one depends
on the other?
cam-vin_left = rect-left ~1;
cam-vin_top = rect-top ~1;
@@ -1130,8 +1127,6 @@ static int rcar_vin_set_crop(struct soc_camera_device
*icd,
if (ret 0)
return ret;
- cam-subrect = *rect;
-
You remove this, probably, because you added assignments to
soc_scale_crop.c below, right?
dev_dbg(dev, VIN cropped to %ux%u@%u:%u\n,
icd-user_width, icd-user_height,
cam-vin_left, cam-vin_top);
diff --git a/drivers/media/platform/soc_camera/soc_scale_crop.c
b/drivers/media/platform/soc_camera/soc_scale_crop.c
index 8e74fb7..7a1951a 100644
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -74,14 +74,14 @@ static void update_subrect(struct v4l2_rect *rect, struct
v4l2_rect *subrect)
if (rect-left subrect-left)
subrect-left = rect-left;
- else if (rect-left + rect-width
+ else if (rect-left + rect-width
subrect-left + subrect-width)
subrect-left = rect-left + rect-width -
subrect-width;
if (rect-top subrect-top)
subrect-top = rect-top;
- else if (rect-top + rect-height
+ else if (rect-top + rect-height
subrect-top + subrect-height)
subrect-top = rect-top + rect-height -
subrect-height;
The above two are correct, I think.
@@ -117,6 +117,7 @@ int soc_camera_client_s_crop(struct v4l2_subdev *sd,
dev_dbg(dev, Camera S_CROP successful for %dx%d@%d:%d\n,
rect-width, rect-height, rect-left, rect-top);
*target_rect = *cam_rect;
+ *subrect = *rect;
return 0;
}
@@ -204,6 +205,7 @@ int soc_camera_client_s_crop(struct v4l2_subdev *sd,
if (!ret) {
*target_rect = *cam_rect;
+ *subrect = *rect;
update_subrect(target_rect, subrect);
}
The above two don't seem to be correct to me. Please, see
Documentation/video4linux/sh_mobile_ceu_camera.txt for an explanation of
the cropping and scaling algorithms. subrect is a result of both
cropping and scaling, and mapping the camera host (DMA engine) output
window back onto the camera sensor plane.
Thanks
Guennadi
--
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: [RFCv6 PATCH 02/16] vb2: replace 'write' by 'dma_dir'
On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com The 'write' argument is very ambiguous. I first assumed that if it is 1, then we're doing video output but instead it meant the reverse. Since it is used to setup the dma_dir value anyway it is now replaced by the correct dma_dir value which is unambiguous. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Pawel Osciak pa...@osciak.com -- Best regards, Pawel Osciak -- 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: [RFCv6 PATCH 03/16] vb2: add dma_dir to the alloc memop.
On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com This is needed for the next patch where the dma-sg alloc memop needs to know the dma_dir. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Pawel Osciak pa...@osciak.com -- Best regards, Pawel Osciak -- 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: [RFCv6 PATCH 04/16] vb2-dma-sg: add allocation context to dma-sg
On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
Require that dma-sg also uses an allocation context. This is in preparation
for adding prepare/finish memops to sync the memory between DMA and CPU.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
[...]
@@ -166,6 +177,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
unsigned long size,
enum dma_data_direction dma_dir)
{
+ struct vb2_dma_sg_conf *conf = alloc_ctx;
struct vb2_dma_sg_buf *buf;
unsigned long first, last;
int num_pages_from_user;
@@ -235,6 +247,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
buf-num_pages, buf-offset, size, 0))
goto userptr_fail_alloc_table_from_pages;
+ /* Prevent the device from being released while the buffer is used */
+ buf-dev = get_device(conf-dev);
I'm not sure if we should be managing this... As far as I understand
the logic behind taking a ref in alloc, if we are the exporter, we may
have to keep it in case we need to free the buffers after our device
goes away. But for userptr, we only need this for syncs, and in that
case it's triggered by our driver, so I think we don't have to worry
about that. If we do though, then dma-contig should be doing this as
well.
return buf;
userptr_fail_alloc_table_from_pages:
@@ -274,6 +288,7 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
}
kfree(buf-pages);
vb2_put_vma(buf-vma);
+ put_device(buf-dev);
kfree(buf);
}
@@ -356,6 +371,27 @@ const struct vb2_mem_ops vb2_dma_sg_memops = {
};
EXPORT_SYMBOL_GPL(vb2_dma_sg_memops);
+void *vb2_dma_sg_init_ctx(struct device *dev)
+{
+ struct vb2_dma_sg_conf *conf;
+
+ conf = kzalloc(sizeof(*conf), GFP_KERNEL);
+ if (!conf)
+ return ERR_PTR(-ENOMEM);
+
+ conf-dev = dev;
+
+ return conf;
+}
+EXPORT_SYMBOL_GPL(vb2_dma_sg_init_ctx);
+
+void vb2_dma_sg_cleanup_ctx(void *alloc_ctx)
+{
+ if (!IS_ERR_OR_NULL(alloc_ctx))
I would prefer not doing this, it's very weird and would really just
be a programming bug.
--
Best regards,
Pawel Osciak
--
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: [RFCv6 PATCH 06/16] vb2-dma-sg: add dmabuf import support
On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com Add support for importing dmabuf to videobuf2-dma-sg. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Pawel Osciak pa...@osciak.com -- Best regards, Pawel Osciak -- 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: [RFCv6 PATCH 07/16] vb2-dma-sg: add support for dmabuf exports
On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hansv...@cisco.com Add DMABUF export support to vb2-dma-sg. Signed-off-by: Hans Verkuil hansv...@cisco.com Acked-by: Pawel Osciak pa...@osciak.com -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] v4l: Clean up sub-device format documentation
Hi Hans, On Fri, Nov 14, 2014 at 09:29:35AM +0100, Hans Verkuil wrote: Two small notes... On 11/09/2014 12:04 AM, Sakari Ailus wrote: The sub-device format documentation documented scaling configuration through formats. Instead the compose selection rectangle is elsewhere documented to be used for the purpose. Remove scaling related part of the documentation. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/dev-subdev.xml | 108 ++-- 1 file changed, 62 insertions(+), 46 deletions(-) diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml index d15aaf8..dbf9965 100644 --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml @@ -195,53 +195,59 @@ titleSample Pipeline Configuration/title tgroup cols=3 colspec colname=what/ - colspec colname=sensor-0 / - colspec colname=frontend-0 / - colspec colname=frontend-1 / - colspec colname=scaler-0 / - colspec colname=scaler-1 / + colspec colname=sensor-0 format / + colspec colname=frontend-0 format / + colspec colname=frontend-1 format / + colspec colname=scaler-0 format / + colspec colname=scaler-0 compose / + colspec colname=scaler-1 format / thead row entry/entry - entrySensor/0/entry - entryFrontend/0/entry - entryFrontend/1/entry - entryScaler/0/entry - entryScaler/1/entry + entrySensor/0 format/entry + entryFrontend/0 format/entry + entryFrontend/1 format/entry + entryScaler/0 format/entry + entryScaler/0 compose selection rectangle/entry + entryScaler/1 format/entry /row /thead tbody valign=top row entryInitial state/entry - entry2048x1536/entry - entry-/entry - entry-/entry - entry-/entry - entry-/entry + entry2048x1536/SGRBG8_1X8/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry /row row - entryConfigure frontend input/entry - entry2048x1536/entry - entryemphasis2048x1536/emphasis/entry - entryemphasis2046x1534/emphasis/entry - entry-/entry - entry-/entry + entryConfigure frontend sink format/entry + entry2048x1536/SGRBG8_1X8/entry + entryemphasis2048x1536/SGRBG8_1X8/emphasis/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry /row row - entryConfigure scaler input/entry - entry2048x1536/entry - entry2048x1536/entry - entry2046x1534/entry - entryemphasis2046x1534/emphasis/entry - entryemphasis2046x1534/emphasis/entry + entryConfigure scaler sink format/entry + entry2048x1536/SGRBG8_1X8/entry + entry2048x1536/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry + entryemphasis0,0/2046x1534/emphasis/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry /row row - entryConfigure scaler output/entry - entry2048x1536/entry - entry2048x1536/entry - entry2046x1534/entry - entry2046x1534/entry - entryemphasis1280x960/emphasis/entry + entryConfigure scaler sink compose selection/entry + entry2048x1536/SGRBG8_1X8/entry + entry2048x1536/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entryemphasis0,0/1280x960/emphasis/entry + entryemphasis1280x960/SGRBG8_1X8/emphasis/entry /row /tbody /tgroup @@ -249,19 +255,29 @@ para orderedlist - listitemparaInitial state. The sensor output is set to its native 3MP - resolution. Resolutions on the host frontend and scaler input and output - pads are undefined./para/listitem - listitemparaThe application configures the frontend input pad resolution to - 2048x1536. The driver propagates the format to the frontend output pad. - Note that the propagated output format can be different, as in this case, - than the input format, as the hardware might need to crop pixels (for - instance when converting a Bayer filter pattern to RGB or YUV). Does this Bayer filter note no longer apply? Cropping is out of scope as it requires using the selection API. I can add this where selections are discussed in more
Re: [PATCH v3 2/3] media: soc_camera: rcar_vin: Add capture width check for NV16 format
Hi Kaneko-san,
On Tue, 21 Oct 2014, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
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 koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
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
[snip]
@@ -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;
+ }
+
Shouldn't these checks go into rcar_vin_try_fmt() and then just adjust the
width instead of erroring out?
Thanks
Guennadi
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
Re: [PATCH 2/8] rtl2832: implement PIP mode
On 11/16/2014 01:36 PM, Benjamin Larsson wrote: On 11/16/2014 11:25 AM, Mauro Carvalho Chehab wrote: [...] What demod(s) are exposed to userspace? both or just demod#1? If both are exposed, how userspace knows that demod#0 should not be used? Regards, Mauro Currently both demods are exposed to userspace. While it is nice to have both I suggest that if a NM8847x demod is activated only expose that demod. That would remove the hack in master and would make it possible to faster move the NM8847x demods out of staging. The main reason for this hardware is the DVB-C and DVB-T2 support. Lets focus on getting that in an easy obtainable way. Yeah, both demods are exposed on single adapter, but two frontends. frontend0 == DVB-T demod RTL2832 frontend1 == DVB-T/T2/C demod MN88472 frontend0 is pretty useless if frontend1 is loaded... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] media: soc_camera: rcar_vin: Add NV16 horizontal scaling-up support
Hi Kaneko-san,
On Tue, 21 Oct 2014, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
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.
Here and also in the subject - what do you mean by scaling-up? Do you
really mean increasing sizes, i.e. scaling from smaller sizes to larger
ones? Is down-scaling not supported? Maybe someone with a better English
knowledge, then myself, could advise - is add scaling-up support ok or
would add up-scaling support or, if we don't really mean increasing,
just add scaling support be better?
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
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;
+ }
Similar to the previous patch - shouldn't this new test be added to
_try_fmt() and there you would just fix the size instead of erroring out?
Thanks
Guennadi
}
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
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
soc-camera state 3.19
Hi all, I've got 10 patches from Koji Matsuoka and Yoshihiro Kaneko on stack for 3.19 and a patch from Philipp Zabel, that touches soc-camera, but will probably go via Mauro's tree directly. Below is their respective state and most recent version and their posting dates. If I missed any patches, please let me know! [PATCH] media: soc_camera: rcar_vin: Add YUYV capture format support of 14 Oct state: Ok [PATCH] media: soc_camera: Fix VIDIOC_S_CROP ioctl miscalculation of 14 Oct state: comment posted, waiting for reply [PATCH] media: soc_camera: rcar_vin: Add DT support for r8a7793 and r8a7794 SoCs of 20 Oct state: Ok [PATCH v3 1/3] media: soc_camera: rcar_vin: Add scaling support of 21 Oct state: Ok [PATCH v3 2/3] media: soc_camera: rcar_vin: Add capture width check for NV16 format of 21 Oct state: comment posted, waiting for reply [PATCH v3 3/3] media: soc_camera: rcar_vin: Add NV16 horizontal scaling-up support of 21 Oct state: comment posted, waiting for reply [PATCH v2] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode of 22 Oct state: Ok [PATCH] media: soc_camera: rcar_vin: Fix alignment of clipping size of 31 Oct state: waiting for response to Sergei's comments [PATCH] media: soc_camera: rcar_vin: Fix interrupt enable in progressive of 31 Oct state: Ok [PATCH v4] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support of 1 Nov state: Ok [PATCH v5 1/6] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint of 29 Sep state: comment posted, waiting for an update 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 2/3] v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target
Hi Hans, Thank you for the review. On Fri, Nov 14, 2014 at 09:46:54AM +0100, Hans Verkuil wrote: On 11/09/2014 12:04 AM, Sakari Ailus wrote: The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a sensor's pixel array. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/selections-common.xml |8 include/uapi/linux/v4l2-common.h |2 ++ 2 files changed, 10 insertions(+) diff --git a/Documentation/DocBook/media/v4l/selections-common.xml b/Documentation/DocBook/media/v4l/selections-common.xml index 7502f78..5fc833a 100644 --- a/Documentation/DocBook/media/v4l/selections-common.xml +++ b/Documentation/DocBook/media/v4l/selections-common.xml @@ -63,6 +63,14 @@ entryYes/entry /row row + entryconstantV4L2_SEL_TGT_NATIVE_SIZE/constant/entry + entry0x0003/entry + entryThe native size of the device, e.g. a sensor's + pixel array./entry You might want to state that top and left are always 0. Fixed. I also added a patch to fix this in the smiapp driver --- the values were uninitialised. :-P + entryYes/entry + entryYes/entry + /row + row entryconstantV4L2_SEL_TGT_COMPOSE/constant/entry entry0x0100/entry entryCompose rectangle. Used to configure scaling diff --git a/include/uapi/linux/v4l2-common.h b/include/uapi/linux/v4l2-common.h index 2f6f8ca..1527398 100644 --- a/include/uapi/linux/v4l2-common.h +++ b/include/uapi/linux/v4l2-common.h @@ -43,6 +43,8 @@ #define V4L2_SEL_TGT_CROP_DEFAULT 0x0001 /* Cropping bounds */ #define V4L2_SEL_TGT_CROP_BOUNDS 0x0002 +/* Native frame size */ +#define V4L2_SEL_TGT_NATIVE_SIZE 0x0003 /* Current composing area */ #define V4L2_SEL_TGT_COMPOSE 0x0100 /* Default composing area */ I like this. This would also make it possible to set the 'canvas' size of an mem2mem device. Currently calling S_FMT for a mem2mem device cannot setup any scaler since there is no native size. Instead S_FMT effectively *sets* the native size. The same is true for webcams with a scaler, which is why you added this in the first place. Obviously for sensors this target is read-only, but for a mem2mem device it can be writable as well. However, to make full use of this you also need to add input and output capabilities if the native size can be set: V4L2_IN_CAP_NATIVE_SIZE V4L2_OUT_CAP_NATIVE_SIZE Do you think this would require a capability flag, rather than just returning an error if the target is unsettable, as we otherwise already do if a selection target isn't supported? For the compound controls it's even easier, you just don't have a read-only flag set in the equivalent control. (see ENUMINPUT/ENUMOUTPUT) This would nicely fill in a hole in the V4L2 Spec. -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Nov 17 04:00:14 CET 2014 git branch: test git hash: c02ef64aab828d80040b5dce934729312e698c33 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-2.slh.2-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: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-rc1-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: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
