Re: SOLO6x10: fix a race in IRQ handler.
Krzysztof, it seems to really help. The host is working stable for 2.5 hours at the moment, with original framerate of 2 fps. Thank you very much. -- Andrey Utkin -- 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: SOLO6x10: fix a race in IRQ handler.
Hi Andrey,
Please always prefix the subject line with [PATCH] when you post a patch. That
way it
will be picked up by patchwork
(https://patchwork.linuxtv.org/project/linux-media/list/)
and the patch won't be lost.
Can you repost with such a prefix?
Thanks!
Hans
On 11/15/2014 11:34 AM, Andrey Utkin wrote:
From: khal...@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
The IRQs have to be acknowledged before they are serviced, otherwise some
events
may be skipped. Also, acknowledging IRQs just before returning from the
handler
doesn't leave enough time for the device to deassert the INTx line, and for
bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
dual core CPU.
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
Acked-by: Andrey Utkin andrey.ut...@corp.bluecherry.net
Tested-by: Andrey Utkin andrey.ut...@corp.bluecherry.net
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data)
if (!status)
return IRQ_NONE;
- if (status ~solo_dev-irq_mask) {
- solo_reg_write(solo_dev, SOLO_IRQ_STAT,
-status ~solo_dev-irq_mask);
- status = solo_dev-irq_mask;
- }
+ /* Acknowledge all interrupts immediately */
+ solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
if (status SOLO_IRQ_PCI_ERR)
solo_p2m_error_isr(solo_dev);
@@ -132,9 +129,6 @@ static irqreturn_t solo_isr(int irq, void *data)
if (status SOLO_IRQ_G723)
solo_g723_isr(solo_dev);
- /* Clear all interrupts handled */
- solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
-
return IRQ_HANDLED;
}
--
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] tuners: si2157: Si2148 support.
What about defining the firmware for Si2148-A20, but since the file is the same as Si2158-A20 just point to the same file? #define SI2148_A20_FIRMWARE dvb-tuner-si2158-a20-01.fw Then if Si2158-A20 would in the future get a new firmware that would not work with Si2148, this would not break Si2148. Another point that came to my mind is that we start to have quite a list of chips there in the printouts (Si2147/Si2148/Si2157/Si2158) and more is coming - I'm working with an Si2146 device currently. Should we just say Si214x/Si215x there or something? Cheers, -olli On 15 November 2014 03:22, CrazyCat crazyca...@narod.ru wrote: 2148 is 2158 without analog support. Same firmware. 15.11.2014, 03:02, Antti Palosaari cr...@iki.fi: I wonder if we should define own firmware for Si2148-A20 just for sure. Olli? -- 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] solo6x10: fix a race in IRQ handler
From: Krzysztof Hałasa khal...@piap.pl
The IRQs have to be acknowledged before they are serviced, otherwise some events
may be skipped. Also, acknowledging IRQs just before returning from the handler
doesn't leave enough time for the device to deassert the INTx line, and for
bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
dual core CPU.
Signed-off-by: Krzysztof Hałasa khal...@piap.pl
Acked-by: Andrey Utkin andrey.ut...@corp.bluecherry.net
Tested-by: Andrey Utkin andrey.ut...@corp.bluecherry.net
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data)
if (!status)
return IRQ_NONE;
- if (status ~solo_dev-irq_mask) {
- solo_reg_write(solo_dev, SOLO_IRQ_STAT,
- status ~solo_dev-irq_mask);
- status = solo_dev-irq_mask;
- }
+ /* Acknowledge all interrupts immediately */
+ solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
if (status SOLO_IRQ_PCI_ERR)
solo_p2m_error_isr(solo_dev);
@@ -132,9 +129,6 @@ static irqreturn_t solo_isr(int irq, void *data)
if (status SOLO_IRQ_G723)
solo_g723_isr(solo_dev);
- /* Clear all interrupts handled */
- solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
-
return IRQ_HANDLED;
}
--
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] tuners: si2157: Si2148 support.
On 11/15/2014 12:41 PM, Olli Salonen wrote: What about defining the firmware for Si2148-A20, but since the file is the same as Si2158-A20 just point to the same file? #define SI2148_A20_FIRMWARE dvb-tuner-si2158-a20-01.fw Then if Si2158-A20 would in the future get a new firmware that would not work with Si2148, this would not break Si2148. Assuming you rename possible new firmware: dvb-tuner-si2158-a20-01.fw dvb-tuner-si2158-a20-02.fw ? Basically, you would not like to rename firmware when it is updated if it is compatible with the driver. Lets say firmware gets bug fixes, just introduce new firmware with same name. If driver changes are needed, then you have to rename it. These firmware changes are always problematic as you have to think possible regression - it is regression from the user point of view if kernel driver updates but it does not work as firmware incompatibility. How about Si2146 firmware you are working? All-in-all, with the current situation and knowledge I have, I see it is better to define new firmware name for that chip model and revision like the others. Just to make life it easier in a case Si2148-A20 and Si2158-A20 firmwares will be different on some case on some day. So lets implement it that way or explain some possible problem we could meet when defining own firmware file name. Another point that came to my mind is that we start to have quite a list of chips there in the printouts (Si2147/Si2148/Si2157/Si2158) and more is coming - I'm working with an Si2146 device currently. Should we just say Si214x/Si215x there or something? I have no opinion. regards Antti Cheers, -olli On 15 November 2014 03:22, CrazyCat crazyca...@narod.ru wrote: 2148 is 2158 without analog support. Same firmware. 15.11.2014, 03:02, Antti Palosaari cr...@iki.fi: I wonder if we should define own firmware for Si2148-A20 just for sure. Olli? -- 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 1/3] tuners: si2157: Si2148 support.
On Sat, 15 Nov 2014, Antti Palosaari wrote: Assuming you rename possible new firmware: dvb-tuner-si2158-a20-01.fw dvb-tuner-si2158-a20-02.fw ? Basically, you would not like to rename firmware when it is updated if it is compatible with the driver. Lets say firmware gets bug fixes, just introduce new firmware with same name. If driver changes are needed, then you have to rename it. These firmware changes are always problematic as you have to think possible regression - it is regression from the user point of view if kernel driver updates but it does not work as firmware incompatibility. Indeed, I assumed whenever there's a firmware update, we create a new filename for that. If that's not the case, then better to keep Si2148 and Si2158 totally separate. At this point the files would be identical of course. How about Si2146 firmware you are working? No firmware loaded for that. Cheers, -olli -- 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] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
Thanks to all for the great help so far, but I've got another issue with upstream driver. In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The S_STD ioctl call actually makes difference, because without that the frame slides vertically all the time. But after the call the picture is not correct. Such change didn't help: https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4 So, temporarily, I've hardcoded this for exact customer who uses PAL: https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a rmmod/modprobe cycle works fine and doesn't make any difference from reboot, but still it works correctly only with PAL hardcoded for the first-time initialization. Any ideas why wouldn't it work to change the mode after the driver load? Would it be allowed to add back that kernel module parameter (the one passed at module load time)? -- Bluecherry developer. -- 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] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
Hi Andrey, On 11/15/2014 02:48 PM, Andrey Utkin wrote: Thanks to all for the great help so far, but I've got another issue with upstream driver. In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The S_STD ioctl call actually makes difference, because without that the frame slides vertically all the time. But after the call the picture is not correct. That's strange. I know I tested it at the time. I assume it is the PAL standard that isn't working (as opposed to NTSC)? Or does it just always fail when you switch between the two standards? Such change didn't help: https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4 So, temporarily, I've hardcoded this for exact customer who uses PAL: https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a rmmod/modprobe cycle works fine and doesn't make any difference from reboot, but still it works correctly only with PAL hardcoded for the first-time initialization. Any ideas why wouldn't it work to change the mode after the driver load? Not really. I will have to test this next week (either Monday or Friday) with my solo board. Would it be allowed to add back that kernel module parameter (the one passed at module load time)? No. That's a hack, the S_STD call should just work and we need to figure out why it fails. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] videodev2.h: add new v4l2_ext_control flags field
Hi Hans,
On Sun, Sep 21, 2014 at 04:48:24PM +0200, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Replace reserved2 by a flags field. This is used to tell whether
setting a new store value is applied only once or every time that
v4l2_ctrl_apply_store() is called for that store.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/uapi/linux/videodev2.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2ca44ed..fa84070 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1282,7 +1282,7 @@ struct v4l2_control {
struct v4l2_ext_control {
__u32 id;
__u32 size;
- __u32 reserved2[1];
+ __u32 flags;
16 bits, please. The pad number (for sub-devices) would need to be added
here as well, and that's 16 bits. A flag might be needed to tell it's valid,
too.
union {
__s32 value;
__s64 value64;
@@ -1294,6 +1294,10 @@ struct v4l2_ext_control {
};
} __attribute__ ((packed));
+/* v4l2_ext_control flags */
+#define V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE 0x0001
+#define V4L2_EXT_CTRL_FL_IGN_STORE 0x0002
Do we need both? Aren't these mutually exclusive, and you must have either
to be meaningful in the context of a store?
+
struct v4l2_ext_controls {
union {
__u32 ctrl_class;
--
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
Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
On Sat, Nov 15, 2014 at 6:08 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Andrey, On 11/15/2014 02:48 PM, Andrey Utkin wrote: Thanks to all for the great help so far, but I've got another issue with upstream driver. In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The S_STD ioctl call actually makes difference, because without that the frame slides vertically all the time. But after the call the picture is not correct. That's strange. I know I tested it at the time. I assume it is the PAL standard that isn't working (as opposed to NTSC)? Or does it just always fail when you switch between the two standards? Switching to PAL is not working (NTSC is default). Not sure if it fails to make _any_ switching, or whether it fails to switch between (hardcoded or switched) PAL to NTSC. I can test it a bit later. Such change didn't help: https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4 So, temporarily, I've hardcoded this for exact customer who uses PAL: https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a rmmod/modprobe cycle works fine and doesn't make any difference from reboot, but still it works correctly only with PAL hardcoded for the first-time initialization. Any ideas why wouldn't it work to change the mode after the driver load? Not really. I will have to test this next week (either Monday or Friday) with my solo board. Thanks in advance. Would it be allowed to add back that kernel module parameter (the one passed at module load time)? No. That's a hack, the S_STD call should just work and we need to figure out why it fails. Ok. -- Bluecherry developer. -- 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
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_FIXED0x0001 -/* RGB - next is 0x100e */ +/* RGB - next is 0x1010 */ #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 @@ -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_1X320x100d +#define MEDIA_BUS_FMT_RGB444_1X12 0x100e +#define MEDIA_BUS_FMT_RGB565_1X16 0x100f 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. -- Kind regards, Sakari Ailus sakari.ai...@iki.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: [RFC PATCH 06/11] videodev2.h: add new v4l2_ext_control flags field
Hi,
On Sat, Nov 15, 2014 at 04:18:59PM +0200, Sakari Ailus wrote:
...
union {
__s32 value;
__s64 value64;
@@ -1294,6 +1294,10 @@ struct v4l2_ext_control {
};
} __attribute__ ((packed));
+/* v4l2_ext_control flags */
+#define V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE 0x0001
+#define V4L2_EXT_CTRL_FL_IGN_STORE 0x0002
Do we need both? Aren't these mutually exclusive, and you must have either
to be meaningful in the context of a store?
Ah. Now I think I understand what do these mean. Please ignore my previous
comment.
I might call them differently. What would you think of
V4L2_EXT_CTRL_FL_STORE_IGNORE and V4L2_EXT_CTRL_FL_STORE_ONCE?
V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE is quite long IMO. Up to you.
I wonder if we need EXT in V4L2_EXT_CTRL_FL. It's logical but also
redundant since the old control interface won't have flags either.
I'd assume that for cameras the vast majority of users will always want to
just apply the values once. How are the use cases in video decoding?
--
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
[PATCH 1/3] staging: imx-drm: document internal HDMI I2C master controller DT binding
Provide information about how to bind internal iMX6Q/DL HDMI DDC I2C
master controller. The property is set as optional one, because iMX6
HDMI DDC bus may be represented by one of general purpose I2C busses
found on SoC.
Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: Philipp Zabel p.za...@pengutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: devicet...@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
---
Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
index 1b756cf..43c8924 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
@@ -10,6 +10,8 @@ Required properties:
- #address-cells : should be 1
- #size-cells : should be 0
- compatible : should be fsl,imx6q-hdmi or fsl,imx6dl-hdmi.
+ If internal HDMI DDC I2C master controller is supposed to be used,
+ then simple-bus should be added to compatible value.
- gpr : should be gpr.
The phandle points to the iomuxc-gpr region containing the HDMI
multiplexer control register.
@@ -22,6 +24,7 @@ Required properties:
Optional properties:
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - ddc: internal HDMI DDC I2C master controller
example:
@@ -32,7 +35,7 @@ example:
hdmi: hdmi@012 {
#address-cells = 1;
#size-cells = 0;
-compatible = fsl,imx6q-hdmi;
+compatible = fsl,imx6q-hdmi, simple-bus;
reg = 0x0012 0x9000;
interrupts = 0 115 0x04;
gpr = gpr;
@@ -40,6 +43,11 @@ example:
clock-names = iahb, isfr;
ddc-i2c-bus = i2c2;
+hdmi_ddc: ddc {
+compatible = fsl,imx6q-hdmi-ddc;
+status = disabled;
+};
+
port@0 {
reg = 0;
--
1.7.10.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: bisected: IR press/release behavior changed in 3.17, repeat events
Hi Stephan, C/C linux-media, as this is the right ML for IR discussions. Em Sat, 15 Nov 2014 18:59:05 +0100 Stephan Raue mailingli...@openelec.tv escreveu: Hi with kernel 3.17 using a RC6 remote with a buildin nuvoton IR receiver (not tested others, but i think its a common problem) when pressing/releasing the same button often within 1 second there will no release event sent. Instead we get repeat events. To get the release event i must press the same button with a delay of ~ 1sec. the evtest output for kernel with the difference 3.16 and 3.17 looks like kernel 3.16 Event: time 1415452412.497503, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0 Event: time 1415452412.497503, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452412.497503, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415452412.497503, -- SYN_REPORT Event: time 1415452412.672387, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452412.672387, -- SYN_REPORT Event: time 1415452412.919799, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0 Event: time 1415452412.919799, -- SYN_REPORT Event: time 1415452414.363169, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452414.363169, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415452414.363169, -- SYN_REPORT Event: time 1415452414.538010, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452414.538010, -- SYN_REPORT Event: time 1415452414.621916, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0 Event: time 1415452414.621916, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452414.621916, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415452414.621916, -- SYN_REPORT Event: time 1415452414.818869, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0 Event: time 1415452414.818869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452414.818869, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415452414.818869, -- SYN_REPORT Event: time 1415452414.994902, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0 Event: time 1415452414.994902, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415452414.994902, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415452414.994902, -- SYN_REPORT kernel 3.17 Event: time 1415454057.620687, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454057.620687, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1 Event: time 1415454057.620687, -- SYN_REPORT Event: time 1415454057.795567, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454057.795567, -- SYN_REPORT Event: time 1415454057.896636, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454057.896636, -- SYN_REPORT Event: time 1415454058.056369, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.056369, -- SYN_REPORT Event: time 1415454058.210349, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.210349, -- SYN_REPORT Event: time 1415454058.371157, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.371157, -- SYN_REPORT Event: time 1415454058.540551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.540551, -- SYN_REPORT Event: time 1415454058.622935, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2 Event: time 1415454058.622935, -- SYN_REPORT Event: time 1415454058.696211, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.696211, -- SYN_REPORT Event: time 1415454058.749595, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2 Event: time 1415454058.749595, -- SYN_REPORT Event: time 1415454058.849992, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454058.849992, -- SYN_REPORT Event: time 1415454058.876332, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2 Event: time 1415454058.876332, -- SYN_REPORT Event: time 1415454059.002998, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2 Event: time 1415454059.002998, -- SYN_REPORT Event: time 1415454059.008823, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f041f Event: time 1415454059.008823, -- SYN_REPORT Event: time 1415454059.129614, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2 Event: time 1415454059.129614, -- SYN_REPORT Event: time 1415454059.179093, type 4 (EV_MSC), code
[PATCH] staging: media: bcm2048: fix coding style error
Simple style fix (checkpatch.pl: space prohibited before that ',').
For the eudyptula challenge (http://eudyptula-challenge.org/).
Signed-off-by: Christian F. Resell christian.res...@gmail.com
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { bcm2048 , 0 },
+ { bcm2048, 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
--
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
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.
Thanks,
Konrad
Signed-off-by: Christian F. Resell christian.res...@gmail.com
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { bcm2048 , 0 },
+ { bcm2048, 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
Andrey Utkin andrey.ut...@corp.bluecherry.net writes: In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The S_STD ioctl call actually makes difference, because without that the frame slides vertically all the time. But after the call the picture is not correct. Which kernel version are you using? I remember there were some problems with earlier versions, where the NTSC vs PAL wasn't consistenly a bool but rather a raw register value (or something like this), but it was fixed last time I checked. I'm personally using SOLO6110-based cards with v3.17 and PAL and it works, with minimal unrelated patches. Any ideas why wouldn't it work to change the mode after the driver load? Would it be allowed to add back that kernel module parameter (the one passed at module load time)? I don't think this alone would help. Looking at my patch queue (will try to remember to have them posted)... Well, it could be the SDRAM size detection routine. I'm using cards with 64 MB of RAM and the routine repeatedly detected 128 MB or so (max supported). I have a temporary fix for this but it needs a bit more work, I have seen a case when it failed (I'm using ARM and MIPS platforms and they may differ from x86 in endianness, cache coherency etc). If you have a card with 64 MB RAM you may want to check if the driver detects it correctly, and if not e.g. hardcode the size. Otherwise, I have no idea what could be wrong, it works for me. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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
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?
Pavel
Thanks,
Konrad
Signed-off-by: Christian F. Resell christian.res...@gmail.com
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { bcm2048 , 0 },
+ { bcm2048, 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
(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 PATCH 07/11] v4l2-ctrls: implement 'ignore after use' support.
Hi Hans,
A few comments below.
On Sun, Sep 21, 2014 at 04:48:25PM +0200, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Sometimes you want to apply a value every time v4l2_ctrl_apply_store
is called, and sometimes you want to apply that value only once.
This adds support for that feature.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 75
drivers/media/v4l2-core/v4l2-ioctl.c | 14 +++
include/media/v4l2-ctrls.h | 12 ++
3 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index e5dccf2..21560b0 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1475,6 +1475,7 @@ static int ptr_to_user(struct v4l2_ext_control *c,
static int cur_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
{
+ c-flags = 0;
return ptr_to_user(c, ctrl, ctrl-p_cur);
}
@@ -1482,8 +1483,13 @@ static int cur_to_user(struct v4l2_ext_control *c,
static int store_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl, unsigned store)
{
+ c-flags = 0;
if (store == 0)
return ptr_to_user(c, ctrl, ctrl-p_new);
+ if (test_bit(store - 1, ctrl-cluster[0]-ignore_store_after_use))
+ c-flags |= V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
+ if (test_bit(store - 1, ctrl-cluster[0]-ignore_store))
+ c-flags |= V4L2_EXT_CTRL_FL_IGN_STORE;
return ptr_to_user(c, ctrl, ctrl-p_stores[store - 1]);
}
@@ -1491,6 +1497,7 @@ static int store_to_user(struct v4l2_ext_control *c,
static int new_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
{
+ c-flags = 0;
return ptr_to_user(c, ctrl, ctrl-p_new);
}
@@ -1546,6 +1553,8 @@ static int user_to_ptr(struct v4l2_ext_control *c,
static int user_to_new(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
{
+ ctrl-cluster[0]-new_ignore_store_after_use =
+ c-flags V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
return user_to_ptr(c, ctrl, ctrl-p_new);
}
@@ -1597,8 +1606,11 @@ static void new_to_cur(struct v4l2_fh *fh, struct
v4l2_ctrl *ctrl, u32 ch_flags)
/* Helper function: copy the new control value to the store */
static void new_to_store(struct v4l2_ctrl *ctrl)
{
+ if (ctrl == NULL)
+ return;
+
/* has_changed is set by cluster_changed */
- if (ctrl ctrl-has_changed)
+ if (ctrl-has_changed)
ptr_to_ptr(ctrl, ctrl-p_new, ctrl-p_stores[ctrl-store - 1]);
}
@@ -2328,6 +2340,12 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct
v4l2_ctrl **controls)
for (i = 0; i ncontrols; i++) {
if (controls[i]) {
+ /*
+ * All controls in a cluster must have the same
+ * V4L2_CTRL_FLAG_CAN_STORE flag value.
+ */
+ WARN_ON((controls[0]-flags controls[i]-flags)
+ V4L2_CTRL_FLAG_CAN_STORE);
controls[i]-cluster = controls;
controls[i]-ncontrols = ncontrols;
if (controls[i]-flags V4L2_CTRL_FLAG_VOLATILE)
@@ -2850,6 +2868,10 @@ static int extend_store(struct v4l2_ctrl *ctrl,
unsigned stores)
unsigned s, idx;
union v4l2_ctrl_ptr *p;
+ /* round up to the next multiple of 4 */
+ stores = (stores + 3) ~3;
You said it, round_up(). :-)
The comment becomes redundant as a result, too.
The above may also overflow.
+ if (stores V4L2_CTRLS_MAX_STORES)
+ return -EINVAL;
p = kcalloc(stores, sizeof(union v4l2_ctrl_ptr), GFP_KERNEL);
if (p == NULL)
return -ENOMEM;
@@ -2868,6 +2890,7 @@ static int extend_store(struct v4l2_ctrl *ctrl,
unsigned stores)
memcpy(p, ctrl-p_stores, ctrl-nr_of_stores * sizeof(union
v4l2_ctrl_ptr));
kfree(ctrl-p_stores);
ctrl-p_stores = p;
+ bitmap_set(ctrl-ignore_store, ctrl-nr_of_stores, stores -
ctrl-nr_of_stores);
ctrl-nr_of_stores = stores;
return 0;
}
@@ -3081,21 +3104,33 @@ static int try_or_set_cluster(struct v4l2_fh *fh,
struct v4l2_ctrl *master,
ret = call_op(master, try_ctrl);
- /* Don't set if there is no change */
- if (ret || !set || !cluster_changed(master))
- return ret;
- ret = call_op(master, s_ctrl);
- if (ret)
+ if (ret || !set)
return ret;
- /* If OK, then make the new values permanent. */
- update_flag = is_cur_manual(master) != is_new_manual(master);
- for (i = 0; i master-ncontrols; i++) {
- if (store)
-
Re: [PATCH] staging: media: bcm2048: fix coding style error
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. greg k-h -- 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
On 11/15, 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 think that every contribution, as long as it acctually fixes
something, is worth the patch. The beauty of the open source community
is that we do when we have time as much as we are able to do - totally
no stress.
You, Pavel, are more experienced however those who are not have to learn
somehow and one of the options is to start with something very simple.
Sometimes the 'simple' means oneliner however as long as it compiles, is
inline with the coding standard and in general is an improvement then it
is good.
Regards,
Konrad
Pavel
Thanks,
Konrad
Signed-off-by: Christian F. Resell christian.res...@gmail.com
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct
i2c_client *client)
* bcm2048_i2c_driver - i2c driver interface
*/
static const struct i2c_device_id bcm2048_id[] = {
- { bcm2048 , 0 },
+ { bcm2048, 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, bcm2048_id);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
(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
Nudimo osiguran i unsecured kredita
Nudimo osiguran i unsecured kredita zainteresiranim pojedincima i tvrtkama na niske kamatne stope. dajemo kredite od 20.000 £ na £ 900,000,000 (poslovnih kredita od dvadeset tisuca britanskih funti na 900 milijuna funti) Ako odobriti kredit, sredstva ce biti pohranjena u svoj bankovni racun u roku od 2 radna dana. Za pocetak vašeg zahtjeva za kredit molimo vas da ispunite obrazac u nastavku i vratite nam se Puno ime: Zemlja: Mobitel: Zanimanje: Iznos kredita: Pojam zajma: Trajanje: seks: Email:zenoxfu...@gmail.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
Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
On Sun, Nov 16, 2014 at 12:42 AM, Krzysztof Hałasa khal...@piap.pl wrote: Andrey Utkin andrey.ut...@corp.bluecherry.net writes: In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The S_STD ioctl call actually makes difference, because without that the frame slides vertically all the time. But after the call the picture is not correct. Which kernel version are you using? linux-next from Oct 31 with few my patches which are not in linux-next yet. -- Bluecherry developer. -- 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
kernel panic in DVB code
Hi, I am using DVB on ARM and believe this is a little bit instable. Is this trace of any use to you? Please don't care about this only because of me. It is the first time this occured in 6 weeks, so fixing it is not important to me. I only wanted to report in case it was helpful to anyone for finding bugs in the dvb code. (I know from java the value of real-live stack-traces) It's a self built 3.17.2 kernel with a small patch in the DVB USB buffer size. I can supply the .config or binary if needed. I cannot find any suspect entry in the syslog just before the crash. There are only a few cron entries issuing php scripts. regards, Jan Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948 Internal error: : 409 [#1] ARM Modules linked in: ir_lirc_codec ir_xmp_decoder lirc_dev ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_technisat_usb2 stv6110x usblp dvb_usb_technisat_usb2 dvb_usb dvb_core stv090x rc_core CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.2-rn104-jpt9 #6 task: c08459f0 ti: c0838000 task.ti: c0838000 PC is at crc32_be+0x40/0x168 LR is at 0xc083dff0 pc : [c02fc948]lr : [c083dff0]psr: 2193 sp : c0839d74 ip : 65622065 fp : 0067 r10: e0aef730 r9 : 0049 r8 : e9bf7754 r7 : aa9e5f03 r6 : d98cdd52 r5 : 6965ba03 r4 : c083f9d4 r3 : 6964206e r2 : r1 : e0aef640 r0 : 9e5bff47 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 1de78019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc0838240) Stack: (0xc0839d74 to 0xc083a000) 9d60: e0aef62c e0adf30c 0338 9d80: e0aef62c e0af062c df64f000 bf01dbc8 0397 bf01c7ec 9da0: 0020 c084004c df64f000 0397 0001 e0aef62c e0af062c 0012 9dc0: df414b78 e082a017 df64f000 bf01cef4 91dd391e 1d7d 9de0: c08d2e40 e083aa58 0003 c005541c c08d2f70 df414a78 9e00: 2193 0400 e082a000 00d3 03e9 c084004c df64f000 bf01d14c 9e20: dec2c200 0001 df414ce0 dec2c200 e082a000 c084004c bf03bebc 9e40: dec2c200 6193 dec2c200 df67f000 e09b35d0 c084004c c0401e44 9e60: e09b3640 0001 c042a8d0 c0839ebc c084a6e8 c003df38 9e80: ddeacb40 0040 0200 dee46580 000d 0001 de56e7e0 9ea0: 1f4e00b0 df67f1d4 0004 000d 0d000400 1d81 7074aa2f 9ec0: c0839ec0 df610880 006b 006b df778300 c08813ff 9ee0: c0048f40 c0838000 c004e918 df778300 006b c0839f70 9f00: dfffcc00 c082e350 c0049030 006b c004b1d8 c0838028 006b 9f20: 006b c004886c c085dfac c000f608 0011 0002 c08ddb40 c030bba0 9f40: c08ddb40 03ff c0839f70 c08ddb40 c08813fd c00084f0 c0040a54 6013 9f60: c0839fa4 c08813fd c00126c0 c084a698 c001911c 9f80: c0838000 c08400dc c0838038 c08813fd c08813fd dfffcc00 c082e350 9fa0: 0100 c0839fb8 c000f75c c0040a54 6013 c084 c0805c04 9fc0: c0805610 c082e350 c088ded4 c0840078 9fe0: c082e34c c0846a60 4059 561f5811 8070 [c02fc948] (crc32_be) from [bf01dbc8] (dvb_dmx_crc32+0x10/0x18 [dvb_core]) [bf01dbc8] (dvb_dmx_crc32 [dvb_core]) from [bf01c7ec] (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core]) [bf01c7ec] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from [bf01cef4] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core]) [bf01cef4] (dvb_dmx_swfilter_packet [dvb_core]) from [bf01d14c] (dvb_dmx_swfilter+0xf4/0x164 [dvb_core]) [bf01d14c] (dvb_dmx_swfilter [dvb_core]) from [bf03bebc] (usb_urb_complete+0xbc/0xe4 [dvb_usb]) [bf03bebc] (usb_urb_complete [dvb_usb]) from [c0401e44] (__usb_hcd_giveback_urb+0x5c/0xe8) [c0401e44] (__usb_hcd_giveback_urb) from [c042a8d0] (xhci_irq+0x8d8/0x1e08) [c042a8d0] (xhci_irq) from [c0048f40] (handle_irq_event_percpu+0x78/0x140) [c0048f40] (handle_irq_event_percpu) from [c0049030] (handle_irq_event+0x28/0x38) [c0049030] (handle_irq_event) from [c004b1d8] (handle_simple_irq+0x64/0xa8) [c004b1d8] (handle_simple_irq) from [c004886c] (generic_handle_irq+0x2c/0x3c) [c004886c] (generic_handle_irq) from [c000f608] (handle_IRQ+0x38/0x84) [c000f608] (handle_IRQ) from [c030bba0] (armada_370_xp_handle_msi_irq+0x9c/0xa0) [c030bba0] (armada_370_xp_handle_msi_irq) from [c00084f0] (armada_370_xp_handle_irq+0x5c/0x60) [c00084f0] (armada_370_xp_handle_irq) from [c00126c0] (__irq_svc+0x40/0x54) Exception stack(0xc0839f70 to 0xc0839fb8) 9f60: c084a698 c001911c 9f80: c0838000 c08400dc c0838038 c08813fd c08813fd dfffcc00 c082e350 9fa0: 0100 c0839fb8 c000f75c c0040a54 6013 [c00126c0] (__irq_svc) from [c0040a54] (cpu_startup_entry+0xa8/0xf4) [c0040a54] (cpu_startup_entry) from [c0805c04] (start_kernel+0x3b0/0x3bc) Code:
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Nov 16 04:00:15 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: 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: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: 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: 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: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: 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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
