Re: dvbv5-scan needs which channel file?
Ah, thank you Olli -- much appreciated! If dvbv5-scan expects the initial scan files in the new DVBV5 format, does that mean that these still somewhat mysterious initial scan files have to be supplied, as in the link to the dtv-scan-tables? How are these initial scan files themselves generated? Surely there must be thousands of different dvb signal locations -- is linux-tv going to try to maintain these thousands of scan tables for download? What do users do when their particular location is not represented in the dtv-scan-tables.git? Finally, I'm using gnutv to record television; I imagine it still only accepts the old format? What's the new alternative? Cheers, David On 12/29/14, 11:55 PM, Olli Salonen wrote: Hello David, Coincidentally I was just yesterday working with dvbv5-scan and the initial scan files. dvbv5-scan expects the initial scan files in the new DVBV5 format. w_scan is not producing results in this format. The scan tables at http://git.linuxtv.org/cgit.cgi/dtv-scan-tables.git/ are in the new format. Some of them are a bit outdated though (send in a patch if you can update it for your area). The v4l-utils package also includes tools to convert between the old and the new format. Cheers, -olli On 29 December 2014 at 22:09, David Liontooth lionte...@cogweb.net wrote: Greetings -- How do you actually use dvbv5-scan? It seems to require some kind of input file but there is no man page and the --help screen doesn't say anything about it. Could we document this? I tried $ dvbv5-scan Usage: dvbv5-scan [OPTION...] initial file scan DVB services using the channel file What is the channel file? Maybe the channels.conf file? (I created mine using w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/) $ dvbv5-scan /etc/channels.conf ERROR key/value without a channel group while parsing line 1 of /etc/channels.conf So it knows what it wants -- but what is it? Or is this a matter of dvb versions, and my /etc/channels.conf is in the older format? Very mysterious. Cheers, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v4 2/5] media: ov2640: add async probe function
Hi Laurent, First of all, sorry, I am currently on a holiday, so, replies are delayed, real work (reviewing or anything else) is impossible. On Tue, 30 Dec 2014, Laurent Pinchart wrote: Hi Guennadi, On Friday 26 December 2014 11:38:11 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 14:37:14 Josh Wu wrote: [snip] Talking about mclk and xvclk is quite confusing. There's no mclk from an ov2640 point of view. The ov2640 driver should call v4l2_clk_get(xvclk). Yes, I also was thinking about this, and yes, requesting a xvclk clock would be more logical. But then, as you write below, if we let the v4l2_clk wrapper first check for a CCF xvclk clock, say, none is found. How do we then find the exported mclk V4L2 clock? Maybe v4l2_clk_get() should use two names?.. Given that v4l2_clk_get() is only used by soc-camera drivers and that they all call it with the clock name set to mclk, I wonder whether we couldn't just get rid of struct v4l2_clk.id and ignore the id argument to v4l2_clk_get() when CCF isn't available. Maybe we've overdesigned v4l2_clk :-) Sure, that'd be fine with me, if everyone else agrees. Can you submit a patch ? That's the best way to find out if anyone objects. Can do, sure, once I am back home and find time for this. [snip] v4l2_clk_get() should try to get the clock from CCF with a call to clk_get() first, and then look at the list of v4l2-specific clocks. Yes, how will it find the mclk when xvclk (or any other name) is requested? We did discuss this in the beginning and agreed to use a fixed clock name for the time being... Please see above. That's at least how I had envisioned it when v4l2_clk_get() was introduced. Let's remember that v4l2_clk was designed as a temporary workaround for platforms not implementing CCF yet. Is that still needed, or could be instead just get rid of it now ? I didn't check, but I don't think all platforms, handled by soc-camera, support CCF yet. After a quick check it looks like only OMAP1 and SH Mobile are missing. Atmel, MX2, MX3 and R-Car all support CCF. PXA27x has CCF support but doesn't enable it yet for an unknown (to me) reason. The CEU driver is used on both arch/sh and arch/arm/mach-shmobile. The former will most likely never receive CCF support, and the latter is getting fixed. As arch/sh isn't maintained anymore I would be fine with dropping CEU support for it. OMAP1 is thus the only long-term show-stopper. What should we do with it ? Indeed, what should we? :) You're listed as the soc-camera maintainer, so you should provide an answer to that question :-) Thanks for ar reminder;) I'll propose one, let's drop the omap1-camera driver (I've CC'ed the original author of the driver to this e-mail). Let's see what they reply, but I don't tgink Josh will want to wait that long. And until omap1 is in the mainline we cannot drop v4l2_clk. Thanks Guennadi -- Regards, Laurent Pinchart -- 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 v4 2/5] media: ov2640: add async probe function
Hi Guennadi, On Tuesday 30 December 2014 09:36:31 Guennadi Liakhovetski wrote: Hi Laurent, First of all, sorry, I am currently on a holiday, so, replies are delayed, real work (reviewing or anything else) is impossible. Sure, no worries. Enjoy your holidays without thinking too much about soc- camera :-) On Tue, 30 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 11:38:11 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 14:37:14 Josh Wu wrote: [snip] Talking about mclk and xvclk is quite confusing. There's no mclk from an ov2640 point of view. The ov2640 driver should call v4l2_clk_get(xvclk). Yes, I also was thinking about this, and yes, requesting a xvclk clock would be more logical. But then, as you write below, if we let the v4l2_clk wrapper first check for a CCF xvclk clock, say, none is found. How do we then find the exported mclk V4L2 clock? Maybe v4l2_clk_get() should use two names?.. Given that v4l2_clk_get() is only used by soc-camera drivers and that they all call it with the clock name set to mclk, I wonder whether we couldn't just get rid of struct v4l2_clk.id and ignore the id argument to v4l2_clk_get() when CCF isn't available. Maybe we've overdesigned v4l2_clk :-) Sure, that'd be fine with me, if everyone else agrees. Can you submit a patch ? That's the best way to find out if anyone objects. Can do, sure, once I am back home and find time for this. [snip] v4l2_clk_get() should try to get the clock from CCF with a call to clk_get() first, and then look at the list of v4l2-specific clocks. Yes, how will it find the mclk when xvclk (or any other name) is requested? We did discuss this in the beginning and agreed to use a fixed clock name for the time being... Please see above. That's at least how I had envisioned it when v4l2_clk_get() was introduced. Let's remember that v4l2_clk was designed as a temporary workaround for platforms not implementing CCF yet. Is that still needed, or could be instead just get rid of it now ? I didn't check, but I don't think all platforms, handled by soc-camera, support CCF yet. After a quick check it looks like only OMAP1 and SH Mobile are missing. Atmel, MX2, MX3 and R-Car all support CCF. PXA27x has CCF support but doesn't enable it yet for an unknown (to me) reason. On a side note, patches to enable CCF for PXA27x have been posted, they should be merged in v3.20. The CEU driver is used on both arch/sh and arch/arm/mach-shmobile. The former will most likely never receive CCF support, and the latter is getting fixed. As arch/sh isn't maintained anymore I would be fine with dropping CEU support for it. OMAP1 is thus the only long-term show-stopper. What should we do with it ? Indeed, what should we? :) You're listed as the soc-camera maintainer, so you should provide an answer to that question :-) Thanks for ar reminder;) I'll propose one, let's drop the omap1-camera driver (I've CC'ed the original author of the driver to this e-mail). Let's see what they reply, but I don't tgink Josh will want to wait that long. And until omap1 is in the mainline we cannot drop v4l2_clk. Agreed, this was more of a question for the next step. -- Regards, Laurent Pinchart -- 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_demux.c:dvb_dmx_crc32
Hi, I'm having kernel panics always at this exact location. how can I find the cause? how can I debug? I already enabled DEBUG in kernel config, but haven't tried it yet. this was with self built kernel 3.17.2, find the .config attached. (jpt9 config was same except CONFIG_USB_*HCI_HCD=y) Hardware: Technisat SkyStar USB HD (DVB-S/S2), Netgear ReadyNAS RN104, Marvell Armada 370/XP (ARMv7) Please CC, I'm not subscribed to the list. thanks, Jan [37990.828635] Unable to handle kernel paging request at virtual address 13e09548 [37990.835879] pgd = c0004000 [37990.838590] [13e09548] *pgd= [37990.842185] Internal error: Oops: 815 [#1] ARM [37990.846635] 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 dvb_usb_technisat_usb2 dvb_usb dvb_core stv090x rc_core ehci_orion xhci_hcd ehci_hcd [37990.874197] CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.2-rn104-jpt10 #7 [37990.880996] task: c081f8b0 ti: c0812000 task.ti: c0812000 [37990.886414] PC is at crc32_be+0x40/0x168 [37990.890345] LR is at 0xc0817ff0 [37990.893492] pc : [c02fc948]lr : [c0817ff0]psr: 2193 [37990.893492] sp : c0813d74 ip : 4544384d fp : 00ac [37990.904988] r10: e23a4770 r9 : 0086 r8 : a93252d6 [37990.910221] r7 : 139b5110 r6 : 6c7ae81a r5 : e9279e7d r4 : c0819ab0 [37990.916758] r3 : 31042148 r2 : 0001 r1 : e23a4640 r0 : 4faf1010 [37990.923296] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [37990.930703] Control: 10c5387d Table: 03330019 DAC: 0015 [37990.936457] Process swapper (pid: 0, stack limit = 0xc0812240) [37990.942298] Stack: (0xc0813d74 to 0xc0814000) [37990.946663] 3d60: e23a462c e239430c 0561 [37990.954857] 3d80: e23a462c e23a562c df5aa000 bf05dbc8 05bf bf05c7ec [37990.963050] 3da0: 0020 c081a04c df5aa000 05bf 0001 e23a462c e23a562c 0012 [37990.971243] 3dc0: df414b78 e0830a34 df5aa000 bf05cef4 6c4a7895 228d [37990.979437] 3de0: c08ab040 e0828981 0003 c005541c c08ab170 df414a78 [37990.987631] 3e00: 2193 0400 e0830800 02f0 01cc c081a04c df5aa000 bf05d14c [37990.995824] 3e20: dd9d1a50 0006 df414ce0 dd9d1a00 e082e000 c081a04c bf07bebc [37991.004018] 3e40: dd9d1a00 6193 dd9d1a00 df4af000 e0a4e620 c081a04c c0401e44 [37991.012212] 3e60: e0a4e690 0001 bf02189c c0813ebc c08245a8 c003df38 [37991.020406] 3e80: def903c0 0040 0200 dda1d200 000d 0001 df4b59e0 [37991.028599] 3ea0: 020bf0b0 df4af1d4 0004 000d 0d000800 2291 75429efd [37991.036793] 3ec0: c0813ec0 de098e40 006b 006b defe1300 c085b13f [37991.044987] 3ee0: c0048f40 c0812000 c004e918 defe1300 006b c0813f70 [37991.053180] 3f00: dfffcc00 c08070d0 c0049030 006b c004b1d8 c0812028 006b [37991.061373] 3f20: 006b c004886c c0837e6c c000f608 0011 0002 c08b5d40 c030bba0 [37991.069566] 3f40: c08b5d40 03ff c0813f70 c08b5d40 c085b13d c00084f0 c0040a54 6013 [37991.077760] 3f60: c0813fa4 c085b13d c00126c0 c0824558 c001911c [37991.085952] 3f80: c0812000 c081a0dc c0812038 c085b13d c085b13d dfffcc00 c08070d0 [37991.094146] 3fa0: 0100 c0813fb8 c000f75c c0040a54 6013 c081a000 c07dec04 [37991.102339] 3fc0: c07de610 c08070d0 c08660d4 c081a078 [37991.110532] 3fe0: c08070cc c0820920 4059 561f5811 8070 [37991.118753] [c02fc948] (crc32_be) from [bf05dbc8] (dvb_dmx_crc32+0x10/0x18 [dvb_core]) [37991.127046] [bf05dbc8] (dvb_dmx_crc32 [dvb_core]) from [bf05c7ec] (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core]) [37991.138728] [bf05c7ec] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from [bf05cef4] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core]) [37991.151280] [bf05cef4] (dvb_dmx_swfilter_packet [dvb_core]) from [bf05d14c] (dvb_dmx_swfilter+0xf4/0x164 [dvb_core]) [37991.162179] [bf05d14c] (dvb_dmx_swfilter [dvb_core]) from [bf07bebc] (usb_urb_complete+0xbc/0xe4 [dvb_usb]) [37991.172299] [bf07bebc] (usb_urb_complete [dvb_usb]) from [c0401e44] (__usb_hcd_giveback_urb+0x5c/0xe8) [37991.181997] [c0401e44] (__usb_hcd_giveback_urb) from [bf02189c] (xhci_irq+0x8d8/0x1e08 [xhci_hcd]) [37991.191333] [bf02189c] (xhci_irq [xhci_hcd]) from [c0048f40] (handle_irq_event_percpu+0x78/0x140) [37991.200570] [c0048f40] (handle_irq_event_percpu) from [c0049030] (handle_irq_event+0x28/0x38) [37991.209461] [c0049030] (handle_irq_event) from [c004b1d8] (handle_simple_irq+0x64/0xa8) [37991.217838] [c004b1d8] (handle_simple_irq) from [c004886c] (generic_handle_irq+0x2c/0x3c) [37991.226385] [c004886c] (generic_handle_irq) from [c000f608]
Re: [PATCH v4 2/5] media: ov2640: add async probe function
Hi, Laurent
On 12/30/2014 8:15 AM, Laurent Pinchart wrote:
Hi Josh,
On Monday 29 December 2014 16:28:02 Josh Wu wrote:
On 12/26/2014 6:06 PM, Laurent Pinchart wrote:
On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote:
On Fri, 26 Dec 2014, Laurent Pinchart wrote:
On Friday 26 December 2014 14:37:14 Josh Wu wrote:
On 12/25/2014 6:39 AM, Guennadi Liakhovetski wrote:
On Mon, 22 Dec 2014, Josh Wu wrote:
On 12/20/2014 6:16 AM, Guennadi Liakhovetski wrote:
On Fri, 19 Dec 2014, Josh Wu wrote:
On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
On Thu, 18 Dec 2014, Josh Wu wrote:
To support async probe for ov2640, we need remove the code to get
'mclk' in ov2640_probe() function. oterwise, if soc_camera host
is not probed in the moment, then we will fail to get 'mclk' and
quit the ov2640_probe() function.
So in this patch, we move such 'mclk' getting code to
ov2640_s_power() function. That make ov2640 survive, as we can
pass a NULL (priv-clk) to soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is
called, then we can get the 'mclk' and that make us
enable/disable soc_camera host's clock as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
v3 - v4:
v2 - v3:
v1 - v2:
no changes.
drivers/media/i2c/soc_camera/ov2640.c | 31 ++---
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev
*sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd =
soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv-clk) {
+ clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(clk))
+ dev_warn(client-dev, Cannot get the mclk.
maybe soc-camera host is not probed yet.\n);
+ else
+ priv-clk = clk;
+ }
return soc_camera_set_power(client-dev, ssdd, priv
-clk, on);
}
Just let me explained a little more details at first:
As my understanding, current the priv-clk is a v4l2_clk: mclk, which
is a wrapper clock in soc_camera.c. it can make soc_camera to call
camera host's clock_start() clock_stop(). As in ov2640, the real mck
(pck1) is in ov2640 dt node (xvclk). So the camera host's
clock_start()/stop() only need to enable/disable his peripheral
clock.
I'm looking at the ov2640 datasheet. In the block diagram I only see
one input clock - the xvclk. Yes, it can be supplied by the camera
host controller, in which case it is natural for the camera host
driver to own and control it, or it can be a separate clock device -
either static or configurable. This is just a note to myself to
clarify, that it's one and the same clock pin we're talking about.
Now, from the hardware / DT PoV, I think, the DT should look like:
a) in the ov2640 I2C DT node we should have a clock consumer entry,
linking to a board-specific source.
That's what this patch series do right now.
In my patch 5/5 DT document said, ov2640 need a clock consumer which
refer to the xvclk input clock.
And it is a required property.
b) if the ov2640 clock is supplied by a camera host, its DT entry
should have a clock source subnode, to which ov2640 clock consumer
entry should link. The respective camera host driver should then parse
that clock subnode and register the respective clock with the V4L2
framework, by calling v4l2_clk_register().
Ok, So in this case, I need to wait for the mclk in probe of ov2640
driver. So that I can be compatible for the camera host which provide
the clock source.
Talking about mclk and xvclk is quite confusing. There's no mclk from an
ov2640 point of view. The ov2640 driver should call
v4l2_clk_get(xvclk).
Yes, I also was thinking about this, and yes, requesting a xvclk clock
would be more logical. But then, as you write below, if we let the
v4l2_clk wrapper first check for a CCF xvclk clock, say, none is found.
How do we then find the exported mclk V4L2 clock? Maybe v4l2_clk_get()
should use two names?..
Given that v4l2_clk_get() is only used by soc-camera drivers and that they
all call it with the clock name set to mclk, I wonder whether we
couldn't just get rid of struct v4l2_clk.id and ignore the id argument to
v4l2_clk_get() when CCF isn't available. Maybe we've overdesigned
v4l2_clk :-)
Sorry, I'm not clear about how to implement what you discussed here.
Do you mean, In the ov2640 driver:
1. need to remove the patch 4/5, add a master clock for sensor
No, the sensor has a clock input named xvclk, the ov2640 driver should thus
manage that clock. Patch 4/5 does the right thing.
However, I've just realized that it will cause
Re: [PATCH 09/11 linux-next] [media] uvcvideo: remove unnecessary version.h inclusion
On 30 December 2014 at 00:42 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Fabian, Thank you for the patch. On Monday 29 December 2014 15:29:43 Fabian Frederick wrote: Based on versioncheck. Signed-off-by: Fabian Frederick f...@skynet.be Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Should I take the patch in my tree or do you plan to send a pull request for the whole series elsewhere ? --- drivers/media/usb/uvc/uvc_v4l2.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 9c5cbcf..43e953f 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -13,7 +13,6 @@ #include linux/compat.h #include linux/kernel.h -#include linux/version.h #include linux/list.h #include linux/module.h #include linux/slab.h -- Regards, Laurent Pinchart Hi Laurent, Thanks for the ack, you can take the patch. (Maybe Greg will try later to apply the whole patchset on linux-next. It should not be a problem if some of them are already in.) Regards, Fabian -- 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 v4 2/5] media: ov2640: add async probe function
Hi, Guennadi On 12/30/2014 4:36 PM, Guennadi Liakhovetski wrote: Hi Laurent, First of all, sorry, I am currently on a holiday, so, replies are delayed, real work (reviewing or anything else) is impossible. Thanks for your review in holiday. That's very helpful. On Tue, 30 Dec 2014, Laurent Pinchart wrote: Hi Guennadi, On Friday 26 December 2014 11:38:11 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote: On Fri, 26 Dec 2014, Laurent Pinchart wrote: On Friday 26 December 2014 14:37:14 Josh Wu wrote: [snip] Talking about mclk and xvclk is quite confusing. There's no mclk from an ov2640 point of view. The ov2640 driver should call v4l2_clk_get(xvclk). Yes, I also was thinking about this, and yes, requesting a xvclk clock would be more logical. But then, as you write below, if we let the v4l2_clk wrapper first check for a CCF xvclk clock, say, none is found. How do we then find the exported mclk V4L2 clock? Maybe v4l2_clk_get() should use two names?.. Given that v4l2_clk_get() is only used by soc-camera drivers and that they all call it with the clock name set to mclk, I wonder whether we couldn't just get rid of struct v4l2_clk.id and ignore the id argument to v4l2_clk_get() when CCF isn't available. Maybe we've overdesigned v4l2_clk :-) Sure, that'd be fine with me, if everyone else agrees. Can you submit a patch ? That's the best way to find out if anyone objects. Can do, sure, once I am back home and find time for this. [snip] v4l2_clk_get() should try to get the clock from CCF with a call to clk_get() first, and then look at the list of v4l2-specific clocks. Yes, how will it find the mclk when xvclk (or any other name) is requested? We did discuss this in the beginning and agreed to use a fixed clock name for the time being... Please see above. That's at least how I had envisioned it when v4l2_clk_get() was introduced. Let's remember that v4l2_clk was designed as a temporary workaround for platforms not implementing CCF yet. Is that still needed, or could be instead just get rid of it now ? I didn't check, but I don't think all platforms, handled by soc-camera, support CCF yet. After a quick check it looks like only OMAP1 and SH Mobile are missing. Atmel, MX2, MX3 and R-Car all support CCF. PXA27x has CCF support but doesn't enable it yet for an unknown (to me) reason. The CEU driver is used on both arch/sh and arch/arm/mach-shmobile. The former will most likely never receive CCF support, and the latter is getting fixed. As arch/sh isn't maintained anymore I would be fine with dropping CEU support for it. OMAP1 is thus the only long-term show-stopper. What should we do with it ? Indeed, what should we? :) You're listed as the soc-camera maintainer, so you should provide an answer to that question :-) Thanks for ar reminder;) I'll propose one, let's drop the omap1-camera driver (I've CC'ed the original author of the driver to this e-mail). Let's see what they reply, but I don't tgink Josh will want to wait that long. Thanks. it's indeed true for me. And until omap1 is in the mainline we cannot drop v4l2_clk. So I think the better way right now for ov2640 driver is still request both the v4l2_clock: mclk, and the clock: xvclk in probe(). In that way, we can take our time to introduce other patches to merged these two clocks. Does it make sense? Best Regards, Josh Wu Thanks Guennadi -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] media: ov2640: add async probe function
On Tue, 30 Dec 2014, Josh Wu wrote: [snip] And until omap1 is in the mainline we cannot drop v4l2_clk. s/until/as lonh as/ So I think the better way right now for ov2640 driver is still request both the v4l2_clock: mclk, and the clock: xvclk in probe(). In that way, we can take our time to introduce other patches to merged these two clocks. Does it make sense? How about this sequence, that we cat still try to get in on time for the next merge window: 1. stop using the clock name in v4l2_clk 2. add support for CCF to v4l2_clk, falling back to current behaviour if no clock is found 3. switch ov2640 to using xvclk Otherwise I would propose to add asynchronous probing support to ov2640 _without_ changing the clock name. Whether or not we changee clock's name isn't related directly to async support, since the driver already is using v4l2_clk with the standarf wrong name. So, I would consider these two changes separately - one is a new feature, another is a fix. The only question is in which order to apply them. In general fix-first is preferred, but since in this case the fix requires framework changes, we could go with feature-first. This also makes sense since features need to catch a merge window, whereas a fix can go in later too. So, if we don't manage the above 3-step plan, I would priposw the most primitive patch ro ov2640 just adding async support in line wuth other drivers and without changing the clock name at first. 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: V4L2_CID_AUTO_FOCUS_START VS V4L2_CID_FOCUS_AUTO
Hi Ben, On Fri, Dec 19, 2014 at 11:48:58AM +0800, Bin Chen wrote: Hi, Can anyone explain what is the difference between setting control V4L2_CID_FOCUS_AUTO to 1 and and issuing V4L2_CID_AUTO_FOCUS_START? Confused... V4L2_CID_AUTO_FOCUS_START starts a single-pass AF algorithm which ends after reaching focus (or failing in trying that), whereas enabling the V4L2_CID_FOCUS_AUTO control enables a contiguous AF algorithm. -- 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
How to access DVB-onboard RC? (Technisat)
Hi, I currently try to make my Technisat IR-RC work. But nothing happens when I press a key. What's wrong? I checked the RC using a photo camera: at least it emits IR. triggerhappy config: DAEMON_OPTS=--triggers /etc/triggerhappy/triggers.d/ /dev/input/event0 /dev/input/event1 KEY_1 1 logger thd recieved KEY_1 from Technisat RC KEY_2 1 logger thd recieved KEY_2 from Technisat RC KEY_3 1 logger thd recieved KEY_3 from Technisat RC ... (keys from rc-technisat-usb2.c see syslog below) Triggerhappy works fine with events from event0 but not from event1 $ inputeventdaemon -l /dev/input/event0: name : gpio-keys phys : gpio-keys/input0 features : syn keys /dev/input/event1: name : IR-receiver inside an USB DVB receiver phys : usb-:01:00.0-1/ir0 features : syn keys reserved repeat /dev/input/event2: name : MCE IR Keyboard/Mouse (technisat-usb2) phys : /input0 features : syn keys relative reserved repeat $ lsusb -t ... /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M |__ Port 1: Dev 3, If 0, Class=vend., Driver=dvb_usb_technisat_usb2, 480M syslog: dvb-usb: found a 'Technisat SkyStar USB HD (DVB-S/S2)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Technisat SkyStar USB HD (DVB-S/S2)) dvb-usb: MAC address: x stv6110x_attach: Attaching STV6110x technisat-usb2: i2c-error: 60 = 7 usb 1-1: DVB: registering adapter 0 frontend 0 (Technisat SkyStar USB HD (DVB-S/S2))... Registered IR keymap rc-technisat-usb2 input: IR-receiver inside an USB DVB receiver as /devices/soc/soc:pcie-controller/pci:00/:00:01.0/:01:00.0/usb1/1-1/rc/rc0/input1 evbug: Connected device: input1 (IR-receiver inside an USB DVB receiver at usb-:01:00.0-1/ir0) rc0: IR-receiver inside an USB DVB receiver as /devices/soc/soc:pcie-controller/pci:00/:00:01.0/:01:00.0/usb1/1-1/rc/rc0 IR NEC protocol handler initialized IR RC5(x/sz) protocol handler initialized IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized IR SANYO protocol handler initialized IR Sharp protocol handler initialized dvb-usb: schedule remote query interval to 100 msecs. do I need those protocol handlers? do I need lirc? thanks, Jan -- 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] dvb-core: add template code for i2c binding model
Em Fri, 05 Dec 2014 19:49:33 +0900
tsk...@gmail.com escreveu:
From: Akihiro Tsukada tsk...@gmail.com
Define a standard interface for demod/tuner i2c driver modules.
A module client calls dvb_i2c_attach_{fe,tuner}(),
and a module driver defines struct dvb_i2c_module_param and
calls DEFINE_DVB_I2C_MODULE() macro.
This template provides implicit module requests and ref-counting,
alloc/free's private data structures,
fixes the usage of clientdata of i2c devices,
and defines the platformdata structures for passing around
device specific config/output parameters between drivers and clients.
These kinds of code are common to (almost) all dvb i2c drivers/client,
but they were scattered over adapter modules and demod/tuner modules.
The idea behind this patch is good. I didn't have time yet to test it on a
device that I have currently access.
I have a few comments below, mostly regards with naming convention.
By seeing the patches you converted a few drivers to use this, I'm a little
bit concern about the conversion. We need something that won't be hard to
convert to the new model without requiring to re-test everything.
Anyway, my plan is to take a deeper look on it next week and convert one
or two drivers to use the new I2C binding approach you're proposing.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/dvb-core/Makefile | 4 +
drivers/media/dvb-core/dvb_frontend.h | 1 +
drivers/media/dvb-core/dvb_i2c.c | 219
++
drivers/media/dvb-core/dvb_i2c.h | 110 +
4 files changed, 334 insertions(+)
create mode 100644 drivers/media/dvb-core/dvb_i2c.c
create mode 100644 drivers/media/dvb-core/dvb_i2c.h
diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 8f22bcd..271648d 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -8,4 +8,8 @@ dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o
\
dvb_ca_en50221.o dvb_frontend.o\
$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
+ifneq ($(CONFIG_I2C)$(CONFIG_I2C_MODULE),)
+dvb-core-objs += dvb_i2c.o
+endif
+
obj-$(CONFIG_DVB_CORE) += dvb-core.o
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 816269e..41aae1b 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -415,6 +415,7 @@ struct dtv_frontend_properties {
struct dvb_frontend {
struct dvb_frontend_ops ops;
struct dvb_adapter *dvb;
+ struct i2c_client *fe_cl;
fe_cl doesn't seem to be a good name for something that should be
accessed by all drivers that use it. fe_i2c_client is likely a
better name for it.
void *demodulator_priv;
void *tuner_priv;
void *frontend_priv;
diff --git a/drivers/media/dvb-core/dvb_i2c.c
b/drivers/media/dvb-core/dvb_i2c.c
new file mode 100644
index 000..4ea4e5e
--- /dev/null
+++ b/drivers/media/dvb-core/dvb_i2c.c
@@ -0,0 +1,219 @@
+/*
+ * dvb_i2c.c
+ *
+ * Copyright 2014 Akihiro Tsukada tskd08 AT gmail DOT com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include dvb_i2c.h
+
+static struct i2c_client *
+dvb_i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info *info,
+const unsigned short *probe_addrs)
+{
+ struct i2c_client *cl;
+
+ request_module(I2C_MODULE_PREFIX %s, info-type);
+ /* Create the i2c client */
+ if (info-addr == 0 probe_addrs)
+ cl = i2c_new_probed_device(adap, info, probe_addrs, NULL);
+ else
+ cl = i2c_new_device(adap, info);
+ if (!cl || !cl-dev.driver)
+ return NULL;
+ return cl;
The best would be to also register the device with the media controller,
if CONFIG_MEDIA_CONTROLLER is defined, just like v4l2_i2c_subdev_init()
does.
I would also try to use similar names for the function calls to the ones
that the v4l subsystem uses for subdevices.
+}
+
+struct dvb_frontend *
+dvb_i2c_attach_fe(struct i2c_adapter *adap, const struct i2c_board_info
*info,
+ const void *cfg, void **out)
+{
+ struct i2c_client *cl;
+ struct i2c_board_info bi;
Better to call this as tmp_info, as this seems to be just a temp var.
Re: [RFC PATCH 2/5] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
Hi Ben, On Thu, Dec 18, 2014 at 02:49:33PM +, Ben Hutchings wrote: From: Ian Molton ian.mol...@codethink.co.uk Videobuf2 complains about buffers that are still marked ACTIVE (in use by the driver) following a call to stop_streaming(). This patch returns all active buffers to state ERROR prior to stopping. Note: this introduces a (non fatal) race condition as the stream is not guaranteed to be stopped at this point. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Signed-off-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 773de53..7069176 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -516,8 +516,14 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq) struct soc_camera_host *ici = to_soc_camera_host(icd-parent); struct rcar_vin_priv *priv = ici-priv; struct list_head *buf_head, *tmp; + int i; spin_lock_irq(priv-lock); + + for (i = 0; i vq-num_buffers; ++i) + if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) + vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR); + list_for_each_safe(buf_head, tmp, priv-capture) list_del_init(buf_head); spin_unlock_irq(priv-lock); I'd use the driver's own queued buffer list to access the queued buffers, you alread loop over that just below your own change. -- 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: dvbv5-scan needs which channel file?
Hi David, Well, the initial scan files need to be supplied for dvbv5-scan somehow. The initial scan files that are maintained in the the git repo I posted earlier are updated by users who notice differencies. Basically I and some other users have created scripts that automatically generate the files for my country, so it's rather easy. I don't know how it works for other countries. Anyway, if you prefer to generate the data yourself you can use w_scan to generate it in DVBV3 format: w_scan -ft -c FI -x ~/initial_v3.conf Then use the dvb-format-convert tool that comes in the v4l-utils package: dvb-format-convert -I CHANNEL -O DVBV5 ~/initial_v3.conf ~/initial_data_v5.conf Then you can run dvbv5-scan with this file: dvbv5-scan ~/initial_data_v5.conf Alternatively you can skip the whole conversion phase and run dvbv5-scan with the DVBV3 initial tuning data: dvbv5-scan -I CHANNEL ~/initial_v3.conf Cheers, -olli On 30 December 2014 at 10:23, David Liontooth lionte...@cogweb.net wrote: Ah, thank you Olli -- much appreciated! If dvbv5-scan expects the initial scan files in the new DVBV5 format, does that mean that these still somewhat mysterious initial scan files have to be supplied, as in the link to the dtv-scan-tables? How are these initial scan files themselves generated? Surely there must be thousands of different dvb signal locations -- is linux-tv going to try to maintain these thousands of scan tables for download? What do users do when their particular location is not represented in the dtv-scan-tables.git? Finally, I'm using gnutv to record television; I imagine it still only accepts the old format? What's the new alternative? Cheers, David On 12/29/14, 11:55 PM, Olli Salonen wrote: Hello David, Coincidentally I was just yesterday working with dvbv5-scan and the initial scan files. dvbv5-scan expects the initial scan files in the new DVBV5 format. w_scan is not producing results in this format. The scan tables at http://git.linuxtv.org/cgit.cgi/dtv-scan-tables.git/ are in the new format. Some of them are a bit outdated though (send in a patch if you can update it for your area). The v4l-utils package also includes tools to convert between the old and the new format. Cheers, -olli On 29 December 2014 at 22:09, David Liontooth lionte...@cogweb.net wrote: Greetings -- How do you actually use dvbv5-scan? It seems to require some kind of input file but there is no man page and the --help screen doesn't say anything about it. Could we document this? I tried $ dvbv5-scan Usage: dvbv5-scan [OPTION...] initial file scan DVB services using the channel file What is the channel file? Maybe the channels.conf file? (I created mine using w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/) $ dvbv5-scan /etc/channels.conf ERROR key/value without a channel group while parsing line 1 of /etc/channels.conf So it knows what it wants -- but what is it? Or is this a matter of dvb versions, and my /etc/channels.conf is in the older format? Very mysterious. Cheers, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/6] cec: add new driver for cec support.
On Tue, Dec 23, 2014 at 03:32:17PM +0100, Kamil Debski wrote: +There are still a few todo's, the main one being the remote control support +feature of CEC. I need to research if that should be implemented via the +standard kernel remote control support. I guess a new rc driver type RC_DRIVER_CEC should be introduced (existing types are RC_DRIVER_IR_RAW and RC_DRIVER_SCANCODE). rc_register_device() should not register the sysfs attributes specific for IR, but register sysfs attributes for cec like a link to the device. In addition there should be a new rc_type protocol RC_TYPE_CEC; now rc_keydown_notimeout() can be called for each key press. I guess a new keymap should exist too. HTH Sean -- 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: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
Hi Pavel,
Thanks for the patch! A few comments below.
On Wed, Dec 24, 2014 at 11:34:34PM +0100, Pavel Machek wrote:
We are moving to device tree support on OMAP3, but that currently
breaks ADP1653 driver. This adds device tree support, plus required
documentation.
Signed-off-by: Pavel Machek pa...@ucw.cz
---
Changed -microsec to -us, as requested by devicetree people.
Fixed checkpatch issues.
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 2d88816..2c6c7c5 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -14,6 +14,15 @@ Optional properties for child nodes:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
+- max-microamp : maximum intensity in microamperes of the LED
+ (torch LED for flash devices)
s/torch LED/torch mode/
+- flash-max-microamp : maximum intensity in microamperes of the
+ flash LED; it is mandatory if the LED should
+support the flash mode
+- flash-timeout-microsec : timeout in microseconds after which the flash
+ LED is turned off
These should go to a different patch.
+
+
Examples:
system-status {
@@ -21,3 +30,10 @@ system-status {
linux,default-trigger = heartbeat;
...
};
+
+camera-flash {
+ label = Flash;
+ max-microamp = 5;
+ flash-max-microamp = 32;
+ flash-timeout-microsec = 50;
+}
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..3c7065f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,38 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adp1653
I doubt whether there are going to be more chips supported with the driver.
There hasn't been since the driver was written not I'm aware of one now.
+ - reg: I2C slave address
+
+ - gpios: References to the GPIO that controls the power for the chip.
+
+There are two led outputs available - flash and indicator. One led is
+represented by one child node, nodes need to be named flash and
indicator.
80 characters per line.
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+adp1653: led-controller@30 {
+compatible = adi,adp1653;
+ reg = 0x30;
+gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
Please use tabs for indentation above (and below).
+
+ flash {
+flash-timeout-us = 50;
+flash-max-microamp = 32;
+max-microamp = 5;
+ };
+indicator {
+max-microamp = 17500;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index bc82a12..d04e7cc 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -553,6 +558,22 @@
ti,usb-charger-detection = isp1704;
};
+
+ adp1653: led-controller@30 {
+ compatible = adi,adp1653;
+ reg = 0x30;
+ gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
+
+ flash {
+ flash-timeout-us = 50;
+ flash-max-microamp = 32;
+ max-microamp = 5;
+ };
+
+ indicator {
+ max-microamp = 17500;
+ };
+ };
This should go to a separate patch as well.
};
i2c3 {
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..78341d0 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
Please arrange along with the rest of headers.
+
#define TIMEOUT_MAX 82
#define TIMEOUT_STEP 54600
#define TIMEOUT_MIN (TIMEOUT_MAX -
Re: dvbv5-scan needs which channel file?
OK, perfect; thank you. This should be documented in dvbv5-scan. And we should have a man page for it. Cheers, David On 12/30/14, 5:15 AM, Olli Salonen wrote: Hi David, Well, the initial scan files need to be supplied for dvbv5-scan somehow. The initial scan files that are maintained in the the git repo I posted earlier are updated by users who notice differencies. Basically I and some other users have created scripts that automatically generate the files for my country, so it's rather easy. I don't know how it works for other countries. Anyway, if you prefer to generate the data yourself you can use w_scan to generate it in DVBV3 format: w_scan -ft -c FI -x ~/initial_v3.conf Then use the dvb-format-convert tool that comes in the v4l-utils package: dvb-format-convert -I CHANNEL -O DVBV5 ~/initial_v3.conf ~/initial_data_v5.conf Then you can run dvbv5-scan with this file: dvbv5-scan ~/initial_data_v5.conf Alternatively you can skip the whole conversion phase and run dvbv5-scan with the DVBV3 initial tuning data: dvbv5-scan -I CHANNEL ~/initial_v3.conf Cheers, -olli On 30 December 2014 at 10:23, David Liontooth lionte...@cogweb.net wrote: Ah, thank you Olli -- much appreciated! If dvbv5-scan expects the initial scan files in the new DVBV5 format, does that mean that these still somewhat mysterious initial scan files have to be supplied, as in the link to the dtv-scan-tables? How are these initial scan files themselves generated? Surely there must be thousands of different dvb signal locations -- is linux-tv going to try to maintain these thousands of scan tables for download? What do users do when their particular location is not represented in the dtv-scan-tables.git? Finally, I'm using gnutv to record television; I imagine it still only accepts the old format? What's the new alternative? Cheers, David On 12/29/14, 11:55 PM, Olli Salonen wrote: Hello David, Coincidentally I was just yesterday working with dvbv5-scan and the initial scan files. dvbv5-scan expects the initial scan files in the new DVBV5 format. w_scan is not producing results in this format. The scan tables at http://git.linuxtv.org/cgit.cgi/dtv-scan-tables.git/ are in the new format. Some of them are a bit outdated though (send in a patch if you can update it for your area). The v4l-utils package also includes tools to convert between the old and the new format. Cheers, -olli On 29 December 2014 at 22:09, David Liontooth lionte...@cogweb.net wrote: Greetings -- How do you actually use dvbv5-scan? It seems to require some kind of input file but there is no man page and the --help screen doesn't say anything about it. Could we document this? I tried $ dvbv5-scan Usage: dvbv5-scan [OPTION...] initial file scan DVB services using the channel file What is the channel file? Maybe the channels.conf file? (I created mine using w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/) $ dvbv5-scan /etc/channels.conf ERROR key/value without a channel group while parsing line 1 of /etc/channels.conf So it knows what it wants -- but what is it? Or is this a matter of dvb versions, and my /etc/channels.conf is in the older format? Very mysterious. Cheers, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] dvb-core: add template code for i2c binding model
Em Tue, 30 Dec 2014 11:10:51 -0200
Mauro Carvalho Chehab mche...@osg.samsung.com escreveu:
Em Fri, 05 Dec 2014 19:49:33 +0900
tsk...@gmail.com escreveu:
From: Akihiro Tsukada tsk...@gmail.com
Define a standard interface for demod/tuner i2c driver modules.
A module client calls dvb_i2c_attach_{fe,tuner}(),
and a module driver defines struct dvb_i2c_module_param and
calls DEFINE_DVB_I2C_MODULE() macro.
This template provides implicit module requests and ref-counting,
alloc/free's private data structures,
fixes the usage of clientdata of i2c devices,
and defines the platformdata structures for passing around
device specific config/output parameters between drivers and clients.
These kinds of code are common to (almost) all dvb i2c drivers/client,
but they were scattered over adapter modules and demod/tuner modules.
The idea behind this patch is good. I didn't have time yet to test it on a
device that I have currently access.
I have a few comments below, mostly regards with naming convention.
By seeing the patches you converted a few drivers to use this, I'm a little
bit concern about the conversion. We need something that won't be hard to
convert to the new model without requiring to re-test everything.
Anyway, my plan is to take a deeper look on it next week and convert one
or two drivers to use the new I2C binding approach you're proposing.
Ok, did some tests and it worked. The issues I commented on my last email
may be fixed latter. I'm working on adding media controller support for
it.
The only thing I noticed is that it is causing some warnings at
dmesg about trying to create already created sysfs nodes, when the
driver is removed/reinserted.
Probably, the remove callback is called too soon or too late.
I'll do more tests latter (either this or the next week).
I used the enclosed patch on my tests.
Regards,
Mauro
[PATCH] mb86a20s: convert it to I2C binding model
Instead of using I2C raw API, use the standard I2C binding API,
with the DVB core support for it.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 8f54c39..8dd608b 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -18,6 +18,7 @@
#include asm/div64.h
#include dvb_frontend.h
+#include dvb_i2c.h
#include mb86a20s.h
#define NUM_LAYERS 3
@@ -35,12 +36,10 @@ static u8 mb86a20s_subchannel[] = {
};
struct mb86a20s_state {
- struct i2c_adapter *i2c;
+ struct i2c_client *i2c;
const struct mb86a20s_config *config;
u32 last_frequency;
- struct dvb_frontend frontend;
-
u32 if_freq;
enum mb86a20s_bandwidth bw;
bool inversion;
@@ -234,7 +233,7 @@ static int mb86a20s_i2c_writereg(struct mb86a20s_state
*state,
};
int rc;
- rc = i2c_transfer(state-i2c, msg, 1);
+ rc = i2c_transfer(state-i2c-adapter, msg, 1);
if (rc != 1) {
dev_err(state-i2c-dev,
%s: writereg error (rc == %i, reg == 0x%02x, data ==
0x%02x)\n,
@@ -269,7 +268,7 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state
*state,
{ .addr = i2c_addr, .flags = I2C_M_RD, .buf = val, .len = 1 }
};
- rc = i2c_transfer(state-i2c, msg, 2);
+ rc = i2c_transfer(state-i2c-adapter, msg, 2);
if (rc != 2) {
dev_err(state-i2c-dev, %s: reg=0x%x (error=%d)\n,
@@ -281,11 +280,11 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state
*state,
}
#define mb86a20s_readreg(state, reg) \
- mb86a20s_i2c_readreg(state, state-config-demod_address, reg)
+ mb86a20s_i2c_readreg(state, state-i2c-addr, reg)
#define mb86a20s_writereg(state, reg, val) \
- mb86a20s_i2c_writereg(state, state-config-demod_address, reg, val)
+ mb86a20s_i2c_writereg(state, state-i2c-addr, reg, val)
#define mb86a20s_writeregdata(state, regdata) \
- mb86a20s_i2c_writeregdata(state, state-config-demod_address, \
+ mb86a20s_i2c_writeregdata(state, state-i2c-addr, \
regdata, ARRAY_SIZE(regdata))
/*
@@ -2058,41 +2057,34 @@ static int mb86a20s_tune(struct dvb_frontend *fe,
return rc;
}
-static void mb86a20s_release(struct dvb_frontend *fe)
+static int mb86a20s_remove(struct i2c_client *i2c)
{
- struct mb86a20s_state *state = fe-demodulator_priv;
-
- dev_dbg(state-i2c-dev, %s called.\n, __func__);
+ dev_dbg(i2c-dev, %s called.\n, __func__);
- kfree(state);
+ return 0;
}
static struct dvb_frontend_ops mb86a20s_ops;
-struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
- struct i2c_adapter *i2c)
+static int mb86a20s_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
{
+ struct dvb_frontend *fe;
struct mb86a20s_state *state;
Re: mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi Adding the maintainers for drivers/media/rc/rc-main.c into the loop. This is a follow-up for: http://lkml.kernel.org/r/201412181916.18051.s@gmx.de On Thursday 18 December 2014, Stefan Lippers-Hollmann wrote: Occassionally, but not readily reproducably, I hit a race condition between mceusb and other connected RC_CORE devices when mceusb tries to create /class/rc/rc0, which is -by then- already taken by another RC_CORE device. The other involved IR devices (physically only one) are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't actually supposed to receive IR signals (IR receiver not connected): mceusb device transceiver: Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared Receiver DVB-T receiver (no RC_CORE device) Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE (Version 2, AF9015) twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR receiver (NEC protocol), logically recognized as two RC_CORE devices): [...] Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Today I got a new, similar, trace with kernel 3.18.1, but this is not a regression and randomly happens with older kernels as well. The frequency of this occuring differs vastly, this time it was 12 days with probably 20 (re-)boots, before that it didn't happen for multiple weeks. I can not totally rule out if it ever happened in the reverse detection/ initialisation order, as I wouldn't notice the consequences of dvb_usb_dw2102's RC_CORE devices failing to initialise, but I think the problem might be seated in the common core of rc-main.c. usb 1-1.5: New USB device found, idVendor=0ccd, idProduct=0069 usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.5: Product: Cinergy T USB XE Ver.2 usb 1-1.5: Manufacturer: TerraTec usb 1-1.5: SerialNumber: 10012007 [...] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in cold state usb 1-1.5: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9015.fw' [...] usb 2-1.6: New USB device found, idVendor=0609, idProduct=0334 usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.6: Product: MCE TRANCEIVR Emulator Device 2006 usb 2-1.6: Manufacturer: SMK CORPORATION usb 2-1.6: SerialNumber: PA070620045513C [...] usb 3-1: USB disconnect, device number 2 usb 2-1.8: new full-speed USB device number 5 using ehci-pci usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in warm state [...] dvb-usb: found a 'TeVii S480.1 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S480.1 USB) dvb-usb: MAC address: 70:70:70:70:70:70 Invalid probe, probably not a DS3000 dvb-usb: no frontend was attached by 'TeVii S480.1 USB' [...] Registered IR keymap rc-tevii-nec input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0/input18 rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1c.5/:04:00.1/usb3/3-1/rc/rc0 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S480.1 USB successfully initialized and connected. dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware [...] Registered IR keymap rc-rc6-mce [ cut here ] WARNING: CPU: 1 PID: 311 at /tmp/buildd/linux-aptosid-3.18/fs/sysfs/dir.c:31 sysfs_warn_dup+0x55/0x70() sysfs: cannot create duplicate filename '/class/rc/rc0' Modules linked in: rt2800usb(+) rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 crc_ccitt rc_rc6_mce mceusb(+) rc_tevii_nec ds3000 nls_utf8 nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi intel_rapl sparse_keymap rfkill x86_pkg_temp_thermal evdev intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper dvb_usb_af9015(+) cryptd dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb dvb_core rc_core psmouse snd_hda_intel pcspkr snd_hda_controller serio_raw i2c_i801 snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore lpc_ich mfd_core battery tpm_infineon i915 video i2c_algo_bit drm_kms_helper drm i2c_core intel_gtt ie31200_edac mei_me edac_core mei wmi button processor nct6775 hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sg sd_mod ohci_pci crc32c_intel ahci libahci libata scsi_mod xhci_pci ohci_hcd ehci_pci xhci_hcd ehci_hcd r8169 mii usbcore usb_common fan thermal CPU: 1 PID: 311
Re: [PATCH/RFC v9 07/19] dt-binding: mfd: max77693: Add DT binding related macros
Hi Jacek, The driver depends on these so I'd rearrange this patch in the set before the driver patch. On Wed, Dec 03, 2014 at 05:06:42PM +0100, Jacek Anaszewski wrote: Add macros for max77693 led part related binding. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Cc: Chanwoo Choi cw00.c...@samsung.com --- include/dt-bindings/mfd/max77693.h | 38 1 file changed, 38 insertions(+) create mode 100644 include/dt-bindings/mfd/max77693.h diff --git a/include/dt-bindings/mfd/max77693.h b/include/dt-bindings/mfd/max77693.h new file mode 100644 index 000..4011cb47 --- /dev/null +++ b/include/dt-bindings/mfd/max77693.h @@ -0,0 +1,38 @@ +/* + * This header provides macros for MAX77693 device binding + * + * Copyright (C) 2014, Samsung Electronics Co., Ltd. + * + * Author: Jacek Anaszewski j.anaszew...@samsung.com + */ + +#ifndef __DT_BINDINGS_MAX77693_H__ +#define __DT_BINDINGS_MAX77693_H + +/* External control pins */ +#define MAX77693_LED_FLED_UNUSED 0 +#define MAX77693_LED_FLED_USED 1 + +/* FLED pins */ +#define MAX77693_LED_FLED1 1 +#define MAX77693_LED_FLED2 2 I'd personally simply use numbers for the above but I can't really say to be an expert on the topic. +/* External trigger type */ +#define MAX77693_LED_TRIG_TYPE_EDGE 0 +#define MAX77693_LED_TRIG_TYPE_LEVEL 1 + +/* Trigger flags */ +#define MAX77693_LED_TRIG_FLASHEN(1 0) +#define MAX77693_LED_TRIG_TORCHEN(1 1) +#define MAX77693_LED_TRIG_SOFTWARE (1 2) + +#define MAX77693_LED_TRIG_ALL(MAX77693_LED_TRIG_FLASHEN | \ + MAX77693_LED_TRIG_TORCHEN | \ + MAX77693_LED_TRIG_SOFTWARE) + +/* Boost modes */ +#define MAX77693_LED_BOOST_OFF 0 +#define MAX77693_LED_BOOST_ADAPTIVE 1 +#define MAX77693_LED_BOOST_FIXED 2 + +#endif /* __DT_BINDINGS_MAX77693_H */ -- 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][PATCH] mn88472: add support for the mn88473 demod
On 12/21/2014 10:21 AM, Antti Palosaari wrote: Moikka! [...] You patch looks rather good and these drivers should be merged to one if possible, lets say registers are 80% same or something like that. Looks like those are. I've dropped this effort, the chips registers are not similar enough. The code that could be shared is not enough to give any advantage over 2 drivers. 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
[PATCH] media: au0828 analog_register error path fixes to do proper cleanup
au0828_analog_register() doesn't release video and vbi queues created by vb2_queue_init(). In addition, it doesn't unregister vdev when vbi register fails. Add vb2_queue_release() calls to release video and vbi queues to the failure path to be called when vdev register fails. Add video_unregister_device() for vdev when vbi register fails. Signed-off-by: Shuah Khan shua...@osg.samsung.com --- Please note that this patch is dependent on the au0828 vb2 conversion patch. drivers/media/usb/au0828/au0828-video.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index 94b65b8..17450eb 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -1785,7 +1785,7 @@ int au0828_analog_register(struct au0828_dev *dev, dprintk(1, unable to register video device (error = %d).\n, retval); ret = -ENODEV; - goto err_vbi_dev; + goto err_reg_vdev; } /* Register the vbi device */ @@ -1795,14 +1795,18 @@ int au0828_analog_register(struct au0828_dev *dev, dprintk(1, unable to register vbi device (error = %d).\n, retval); ret = -ENODEV; - goto err_vbi_dev; + goto err_reg_vbi_dev; } - dprintk(1, %s completed!\n, __func__); return 0; +err_reg_vbi_dev: + video_unregister_device(dev-vdev); +err_reg_vdev: + vb2_queue_release(dev-vb_vidq); + vb2_queue_release(dev-vb_vbiq); err_vbi_dev: video_device_release(dev-vbi_dev); err_vdev: -- 2.1.0 -- 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: dvbv5-scan needs which channel file?
Hi David, Em Tue, 30 Dec 2014 07:49:05 -0800 David Liontooth lionte...@cogweb.net escreveu: OK, perfect; thank you. This should be documented in dvbv5-scan. And we should have a man page for it. This is documented, and there is a man page for it: dvbv5-scan(1)User Commands dvbv5-scan(1) NAME dvbv5-scan - DVBv5 tool for frequency scanning SYNOPSIS dvbv5-scan [OPTION]... initial-file DESCRIPTION dvbv5-scan is a command line frequency scanning tool for digital TV services that is compliant with version 5 of the DVB API, and backward compatible with the older v3 DVB API. dvbv5-scan uses by default the new channel/service file format that it is capable of supporting all types of Digital TV standards. It can also support the legacy format used by the legacy dvb-apps. A single physical channel (also called as transponder) may have several virtual channels inside it, encapsulated via a MPEG Transport stream. Those virtual channels are called as 'service' at the MPEG-TS terminol‐ ogy, and may have one or more audio, video and other types of elements inside it. The dvbv5-scan goal is to scan for a list of physical chan‐ nels/transponders and identify there the MPEG-TS services available. The dvbv5-scan tool is smart enough to retrieve the information at the MPEG-TS Network Information Table (NIT) about other channels available on the stream. OPTIONS The following options are valid: -3, --dvbv3 Force dvbv5-scan to use DVBv3 only. -a, --adapter=adapter# Use the given adapter. Default value: 0. -d, --demux=demux# Use the given demux. Default value: 0. -f, --frontend=frontend# Use the given frontend. Default value: 0. -F, --file-freqs-only Don't use the other frequencies discovered during scan. By default, dvbv5-scan will find new transponder/physical channels and add them at the internal frequency table it uses for scan. This option disables such feature. -G, --get_frontend Use data from get_frontend on the output file. By default, dvbv5-scan will repeat the same network parameters as found at the scan file. This should work fine if the output file will be used by the same frontend. However, if you intend to use the generated file on another frontend, or wants a faster tuner, this option can be used to store the actual detected parameters, instead of the ones that came from the source channel file. -I, --input-format=format Format of the input file. Please notice that caps is ignored. It can be: channel - for dvb-apps compatible channel file; zap - for dvb-apps compatible zap file; dvbv5 (default) - for the dvbv5 apps format. -l, --lnbf=LNBf_type Type of LNBf to use 'help' lists the available ones. -N, --nit Use data from NIT table on the output file. By default, dvbv5-scan will repeat the same network parameters as found at the scan file. This should work fine if the output file will be used by the same frontend. However, if you intend to use the generated file on another frontend, or wants a faster tuner, this option can be used to store the parameters that are announced by the broadcaster via the MPEG-TS Network Information Table (NIT), instead of the ones that came from the source chan‐ nel file. -o, --output=file output filename (default: dvb_channel.conf) -O, --output-format=format Output format: channel - for dvb-apps compatible channel file; zap - for dvb-apps compatible zap file; vdr - for vdr compatible zap file; dvbv5 (default) - for the dvbv5 apps format. -p, --parse-other-nit Parse the other NIT/SDT tables that could be found mainly on some DVB-C carriers. -S, --sat_number=satellite_number Satellite number. Used only on satellite delivery systems. If not specified, disable DISEqC satellite switch. -T, --timeout-multiply=factor Multiply the scan lock wait time and MPEG-TS table parsing by this factor. -U, --freq_bpf=frequency SCR/Unicable band-pass filter frequency to use, in kHz. Used only on satellite delivery systems. -v, --verbose
Re: dvbv5-scan needs which channel file?
Em Wed, 31 Dec 2014 00:11:34 -0200 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu: Hi David, Em Tue, 30 Dec 2014 07:49:05 -0800 David Liontooth lionte...@cogweb.net escreveu: OK, perfect; thank you. This should be documented in dvbv5-scan. And we should have a man page for it. This is documented, and there is a man page for it: dvbv5-scan(1)User Commands dvbv5-scan(1) ... Forgot to mention, but, of course, if you think that the information there is not enough, feel free to submit patches to improve it ;) The documentation source file is at: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/dvb/dvbv5-scan.1.in Also, translations for other languages is also welcomed. -- Cheers, 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
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: Wed Dec 31 04:00:09 CET 2014 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.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: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-i686: 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: 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: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
