Re: [PATCH 00/24] Various HVR-950q and xc5000 fixes
Hi Devin! On Tue August 7 2012 04:46:50 Devin Heitmueller wrote: This patch series contains fixes for a variety of problems found in the HVR-950q as well as the xc5000 driver. Details can be found in the individual patches, but it is worth mentioning specifically that this addresses the MythTV problem causing BUG() to occur, firmware loading is now significantly improved, and we now have a redistributable version for the xc5000c firmware. Since you're working on the au0828 would it perhaps be possible to have that driver use unlocked_ioctl instead of ioctl? It would be really nice if we can get rid of the ioctl v4l2_operation at some point in the future. Regards, Hans Devin Heitmueller (24): au8522: fix intermittent lockup of analog video decoder au8522: Fix off-by-one in SNR table for QAM256 au8522: properly recover from the au8522 delivering misaligned TS streams au0828: Make the s_reg and g_reg advanced debug calls work against the bridge xc5000: properly show quality register values xc5000: add support for showing the SNR and gain in the debug output xc5000: properly report i2c write failures au0828: fix race condition that causes xc5000 to not bind for digital au0828: make sure video standard is setup in tuner-core au8522: fix regression in logging introduced by separation of modules xc5000: don't invoke auto calibration unless we really did reset tuner au0828: prevent i2c gate from being kept open while in analog mode au0828: fix case where STREAMOFF being called on stopped stream causes BUG() au0828: speed up i2c clock when doing xc5000 firmware load au0828: remove control buffer from send_control_msg au0828: tune retry interval for i2c interaction au0828: fix possible race condition in usage of dev-ctrlmsg xc5000: reset device if encountering PLL lock failure xc5000: add support for firmware load check and init status au0828: tweak workaround for i2c clock stretching bug xc5000: show debug version fields in decimal instead of hex au0828: fix a couple of missed edge cases for i2c gate with analog au0828: make xc5000 firmware speedup apply to the xc5000c as well xc5000: change filename to production/redistributable xc5000c firmware drivers/media/common/tuners/xc5000.c | 161 +- drivers/media/dvb/frontends/au8522_common.c | 22 +++- drivers/media/dvb/frontends/au8522_decoder.c | 11 +- drivers/media/dvb/frontends/au8522_dig.c | 98 drivers/media/dvb/frontends/au8522_priv.h| 29 - drivers/media/video/au0828/au0828-cards.c|4 +- drivers/media/video/au0828/au0828-core.c | 59 -- drivers/media/video/au0828/au0828-dvb.c | 54 - drivers/media/video/au0828/au0828-i2c.c | 21 +++- drivers/media/video/au0828/au0828-reg.h |1 + drivers/media/video/au0828/au0828-video.c| 76 +--- drivers/media/video/au0828/au0828.h |2 + 12 files changed, 379 insertions(+), 159 deletions(-) -- 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: Vacations.
On Fri, Aug 03, 2012 at 05:09:15PM +0200, Guennadi Liakhovetski wrote: Hi Javier On Fri, 3 Aug 2012, javier Martin wrote: Hi, I will be out of the office until August the 19th. I just wanted to send a reminder of some patches that I have pending. For Mauro 3.7: [PULL] video_visstrim for 3.6 [PATCH] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks. For Guennadi: [PATCH 1/4] i.MX27: Fix emma-prp and csi clocks. As I mentioned several times, the above patch is not for me. Have a nice vacation. Indeed it's for me. Queued this up. Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [3.0.y+] [media] Avoid sysfs oops when an rc_dev's raw device is absent
Ben Hutchings wrote:
This returns without unlocking dev-lock, which isn't much of an
improvement. Please get that fixed in mainline, and then I can apply
both of the changes to 3.2.y at once.
Oh dear. Quite right. Sorry. Thanks.
Douglas
From c1d4df58efb2d13551586d177bcbb4e9af588618 Mon Sep 17 00:00:00 2001
From: Douglas Bagnall doug...@paradise.net.nz
Date: Tue, 7 Aug 2012 19:30:36 +1200
Subject: [PATCH] Unlock the rc_dev lock when the raw device is missing
As pointed out by Ben Hutchings, after commit 720bb6436, the lock was
being taken and not released when an rc_dev has a NULL raw device.
Signed-off-by: Douglas Bagnall doug...@paradise.net.nz
---
drivers/media/rc/rc-main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index cabc19c..dcd45d0 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -778,9 +778,10 @@ static ssize_t show_protocols(struct device *device,
} else if (dev-raw) {
enabled = dev-raw-enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
- } else
+ } else {
+ mutex_unlock(dev-lock);
return -ENODEV;
-
+ }
IR_dprintk(1, allowed - 0x%llx, enabled - 0x%llx\n,
(long long)allowed,
(long long)enabled);
--
1.7.9.5
Re: [PATCH] uvcvideo: Fix uvc_fixup_video_ctrl() format search
Hi Laurent,
On 19/02/11 12:35, Laurent Pinchart wrote:
Hi Stephan,
On Friday 28 January 2011 03:04:33 Stephan Lachowsky wrote:
The scheme used to index format in uvc_fixup_video_ctrl() is not robust:
format index is based on descriptor ordering, which does not necessarily
match bFormatIndex ordering. Searching for first matching format will
prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make
adjustments.
Thanks for the patch. It's missing your Signed-off-by line, can I add it ?
Sorry for the late reply, you certainly may.
---
drivers/media/video/uvc/uvc_video.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c index 5673d67..545c029 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -89,15 +89,19 @@ int uvc_query_ctrl(struct uvc_device *dev, __u8 query,
__u8 unit, static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl)
{
- struct uvc_format *format;
+ struct uvc_format *format = NULL;
struct uvc_frame *frame = NULL;
unsigned int i;
- if (ctrl-bFormatIndex = 0 ||
- ctrl-bFormatIndex stream-nformats)
- return;
+ for (i = 0; i stream-nformats; ++i) {
+ if (stream-format[i].index == ctrl-bFormatIndex) {
+ format = stream-format[i];
+ break;
+ }
+ }
- format = stream-format[ctrl-bFormatIndex - 1];
+ if (format == NULL)
+ return;
for (i = 0; i format-nframes; ++i) {
if (format-frame[i].bFrameIndex == ctrl-bFrameIndex) {
--
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] m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode
Fixes following warnings on 64-bit architectures:
m5mols.h: In function 'm5mols_set_ctrl_mode':
m5mols.h:326:15: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
m5mols.h: In function 'm5mols_get_ctrl_mode':
m5mols.h:331:9: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
drivers/media/video/m5mols/m5mols_controls.c:466:2: warning: cast
from pointer to integer of different size
Cc: Heungjun Kim riverful@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/m5mols/m5mols.h |4 ++--
drivers/media/video/m5mols/m5mols_controls.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
index bb58991..527e7b2 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -323,12 +323,12 @@ static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl
*ctrl)
static inline void m5mols_set_ctrl_mode(struct v4l2_ctrl *ctrl,
unsigned int mode)
{
- ctrl-priv = (void *)mode;
+ ctrl-priv = (void *)(uintptr_t)mode;
}
static inline unsigned int m5mols_get_ctrl_mode(struct v4l2_ctrl *ctrl)
{
- return (unsigned int)ctrl-priv;
+ return (unsigned int)(uintptr_t)ctrl-priv;
}
#endif /* M5MOLS_H */
diff --git a/drivers/media/video/m5mols/m5mols_controls.c
b/drivers/media/video/m5mols/m5mols_controls.c
index fdbc205..f34429e 100644
--- a/drivers/media/video/m5mols/m5mols_controls.c
+++ b/drivers/media/video/m5mols/m5mols_controls.c
@@ -463,8 +463,8 @@ static int m5mols_s_ctrl(struct v4l2_ctrl *ctrl)
return 0;
}
- v4l2_dbg(1, m5mols_debug, sd, %s: %s, val: %d, priv: %#x\n,
-__func__, ctrl-name, ctrl-val, (int)ctrl-priv);
+ v4l2_dbg(1, m5mols_debug, sd, %s: %s, val: %d, priv: %p\n,
+__func__, ctrl-name, ctrl-val, ctrl-priv);
if (ctrl_mode ctrl_mode != info-mode) {
ret = m5mols_set_mode(info, ctrl_mode);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: fix MEDIA_IOC_DEVICE_INFO return code
The MEDIA_IOC_DEVICE_INFO ioctl was returning a positive value rather than a negative error code when failing to copy output parameter to user-space. Tested by compilation only. Signed-off-by: Nicolas Thery nicolas.th...@st.com --- drivers/media/media-device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 6f9eb94..d01fcb7 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -59,7 +59,9 @@ static int media_device_get_info(struct media_device *dev, info.hw_revision = dev-hw_revision; info.driver_version = dev-driver_version; - return copy_to_user(__info, info, sizeof(*__info)); + if (copy_to_user(__info, info, sizeof(*__info))) + return -EFAULT; + return 0; } static struct media_entity *find_entity(struct media_device *mdev, u32 id) -- 1.7.11.3 -- 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] omap_vout: Set DSS overlay_info only if paddr is non zero
On Thursday 28 June 2012 11:36:48 Semwal, Sumit wrote:
On Mon, Mar 19, 2012 at 5:16 PM, Archit Taneja a0393...@ti.com wrote:
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info() when the physical address for the overlay is still
not configured. This happens in omap_vout_probe() and
vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info())
are removed from these functions. They don't need to be called as the
omap_vout_device struct anyway maintains the overlay related changes
made. Also, remove the explicit call to set_overlay_info() in
vidioc_streamon(), this was used to set the paddr, this isn't needed
as omapvid_init() does the same thing later.
These changes are required as the DSS2 driver since 3.3 kernel
doesn't let you set the overlay info with paddr as 0.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36 ---
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinentomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change
mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request
based on master branch.
Okay. Thanks for looking into this.
Archit
Hi Vaibhav,
This patch has been outstanding since March, and we have received
reports from various users. Could you please push it ASAP to Mauro for
the upcoming -rc?
I second this request. Vaibhav, could you please take care of this ?
Or Did I miss a pull request from you containing this?
--
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: boot slow down
Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] az6007: handle CI during suspend/resume
Em 06-08-2012 09:21, Antti Palosaari escreveu: On 08/05/2012 08:44 PM, Mauro Carvalho Chehab wrote: The dvb-usb-v2 core doesn't know anything about CI. So, the driver needs to handle it by hand. This patch stops CI just before stopping URB's/RC, and restarts it before URB/RC start. It should be noticed that suspend/resume is not yet working properly, as the PM model requires the implementation of reset_resume: dvb_usb_az6007 1-6:1.0: no reset_resume for driver dvb_usb_az6007? But this is not implemented there at dvb-usb-v2 yet. That is true, but it is coming: http://blog.palosaari.fi/2012/07/dvb-power-management-on-suspend.html http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb_core3 At the time I added initial suspend/resume support for dvb-usb-v2 I left those out purposely as I saw some study and changes are needed for DVB-core/frontend. Normally suspend keeps USB-device powered and calls .resume() on resume. But on certain conditions USB device could lose power during suspend and on that case reset_resume() is called, and if there is no reset_resume() is calls disconnect() (and probe() after that). This should depend on BIOS settings, and what of the following type of suspend[1] was done: S1: All processor caches are flushed, and the CPU(s) stops executing instructions. Power to the CPU(s) and RAM is maintained; devices that do not indicate they must remain on may be powered down. S2: CPU powered off. Dirty cache is flushed to RAM. S3: Commonly referred to as Standby, Sleep, or Suspend to RAM. RAM remains powered S4: Hibernation or Suspend to Disk. All content of main memory is saved to non-volatile memory such as a hard drive, and is powered down. [1] http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface There are also some per-device sysfs nodes that control how PM will work for them. See: $ tree /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 ├── dev ├── device - ../../../1-8 ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── subsystem - ../../../../../../../class/dvb └── uevent There are a number of pm functions that can change the power management behavior as well. Not sure how to control it, but, IMHO, for a media device, it only makes sense to keep it powered on suspend if the device has IR and if the power button of the IR could be used to wake up the hardware. Otherwise, the better is to just power it off, to save battery (for notebooks). Maybe it makes sense to talk with Raphael Wysocki to be sure that it will cover all possible cases: auto-suspend, S1/S2/S3/S4 and wake on IR). regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
Hi Eiraku-san,
On Monday 06 August 2012 18:55:24 Hideki EIRAKU wrote:
fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer. In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled. dma_mmap_coherent() maps the address correctly. It is
available on ARM platforms.
Signed-off-by: Hideki EIRAKU h...@igel.co.jp
Acked-by: Hideki EIRAKU h...@igel.co.jp
As this patch doesn't depend on any other patch in your series
(ARCH_HAS_DMA_MMAP_COHERENT will not be defined without 1/4, so this patch
will be a no-op until then), I've applied it to my tree and will push it to
avoid merge conflicts, unless you would prefer to push it yourself.
---
drivers/video/sh_mobile_lcdcfb.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c index 8cb653b..c8cba7a 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1614,6 +1614,17 @@ static int sh_mobile_lcdc_overlay_blank(int blank,
struct fb_info *info) return 1;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_overlay_mmap(struct fb_info *info, struct vm_area_struct
*vma) +{
+ struct sh_mobile_lcdc_overlay *ovl = info-par;
+
+ return dma_mmap_coherent(ovl-channel-lcdc-dev, vma, ovl-fb_mem,
+ ovl-dma_handle, ovl-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
.fb_read= fb_sys_read,
@@ -1626,6 +1637,9 @@ static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_overlay_mmap,
+#endif
};
static void
@@ -2093,6 +2107,17 @@ static int sh_mobile_lcdc_blank(int blank, struct
fb_info *info) return 0;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_chan *ch = info-par;
+
+ return dma_mmap_coherent(ch-lcdc-dev, vma, ch-fb_mem,
+ ch-dma_handle, ch-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
@@ -2108,6 +2133,9 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_release = sh_mobile_lcdc_release,
.fb_check_var = sh_mobile_lcdc_check_var,
.fb_set_par = sh_mobile_lcdc_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_mmap,
+#endif
};
static void
--
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 3/3] [media] az6007: handle CI during suspend/resume
On 08/07/2012 02:41 PM, Mauro Carvalho Chehab wrote: Em 06-08-2012 09:21, Antti Palosaari escreveu: On 08/05/2012 08:44 PM, Mauro Carvalho Chehab wrote: The dvb-usb-v2 core doesn't know anything about CI. So, the driver needs to handle it by hand. This patch stops CI just before stopping URB's/RC, and restarts it before URB/RC start. It should be noticed that suspend/resume is not yet working properly, as the PM model requires the implementation of reset_resume: dvb_usb_az6007 1-6:1.0: no reset_resume for driver dvb_usb_az6007? But this is not implemented there at dvb-usb-v2 yet. That is true, but it is coming: http://blog.palosaari.fi/2012/07/dvb-power-management-on-suspend.html http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb_core3 At the time I added initial suspend/resume support for dvb-usb-v2 I left those out purposely as I saw some study and changes are needed for DVB-core/frontend. Normally suspend keeps USB-device powered and calls .resume() on resume. But on certain conditions USB device could lose power during suspend and on that case reset_resume() is called, and if there is no reset_resume() is calls disconnect() (and probe() after that). This should depend on BIOS settings, and what of the following type of suspend[1] was done: S1: All processor caches are flushed, and the CPU(s) stops executing instructions. Power to the CPU(s) and RAM is maintained; devices that do not indicate they must remain on may be powered down. S2: CPU powered off. Dirty cache is flushed to RAM. S3: Commonly referred to as Standby, Sleep, or Suspend to RAM. RAM remains powered S4: Hibernation or Suspend to Disk. All content of main memory is saved to non-volatile memory such as a hard drive, and is powered down. [1] http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface That was something I was already aware. There is even S5 and S4b mentioned by Kernel documentation. But in real life you have to care only: S3, Suspend, suspend to ram S4, Hibernation, suspend to disk And from the USB-driver point of view those are covered by there three callbacks: .suspend() .resume() .reset_resume() * if reset_resume() does not exits .disconnect() + .probe() is called instead What is my current understanding S3 level leaves USB/PCI powered normally, but device driver should drop device to low power state. In case of DVB -device this means all sub-drivers should put sleep. S4 naturally powers everything off. Also worth to mention laptops will switch from S3 to S4 if battery drains empty during S3. There are also some per-device sysfs nodes that control how PM will work for them. See: $ tree /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 ├── dev ├── device - ../../../1-8 ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── subsystem - ../../../../../../../class/dvb └── uevent There are a number of pm functions that can change the power management behavior as well. Not sure how to control it, but, IMHO, for a media device, it only makes sense to keep it powered on suspend if the device has IR and if the power button of the IR could be used to wake up the hardware. Otherwise, the better is to just power it off, to save battery (for notebooks). yeah, and it was already done. Maybe it makes sense to talk with Raphael Wysocki to be sure that it will cover all possible cases: auto-suspend, S1/S2/S3/S4 and wake on IR). That IR was something I wasn't noticed at all. Currently it stops IR polling too. If that kind of functionality is needed it is surely some more work as you cannot stop IR-polling. Maybe I will skip it that time as I don't have time for it currently :) If someone wish to learn how USB polling remote could be used for wake-up computer then feel free to do that. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
On Tuesday 07 August 2012 14:01:43 Laurent Pinchart wrote:
Hi Eiraku-san,
On Monday 06 August 2012 18:55:24 Hideki EIRAKU wrote:
fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer. In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled. dma_mmap_coherent() maps the address correctly. It is
available on ARM platforms.
Signed-off-by: Hideki EIRAKU h...@igel.co.jp
Acked-by: Hideki EIRAKU h...@igel.co.jp
I obviously meant
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
As this patch doesn't depend on any other patch in your series
(ARCH_HAS_DMA_MMAP_COHERENT will not be defined without 1/4, so this patch
will be a no-op until then), I've applied it to my tree and will push it to
avoid merge conflicts, unless you would prefer to push it yourself.
---
drivers/video/sh_mobile_lcdcfb.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c index 8cb653b..c8cba7a 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1614,6 +1614,17 @@ static int sh_mobile_lcdc_overlay_blank(int blank,
struct fb_info *info) return 1;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_overlay_mmap(struct fb_info *info, struct vm_area_struct
*vma) +{
+ struct sh_mobile_lcdc_overlay *ovl = info-par;
+
+ return dma_mmap_coherent(ovl-channel-lcdc-dev, vma, ovl-fb_mem,
+ovl-dma_handle, ovl-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
.fb_read= fb_sys_read,
@@ -1626,6 +1637,9 @@ static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_overlay_mmap,
+#endif
};
static void
@@ -2093,6 +2107,17 @@ static int sh_mobile_lcdc_blank(int blank, struct
fb_info *info) return 0;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_chan *ch = info-par;
+
+ return dma_mmap_coherent(ch-lcdc-dev, vma, ch-fb_mem,
+ch-dma_handle, ch-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
@@ -2108,6 +2133,9 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_release = sh_mobile_lcdc_release,
.fb_check_var = sh_mobile_lcdc_check_var,
.fb_set_par = sh_mobile_lcdc_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_mmap,
+#endif
};
static void
--
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 3/3] [media] az6007: handle CI during suspend/resume
Em 07-08-2012 09:12, Antti Palosaari escreveu: On 08/07/2012 02:41 PM, Mauro Carvalho Chehab wrote: Em 06-08-2012 09:21, Antti Palosaari escreveu: On 08/05/2012 08:44 PM, Mauro Carvalho Chehab wrote: The dvb-usb-v2 core doesn't know anything about CI. So, the driver needs to handle it by hand. This patch stops CI just before stopping URB's/RC, and restarts it before URB/RC start. It should be noticed that suspend/resume is not yet working properly, as the PM model requires the implementation of reset_resume: dvb_usb_az6007 1-6:1.0: no reset_resume for driver dvb_usb_az6007? But this is not implemented there at dvb-usb-v2 yet. That is true, but it is coming: http://blog.palosaari.fi/2012/07/dvb-power-management-on-suspend.html http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb_core3 At the time I added initial suspend/resume support for dvb-usb-v2 I left those out purposely as I saw some study and changes are needed for DVB-core/frontend. Normally suspend keeps USB-device powered and calls .resume() on resume. But on certain conditions USB device could lose power during suspend and on that case reset_resume() is called, and if there is no reset_resume() is calls disconnect() (and probe() after that). This should depend on BIOS settings, and what of the following type of suspend[1] was done: S1: All processor caches are flushed, and the CPU(s) stops executing instructions. Power to the CPU(s) and RAM is maintained; devices that do not indicate they must remain on may be powered down. S2: CPU powered off. Dirty cache is flushed to RAM. S3: Commonly referred to as Standby, Sleep, or Suspend to RAM. RAM remains powered S4: Hibernation or Suspend to Disk. All content of main memory is saved to non-volatile memory such as a hard drive, and is powered down. [1] http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface That was something I was already aware. There is even S5 and S4b mentioned by Kernel documentation. But in real life you have to care only: S3, Suspend, suspend to ram S4, Hibernation, suspend to disk At least on some of my machines, BIOS allow to select between S1 and S3 for suspend. Not sure how USB PM suspend works for either case. And from the USB-driver point of view those are covered by there three callbacks: .suspend() .resume() .reset_resume() * if reset_resume() does not exits .disconnect() + .probe() is called instead What is my current understanding S3 level leaves USB/PCI powered normally, but device driver should drop device to low power state. In case of DVB -device this means all sub-drivers should put sleep. Yes. It might make sense to keep IR working (maybe at a lower polling rate, for non- interrupt based drivers), in order to wake machine up, if the power button is pressed, but this would be an additional feature, and I've no idea how this would be implemented. S4 naturally powers everything off. Also worth to mention laptops will switch from S3 to S4 if battery drains empty during S3. I'm not a PM expert, but as BIOS may support features like wake on LAN, it would make sense to keep USB power, at least on those devices that may wake up the device (hid and network devices, for example). There are also some per-device sysfs nodes that control how PM will work for them. See: $ tree /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 /sys/devices/pci:00/:00:1d.7/usb1/1-8/dvb/dvb0.frontend0 ├── dev ├── device - ../../../1-8 ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── subsystem - ../../../../../../../class/dvb └── uevent There are a number of pm functions that can change the power management behavior as well. Not sure how to control it, but, IMHO, for a media device, it only makes sense to keep it powered on suspend if the device has IR and if the power button of the IR could be used to wake up the hardware. Otherwise, the better is to just power it off, to save battery (for notebooks). yeah, and it was already done. Maybe it makes sense to talk with Raphael Wysocki to be sure that it will cover all possible cases: auto-suspend, S1/S2/S3/S4 and wake on IR). That IR was something I wasn't noticed at all. Currently it stops IR polling too. If that kind of functionality is needed it is surely some more work as you cannot stop IR-polling. Yes. There's also an addidional case: dib0700, for example, doesn't do IR polling. Instead, they send an URB on a separate endpoint. When a key is pressed, the device answers to that pending URB request with the keypress. Maybe I will skip it that time as I don't have time for it currently :) If someone wish to learn how
Re: [PATCH 00/24] Various HVR-950q and xc5000 fixes
On Tue, Aug 7, 2012 at 2:26 AM, Hans Verkuil hverk...@xs4all.nl wrote: Since you're working on the au0828 would it perhaps be possible to have that driver use unlocked_ioctl instead of ioctl? It would be really nice if we can get rid of the ioctl v4l2_operation at some point in the future. Hi Hans, I'm pretty sure that actually got done implicitly by patch #8 as a result of a fix for a race condition at startup. Please take a look and let me know if I missed anything: [PATCH 08/24] au0828: fix race condition that causes xc5000 to not bind for digital Thanks, 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
help me, Kconfig problem
I added Kernel GPIO interface for cxd2820r driver. What I understand I should select GPIOLIB in order to compile cxd2820r now. I am not sure if that problem comes from recent Media Kconfig re-arrangement or not, but for some reason I didn't saw it earlier. What I should put for Kconfig in order to prevent these errors? config DVB_CXD2820R tristate Sony CXD2820R depends on DVB_CORE I2C GPIOLIB default m if DVB_FE_CUSTOMISE help Say Y when you want to support this frontend. [crope@localhost linux]$ make silentoldconfig scripts/kconfig/conf --silentoldconfig Kconfig warning: (VIDEO_EM28XX_DVB DVB_USB_ANYSEE) selects DVB_CXD2820R which has unmet direct dependencies (MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_CORE I2C GPIOLIB) warning: (VIDEO_EM28XX_DVB DVB_USB_ANYSEE) selects DVB_CXD2820R which has unmet direct dependencies (MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_CORE I2C GPIOLIB) *** config DVB_CXD2820R tristate Sony CXD2820R depends on DVB_CORE I2C select GPIOLIB default m if DVB_FE_CUSTOMISE help Say Y when you want to support this frontend. [crope@localhost linux]$ make silentoldconfig scripts/kconfig/conf --silentoldconfig Kconfig drivers/usb/Kconfig:88:error: recursive dependency detected! drivers/usb/Kconfig:88: symbol USB is selected by MOUSE_APPLETOUCH drivers/input/mouse/Kconfig:152: symbol MOUSE_APPLETOUCH depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by DVB_CXD2820R drivers/media/dvb/frontends/Kconfig:422: symbol DVB_CXD2820R is selected by VIDEO_EM28XX_DVB drivers/media/video/em28xx/Kconfig:33: symbol VIDEO_EM28XX_DVB depends on V4L_USB_DRIVERS drivers/media/video/Kconfig:668:symbol V4L_USB_DRIVERS depends on USB # # configuration written to .config # regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/24] Various HVR-950q and xc5000 fixes
On Tue 7 August 2012 14:48:41 Devin Heitmueller wrote: On Tue, Aug 7, 2012 at 2:26 AM, Hans Verkuil hverk...@xs4all.nl wrote: Since you're working on the au0828 would it perhaps be possible to have that driver use unlocked_ioctl instead of ioctl? It would be really nice if we can get rid of the ioctl v4l2_operation at some point in the future. Hi Hans, I'm pretty sure that actually got done implicitly by patch #8 as a result of a fix for a race condition at startup. Please take a look and let me know if I missed anything: [PATCH 08/24] au0828: fix race condition that causes xc5000 to not bind for digital Great! That's what I was hoping for. It wasn't clear from the patch subject that that patch contained these changes, otherwise I wouldn't have bothered you. Anyway, another one bites the dust. 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: boot slow down
Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? -- 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
[RFC PATCH 0/2] Add support for RDS decoding (updated)
Hello, first of all: thank you for the comments to my previous RFC for the libv4l2rds library and the rds-ctl control testing tool. The proposed changes have been implemented, and the code has been further improved after a thorough code review by Hans Verkuil. Changes: -the code is rebased on the latest v4l-utils code (as of today 07.08) -added feature: time/date decoding -implementing proposed changes -code cleanup -extended comments Status: From my point of view the RDS decoding is now almost feature complete. There are some obscure RDS features like paging that are not supported, but they do not seem to used anywhere. So in the near future no features will be added and the goal is to get the library and control tool merged into the v4l-utils codebase. Upcoming: Work on RDS-TMC decoding is going well and is being done in a seperate branch. It will be the subject of a future RFC, once it has reached a mature stage. But TMC is not a core feature of RDS but an addition. Regards, Konke -- 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
[RFC PATCH 2/2] Add rds-ctl tool (with changes proposed in RFC)
---
Makefile.am |3 +-
configure.ac |1 +
utils/rds-ctl/Makefile.am |5 +
utils/rds-ctl/rds-ctl.cpp | 959 +
4 files changed, 967 insertions(+), 1 deletion(-)
create mode 100644 utils/rds-ctl/Makefile.am
create mode 100644 utils/rds-ctl/rds-ctl.cpp
diff --git a/Makefile.am b/Makefile.am
index 621d8d9..8ef0d00 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,8 @@ SUBDIRS += \
utils/v4l2-compliance \
utils/v4l2-ctl \
utils/v4l2-dbg \
- utils/v4l2-sysfs-path
+ utils/v4l2-sysfs-path \
+ utils/rds-ctl
if LINUX_OS
SUBDIRS += \
diff --git a/configure.ac b/configure.ac
index 1109c4d..a99f1c6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,6 +28,7 @@ AC_CONFIG_FILES([Makefile
utils/v4l2-sysfs-path/Makefile
utils/xc3028-firmware/Makefile
utils/qv4l2/Makefile
+ utils/rds-ctl/Makefile
contrib/freebsd/Makefile
contrib/test/Makefile
diff --git a/utils/rds-ctl/Makefile.am b/utils/rds-ctl/Makefile.am
new file mode 100644
index 000..9a84257
--- /dev/null
+++ b/utils/rds-ctl/Makefile.am
@@ -0,0 +1,5 @@
+bin_PROGRAMS = rds-ctl
+
+rds_ctl_SOURCES = rds-ctl.cpp
+rds_ctl_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4l2rds/libv4l2rds.la
+
diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp
new file mode 100644
index 000..072ffb7
--- /dev/null
+++ b/utils/rds-ctl/rds-ctl.cpp
@@ -0,0 +1,959 @@
+/*
+ * rds-ctl.cpp is based on v4l2-ctl.cpp
+ *
+ * the following applies for all RDS related parts:
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include wchar.h
+#include locale.h
+#include inttypes.h
+#include getopt.h
+#include sys/types.h
+#include fcntl.h
+#include errno.h
+#include sys/ioctl.h
+#include sys/time.h
+#include dirent.h
+#include config.h
+#include signal.h
+
+#include linux/videodev2.h
+#include libv4l2.h
+#include libv4l2rds.h
+
+#include list
+#include vector
+#include map
+#include string
+#include algorithm
+
+#define ARRAY_SIZE(arr) ((int)(sizeof(arr) / sizeof((arr)[0])))
+
+typedef std::vectorstd::string dev_vec;
+typedef std::mapstd::string, std::string dev_map;
+
+/* Short option list
+
+ Please keep in alphabetical order.
+ That makes it easier to see which short options are still free.
+
+ In general the lower case is used to set something and the upper
+ case is used to retrieve a setting. */
+enum Option {
+ OptSetDevice = 'd',
+ OptGetDriverInfo = 'D',
+ OptGetFreq = 'F',
+ OptSetFreq = 'f',
+ OptHelp = 'h',
+ OptReadRds = 'R',
+ OptGetTuner = 'T',
+ OptSetTuner = 't',
+ OptUseWrapper = 'w',
+ OptAll = 128,
+ OptFreqSeek,
+ OptListDevices,
+ OptListFreqBands,
+ OptOpenFile,
+ OptPrintBlock,
+ OptSilent,
+ OptTunerIndex,
+ OptVerbose,
+ OptWaitLimit,
+ OptLast = 256
+};
+
+struct ctl_parameters {
+ bool terminate_decoding;
+ char options[OptLast];
+ char fd_name[80];
+ bool filemode_active;
+ double freq;
+ uint32_t wait_limit;
+ uint8_t tuner_index;
+ struct v4l2_hw_freq_seek freq_seek;
+};
+
+static struct ctl_parameters params;
+static int app_result;
+
+static struct option long_options[] = {
+ {all, no_argument, 0, OptAll},
+ {device, required_argument, 0, OptSetDevice},
+ {file, required_argument, 0, OptOpenFile},
+ {freq-seek, required_argument, 0, OptFreqSeek},
+ {get-freq, no_argument, 0, OptGetFreq},
+ {get-tuner, no_argument, 0, OptGetTuner},
+ {help, no_argument, 0, OptHelp},
+ {info, no_argument, 0, OptGetDriverInfo},
+ {list-devices, no_argument, 0, OptListDevices},
+ {list-freq-bands, no_argument, 0, OptListFreqBands},
+ {print-block, no_argument, 0, OptPrintBlock},
+ {read-rds, no_argument, 0, OptReadRds},
+ {set-freq, required_argument, 0, OptSetFreq},
+ {tuner-index, required_argument, 0, OptTunerIndex},
+ {verbose,
[RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
---
Makefile.am |3 +-
configure.ac|7 +-
lib/include/libv4l2rds.h| 228 ++
lib/libv4l2rds/Makefile.am | 11 +
lib/libv4l2rds/libv4l2rds.c | 953 +++
lib/libv4l2rds/libv4l2rds.pc.in | 11 +
6 files changed, 1211 insertions(+), 2 deletions(-)
create mode 100644 lib/include/libv4l2rds.h
create mode 100644 lib/libv4l2rds/Makefile.am
create mode 100644 lib/libv4l2rds/libv4l2rds.c
create mode 100644 lib/libv4l2rds/libv4l2rds.pc.in
diff --git a/Makefile.am b/Makefile.am
index a754955..621d8d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,8 @@ SUBDIRS = \
lib/libv4lconvert \
lib/libv4l2 \
lib/libv4l1 \
- lib/libdvbv5
+ lib/libdvbv5 \
+ lib/libv4l2rds
if WITH_V4LUTILS
SUBDIRS += \
diff --git a/configure.ac b/configure.ac
index 8ddcc9d..1109c4d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -14,6 +14,7 @@ AC_CONFIG_FILES([Makefile
lib/libv4l2/Makefile
lib/libv4l1/Makefile
lib/libdvbv5/Makefile
+ lib/libv4l2rds/Makefile
utils/libv4l2util/Makefile
utils/libmedia_dev/Makefile
@@ -36,6 +37,7 @@ AC_CONFIG_FILES([Makefile
lib/libv4l1/libv4l1.pc
lib/libv4l2/libv4l2.pc
lib/libdvbv5/libdvbv5.pc
+ lib/libv4l2rds/libv4l2rds.pc
])
AM_INIT_AUTOMAKE([1.9 no-dist-gzip dist-bzip2 -Wno-portability]) # 1.10 is
needed for target_LIBTOOLFLAGS
@@ -146,9 +148,12 @@ AC_ARG_WITH(libv4l2subdir,
AS_HELP_STRING(--with-libv4l2subdir=DIR,set libv4l2 l
AC_ARG_WITH(libv4lconvertsubdir,
AS_HELP_STRING(--with-libv4lconvertsubdir=DIR,set libv4lconvert library subdir
[default=libv4l]),
libv4lconvertsubdir=$withval, libv4lconvertsubdir=libv4l)
+AC_ARG_WITH(libv4l2rdssubdir, AS_HELP_STRING(--with-libv4l2rdssubdir=DIR,set
libv4l2rds library subdir [default=libv4l]),
+ libv4l2rdssubdir=$withval, libv4l2rdssubdir=libv4l)
+
AC_ARG_WITH(udevdir, AS_HELP_STRING(--with-udevdir=DIR,set udev directory
[default=/lib/udev]),
udevdir=$withval, udevdir=/lib/udev)
-
+
libv4l1privdir=$libdir/$libv4l1subdir
libv4l2privdir=$libdir/$libv4l2subdir
libv4l2plugindir=$libv4l2privdir/plugins
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..4aa8593
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,228 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include time.h
+#include sys/types.h
+#include sys/mman.h
+#include config.h
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if HAVE_VISIBILITY
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds struct */
+#define V4L2_RDS_VERSION (1)
+
+/* Constants used to define the size of arrays used to store RDS information */
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
+* 32 distinct groups, 18 can be used for ODA purposes
*/
+#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be defined
+* AF Method B does not impose a limit on the number of
AFs
+* but it is not fully supported at the moment and will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_fields bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40
Re: boot slow down
bjloc...@lockie.ca wrote: Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? Hi, The CX2388x firmware is _never_ built into the kernel. I'm not sure what that particular kernel config option is for. The kernel delay waiting for userspace to load firmware is settable using a node under /sys somewhere. The default is 60 seconds. You will have to change it in very early boot, or fix the hardcoded constant in the kernel and recompile your kernel. Shortening the delay may not get you entirely acceptable results. If udev is not, or is refusing to load firmware for the cx25840 module, then that module will not properly initialize the CX23885/7/8 A/V core hardware and will likely return with failure. I'm not sure if the cx23885 driver will happily continue on, if that happens. If you still have a modular kernel build around, you may wish to test with it. Blacklist the cx23885 module in /etc/modprobe.conf and the use udevadm to investigate what is going on with udev when you later modprobe the cx23885 driver. If building the video card driver into the kernel is causing you all the problems, then I simply recommend not doing that. Regards, Andy -- 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
it913x: DEV it913x Error
I am running Linux media for 3.7 and got this error all the time all the IT9135 devices. Is that coming from the udev issues? At least it looks different than those earlier udev fw dl problemd I have seen. Aug 7 16:55:23 localhost kernel: [53625.353211] usb 2-2: new high-speed USB device number 22 using ehci_hcd Aug 7 16:55:23 localhost kernel: [53625.469720] usb 2-2: New USB device found, idVendor=048d, idProduct=9135 Aug 7 16:55:23 localhost kernel: [53625.469731] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Aug 7 16:55:23 localhost kernel: [53625.471127] it913x: DEV it913x Error regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Hello, On Monday, August 06, 2012 11:55 AM Hideki EIRAKU wrote: Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a physical address. The two addressses are not necessarily the same. For example, when using the IOMMU funtion on certain platforms, dma_addr_t addresses are not directly mappable physical address. dma_mmap_coherent() maps the address correctly. It is available on ARM platforms. Signed-off-by: Hideki EIRAKU h...@igel.co.jp I'm sorry for bringing this issue now, once you have already created v3 of your patches, but similar patch has been already proposed some time ago. It is already processed together with general videobuf2-dma-contig redesign and dma-buf extensions by Tomasz Stanislawski. See post http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focus=49461 and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438 It doesn't use conditional code inside videobuf2 allocator and rely entirely on dma-mapping subsystem to provide a working dma_mmap_coherent/writecombine/attrs() function. When it was posted, it relied on the dma-mapping extensions, which now have been finally merged to v3.6-rc1. Now I wonder if there are any architectures, which don't use dma_map_ops based dma-mapping framework, which might use videobuf2-dma-conting module. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT
Hi Hideki, On Monday, August 06, 2012 11:55 AM Hideki EIRAKU wrote: ARCH_HAS_DMA_MMAP_COHERENT indicates that there is dma_mmap_coherent() API in this architecture. The name is already defined in PowerPC. Signed-off-by: Hideki EIRAKU h...@igel.co.jp --- arch/arm/include/asm/dma-mapping.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index bbef15d..f41cd30 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -187,6 +187,7 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, struct dma_attrs *attrs); #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL) +#define ARCH_HAS_DMA_MMAP_COHERENT static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, -- 1.7.0.4 I will take this patch to my dma-mapping kernel tree, to the fixes branch. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: [3.0.y+] [media] Avoid sysfs oops when an rc_dev's raw device is absent
On Tue, Aug 07, 2012 at 07:58:44PM +1200, Douglas Bagnall wrote:
Ben Hutchings wrote:
This returns without unlocking dev-lock, which isn't much of an
improvement. Please get that fixed in mainline, and then I can apply
both of the changes to 3.2.y at once.
Thanks for reviewing it Ben.
Oh dear. Quite right. Sorry. Thanks.
Douglas
From c1d4df58efb2d13551586d177bcbb4e9af588618 Mon Sep 17 00:00:00 2001
From: Douglas Bagnall doug...@paradise.net.nz
Date: Tue, 7 Aug 2012 19:30:36 +1200
Subject: [PATCH] Unlock the rc_dev lock when the raw device is missing
As pointed out by Ben Hutchings, after commit 720bb6436, the lock was
being taken and not released when an rc_dev has a NULL raw device.
Signed-off-by: Douglas Bagnall doug...@paradise.net.nz
As it's desired for stable, this could also have
Cc: sta...@vger.kernel.org when applied, so it's picked up
automatically when lands in mainline. Also nitpicking some more,
may be the patch could have a Reported-by line added.
Acked-by: Herton R. Krzesinski herton.krzesin...@canonical.com
---
drivers/media/rc/rc-main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index cabc19c..dcd45d0 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -778,9 +778,10 @@ static ssize_t show_protocols(struct device *device,
} else if (dev-raw) {
enabled = dev-raw-enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
- } else
+ } else {
+ mutex_unlock(dev-lock);
return -ENODEV;
-
+ }
IR_dprintk(1, allowed - 0x%llx, enabled - 0x%llx\n,
(long long)allowed,
(long long)enabled);
--
1.7.9.5
--
[]'s
Herton
--
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] lmedm04 2.06 conversion to dvb-usb-v2 version 2
On 08/06/2012 11:21 PM, Malcolm Priestley wrote: Conversion of lmedm04 to dvb-usb-v2 Functional changes m88rs2000 tuner now uses all callbacks. TODO migrate other tuners to the callbacks. This patch is applied on top of [BUG] Re: dvb_usb_lmedm04 crash Kernel (rs2000) http://patchwork.linuxtv.org/patch/13584/ Signed-off-by: Malcolm Priestley tvbox...@gmail.com Could you try to make this driver more generic? You use some internals of dvb-usb directly and most likely those are without a reason. For example data streaming, lme2510_kill_urb() kills directly urbs allocated and submitted by dvb-usb. Guess that driver is broken just after someone changes dvb-usb streaming code. lme2510_usb_talk() could be replaced by generic dvb_usbv2_generic_rw(). What is function of lme2510_int_read() ? I see you use own low level URB routines for here too. It starts polling, reads remote, tuner, demod, etc, and updates state. You would better to implement I2C-adapter correctly and then start Kernel work-queue, which reads same information using I2C-adapter. Or you could even abuse remote controller polling function provided by dvb-usb. lme2510_get_stream_config() enables pid-filter again over the dvb-usb, but I can live with it because there is no dynamic configuration for that. Anyhow, is that really needed? I can live with the pid-filter abuse, but killing stream URBs on behalf of DVB-USB is something I don't like to see. If you have very good explanation and I cannot fix DVB USB to meet it I could consider that kind of hack. And it should be documented clearly adding necessary comments to code. Re-implementing that driver to use 100% DVB-USB services will reduce around 50% of code or more. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] saa7164: use native print_hex_dump() instead of custom one
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/video/saa7164/saa7164-api.c | 15 ++---
drivers/media/video/saa7164/saa7164-core.c | 46 +++-
drivers/media/video/saa7164/saa7164.h |1 -
3 files changed, 14 insertions(+), 48 deletions(-)
diff --git a/drivers/media/video/saa7164/saa7164-api.c
b/drivers/media/video/saa7164/saa7164-api.c
index c8799fd..eff7135 100644
--- a/drivers/media/video/saa7164/saa7164-api.c
+++ b/drivers/media/video/saa7164/saa7164-api.c
@@ -670,7 +670,8 @@ int saa7164_api_set_dif(struct saa7164_port *port, u8 reg,
u8 val)
if (ret != SAA_OK)
printk(KERN_ERR %s() error, ret(2) = 0x%x\n, __func__, ret);
#if 0
- saa7164_dumphex16(dev, buf, 16);
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1, buf, 16,
+ false);
#endif
return ret == SAA_OK ? 0 : -EIO;
}
@@ -1352,7 +1353,8 @@ int saa7164_api_enum_subdevs(struct saa7164_dev *dev)
}
if (saa_debug DBGLVL_API)
- saa7164_dumphex16(dev, buf, (buflen/16)*16);
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1, buf,
+ buflen ~15, false);
saa7164_api_dump_subdevs(dev, buf, buflen);
@@ -1403,7 +1405,8 @@ int saa7164_api_i2c_read(struct saa7164_i2c *bus, u8
addr, u32 reglen, u8 *reg,
dprintk(DBGLVL_API, %s() len = %d bytes\n, __func__, len);
if (saa_debug DBGLVL_I2C)
- saa7164_dumphex16(dev, buf, 2 * 16);
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1, buf,
+ 32, false);
ret = saa7164_cmd_send(bus-dev, unitid, GET_CUR,
EXU_REGISTER_ACCESS_CONTROL, len, buf);
@@ -1411,7 +1414,8 @@ int saa7164_api_i2c_read(struct saa7164_i2c *bus, u8
addr, u32 reglen, u8 *reg,
printk(KERN_ERR %s() error, ret(2) = 0x%x\n, __func__, ret);
else {
if (saa_debug DBGLVL_I2C)
- saa7164_dumphex16(dev, buf, sizeof(buf));
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1,
+ buf, sizeof(buf), false);
memcpy(data, (buf + 2 * sizeof(u32) + reglen), datalen);
}
@@ -1471,7 +1475,8 @@ int saa7164_api_i2c_write(struct saa7164_i2c *bus, u8
addr, u32 datalen,
memcpy((buf + 2 * sizeof(u32)), data, datalen);
if (saa_debug DBGLVL_I2C)
- saa7164_dumphex16(dev, buf, sizeof(buf));
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1,
+ buf, sizeof(buf), false);
ret = saa7164_cmd_send(bus-dev, unitid, SET_CUR,
EXU_REGISTER_ACCESS_CONTROL, len, buf);
diff --git a/drivers/media/video/saa7164/saa7164-core.c
b/drivers/media/video/saa7164/saa7164-core.c
index 3b7d7b4..2c9ad87 100644
--- a/drivers/media/video/saa7164/saa7164-core.c
+++ b/drivers/media/video/saa7164/saa7164-core.c
@@ -92,28 +92,6 @@ LIST_HEAD(saa7164_devlist);
#define INT_SIZE 16
-void saa7164_dumphex16FF(struct saa7164_dev *dev, u8 *buf, int len)
-{
- int i;
- u8 tmp[16];
- memset(tmp[0], 0xff, sizeof(tmp));
-
- printk(KERN_INFO
- 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f\n);
-
- for (i = 0; i len; i += 16) {
- if (memcmp(tmp, buf + i, sizeof(tmp)) != 0) {
- printk(KERN_INFO [0x%08x]
- %02x %02x %02x %02x %02x %02x %02x %02x
- %02x %02x %02x %02x %02x %02x %02x %02x\n, i,
- *(buf+i+0), *(buf+i+1), *(buf+i+2), *(buf+i+3),
- *(buf+i+4), *(buf+i+5), *(buf+i+6), *(buf+i+7),
- *(buf+i+8), *(buf+i+9), *(buf+i+10), *(buf+i+11),
- *(buf+i+12), *(buf+i+13), *(buf+i+14), *(buf+i+15));
- }
- }
-}
-
static void saa7164_pack_verifier(struct saa7164_buffer *buf)
{
u8 *p = (u8 *)buf-cpu;
@@ -125,7 +103,8 @@ static void saa7164_pack_verifier(struct saa7164_buffer
*buf)
(*(p + i + 2) != 0x01) || (*(p + i + 3) != 0xBA)) {
printk(KERN_ERR No pack at 0x%x\n, i);
#if 0
- saa7164_dumphex16FF(buf-port-dev, (p + i), 32);
+ print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 16, 1,
+ p + 1, 32, false);
#endif
}
}
@@ -316,7 +295,8 @@ static void saa7164_work_enchandler_helper(struct
saa7164_port *port, int bufnr)
printk(KERN_ERR %s() buf %p
guard buffer breach\n,
__func__, buf);
#if 0
- saa7164_dumphex16FF(dev, (p +
buf-actual_size) - 32 , 64);
+
[PATCH 02/11] dvb: nxt200x: apply levels to the printk()s
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/dvb/frontends/nxt200x.c | 56 ++---
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/frontends/nxt200x.c
b/drivers/media/dvb/frontends/nxt200x.c
index 49ca78d..03af52e 100644
--- a/drivers/media/dvb/frontends/nxt200x.c
+++ b/drivers/media/dvb/frontends/nxt200x.c
@@ -37,6 +37,8 @@
* /usr/lib/hotplug/firmware/ or /lib/firmware/
* (depending on configuration of firmware hotplug).
*/
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
#define NXT2002_DEFAULT_FIRMWARE dvb-fe-nxt2002.fw
#define NXT2004_DEFAULT_FIRMWARE dvb-fe-nxt2004.fw
#define CRC_CCIT_MASK 0x1021
@@ -62,10 +64,7 @@ struct nxt200x_state {
};
static int debug;
-#define dprintk(args...) \
- do { \
- if (debug) printk(KERN_DEBUG nxt200x: args); \
- } while (0)
+#define dprintk(args...) do { if (debug) pr_debug(args); } while (0)
static int i2c_writebytes (struct nxt200x_state* state, u8 addr, u8 *buf, u8
len)
{
@@ -73,7 +72,7 @@ static int i2c_writebytes (struct nxt200x_state* state, u8
addr, u8 *buf, u8 len
struct i2c_msg msg = { .addr = addr, .flags = 0, .buf = buf, .len = len
};
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk (KERN_WARNING nxt200x: %s: i2c write error (addr
0x%02x, err == %i)\n,
+ pr_warn(%s: i2c write error (addr 0x%02x, err == %i)\n,
__func__, addr, err);
return -EREMOTEIO;
}
@@ -86,7 +85,7 @@ static int i2c_readbytes(struct nxt200x_state *state, u8
addr, u8 *buf, u8 len)
struct i2c_msg msg = { .addr = addr, .flags = I2C_M_RD, .buf = buf,
.len = len };
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk (KERN_WARNING nxt200x: %s: i2c read error (addr 0x%02x,
err == %i)\n,
+ pr_warn(%s: i2c read error (addr 0x%02x, err == %i)\n,
__func__, addr, err);
return -EREMOTEIO;
}
@@ -104,7 +103,7 @@ static int nxt200x_writebytes (struct nxt200x_state* state,
u8 reg,
memcpy(buf2[1], buf, len);
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk (KERN_WARNING nxt200x: %s: i2c write error (addr
0x%02x, err == %i)\n,
+ pr_warn(%s: i2c write error (addr 0x%02x, err == %i)\n,
__func__, state-config-demod_address, err);
return -EREMOTEIO;
}
@@ -121,7 +120,7 @@ static int nxt200x_readbytes(struct nxt200x_state *state,
u8 reg, u8 *buf, u8 le
int err;
if ((err = i2c_transfer (state-i2c, msg, 2)) != 2) {
- printk (KERN_WARNING nxt200x: %s: i2c read error (addr 0x%02x,
err == %i)\n,
+ pr_warn(%s: i2c read error (addr 0x%02x, err == %i)\n,
__func__, state-config-demod_address, err);
return -EREMOTEIO;
}
@@ -199,7 +198,7 @@ static int nxt200x_writereg_multibyte (struct
nxt200x_state* state, u8 reg, u8*
break;
}
- printk(KERN_WARNING nxt200x: Error writing multireg register
0x%02X\n,reg);
+ pr_warn(Error writing multireg register 0x%02X\n, reg);
return 0;
}
@@ -281,7 +280,8 @@ static void nxt200x_microcontroller_stop (struct
nxt200x_state* state)
counter++;
}
- printk(KERN_WARNING nxt200x: Timeout waiting for nxt200x to stop. This
is ok after firmware upload.\n);
+ pr_warn(Timeout waiting for nxt200x to stop. This is ok after
+ firmware upload.\n);
return;
}
@@ -320,7 +320,7 @@ static void nxt2004_microcontroller_init (struct
nxt200x_state* state)
counter++;
}
- printk(KERN_WARNING nxt200x: Timeout waiting for nxt2004 to init.\n);
+ pr_warn(Timeout waiting for nxt2004 to init.\n);
return;
}
@@ -338,7 +338,7 @@ static int nxt200x_writetuner (struct nxt200x_state* state,
u8* data)
switch (state-demod_chip) {
case NXT2004:
if (i2c_writebytes(state, data[0], data+1, 4))
- printk(KERN_WARNING nxt200x: error writing to
tuner\n);
+ pr_warn(error writing to tuner\n);
/* wait until we have a lock */
while (count 20) {
i2c_readbytes(state, data[0], buf, 1);
@@ -347,7 +347,7 @@ static int nxt200x_writetuner (struct nxt200x_state* state,
u8* data)
msleep(100);
count++;
}
- printk(nxt2004: timeout waiting for tuner lock\n);
+ pr_warn(timeout waiting for tuner lock\n);
break;
case NXT2002:
/* set the i2c
[PATCH 06/11] radio-shark2: use %*ph to print small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/radio/radio-shark2.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/media/radio/radio-shark2.c b/drivers/media/radio/radio-shark2.c index b9575de..90aecfb 100644 --- a/drivers/media/radio/radio-shark2.c +++ b/drivers/media/radio/radio-shark2.c @@ -100,12 +100,8 @@ static int shark_write_reg(struct radio_tea5777 *tea, u64 reg) for (i = 0; i 6; i++) shark-transfer_buffer[i + 1] = (reg (40 - i * 8)) 0xff; - v4l2_dbg(1, debug, tea-v4l2_dev, -shark2-write: %02x %02x %02x %02x %02x %02x %02x\n, -shark-transfer_buffer[0], shark-transfer_buffer[1], -shark-transfer_buffer[2], shark-transfer_buffer[3], -shark-transfer_buffer[4], shark-transfer_buffer[5], -shark-transfer_buffer[6]); + v4l2_dbg(1, debug, tea-v4l2_dev, shark2-write: %*ph\n, +7, shark-transfer_buffer); res = usb_interrupt_msg(shark-usbdev, usb_sndintpipe(shark-usbdev, SHARK_OUT_EP), @@ -148,9 +144,8 @@ static int shark_read_reg(struct radio_tea5777 *tea, u32 *reg_ret) for (i = 0; i 3; i++) reg |= shark-transfer_buffer[i] (16 - i * 8); - v4l2_dbg(1, debug, tea-v4l2_dev, shark2-read: %02x %02x %02x\n, -shark-transfer_buffer[0], shark-transfer_buffer[1], -shark-transfer_buffer[2]); + v4l2_dbg(1, debug, tea-v4l2_dev, shark2-read: %*ph\n, +3, shark-transfer_buffer); *reg_ret = reg; return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] saa7127: use %*ph to print small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/video/saa7127.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/media/video/saa7127.c b/drivers/media/video/saa7127.c index 39c90b0..8ecb656 100644 --- a/drivers/media/video/saa7127.c +++ b/drivers/media/video/saa7127.c @@ -364,10 +364,7 @@ static int saa7127_set_vps(struct v4l2_subdev *sd, const struct v4l2_sliced_vbi_ state-vps_data[2] = data-data[9]; state-vps_data[3] = data-data[10]; state-vps_data[4] = data-data[11]; - v4l2_dbg(1, debug, sd, Set VPS data %02x %02x %02x %02x %02x\n, - state-vps_data[0], state-vps_data[1], - state-vps_data[2], state-vps_data[3], - state-vps_data[4]); + v4l2_dbg(1, debug, sd, Set VPS data %*ph\n, 5, state-vps_data); saa7127_write(sd, 0x55, state-vps_data[0]); saa7127_write(sd, 0x56, state-vps_data[1]); saa7127_write(sd, 0x57, state-vps_data[2]); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] dvb: use %*ph to hexdump small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/dvb/b2c2/flexcop-usb.c |5 +
drivers/media/dvb/bt8xx/dst_ca.c |3 ++-
drivers/media/dvb/dvb-core/dmxdev.c |4 +---
drivers/media/dvb/ngene/ngene-core.c | 14 --
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/media/dvb/b2c2/flexcop-usb.c
b/drivers/media/dvb/b2c2/flexcop-usb.c
index 26c666d..8b6275f 100644
--- a/drivers/media/dvb/b2c2/flexcop-usb.c
+++ b/drivers/media/dvb/b2c2/flexcop-usb.c
@@ -324,10 +324,7 @@ static void flexcop_usb_process_frame(struct flexcop_usb
*fc_usb,
flexcop_pass_dmx_packets(
fc_usb-fc_dev, b+2, 1);
else
- deb_ts(
- not ts packet %02x %02x %02x %02x \n,
- *(b+2), *(b+3),
- *(b+4), *(b+5));
+ deb_ts(not ts packet %*ph\n, 4, b+2);
b += 190;
l -= 190;
break;
diff --git a/drivers/media/dvb/bt8xx/dst_ca.c b/drivers/media/dvb/bt8xx/dst_ca.c
index 66f52f1..ee3884f 100644
--- a/drivers/media/dvb/bt8xx/dst_ca.c
+++ b/drivers/media/dvb/bt8xx/dst_ca.c
@@ -321,7 +321,8 @@ static int ca_get_message(struct dst_state *state, struct
ca_msg *p_ca_message,
return -EFAULT;
if (p_ca_message-msg) {
- dprintk(verbose, DST_CA_NOTICE, 1, Message = [%02x %02x
%02x], p_ca_message-msg[0], p_ca_message-msg[1], p_ca_message-msg[2]);
+ dprintk(verbose, DST_CA_NOTICE, 1, Message = [%*ph],
+ 3, p_ca_message-msg);
for (i = 0; i 3; i++) {
command = command | p_ca_message-msg[i];
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index 73970cd..889c9c1 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -370,9 +370,7 @@ static int dvb_dmxdev_section_callback(const u8 *buffer1,
size_t buffer1_len,
return 0;
}
del_timer(dmxdevfilter-timer);
- dprintk(dmxdev: section callback %02x %02x %02x %02x %02x %02x\n,
- buffer1[0], buffer1[1],
- buffer1[2], buffer1[3], buffer1[4], buffer1[5]);
+ dprintk(dmxdev: section callback %*ph\n, 6, buffer1);
ret = dvb_dmxdev_buffer_write(dmxdevfilter-buffer, buffer1,
buffer1_len);
if (ret == buffer1_len) {
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 3985738..c8e0d5b 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -258,22 +258,16 @@ static void dump_command_io(struct ngene *dev)
u8 buf[8], *b;
ngcpyfrom(buf, HOST_TO_NGENE, 8);
- printk(KERN_ERR host_to_ngene (%04x): %02x %02x %02x %02x %02x %02x
%02x %02x\n,
- HOST_TO_NGENE, buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6], buf[7]);
+ printk(KERN_ERR host_to_ngene (%04x): %*ph\n, HOST_TO_NGENE, 8, buf);
ngcpyfrom(buf, NGENE_TO_HOST, 8);
- printk(KERN_ERR ngene_to_host (%04x): %02x %02x %02x %02x %02x %02x
%02x %02x\n,
- NGENE_TO_HOST, buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6], buf[7]);
+ printk(KERN_ERR ngene_to_host (%04x): %*ph\n, NGENE_TO_HOST, 8, buf);
b = dev-hosttongene;
- printk(KERN_ERR dev-hosttongene (%p): %02x %02x %02x %02x %02x %02x
%02x %02x\n,
- b, b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7]);
+ printk(KERN_ERR dev-hosttongene (%p): %*ph\n, b, 8, b);
b = dev-ngenetohost;
- printk(KERN_ERR dev-ngenetohost (%p): %02x %02x %02x %02x %02x %02x
%02x %02x\n,
- b, b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7]);
+ printk(KERN_ERR dev-ngenetohost (%p): %*ph\n, b, 8, b);
}
static int ngene_command_mutex(struct ngene *dev, struct ngene_command *com)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] dvb: frontends: use %*ph to dump small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/frontends/cxd2820r_t.c |3 +--
drivers/media/dvb/frontends/nxt200x.c|8 +++-
drivers/media/dvb/frontends/rtl2830.c|2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_t.c
b/drivers/media/dvb/frontends/cxd2820r_t.c
index 1a02623..e5dd22b 100644
--- a/drivers/media/dvb/frontends/cxd2820r_t.c
+++ b/drivers/media/dvb/frontends/cxd2820r_t.c
@@ -389,8 +389,7 @@ int cxd2820r_read_status_t(struct dvb_frontend *fe,
fe_status_t *status)
}
}
- dbg(%s: lock=%02x %02x %02x %02x, __func__,
- buf[0], buf[1], buf[2], buf[3]);
+ dbg(%s: lock=%*ph, __func__, 4, buf);
return ret;
error:
diff --git a/drivers/media/dvb/frontends/nxt200x.c
b/drivers/media/dvb/frontends/nxt200x.c
index 03af52e..8e28894 100644
--- a/drivers/media/dvb/frontends/nxt200x.c
+++ b/drivers/media/dvb/frontends/nxt200x.c
@@ -331,7 +331,7 @@ static int nxt200x_writetuner (struct nxt200x_state* state,
u8* data)
dprintk(%s\n, __func__);
- dprintk(Tuner Bytes: %02X %02X %02X %02X\n, data[1], data[2],
data[3], data[4]);
+ dprintk(Tuner Bytes: %*ph\n, 4, data + 1);
/* if NXT2004, write directly to tuner. if NXT2002, write through NXT
chip.
* direct write is required for Philips TUV1236D and ALPS TDHU2 */
@@ -1161,8 +1161,7 @@ struct dvb_frontend* nxt200x_attach(const struct
nxt200x_config* config,
/* read card id */
nxt200x_readbytes(state, 0x00, buf, 5);
- dprintk(NXT info: %02X %02X %02X %02X %02X\n,
- buf[0], buf[1], buf[2], buf[3], buf[4]);
+ dprintk(NXT info: %*ph\n, 5, buf);
/* set demod chip */
switch (buf[0]) {
@@ -1201,8 +1200,7 @@ struct dvb_frontend* nxt200x_attach(const struct
nxt200x_config* config,
error:
kfree(state);
- printk(Unknown/Unsupported NXT chip: %02X %02X %02X %02X %02X\n,
- buf[0], buf[1], buf[2], buf[3], buf[4]);
+ pr_err(Unknown/Unsupported NXT chip: %*ph\n, 5, buf);
return NULL;
}
diff --git a/drivers/media/dvb/frontends/rtl2830.c
b/drivers/media/dvb/frontends/rtl2830.c
index 93612eb..8fa8b08 100644
--- a/drivers/media/dvb/frontends/rtl2830.c
+++ b/drivers/media/dvb/frontends/rtl2830.c
@@ -392,7 +392,7 @@ static int rtl2830_get_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- dbg(%s: TPS=%02x %02x %02x, __func__, buf[0], buf[1], buf[2]);
+ dbg(%s: TPS=%*ph, __func__, 3, buf);
switch ((buf[0] 2) 3) {
case 0:
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] ati_remote: use %*ph to dump small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Anssi Hannula anssi.hann...@iki.fi
---
drivers/media/rc/ati_remote.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 8fa72e2..08aede5 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -331,13 +331,9 @@ static void ati_remote_dump(struct device *dev, unsigned
char *data,
if (data[0] != (unsigned char)0xff data[0] != 0x00)
dev_warn(dev, Weird byte 0x%02x\n, data[0]);
} else if (len == 4)
- dev_warn(dev, Weird key %02x %02x %02x %02x\n,
-data[0], data[1], data[2], data[3]);
+ dev_warn(dev, Weird key %*ph\n, 4, data);
else
- dev_warn(dev,
- Weird data, len=%d %02x %02x %02x %02x %02x %02x
...\n,
- len, data[0], data[1], data[2], data[3], data[4],
- data[5]);
+ dev_warn(dev, Weird data, len=%d %*ph ...\n, len, 6, data);
}
/*
@@ -519,8 +515,7 @@ static void ati_remote_input_report(struct urb *urb)
if (data[1] != ((data[2] + data[3] + 0xd5) 0xff)) {
dbginfo(ati_remote-interface-dev,
- wrong checksum in input: %02x %02x %02x %02x\n,
- data[0], data[1], data[2], data[3]);
+ wrong checksum in input: %*ph\n, 4, data);
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] common: tunners: use %*ph to dump small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/common/tuners/tuner-xc2028.c |3 +--
drivers/media/common/tuners/xc4000.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ea0550e..5d86b26 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1126,8 +1126,7 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
priv-frequency = freq;
- tuner_dbg(divisor= %02x %02x %02x %02x (freq=%d.%03d)\n,
- buf[0], buf[1], buf[2], buf[3],
+ tuner_dbg(divisor= %*ph (freq=%d.%03d)\n, 4, buf,
freq / 100, (freq % 100) / 1000);
rc = 0;
diff --git a/drivers/media/common/tuners/xc4000.c
b/drivers/media/common/tuners/xc4000.c
index 6839711..4937712 100644
--- a/drivers/media/common/tuners/xc4000.c
+++ b/drivers/media/common/tuners/xc4000.c
@@ -263,8 +263,7 @@ static int xc_send_i2c_data(struct xc4000_priv *priv, u8
*buf, int len)
printk(KERN_ERR xc4000: I2C write failed (len=%i)\n,
len);
if (len == 4) {
- printk(KERN_ERR bytes %02x %02x %02x %02x\n,
buf[0],
- buf[1], buf[2], buf[3]);
+ printk(KERN_ERR bytes %*ph\n, 4, buf);
}
return -EREMOTEIO;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] gspca: use %*ph to print small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com Cc: Hans de Goede hdego...@redhat.com --- drivers/media/video/gspca/sq905c.c |7 ++- drivers/media/video/gspca/sq930x.c | 10 +- drivers/media/video/gspca/vc032x.c |7 ++- 3 files changed, 5 insertions(+), 19 deletions(-) diff --git a/drivers/media/video/gspca/sq905c.c b/drivers/media/video/gspca/sq905c.c index 2c2f3d2..70fae69 100644 --- a/drivers/media/video/gspca/sq905c.c +++ b/drivers/media/video/gspca/sq905c.c @@ -228,11 +228,8 @@ static int sd_config(struct gspca_dev *gspca_dev, } /* Note we leave out the usb id and the manufacturing date */ PDEBUG(D_PROBE, - SQ9050 ID string: %02x - %02x %02x %02x %02x %02x %02x, - gspca_dev-usb_buf[3], - gspca_dev-usb_buf[14], gspca_dev-usb_buf[15], - gspca_dev-usb_buf[16], gspca_dev-usb_buf[17], - gspca_dev-usb_buf[18], gspca_dev-usb_buf[19]); + SQ9050 ID string: %02x - %*ph, + gspca_dev-usb_buf[3], 6, gspca_dev-usb_buf + 14); cam-cam_mode = sq905c_mode; cam-nmodes = 2; diff --git a/drivers/media/video/gspca/sq930x.c b/drivers/media/video/gspca/sq930x.c index 3e1e486..7e8748b 100644 --- a/drivers/media/video/gspca/sq930x.c +++ b/drivers/media/video/gspca/sq930x.c @@ -863,15 +863,7 @@ static int sd_init(struct gspca_dev *gspca_dev) * 6: c8 / c9 / ca / cf = mode webcam?, sensor? webcam? * 7: 00 */ - PDEBUG(D_PROBE, info: %02x %02x %02x %02x %02x %02x %02x %02x, - gspca_dev-usb_buf[0], - gspca_dev-usb_buf[1], - gspca_dev-usb_buf[2], - gspca_dev-usb_buf[3], - gspca_dev-usb_buf[4], - gspca_dev-usb_buf[5], - gspca_dev-usb_buf[6], - gspca_dev-usb_buf[7]); + PDEBUG(D_PROBE, info: %*ph, 8, gspca_dev-usb_buf); bridge_init(sd); diff --git a/drivers/media/video/gspca/vc032x.c b/drivers/media/video/gspca/vc032x.c index f21fd16..e500795 100644 --- a/drivers/media/video/gspca/vc032x.c +++ b/drivers/media/video/gspca/vc032x.c @@ -2934,11 +2934,8 @@ static void reg_r(struct gspca_dev *gspca_dev, PDEBUG(D_USBI, GET %02x 0001 %04x %02x, req, index, gspca_dev-usb_buf[0]); else - PDEBUG(D_USBI, GET %02x 0001 %04x %02x %02x %02x, - req, index, - gspca_dev-usb_buf[0], - gspca_dev-usb_buf[1], - gspca_dev-usb_buf[2]); + PDEBUG(D_USBI, GET %02x 0001 %04x %*ph, + req, index, 3, gspca_dev-usb_buf); #endif } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] au0828: use %*ph to dump small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/media/video/au0828/au0828-core.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/media/video/au0828/au0828-core.c b/drivers/media/video/au0828/au0828-core.c index 1e4ce50..49e0e92 100644 --- a/drivers/media/video/au0828/au0828-core.c +++ b/drivers/media/video/au0828/au0828-core.c @@ -73,17 +73,7 @@ static void cmd_msg_dump(struct au0828_dev *dev) int i; for (i = 0; i sizeof(dev-ctrlmsg); i += 16) - dprintk(2, %s() %02x %02x %02x %02x %02x %02x %02x %02x - %02x %02x %02x %02x %02x %02x %02x %02x\n, - __func__, - dev-ctrlmsg[i+0], dev-ctrlmsg[i+1], - dev-ctrlmsg[i+2], dev-ctrlmsg[i+3], - dev-ctrlmsg[i+4], dev-ctrlmsg[i+5], - dev-ctrlmsg[i+6], dev-ctrlmsg[i+7], - dev-ctrlmsg[i+8], dev-ctrlmsg[i+9], - dev-ctrlmsg[i+10], dev-ctrlmsg[i+11], - dev-ctrlmsg[i+12], dev-ctrlmsg[i+13], - dev-ctrlmsg[i+14], dev-ctrlmsg[i+15]); + dprintk(2, %s() %*ph\n, __func__, 16, dev-ctrlmsg + i); } static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value, -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Administrator Letzte Warnung !!
ACHTUNG. Ihr Postfach hat die Speicherung zu begrenzen, die 10GB als überschritten von Ihrem Administrator festgelegt, sind Sie derzeit auf 10.9GB, Sie sind möglicherweise nicht in der Lage zu senden oder zu empfangen neue E-Mail bis zum Sie re-validieren Ihre Mailbox. Zur erneuten Überprüfung Ihrer Mailbox klicken Sie bitte den folgenden Link: http://www.dlinlandempire.com/forms/use/deletememakeu-seewaitingohappen/form1.html Wenn der Link oben nicht funktionieren bitte kopieren und fügen Sie den Linkunten, um Ihre Browser-Fenster http://www.dlinlandempire.com/forms/use/deletememakeu-seewaitingohappen/form1.html Dank System Administrator -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] dma-fence: dma-buf synchronization (v7)
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence.
+ dma_fence_signal()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.
The one pending on the fence can add an async callback:
+ dma_fence_add_callback()
The callback can optionally be cancelled with remove_wait_queue()
Or wait synchronously (optionally with timeout or interruptible):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence-ops == bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, fence_buf, offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/Makefile |2
drivers/base/dma-fence.c | 287 +
include/linux/dma-fence.h | 96 +++
3 files changed, 384 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/dma-fence.c
create mode 100644 include/linux/dma-fence.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..6e9f217 100644
---
[PATCH 2/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
dma_buf[offset] = value has been met, accounting for wraparound.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/Makefile |2 -
drivers/base/dma-bikeshed-fence.c | 44 +
include/linux/dma-bikeshed-fence.h | 92
3 files changed, 137 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/dma-bikeshed-fence.c
create mode 100644 include/linux/dma-bikeshed-fence.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6e9f217..1e7723b 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-bikeshed-fence.c
b/drivers/base/dma-bikeshed-fence.c
new file mode 100644
index 000..fa063e8
--- /dev/null
+++ b/drivers/base/dma-bikeshed-fence.c
@@ -0,0 +1,44 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include linux/dma-bikeshed-fence.h
+
+static int enable_signaling(struct dma_fence *fence)
+{
+ struct dma_bikeshed_fence *bikeshed_fence = to_bikeshed_fence(fence);
+ return bikeshed_fence-enable_signaling(bikeshed_fence);
+}
+
+static void bikeshed_release(struct dma_fence *fence)
+{
+ struct dma_bikeshed_fence *f = to_bikeshed_fence(fence);
+
+ if (f-release)
+ f-release(f);
+ dma_buf_put(f-sync_buf);
+}
+
+struct dma_fence_ops dma_bikeshed_fence_ops = {
+ .enable_signaling = enable_signaling,
+ .release = bikeshed_release
+};
+EXPORT_SYMBOL_GPL(dma_bikeshed_fence_ops);
diff --git a/include/linux/dma-bikeshed-fence.h
b/include/linux/dma-bikeshed-fence.h
new file mode 100644
index 000..4f19801
--- /dev/null
+++ b/include/linux/dma-bikeshed-fence.h
@@ -0,0 +1,92 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __DMA_BIKESHED_FENCE_H__
+#define __DMA_BIKESHED_FENCE_H__
+
+#include linux/types.h
+#include linux/dma-fence.h
+#include linux/dma-buf.h
+
+struct dma_bikeshed_fence {
+ struct dma_fence base;
+
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+ uint32_t seqno;
+
+ int (*enable_signaling)(struct dma_bikeshed_fence *fence);
+ void (*release)(struct dma_bikeshed_fence *fence);
+};
+
+/*
+ * TODO does it make sense to be able to enable dma-fence without dma-buf,
+ * or visa versa?
+ */
+#ifdef CONFIG_DMA_SHARED_BUFFER
+
+extern struct dma_fence_ops dma_bikeshed_fence_ops;
+
+static inline bool is_bikeshed_fence(struct dma_fence *fence)
+{
+ return fence-ops == dma_bikeshed_fence_ops;
+}
+
+static
[PATCH 3/3] dma-buf-mgr: multiple dma-buf synchronization (v3)
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com dma-buf-mgr handles the case of reserving single or multiple dma-bufs while trying to prevent deadlocks from buffers being reserved simultaneously. For this to happen extra functions have been introduced: + dma_buf_reserve() + dma_buf_unreserve() + dma_buf_wait_unreserved() Reserve a single buffer, optionally with a sequence to indicate this is part of a multi-dmabuf reservation. This function will return -EDEADLK and return immediately if reserving would cause a deadlock. In case a single buffer is being reserved, no sequence is needed, otherwise please use the dmabufmgr calls. If you want to attach a exclusive dma-fence, you have to wait until all shared fences have signalled completion. If there are none, or if a shared fence has to be attached, wait until last exclusive fence has signalled completion. The new fence has to be attached before unreserving the buffer, and in exclusive mode all previous fences will have be removed from the buffer, and unreffed when done with it. dmabufmgr methods: + dmabufmgr_validate_init() This function inits a dmabufmgr_validate structure and appends it to the tail of the list, with refcount set to 1. + dmabufmgr_validate_put() Convenience function to unref and free a dmabufmgr_validate structure. However if it's used for custom callback signalling, a custom function should be implemented. + dmabufmgr_reserve_buffers() This function takes a linked list of dmabufmgr_validate's, each one requires the following members to be set by the caller: - validate-head, list head - validate-bo, must be set to the dma-buf to reserve. - validate-shared, set to true if opened in shared mode. - validate-priv, can be used by the caller to identify this buffer. This function will then set the following members on succesful completion: - validate-num_fences, amount of valid fences to wait on before this buffer can be accessed. This can be 0. - validate-fences[0...num_fences-1] fences to wait on + dmabufmgr_backoff_reservation() This can be used when the caller encounters an error between reservation and usage. No new fence will be attached and all reservations will be undone without side effects. + dmabufmgr_fence_buffer_objects Upon successful completion a new fence will have to be attached. This function releases old fences and attaches the new one. + dmabufmgr_wait_completed_cpu A simple cpu waiter convenience function. Waits until all fences have signalled completion before returning. The rationale of refcounting dmabufmgr_validate lies in the wait dma_fence_cb wait member. Before calling dma_fence_add_callback you should increase the refcount on dmabufmgr_validate with dmabufmgr_validate_get, and on signal completion you should call kref_put(val-refcount, custom_free_signal); after all callbacks have added you drop the refcount by 1 also, when refcount drops to 0 all callbacks have been signalled, and dmabufmgr_validate has been waited on and can be freed. Since this will require atomic spinlocks to unlink the list and signal completion, a deadlock could occur if you try to call add_callback otherwise, so the refcount is used as a means of preventing this from occuring by having your custom free function take a device specific lock, removing from list and freeing the data. The nice/evil part about this is that this will also guarantee no memory leaks can occur behind your back. This allows delays completion by moving the dmabufmgr_validate list to be a part of the committed reservation. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/base/Makefile |3 - drivers/base/dma-buf-mgr.c | 240 +++ drivers/base/dma-buf.c | 113 drivers/base/dma-fence.c|1 include/linux/dma-buf-mgr.h | 123 ++ include/linux/dma-buf.h | 31 ++ include/linux/dma-fence.h |2 7 files changed, 511 insertions(+), 2 deletions(-) create mode 100644 drivers/base/dma-buf-mgr.c create mode 100644 include/linux/dma-buf-mgr.h diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 1e7723b..819281a 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -10,7 +10,8 @@ obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-buf-mgr.o \ + dma-bikeshed-fence.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER)+= firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf-mgr.c b/drivers/base/dma-buf-mgr.c new file mode 100644 index 000..fbcd631 --- /dev/null +++ b/drivers/base/dma-buf-mgr.c @@ -0,0 +1,240 @@ +/* + * Copyright (C) 2012
Philips saa7134 IR remote problem with linux kernel v2.6.35
Hi, I have a saa7134 analog tv card (Avermedia PCI pure m135a) with an IR remote. The IR remote is recognized by a standard keyboard and lirc used to work fine with this. However, from kernel v2.6.35, the IR remote does not work properly. The major problem is that every keystroke is registered after the next keystroke. So, if I press the sequence 123 on the remote, it actually comes up with only 12. If I then if I wait for 5 seconds, the 3 gets lost. Now I tried to bisect the kernel and it lead to the following commit: commit e40b1127f994a427568319d1be9b9e5ab1f58dd1 Author: David Härdeman da...@hardeman.nu Date: Thu Apr 15 18:46:00 2010 -0300 V4L/DVB: ir-core: change duration to be coded as a u32 integer This patch implements the agreed upon 1:31 integer encoded pulse/duration struct for ir-core raw decoders. All decoders have been tested after the change. Comments are welcome. Signed-off-by: David Härdeman da...@hardeman.nu Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I am willing to test patches if needed. Thanks and regards. /Partha Roy -- 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
Philips saa7134 IR remote problem with linux kernel v2.6.35
Hi, I have a saa7134 analog tv card (Avermedia PCI pure m135a) with an IR remote. The IR remote is recognized by a standard keyboard and lirc used to work fine with this. However, from kernel v2.6.35, the IR remote does not work properly. The major problem is that every keystroke is registered after the next keystroke. So, if I press the sequence 123 on the remote, it actually comes up with only 12. If I then if I wait for 5 seconds, the 3 gets lost. Now I tried to bisect the kernel and it lead to the following commit: commit e40b1127f994a427568319d1be9b9e5ab1f58dd1 Author: David Härdeman da...@hardeman.nu Date: Thu Apr 15 18:46:00 2010 -0300 V4L/DVB: ir-core: change duration to be coded as a u32 integer This patch implements the agreed upon 1:31 integer encoded pulse/duration struct for ir-core raw decoders. All decoders have been tested after the change. Comments are welcome. Signed-off-by: David Härdeman da...@hardeman.nu Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I am willing to test patches if needed. Thanks and regards. /Partha Roy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)
Op 07-08-12 19:53, Maarten Lankhorst schreef: A dma-fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU is still rendering. The display device sharing the buffer with the GPU would attach a callback to get notified when the GPU's rendering-complete IRQ fires, to update the scan-out address of the display, without having to wake up userspace. I implemented this for intel and debugged it with intel - nouveau interaction. Unfortunately the nouveau patches aren't ready at this point, but the git repo I'm using is available at: http://cgit.freedesktop.org/~mlankhorst/linux/ It has the patch series and a sample implementation for intel, based on drm-intel-next tree. I tried to keep it deadlock and race condition free as much as possible, but locking gets complicated enough that if I'm unlucky something might have slipped through regardless. Especially the locking in i915_gem_reset_requests, is screwed up. This shows what a real PITA it is to abort callbacks prematurely while keeping everything stable. As such, aborting requests should only be done in exceptional circumstances, in this case hardware died and things are already locked up anyhow.. ~Maarten -- 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] lmedm04 2.06 conversion to dvb-usb-v2 version 2
Em 07-08-2012 13:28, Antti Palosaari escreveu: On 08/06/2012 11:21 PM, Malcolm Priestley wrote: Conversion of lmedm04 to dvb-usb-v2 Functional changes m88rs2000 tuner now uses all callbacks. TODO migrate other tuners to the callbacks. This patch is applied on top of [BUG] Re: dvb_usb_lmedm04 crash Kernel (rs2000) http://patchwork.linuxtv.org/patch/13584/ Signed-off-by: Malcolm Priestley tvbox...@gmail.com Could you try to make this driver more generic? You use some internals of dvb-usb directly and most likely those are without a reason. For example data streaming, lme2510_kill_urb() kills directly urbs allocated and submitted by dvb-usb. Guess that driver is broken just after someone changes dvb-usb streaming code. Yeah, it is better to replace it by the dvb-usb-v2 solution (usb_clear_halt), as some special treatment there might be needed due to suspend/resume. lme2510_usb_talk() could be replaced by generic dvb_usbv2_generic_rw(). What is function of lme2510_int_read() ? I see you use own low level URB routines for here too. It starts polling, reads remote, tuner, demod, etc, and updates state. You would better to implement I2C-adapter correctly and then start Kernel work-queue, which reads same information using I2C-adapter. Or you could even abuse remote controller polling function provided by dvb-usb. While I don't know any technical details about this device, this looks similar to what dib0700_core does. Instead of polling IR, with is expensive, it sets an special endpoint to receive IR data, and sends an URB request. That URB request will be pending until someone kicks the IR. If nothing is pressed, no URB is received. This is a way better than polling, as no traffic happens while a key is not pressed. From what I saw at the driver, the mpeg stream is at endpoint 0x08, and it uses bulk transfer; for IR data, it uses endpoint 0x0a, and interrupt URB. So, this extra control is needed. It may make sense to move part of this code to the dvb-usb-v2 core (the part that starts/stops the URB handling), in order to properly handle device suspend/resume, as, depending on the suspend level, you might need to stop it, restarting at resume. The payload handling should be driver-specific, of course. So, in summary, that seems to be OK, for the current dvb-usb-v2 core, requiring further changes for suspend/resume to work properly. lme2510_get_stream_config() enables pid-filter again over the dvb-usb, but I can live with it because there is no dynamic configuration for that. Anyhow, is that really needed? I can live with the pid-filter abuse, but killing stream URBs on behalf of DVB-USB is something I don't like to see. If you have very good explanation and I cannot fix DVB USB to meet it I could consider that kind of hack. And it should be documented clearly adding necessary comments to code. Re-implementing that driver to use 100% DVB-USB services will reduce around 50% of code or more. The thing that bother me at the code is the implementation of a device-specific set_voltage() callback. This should be part of dvb-usb-v2 core, and, during suspend, it makes sense to set voltage to OFF, returning it to its original state during resume. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lmedm04 2.06 conversion to dvb-usb-v2 version 2
On 08/07/2012 10:12 PM, Mauro Carvalho Chehab wrote: Em 07-08-2012 13:28, Antti Palosaari escreveu: On 08/06/2012 11:21 PM, Malcolm Priestley wrote: Conversion of lmedm04 to dvb-usb-v2 Functional changes m88rs2000 tuner now uses all callbacks. TODO migrate other tuners to the callbacks. This patch is applied on top of [BUG] Re: dvb_usb_lmedm04 crash Kernel (rs2000) http://patchwork.linuxtv.org/patch/13584/ Signed-off-by: Malcolm Priestley tvbox...@gmail.com Could you try to make this driver more generic? You use some internals of dvb-usb directly and most likely those are without a reason. For example data streaming, lme2510_kill_urb() kills directly urbs allocated and submitted by dvb-usb. Guess that driver is broken just after someone changes dvb-usb streaming code. Yeah, it is better to replace it by the dvb-usb-v2 solution (usb_clear_halt), as some special treatment there might be needed due to suspend/resume. lme2510_usb_talk() could be replaced by generic dvb_usbv2_generic_rw(). What is function of lme2510_int_read() ? I see you use own low level URB routines for here too. It starts polling, reads remote, tuner, demod, etc, and updates state. You would better to implement I2C-adapter correctly and then start Kernel work-queue, which reads same information using I2C-adapter. Or you could even abuse remote controller polling function provided by dvb-usb. While I don't know any technical details about this device, this looks similar to what dib0700_core does. Instead of polling IR, with is expensive, it sets an special endpoint to receive IR data, and sends an URB request. That URB request will be pending until someone kicks the IR. If nothing is pressed, no URB is received. This is a way better than polling, as no traffic happens while a key is not pressed. From what I saw at the driver, the mpeg stream is at endpoint 0x08, and it uses bulk transfer; for IR data, it uses endpoint 0x0a, and interrupt URB. So, this extra control is needed. It may make sense to move part of this code to the dvb-usb-v2 core (the part that starts/stops the URB handling), in order to properly handle device suspend/resume, as, depending on the suspend level, you might need to stop it, restarting at resume. The payload handling should be driver-specific, of course. So, in summary, that seems to be OK, for the current dvb-usb-v2 core, requiring further changes for suspend/resume to work properly. lme2510_get_stream_config() enables pid-filter again over the dvb-usb, but I can live with it because there is no dynamic configuration for that. Anyhow, is that really needed? I can live with the pid-filter abuse, but killing stream URBs on behalf of DVB-USB is something I don't like to see. If you have very good explanation and I cannot fix DVB USB to meet it I could consider that kind of hack. And it should be documented clearly adding necessary comments to code. Re-implementing that driver to use 100% DVB-USB services will reduce around 50% of code or more. The thing that bother me at the code is the implementation of a device-specific set_voltage() callback. This should be part of dvb-usb-v2 core, and, during suspend, it makes sense to set voltage to OFF, returning it to its original state during resume. Regards, Mauro I think it is better to merge that now as is and try to improve those later. It does support suspend/resume currently (as callbacks are not defined at all). Also I have some upcoming patches for suspend/resume power-management. Due to that suspend/resume is not even worth to implement that driver until those are merged. Tested using LME2510C + M88RS2000 device. Acked-by: Antti Palosaari cr...@iki.fi Tested-by: Antti Palosaari cr...@iki.fi regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 Aug 7 19:00:23 CEST 2012 git hash:c3707357c6c651652a87a05eabd7582f90a4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification 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
Re: boot slow down
bjloc...@lockie.ca wrote: Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? Hi, The CX2388x firmware is _never_ built into the kernel. I'm not sure what that particular kernel config option is for. The kernel delay waiting for userspace to load firmware is settable using a node under /sys somewhere. The default is 60 seconds. You will have to change it in very early boot, or fix the hardcoded constant in the kernel and recompile your kernel. Shortening the delay may not get you entirely acceptable results. If udev is not, or is refusing to load firmware for the cx25840 module, then that module will not properly initialize the CX23885/7/8 A/V core hardware and will likely return with failure. I'm not sure if the cx23885 driver will happily continue on, if that happens. It works fine even though it times out. If you still have a modular kernel build around, you may wish to test with it. Blacklist the cx23885 module in /etc/modprobe.conf and the use udevadm to investigate what is going on with udev when you later modprobe the cx23885 driver. If building the video card driver into the kernel is causing you all the problems, then I simply recommend not doing that. I'll try it as a module. Regards, Andy -- 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
[PATCH] [media] Unlock the rc_dev lock when the raw device is missing
On 08/08/12 04:10, Herton Ronaldo Krzesinski wrote:
As it's desired for stable, this could also have
Cc: sta...@vger.kernel.org when applied, so it's picked up
automatically when lands in mainline. Also nitpicking some more,
may be the patch could have a Reported-by line added.
OK. Here it is again, with CC: stable, Reported-by Ben, and Herton's
Acked-by.
thanks,
Douglas
From 47aadfdaa5a6e5c3d8f1bf2b5be4c4a4156085ee Mon Sep 17 00:00:00 2001
From: Douglas Bagnall doug...@paradise.net.nz
Date: Tue, 7 Aug 2012 19:30:36 +1200
Subject: [PATCH] Unlock the rc_dev lock when the raw device is missing
As pointed out by Ben Hutchings, after commit 720bb6436, the lock was
being taken and not released when an rc_dev has a NULL raw device.
Cc: sta...@vger.kernel.org
Reported-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Douglas Bagnall doug...@paradise.net.nz
Acked-by: Herton R. Krzesinski herton.krzesin...@canonical.com
---
drivers/media/rc/rc-main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index cabc19c..dcd45d0 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -778,9 +778,10 @@ static ssize_t show_protocols(struct device *device,
} else if (dev-raw) {
enabled = dev-raw-enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
- } else
+ } else {
+ mutex_unlock(dev-lock);
return -ENODEV;
-
+ }
IR_dprintk(1, allowed - 0x%llx, enabled - 0x%llx\n,
(long long)allowed,
(long long)enabled);
--
1.7.9.5
Re: [PATCH 05/11] dvb: frontends: use %*ph to dump small buffers
On 08/07/2012 07:43 PM, Andy Shevchenko wrote:
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Antti Palosaari cr...@iki.fi
Acked-by: Antti Palosaari cr...@iki.fi
Nice! I have been looking that kind of solution long time.
---
drivers/media/dvb/frontends/cxd2820r_t.c |3 +--
drivers/media/dvb/frontends/nxt200x.c|8 +++-
drivers/media/dvb/frontends/rtl2830.c|2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_t.c
b/drivers/media/dvb/frontends/cxd2820r_t.c
index 1a02623..e5dd22b 100644
--- a/drivers/media/dvb/frontends/cxd2820r_t.c
+++ b/drivers/media/dvb/frontends/cxd2820r_t.c
@@ -389,8 +389,7 @@ int cxd2820r_read_status_t(struct dvb_frontend *fe,
fe_status_t *status)
}
}
- dbg(%s: lock=%02x %02x %02x %02x, __func__,
- buf[0], buf[1], buf[2], buf[3]);
+ dbg(%s: lock=%*ph, __func__, 4, buf);
return ret;
error:
diff --git a/drivers/media/dvb/frontends/nxt200x.c
b/drivers/media/dvb/frontends/nxt200x.c
index 03af52e..8e28894 100644
--- a/drivers/media/dvb/frontends/nxt200x.c
+++ b/drivers/media/dvb/frontends/nxt200x.c
@@ -331,7 +331,7 @@ static int nxt200x_writetuner (struct nxt200x_state* state,
u8* data)
dprintk(%s\n, __func__);
- dprintk(Tuner Bytes: %02X %02X %02X %02X\n, data[1], data[2],
data[3], data[4]);
+ dprintk(Tuner Bytes: %*ph\n, 4, data + 1);
/* if NXT2004, write directly to tuner. if NXT2002, write through NXT
chip.
* direct write is required for Philips TUV1236D and ALPS TDHU2 */
@@ -1161,8 +1161,7 @@ struct dvb_frontend* nxt200x_attach(const struct
nxt200x_config* config,
/* read card id */
nxt200x_readbytes(state, 0x00, buf, 5);
- dprintk(NXT info: %02X %02X %02X %02X %02X\n,
- buf[0], buf[1], buf[2], buf[3], buf[4]);
+ dprintk(NXT info: %*ph\n, 5, buf);
/* set demod chip */
switch (buf[0]) {
@@ -1201,8 +1200,7 @@ struct dvb_frontend* nxt200x_attach(const struct
nxt200x_config* config,
error:
kfree(state);
- printk(Unknown/Unsupported NXT chip: %02X %02X %02X %02X %02X\n,
- buf[0], buf[1], buf[2], buf[3], buf[4]);
+ pr_err(Unknown/Unsupported NXT chip: %*ph\n, 5, buf);
return NULL;
}
diff --git a/drivers/media/dvb/frontends/rtl2830.c
b/drivers/media/dvb/frontends/rtl2830.c
index 93612eb..8fa8b08 100644
--- a/drivers/media/dvb/frontends/rtl2830.c
+++ b/drivers/media/dvb/frontends/rtl2830.c
@@ -392,7 +392,7 @@ static int rtl2830_get_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- dbg(%s: TPS=%02x %02x %02x, __func__, buf[0], buf[1], buf[2]);
+ dbg(%s: TPS=%*ph, __func__, 3, buf);
switch ((buf[0] 2) 3) {
case 0:
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] dvb-usb: use %*ph to dump small buffers
From: Andy Shevchenko andriy.shevche...@linux.intel.com
[cr...@iki.fi: fix trivial merge conflict]
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Antti Palosaari cr...@iki.fi
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb-v2/af9015.c | 3 +--
drivers/media/dvb/dvb-usb-v2/af9035.c | 3 +--
drivers/media/dvb/dvb-usb/pctv452e.c | 7 +++
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb-v2/af9015.c
b/drivers/media/dvb/dvb-usb-v2/af9015.c
index 10363f6..e77429b 100644
--- a/drivers/media/dvb/dvb-usb-v2/af9015.c
+++ b/drivers/media/dvb/dvb-usb-v2/af9015.c
@@ -1199,8 +1199,7 @@ static int af9015_rc_query(struct dvb_usb_device *d)
/* Only process key if canary killed */
if (buf[16] != 0xff buf[0] != 0x01) {
- deb_rc(%s: key pressed %02x %02x %02x %02x\n, __func__,
- buf[12], buf[13], buf[14], buf[15]);
+ deb_rc(%s: key pressed %*ph\n, __func__, 4, buf + 12);
/* Reset the canary */
ret = af9015_write_reg(d, 0x98e9, 0xff);
diff --git a/drivers/media/dvb/dvb-usb-v2/af9035.c
b/drivers/media/dvb/dvb-usb-v2/af9035.c
index 79197f4..bb90b87 100644
--- a/drivers/media/dvb/dvb-usb-v2/af9035.c
+++ b/drivers/media/dvb/dvb-usb-v2/af9035.c
@@ -290,8 +290,7 @@ static int af9035_identify_state(struct dvb_usb_device *d,
const char **name)
if (ret 0)
goto err;
- pr_debug(%s: reply=%02x %02x %02x %02x\n, __func__,
- rbuf[0], rbuf[1], rbuf[2], rbuf[3]);
+ pr_debug(%s: reply=%*ph\n, __func__, 4, rbuf);
if (rbuf[0] || rbuf[1] || rbuf[2] || rbuf[3])
ret = WARM;
else
diff --git a/drivers/media/dvb/dvb-usb/pctv452e.c
b/drivers/media/dvb/dvb-usb/pctv452e.c
index f526eb0..02e8785 100644
--- a/drivers/media/dvb/dvb-usb/pctv452e.c
+++ b/drivers/media/dvb/dvb-usb/pctv452e.c
@@ -136,8 +136,8 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd,
u8 *data,
return 0;
failed:
- err(CI error %d; %02X %02X %02X - %02X %02X %02X.,
-ret, SYNC_BYTE_OUT, id, cmd, buf[0], buf[1], buf[2]);
+ err(CI error %d; %02X %02X %02X - %*ph.,
+ret, SYNC_BYTE_OUT, id, cmd, 3, buf);
return ret;
}
@@ -556,8 +556,7 @@ static int pctv452e_rc_query(struct dvb_usb_device *d)
return ret;
if (debug 3) {
- info(%s: read: %2d: %02x %02x %02x: , __func__,
- ret, rx[0], rx[1], rx[2]);
+ info(%s: read: %2d: %*ph: , __func__, ret, 3, rx);
for (i = 0; (i rx[3]) ((i+3) PCTV_ANSWER_LEN); i++)
info( %02x, rx[i+3]);
--
1.7.11.2
--
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] dvb_usb_v2: use %*ph to dump usb xfer debugs
Cc: Andy Shevchenko andriy.shevche...@linux.intel.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c
b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c
index 5f5bdd0..0431bee 100644
--- a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c
+++ b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c
@@ -21,7 +21,6 @@
#include dvb_usb_common.h
-#undef DVB_USB_XFER_DEBUG
int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8
*rbuf,
u16 rlen)
{
@@ -37,10 +36,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf,
u16 wlen, u8 *rbuf,
if (ret 0)
return ret;
-#ifdef DVB_USB_XFER_DEBUG
- print_hex_dump(KERN_DEBUG, KBUILD_MODNAME : , DUMP_PREFIX_NONE,
- 32, 1, wbuf, wlen, 0);
-#endif
+ dev_dbg(d-udev-dev, %s: %*ph\n, __func__, wlen, wbuf);
+
ret = usb_bulk_msg(d-udev, usb_sndbulkpipe(d-udev,
d-props-generic_bulk_ctrl_endpoint), wbuf, wlen,
actual_length, 2000);
@@ -64,11 +61,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf,
u16 wlen, u8 *rbuf,
dev_err(d-udev-dev, %s: 2nd usb_bulk_msg() \
failed=%d\n, KBUILD_MODNAME, ret);
-#ifdef DVB_USB_XFER_DEBUG
- print_hex_dump(KERN_DEBUG, KBUILD_MODNAME : ,
- DUMP_PREFIX_NONE, 32, 1, rbuf, actual_length,
- 0);
-#endif
+ dev_dbg(d-udev-dev, %s: %*ph\n, __func__,
+ actual_length, rbuf);
}
mutex_unlock(d-usb_mutex);
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] dvb-usb: use %*ph to dump small buffers
On 08/07/2012 07:43 PM, Andy Shevchenko wrote:
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Antti Palosaari cr...@iki.fi
Drop that patch.
af9015 and af9035 were moved to dvb-usb-v2 and due to that it conflicts.
I fixed merge conflict, reviewed and tested patch. New version (13678)
is here: http://patchwork.linuxtv.org/patch/13678/
And very big thanks Andy, I have been looking that for a while!
https://lkml.org/lkml/2012/7/5/85
regards
Antti
---
drivers/media/dvb/dvb-usb/af9015.c |3 +--
drivers/media/dvb/dvb-usb/af9035.c |3 +--
drivers/media/dvb/dvb-usb/pctv452e.c |7 +++
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 677fed7..ae1a01b 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1053,8 +1053,7 @@ static int af9015_rc_query(struct dvb_usb_device *d)
/* Only process key if canary killed */
if (buf[16] != 0xff buf[0] != 0x01) {
- deb_rc(%s: key pressed %02x %02x %02x %02x\n, __func__,
- buf[12], buf[13], buf[14], buf[15]);
+ deb_rc(%s: key pressed %*ph\n, __func__, 4, buf + 12);
/* Reset the canary */
ret = af9015_write_reg(d, 0x98e9, 0xff);
diff --git a/drivers/media/dvb/dvb-usb/af9035.c
b/drivers/media/dvb/dvb-usb/af9035.c
index e83b39d..01e3321 100644
--- a/drivers/media/dvb/dvb-usb/af9035.c
+++ b/drivers/media/dvb/dvb-usb/af9035.c
@@ -393,8 +393,7 @@ static int af9035_identify_state(struct usb_device *udev,
if (ret 0)
goto err;
- pr_debug(%s: reply=%02x %02x %02x %02x\n, __func__,
- rbuf[0], rbuf[1], rbuf[2], rbuf[3]);
+ pr_debug(%s: reply=%*ph\n, __func__, 4, rbuf);
if (rbuf[0] || rbuf[1] || rbuf[2] || rbuf[3])
*cold = 0;
else
diff --git a/drivers/media/dvb/dvb-usb/pctv452e.c
b/drivers/media/dvb/dvb-usb/pctv452e.c
index f526eb0..02e8785 100644
--- a/drivers/media/dvb/dvb-usb/pctv452e.c
+++ b/drivers/media/dvb/dvb-usb/pctv452e.c
@@ -136,8 +136,8 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd,
u8 *data,
return 0;
failed:
- err(CI error %d; %02X %02X %02X - %02X %02X %02X.,
-ret, SYNC_BYTE_OUT, id, cmd, buf[0], buf[1], buf[2]);
+ err(CI error %d; %02X %02X %02X - %*ph.,
+ret, SYNC_BYTE_OUT, id, cmd, 3, buf);
return ret;
}
@@ -556,8 +556,7 @@ static int pctv452e_rc_query(struct dvb_usb_device *d)
return ret;
if (debug 3) {
- info(%s: read: %2d: %02x %02x %02x: , __func__,
- ret, rx[0], rx[1], rx[2]);
+ info(%s: read: %2d: %*ph: , __func__, ret, 3, rx);
for (i = 0; (i rx[3]) ((i+3) PCTV_ANSWER_LEN); i++)
info( %02x, rx[i+3]);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: boot slow down
On 08/07/12 09:53, Andy Walls wrote: bjloc...@lockie.ca wrote: Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? Hi, The CX2388x firmware is _never_ built into the kernel. I'm not sure what that particular kernel config option is for. The kernel delay waiting for userspace to load firmware is settable using a node under /sys somewhere. The default is 60 seconds. You will have to change it in very early boot, or fix the hardcoded constant in the kernel and recompile your kernel. Shortening the delay may not get you entirely acceptable results. If udev is not, or is refusing to load firmware for the cx25840 module, then that module will not properly initialize the CX23885/7/8 A/V core hardware and will likely return with failure. I'm not sure if the cx23885 driver will happily continue on, if that happens. If you still have a modular kernel build around, you may wish to test with it. Blacklist the cx23885 module in /etc/modprobe.conf and the use udevadm to investigate what is going on with udev when you later modprobe the cx23885 driver. If building the video card driver into the kernel is causing you all the problems, then I simply recommend not doing that. Regards, Andy I make it a module and I ran into more problems. It seemed to load the firmware but Kaffeine says there is no video device. http://pastebin.com/ABVWVrma It seems to print a lot. -- 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: boot slow down
On 08/07/12 16:33, bjloc...@lockie.ca wrote: bjloc...@lockie.ca wrote: Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fijabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? Hi, The CX2388x firmware is _never_ built into the kernel. I'm not sure what that particular kernel config option is for. The kernel delay waiting for userspace to load firmware is settable using a node under /sys somewhere. The default is 60 seconds. You will have to change it in very early boot, or fix the hardcoded constant in the kernel and recompile your kernel. Shortening the delay may not get you entirely acceptable results. If udev is not, or is refusing to load firmware for the cx25840 module, then that module will not properly initialize the CX23885/7/8 A/V core hardware and will likely return with failure. I'm not sure if the cx23885 driver will happily continue on, if that happens. It works fine even though it times out. If you still have a modular kernel build around, you may wish to test with it. Blacklist the cx23885 module in /etc/modprobe.conf and the use udevadm to investigate what is going on with udev when you later modprobe the cx23885 driver. If building the video card driver into the kernel is causing you all the problems, then I simply recommend not doing that. I'll try it as a module. Regards, Andy This is what I tried before. It implies that I shouldn't need user space. ┌─── Include in-kernel firmware blobs in kernel binary ───┐ │ CONFIG_FIRMWARE_IN_KERNEL: │ │ │ │ The kernel source tree includes a number of firmware 'blobs'│ │ that are used by various drivers. The recommended way to│ │ use these is to run make firmware_install, which, after │ │ converting ihex files to binary, copies all of the needed │ │ binary files in firmware/ to /lib/firmware/ on your system so │ │ that they can be loaded by userspace helpers on request.│ │ │ │ Enabling this option will build each required firmware blob │ │ into the kernel directly, where request_firmware() will find│ │ them without having to call out to userspace. This may be │ │ useful if your root file system requires a device that uses │ │ such
Re: boot slow down
On 08/07/12 17:42, James wrote: On 08/07/12 16:33, bjloc...@lockie.ca wrote: bjloc...@lockie.ca wrote: Hi James, On Mon, Aug 06, 2012 at 12:38:51AM -0400, James wrote: On 08/05/12 17:20, Sakari Ailus wrote: Hi Andy and James, On Sat, Aug 04, 2012 at 06:28:19PM -0400, James wrote: On 08/04/12 13:42, Andy Walls wrote: James bjloc...@lockie.ca wrote: There's a big pause before the 'unable' [2.243856] usb 4-1: Manufacturer: Logitech [ 62.739097] cx25840 6-0044: unable to open firmware v4l-cx23885-avcore-01.fw I have a cx23885 cx23885[0]: registered device video0 [v4l2] Is there any way to stop it from trying to load the firmware? What is the firmware for, analog tv? Digital works fine and analog is useless to me. I assume it is timing out there. -- 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 The firmware is for the analog broadcast audio standard (e.g. BTSC) detection microcontroller. The A/V core of the CX23885/7/8 chips is for analog vidoe and audio processing (broadcast, CVBS, SVideo, audio L/R in). The A/V core of the CX23885 provides the IR unit and the Video PLL provides the timing for the IR unit. The A/V core of the CX23888 provides the Video PLL which is the timing for the IR unit in the CX23888. Just grab the firmware and be done with it. Don't waste time with trying to make the cx23885 working properly but halfway. Regards, Andy I already have the firmware. # ls -l /lib/firmware/v4l-cx23885-avcore-01.fw -rw-r--r-- 1 root root 16382 Oct 15 2011 /lib/firmware/v4l-cx23885-avcore-01.fw The timeout if for allowing the user space helper enough time to provide the driver with the firmware, but it seems the helper isn't around as the timeout expires. Is udev running around the time of the first line? Is the driver linked directly into the kernel or is it a module? Kind regards, I have this set so the firmware is in the kernel. Symbol: FIRMWARE_IN_KERNEL [=y] I don't know about that driver, but if the udev would have to provide the firmware, and it's not running, the delay is expected. Two seconds after kernel startup is so early that the user space, including udev, might not yet be running. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk Doesn't that kernel option mean the firmware is put into the kernel at kernel build time? If I build the module, is there a module option to skip the delay? Hi, The CX2388x firmware is _never_ built into the kernel. I'm not sure what that particular kernel config option is for. The kernel delay waiting for userspace to load firmware is settable using a node under /sys somewhere. The default is 60 seconds. You will have to change it in very early boot, or fix the hardcoded constant in the kernel and recompile your kernel. Shortening the delay may not get you entirely acceptable results. If udev is not, or is refusing to load firmware for the cx25840 module, then that module will not properly initialize the CX23885/7/8 A/V core hardware and will likely return with failure. I'm not sure if the cx23885 driver will happily continue on, if that happens. It works fine even though it times out. If you still have a modular kernel build around, you may wish to test with it. Blacklist the cx23885 module in /etc/modprobe.conf and the use udevadm to investigate what is going on with udev when you later modprobe the cx23885 driver. If building the video card driver into the kernel is causing you all the problems, then I simply recommend not doing that. I'll try it as a module. Regards, Andy This is what I tried before. It implies that I shouldn't need user space. ┌─── Include in-kernel firmware blobs in kernel binary ───┐ │ CONFIG_FIRMWARE_IN_KERNEL: │ │ │ │ The kernel source tree includes a number of firmware 'blobs'│ │ that are used by various drivers. The recommended way to│ │ use these is to run make firmware_install, which, after │ │ converting ihex files to binary, copies all of the needed │ │ binary files in firmware/ to /lib/firmware/ on your system so │ │ that they can be loaded by userspace helpers on request.│ │ │ │ Enabling this option will build each required firmware blob │ │ into the kernel directly, where request_firmware() will find│ │ them without having to call out to userspace. This may be │ │ useful if your root
Re: [PATCH 2/2] dvb_usb_v2: use %*ph to dump usb xfer debugs
On Wed, Aug 8, 2012 at 1:56 AM, Antti Palosaari cr...@iki.fi wrote: diff --git a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c index 5f5bdd0..0431bee 100644 --- a/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c +++ b/drivers/media/dvb/dvb-usb-v2/dvb_usb_urb.c @@ -37,10 +36,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8 *rbuf, if (ret 0) return ret; -#ifdef DVB_USB_XFER_DEBUG - print_hex_dump(KERN_DEBUG, KBUILD_MODNAME : , DUMP_PREFIX_NONE, - 32, 1, wbuf, wlen, 0); -#endif + dev_dbg(d-udev-dev, %s: %*ph\n, __func__, wlen, wbuf); + ret = usb_bulk_msg(d-udev, usb_sndbulkpipe(d-udev, d-props-generic_bulk_ctrl_endpoint), wbuf, wlen, actual_length, 2000); @@ -64,11 +61,8 @@ int dvb_usbv2_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen, u8 *rbuf, dev_err(d-udev-dev, %s: 2nd usb_bulk_msg() \ failed=%d\n, KBUILD_MODNAME, ret); -#ifdef DVB_USB_XFER_DEBUG - print_hex_dump(KERN_DEBUG, KBUILD_MODNAME : , - DUMP_PREFIX_NONE, 32, 1, rbuf, actual_length, - 0); -#endif + dev_dbg(d-udev-dev, %s: %*ph\n, __func__, + actual_length, rbuf); } Antti, I didn't check how long buffer could be in above cases, but be aware that %*ph prints up to 64 bytes only. Is it enough here? -- With Best Regards, Andy Shevchenko -- 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
