date:20170326

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

2017-03-26 Thread Ayaka



從我的 iPad 傳送

> Ander Conselvan De Oliveira  於 2017年3月14日 下午9:53 寫道：
> 
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>> 
>> 從我的 iPad 傳送
>> 
 Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
 
 On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
 
 
 從我的 iPad 傳送
 
>> Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
>> 
>> On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
>> per channel video format.
>> 
>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
>> per channel video format.
>> 
>> V3: Added P012 and fixed cpp for P010
>> V4: format definition refined per review
>> V5: Format comment block for each new pixel format
>> V6: reversed Cb/Cr order in comments
>> v7: reversed Cb/Cr order in comments of header files, remove
>> the wrong part of commit message.
> 
> What? Why? You just undid what Clint did in v6.
 
 He missed a file also keeping the wrong description of rockchip.
>>> 
>>> I don't follow. Who missed what exactly?
>> 
>> What he sent is v5, I increase the order number twice in the message, it 
>> confuse me as well. 
>> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
> 
> Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
> 
> https://patchwork.freedesktop.org/patch/141342/
Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.
> 
> 
> Ander
> 
>>> 
>>> 
> 
>> 
>> Cc: Daniel Stone 
>> Cc: Ville Syrjälä 
>> 
>> Signed-off-by: Randy Li 
>> Signed-off-by: Clint Taylor 
>> ---
>> drivers/gpu/drm/drm_fourcc.c  |  3 +++
>> include/uapi/drm/drm_fourcc.h | 21 +
>> 2 files changed, 24 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index 90d2cc8..3e0fd58 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 
>> format)
>>  { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes = 1, 
>> .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>>  { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes = 1, 
>> .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
>> +{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>> +{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes = 
>> 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
>>  };
>> 
>>  unsigned int i;
>> diff --git a/include/uapi/drm/drm_fourcc.h 
>> b/include/uapi/drm/drm_fourcc.h
>> index ef20abb..306f979 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -128,6 +128,27 @@ extern "C" {
>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
>> non-subsampled Cb:Cr plane */
>> 
>> /*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
>> + */
>> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
>> subsampled Cb:Cr plane 10 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
>> + */
>> +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
>> subsampled Cb:Cr plane 12 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y little endian
>> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
>> + */
>> +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
>> subsampled Cb:Cr plane 16 bits per channel */
>> +
>> +/*
>> * 3 plane YCbCr
>> * index 0: Y plane, [7:0] Y
>> * index 1: Cb plane, [7:0] Cb
>> -- 
>> 2.7.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
>>> 
>>> -- 
>>> Ville Syrjälä
>>> Intel OTC
>> 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

cron job: media_tree daily build: ERRORS

2017-03-26 Thread 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:   Mon Mar 27 05:00:14 CEST 2017
media-tree git hash:c3d4fb0fb41f4b5eafeee51173c14e50be12f839
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 8fc88615b49843acb82cd8316d0bc4ab8474cba2
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH] staging: media: atomisp: compress return logic

2017-03-26 Thread kbuild test robot

Hi Arushi,

[auto build test ERROR on next-20170323]
[cannot apply to linuxtv-media/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Arushi-Singhal/staging-media-atomisp-compress-return-logic/20170327-030611
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c: 
In function 'ia_css_bufq_dequeue_isys_event':
>> drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c:467:18:
>>  error: unused variable 'return_err' [-Werror=unused-variable]
 enum ia_css_err return_err;
 ^~
   cc1: all warnings being treated as errors

vim +/return_err +467 
drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c

a49d2536 Alan Cox 2017-02-17  461  }
a49d2536 Alan Cox 2017-02-17  462  
a49d2536 Alan Cox 2017-02-17  463  enum  ia_css_err 
ia_css_bufq_dequeue_isys_event(
a49d2536 Alan Cox 2017-02-17  464   uint8_t item[BUFQ_EVENT_SIZE])
a49d2536 Alan Cox 2017-02-17  465  {
a49d2536 Alan Cox 2017-02-17  466  #if !defined(HAS_NO_INPUT_SYSTEM)
a49d2536 Alan Cox 2017-02-17 @467   enum ia_css_err return_err;
a49d2536 Alan Cox 2017-02-17  468   int error = 0;
a49d2536 Alan Cox 2017-02-17  469   ia_css_queue_t *q;
a49d2536 Alan Cox 2017-02-17  470  

:: The code at line 467 was first introduced by commit
:: a49d25364dfb9f8a64037488a39ab1f56c5fa419 staging/atomisp: Add support 
for the Intel IPU v2

:: TO: Alan Cox 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v7 5/9] media: venus: vdec: add video decoder files

2017-03-26 Thread Nicolas Dufresne

Le dimanche 26 mars 2017 à 00:30 +0200, Stanimir Varbanov a écrit :
> > > +vb->planes[0].data_offset = data_offset;
> > > +vb->timestamp = timestamp_us * NSEC_PER_USEC;
> > > +vbuf->sequence = inst->sequence++;
> > 
> > timestamp and sequence are only set for CAPTURE, not OUTPUT. Is
> > that correct?
> 
> Correct. I can add sequence for the OUTPUT queue too, but I have no idea 
> how that sequence is used by userspace.

Neither GStreamer or Chromium seems to use it. What does that number
means for a m2m driver ? Does it really means something ?

Nicolas

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 12/12] [media] ddbridge: support STV0367-based cards and modules

2017-03-26 Thread Daniel Scheller

Am Mon, 27 Mar 2017 00:46:45 +0800
schrieb kbuild test robot <l...@intel.com>:

> [auto build test WARNING on linuxtv-media/master]
> [also build test WARNING on v4.11-rc3 next-20170324]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Scheller/stv0367-ddbridge-support-CTv6-FlexCT-hardware/20170326-235957
> base:   git://linuxtv.org/media_tree.git master config:
> x86_64-rhel-7.2 (attached as .config) compiler: gcc-6 (Debian
> 6.2.0-3) 6.2.0 20160901 reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/media/pci/ddbridge/ddbridge-core.c: In function
> 'dvb_input_detach':
> >> drivers/media/pci/ddbridge/ddbridge-core.c:891:3: warning: this
> >> 'if' clause does not guard... [-Wmisleading-indentation]  
>   if (input->fe2)
>   ^~
>drivers/media/pci/ddbridge/ddbridge-core.c:893:4: note: ...this
> statement, but the latter is misleadingly indented as if it is
> guarded by the 'if' input->fe2 = NULL; ^

Fixed in what I'll post as V3 series (planned for mid-week).

Daniel

Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

2017-03-26 Thread Sean Young

On Sun, Mar 26, 2017 at 02:28:08PM -0400, A Sun wrote:
> commit 
> https://github.com/asunxx/linux/commit/17fe3b51f4ad5202a876ea4c92b5d99d4e166823
> Author: A Sun 
> Date:   Sun, 26 Mar 2017 13:24:18 -0400 

Please don't include this.

> 
> Bug:
> 
> RX -EPIPE failure with infinite loop and flooding of
> Mar 20 22:24:56 raspberrypi kernel: [ 2851.966506] mceusb 1-1.2:1.0: Error: 
> urb status = -32
> log message at 8000 messages per second.
> Bug trigger appears to be normal, but heavy, IR receiver use.
> Driver and Linux host become unusable after error.
> Also seen at https://sourceforge.net/p/lirc/mailman/message/34886165/
> 
> Fix:
> 
> Message reports RX usb halt (stall) condition requiring usb_clear_halt() call 
> in non-interrupt context to recover.
> Add driver workqueue call to perform this recovery based on method in use for 
> the usbnet device driver.
> 
> Tested with:
> 
> Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l 
> GNU/Linux
> mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce 
> emulator interface version 1
> mceusb 1-1.2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors (0x1 active)

It would be nice to have this tested against a mainline kernel. I thought
that was entirely possible on raspberry pis nowadays.
> 
> Signed-off-by: A Sun 
> ---
>  drivers/media/rc/mceusb.c | 67 
> ++-
>  1 file changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index 238d8ea..7b6f9e5 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -36,12 +36,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -#define DRIVER_VERSION   "1.92"
> +#define DRIVER_VERSION   "1.93"
>  #define DRIVER_AUTHOR"Jarod Wilson "
>  #define DRIVER_DESC  "Windows Media Center Ed. eHome Infrared Transceiver " \
>   "device driver"
> @@ -417,6 +418,7 @@ struct mceusb_dev {
>   /* usb */
>   struct usb_device *usbdev;
>   struct urb *urb_in;
> + unsigned int pipe_in;
>   struct usb_endpoint_descriptor *usb_ep_out;
>  
>   /* buffers and dma */
> @@ -454,6 +456,12 @@ struct mceusb_dev {
>   u8 num_rxports; /* number of receive sensors */
>   u8 txports_cabled;  /* bitmask of transmitters with cable */
>   u8 rxports_active;  /* bitmask of active receive sensors */
> +
> + /* kevent support */
> + struct work_struct kevent;

kevent is not a descriptive name. How about something like clear_halt?

> + unsigned long kevent_flags;
> +#define EVENT_TX_HALT0
> +#define EVENT_RX_HALT1

EVENT_TX_HALT is never used, so kevent_flags is only ever set to 1. The
entire field can be dropped.

>  };
>  
>  /* MCE Device Command Strings, generally a port and command pair */
> @@ -1025,6 +1033,23 @@ static void mceusb_process_ir_data(struct mceusb_dev 
> *ir, int buf_len)
>   }
>  }
>  
> +/*
> + * Workqueue task dispatcher
> + * for work that can't be done in interrupt handlers
> + * (mceusb_dev_recv() and mce_async_callback()) nor tasklets.
> + * Invokes mceusb_deferred_kevent() for recovering from
> + * error events specified by the kevent bit field.
> + */
> +static void mceusb_defer_kevent(struct mceusb_dev *ir, int kevent)
> +{
> + set_bit(kevent, >kevent_flags);
> + if (!schedule_work(>kevent)) {
> + dev_err(ir->dev, "kevent %d may have been dropped", kevent);
> + } else {
> + dev_dbg(ir->dev, "kevent %d scheduled", kevent);
> + }
> +}

Again name is not very descriptive.

> +
>  static void mceusb_dev_recv(struct urb *urb)
>  {
>   struct mceusb_dev *ir;
> @@ -1052,6 +1077,11 @@ static void mceusb_dev_recv(struct urb *urb)
>   return;
>  
>   case -EPIPE:
> + dev_err(ir->dev, "Error: urb status = %d (RX HALT)",
> + urb->status);
> + mceusb_defer_kevent(ir, EVENT_RX_HALT);

Here you could simply call schedule_work(). Note that EPIPE might also
be returned for device disconnect for some host controllers.

> + return;
> +
>   default:
>   dev_err(ir->dev, "Error: urb status = %d", urb->status);
>   break;
> @@ -1170,6 +1200,37 @@ static void mceusb_flash_led(struct mceusb_dev *ir)
>   mce_async_out(ir, FLASH_LED, sizeof(FLASH_LED));
>  }
>  
> +/*
> + * Workqueue function
> + * for resetting or recovering device after occurrence of error events
> + * specified in ir->kevent bit field.
> + * Function runs (via schedule_work()) in non-interrupt context, for
> + * calls here (such as usb_clear_halt()) requiring non-interrupt context.
> + */
> +static void mceusb_deferred_kevent(struct work_struct *work)
> +{
> + struct mceusb_dev *ir =
> + container_of(work,

[PATCH 3/3] [media] mceusb: fix inaccurate debug buffer dumps,and misleading debug messages

2017-03-26 Thread A Sun

commit 
https://github.com/asunxx/linux/commit/14cae79824739ae03caa3b1c4f66cbdf73654bde
Author: A Sun 
Date:   Sun, 26 Mar 2017 14:55:31 -0400

Bug:

Some dev_dbg messages are misleading.
Some dev_dbg messages have inconsistent formatting.
mceusb_dev_printdata() prints incorrect range of bytes (0 to len) in buffer 
which the driver will actually process next.

Fix:

Add size of received data argument to mceusb_dev_printdata().
Revise buffer print range to (offset to offset+len).
Remove static USB_BUFLEN = 32, which is variable depending on device
(buffer size is 64 for Pinnacle IR transceiver).
Revise bound test to prevent reporting data beyond end of read or end of buffer.
Drop "\n" use from dev_dbg().
References to "receive request" should read "send request".

Tested with:

Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l 
GNU/Linux
mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator 
interface version 1
mceusb 1-1.2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors (0x1 active)

Signed-off-by: A Sun 
---
 drivers/media/rc/mceusb.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 720df6f..a9a9a85 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -48,7 +48,6 @@
"device driver"
 #define DRIVER_NAME"mceusb"
 
-#define USB_BUFLEN 32 /* USB reception buffer length */
 #define USB_CTRL_MSG_SZ2  /* Size of usb ctrl msg on gen1 hw */
 #define MCE_G1_INIT_MSGS   40 /* Init messages on gen1 hw to throw out */
 
@@ -535,7 +534,7 @@ static int mceusb_cmd_datasize(u8 cmd, u8 subcmd)
 }
 
 static void mceusb_dev_printdata(struct mceusb_dev *ir, char *buf,
-int offset, int len, bool out)
+int buf_len, int offset, int len, bool out)
 {
 #if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG)
char *inout;
@@ -552,7 +551,8 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
return;
 
dev_dbg(dev, "%cx data: %*ph (length=%d)",
-   (out ? 't' : 'r'), min(len, USB_BUFLEN), buf, len);
+   (out ? 't' : 'r'),
+   min(len, buf_len - offset), buf + offset, len);
 
inout = out ? "Request" : "Got";
 
@@ -709,7 +709,8 @@ static void mce_async_callback(struct urb *urb)
case 0:
len = urb->actual_length;
 
-   mceusb_dev_printdata(ir, urb->transfer_buffer, 0, len, true);
+   mceusb_dev_printdata(ir, urb->transfer_buffer, len,
+0, len, true);
break;
 
case -ECONNRESET:
@@ -729,7 +730,7 @@ static void mce_async_callback(struct urb *urb)
usb_free_urb(urb);
 }
 
-/* request incoming or send outgoing usb packet - used to initialize remote */
+/* request outgoing (send) usb packet - used to initialize remote */
 static void mce_request_packet(struct mceusb_dev *ir, unsigned char *data,
int size)
 {
@@ -740,7 +741,7 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
 
async_urb = usb_alloc_urb(0, GFP_KERNEL);
if (unlikely(!async_urb)) {
-   dev_err(dev, "Error, couldn't allocate urb!\n");
+   dev_err(dev, "Error, couldn't allocate urb!");
return;
}
 
@@ -766,17 +767,17 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
}
memcpy(async_buf, data, size);
 
-   dev_dbg(dev, "receive request called (size=%#x)", size);
+   dev_dbg(dev, "send request called (size=%#x)", size);
 
async_urb->transfer_buffer_length = size;
async_urb->dev = ir->usbdev;
 
res = usb_submit_urb(async_urb, GFP_ATOMIC);
if (res) {
-   dev_err(dev, "receive request FAILED! (res=%d)", res);
+   dev_err(dev, "send request FAILED! (res=%d)", res);
return;
}
-   dev_dbg(dev, "receive request complete (res=%d)", res);
+   dev_dbg(dev, "send request complete (res=%d)", res);
 }
 
 static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size)
@@ -982,7 +983,7 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir, 
int buf_len)
switch (ir->parser_state) {
case SUBCMD:
ir->rem = mceusb_cmd_datasize(ir->cmd, ir->buf_in[i]);
-   mceusb_dev_printdata(ir, ir->buf_in, i - 1,
+   mceusb_dev_printdata(ir, ir->buf_in, buf_len, i - 1,
 ir->rem + 2, false);
mceusb_handle_command(ir, i);
ir->parser_state = CMD_DATA;
@@ -994,7 +995,7 @@ static void

[PATCH 2/3] [media] mceusb: sporadic RX truncation corruption fix

2017-03-26 Thread A Sun

commit 
https://github.com/asunxx/linux/commit/d71c609e99cabc0a92a4d0b225486cbc09bbd8bd
Author: A Sun 
Date:   Sun, 26 Mar 2017 14:11:49 -0400

Bug:

Intermittent RX truncation and loss of IR received data.
This resulted in receive stream synchronization errors where driver attempted 
to incorrectly parse IR data (eg 0x90 below) as command response.

Mar 22 12:01:40 raspberrypi kernel: [ 3969.139898] mceusb 1-1.2:1.0: processed 
IR data
Mar 22 12:01:40 raspberrypi kernel: [ 3969.151315] mceusb 1-1.2:1.0: rx data: 
00 90 (length=2)
Mar 22 12:01:40 raspberrypi kernel: [ 3969.151321] mceusb 1-1.2:1.0: Unknown 
command 0x00 0x90
Mar 22 12:01:40 raspberrypi kernel: [ 3969.151336] mceusb 1-1.2:1.0: rx data: 
98 0a 8d 0a 8e 0a 8e 0a 8e 0a 8e 0a 9a 0a 8e 0a 0b 3a 8e 00 80 41 59 00 00 
(length=25)
Mar 22 12:01:40 raspberrypi kernel: [ 3969.151341] mceusb 1-1.2:1.0: Raw IR 
data, 24 pulse/space samples
Mar 22 12:01:40 raspberrypi kernel: [ 3969.151348] mceusb 1-1.2:1.0: Storing 
space with duration 50

Bug trigger appears to be normal, but heavy, IR receiver use.

Fix:

Cause may be receiver with ep_in bulk endpoint incorrectly bound to 
usb_fill_int_urb() urb for interrupt endpoint.
This may also have been the root cause for "RX -EPIPE (urb status = -32)" 
lockups.
In mceusb_dev_probe(), test ep_in endpoint for int versus bulk and use 
usb_fill_bulk_urb() as appropriate.

Tested with:
Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l 
GNU/Linux
mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator 
interface version 1
mceusb 1-1.2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors (0x1 active)

Signed-off-by: A Sun 
---
 drivers/media/rc/mceusb.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 7b6f9e5..720df6f 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1401,8 +1401,13 @@ static int mceusb_dev_probe(struct usb_interface *intf,
INIT_WORK(>kevent, mceusb_deferred_kevent);
 
/* wire up inbound data handler */
-   usb_fill_int_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
+   if (usb_endpoint_xfer_int(ep_in)) {
+   usb_fill_int_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
mceusb_dev_recv, ir, ep_in->bInterval);
+   } else {
+   usb_fill_bulk_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
+   mceusb_dev_recv, ir);
+   }
ir->urb_in->transfer_dma = ir->dma_in;
ir->urb_in->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 
-- 
2.1.4

[PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

2017-03-26 Thread A Sun

commit 
https://github.com/asunxx/linux/commit/17fe3b51f4ad5202a876ea4c92b5d99d4e166823
Author: A Sun 
Date:   Sun, 26 Mar 2017 13:24:18 -0400 

Bug:

RX -EPIPE failure with infinite loop and flooding of
Mar 20 22:24:56 raspberrypi kernel: [ 2851.966506] mceusb 1-1.2:1.0: Error: urb 
status = -32
log message at 8000 messages per second.
Bug trigger appears to be normal, but heavy, IR receiver use.
Driver and Linux host become unusable after error.
Also seen at https://sourceforge.net/p/lirc/mailman/message/34886165/

Fix:

Message reports RX usb halt (stall) condition requiring usb_clear_halt() call 
in non-interrupt context to recover.
Add driver workqueue call to perform this recovery based on method in use for 
the usbnet device driver.

Tested with:

Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l 
GNU/Linux
mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator 
interface version 1
mceusb 1-1.2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors (0x1 active)

Signed-off-by: A Sun 
---
 drivers/media/rc/mceusb.c | 67 ++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 238d8ea..7b6f9e5 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -36,12 +36,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#define DRIVER_VERSION "1.92"
+#define DRIVER_VERSION "1.93"
 #define DRIVER_AUTHOR  "Jarod Wilson "
 #define DRIVER_DESC"Windows Media Center Ed. eHome Infrared Transceiver " \
"device driver"
@@ -417,6 +418,7 @@ struct mceusb_dev {
/* usb */
struct usb_device *usbdev;
struct urb *urb_in;
+   unsigned int pipe_in;
struct usb_endpoint_descriptor *usb_ep_out;
 
/* buffers and dma */
@@ -454,6 +456,12 @@ struct mceusb_dev {
u8 num_rxports; /* number of receive sensors */
u8 txports_cabled;  /* bitmask of transmitters with cable */
u8 rxports_active;  /* bitmask of active receive sensors */
+
+   /* kevent support */
+   struct work_struct kevent;
+   unsigned long kevent_flags;
+#  define EVENT_TX_HALT0
+#  define EVENT_RX_HALT1
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
@@ -1025,6 +1033,23 @@ static void mceusb_process_ir_data(struct mceusb_dev 
*ir, int buf_len)
}
 }
 
+/*
+ * Workqueue task dispatcher
+ * for work that can't be done in interrupt handlers
+ * (mceusb_dev_recv() and mce_async_callback()) nor tasklets.
+ * Invokes mceusb_deferred_kevent() for recovering from
+ * error events specified by the kevent bit field.
+ */
+static void mceusb_defer_kevent(struct mceusb_dev *ir, int kevent)
+{
+   set_bit(kevent, >kevent_flags);
+   if (!schedule_work(>kevent)) {
+   dev_err(ir->dev, "kevent %d may have been dropped", kevent);
+   } else {
+   dev_dbg(ir->dev, "kevent %d scheduled", kevent);
+   }
+}
+
 static void mceusb_dev_recv(struct urb *urb)
 {
struct mceusb_dev *ir;
@@ -1052,6 +1077,11 @@ static void mceusb_dev_recv(struct urb *urb)
return;
 
case -EPIPE:
+   dev_err(ir->dev, "Error: urb status = %d (RX HALT)",
+   urb->status);
+   mceusb_defer_kevent(ir, EVENT_RX_HALT);
+   return;
+
default:
dev_err(ir->dev, "Error: urb status = %d", urb->status);
break;
@@ -1170,6 +1200,37 @@ static void mceusb_flash_led(struct mceusb_dev *ir)
mce_async_out(ir, FLASH_LED, sizeof(FLASH_LED));
 }
 
+/*
+ * Workqueue function
+ * for resetting or recovering device after occurrence of error events
+ * specified in ir->kevent bit field.
+ * Function runs (via schedule_work()) in non-interrupt context, for
+ * calls here (such as usb_clear_halt()) requiring non-interrupt context.
+ */
+static void mceusb_deferred_kevent(struct work_struct *work)
+{
+   struct mceusb_dev *ir =
+   container_of(work, struct mceusb_dev, kevent);
+   int status;
+
+   if (test_bit(EVENT_RX_HALT, >kevent_flags)) {
+   usb_unlink_urb(ir->urb_in);
+   status = usb_clear_halt(ir->usbdev, ir->pipe_in);
+   if (status < 0) {
+   dev_err(ir->dev, "rx clear halt error %d",
+   status);
+   return;
+   }
+   clear_bit(EVENT_RX_HALT, >kevent_flags);
+   status = usb_submit_urb(ir->urb_in, GFP_KERNEL);
+   if (status < 0) {
+   dev_err(ir->dev, "rx unhalt submit urb error %d",
+   status);
+   return;
+   }
+   }
+}
+
 static struct rc_dev

Re: [PATCH v2] staging: media: omap4iss: Replace a bit shift by a use of BIT.

2017-03-26 Thread Mauro Carvalho Chehab

Em Sun, 26 Mar 2017 20:57:02 +0300
Laurent Pinchart  escreveu:

> Hi Arushi,
> 
> Thank you for the patch.
> 
> On Friday 24 Mar 2017 21:31:45 Arushi Singhal wrote:
> > This patch replaces bit shifting on 1 with the BIT(x) macro.
> > This was done with coccinelle:
> > @@
> > constant c;
> > @@
> > 
> > -1 << c
> > +BIT(c)
> > 
> > Signed-off-by: Arushi Singhal   
> 
> Acked-by: Laurent Pinchart 
> 
> Greg, as this is a staging driver, do you want to merge the patch through 
> your 
> tree ?

As this is at staging/media, better to merge via my tree.

Regards,
Mauro

> 
> > ---
> > changes in v2
> >  -Remove unnecessary parenthesis
> > 
> >  drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
> >  drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
> >  drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
> >  drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_csi2.c
> > b/drivers/staging/media/omap4iss/iss_csi2.c index
> > f71d5f2f179f..f6acc541e8a2 100644
> > --- a/drivers/staging/media/omap4iss/iss_csi2.c
> > +++ b/drivers/staging/media/omap4iss/iss_csi2.c
> > @@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device
> > *csi2, const char *subname) snprintf(name, sizeof(name), "CSI2%s",
> > subname);
> > snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
> > 
> > -   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> > +   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
> > v4l2_set_subdevdata(sd, csi2);
> > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
> > b/drivers/staging/media/omap4iss/iss_ipipe.c index
> > d38782e8e84c..d86ef8a031f2 100644
> > --- a/drivers/staging/media/omap4iss/iss_ipipe.c
> > +++ b/drivers/staging/media/omap4iss/iss_ipipe.c
> > @@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device
> > *ipipe) v4l2_subdev_init(sd, _v4l2_ops);
> > sd->internal_ops = _v4l2_internal_ops;
> > strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
> > -   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> > +   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
> > v4l2_set_subdevdata(sd, ipipe);
> > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c
> > b/drivers/staging/media/omap4iss/iss_ipipeif.c index
> > 23de8330731d..cb88b2bd0d82 100644
> > --- a/drivers/staging/media/omap4iss/iss_ipipeif.c
> > +++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
> > @@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct
> > iss_ipipeif_device *ipipeif) v4l2_subdev_init(sd, _v4l2_ops);
> > sd->internal_ops = _v4l2_internal_ops;
> > strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
> > -   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> > +   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
> > v4l2_set_subdevdata(sd, ipipeif);
> > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_resizer.c
> > b/drivers/staging/media/omap4iss/iss_resizer.c index
> > f1d352c711d5..4bbfa20b3c38 100644
> > --- a/drivers/staging/media/omap4iss/iss_resizer.c
> > +++ b/drivers/staging/media/omap4iss/iss_resizer.c
> > @@ -782,7 +782,7 @@ static int resizer_init_entities(struct
> > iss_resizer_device *resizer) v4l2_subdev_init(sd, _v4l2_ops);
> > sd->internal_ops = _v4l2_internal_ops;
> > strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
> > -   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> > +   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
> > v4l2_set_subdevdata(sd, resizer);
> > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;  
> 



Thanks,
Mauro

Re: [PATCH v2] staging: media: omap4iss: Replace a bit shift by a use of BIT.

2017-03-26 Thread Laurent Pinchart

Hi Arushi,

Thank you for the patch.

On Friday 24 Mar 2017 21:31:45 Arushi Singhal wrote:
> This patch replaces bit shifting on 1 with the BIT(x) macro.
> This was done with coccinelle:
> @@
> constant c;
> @@
> 
> -1 << c
> +BIT(c)
> 
> Signed-off-by: Arushi Singhal 

Acked-by: Laurent Pinchart 

Greg, as this is a staging driver, do you want to merge the patch through your 
tree ?

> ---
> changes in v2
>  -Remove unnecessary parenthesis
> 
>  drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
>  drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
>  drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
>  drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_csi2.c
> b/drivers/staging/media/omap4iss/iss_csi2.c index
> f71d5f2f179f..f6acc541e8a2 100644
> --- a/drivers/staging/media/omap4iss/iss_csi2.c
> +++ b/drivers/staging/media/omap4iss/iss_csi2.c
> @@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device
> *csi2, const char *subname) snprintf(name, sizeof(name), "CSI2%s",
> subname);
>   snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
> 
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, csi2);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
> b/drivers/staging/media/omap4iss/iss_ipipe.c index
> d38782e8e84c..d86ef8a031f2 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipe.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipe.c
> @@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device
> *ipipe) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, ipipe);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c
> b/drivers/staging/media/omap4iss/iss_ipipeif.c index
> 23de8330731d..cb88b2bd0d82 100644
> --- a/drivers/staging/media/omap4iss/iss_ipipeif.c
> +++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
> @@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct
> iss_ipipeif_device *ipipeif) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, ipipeif);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 
> diff --git a/drivers/staging/media/omap4iss/iss_resizer.c
> b/drivers/staging/media/omap4iss/iss_resizer.c index
> f1d352c711d5..4bbfa20b3c38 100644
> --- a/drivers/staging/media/omap4iss/iss_resizer.c
> +++ b/drivers/staging/media/omap4iss/iss_resizer.c
> @@ -782,7 +782,7 @@ static int resizer_init_entities(struct
> iss_resizer_device *resizer) v4l2_subdev_init(sd, _v4l2_ops);
>   sd->internal_ops = _v4l2_internal_ops;
>   strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
> - sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
> + sd->grp_id = BIT(16);   /* group ID for iss subdevs */
>   v4l2_set_subdevdata(sd, resizer);
>   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 12/12] [media] ddbridge: support STV0367-based cards and modules

2017-03-26 Thread kbuild test robot

Hi Daniel,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.11-rc3 next-20170324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Scheller/stv0367-ddbridge-support-CTv6-FlexCT-hardware/20170326-235957
base:   git://linuxtv.org/media_tree.git master
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/media/pci/ddbridge/ddbridge-core.c: In function 'dvb_input_detach':
>> drivers/media/pci/ddbridge/ddbridge-core.c:891:3: warning: this 'if' clause 
>> does not guard... [-Wmisleading-indentation]
  if (input->fe2)
  ^~
   drivers/media/pci/ddbridge/ddbridge-core.c:893:4: note: ...this statement, 
but the latter is misleadingly indented as if it is guarded by the 'if'
   input->fe2 = NULL;
   ^

vim +/if +891 drivers/media/pci/ddbridge/ddbridge-core.c

ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
875  }
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
876  
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
877  
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
878  static void dvb_input_detach(struct ddb_input *input)
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
879  {
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
880 struct dvb_adapter *adap = >adap;
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
881 struct dvb_demux *dvbdemux = >demux;
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
882 struct i2c_client *client;
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
883  
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
884 switch (input->attached) {
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
885 case 5:
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
886 client = input->i2c_client[0];
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
887 if (client) {
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
888 module_put(client->dev.driver->owner);
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
889 i2c_unregister_device(client);
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
890 }
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03 
@891 if (input->fe2)
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
892 dvb_unregister_frontend(input->fe2);
9f5af2d9 drivers/media/pci/ddbridge/ddbridge-core.c Daniel Scheller 2017-03-24  
893 input->fe2 = NULL;
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
894 if (input->fe) {
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
895 dvb_unregister_frontend(input->fe);
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
896 dvb_frontend_detach(input->fe);
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
897 input->fe = NULL;
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
898 }
ccad0457 drivers/media/dvb/ddbridge/ddbridge-core.c Ralph Metzler   2011-07-03  
899 case 4:

:: The code at line 891 was first introduced by commit
:: ccad04578fcbe2678084af0986ac010ab84a023d [media] ddbridge: Initial 
check-in

:: TO: Ralph Metzler <rmetz...@digitaldevices.de>
:: CC: Mauro Carvalho Chehab <mche...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-26 Thread Laurent Pinchart

Hi Hans,

On Tuesday 14 Mar 2017 08:55:36 Hans Verkuil wrote:
> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> > 
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> > 
> > Em Mon, 13 Mar 2017 14:46:22 +0200 Sakari Ailus escreveu:
> >> Drivers are written to support hardware, not particular use case.
> > 
> > No, it is just the reverse: drivers and hardware are developed to
> > support use cases.
> > 
> > Btw, you should remember that the hardware is the full board, not just the
> > SoC. In practice, the board do limit the use cases: several provide a
> > single physical CSI connector, allowing just one sensor.
> > 
> >>> This situation is there since 2009. If I remember well, you tried to
> >>> write such generic plugin in the past, but never finished it, apparently
> >>> because it is too complex. Others tried too over the years.
> >> 
> >> I'd argue I know better what happened with that attempt than you do. I
> >> had a prototype of a generic pipeline configuration library but due to
> >> various reasons I haven't been able to continue working on that since
> >> around 2012.
> > ...
> > 
> >>> The last trial was done by Jacek, trying to cover just the exynos4
> >>> driver. Yet, even such limited scope plugin was not good enough, as it
> >>> was never merged upstream. Currently, there's no such plugins upstream.
> >>> 
> >>> If we can't even merge a plugin that solves it for just *one* driver,
> >>> I have no hope that we'll be able to do it for the generic case.
> >> 
> >> I believe Jacek ceased to work on that plugin in his day job; other than
> >> that, there are some matters left to be addressed in his latest patchset.
> > 
> > The two above basically summaries the issue: the task of doing a generic
> > plugin on userspace, even for a single driver is complex enough to
> > not cover within a reasonable timeline.
> > 
> > From 2009 to 2012, you were working on it, but didn't finish it.
> > 
> > Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
> > I didn't check when the generic plugin interface was added to libv4l).
> > 
> > In the case of Jacek's work, the first patch I was able to find was
> > 
> > written in Oct, 2014:
> > https://patchwork.kernel.org/patch/5098111/
> > (not sure what happened with the version 1).
> > 
> > The last e-mail about this subject was issued in Dec, 2016.
> > 
> > In summary, you had this on your task for 3 years for an OMAP3
> > plugin (where you have a good expertise), and Jacek for 2 years,
> > for Exynos 4, where he should also have a good knowledge.
> > 
> > Yet, with all that efforts, no concrete results were achieved, as none
> > of the plugins got merged.
> > 
> > Even if they were merged, if we keep the same mean time to develop a
> > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > years to be developed.
> > 
> > There's a clear message on it:
> > - we shouldn't keep pushing for a solution via libv4l.
> 
> Or:
>   - userspace plugin development had a very a low priority and
> never got the attention it needed.
>
> I know that's *my* reason. I rarely if ever looked at it. I always assumed
> Sakari and/or Laurent would look at it. If this reason is also valid for
> Sakari and Laurent, then it is no wonder nothing has happened in all that
> time.

The reason is also valid for me. I'd really love to work on the userspace 
side, but I just can't find time at the moment.

> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it because of fundamental design defects, or because nobody paid attention
> to it?
> 
> I strongly suspect it is the latter.
> 
> In addition, I suspect end-users of these complex devices don't really care
> about a plugin: they want full control and won't typically use generic
> applications. If they would need support for that, we'd have seen much more
> interest. The main reason for having a plugin is to simplify testing and
> if this is going to be used on cheap hobbyist devkits.
> 
> An additional complication is simply that it is hard to find fully supported
> MC hardware. omap3 boards are hard to find these days, renesas boards are
> not easy to get, freescale isn't the most popular either. Allwinner,
> mediatek, amlogic, broadcom and qualcomm all have closed source
> implementations or no implementation at all.
> 
> I know it took me a very long time before I had a working omap3.
> 
> So I am not at all surprised that little progress has been made.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/3] [media] mceusb: RX -EPIPE lockup fault and more

2017-03-26 Thread A Sun

On 3/26/2017 6:27 AM, Sean Young wrote:
...

>> +status = usb_submit_urb(ir->urb_in, GFP_ATOMIC);
> 
> This can be GFP_KERNEL.
> 
...

>> +rc_free_device(ir->rc);
> 
> That change is wrong and will cause a double free.
> 
>>  usb_kill_urb(ir->urb_in);
>>  usb_free_urb(ir->urb_in);
>>  usb_free_coherent(dev, ir->len_in, ir->buf_in, ir->dma_in);
> 
> Would you be able to split this into multiple commits please?
> 
> Thanks,
> Sean
> 

Hi Sean,

Thank you for the quick reply, review, corrections, and suggestions. Please 
bear with me since this is my first contribution for Linux. The patch 
production submission/review process is entirely new to me at this time.

I'll perform the corrections in the forthcoming replies containing the split 
patches:
[PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix
[PATCH 2/3] [media] mceusb: sporadic RX truncation corruption fix
[PATCH 3/3] [media] mceusb: fix inaccurate debug buffer dumps and 
misleading debug messages

Thanks again. ..A Sun

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

2017-03-26 Thread Frank Schäfer




Am 24.03.2017 um 20:16 schrieb Mauro Carvalho Chehab:

Em Thu, 23 Mar 2017 19:03:20 +0100
Frank Schäfer  escreveu:


Am 23.03.2017 um 13:56 schrieb Mauro Carvalho Chehab:

Em Thu, 23 Mar 2017 13:01:32 +0100
Frank Schäfer  escreveu:
  

Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab:

Em Sun, 19 Feb 2017 19:29:18 +0100
Frank Schäfer  escreveu:
 

Use i2c_smbus_read_word_data() instead of i2c_master_send() and
i2c_master_recv() for reading the ID of Micorn sensors.
Bytes need to be swapped afterwards, because i2c_smbus_read_word_data()
assumes that the received bytes are little-endian byte order (as specified
by smbus), while Micron sensors with 16 bit register width use big endian
byte order.

Signed-off-by: Frank Schäfer 
---
drivers/media/usb/em28xx/em28xx-camera.c | 28 
1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7b4129ab1cf9..4839479624e7 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
{
int ret, i;
char *name;
-   u8 reg;
-   __be16 id_be;
u16 id;

	struct i2c_client *client = >i2c_client[dev->def_i2c_bus];

@@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
dev->em28xx_sensor = EM28XX_NOSENSOR;
for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
client->addr = micron_sensor_addrs[i];
-   /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
/* Read chip ID from register 0x00 */
-   reg = 0x00;
-   ret = i2c_master_send(client, , 1);
+   ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */
if (ret < 0) {
if (ret != -ENXIO)
dev_err(>intf->dev,
@@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
   client->addr << 1, ret);
continue;
}
-   ret = i2c_master_recv(client, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client->addr << 1, ret);
-   continue;
-   }
-   id = be16_to_cpu(id_be);
+   id = swab16(ret); /* LE -> BE */

That's wrong! You can't assume that CPU is BE, as some archs use LE.

You should, instead, call le16_to_cpu(), to be sure that it will be
doing the right thing.

Something like:

id = le16_to_cpu((__le16)ret);

SMBus read/write word transfers are always LE (see SMBus spec section
6.5.5),
which is also what i2c_smbus_xfer_emulated() assumes:
http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485

I got that part, but, if the CPU is also LE, doing swab16() is
wrong. It should swap it *only* if the CPU is BE.

No, it should always be swapped, because the bytes are always transfered
in the wrong order.
The cpu endianess doesn't matter, (0x12 << 8) | 0x34 is always 0x1234.

You still didn't get it.

Let's assume that the ID is 0x148c (MT9M112).

This value, represented in low endian, is stored in memory as:

unsigned char __id[2] = { 0x8c, 0x14 };

If we do:
u16 ret = *(u16 *)__id;

What's stored at "ret" will depend if the sistem is LE or BE:

on LE, ret == 0x148c
on BE, ret == 0x8c14

If you do:
u16 id = swapb16(val)

you'll get:

on LE, id == 0x8c14
on BE, id == 0x148c

So, the value will be *wrong* at LE.

However, if you do:
id = le16_to_cpu((__le16)ret);

On LE, this will evaluate to id = ret, and on BE, to id = swab16(ret).
So, on both, you'll have:
id = 0x148c.


Can you please show me the code line(s) that make the value of the word 
returned by i2c_smbus_read_word_data() cpu endianess dependent ? :)


Cheers,
Frank




Thanks,
Mauro

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

2017-03-26 Thread Daniel Scheller

Am Sun, 26 Mar 2017 10:03:33 +0200
schrieb Matthias Schwarzott :

> Am 24.03.2017 um 19:23 schrieb Daniel Scheller:
> > From: Daniel Scheller 
> > 
> > Some hardware and bridges (namely ddbridge) require that tuner
> > access is limited to one concurrent access and wrap i2c gate
> > control with a mutex_lock when attaching frontends. According to
> > vendor information, this is required as concurrent tuner
> > reconfiguration can interfere each other and at worst cause tuning
> > fails or bad reception quality.
> > 
> > If the demod driver does gate_ctrl before setting up tuner
> > parameters, and the tuner does another I2C enable, it will deadlock
> > forever when gate_ctrl is wrapped into the mutex_lock. This adds a
> > flag and a conditional before triggering gate_ctrl in the
> > demodulator driver. 
> 
> If I get this right, the complete call to i2c_gate_ctrl should be
> disabled. Why not just overwrite the function-pointer i2c_gate_ctrl
> with NULL in the relevant attach function (stv0367ddb_attach) or not
> define it in stv0367ddb_ops?

This will make communication with the TDA18212 tuner chip impossible.
We need to open stv0367's I2C gate, thus need the function. But for the
overall hardware case, concurrent tuner reconfiguration must be avoided
due to the mentioned issues, thus after _attach the bridge driver
remaps the function pointer to wrap i2c_gate_ctrl with a lock to
accomplish this - see [1] and [2]. As the demod AND the tuner driver
both open the I2C gate, this will lead to a dead lock. To not change or
break existing behaviour with other cards and tuner drivers, this
(flag, conditional) appears to be the best option.

Thanks,
Daniel

[1]
https://github.com/herrnst/dddvb-linux-kernel/blob/cfefdc71b25d8c135889971dc5735414d22003cf/drivers/media/pci/ddbridge/ddbridge-core.c#L646
[2]
https://github.com/herrnst/dddvb-linux-kernel/blob/cfefdc71b25d8c135889971dc5735414d22003cf/drivers/media/pci/ddbridge/ddbridge-core.c#L556

Re: [PATCH] mceusb: RX -EPIPE lockup fault and more

2017-03-26 Thread Sean Young

On Sat, Mar 25, 2017 at 12:59:09PM -0400, A Sun wrote:
> commit 
> https://github.com/asunxx/linux/commit/e557c1d737462961f2aadfbfb0836ffa3c778518
> Author: A Sun 
> Date:   Sat Mar 25 02:42:03 2017 -0400
> 
> [PATCH] mceusb RX -EPIPE fault and more
> 
> Patch for mceusb driver tested with
> 
> [8.627769] mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB 
> with mce emulator interface version 1
> [8.627797] mceusb 1-1.2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors 
> (0x1 active)
> 
> running on
> 
> pi@raspberrypi:~ $ uname -a
> Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l 
> GNU/Linux
> pi@raspberrypi:~ $
> 
> This patch is bug fix and debug messages fix (used for troubleshooting) for

Patches should be against media_tree. Also, one change per commit; please
split this into multiple commits.

> 
> Bug:
> 
> RX -EPIPE failure with infinite loop and flooding of
> Mar 20 22:24:56 raspberrypi kernel: [ 2851.966506] mceusb 1-1.2:1.0: Error: 
> urb status = -32
> log message at 8000 messages per second.
> Bug trigger appears to be normal, but heavy, IR receiver use.
> Driver and Linux host become unusable after error.
> Also seen at https://sourceforge.net/p/lirc/mailman/message/34886165/
> 
> Fix:
> 
> Message reports RX usb halt (stall) condition requiring usb_clear_halt() call 
> in non-interrupt context to recover.
> Add driver workqueue call to perform this recovery based on method in use for 
> the usbnet device driver.
> 
> Bug:
> 
> Intermittent RX truncation and loss of IR received data. Results in receive 
> data stream synchronization errors where driver attempts to incorrectly parse 
> IR data as command responses.
> 
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.139898] mceusb 1-1.2:1.0: 
> processed IR data
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.151315] mceusb 1-1.2:1.0: rx data: 
> 00 90 (length=2)
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.151321] mceusb 1-1.2:1.0: Unknown 
> command 0x00 0x90
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.151336] mceusb 1-1.2:1.0: rx data: 
> 98 0a 8d 0a 8e 0a 8e 0a 8e 0a 8e 0a 9a 0a 8e 0a 0b 3a 8e 00 80 41 59 00 00 
> (length=25)
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.151341] mceusb 1-1.2:1.0: Raw IR 
> data, 24 pulse/space samples
> Mar 22 12:01:40 raspberrypi kernel: [ 3969.151348] mceusb 1-1.2:1.0: Storing 
> space with duration 50
> 
> Bug trigger appears to be normal, but heavy, IR receiver use.
> 
> Fix:
> 
> Cause may be receiver with ep_in bulk endpoint incorrectly bound to 
> usb_fill_int_urb() urb for interrupt endpoint.
> In mceusb_dev_probe(), test ep_in endpoint for int versus bulk and use 
> usb_fill_bulk_urb() as appropriate.
> 
> Bug:
> 
> Memory leak on disconnect for rc = rc_allocate_device().
> 
> Fix:
> 
> Add call rc_free_device() to mceusb_dev_disconnect()

rc_unregister_device() will call rc_free_device() for you.

> Bug:
> 
> mceusb_dev_printdata() prints incorrect window of bytes (0 to len) that are 
> of interest and will be processed next.
> 
> Fix:
> 
> Add size of received data argument to mceusb_dev_printdata().
> Revise buffer print window (offset to offset+len).
> Remove static USB_BUFLEN = 32, which is variable depending on device
> (my receiver buffer size is 64 for Pinnacle IR transceiver).
> Revise bound test to prevent reporting data beyond end of read or end of 
> buffer.
> 
> Bug:
> 
> Debug messages; some misleading.
> 
> Fix:
> 
> Drop "\n" use from dev_dbg().
> References to "receive request" should read "send request".
> Various syntax and other corrections.
> 
> Signed-off-by: A Sun 
> 
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index 238d8ea..48e942e 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -36,18 +36,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -#define DRIVER_VERSION   "1.92"
> +#define DRIVER_VERSION   "1.93"
>  #define DRIVER_AUTHOR"Jarod Wilson "
>  #define DRIVER_DESC  "Windows Media Center Ed. eHome Infrared Transceiver " \
>   "device driver"
>  #define DRIVER_NAME  "mceusb"
>  
> -#define USB_BUFLEN   32 /* USB reception buffer length */
>  #define USB_CTRL_MSG_SZ  2  /* Size of usb ctrl msg on gen1 hw */
>  #define MCE_G1_INIT_MSGS 40 /* Init messages on gen1 hw to throw out */
>  
> @@ -417,6 +417,7 @@ struct mceusb_dev {
>   /* usb */
>   struct usb_device *usbdev;
>   struct urb *urb_in;
> + unsigned int pipe_in;
>   struct usb_endpoint_descriptor *usb_ep_out;
>  
>   /* buffers and dma */
> @@ -454,6 +455,12 @@ struct mceusb_dev {
>   u8 num_rxports; /* number of receive sensors */
>   u8 txports_cabled;  /* bitmask of transmitters with cable */
>   u8 rxports_active;  /* bitmask of active receive sensors */
> +
> + /* kevent

[PATCH] BIT_ULL macro change in 3.13

2017-03-26 Thread Sean Young

Signed-off-by: Sean Young 
---
 backports/backports.txt   |  1 +
 backports/v3.12_bit_ull.patch | 70 +++
 2 files changed, 71 insertions(+)
 create mode 100644 backports/v3.12_bit_ull.patch

diff --git a/backports/backports.txt b/backports/backports.txt
index ebd3ce0..35473dc 100644
--- a/backports/backports.txt
+++ b/backports/backports.txt
@@ -78,6 +78,7 @@ add v3.16_void_gpiochip_remove.patch
 
 [3.12.255]
 add v3.12_kfifo_in.patch
+add v3.12_bit_ull.patch
 
 [3.11.255]
 add v3.11_dev_groups.patch
diff --git a/backports/v3.12_bit_ull.patch b/backports/v3.12_bit_ull.patch
new file mode 100644
index 000..e57f478
--- /dev/null
+++ b/backports/v3.12_bit_ull.patch
@@ -0,0 +1,70 @@
+diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
+index 90f66dc..456d59f 100644
+--- a/drivers/media/rc/rc-ir-raw.c
 b/drivers/media/rc/rc-ir-raw.c
+@@ -264,7 +264,7 @@ int ir_raw_gen_manchester(struct ir_raw_event **ev, 
unsigned int max,
+   u64 i;
+   int ret = -ENOBUFS;
+ 
+-  i = BIT_ULL(n - 1);
++  i = 1ULL << (n - 1);
+ 
+   if (timings->leader) {
+   if (!max--)
+diff --git a/include/media/rc-map.h b/include/media/rc-map.h
+index 1a815a5..c16b157 100644
+--- a/include/media/rc-map.h
 b/include/media/rc-map.h
+@@ -65,29 +65,29 @@ enum rc_type {
+ };
+ 
+ #define RC_BIT_NONE   0ULL
+-#define RC_BIT_UNKNOWNBIT_ULL(RC_TYPE_UNKNOWN)
+-#define RC_BIT_OTHER  BIT_ULL(RC_TYPE_OTHER)
+-#define RC_BIT_RC5BIT_ULL(RC_TYPE_RC5)
+-#define RC_BIT_RC5X_20BIT_ULL(RC_TYPE_RC5X_20)
+-#define RC_BIT_RC5_SZ BIT_ULL(RC_TYPE_RC5_SZ)
+-#define RC_BIT_JVCBIT_ULL(RC_TYPE_JVC)
+-#define RC_BIT_SONY12 BIT_ULL(RC_TYPE_SONY12)
+-#define RC_BIT_SONY15 BIT_ULL(RC_TYPE_SONY15)
+-#define RC_BIT_SONY20 BIT_ULL(RC_TYPE_SONY20)
+-#define RC_BIT_NECBIT_ULL(RC_TYPE_NEC)
+-#define RC_BIT_NECX   BIT_ULL(RC_TYPE_NECX)
+-#define RC_BIT_NEC32  BIT_ULL(RC_TYPE_NEC32)
+-#define RC_BIT_SANYO  BIT_ULL(RC_TYPE_SANYO)
+-#define RC_BIT_MCIR2_KBD  BIT_ULL(RC_TYPE_MCIR2_KBD)
+-#define RC_BIT_MCIR2_MSE  BIT_ULL(RC_TYPE_MCIR2_MSE)
+-#define RC_BIT_RC6_0  BIT_ULL(RC_TYPE_RC6_0)
+-#define RC_BIT_RC6_6A_20  BIT_ULL(RC_TYPE_RC6_6A_20)
+-#define RC_BIT_RC6_6A_24  BIT_ULL(RC_TYPE_RC6_6A_24)
+-#define RC_BIT_RC6_6A_32  BIT_ULL(RC_TYPE_RC6_6A_32)
+-#define RC_BIT_RC6_MCEBIT_ULL(RC_TYPE_RC6_MCE)
+-#define RC_BIT_SHARP  BIT_ULL(RC_TYPE_SHARP)
+-#define RC_BIT_XMPBIT_ULL(RC_TYPE_XMP)
+-#define RC_BIT_CECBIT_ULL(RC_TYPE_CEC)
++#define RC_BIT_UNKNOWN(1ULL << RC_TYPE_UNKNOWN)
++#define RC_BIT_OTHER  (1ULL << RC_TYPE_OTHER)
++#define RC_BIT_RC5(1ULL << RC_TYPE_RC5)
++#define RC_BIT_RC5X_20(1ULL << RC_TYPE_RC5X_20)
++#define RC_BIT_RC5_SZ (1ULL << RC_TYPE_RC5_SZ)
++#define RC_BIT_JVC(1ULL << RC_TYPE_JVC)
++#define RC_BIT_SONY12 (1ULL << RC_TYPE_SONY12)
++#define RC_BIT_SONY15 (1ULL << RC_TYPE_SONY15)
++#define RC_BIT_SONY20 (1ULL << RC_TYPE_SONY20)
++#define RC_BIT_NEC(1ULL << RC_TYPE_NEC)
++#define RC_BIT_NECX   (1ULL << RC_TYPE_NECX)
++#define RC_BIT_NEC32  (1ULL << RC_TYPE_NEC32)
++#define RC_BIT_SANYO  (1ULL << RC_TYPE_SANYO)
++#define RC_BIT_MCIR2_KBD  (1ULL << RC_TYPE_MCIR2_KBD)
++#define RC_BIT_MCIR2_MSE  (1ULL << RC_TYPE_MCIR2_MSE)
++#define RC_BIT_RC6_0  (1ULL << RC_TYPE_RC6_0)
++#define RC_BIT_RC6_6A_20  (1ULL << RC_TYPE_RC6_6A_20)
++#define RC_BIT_RC6_6A_24  (1ULL << RC_TYPE_RC6_6A_24)
++#define RC_BIT_RC6_6A_32  (1ULL << RC_TYPE_RC6_6A_32)
++#define RC_BIT_RC6_MCE(1ULL << RC_TYPE_RC6_MCE)
++#define RC_BIT_SHARP  (1ULL << RC_TYPE_SHARP)
++#define RC_BIT_XMP(1ULL << RC_TYPE_XMP)
++#define RC_BIT_CEC(1ULL << RC_TYPE_CEC)
+ 
+ #define RC_BIT_ALL(RC_BIT_UNKNOWN | RC_BIT_OTHER | \
+RC_BIT_RC5 | RC_BIT_RC5X_20 | RC_BIT_RC5_SZ | \
-- 
2.9.3

script to setup pipeline was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-26 Thread Pavel Machek

Hi!

> > I do agree with you that MC places a lot of burden on the user to
> > attain a lot of knowledge of the system's architecture.
> 
> Setting up the pipeline is not the hard part. One could write a
> script to do that. 

Can you try to write that script? I believe it would solve big part of
the problem.

> > And my other point is, I think most people who have a need to work with
> > the media framework on a particular platform will likely already be
> > quite familiar with that platform.
> 
> I disagree. The most popular platform device currently is Raspberry PI.
> 
> I doubt that almost all owners of RPi + camera module know anything
> about MC. They just use Raspberry's official driver with just provides
> the V4L2 interface.
> 
> I have a strong opinion that, for hardware like RPi, just the V4L2
> API is enough for more than 90% of the cases.

Maybe V4L2 API is enough for 90% of the users. But I don't believe
that means that we should provide compatibility. V4L2 API is not good
enough for complex devices, and if we can make RPi people fix
userspace... that's a good thing.

> > The media graph for imx6 is fairly self-explanatory in my opinion.
> > Yes that graph has to be generated, but just with a simple 'media-ctl
> > --print-dot', I don't see how that is difficult for the user.
> 
> Again, IMHO, the problem is not how to setup the pipeline, but, instead,
> the need to forward controls to the subdevices.
> 
> To use a camera, the user needs to set up a set of controls for the
> image to make sense (bright, contrast, focus, etc). If the driver
> doesn't forward those controls to the subdevs, an application like
> "camorama" won't actually work for real, as the user won't be able
> to adjust those parameters via GUI.

I believe this can be fixed in libv4l2.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

2017-03-26 Thread Matthias Schwarzott

Am 24.03.2017 um 19:23 schrieb Daniel Scheller:
> From: Daniel Scheller 
> 
> Some hardware and bridges (namely ddbridge) require that tuner access is
> limited to one concurrent access and wrap i2c gate control with a
> mutex_lock when attaching frontends. According to vendor information, this
> is required as concurrent tuner reconfiguration can interfere each other
> and at worst cause tuning fails or bad reception quality.
> 
> If the demod driver does gate_ctrl before setting up tuner parameters, and
> the tuner does another I2C enable, it will deadlock forever when gate_ctrl
> is wrapped into the mutex_lock. This adds a flag and a conditional before
> triggering gate_ctrl in the demodulator driver.
> 

If I get this right, the complete call to i2c_gate_ctrl should be disabled.
Why not just overwrite the function-pointer i2c_gate_ctrl with NULL in
the relevant attach function (stv0367ddb_attach) or not define it in
stv0367ddb_ops?

That should have exactly the same effect.

Regards
Matthias

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

cron job: media_tree daily build: ERRORS

Re: [PATCH] staging: media: atomisp: compress return logic

Re: [PATCH v7 5/9] media: venus: vdec: add video decoder files

Re: [PATCH v2 12/12] [media] ddbridge: support STV0367-based cards and modules

Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

[PATCH 3/3] [media] mceusb: fix inaccurate debug buffer dumps,and misleading debug messages

[PATCH 2/3] [media] mceusb: sporadic RX truncation corruption fix

[PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

Re: [PATCH v2] staging: media: omap4iss: Replace a bit shift by a use of BIT.

Re: [PATCH v2] staging: media: omap4iss: Replace a bit shift by a use of BIT.

Re: [PATCH v2 12/12] [media] ddbridge: support STV0367-based cards and modules

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

Re: [PATCH 0/3] [media] mceusb: RX -EPIPE lockup fault and more

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

Re: [PATCH] mceusb: RX -EPIPE lockup fault and more

[PATCH] BIT_ULL macro change in 3.13

script to setup pipeline was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

20 matches

Site Navigation

Mail list logo

Footer information