Vážení: Webmail odberateľ
-- Vážení: Webmail odberateľ Oznamujeme vám, že váš e-mailový účet bol prekročený skladovacie kapacity. Nebudete môcť odosielať a prijímať e-maily a vaše e-mailový účet bude vymazaný z nášho servera. Ak sa chcete tomuto problému vyhnúť, Kliknite na odkaz nižšie pre aktualizáciu pokynov http://webmailupdate80997.jimdo.com/ Ďakujem. Manažérsky tím. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] dt: binding: add binding for ImgTec IR block
On 22/12/13 12:48, Tomasz Figa wrote: diff --git a/Documentation/devicetree/bindings/media/img-ir.txt b/Documentation/devicetree/bindings/media/img-ir.txt new file mode 100644 index ..6f623b094ea6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/img-ir.txt @@ -0,0 +1,20 @@ +* ImgTec Infrared (IR) decoder + +Required properties: +- compatible: Should be img,ir This compatible string isn't really very specific. Is there some IP revision string that could be added, to account for possible design changes that may require binding change? Yes, agreed. I'll try and find a more unambiguous name for the IP block. +- reg: Physical base address of the controller and length of +memory mapped region. +- interrupts: The interrupt specifier to the cpu. + +Optional properties: +- clocks: Clock specifier for base clock. +Defaults to 32.768KHz if not specified. To make the binding less fragile and allow interoperability with non-DT platforms it may be better to provide also clock-names property (so you can use clk_get(); that's a Linux implementation detail, though, but to make our lives easier IMHO they should be sometimes considered too). Good idea. Looking at the hardware manual it actually describes 3 clock inputs, and although only one is needed by the driver it makes sense for the DT binding to be able to describe them all. I'll probably go with these clock-names values: core: Core clock (32.867kHz) sys: System side (fast) clock mod: Power modulation clock Cheers James -- 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] cx231xx: fix i2c debug prints
Do not shift the already 7bit i2c address.
Print a message also for write+read transactions.
For write+read, print the read buffer correctly instead of using the write
buffer.
Fix continuation lines
Signed-off-by: Matthias Schwarzott z...@gentoo.org
---
drivers/media/usb/cx231xx/cx231xx-i2c.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c
b/drivers/media/usb/cx231xx/cx231xx-i2c.c
index 96a5a09..7c0f797 100644
--- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
@@ -371,9 +371,9 @@ static int cx231xx_i2c_xfer(struct i2c_adapter *i2c_adap,
mutex_lock(dev-i2c_lock);
for (i = 0; i num; i++) {
- addr = msgs[i].addr 1;
+ addr = msgs[i].addr;
- dprintk2(2, %s %s addr=%x len=%d:,
+ dprintk2(2, %s %s addr=0x%x len=%d:,
(msgs[i].flags I2C_M_RD) ? read : write,
i == num - 1 ? stop : nonstop, addr, msgs[i].len);
if (!msgs[i].len) {
@@ -390,32 +390,41 @@ static int cx231xx_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = cx231xx_i2c_recv_bytes(i2c_adap, msgs[i]);
if (i2c_debug = 2) {
for (byte = 0; byte msgs[i].len; byte++)
- printk( %02x, msgs[i].buf[byte]);
+ printk(KERN_CONT %02x,
msgs[i].buf[byte]);
}
} else if (i + 1 num (msgs[i + 1].flags I2C_M_RD)
msgs[i].addr == msgs[i + 1].addr
(msgs[i].len = 2) (bus-nr 3)) {
+ /* write bytes */
+ if (i2c_debug = 2) {
+ for (byte = 0; byte msgs[i].len; byte++)
+ printk(KERN_CONT %02x,
msgs[i].buf[byte]);
+ printk(KERN_CONT \n);
+ }
/* read bytes */
+ dprintk2(2, plus %s %s addr=0x%x len=%d:,
+ (msgs[i+1].flags I2C_M_RD) ? read : write,
+ i+1 == num - 1 ? stop : nonstop, addr,
msgs[i+1].len);
rc = cx231xx_i2c_recv_bytes_with_saddr(i2c_adap,
msgs[i],
msgs[i + 1]);
if (i2c_debug = 2) {
- for (byte = 0; byte msgs[i].len; byte++)
- printk( %02x, msgs[i].buf[byte]);
+ for (byte = 0; byte msgs[i+1].len; byte++)
+ printk(KERN_CONT %02x,
msgs[i+1].buf[byte]);
}
i++;
} else {
/* write bytes */
if (i2c_debug = 2) {
for (byte = 0; byte msgs[i].len; byte++)
- printk( %02x, msgs[i].buf[byte]);
+ printk(KERN_CONT %02x,
msgs[i].buf[byte]);
}
rc = cx231xx_i2c_send_bytes(i2c_adap, msgs[i]);
}
if (rc 0)
goto err;
if (i2c_debug = 2)
- printk(\n);
+ printk(KERN_CONT \n);
}
mutex_unlock(dev-i2c_lock);
return num;
--
1.8.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] media: rc: img-ir: add NEC decoder module
On 22/12/13 13:49, Mauro Carvalho Chehab wrote:
Em Fri, 13 Dec 2013 15:12:54 +
James Hogan james.ho...@imgtec.com escreveu:
+/* Convert NEC data to a scancode */
+static int img_ir_nec_scancode(int len, u64 raw, u64 protocols)
+{
+unsigned int addr, addr_inv, data, data_inv;
+int scancode;
+/* a repeat code has no data */
+if (!len)
+return IMG_IR_REPEATCODE;
+if (len != 32)
+return IMG_IR_ERR_INVALID;
+addr = (raw 0) 0xff;
+addr_inv = (raw 8) 0xff;
+data = (raw 16) 0xff;
+data_inv = (raw 24) 0xff;
+/* Validate data */
+if ((data_inv ^ data) != 0xff)
+return IMG_IR_ERR_INVALID;
+
+if ((addr_inv ^ addr) != 0xff) {
+/* Extended NEC */
+scancode = addr 16 |
+ addr_inv 8 |
+ data;
+} else {
+/* Normal NEC */
+scancode = addr 8 |
+ data;
+}
There are some types of NEC extended that uses the full 32 bits as
scancodes. Those are used at least on Apple and TiVo remote controllers.
Ooh, I hadn't spotted that patch. I'll make the necessary changes.
I notice that the scancode produced by the raw NEC decoder is the raw
non-bit-reversed version of the bits received, whereas for normal and
extended NEC the scancode fields are bit reversed. The TiVo keymap
appears to confirm that this is essentially backwards:
NEC:0xAAaaCCcc (AA=address, aa=not A, CC=command, cc=not command)
bitrev(CCcc):
{ 0xa10c140b, KEY_NUMERIC_1 }, d028
{ 0xa10c940b, KEY_NUMERIC_2 }, d029
{ 0xa10c540b, KEY_NUMERIC_3 }, d02a
{ 0xa10cd40b, KEY_NUMERIC_4 }, d02b
{ 0xa10c340b, KEY_NUMERIC_5 }, d02c
{ 0xa10cb40b, KEY_NUMERIC_6 }, d02d
{ 0xa10c740b, KEY_NUMERIC_7 }, d02e
{ 0xa10cf40b, KEY_NUMERIC_8 }, d02f
{ 0x0085302f, KEY_NUMERIC_8 },
{ 0xa10c0c03, KEY_NUMERIC_9 }, c030
{ 0xa10c8c03, KEY_NUMERIC_0 }, c031
Clearly CC is supposed to be the LSB of the command.
Is it possible to reverse the bits in these scancode encodings (and of
course update the keymaps) or does this constitute a stable ABI that is
now too late to change?
IMO the following encoding would make much better sense for 32bit NEC
scancodes:
bits 31:16 = bitrev(AAaa)
bits 15:0 = bitrev(CCcc)
I.e. just bit reverse each 16bit half.
This puts the LSB of the command field in the LSB of the scancode which
I think is important, and treats the address field as a continuous
16bits (even though the extended NEC scancodes have address bytes
swapped for some reason - although for address it doesn't really
matter). If we assume the high byte of the address (aa) is always
non-zero, then the scancodes can be distinguished.
Cheers
James
--
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 10/11] media: rc: img-ir: add Sharp decoder module
On 22/12/13 14:01, Mauro Carvalho Chehab wrote: Em Fri, 13 Dec 2013 15:12:58 + James Hogan james.ho...@imgtec.com escreveu: Add an img-ir module for decoding the Sharp infrared protocol. Patches 5 and 7-11 look OK to me. Thanks very much for reviewing. While not required for patchset acceptance, it would be great if you could also add an IR raw decoder for this protocol, specially if you can also test it. Yes, this had occurred to me too, but I haven't got around to it yet. I've found several codes my universal remote control can use which appear to be the sharp protocol so I am able to test it a bit, but don't have any original sharp remotes to hand. Cheers James -- 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 04/11] media: rc: img-ir: add hardware decoder driver
Hi Mauro, On 22/12/13 13:40, Mauro Carvalho Chehab wrote: Em Fri, 13 Dec 2013 15:12:52 + James Hogan james.ho...@imgtec.com escreveu: Add remote control input driver for the ImgTec Infrared block hardware decoder, which is set up with timings for a specific protocol and supports mask/value filtering and wake events. The hardware decoder timing values, raw data to scan code conversion function and scan code filter to raw data filter conversion function are provided as separate modules for each protocol which this part of the driver can use. The scan code filter value and mask (and the same again for wake from sleep) are specified via sysfs files in /sys/class/rc/rcX/. We should discuss a little more about those new sysfs controls. Yes I thought so. For reference there was some mention of this in an old thread ([RFC] What are the goals for the architecture of an in-kernel IR system), but I didn't go into any details back then: http://thread.gmane.org/gmane.linux.kernel.input/9747 (search for my name) There are two separate questions here: 1) are those new sysfs controls really device specific? If not, then it makes sense to add support for it at rc-core. I would say no, although at least wakeup filters is dependent on hardware support. I've attempted to make them fairly generic (i.e. they deal with scancodes rather than raw data, so the filter could certainly be done in software) but they do implicitly assume only a single protocol being enabled at a time (in fact the values reset if the protocol is changed). I suppose it could just be expected that matches on any enabled protocol would be reported. I suspect that a wakeup scancode is something that should be part of the RC core, as other devices may have it too. Also, the RC core currently supports a scancode mask. Not sure if it is the same concept as the one used on your hardware. Could you please explain it better? Okay. The hardware provides a data valid interrupt (indicating that data was received which conforms to the programmed timings), and a data match interrupt (indicating that the valid data matches a certain value - with a mask of bits which are compared). By default the data valid interrupt is used to trigger input events, and wake-on-interrupt is disabled. After ... echo 0x1fc00 filter echo 0x00 filter_mask ... the data match interrupt is used to trigger input events, and the value and mask are transformed into raw IR data value and mask and programmed into HW. In this case only extended-NEC IR codes (NEC is current protocol, extended because the filter value has 0xff bits set) with an address field of 0x01fc will trigger input events, but the command code (in scancode bits 0xff) isn't matched so any button on the remote triggers input events. As well as reducing the irrelevant input events, this prevents the driver switching to repeat code timings until the timeout is hit for codes that aren't actually interesting anyway. The wakeup_* files behave identically, except they apply only during suspend and a match triggers a wakeup. So after the following ... echo 0x1fc00 wakeup_filter echo 0xff wakeup_filter_mask ... when suspend takes place the wakeup specific value/mask is programmed, and the wake only occurs if the whole address and command code matches, i.e. only the power button of this specific remote triggers a wake. Note that wakeup_filter[_mask] currently does not have to be a subset of filter[_mask]. 2) Where those new sysfs nodes will be documented. With regards to (2), we currently lack a chapter at the Linux Media Documentation/DocBook or at Documentation/ABI/ for the existing sysfs interface, but let's not increase the gap, please. I'll see if I can find some time to write such documentation, probably at Documentation/ABI/testing. So, if we come to the conclusion that those interfaces should be part of the rc core, we'll need them to be documented at Documentation/ABI/testing too. Otherwise, if we decide to add some of those as private API, please add a README for this device, under Documentation/remote-controllers. Okay. The patch itself (and patches 1-3) look OK to me. I'll be reviewing the other patches on separate emails. Thanks very much for taking the time to review it. Cheers James -- 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: omap3isp device tree support
On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: [1.575225] console [ttyO2] enabled [1.581268] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb042050 [1.589324] Internal error: : 1028 [#1] ARM [1.593719] Modules linked in: [1.596954] CPU: 0 PID: 1 Comm: swapper Tainted: GW3.13.0-rc3+ #2 [1.604461] task: de87 ti: de86c000 task.ti: de86c000 [1.610137] PC is at serial_omap_probe+0x3a8/0x644 [1.615203] LR is at trace_hardirqs_on_caller+0x104/0x1dc [1.620849] pc : [c028c0a4]lr : [c006411c]psr: 2153 [1.620849] sp : de86de30 ip : c06f8784 fp : [1.632934] r10: r9 : dea931ad r8 : c0b7e144 [1.638397] r7 : dea75c50 r6 : de8e4c00 r5 : de8e4c10 r4 : dea93010 [1.645263] r3 : fb042000 r2 : fb042050 r1 : 0014 r0 : [1.652130] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [1.659912] Control: 10c5387d Table: 80004019 DAC: 0015 [1.665924] Process swapper (pid: 1, stack limit = 0xde86c240) [1.672058] Stack: (0xde86de30 to 0xde86e000) [1.676635] de20: c053bd40 dea931ad [1.685241] de40: de8e4c10 de8e4c10 c0636340 c0636340 006e [1.693847] de60: de86c030 c029414c c0294134 c0b7e618 de8e4c10 c0292c98 de8e4c10 c0636340 [1.702453] de80: de8e4c44 c05eb8ac c0292e90 c0636340 c0292dfc c02912a8 [1.711029] dea0: de803aa8 de8c8050 c0636340 de9e4900 c0636ec0 c029246c c0559bec c0636340 [1.719635] dec0: 0006 c0636340 0006 c064e500 c064e500 c0293254 c05fddf8 [1.728240] dee0: 0006 c05eb8cc c05fddf8 c00087e4 de87 c0620438 6153 c0068fcc [1.736816] df00: c064e500 1480 c0620434 c05f72e0 c05f72b8 c0439170 0002 de86c000 [1.745422] df20: c0f9e9f5 c04568d4 006e c004be2c c05ab990 0006 c0f9ea08 0006 [1.754028] df40: 6153 c05fddf8 0006 c064e500 c064e500 c05d1480 006e c05f72e0 [1.762634] df60: c05f72d4 c05d1c68 0006 0006 c05d1480 c00550a0 052d1144 [1.771209] df80: 08010820 c04310f4 [1.779815] dfa0: c04310fc c000e048 [1.788421] dfc0: [1.796997] dfe0: 0013 41001412 44300082 [1.805633] [c028c0a4] (serial_omap_probe+0x3a8/0x644) from [c029414c] (platform_drv_probe+0x18/0x48) [1.815673] [c029414c] (platform_drv_probe+0x18/0x48) from [c0292c98] (driver_probe_device+0x114/0x234) [1.825927] [c0292c98] (driver_probe_device+0x114/0x234) from [c0292e90] (__driver_attach+0x94/0x98) [1.835906] [c0292e90] (__driver_attach+0x94/0x98) from [c02912a8] (bus_for_each_dev+0x60/0x94) [1.845428] [c02912a8] (bus_for_each_dev+0x60/0x94) from [c029246c] (bus_add_driver+0x148/0x1f0) [1.855010] [c029246c] (bus_add_driver+0x148/0x1f0) from [c0293254] (driver_register+0x78/0xf8) [1.864532] [c0293254] (driver_register+0x78/0xf8) from [c05eb8cc] (serial_omap_init+0x20/0x44) [1.874053] [c05eb8cc] (serial_omap_init+0x20/0x44) from [c00087e4] (do_one_initcall+0x100/0x150) [1.883758] [c00087e4] (do_one_initcall+0x100/0x150) from [c05d1c68] (kernel_init_freeable+0x1fc/0x29c) [1.894012] [c05d1c68] (kernel_init_freeable+0x1fc/0x29c) from [c04310fc] (kernel_init+0x8/0x120) [1.903717] [c04310fc] (kernel_init+0x8/0x120) from [c000e048] (ret_from_fork+0x14/0x2c) [1.912567] Code: e5d42051 e5943024 e3a01014 e0832211 (e5923000) is it a known bug? something i should check in my config/dts? Enrico -- 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: omap3isp device tree support
On Mon, Dec 23, 2013 at 6:45 PM, Enrico ebut...@users.berlios.de wrote: On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: Sorry for the noise, it was a stupid problem with DT. Enrico -- 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: soc_camera: rcar_vin: Add preliminary R-Car M2 support
This adds R-Car M2 (R8A7791) VIN support.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 6866bb4..8b79727 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,6 +106,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
+ RCAR_M2,
RCAR_H2,
RCAR_H1,
RCAR_M1,
@@ -302,8 +303,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
- priv-chip == RCAR_E1) {
+ if (priv-chip == RCAR_M2 || priv-chip == RCAR_H2 ||
+ priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1384,6 +1385,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
+ { r8a7791-vin, RCAR_M2 },
{ r8a7790-vin, RCAR_H2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
--
1.8.3.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: Regression inside omap3isp/resizer (was: 3fdfeda causes a regression)
Hello Laurent, On 12/17/2013 11:42 AM, Florian Vaussard wrote: Hello Laurent, I was working on having a functional IOMMU/ISP for 3.14, and had an issue with an image completely distorted. Comparing with another kernel, I saw that PRV_HORZ_INFO and PRV_VERT_INFO differed. On the newer kernel, sph, eph, svl, and slv were all off-by 2, causing my final image to miss 4 pixels on each line, thus distorting the result. Your commit 3fdfedaaa7f243f3347084231c64f6c1be0ba131 '[media] omap3isp: preview: Lower the crop margins' indeed changes PRV_HORZ_INFO and PRV_VERT_INFO by removing the if() condition. Reverting it made my image to be valid again. FYI, my pipeline is: MT9V032 (SGRBG10 752x480) - CCDC - PREVIEW (UYVY 752x480) - RESIZER - out Just an XMAS ping on this :-) Do you have any idea how to solve this without reverting the patch? (I changed the topic to make it more clear) Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Dec 24 04:00:25 CET 2013 git branch: test git hash: 7d459937dc09bb8e448d9985ec4623779427d8a5 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: ERRORS linux-git-arm-davinci: ERRORS linux-git-arm-exynos: ERRORS linux-git-arm-mx: ERRORS linux-git-arm-omap: ERRORS linux-git-arm-omap1: ERRORS linux-git-arm-pxa: ERRORS linux-git-blackfin: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-rc1-i686: OK linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12-x86_64: WARNINGS linux-3.13-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
