Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)

[Sumit Semwal]

Hi Maarten,

On 8 August 2012 00:17, Maarten Lankhorst
 wrote:
> 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.

Thanks for this patchset; Could you please also fill up
Documentation/dma-buf-sharing.txt, to include the relevant bits?

We've tried to make sure the Documentation corresponding is kept
up-to-date as the framework has grown, and new features are added to
it - and I think features as important as dma-fence and dmabufmgr do
warrant a healthy update.
>
> 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
>

-- 
Thanks and best regards,
Sumit Semwal
--
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 2/2] dvb_usb_v2: use %*ph to dump usb xfer debugs

[Andy Shevchenko]

On Wed, Aug 8, 2012 at 1:56 AM, Antti Palosaari  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

Re: boot slow down

[James]

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  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

Re: boot slow down

[James]

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  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, c

Re: boot slow down

[James]

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  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: [PATCH 04/11] dvb-usb: use %*ph to dump small buffers

[Antti Palosaari]

On 08/07/2012 07:43 PM, Andy Shevchenko wrote:

Signed-off-by: Andy Shevchenko 
Cc: Antti Palosaari 


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

[PATCH 2/2] dvb_usb_v2: use %*ph to dump usb xfer debugs

[Antti Palosaari]

Cc: Andy Shevchenko 
Signed-off-by: Antti Palosaari 
---
 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

[PATCH 1/2] dvb-usb: use %*ph to dump small buffers

[Antti Palosaari]

From: Andy Shevchenko 

[cr...@iki.fi: fix trivial merge conflict]
Signed-off-by: Andy Shevchenko 
Cc: Antti Palosaari 
Signed-off-by: Antti Palosaari 
---
 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

Re: [PATCH 05/11] dvb: frontends: use %*ph to dump small buffers

[Antti Palosaari]

On 08/07/2012 07:43 PM, Andy Shevchenko wrote:

Signed-off-by: Andy Shevchenko 
Cc: Antti Palosaari 

Acked-by: Antti Palosaari 

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] [media] Unlock the rc_dev lock when the raw device is missing

[Douglas Bagnall]

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 
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: 
Reported-by: Ben Hutchings 
Signed-off-by: Douglas Bagnall 
Acked-by: Herton R. Krzesinski 
---
 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: boot slow down

[bjlockie]

> 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  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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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: [PATCH] lmedm04 2.06 conversion to dvb-usb-v2 version 2

[Antti Palosaari]

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 


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 
Tested-by: Antti Palosaari 

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] lmedm04 2.06 conversion to dvb-usb-v2 version 2

[Mauro Carvalho Chehab]

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 
> 
> 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 1/3] dma-fence: dma-buf synchronization (v7)

[Maarten Lankhorst]

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

Philips saa7134 IR remote problem with linux kernel v2.6.35

[Partha Guha Roy]

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 
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 
Signed-off-by: Mauro Carvalho Chehab 

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

[Partha Guha Roy]

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 
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 
Signed-off-by: Mauro Carvalho Chehab 

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

[PATCH 3/3] dma-buf-mgr: multiple dma-buf synchronization (v3)

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 

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 
---
 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 Canonical Ltd
+ *
+ * Based on ttm_bo.c which bears th

[PATCH 2/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing

[Maarten Lankhorst]

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 
---
 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 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+
+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 
+ *
+ * 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 .
+ */
+
+#ifndef __DMA_BIKESHED_FENCE_H__
+#define __DMA_BIKESHED_FENCE_H__
+
+#include 
+#include 
+#include 
+
+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 inline struct dma_bikeshed_fence *to_bikeshed_fence(struct dma_fence 
*fence)
+{
+   if (WARN_ON(!is_bikeshed_fence(fence)))
+   return NULL;
+  

[PATCH 1/3] dma-fence: dma-buf synchronization (v7)

[Maarten Lankhorst]

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 
---
 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
--- a/drivers/base/Makefile
+++ b/drivers/base

Administrator Letzte Warnung !!

[System Administrator]

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 11/11] au0828: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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

[PATCH 07/11] gspca: use %*ph to print small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
Cc: Hans de Goede 
---
 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 03/11] common: tunners: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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 09/11] ati_remote: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
Cc: Anssi Hannula 
---
 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 05/11] dvb: frontends: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
Cc: Antti Palosaari 
---
 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 04/11] dvb-usb: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
Cc: Antti Palosaari 
---
 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]);
 
-- 
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

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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 10/11] saa7127: use %*ph to print small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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 06/11] radio-shark2: use %*ph to print small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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 02/11] dvb: nxt200x: apply levels to the printk()s

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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:
  

[PATCH 01/11] saa7164: use native print_hex_dump() instead of custom one

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 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) - 

Re: [PATCH] lmedm04 2.06 conversion to dvb-usb-v2 version 2

[Antti Palosaari]

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 


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

Re: [3.0.y+] [media] Avoid sysfs oops when an rc_dev's raw device is absent

[Herton Ronaldo Krzesinski]

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 
> 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 

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 

> ---
>  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 v3 1/4] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT

[Marek Szyprowski]

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 
> ---
>  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 R&D 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 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available

[Marek Szyprowski]

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 

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 R&D 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

it913x: DEV it913x Error

[Antti Palosaari]

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: boot slow down

[Andy Walls]

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  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

[RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)

[Konke Radlow]

---
 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 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#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/* Music / Speech flag */
+#define V4L2_RDS_PTYN  0x80/* Program Type Name */
+#define V4L2_RDS_RT

[RFC PATCH 2/2] Add rds-ctl tool (with changes proposed in RFC)

[Konke Radlow]

---
 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 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARRAY_SIZE(arr) ((int)(sizeof(arr) / sizeof((arr)[0])))
+
+typedef std::vector dev_vec;
+typedef std::map 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", no_argument, 0, OptVerbose},
+   {"wait-limit", required_argument, 0, OptWaitLimit},
+   {"wrapper", no_argument, 0, OptUseWrapper},
+   {0, 0, 0, 0}
+};
+
+static void usage_hint(void)
+{
+   fprintf(stderr, "Tr

[RFC PATCH 0/2] Add support for RDS decoding (updated)

[Konke Radlow]

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

Re: boot slow down

[bjlockie]

> 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  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

Re: [PATCH 00/24] Various HVR-950q and xc5000 fixes

[Hans Verkuil]

On Tue 7 August 2012 14:48:41 Devin Heitmueller wrote:
> On Tue, Aug 7, 2012 at 2:26 AM, Hans Verkuil  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

help me, Kconfig problem

[Antti Palosaari]

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

[Devin Heitmueller]

On Tue, Aug 7, 2012 at 2:26 AM, Hans Verkuil  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

Re: [PATCH 3/3] [media] az6007: handle CI during suspend/resume

[Mauro Carvalho Chehab]

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 separ

Re: [PATCH v3 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available

[Laurent Pinchart]

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 
> 
> Acked-by: Hideki EIRAKU 

I obviously meant

Acked-by: Laurent Pinchart 

> 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

[Antti Palosaari]

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

[Laurent Pinchart]

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 

Acked-by: Hideki EIRAKU 

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

[Mauro Carvalho Chehab]

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: boot slow down

[Sakari Ailus]

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  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] omap_vout: Set DSS overlay_info only if paddr is non zero

[Laurent Pinchart]

On Thursday 28 June 2012 11:36:48 Semwal, Sumit wrote:
> On Mon, Mar 19, 2012 at 5:16 PM, Archit Taneja  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 Taneja
> >> ---
> >> 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 Valkeinen
> >> 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 int

[PATCH] media: fix MEDIA_IOC_DEVICE_INFO return code

[Nicolas THERY]

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 
---
 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

[PATCH] m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode

[Sylwester Nawrocki]

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 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 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

Re: [PATCH] uvcvideo: Fix uvc_fixup_video_ctrl() format search

[Stephan Lachowsky]

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

Re: [3.0.y+] [media] Avoid sysfs oops when an rc_dev's raw device is absent

[Douglas Bagnall]

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 
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 
---
 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: Vacations.

[Sascha Hauer]

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