Re: [PATCH/RFC v10 02/19] Documentation: leds: Add description of LED Flash class extension
Hi Pavel, Thanks for the review. On 01/09/2015 06:40 PM, Pavel Machek wrote: Hi! The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register function to gain flash +related capabilities. + +There are flash LED devices which can control more than one LED and allow for +strobing the sub-leds synchronously. A LED will be strobed synchronously with +the one whose identifier is written to the flash_sync_strobe sysfs attribute. +The list of available sub-led identifiers can be read from the sub-LED? Indeed, this naming will be more consistent. + - flash_fault - bitmask of flash faults that may have occurred + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x20 - the flash controller has detected a short or open +circuit condition on the indicator LED + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit Did not everyone agree that text strings are preferable to bitmasks? Pavel I just forgot to update the flash_fault documentation. Will fix in the next version. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 08/19] leds: Add support for max77693 mfd flash cell
Hi Pavel,
Thanks for the review.
On 01/09/2015 07:46 PM, Pavel Machek wrote:
On Fri 2015-01-09 16:22:58, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
+struct max77693_sub_led {
+ /* related FLED output identifier */
-flash LED, about 4x.
+/* split composite current @i into two @iout according to @imax weights */
+static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2])
+{
+ u64 t = i;
+
+ t *= imax[1];
+ do_div(t, imax[0] + imax[1]);
+
+ iout[1] = (u32)t / FLASH_IOUT_STEP * FLASH_IOUT_STEP;
+ iout[0] = i - iout[1];
+}
Is 64-bit arithmetics neccessary here? Could we do the FLASH_IOUT_STEP
divisons before t *=, so that 64-bit division is not neccessary?
It is required. All these operations allow for splitting the composite
current into both outputs according to weights given in the imax array.
+static int max77693_led_flash_strobe_get(
+ struct led_classdev_flash *fled_cdev,
+ bool *state)
+{
+ struct max77693_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
+ struct max77693_led_device *led = sub_led_to_led(sub_led);
+ int ret;
+
+ if (!state)
+ return -EINVAL;
+
+ mutex_lock(led-lock);
+
+ ret = max77693_strobe_status_get(led, state);
+
+ *state = !!(*state (led-strobing_sub_led_id == sub_led-fled_id));
+
+
+ mutex_unlock(led-lock);
+
+ return ret;
+}
Maybe remove some empty lines?
Of course.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] V4L: remove clock name from v4l2_clk API
Hi, Guennadi and Laurent On 1/9/2015 6:47 AM, Laurent Pinchart wrote: Hi Guennadi and Josh, On Thursday 08 January 2015 23:37:58 Guennadi Liakhovetski wrote: On Wed, 7 Jan 2015, Josh Wu wrote: On 1/7/2015 6:17 AM, Guennadi Liakhovetski wrote: On Tue, 6 Jan 2015, Josh Wu wrote: Hi, Guennadi After look deep into this patch, I found you miss one line that should be changed as well. It's In function v4l2_clk_get(), there still has one line code called v4l2_clk_find(dev_id, id). You need to change it to v4l2_clk_find(dev_id, NULL) as well. Otherwise the code that many sensor used: v4l2_clk_get(client-dev, mclk) cannot acquired the mclk clock. After above changes, this patch works for me. I think you're right, in fact, since we now don't store CCF-based v4l2_clk wrappers on the list, this can be simplified even further, I'll update the patch. Did you only test this patch or both? I tested both patches with Atmel-isi driver. For the 2/2 patch I applied the modification Laurent suggested. Those patches works for me. The only concern is in ov2640 I still need to acquired two v4l2 clocks: xvclk that will get the xvclk CCF clock directly. mclk that make ISI driver call his clock_start()/stop() to enable/disable ISI's peripheral clock. If I only get xvclk clock, then the camera capture will be failed with a ISI timeout error. No, this doesn't look right to me. The camera sensor has only one clock input, so, it should only request one clock. Where does the clock signal to the camera come from on your system? That's correct, the sensor driver only has one clock input, so it should just request the xvclk clock. If it comes from the ISI itself, you don't need to specify the clock in the DT, since the ISI doesn't produce a clock from DT. If you do want to have your clock consumer (ov2640) and the supplier (ISI) properly described in DT, you'll have to teach the ISI to register a CCF clock source, which then will be connected to from the ov2640. If you choose not to show your clock in the DT, you can just use v4l2_clk_get(dev, xvclk) and it will be handled by v4l2_clk / soc-camera / isi-atmel. If the closk to ov2640 is supplied by a separate clock source, then you v4l2_clk_get() will connect ov2640 to it directly and soc-camera will enable and disable it on power-on / -off as required. The ISI has no way to supply a sensor clock, the clock is supplied by a separate clock source. From your above description it looks like the clock to ov2640 is supplied by a separate source, but atmel-isi's .clock_start() / .clock_stop() functions still need to be called? By looking at those functions it looks like they turn on and off clocks, supplying the ISI itself... Instead of only turning on and off clocks, provided by the ISI to a camera sensor. If my understanding is right, then this is a bug in atmel-isi and it has to be fixed. That's correct as well, the ISI driver needs to be fixed. Thanks both of you for the details. Now I got it. Indeed, I need fix this in atmel-isi driver not in ov2640 driver. So I will send a new patch for this, which should move the ISI peripheral clock enable/disable() from clock_start/stop() to isi_camera_add_device/remove_device(). Best Regards, Josh Wu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On 01/09/2015 07:33 PM, Rob Herring wrote:
On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
Add a property for defining the device outputs the LED
represented by the DT child node is connected to.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
---
Documentation/devicetree/bindings/leds/common.txt |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index a2c3f7a..29295bf 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -1,6 +1,10 @@
Common leds properties.
Optional properties for child nodes:
+- led-sources : Array of bits signifying the LED current regulator outputs the
+ LED represented by the child node is connected to (1 - the LED
+ is connected to the output, 0 - the LED isn't connected to the
+ output).
Sorry, I just don't understand this.
In some Flash LED devices one LED can be connected to one or more
electric current outputs, which allows for multiplying the maximum
current allowed for the LED. Each sub-LED is represented by a child
node in the DT binding of the Flash LED device and it needs to declare
which outputs it is connected to. In the example below the led-sources
property is a two element array, which means that the flash LED device
has two current outputs, and the bits signify if the LED is connected
to the output.
Do your doubts stem from the ambiguity of the word current or the
form of the description itself is unclear? Probably there should be
explicit explanation added that the size of the array depends on the
number of current outputs of the flash LED device.
- label : The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
@@ -33,6 +37,7 @@ system-status {
camera-flash {
label = Flash;
+ led-sources = 1 0;
max-microamp = 5;
flash-max-microamp = 32;
flash-timeout-us = 50;
--
1.7.9.5
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 15/19] media: Add registration helpers for V4L2 flash sub-devices
Hi Pavel,
Thanks for the review.
On 01/09/2015 09:54 PM, Pavel Machek wrote:
On Fri 2015-01-09 16:23:05, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pavel Machek pa...@ucw.cz
+ /*
+* Indicator leds, unlike torch leds, are turned on/off basing
on
leds - LEDs.
Sure.
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Therefore it must be possible to set it to 0 level which in
+* the LED subsystem reflects LED_OFF state.
+*/
+ if (cdata_id != INDICATOR_INTENSITY)
+ ++__intensity;
And normally we'd do i++ instead of ++i, and avoid __ for local
variables...?
Pre-incrementation operator is favourable over the post-incrementation
one if we don't want to have an access to the value of a variable before
incrementation, which is the case here.
Maybe gcc detects the cases when the value of a variable is not assigned
and doesn't copy it before incrementing, however I haven't found any
reference. I see that often in the for loops the i++ version
is used, but I am not sure if this is done because developers are
aware that gcc will optimize it anyway or it is just an omission.
And regarding __ for local variable - I haven't found any restriction
about it in the Documentation/CodingStyle. Nevertheless I can rename
it to tmp or something.
+/**
+ * struct v4l2_flash_ctrl_config - V4L2 Flash controls initialization data
+ * @intensity: constraints for the led in a non-flash mode
+ * @flash_intensity: V4L2_CID_FLASH_INTENSITY settings constraints
+ * @flash_timeout: V4L2_CID_FLASH_TIMEOUT constraints
+ * @flash_faults: possible flash faults
+ * @has_external_strobe: external strobe capability
+ * @indicator_led: signifies that a led is of indicator type
+ */
+struct v4l2_flash_ctrl_config {
+ struct v4l2_ctrl_config intensity;
+ struct v4l2_ctrl_config flash_intensity;
+ struct v4l2_ctrl_config flash_timeout;
+ u32 flash_faults;
+ bool has_external_strobe:1;
+ bool indicator_led:1;
+};
I don't think you are supposed to do boolean bit arrays.
These bit fields allow to reduce memory usage. If they were not bit
fields, the address of the next variable would be aligned to the
multiply of the CPU word size.
Please look e.g. at struct dev_pm_info in the file include/linux/pm.h.
It also contains boolean bit fields.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 01/11/2015 10:33 AM, Raimonds Cicans wrote: Hello. I contacted you because I am hit by regression caused by your commit: 453afdd [media] cx23885: convert to vb2 My system: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver) After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: This makes no sense. The cx23885 driver in 3.17.7 doesn't use vb2. Are you using the media_build repo perhaps to install the latest media drivers on a 3.17 kernel? 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card sometimes this message was followed by storm of following messages: cx23885[0]: mpeg risc op code error This looks awfully like the bug that is fixed in commit 7675fe99d280ea83388a4382c54573c80db37cda. ... 2) [ cut here ] WARNING: CPU: 1 PID: 6946 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x55/0x72() Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx24117 cx25840 snd_usb_audio snd_hwdep snd_usbmidi_lib uvcvideo snd_rawmidi videobuf2_vmalloc snd_hda_codec_hdmi ir_xmp_decoder ir_lirc_codec 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_rc6_mce microcode k10temp mceusb cx23885 tda18271 altera_stapl videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops tveeprom cx2341x rc_core v4l2_common videodev si2157 si2168 saa716x_budget saa716x_core dvb_core nouveau i2c_algo_bit ttm snd_hda_intel drm_kms_helper snd_hda_controller sp5100_tco r8169 i2c_piix4 snd_hda_codec drm mii CPU: 1 PID: 6946 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc01 #1 Hmm, and this says 3.19-rc3. I really need to know what kernel and media drivers you are using! Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 0009 b0640fe8 b00bcf46 00d27000 b04eb2a0 00d46000 00d27000 8800b8287938 0001 01f8 Call Trace: [b0640fe8] ? dump_stack+0x40/0x50 [b00bcf46] ? warn_slowpath_common+0x93/0xab [b04eb2a0] ? dma_ops_domain_unmap.part.12+0x55/0x72 [b04eb2a0] ? dma_ops_domain_unmap.part.12+0x55/0x72 [b04ecc8c] ? __unmap_single.isra.15+0x7b/0xcf [b04ed43a] ? free_coherent+0x46/0x7e [c05b064f] ? __vb2_queue_cancel+0x1b8/0x1d6 [videobuf2_core] [c05b22e1] ? __reqbufs+0x15b/0x334 [videobuf2_core] [c05b2647] ? vb2_thread_stop+0x100/0x146 [videobuf2_core] [c05bc0ce] ? vb2_dvb_stop_feed+0x41/0x58 [videobuf2_dvb] [c052b4ea] ? dvb_dmxdev_filter_start+0x35/0x301 [dvb_core] [c052d12f] ? dmx_section_feed_stop_filtering+0x40/0x7b [dvb_core] [c052b307] ? dvb_dmxdev_feed_stop+0x5d/0x89 [dvb_core] [c052b60f] ? dvb_dmxdev_filter_start+0x15a/0x301 [dvb_core] [c052bd3f] ? dvb_demux_do_ioctl+0x1cc/0x4fe [dvb_core] [b016973d] ? path_openat+0x44d/0x55d [c052bb73] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c052a6b9] ? dvb_usercopy+0xa7/0x127 [dvb_core] [b016a38f] ? do_filp_open+0x2b/0x6f [c052aa3f] ? dvb_demux_ioctl+0xd/0x11 [dvb_core] [c052aa32] ? dvb_dvr_ioctl+0x11/0x11 [dvb_core] [b016bf68] ? do_vfs_ioctl+0x360/0x424 [b0173706] ? __fd_install+0x15/0x40 [b015d5a9] ? do_sys_open+0x1b3/0x1c5 [b016c05f] ? SyS_ioctl+0x33/0x58 [b0646452] ? system_call_fastpath+0x12/0x17 ---[ end trace 2f92b32249912b0e ]--- 3) after enabling debug in DMA API, I started receiving following message: [ cut here ] WARNING: CPU: 1 PID: 6946 at lib/dma-debug.c:1093 check_unmap+0x180/0x7c6() cx23885 :0a:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00d27000] [size=504 bytes] Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb
Re: [PATCH v2 2/3] media: au0828 change to not zero out fmt.pix.priv
My first code review of the new year, so let's start with a simple one to avoid taxing my brain cells (that are still in vacation mode) too much... On 12/18/2014 05:20 PM, Shuah Khan wrote: There is no need to zero out fmt.pix.priv in vidioc_g_fmt_vid_cap() vidioc_try_fmt_vid_cap(), and vidioc_s_fmt_vid_cap(). Remove it. Signed-off-by: Shuah Khan shua...@osg.samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com Happy New Year! Hans --- drivers/media/usb/au0828/au0828-video.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index 3011ca8..ef49b2e 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -1104,7 +1104,6 @@ static int au0828_set_format(struct au0828_dev *dev, unsigned int cmd, format-fmt.pix.sizeimage = width * height * 2; format-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; format-fmt.pix.field = V4L2_FIELD_INTERLACED; - format-fmt.pix.priv = 0; if (cmd == VIDIOC_TRY_FMT) return 0; @@ -1189,7 +1188,6 @@ static int vidioc_g_fmt_vid_cap(struct file *file, void *priv, f-fmt.pix.sizeimage = dev-frame_size; f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; /* NTSC/PAL */ f-fmt.pix.field = V4L2_FIELD_INTERLACED; - f-fmt.pix.priv = 0; return 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: [PATCH v2 1/3] media: au0828 - convert to use videobuf2
Hi Shuah,
Looks good! I do have a few small comments, see below.
On 12/18/2014 05:20 PM, Shuah Khan wrote:
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no new regressions in video and vbi now has 3 fewer
failures.
video before:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
vbi before:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test USERPTR: OK
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-cards.c | 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 949
+---
drivers/media/usb/au0828/au0828.h | 61 +-
5 files changed, 444 insertions(+), 692 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index 5f337b1..3011ca8 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
+void au0828_analog_unregister(struct au0828_dev *dev)
{
- switch (fh-type) {
- case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- return AU0828_RESOURCE_VIDEO;
- case V4L2_BUF_TYPE_VBI_CAPTURE:
- return AU0828_RESOURCE_VBI;
- default:
- BUG();
- return 0;
- }
+ dprintk(1, au0828_analog_unregister called\n);
+ mutex_lock(au0828_sysfs_lock);
+
+ if (dev-vdev)
+ video_unregister_device(dev-vdev);
+ if (dev-vbi_dev)
+ video_unregister_device(dev-vbi_dev);
+
+ mutex_unlock(au0828_sysfs_lock);
}
/* This function ensures that video frames continue to be delivered even if
@@ -951,8 +932,8 @@ static void au0828_vid_buffer_timeout(unsigned long data)
buf = dev-isoc_ctl.buf;
if (buf != NULL) {
- vid_data = videobuf_to_vmalloc(buf-vb);
- memset(vid_data, 0x00, buf-vb.size); /* Blank green frame */
+ vid_data = vb2_plane_vaddr(buf-vb, 0);
+ memset(vid_data, 0x00, buf-length); /* Blank green frame */
buffer_filled(dev, dma_q, buf);
}
get_next_buf(dma_q, buf);
@@ -975,8 +956,8 @@ static void au0828_vbi_buffer_timeout(unsigned long data)
buf = dev-isoc_ctl.vbi_buf;
if (buf != NULL) {
- vbi_data = videobuf_to_vmalloc(buf-vb);
- memset(vbi_data, 0x00, buf-vb.size);
+ vbi_data = vb2_plane_vaddr(buf-vb, 0);
+ memset(vbi_data, 0x00, buf-length);
vbi_buffer_filled(dev, dma_q, buf);
}
vbi_get_next_buf(dma_q, buf);
@@ -986,14 +967,12 @@ static void au0828_vbi_buffer_timeout(unsigned long
data)
spin_unlock_irqrestore(dev-slock, flags);
}
-
static int au0828_v4l2_open(struct file *filp)
{
- int ret = 0;
struct video_device *vdev = video_devdata(filp);
struct au0828_dev *dev = video_drvdata(filp);
- struct au0828_fh *fh;
int type;
+ int ret = 0;
switch (vdev-vfl_type) {
case VFL_TYPE_GRABBER:
This switch can be removed.
@@ -1957,17 +1693,23 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_g_audio = vidioc_g_audio,
.vidioc_s_audio = vidioc_s_audio,
.vidioc_cropcap = vidioc_cropcap,
- .vidioc_reqbufs = vidioc_reqbufs,
- .vidioc_querybuf= vidioc_querybuf,
- .vidioc_qbuf= vidioc_qbuf,
- .vidioc_dqbuf = vidioc_dqbuf,
+
+ .vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
+ .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
+ .vidioc_querybuf= vb2_ioctl_querybuf,
+ .vidioc_qbuf= vb2_ioctl_qbuf,
+ .vidioc_dqbuf = vb2_ioctl_dqbuf,
Add vidioc_expbuf as well. That is now supported by videobuf2-vmalloc.
+
.vidioc_s_std = vidioc_s_std,
.vidioc_g_std = vidioc_g_std,
.vidioc_enum_input = vidioc_enum_input,
.vidioc_g_input = vidioc_g_input,
.vidioc_s_input = vidioc_s_input,
- .vidioc_streamon= vidioc_streamon,
- .vidioc_streamoff = vidioc_streamoff,
+
+ .vidioc_streamon= vb2_ioctl_streamon,
+ .vidioc_streamoff = vb2_ioctl_streamoff,
+
.vidioc_g_tuner
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
On 01/09/2015 07:33 PM, Rob Herring wrote:
On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
Add a property for defining the device outputs the LED
represented by the DT child node is connected to.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
---
Documentation/devicetree/bindings/leds/common.txt |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index a2c3f7a..29295bf 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -1,6 +1,10 @@
Common leds properties.
Optional properties for child nodes:
+- led-sources : Array of bits signifying the LED current regulator
outputs the
+ LED represented by the child node is connected to (1 -
the LED
+ is connected to the output, 0 - the LED isn't connected
to the
+ output).
Sorry, I just don't understand this.
In some Flash LED devices one LED can be connected to one or more
electric current outputs, which allows for multiplying the maximum
current allowed for the LED. Each sub-LED is represented by a child
node in the DT binding of the Flash LED device and it needs to declare
which outputs it is connected to. In the example below the led-sources
property is a two element array, which means that the flash LED device
has two current outputs, and the bits signify if the LED is connected
to the output.
Sounds like a regulator for which we already have bindings for and we
have a driver for regulator based LEDs (but no binding for it). Please
use the regulator binding.
Do your doubts stem from the ambiguity of the word current or the
form of the description itself is unclear? Probably there should be
explicit explanation added that the size of the array depends on the
number of current outputs of the flash LED device.
The size of the array and meaning of array indexes was not clear.
Rob
- label : The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
@@ -33,6 +37,7 @@ system-status {
camera-flash {
label = Flash;
+ led-sources = 1 0;
max-microamp = 5;
flash-max-microamp = 32;
flash-timeout-us = 50;
--
1.7.9.5
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 15/19] media: Add registration helpers for V4L2 flash sub-devices
Hi!
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Therefore it must be possible to set it to 0 level which in
+* the LED subsystem reflects LED_OFF state.
+*/
+ if (cdata_id != INDICATOR_INTENSITY)
+ ++__intensity;
And normally we'd do i++ instead of ++i, and avoid __ for local
variables...?
Pre-incrementation operator is favourable over the post-incrementation
one if we don't want to have an access to the value of a variable before
incrementation, which is the case here.
That may be some old C++ convention, but I'm pretty sure gcc does not
care.
Maybe gcc detects the cases when the value of a variable is not assigned
and doesn't copy it before incrementing, however I haven't found any
reference. I see that often in the for loops the i++ version
is used, but I am not sure if this is done because developers are
aware that gcc will optimize it anyway or it is just an omission.
The code is equivalent, and normally the n++ version is used. gcc will
get it right.
+struct v4l2_flash_ctrl_config {
+ struct v4l2_ctrl_config intensity;
+ struct v4l2_ctrl_config flash_intensity;
+ struct v4l2_ctrl_config flash_timeout;
+ u32 flash_faults;
+ bool has_external_strobe:1;
+ bool indicator_led:1;
+};
I don't think you are supposed to do boolean bit arrays.
These bit fields allow to reduce memory usage. If they were not bit
fields, the address of the next variable would be aligned to the
multiply of the CPU word size.
Please look e.g. at struct dev_pm_info in the file include/linux/pm.h.
It also contains boolean bit fields.
Looks like you are right. I guess I confused bool foo:1 with int
foo:1.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder
On 12/22/2014 05:00 PM, Philipp Zabel wrote:
The encoder needs to know the nominal framerate for the constant bitrate
control mechanism to work. Currently the only way to set the framerate is
by using VIDIOC_S_PARM on the output queue.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..63eb510 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -803,6 +803,32 @@ static int coda_decoder_cmd(struct file *file, void *fh,
return 0;
}
+static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
If a-type != V4L2_BUF_TYPE_VIDEO_OUTPUT, then return -EINVAL. Ditto for s_parm.
+ a-parm.output.timeperframe.denominator = 1;
+ a-parm.output.timeperframe.numerator = ctx-params.framerate;
+
+ return 0;
+}
+
+static int coda_s_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT
+ a-parm.output.timeperframe.numerator != 0) {
+ ctx-params.framerate = a-parm.output.timeperframe.denominator
+ / a-parm.output.timeperframe.numerator;
Hmm, what happens if the denominator is 1 and the numerator is 2?
You probably want to clamp ctx-params.framerate to the range of allowed
framerates.
And at least ensure a framerate 0.
Also check with v4l2_compliance! You'd have caught at least the missing a-type
check.
+ }
+
+ a-parm.output.timeperframe.denominator = 1;
+ a-parm.output.timeperframe.numerator = ctx-params.framerate;
+
+ return 0;
+}
+
static int coda_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
{
@@ -843,6 +869,9 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_try_decoder_cmd = coda_try_decoder_cmd,
.vidioc_decoder_cmd = coda_decoder_cmd,
+ .vidioc_g_parm = coda_g_parm,
+ .vidioc_s_parm = coda_s_parm,
+
.vidioc_subscribe_event = coda_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
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: [PATCH/RFC v10 08/19] leds: Add support for max77693 mfd flash cell
Hi!
+struct max77693_sub_led {
+ /* related FLED output identifier */
-flash LED, about 4x.
+/* split composite current @i into two @iout according to @imax weights */
+static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2])
+{
+ u64 t = i;
+
+ t *= imax[1];
+ do_div(t, imax[0] + imax[1]);
+
+ iout[1] = (u32)t / FLASH_IOUT_STEP * FLASH_IOUT_STEP;
+ iout[0] = i - iout[1];
+}
Is 64-bit arithmetics neccessary here? Could we do the FLASH_IOUT_STEP
divisons before t *=, so that 64-bit division is not neccessary?
It is required. All these operations allow for splitting the composite
current into both outputs according to weights given in the imax
array.
I know.
What about this?
static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2])
{
u32 t = i;
t *= imax[1] / FLASH_IOUT_STEP;
t = t / (imax[0] + imax[1]);
t /= FLASH_IOUT_STEP
iout[1] = (u32)t;
iout[0] = i - iout[1];
}
Does it lack precision?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 08/19] leds: Add support for max77693 mfd flash cell
On 01/12/2015 02:25 PM, Pavel Machek wrote:
Hi!
+struct max77693_sub_led {
+ /* related FLED output identifier */
-flash LED, about 4x.
+/* split composite current @i into two @iout according to @imax weights */
+static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2])
+{
+ u64 t = i;
+
+ t *= imax[1];
+ do_div(t, imax[0] + imax[1]);
+
+ iout[1] = (u32)t / FLASH_IOUT_STEP * FLASH_IOUT_STEP;
+ iout[0] = i - iout[1];
+}
Is 64-bit arithmetics neccessary here? Could we do the FLASH_IOUT_STEP
divisons before t *=, so that 64-bit division is not neccessary?
It is required. All these operations allow for splitting the composite
current into both outputs according to weights given in the imax
array.
I know.
What about this?
static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2])
{
u32 t = i;
t *= imax[1] / FLASH_IOUT_STEP;
Let's consider following case:
t = 100
imax[1] = 100
multiplication of the above will give 10^12 - much more than
it is possible to encode on 32 bits.
t = t / (imax[0] + imax[1]);
t /= FLASH_IOUT_STEP
iout[1] = (u32)t;
iout[0] = i - iout[1];
}
Does it lack precision?
Thanks,
Pavel
--
Best Regards,
Jacek Anaszewski
--
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: Supporting 3D formats in V4L2
Hi Jean-Marc, On 01/09/2015 05:38 PM, Jean-Marc VOLLE wrote: Hello Hans! Best wishes! You too. In reply to the below mail (sorry I do not know how to reply to mails I did not get but only found on the mail archive). I think (reading the HDMI spec 1.4b) that in fact any of the V4L2_FIELD_3D_FRAME_PACK, V4L2_FIELD_3D_SBS_HALF, V4L2_FIELD_3D_TAB may all be passed with interlaced or progressive content. Figure 8-5 3D structure (Side-by-Side (Half) ) states: For interlaced formats, Vactive is number of active lines per field p148 also lists primary 3D video format timings that show eg 1920 x 1080i @50Hz Side by Side Since you proposed initially to pass all 3D information in the enum v4l2_field I think that at least SbS, TAB and FP shall be duplicated with TB or BT attributes or a dedicated 3D only enum would have to be created to reused interlaced/progressive information from enum v4l2_field. What is your view on this? Thanks for your comments. JM A second field just for 3D information is not a good idea for two reasons: 1) The v4l2_buffer struct is very full, and adding another field there should only be done if there is no alternative. 2) I think it makes sense to extend v4l2_field: after all it describes how fields are stored in a buffer, and that fits very well with the 3D extension. In practice the FIELD_INTERLACED, FIELD_SEQ_TB/BT and FIELD_INTERLACED_TB/BT values will never be used with 3D formats. Those field values are specific to SDTV. For the new 3D field values you need to add two sets: one for progressive 3D (the equivalent to FIELD_NONE for normal 2D) and one for interlaced 3D (the equivalent to FIELD_ALTERNATE for normal 2D). Regards, Hans Hi Soby! On Thu 19 July 2012 14:18:13 Soby Mathew wrote: Hi everyone, Currently there is limitation in v4l2 for specifying the 3D formats . In HDMI 1.4 standard, the following 3D formats are specified: I think that this is ideal for adding to enum v4l2_field. I've made some proposals below: 1. FRAME_PACK, V4L2_FIELD_3D_FRAME_PACK(progressive) V4L2_FIELD_3D_FRAME_PACK_TB (interlaced, odd == top comes first) 2. FIELD_ALTERNATIVE, V4L2_FIELD_3D_FIELD_ALTERNATIVE 3. LINE_ALTERNATIVE, V4L2_FIELD_3D_LINE_ALTERNATIVE 4. SIDE BY SIDE FULL, V4L2_FIELD_3D_SBS_FULL 5. SIDE BY SIDE HALF, V4L2_FIELD_3D_SBS_HALF 6. LEFT + DEPTH, V4L2_FIELD_3D_L_DEPTH 7. LEFT + DEPTH + GRAPHICS + GRAPHICS-DEPTH, V4L2_FIELD_3D_L_DEPTH_GFX_DEPTH 8. TOP AND BOTTOM V4L2_FIELD_3D_TAB You would also need defines that describe which field is received for the field alternative mode (it's put in struct v4l2_buffer): V4L2_FIELD_3D_LEFT_TOP V4L2_FIELD_3D_LEFT_BOTTOM V4L2_FIELD_3D_RIGHT_TOP V4L2_FIELD_3D_RIGHT_BOTTOM In addition for some of the formats like Side-by-side-half there are some additional metadata (like type of horizontal sub-sampling) A control seems to be the most appropriate method of exposing the horizontal subsampling. and parallax information which may be required for programming the display processing pipeline properly. This would be a new ioctl, but I think this should only be implemented if someone can actually test it with real hardware. The same is true for the more exotic 3D formats above. It seems SBS is by far the most common format. I am not very sure on how to expose this to the userspace. This is an inherent property of video signal , hence it would be appropriate to have an additional field in v4l_format to specify 3D format. Currently this is a requirement for HDMI 1.4 Rx / Tx but in the future it would be applicable to broadcast sources also. In our implementation we have temporarily defined a Private Control to expose this . Please let me know of your suggestions . I hope this helps! 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: dvb-t scan tables
On 11/01/15 10:26, Olliver Schinagl wrote: Hey Adam, I've merged your changes, but this last patch seems to go against the old (obsolete) dvbv3 stuff (that gets auto-generated afaik) and fails to apply. Look at the result on the various repositories and see what needs to be changed. OK, I'll take a look. Best way to send a patch, is to use git to checkout the tree, and then do a git format-patch to send the patch, saves me some work ;) Is that different from the attached? I've updated the channel numbers as they are now exact and not +/- cheers, Adam -- Adam Laurie Tel: +44 (0) 20 7993 2690 Suite 7 61 Victoria Road Surbiton Surrey mailto:a...@algroup.co.uk KT6 4JX http://rfidiot.org diff --git a/dvb-t/uk-StocklandHill b/dvb-t/uk-StocklandHill index 8b9ad5a..5d2ee81 100644 --- a/dvb-t/uk-StocklandHill +++ b/dvb-t/uk-StocklandHill @@ -6,7 +6,7 @@ # date (-mm-dd): 2014-03-25 # #-- -[C26+ BBC A] +[C26 BBC A] DELIVERY_SYSTEM = DVBT FREQUENCY = 51400 BANDWIDTH_HZ = 800 @@ -18,7 +18,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C23+ D34] +[C23 D34] DELIVERY_SYSTEM = DVBT FREQUENCY = 49000 BANDWIDTH_HZ = 800 @@ -30,7 +30,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C25- SDN] +[C25 SDN] DELIVERY_SYSTEM = DVBT FREQUENCY = 50600 BANDWIDTH_HZ = 800 @@ -42,7 +42,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C22- ARQ A] +[C22 ARQ A] DELIVERY_SYSTEM = DVBT FREQUENCY = 48200 BANDWIDTH_HZ = 800 @@ -54,7 +54,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C28- ARQ B] +[C28 ARQ B] DELIVERY_SYSTEM = DVBT FREQUENCY = 53000 BANDWIDTH_HZ = 800 @@ -66,7 +66,7 @@ HIERARCHY = NONE INVERSION = AUTO -[C29+ BBC B HD] +[C29 BBC B HD] DELIVERY_SYSTEM = DVBT2 FREQUENCY = 53800 BANDWIDTH_HZ = 800
Re: [PATCH v2 1/3] media: au0828 - convert to use videobuf2
On 12/18/2014 05:20 PM, Shuah Khan wrote:
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no new regressions in video and vbi now has 3 fewer
failures.
video before:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
vbi before:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test USERPTR: OK
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-cards.c | 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 949
+---
drivers/media/usb/au0828/au0828.h | 61 +-
5 files changed, 444 insertions(+), 692 deletions(-)
diff --git a/drivers/media/usb/au0828/Kconfig
b/drivers/media/usb/au0828/Kconfig
index 1d410ac..78b797e 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
- select VIDEOBUF_VMALLOC
+ select VIDEOBUF2_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 9eb77ac..ae2e563 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -39,7 +39,7 @@ static void hvr950q_cs5340_audio(void *priv, int enable)
struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name = Unknown board,
- .tuner_type = UNSET,
+ .tuner_type = -1U,
.tuner_addr = ADDR_UNSET,
},
[AU0828_BOARD_HAUPPAUGE_HVR850] = {
I would split off this au0828-cards.c change into a separate patch. It has
nothing to
do with the vb2 conversion.
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: [PATCH v2 3/3] media: au0828 remove video and vbi buffer timeout work-around
On 12/18/2014 05:20 PM, Shuah Khan wrote:
au0828 does video and vbi buffer timeout handling to prevent
applications such as tvtime from hanging by ensuring that the
video frames continue to be delivered even when the ITU-656
input isn't receiving any data. This work-around is complex
as it introduces set and clear tier code paths in start/stop
streaming, and close interfaces. After the vb2 conversion, the
timeout handling is introducing instability as well as feeding
too many blank green screens, resulting in degraded video quality.
Why would this result in degraded video quality? And which instability
exactly?
Without this timeout handling, both xawtv, and tvtime are working
well with good quality video.
Erm, tvtime without the recent 'tvtime: don't block indefinitely waiting
for frames' patch will not work well with au0828 without the timeout code
if there is no valid video data.
This should at minimum be mentioned in the commit log.
Especially if this fixes other issues as you mentioned in the log I am
all for it. But others will probably object to this.
Regards,
Hans
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-video.c | 103
+---
drivers/media/usb/au0828/au0828.h | 5 --
2 files changed, 1 insertion(+), 107 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index ef49b2e..3bdf132 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -593,15 +593,6 @@ static inline int au0828_isoc_copy(struct au0828_dev
*dev, struct urb *urb)
outp = NULL;
else
outp = vb2_plane_vaddr(buf-vb, 0);
-
- /* As long as isoc traffic is arriving, keep
-resetting the timer */
- if (dev-vid_timeout_running)
- mod_timer(dev-vid_timeout,
- jiffies + (HZ / 10));
- if (dev-vbi_timeout_running)
- mod_timer(dev-vbi_timeout,
- jiffies + (HZ / 10));
}
if (buf != NULL) {
@@ -804,15 +795,9 @@ int au0828_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
return rc;
}
- if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
v4l2_device_call_all(dev-v4l2_dev, 0, video,
s_stream, 1);
- dev-vid_timeout_running = 1;
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
- } else if (vq-type == V4L2_BUF_TYPE_VBI_CAPTURE) {
- dev-vbi_timeout_running = 1;
- mod_timer(dev-vbi_timeout, jiffies + (HZ / 10));
- }
}
dev-streaming_users++;
return rc;
@@ -851,9 +836,6 @@ static void au0828_stop_streaming(struct vb2_queue *vq)
(AUVI_INPUT(i).audio_setup)(dev, 0);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vid_timeout_running = 0;
- del_timer_sync(dev-vid_timeout);
}
void au0828_stop_vbi_streaming(struct vb2_queue *vq)
@@ -882,9 +864,6 @@ void au0828_stop_vbi_streaming(struct vb2_queue *vq)
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vbi_timeout_running = 0;
- del_timer_sync(dev-vbi_timeout);
}
static struct vb2_ops au0828_video_qops = {
@@ -917,56 +896,6 @@ void au0828_analog_unregister(struct au0828_dev *dev)
mutex_unlock(au0828_sysfs_lock);
}
-/* This function ensures that video frames continue to be delivered even if
- the ITU-656 input isn't receiving any data (thereby preventing
applications
- such as tvtime from hanging) */
-static void au0828_vid_buffer_timeout(unsigned long data)
-{
- struct au0828_dev *dev = (struct au0828_dev *) data;
- struct au0828_dmaqueue *dma_q = dev-vidq;
- struct au0828_buffer *buf;
- unsigned char *vid_data;
- unsigned long flags = 0;
-
- spin_lock_irqsave(dev-slock, flags);
-
- buf = dev-isoc_ctl.buf;
- if (buf != NULL) {
- vid_data = vb2_plane_vaddr(buf-vb, 0);
- memset(vid_data, 0x00, buf-length); /* Blank green frame */
- buffer_filled(dev, dma_q, buf);
- }
- get_next_buf(dma_q, buf);
-
- if (dev-vid_timeout_running == 1)
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
-
- spin_unlock_irqrestore(dev-slock, flags);
-}
-
-static void
Re: videobuf2_core oops, recent media_build
Hi Jurgen, On 12/27/2014 10:35 AM, Jurgen Kramer wrote: I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? Sorry for the delay, I was on vacation. Do you get this when you start streaming, stop streaming or during streaming? I strongly suspect a race condition that can occur when stopping streaming, but I am not aware of race conditions when starting or during streaming. Please let me know when you get this, as that will be very useful information for me. 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 1/6] cec: add new driver for cec support.
On 12/23/2014 03:32 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
Add the CEC framework.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
[k.deb...@samsung.com: change kthread handling when setting logical
address]
[k.deb...@samsung.com: code cleanup]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
cec-rfc.txt | 319 ++
cec.txt | 40 ++
drivers/media/Kconfig|5 +
drivers/media/Makefile |2 +
drivers/media/cec.c | 1048
++
include/media/cec.h | 129 ++
include/uapi/linux/cec.h | 222 ++
7 files changed, 1765 insertions(+)
create mode 100644 cec-rfc.txt
create mode 100644 cec.txt
create mode 100644 drivers/media/cec.c
create mode 100644 include/media/cec.h
create mode 100644 include/uapi/linux/cec.h
...
diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
new file mode 100644
index 000..a2c78d7
--- /dev/null
+++ b/include/uapi/linux/cec.h
@@ -0,0 +1,222 @@
+#ifndef _CEC_H
+#define _CEC_H
+
+#include linux/types.h
+
+struct cec_msg {
+ __u32 len;
+ __u8 msg[16];
+ __u32 status;
+ /* If non-zero, then wait for a reply with this opcode.
+If there was an error when sending the msg or FeatureAbort
+was returned, then reply is set to 0.
+If reply is non-zero upon return, then len/msg are set to
+the received message.
+If reply is zero upon return and status has the
CEC_TX_STATUS_FEATURE_ABORT
+bit set, then len/msg are set to the received feature abort message.
+If reply is zero upon return and status has the
CEC_TX_STATUS_REPLY_TIMEOUT
+bit set, then no reply was seen at all.
+This field is ignored with CEC_RECEIVE.
+If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
+then -EINVAL is returned.
+if reply is non-zero, then timeout is set to 1000 (the required
maximum
+response time).
+ */
+ __u8 reply;
+ /* timeout (in ms) is used to timeout CEC_RECEIVE.
+Set to 0 if you want to wait forever. */
+ __u32 timeout;
+ struct timespec ts;
+};
+
+static inline __u8 cec_msg_initiator(const struct cec_msg *msg)
+{
+ return msg-msg[0] 4;
+}
+
+static inline __u8 cec_msg_destination(const struct cec_msg *msg)
+{
+ return msg-msg[0] 0xf;
+}
+
+static inline bool cec_msg_is_broadcast(const struct cec_msg *msg)
+{
+ return (msg-msg[0] 0xf) == 0xf;
+}
+
+/* cec status field */
+#define CEC_TX_STATUS_OK(0)
+#define CEC_TX_STATUS_ARB_LOST (1 0)
+#define CEC_TX_STATUS_RETRY_TIMEOUT (1 1)
+#define CEC_TX_STATUS_FEATURE_ABORT (1 2)
+#define CEC_TX_STATUS_REPLY_TIMEOUT (1 3)
+#define CEC_RX_STATUS_READY (0)
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+// The maximum number of logical addresses one device can be assigned to.
+// The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+// Analog Devices CEC hardware supports 3. So let's go wild and go for 4.
+#define CEC_MAX_LOG_ADDRS 4
+
+// You are in a maze of twisty little defines, all alike
+// What were they thinking of when they came up with this mess...
+
+// The Primary Device Type
+#define CEC_PRIM_DEVTYPE_TV 0
+#define CEC_PRIM_DEVTYPE_RECORD 1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5
+#define CEC_PRIM_DEVTYPE_SWITCH 6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+// The All Device Types flags (CEC 2.0)
+#define CEC_FL_ALL_DEVTYPE_TV(1 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD(1 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER (1 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK (1 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH(1 2)
+// And if you wondering what happened to VIDEOPROC devices: those should
+// be mapped to a SWITCH.
+
+// The logical address types that the CEC device wants to claim
+#define CEC_LOG_ADDR_TYPE_TV 0
+#define CEC_LOG_ADDR_TYPE_RECORD 1
+#define CEC_LOG_ADDR_TYPE_TUNER 2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+// Switches should use UNREGISTERED.
+// Video processors should use SPECIFIC.
+
+// The CEC version
+#define CEC_VERSION_1_4B 5
+#define CEC_VERSION_2_0 6
+
+struct cec_event {
+ __u32 event;
+ struct timespec ts;
+};
+
+/* Userspace has to configure the adapter state (enable/disable) */
+#define CEC_CAP_STATE
Re: [PATCHv3 0/3] hdmi: add unpack and logging functions
Hi Thierry, On 12/19/2014 01:14 PM, Hans Verkuil wrote: This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and adds unpacking and logging functions to hdmi.c. It also uses those in the V4L2 adv7842 driver (and they will be used in other HDMI drivers once this functionality is merged). Changes since v2: - Applied most comments from Thierry's review - Renamed HDMI_AUDIO_CODING_TYPE_EXT_STREAM as per Thierry's suggestion. Thierry, if this OK, then please give your Ack and I'll post a pull request for 3.20 for the media git tree. Can you Ack this patch series? Thanks! Hans 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 -- 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 12/23/2014 03:32 PM, Kamil Debski wrote: From: Hans Verkuil hansv...@cisco.com Add the CEC framework. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup] Signed-off-by: Kamil Debski k.deb...@samsung.com --- cec-rfc.txt | 319 ++ cec.txt | 40 ++ A note regarding these text files: cec-rfc.txt should go to Documentation/cec.txt. I'm not sure if it is up to date (Kamil, did you check?). The cec.txt file is basically a bunch of notes to myself when I was working on this. It contains some of the not-so-obvious CEC protocol specifications. It should either be deleted for the final version of this patch series, or it should be merged with cec-rfc.txt. 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: [PATCH 1/2] V4L: remove clock name from v4l2_clk API
Hi Josh, On Monday 12 January 2015 17:14:33 Josh Wu wrote: On 1/9/2015 6:47 AM, Laurent Pinchart wrote: On Thursday 08 January 2015 23:37:58 Guennadi Liakhovetski wrote: On Wed, 7 Jan 2015, Josh Wu wrote: On 1/7/2015 6:17 AM, Guennadi Liakhovetski wrote: On Tue, 6 Jan 2015, Josh Wu wrote: Hi, Guennadi After look deep into this patch, I found you miss one line that should be changed as well. It's In function v4l2_clk_get(), there still has one line code called v4l2_clk_find(dev_id, id). You need to change it to v4l2_clk_find(dev_id, NULL) as well. Otherwise the code that many sensor used: v4l2_clk_get(client-dev, mclk) cannot acquired the mclk clock. After above changes, this patch works for me. I think you're right, in fact, since we now don't store CCF-based v4l2_clk wrappers on the list, this can be simplified even further, I'll update the patch. Did you only test this patch or both? I tested both patches with Atmel-isi driver. For the 2/2 patch I applied the modification Laurent suggested. Those patches works for me. The only concern is in ov2640 I still need to acquired two v4l2 clocks: xvclk that will get the xvclk CCF clock directly. mclk that make ISI driver call his clock_start()/stop() to enable/disable ISI's peripheral clock. If I only get xvclk clock, then the camera capture will be failed with a ISI timeout error. No, this doesn't look right to me. The camera sensor has only one clock input, so, it should only request one clock. Where does the clock signal to the camera come from on your system? That's correct, the sensor driver only has one clock input, so it should just request the xvclk clock. If it comes from the ISI itself, you don't need to specify the clock in the DT, since the ISI doesn't produce a clock from DT. If you do want to have your clock consumer (ov2640) and the supplier (ISI) properly described in DT, you'll have to teach the ISI to register a CCF clock source, which then will be connected to from the ov2640. If you choose not to show your clock in the DT, you can just use v4l2_clk_get(dev, xvclk) and it will be handled by v4l2_clk / soc-camera / isi-atmel. If the closk to ov2640 is supplied by a separate clock source, then you v4l2_clk_get() will connect ov2640 to it directly and soc-camera will enable and disable it on power-on / -off as required. The ISI has no way to supply a sensor clock, the clock is supplied by a separate clock source. From your above description it looks like the clock to ov2640 is supplied by a separate source, but atmel-isi's .clock_start() / .clock_stop() functions still need to be called? By looking at those functions it looks like they turn on and off clocks, supplying the ISI itself... Instead of only turning on and off clocks, provided by the ISI to a camera sensor. If my understanding is right, then this is a bug in atmel-isi and it has to be fixed. That's correct as well, the ISI driver needs to be fixed. Thanks both of you for the details. Now I got it. Indeed, I need fix this in atmel-isi driver not in ov2640 driver. So I will send a new patch for this, which should move the ISI peripheral clock enable/disable() from clock_start/stop() to isi_camera_add_device/remove_device(). Shouldn't you move it to the start_streaming() and stop_streaming() functions instead ? An even better solution would be to use runtime PM to enable/disable the ISI clock in the runtime PM resume and suspend handlers, and call pm_runtime_get_sync() and pm_runtime_put() when you need the ISI to be operational. -- 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] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Hi Kukjin,
On Wednesday, January 07, 2015 6:09 PM, Jacek Anaszewski wrote,
Hi Tony,
On 01/07/2015 01:08 PM, Tony K Nadackal wrote:
Dear Jacek,
On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
Hi Tony,
Sorry for late response, just got back from vacation.
On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
Hi Tony,
Thanks for the patches.
Thanks for the review.
Please process them with scripts/checkpatch.pl as you will be
submitting the
next
version - they contain many coding style related issues.
I ran checkpatch before posting. Do you find any checkpatch related
issues in the patch?
There was a problem on my side, sorry for making confusion.
My remaining comments below.
[snip]
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+
EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+
EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg-regs,
ctx-jpeg-variant-version); exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
ctx-subsampling,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_ENC_FMT_MASK :
EXYNOS7_ENC_FMT_MASK);
exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_SWAP_CHROMA_SHIFT :
EXYNOS7_SWAP_CHROMA_SHIFT);
OK. Looks goods to me. Thanks for the suggestion.
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-
fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_huff_tbl(jpeg-regs);
+ exynos4_jpeg_set_huf_table_enable(jpeg-
regs, 1);
+
+ /*
+* JPEG IP allows storing 4 quantization tables
+* We fill table 0 for luma and table 1 for
chroma
+*/
+ exynos4_jpeg_set_qtbl_lum(jpeg-regs,
+ ctx-
compr_quality);
+ exynos4_jpeg_set_qtbl_chr(jpeg-regs,
+ ctx-
compr_quality);
Is it really required to setup quantization tables for encoding?
Without setting up the quantization tables, encoder is working fine.
But, as per Exynos7 User Manual setting up the quantization tables
are required for encoding also.
Sorry I also got it mixed up.
*Decoder* works fine without setting up the quantization tables. But
this step is mentioned in User Manual.
I'm ok with it provided that you will get an ack from Samsung SOCs maintainer.
Actually I intended to ask if setting the quantization tables is
required for *decoding*, as you set it also in decoding path, whereas
for Exynos4 it is not required. I looks strange for me as
quantization tables are usually required
only
for encoding raw images.
The same is related to huffman tables.
Huffman table is required for Exynos7 decoding.
User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL],
User/Host should mandatory program this Bit as 1 for every decoder
operation. SFR HUFF_TBL_ENT and SFR HUFF_CNT should be programmed
accordingly for every encoder/decoder operation.
Same situation as above.
+ exynos4_jpeg_set_stream_size(jpeg-regs, ctx-
cap_q.w,
+
Re: videobuf2_core oops, recent media_build. dvbsky t980c's
On 12/29/2014 03:38 PM, Jurgen Kramer wrote: On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? The problem persist while my system went through a motherboard/mem/cpu upgrade. The oops occurs when one of the DVB-C cards get its first use (in my case mythtv): [ 102.050294] si2157 18-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 181.460991] IP: [a04d833a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 181.461019] PGD 0 [ 181.461024] Oops: 0002 [#1] SMP [ 181.461032] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
Re: [RFC PATCH] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder
On 01/12/2015 04:35 PM, Philipp Zabel wrote:
Hi Hans,
thank you for the comments!
Am Montag, den 12.01.2015, 16:03 +0100 schrieb Hans Verkuil:
On 12/22/2014 05:00 PM, Philipp Zabel wrote:
The encoder needs to know the nominal framerate for the constant bitrate
control mechanism to work. Currently the only way to set the framerate is
by using VIDIOC_S_PARM on the output queue.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 29
+
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..63eb510 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -803,6 +803,32 @@ static int coda_decoder_cmd(struct file *file, void
*fh,
return 0;
}
+static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
If a-type != V4L2_BUF_TYPE_VIDEO_OUTPUT, then return -EINVAL.
If the decoder can retrieve the framerate from the stream, wouldn't it
make sense to allow G_PARM for a-type == V4L2_BUF_TYPE_VIDEO_CAPTURE ?
Certainly. But that wasn't in the patch :-)
Regards,
Hans
Ditto for s_parm.
Will do.
+ a-parm.output.timeperframe.denominator = 1;
+ a-parm.output.timeperframe.numerator = ctx-params.framerate;
+
+ return 0;
+}
+
+static int coda_s_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT
+ a-parm.output.timeperframe.numerator != 0) {
+ ctx-params.framerate = a-parm.output.timeperframe.denominator
+ / a-parm.output.timeperframe.numerator;
Hmm, what happens if the denominator is 1 and the numerator is 2?
You probably want to clamp ctx-params.framerate to the range of allowed
framerates.
And at least ensure a framerate 0.
Also check with v4l2_compliance! You'd have caught at least the missing
a-type check.
Oh dear, I need to improve my v4l-utils update habits. I'll fix this
patch and resend it.
regards
Philipp
--
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] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder
Hi Hans,
thank you for the comments!
Am Montag, den 12.01.2015, 16:03 +0100 schrieb Hans Verkuil:
On 12/22/2014 05:00 PM, Philipp Zabel wrote:
The encoder needs to know the nominal framerate for the constant bitrate
control mechanism to work. Currently the only way to set the framerate is
by using VIDIOC_S_PARM on the output queue.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 29
+
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..63eb510 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -803,6 +803,32 @@ static int coda_decoder_cmd(struct file *file, void
*fh,
return 0;
}
+static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
If a-type != V4L2_BUF_TYPE_VIDEO_OUTPUT, then return -EINVAL.
If the decoder can retrieve the framerate from the stream, wouldn't it
make sense to allow G_PARM for a-type == V4L2_BUF_TYPE_VIDEO_CAPTURE ?
Ditto for s_parm.
Will do.
+ a-parm.output.timeperframe.denominator = 1;
+ a-parm.output.timeperframe.numerator = ctx-params.framerate;
+
+ return 0;
+}
+
+static int coda_s_parm(struct file *file, void *fh, struct v4l2_streamparm
*a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT
+ a-parm.output.timeperframe.numerator != 0) {
+ ctx-params.framerate = a-parm.output.timeperframe.denominator
+ / a-parm.output.timeperframe.numerator;
Hmm, what happens if the denominator is 1 and the numerator is 2?
You probably want to clamp ctx-params.framerate to the range of allowed
framerates.
And at least ensure a framerate 0.
Also check with v4l2_compliance! You'd have caught at least the missing
a-type check.
Oh dear, I need to improve my v4l-utils update habits. I'll fix this
patch and resend it.
regards
Philipp
--
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
[no subject]
My USB dongle is recognized by the system but I have a problem with the channels. Please read all my post for any help ;-) At first, I used this guide: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers After that dmesg showed that system was searching for isdbt_rio.inp firmware. If I use that firmware from linuxtv.org, w_scan shows me an error, it says that my dongle can't search for TERRESTRIAL. So, for using smsmdtv mode DVB-T as the default option, I forced the kernel module in this way: echo options smsmdtv default_mode=0 | sudo tee /etc/modprobe.d/smsmdtv.conf After that system searches for dvb_rio.inp, good ;-) dmesg: [ 1327.312795] usb 1-3: new high-speed USB device number 4 using ehci-pci [ 1327.446103] usb 1-3: New USB device found, idVendor=187f, idProduct=0600 [ 1327.446121] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1327.446130] usb 1-3: Product: MDTV Receiver [ 1327.446138] usb 1-3: Manufacturer: MDTV Receiver [ 1327.451833] usb 1-3: Direct firmware load failed with error -2 [ 1327.451849] usb 1-3: Falling back to user helper [ 1327.456026] smscore_load_firmware_from_file: line: 1168: failed to open firmware file dvb_rio.inp [ 1327.456535] DVB: registering new adapter (Siano Rio Digital Receiver) [ 1327.457351] usb 1-3: DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... I used dvb_rio.inp from my Windows installation (md5: 146156b55ce6fc586470f28194add5a7, sha1: 48907a4749ba5fd5b4b947195c0d484e55a4c169). Now I have this output form lsusb: Bus 002 Device 002: ID 0402:7675 ALi Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 0489:e03c Foxconn / Hon Hai Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 187f:0600 Siano Mobile Silicon Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub dmesg: [ 1390.167433] usb 1-3: new high-speed USB device number 5 using ehci-pci [ 1390.300895] usb 1-3: New USB device found, idVendor=187f, idProduct=0600 [ 1390.300913] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1390.300922] usb 1-3: Product: MDTV Receiver [ 1390.300930] usb 1-3: Manufacturer: MDTV Receiver [ 1390.776240] DVB: registering new adapter (Siano Rio Digital Receiver) [ 1390.777275] usb 1-3: DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... lsmod | grep sms: smsdvb 27513 0 dvb_core 125880 1 smsdvb smsusb 17819 0 smsmdtv 53748 2 smsdvb,smsusb rc_core 27389 1 smsmdtv Finally I can scan and tune with a specific frequency but I can't obtain services from multiplexes. w_scan -c IT output: w_scan version 20130331 (compiled for DVB API 5.10) using settings for ITALY DVB aerial DVB-T Europe scan type TERRESTRIAL, channellist 4 output format vdr-2.0 WARNING: could not guess your codepage. Falling back to 'UTF-8' output charset 'UTF-8', use -C to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - TERRESTRIAL Siano Mobile Digital MDTV Receiver: good :-) Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0) Getting frontend capabilities Using DVB API 5.a frontend 'Siano Mobile Digital MDTV Receiver' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (44.25MHz ... 867.25MHz) ---_ Scanning 7MHz frequencies... 177500: (time: 00:00) (time: 00:01) signal ok: QAM_AUTO f = 177500 kHz I999B7C999D999T999G999Y999 Info: no data from NIT(actual) 184500: (time: 00:15) 191500: (time: 00:18) (time: 00:19) signal ok: QAM_AUTO f = 191500 kHz I999B7C999D999T999G999Y999 Info: no data from NIT(actual) 198500: (time: 00:33) 205500: (time: 00:36) ... ... I created a file named frequency with this content for doing a test: # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 17750 7MHz 2/3 NONE QAM64 8k 1/8 NONE # MUX-B Rai T 69800 8MHz 2/3 NONE QAM64 8k 1/8 NONE # Mediaset 1 and when I launch dvbscan frequency I obtain: Unable to query frontend status. With the utility scan I obtain: scanning frequency using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 17750 1 2 9 3 1 2 0 initial transponder 69800 0 2 9 3 1 2 0 tune to: 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 dumping lists (0 services) Done. WIth dvbv5-scan frequency: ERROR key/value without a channel group while parsing line 3 of frequency. I tried to insert
Re: CMYG support in V4L2
On 12/29/2014 02:33 PM, Ondrej Zary wrote: Hello, I'm working on an old driver called qcamvc for Connectix QuickCam VC webcams (parallel port and USB models), found here: http://sourceforge.net/projects/usb-quickcam-vc/ Luckily, it was modified last year to compile with 3.x kernels. After trivial modification (mfr and model), it works with parallel-port QuickCam Pro (sort of - only at 320x240 and with vertical lines on the left and blank part at the top). I don't have QuickCam VC (yet). After removing a lot of code (it's now around 1200 [main] + 660 [parallel] + 320 [usb] lines), one problem still remains: in-kernel colour conversion with software contrast, hue, saturation and gamma. According to comments in the code, the camera sensor seems to have a CMYG filter, like no other linux-supported camera. So the proper way to support these cameras is to introduce a new pixel format, move the conversion to libv4lconvert and remove all controls not provided by hardware? Correct. 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 12.01.2015 12:55, Hans Verkuil wrote: On 01/11/2015 10:33 AM, Raimonds Cicans wrote: After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: This makes no sense. The cx23885 driver in 3.17.7 doesn't use vb2. Are you using the media_build repo perhaps to install the latest media drivers on a 3.17 kernel? Sorry for misinforming you. IMHO I saw somewhere that 453afdd was included in 3.17.0-rc_something. In last two weeks I did too much tests. As far as I remember kernel / driver combinations was following 3.13.10 built in driver - not affected 3.17.7 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) - affected 3.18.1 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) - affected 3.19.0-rc3 built in driver (+ few new TBS open source drivers injected by https://github.com/bas-t/saa716x-intree) - affected Bisection I did on pure 3.13.10 + pure media tree As you can see bug(s) are kernel version agnostic 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card sometimes this message was followed by storm of following messages: cx23885[0]: mpeg risc op code error This looks awfully like the bug that is fixed in commit 7675fe99d280ea83388a4382c54573c80db37cda. ... 2) [ cut here ] WARNING: CPU: 1 PID: 6946 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x55/0x72() CPU: 1 PID: 6946 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc01 #1 Hmm, and this says 3.19-rc3. I really need to know what kernel and media drivers you are using! Look above Yesterday I did git bisect on Linux media tree (v3.13 - HEAD) and found that your commit is guilty in the first message. Try with commit 7675fe99d280ea83388a4382c54573c80db37cda. Did not help. Same errors. I think the only relevant bug is #2. Just before Christmas I found some issues with the vb2 threading code, although that was for video output streams, not video capture. But it may well be that similar problems exist for capture. I'll look at that this week or early next week. I did new checks on 3.18.2 + https://github.com/ljalves/linux_media (media tree + few new TBS open source drivers) and found strange coincidence: I did two tests in following way: started w_scan on first front-end and after 5-10 seconds on second and after some time received first bug in both tests. Than just for fun reversed order. I did two tests in following way: started w_scan on second front-end and after 5-10 seconds on first and after some time received second bug followed after some time by first bug in both tests. Then I wanted to check following sequences: 1) init first front-end - start scan on second - start scan on first 2) init second front-end - start scan on first - start scan on second By init I mean: run dvb-fe-tool -sDVBS -a0 // or -a1 But on first test of first sequence I received new bug: [ 369.295899] BUG: unable to handle kernel NULL pointer dereference at(nil) [ 369.295945] IP: [c05173df] cx23885_buf_prepare+0x8c/0xa9 [cx23885] [ 369.295989] PGD 0 [ 369.296002] Oops: [#1] SMP [ 369.296020] Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx25840(O) snd_hda_codec_hdmi snd_usb_audio snd_hwdep uvcvideo(O) snd_usbmidi_lib videobuf2_vmalloc(O) snd_rawmidi ir_lirc_codec(O) ir_xmp_decoder(O) lirc_dev(O) ir_mce_kbd_decoder(O) ir_sharp_decoder(O) ir_sanyo_decoder(O) [ 369.296375] ir_sony_decoder(O) ir_jvc_decoder(O) ir_rc6_decoder(O) ir_rc5_decoder(O) ir_nec_decoder(O) rc_rc6_mce(O) mceusb(O) cx23885(O) tveeprom(O) cx2341x(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) videobuf2_memops(O) videobuf2_core(O) v4l2_common(O) videodev(O) k10temp rc_core(O) microcode saa716x_core(O) dvb_core(O) cx24117(O) i2c_piix4 snd_hda_intel snd_hda_controller snd_hda_codec r8169 mii nouveau ttm drm_kms_helper [ 369.296547] CPU: 0 PID: 7016 Comm: vb2-cx23885[0] Tainted: G O 3.18.1-hardened-r1-myrc06-NOSEC #1 [ 369.296574] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 [ 369.296601] task: 88020c720830 ti: 88020c720db0 task.ti: 88020c720db0 [ 369.296622] RIP: 0010:[c05173df] [c05173df]
[PATCH 1/2] r820t: enable flt_ext_wide for SYS_DVBC_ANNEX_A standard
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/tuners/r820t.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index 8e040cf..c94c6a3 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -969,7 +969,7 @@ static int r820t_set_tv_standard(struct r820t_priv *priv,
ext_enable = 0x40; /* r30[6]=1 ext enable; r30[5]:1 ext at
lna max-1 */
loop_through = 0x00;/* r5[7], lt on */
lt_att = 0x00; /* r31[7], lt att enable */
- flt_ext_widest = 0x00; /* r15[7]: flt_ext_wide off */
+ flt_ext_widest = 0x80; /* r15[7]: flt_ext_wide on */
polyfil_cur = 0x60; /* r25[6:5]:min */
} else {
if (bw = 6) {
--
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
[PATCH 2/2] r820t: add settings for SYS_DVBC_ANNEX_C standard
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/tuners/r820t.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index c94c6a3..b4c85ba 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -971,6 +971,18 @@ static int r820t_set_tv_standard(struct r820t_priv *priv,
lt_att = 0x00; /* r31[7], lt att enable */
flt_ext_widest = 0x80; /* r15[7]: flt_ext_wide on */
polyfil_cur = 0x60; /* r25[6:5]:min */
+ } else if (delsys == SYS_DVBC_ANNEX_C) {
+ if_khz = 4063;
+ filt_cal_lo = 55000;
+ filt_gain = 0x10; /* +3db, 6mhz on */
+ img_r = 0x00; /* image negative */
+ filt_q = 0x10; /* r10[4]:low q(1'b1) */
+ hp_cor = 0x6a; /* 1.7m disable, +0cap, 1.0mhz */
+ ext_enable = 0x40; /* r30[6]=1 ext enable; r30[5]:1 ext at
lna max-1 */
+ loop_through = 0x00;/* r5[7], lt on */
+ lt_att = 0x00; /* r31[7], lt att enable */
+ flt_ext_widest = 0x80; /* r15[7]: flt_ext_wide on */
+ polyfil_cur = 0x60; /* r25[6:5]:min */
} else {
if (bw = 6) {
if_khz = 3570;
--
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
m88ds3103 (in a DVBSky S960CI ) loses lock, does not re-gain by itself - unless FE_CAN_RECOVER is removed
Dear DVB-experts, since recently I own a DVBSky S960CI incorporating a m88ds3103. I am on 3.18.2 with two patches from 3.19 in (the S960 CI support + the dvb-usb-dvbsky: fix i2c adapter for sp2 device commit), using firmware 3.B for the m88ds3103. My card is connected to a Quad LNB, to which also two set-top-box receivers and a TV with internal receiver are wired. No extra multiswitch. The card locks fine and has good reception (szap-s2 output): status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK but whenever one of the three other devices connected to the same Quad LNB is turned on / off, the LOCK is lost and not regained unless I explicitly retune, e.g. by restarting szap-s2. Following an intuitive feeling, I removed FE_CAN_RECOVER from the static struct dvb_frontend_ops m88ds3103_ops.info.caps, thus activating the swzigzag-recover method in dvb-frontend.c which seems to be disabled by the CAN_RECOVER capability of a device. After rebuilding my kernel, the card now reacquires the lock by itself following the swzigzag procedure. Below the mail, you can find some debug output I captured with my kernel after removing FE_CAN_RECOVER. Is FE_CAN_RECOVER really true for this device? Is something broken in my setup (the LNB is only a few days old)? Is there a better solution, maybe it would be a good idea to have a generic fallback to swzigzag in any case even for (supposedly) FE_CAN_RECOVER-capable frontends if they do not recover on their own? I would be grateful for any advice on finally getting into a stable situation - I already own one Terratec S7 (for which the driver, or firmware, can not tune to S2 channels, but works fine with the Windows-driver) and an aparently broken TT3650CI which creates broken packages out of nowhere every few seconds (both Windows and Linux) and I am slowly running out of functional DVB-USB (with CI) hardware. Cheers and thanks for any help, Oliver -- $ ./szap-s2 -h -V -c ~/.mpv/channelsS2VDR.conf -r Das Erste HD;ARD -S1 reading channels from file '/home/olifre/.mpv/channelsS2VDR.conf' zapping to 209 'Das Erste HD;ARD': delivery DVB-S2, modulation 8PSK sat 0, frequency 11493 MHz H, symbolrate 2200, coderate 2/3, rolloff 0.35 stream_id -1 vpid 0x13ed, apid 0x13ee, sid 0x283d using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' Filtering for PID= 0x13ed Filtering for PID= 0x13ee status 00 | signal | snr 005a | ber | unc fffe | status 1f | signal c4e9 | snr 009c | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009c | ber | unc fffe | FE_HAS_LOCK ... putting one of the other receivers in standby ... status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 00 | signal c4e9 | snr 0075 | ber | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 00 | signal c4e9 | snr 0068 | ber 7e5f | unc fffe | status 1f | signal c4e9 | snr 008b | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0096 | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 7e5f | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009b | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0099 | ber 0001 | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 009a | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0097 | ber | unc fffe | FE_HAS_LOCK status 1f | signal c4e9 | snr 0093 | ber | unc fffe | FE_HAS_LOCK In kernel log with dyndebug on, from when lock was lost: ... Jan 12 19:55:19 alien17 kernel: [ 510.022420] i2c i2c-9: m88ds3103_read_status: lock=8f status=1f Jan 12 19:55:19 alien17 kernel: [ 510.022424] usb 1-1: dvb_frontend_swzigzag_update_delay: Jan 12 19:55:19 alien17 kernel: [ 510.545510] dvb_dmx_swfilter_packet: 46431 callbacks suppressed Jan 12 19:55:19 alien17 kernel: [ 510.545513] TEI detected. PID=0x13f7 data1=0x93 Jan 12 19:55:19 alien17 kernel: [ 510.545514] TEI detected. PID=0x12fb data1=0x92 Jan 12 19:55:19 alien17 kernel: [ 510.545515] TEI detected. PID=0x1c39 data1=0x9c Jan 12 19:55:19 alien17 kernel: [ 510.545516] TEI detected. PID=0xf6f data1=0xcf Jan 12 19:55:19 alien17 kernel: [ 510.545517] TEI detected. PID=0x14 data1=0xc0 Jan 12 19:55:19 alien17 kernel: [ 510.545518] TEI detected. PID=0x1a09 data1=0xba Jan 12 19:55:19 alien17 kernel: [ 510.545519] TEI detected. PID=0xc82 data1=0xec Jan 12 19:55:19 alien17 kernel: [ 510.545520] TEI detected. PID=0x1b5 data1=0xa1 Jan 12 19:55:19
Terratec Cinergy DVB-T Stick, Siano ID 187f:0600, no data from NIT(actual)
My USB dongle is recognized by the system but I have a problem with the channels. Please read all my post for any help ;-) At first, I used this guide: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers After that dmesg showed that system was searching for isdbt_rio.inp firmware. If I use that firmware from linuxtv.org, w_scan shows me an error, it says that my dongle can't search for TERRESTRIAL. So, for using smsmdtv mode DVB-T as the default option, I forced the kernel module in this way: echo options smsmdtv default_mode=0 | sudo tee /etc/modprobe.d/smsmdtv.conf After that system searches for dvb_rio.inp, good ;-) dmesg: [ 1327.312795] usb 1-3: new high-speed USB device number 4 using ehci-pci [ 1327.446103] usb 1-3: New USB device found, idVendor=187f, idProduct=0600 [ 1327.446121] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1327.446130] usb 1-3: Product: MDTV Receiver [ 1327.446138] usb 1-3: Manufacturer: MDTV Receiver [ 1327.451833] usb 1-3: Direct firmware load failed with error -2 [ 1327.451849] usb 1-3: Falling back to user helper [ 1327.456026] smscore_load_firmware_from_file: line: 1168: failed to open firmware file dvb_rio.inp [ 1327.456535] DVB: registering new adapter (Siano Rio Digital Receiver) [ 1327.457351] usb 1-3: DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... I used dvb_rio.inp from my Windows installation (md5: 146156b55ce6fc586470f28194add5a7, sha1: 48907a4749ba5fd5b4b947195c0d484e55a4c169). Now I have this output form lsusb: Bus 002 Device 002: ID 0402:7675 ALi Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 0489:e03c Foxconn / Hon Hai Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 187f:0600 Siano Mobile Silicon Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub dmesg: [ 1390.167433] usb 1-3: new high-speed USB device number 5 using ehci-pci [ 1390.300895] usb 1-3: New USB device found, idVendor=187f, idProduct=0600 [ 1390.300913] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1390.300922] usb 1-3: Product: MDTV Receiver [ 1390.300930] usb 1-3: Manufacturer: MDTV Receiver [ 1390.776240] DVB: registering new adapter (Siano Rio Digital Receiver) [ 1390.777275] usb 1-3: DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... lsmod | grep sms: smsdvb 27513 0 dvb_core 125880 1 smsdvb smsusb 17819 0 smsmdtv 53748 2 smsdvb,smsusb rc_core 27389 1 smsmdtv Finally I can scan and tune with a specific frequency but I can't obtain services from multiplexes. w_scan -c IT output: w_scan version 20130331 (compiled for DVB API 5.10) using settings for ITALY DVB aerial DVB-T Europe scan type TERRESTRIAL, channellist 4 output format vdr-2.0 WARNING: could not guess your codepage. Falling back to 'UTF-8' output charset 'UTF-8', use -C to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - TERRESTRIAL Siano Mobile Digital MDTV Receiver: good :-) Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0) Getting frontend capabilities Using DVB API 5.a frontend 'Siano Mobile Digital MDTV Receiver' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (44.25MHz ... 867.25MHz) ---_ Scanning 7MHz frequencies... 177500: (time: 00:00) (time: 00:01) signal ok: QAM_AUTO f = 177500 kHz I999B7C999D999T999G999Y999 Info: no data from NIT(actual) 184500: (time: 00:15) 191500: (time: 00:18) (time: 00:19) signal ok: QAM_AUTO f = 191500 kHz I999B7C999D999T999G999Y999 Info: no data from NIT(actual) 198500: (time: 00:33) 205500: (time: 00:36) ... ... I created a file named frequency with this content for doing a test: # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 17750 7MHz 2/3 NONE QAM64 8k 1/8 NONE # MUX-B Rai T 69800 8MHz 2/3 NONE QAM64 8k 1/8 NONE # Mediaset 1 and when I launch dvbscan frequency I obtain: Unable to query frontend status. With the utility scan I obtain: scanning frequency using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 17750 1 2 9 3 1 2 0 initial transponder 69800 0 2 9 3 1 2 0 tune to: 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 dumping lists (0 services) Done. WIth dvbv5-scan frequency: ERROR key/value without a channel group while parsing line 3 of frequency. I tried to
Re: [PATCH v2 2/3] media: au0828 change to not zero out fmt.pix.priv
On 01/12/2015 06:58 AM, Hans Verkuil wrote: My first code review of the new year, so let's start with a simple one to avoid taxing my brain cells (that are still in vacation mode) too much... On 12/18/2014 05:20 PM, Shuah Khan wrote: There is no need to zero out fmt.pix.priv in vidioc_g_fmt_vid_cap() vidioc_try_fmt_vid_cap(), and vidioc_s_fmt_vid_cap(). Remove it. Signed-off-by: Shuah Khan shua...@osg.samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Jan 13 04:00:14 CET 2015 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.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: 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: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mn88473: simplify bandwidth registers setting code
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/staging/media/mn88473/mn88473.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index b65e519..994294c 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -59,28 +59,13 @@ static int mn88473_set_frontend(struct dvb_frontend *fe)
goto err;
}
- switch (c-delivery_system) {
- case SYS_DVBT:
- case SYS_DVBT2:
- if (c-bandwidth_hz = 600) {
- /* IF 357 Hz, BW 600 Hz */
- memcpy(bw_val, \xe9\x55\x55\x1c\x29\x1c\x29, 7);
- } else if (c-bandwidth_hz = 700) {
- /* IF 457 Hz, BW 700 Hz */
- memcpy(bw_val, \xc8\x00\x00\x17\x0a\x17\x0a, 7);
- } else if (c-bandwidth_hz = 800) {
- /* IF 457 Hz, BW 800 Hz */
- memcpy(bw_val, \xaf\x00\x00\x11\xec\x11\xec, 7);
- } else {
- ret = -EINVAL;
- goto err;
- }
- break;
- case SYS_DVBC_ANNEX_A:
- /* IF 507 Hz, BW 800 Hz */
+ if (c-bandwidth_hz = 600) {
+ memcpy(bw_val, \xe9\x55\x55\x1c\x29\x1c\x29, 7);
+ } else if (c-bandwidth_hz = 700) {
+ memcpy(bw_val, \xc8\x00\x00\x17\x0a\x17\x0a, 7);
+ } else if (c-bandwidth_hz = 800) {
memcpy(bw_val, \xaf\x00\x00\x11\xec\x11\xec, 7);
- break;
- default:
+ } else {
ret = -EINVAL;
goto err;
}
--
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: [PATCH v2 1/3] media: au0828 - convert to use videobuf2
On 01/12/2015 07:19 AM, Hans Verkuil wrote:
On 12/18/2014 05:20 PM, Shuah Khan wrote:
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no new regressions in video and vbi now has 3 fewer
failures.
video before:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
vbi before:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test USERPTR: OK
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-cards.c | 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 949
+---
drivers/media/usb/au0828/au0828.h | 61 +-
5 files changed, 444 insertions(+), 692 deletions(-)
diff --git a/drivers/media/usb/au0828/Kconfig
b/drivers/media/usb/au0828/Kconfig
index 1d410ac..78b797e 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
-select VIDEOBUF_VMALLOC
+select VIDEOBUF2_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 9eb77ac..ae2e563 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -39,7 +39,7 @@ static void hvr950q_cs5340_audio(void *priv, int enable)
struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name = Unknown board,
-.tuner_type = UNSET,
+.tuner_type = -1U,
.tuner_addr = ADDR_UNSET,
},
[AU0828_BOARD_HAUPPAUGE_HVR850] = {
I would split off this au0828-cards.c change into a separate patch. It has
nothing to
do with the vb2 conversion.
I will split this patch and add it to the series.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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/2] mn88473: calculate the IF register values
Add xtal as a configuration parameter so it can be used
in the IF register value calculation. If not set in the
configuration then use a default value.
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/dvb-frontends/mn88473.h| 6 ++
drivers/staging/media/mn88473/mn88473.c | 26 +++---
drivers/staging/media/mn88473/mn88473_priv.h | 1 +
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb-frontends/mn88473.h
b/drivers/media/dvb-frontends/mn88473.h
index a373ec9..c717ebed 100644
--- a/drivers/media/dvb-frontends/mn88473.h
+++ b/drivers/media/dvb-frontends/mn88473.h
@@ -33,6 +33,12 @@ struct mn88473_config {
* DVB frontend.
*/
struct dvb_frontend **fe;
+
+ /*
+* Xtal frequency.
+* Hz
+*/
+ u32 xtal;
};
#endif
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index 1659335..b65e519 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -30,6 +30,7 @@ static int mn88473_set_frontend(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret, i;
u32 if_frequency;
+ u64 tmp;
u8 delivery_system_val, if_val[3], bw_val[7];
dev_dbg(client-dev,
@@ -63,15 +64,12 @@ static int mn88473_set_frontend(struct dvb_frontend *fe)
case SYS_DVBT2:
if (c-bandwidth_hz = 600) {
/* IF 357 Hz, BW 600 Hz */
- memcpy(if_val, \x24\x8e\x8a, 3);
memcpy(bw_val, \xe9\x55\x55\x1c\x29\x1c\x29, 7);
} else if (c-bandwidth_hz = 700) {
/* IF 457 Hz, BW 700 Hz */
- memcpy(if_val, \x2e\xcb\xfb, 3);
memcpy(bw_val, \xc8\x00\x00\x17\x0a\x17\x0a, 7);
} else if (c-bandwidth_hz = 800) {
/* IF 457 Hz, BW 800 Hz */
- memcpy(if_val, \x2e\xcb\xfb, 3);
memcpy(bw_val, \xaf\x00\x00\x11\xec\x11\xec, 7);
} else {
ret = -EINVAL;
@@ -80,7 +78,6 @@ static int mn88473_set_frontend(struct dvb_frontend *fe)
break;
case SYS_DVBC_ANNEX_A:
/* IF 507 Hz, BW 800 Hz */
- memcpy(if_val, \x33\xea\xb3, 3);
memcpy(bw_val, \xaf\x00\x00\x11\xec\x11\xec, 7);
break;
default:
@@ -105,17 +102,12 @@ static int mn88473_set_frontend(struct dvb_frontend *fe)
if_frequency = 0;
}
- switch (if_frequency) {
- case 357:
- case 457:
- case 507:
- break;
- default:
- dev_err(client-dev, IF frequency %d not supported\n,
- if_frequency);
- ret = -EINVAL;
- goto err;
- }
+ /* Calculate IF registers ( (124)*IF / Xtal ) */
+ tmp = div_u64(if_frequency * (u64)(124) + (dev-xtal / 2),
+ dev-xtal);
+ if_val[0] = ((tmp 16) 0xff);
+ if_val[1] = ((tmp 8) 0xff);
+ if_val[2] = ((tmp 0) 0xff);
ret = regmap_write(dev-regmap[2], 0x05, 0x00);
ret = regmap_write(dev-regmap[2], 0xfb, 0x13);
@@ -352,6 +344,10 @@ static int mn88473_probe(struct i2c_client *client,
}
dev-i2c_wr_max = config-i2c_wr_max;
+ if (!config-xtal)
+ dev-xtal = 2500;
+ else
+ dev-xtal = config-xtal;
dev-client[0] = client;
dev-regmap[0] = regmap_init_i2c(dev-client[0], regmap_config);
if (IS_ERR(dev-regmap[0])) {
diff --git a/drivers/staging/media/mn88473/mn88473_priv.h
b/drivers/staging/media/mn88473/mn88473_priv.h
index 78af112..ef6f013 100644
--- a/drivers/staging/media/mn88473/mn88473_priv.h
+++ b/drivers/staging/media/mn88473/mn88473_priv.h
@@ -31,6 +31,7 @@ struct mn88473_dev {
u16 i2c_wr_max;
fe_delivery_system_t delivery_system;
bool warm; /* FW running */
+ u32 xtal;
};
#endif
--
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: [PATCH v2 3/3] media: au0828 remove video and vbi buffer timeout work-around
On 01/12/2015 07:10 AM, Hans Verkuil wrote: On 12/18/2014 05:20 PM, Shuah Khan wrote: au0828 does video and vbi buffer timeout handling to prevent applications such as tvtime from hanging by ensuring that the video frames continue to be delivered even when the ITU-656 input isn't receiving any data. This work-around is complex as it introduces set and clear tier code paths in start/stop streaming, and close interfaces. After the vb2 conversion, the timeout handling is introducing instability as well as feeding too many blank green screens, resulting in degraded video quality. Why would this result in degraded video quality? And which instability exactly? What I noticed was that I was seeing a few too many green screens and I had to re-tune xawtv when the timeout code is in place. My thinking was that this timeout handling could be introducing blank green frames when there is no need. However, I can't reproduce the problem on 3.19-rc4 base which is what I am using to test the changes to the patch series. Hence, I am not positive if the timeout code indeed was doing anything bad. Without this timeout handling, both xawtv, and tvtime are working well with good quality video. I am seeing tvtime hangs. Erm, tvtime without the recent 'tvtime: don't block indefinitely waiting for frames' patch will not work well with au0828 without the timeout code if there is no valid video data. This should at minimum be mentioned in the commit log. I will resend the patch with the updated commit log knowing full well that it might not be accepted. I do have to re-cut the patch after the changes to address your comments on the vb2 conversion patch. It applies, with fuzz, so I decided to re-cut the patch. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] media: fix au0828 compile error from au0828_boards initialization
au0828 picked up UNSET from videobuf-core.h and fails to compile
if videobuf-core.h isn't included. Change it to use -1U instead
to fix the problem.
drivers/media/usb/au0828/au0828-cards.c:47:17: error: ‘UNSET’ undeclared
here (not in a function)
.tuner_type = UNSET,
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-cards.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index da87f1c..edc2735 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -44,7 +44,7 @@ static void hvr950q_cs5340_audio(void *priv, int enable)
struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name = Unknown board,
- .tuner_type = UNSET,
+ .tuner_type = -1U,
.tuner_addr = ADDR_UNSET,
},
[AU0828_BOARD_HAUPPAUGE_HVR850] = {
--
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
[PATCH v3 2/3] media: au0828 - convert to use videobuf2
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no regressions. video now has no failures and vbi
has 3 fewer failures.
video before:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
Total: 72, Succeeded: 72, Failed: 0, Warnings: 18
vbi before:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_QUERYCAP: FAIL
test MMAP: FAIL
Total: 78, Succeeded: 75, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 962
drivers/media/usb/au0828/au0828.h | 61 +-
4 files changed, 443 insertions(+), 704 deletions(-)
diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 1d410ac..78b797e 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
- select VIDEOBUF_VMALLOC
+ select VIDEOBUF2_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/au0828/au0828-vbi.c
b/drivers/media/usb/au0828/au0828-vbi.c
index 932d24f..f67247c 100644
--- a/drivers/media/usb/au0828/au0828-vbi.c
+++ b/drivers/media/usb/au0828/au0828-vbi.c
@@ -28,111 +28,67 @@
#include linux/init.h
#include linux/slab.h
-static unsigned int vbibufs = 5;
-module_param(vbibufs, int, 0644);
-MODULE_PARM_DESC(vbibufs, number of vbi buffers, range 2-32);
-
/* -- */
-static void
-free_buffer(struct videobuf_queue *vq, struct au0828_buffer *buf)
+static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct au0828_fh *fh = vq-priv_data;
- struct au0828_dev*dev = fh-dev;
- unsigned long flags = 0;
- if (in_interrupt())
- BUG();
-
- /* We used to wait for the buffer to finish here, but this didn't work
- because, as we were keeping the state as VIDEOBUF_QUEUED,
- videobuf_queue_cancel marked it as finished for us.
- (Also, it could wedge forever if the hardware was misconfigured.)
-
- This should be safe; by the time we get here, the buffer isn't
- queued anymore. If we ever start marking the buffers as
- VIDEOBUF_ACTIVE, it won't be, though.
- */
- spin_lock_irqsave(dev-slock, flags);
- if (dev-isoc_ctl.vbi_buf == buf)
- dev-isoc_ctl.vbi_buf = NULL;
- spin_unlock_irqrestore(dev-slock, flags);
+ struct au0828_dev *dev = vb2_get_drv_priv(vq);
+ unsigned long img_size = dev-vbi_width * dev-vbi_height * 2;
+ unsigned long size;
- videobuf_vmalloc_free(buf-vb);
- buf-vb.state = VIDEOBUF_NEEDS_INIT;
-}
-
-static int
-vbi_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size)
-{
- struct au0828_fh *fh = q-priv_data;
- struct au0828_dev*dev = fh-dev;
+ size = fmt ? (fmt-fmt.vbi.samples_per_line *
+ (fmt-fmt.vbi.count[0] + fmt-fmt.vbi.count[1])) : img_size;
+ if (size img_size)
+ return -EINVAL;
- *size = dev-vbi_width * dev-vbi_height * 2;
+ *nplanes = 1;
+ sizes[0] = size;
- if (0 == *count)
- *count = vbibufs;
- if (*count 2)
- *count = 2;
- if (*count 32)
- *count = 32;
return 0;
}
-static int
-vbi_prepare(struct videobuf_queue *q, struct videobuf_buffer *vb,
- enum v4l2_field field)
+static int vbi_buffer_prepare(struct vb2_buffer *vb)
{
- struct au0828_fh *fh = q-priv_data;
- struct au0828_dev*dev = fh-dev;
+ struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
- int rc = 0;
+ unsigned long size;
- buf-vb.size = dev-vbi_width * dev-vbi_height * 2;
+ size = dev-vbi_width * dev-vbi_height * 2;
- if (0 != buf-vb.baddrbuf-vb.bsize buf-vb.size)
+ if (vb2_plane_size(vb, 0) size) {
+ pr_err(%s data will not fit into plane (%lu %lu)\n,
+ __func__, vb2_plane_size(vb, 0), size);
return -EINVAL;
-
-
[PATCH v3 0/3] au0828 vb2 conversion
This patch series includes patch v3 of the au0828 vb2 conversion, removing video and vbi buffer timeout handling, and a patch to fix compile error from au0828_boards initialization which uses a a define from videobuf-core.h which is no longer included with the vb2 conversion change. The following work is in progress and will be done as separate patches: - removing users and using v4l2_fh_is_singular_file() instead. - Changing dynamic allocation of video device structs to static which will reduce the overhead to allocate at register time and deallocating at unregister. - New v4l2-compliance tool showed warnings on try_fmt and s_fmt because the driver doesn't return error in all cases. Changes from patch v2: - Dropped already acked from the v3 series [PATCH v2 2/3] media: au0828 change to not zero out fmt.pix.priv - Split compile error fix and vb2 conversion patches - Made changes to vb2 conversion patch to address comments on v2 patch. - Updated commit log for remove video and vbi buffer timeout work-around patch - Rebased and tested patches on 3.19-rc4 Shuah Khan (3): media: fix au0828 compile error from au0828_boards initialization media: au0828 - convert to use videobuf2 media: au0828 remove video and vbi buffer timeout work-around drivers/media/usb/au0828/Kconfig|2 +- drivers/media/usb/au082e/au0828-cards.c |2 +- drivers/media/usb/au0828/au0828-vbi.c | 122 ++-- drivers/media/usb/au0828/au0828-video.c | 1005 +++ drivers/media/usb/au0828/au0828.h | 64 +- 5 files changed, 414 insertions(+), 781 deletions(-) -- 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
[PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around
au0828 does video and vbi buffer timeout handling to prevent
applications such as tvtime from hanging by ensuring that the
video frames continue to be delivered even when the ITU-656
input isn't receiving any data. This work-around is complex
as it introduces set and clear timer code paths in start/stop
streaming, and close interfaces. However, tvtime will hang
without the following tvtime change:
'tvtime: don't block indefinitely waiting for frames' with
this change to remove timeout, if there is no valid video data.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-video.c | 103 +---
drivers/media/usb/au0828/au0828.h | 5 --
2 files changed, 1 insertion(+), 107 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index e427913..08b1e96 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -592,15 +592,6 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev,
struct urb *urb)
outp = NULL;
else
outp = vb2_plane_vaddr(buf-vb, 0);
-
- /* As long as isoc traffic is arriving, keep
- resetting the timer */
- if (dev-vid_timeout_running)
- mod_timer(dev-vid_timeout,
- jiffies + (HZ / 10));
- if (dev-vbi_timeout_running)
- mod_timer(dev-vbi_timeout,
- jiffies + (HZ / 10));
}
if (buf != NULL) {
@@ -803,15 +794,9 @@ int au0828_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
return rc;
}
- if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
v4l2_device_call_all(dev-v4l2_dev, 0, video,
s_stream, 1);
- dev-vid_timeout_running = 1;
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
- } else if (vq-type == V4L2_BUF_TYPE_VBI_CAPTURE) {
- dev-vbi_timeout_running = 1;
- mod_timer(dev-vbi_timeout, jiffies + (HZ / 10));
- }
}
dev-streaming_users++;
return rc;
@@ -850,9 +835,6 @@ static void au0828_stop_streaming(struct vb2_queue *vq)
(AUVI_INPUT(i).audio_setup)(dev, 0);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vid_timeout_running = 0;
- del_timer_sync(dev-vid_timeout);
}
void au0828_stop_vbi_streaming(struct vb2_queue *vq)
@@ -881,9 +863,6 @@ void au0828_stop_vbi_streaming(struct vb2_queue *vq)
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vbi_timeout_running = 0;
- del_timer_sync(dev-vbi_timeout);
}
static struct vb2_ops au0828_video_qops = {
@@ -916,56 +895,6 @@ void au0828_analog_unregister(struct au0828_dev *dev)
mutex_unlock(au0828_sysfs_lock);
}
-/* This function ensures that video frames continue to be delivered even if
- the ITU-656 input isn't receiving any data (thereby preventing applications
- such as tvtime from hanging) */
-static void au0828_vid_buffer_timeout(unsigned long data)
-{
- struct au0828_dev *dev = (struct au0828_dev *) data;
- struct au0828_dmaqueue *dma_q = dev-vidq;
- struct au0828_buffer *buf;
- unsigned char *vid_data;
- unsigned long flags = 0;
-
- spin_lock_irqsave(dev-slock, flags);
-
- buf = dev-isoc_ctl.buf;
- if (buf != NULL) {
- vid_data = vb2_plane_vaddr(buf-vb, 0);
- memset(vid_data, 0x00, buf-length); /* Blank green frame */
- buffer_filled(dev, dma_q, buf);
- }
- get_next_buf(dma_q, buf);
-
- if (dev-vid_timeout_running == 1)
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
-
- spin_unlock_irqrestore(dev-slock, flags);
-}
-
-static void au0828_vbi_buffer_timeout(unsigned long data)
-{
- struct au0828_dev *dev = (struct au0828_dev *) data;
- struct au0828_dmaqueue *dma_q = dev-vbiq;
- struct au0828_buffer *buf;
- unsigned char *vbi_data;
- unsigned long flags = 0;
-
- spin_lock_irqsave(dev-slock, flags);
-
- buf = dev-isoc_ctl.vbi_buf;
- if (buf != NULL) {
- vbi_data = vb2_plane_vaddr(buf-vb, 0);
- memset(vbi_data, 0x00, buf-length);
- vbi_buffer_filled(dev, dma_q, buf);
- }
- vbi_get_next_buf(dma_q, buf);
-
- if
Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around
Hi Shuah, On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan shua...@osg.samsung.com wrote: au0828 does video and vbi buffer timeout handling to prevent applications such as tvtime from hanging by ensuring that the video frames continue to be delivered even when the ITU-656 input isn't receiving any data. This work-around is complex as it introduces set and clear timer code paths in start/stop streaming, and close interfaces. However, tvtime will hang without the following tvtime change: I'm confused. When we last debated whether this patch would be accepted, the last message from Mauro said the following: That means that we'll need to keep holding such timeout code for years, until all distros update to a new tvtime, of course assuming that this is the only one application with such issue. In other words, the timeout code has to stay in there since otherwise it will cause ABI breakage. It's great that Hans has submitted a patch to improve tvtime, and over the next couple of years that patch might actually start to appear in distributions. That unfortunately doesn't change the fact that everybody who updates their kernel (or has it updated for them as part of their distribution) will go from works fine to completely broken. The driver was working before the VB2 conversion, so if there is now instability then it's likely that some bug was introduced during the conversion to VB2. Simply ripping out the timeout code seems like the wrong approach to addressing a regression likely caused by your own VB2 conversion patch. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 01/09/2015 07:33 PM, Rob Herring wrote: On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Add a property for defining the device outputs the LED represented by the DT child node is connected to. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org --- Documentation/devicetree/bindings/leds/common.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index a2c3f7a..29295bf 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -1,6 +1,10 @@ Common leds properties. Optional properties for child nodes: +- led-sources : Array of bits signifying the LED current regulator outputs the + LED represented by the child node is connected to (1 - the LED + is connected to the output, 0 - the LED isn't connected to the + output). Sorry, I just don't understand this. In some Flash LED devices one LED can be connected to one or more electric current outputs, which allows for multiplying the maximum current allowed for the LED. Each sub-LED is represented by a child node in the DT binding of the Flash LED device and it needs to declare which outputs it is connected to. In the example below the led-sources property is a two element array, which means that the flash LED device has two current outputs, and the bits signify if the LED is connected to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). Do you think of drivers/leds/leds-regulator.c driver? This driver just allows for registering an arbitrary regulator device as a LED subsystem device. There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. Please use the regulator binding. Do your doubts stem from the ambiguity of the word current or the form of the description itself is unclear? Probably there should be explicit explanation added that the size of the array depends on the number of current outputs of the flash LED device. The size of the array and meaning of array indexes was not clear. What about this: led-sources : Array of connection states between all LED current sources exposed by the device and this LED (1 - this LED is connected to the current output with index N, 0 - this LED isn't connected to the current output with index N); the mapping of N-th element of the array to the physical device output should be defined in the LED driver binding. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
randconfig build error with next-20150112, in drivers/media/usb/gspca
Building with the attached random configuration file, drivers/built-in.o: In function `gspca_dev_probe2': (.text+0x124915): undefined reference to `input_allocate_device' drivers/built-in.o: In function `gspca_dev_probe2': (.text+0x1249c1): undefined reference to `input_register_device' drivers/built-in.o: In function `gspca_dev_probe2': (.text+0x1249d8): undefined reference to `input_free_device' drivers/built-in.o: In function `gspca_dev_probe2': (.text+0x1249f6): undefined reference to `input_unregister_device' drivers/built-in.o: In function `gspca_disconnect': (.text+0x124b2e): undefined reference to `input_unregister_device' drivers/built-in.o: In function `sd_int_pkt_scan': pac7311.c:(.text+0x1295f9): undefined reference to `input_event' pac7311.c:(.text+0x12960f): undefined reference to `input_event' pac7311.c:(.text+0x12962b): undefined reference to `input_event' pac7311.c:(.text+0x129641): undefined reference to `input_event' drivers/built-in.o: In function `sd_int_pkt_scan': sonixb.c:(.text+0x12a12b): undefined reference to `input_event' drivers/built-in.o:sonixb.c:(.text+0x12a141): more undefined references to `input_event' follow make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.19.0-rc4 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SYSVIPC is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_KTHREAD_PRIO=1 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set
Re: videobuf2_core oops, recent media_build. dvbsky t980c's
Hi Hans, On Mon, 2015-01-12 at 16:29 +0100, Hans Verkuil wrote: On 12/29/2014 03:38 PM, Jurgen Kramer wrote: On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? The problem persist while my system went through a motherboard/mem/cpu upgrade. The oops occurs when one of the DVB-C cards get its first use (in my case mythtv): [ 102.050294] si2157 18-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 181.460991] IP: [a04d833a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 181.461019] PGD 0 [ 181.461024] Oops: 0002 [#1] SMP [ 181.461032] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
Adding Mark B and Liam... On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 01/09/2015 07:33 PM, Rob Herring wrote: On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: Add a property for defining the device outputs the LED represented by the DT child node is connected to. [...] b/Documentation/devicetree/bindings/leds/common.txt index a2c3f7a..29295bf 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -1,6 +1,10 @@ Common leds properties. Optional properties for child nodes: +- led-sources : Array of bits signifying the LED current regulator outputs the + LED represented by the child node is connected to (1 - the LED + is connected to the output, 0 - the LED isn't connected to the + output). Sorry, I just don't understand this. In some Flash LED devices one LED can be connected to one or more electric current outputs, which allows for multiplying the maximum current allowed for the LED. Each sub-LED is represented by a child node in the DT binding of the Flash LED device and it needs to declare which outputs it is connected to. In the example below the led-sources property is a two element array, which means that the flash LED device has two current outputs, and the bits signify if the LED is connected to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). Do you think of drivers/leds/leds-regulator.c driver? This driver just allows for registering an arbitrary regulator device as a LED subsystem device. There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = led-reg0, led-reg1, led-reg2, led-reg3; The shared source is already supported by the regulator binding. Rob Please use the regulator binding. Do your doubts stem from the ambiguity of the word current or the form of the description itself is unclear? Probably there should be explicit explanation added that the size of the array depends on the number of current outputs of the flash LED device. The size of the array and meaning of array indexes was not clear. What about this: led-sources : Array of connection states between all LED current sources exposed by the device and this LED (1 - this LED is connected to the current output with index N, 0 - this LED isn't connected to the current output with index N); the mapping of N-th element of the array to the physical device output should be defined in the LED driver binding. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote: On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski There are however devices that don't fall into this category, i.e. they have many outputs, that can be connected to a single LED or to many LEDs and the driver has to know what is the actual arrangement. We may need to extend the regulator binding slightly and allow for multiple phandles on a supply property, but wouldn't something like this work: led-supply = led-reg0, led-reg1, led-reg2, led-reg3; The shared source is already supported by the regulator binding. What is the reasoning for this? If a single supply is being supplied by multiple regulators then in general those regulators will all know about each other at a hardware level and so from a functional and software point of view will effectively be one regulator. If they don't/aren't then they tend to interfere with each other. signature.asc Description: Digital signature
