date:20140807

On 08/05/2014 05:18 PM, Frank Schäfer wrote:
 Hi Hans,
 
 Am 05.08.2014 um 09:00 schrieb Hans Verkuil:
 Fix three compiler warnings:

 drivers/media/usb/em28xx/em28xx-input.c: In function 
 ‘em28xx_i2c_ir_handle_key’:
 drivers/media/usb/em28xx/em28xx-input.c:318:1: warning: the frame size of 
 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
   CC [M]  drivers/media/usb/em28xx/em28xx-dvb.o
 drivers/media/usb/em28xx/em28xx-camera.c: In function 
 ‘em28xx_probe_sensor_micron’:
 drivers/media/usb/em28xx/em28xx-camera.c:199:1: warning: the frame size of 
 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
 drivers/media/usb/em28xx/em28xx-camera.c: In function 
 ‘em28xx_probe_sensor_omnivision’:
 drivers/media/usb/em28xx/em28xx-camera.c:304:1: warning: the frame size of 
 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
 Hmmm... I don't get these weird warnings.
 How can I reproduce them ?

I'm using gcc 4.9.1 and I'm compiling the kernel using just a regular make 
command.
In my .config I have CONFIG_FRAME_WARN=1024.

 
 Note: there is no way the code in em28xx_i2c_ir_handle_key() is correct: it's
 using an almost completely uninitialized i2c_client struct with random flags,
 dev and name fields. Can't this turned into a proper i2c_client struct in
 struct em28xx? At least with this patch it's no longer random data.
 Why do you think the client setup is random ?

Well, this is the code:

struct i2c_client client;
 
client.adapter = ir-dev-i2c_adap[dev-def_i2c_bus];
client.addr = ir-i2c_dev_addr;

All other fields of the client struct are undefined, but it is used as is. That
can't be right. With my patch the i2c_client is either that that was used by the
probe, or it is all zero. Which is still better than having random values.

 Which fields do you think are wrong ? AFAICS this patch doesn't change
 any fields.
 
 What's wrong with using local i2c_client variables ?

Nothing, except that they take a lot of stack space which the compiler 
complains about.
The stack in the kernel is limited, so this should be avoided.

 
 Indeed, the way the driver currently tracks i2c clients / subdevices is
 ... let's say improvable.
 But IMHO, we should go the opposite direction and get rid of the
 i2c_clients in the main device struct.
 They are in fact just temporary helpers and dangerous to use with
 devices with multiple i2c clients on the same bus.

Feel free to find another solution, but allocating i2c_client structs on the
stack is not the right solution.

If you are wondering why these warnings are not seen in the daily build: I'm
increasing the CONFIG_FRAME_WARN setting to 2048. I'll actually disable this
for the next daily build. See what happens. I don't think there are many of
these warnings left, a lot have been cleaned up over the years.

Regards,

Hans

 
 Regards,
 Frank
 
 

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com

 diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
 b/drivers/media/usb/em28xx/em28xx-camera.c
 index 6d2ea9a..c8490ba 100644
 --- a/drivers/media/usb/em28xx/em28xx-camera.c
 +++ b/drivers/media/usb/em28xx/em28xx-camera.c
 @@ -110,40 +110,40 @@ static int em28xx_probe_sensor_micron(struct em28xx 
 *dev)
  __be16 id_be;
  u16 id;
  
 -struct i2c_client client = dev-i2c_client[dev-def_i2c_bus];
 +dev-tmp_i2c_client = dev-i2c_client[dev-def_i2c_bus];
  
  dev-em28xx_sensor = EM28XX_NOSENSOR;
  for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
 -client.addr = micron_sensor_addrs[i];
 +dev-tmp_i2c_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, reg, 1);
 +ret = i2c_master_send(dev-tmp_i2c_client, reg, 1);
  if (ret  0) {
  if (ret != -ENXIO)
  em28xx_errdev(couldn't read from i2c device 
 0x%02x: error %i\n,
 -  client.addr  1, ret);
 +  dev-tmp_i2c_client.addr  1, 
 ret);
  continue;
  }
 -ret = i2c_master_recv(client, (u8 *)id_be, 2);
 +ret = i2c_master_recv(dev-tmp_i2c_client, (u8 *)id_be, 2);
  if (ret  0) {
  em28xx_errdev(couldn't read from i2c device 0x%02x: 
 error %i\n,
 -  client.addr  1, ret);
 +  dev-tmp_i2c_client.addr  1, ret);
  continue;
  }
  id = be16_to_cpu(id_be);
  /* Read chip ID from register 0xff */
  reg = 0xff;
 -ret = i2c_master_send(client, reg, 1);
 +ret = i2c_master_send(dev-tmp_i2c_client, reg, 1);
  if (ret  0) {

[PATCHv4] videobuf2: fix lockdep warning

Changes since v3: renamed queue_lock to mmap_lock.

The following lockdep warning has been there ever since commit 
a517cca6b24fc54ac209e44118ec8962051662e3
one year ago:

[  403.117947] ==
[  403.117949] [ INFO: possible circular locking dependency detected ]
[  403.117953] 3.16.0-rc6-test-media #961 Not tainted
[  403.117954] ---
[  403.117956] v4l2-ctl/15377 is trying to acquire lock:
[  403.117959]  (dev-mutex#3){+.+.+.}, at: [a005a6c3] 
vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.117974]
[  403.117974] but task is already holding lock:
[  403.117976]  (mm-mmap_sem){++}, at: [8118291f] 
vm_mmap_pgoff+0x6f/0xc0
[  403.117987]
[  403.117987] which lock already depends on the new lock.
[  403.117987]
[  403.117990]
[  403.117990] the existing dependency chain (in reverse order) is:
[  403.117992]
[  403.117992] - #1 (mm-mmap_sem){++}:
[  403.117997][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[  403.118006][810d8bc3] __lock_acquire+0x4d3/0xd30
[  403.118010][810d9da7] lock_acquire+0xa7/0x160
[  403.118014][8118c9ec] might_fault+0x7c/0xb0
[  403.118018][a0028a25] video_usercopy+0x425/0x610 [videodev]
[  403.118028][a0028c25] video_ioctl2+0x15/0x20 [videodev]
[  403.118034][a0022764] v4l2_ioctl+0x184/0x1a0 [videodev]
[  403.118040][811d77d0] do_vfs_ioctl+0x2f0/0x4f0
[  403.118307][811d7a51] SyS_ioctl+0x81/0xa0
[  403.118311][8199dc69] system_call_fastpath+0x16/0x1b
[  403.118319]
[  403.118319] - #0 (dev-mutex#3){+.+.+.}:
[  403.118324][810d6a96] check_prevs_add+0x746/0x9f0
[  403.118329][810d733c] validate_chain.isra.39+0x5fc/0x9a0
[  403.118333][810d8bc3] __lock_acquire+0x4d3/0xd30
[  403.118336][810d9da7] lock_acquire+0xa7/0x160
[  403.118340][81999664] 
mutex_lock_interruptible_nested+0x64/0x640
[  403.118344][a005a6c3] vb2_fop_mmap+0x33/0x90 
[videobuf2_core]
[  403.118349][a0022122] v4l2_mmap+0x62/0xa0 [videodev]
[  403.118354][81197270] mmap_region+0x3d0/0x5d0
[  403.118359][8119778d] do_mmap_pgoff+0x31d/0x400
[  403.118363][81182940] vm_mmap_pgoff+0x90/0xc0
[  403.118366][81195cef] SyS_mmap_pgoff+0x1df/0x2a0
[  403.118369][810085c2] SyS_mmap+0x22/0x30
[  403.118376][8199dc69] system_call_fastpath+0x16/0x1b
[  403.118381]
[  403.118381] other info that might help us debug this:
[  403.118381]
[  403.118383]  Possible unsafe locking scenario:
[  403.118383]
[  403.118385]CPU0CPU1
[  403.118387]
[  403.118388]   lock(mm-mmap_sem);
[  403.118391]lock(dev-mutex#3);
[  403.118394]lock(mm-mmap_sem);
[  403.118397]   lock(dev-mutex#3);
[  403.118400]
[  403.118400]  *** DEADLOCK ***
[  403.118400]
[  403.118403] 1 lock held by v4l2-ctl/15377:
[  403.118405]  #0:  (mm-mmap_sem){++}, at: [8118291f] 
vm_mmap_pgoff+0x6f/0xc0
[  403.118411]
[  403.118411] stack backtrace:
[  403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 
3.16.0-rc6-test-media #961
[  403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/31/2013
[  403.118420]  82a6c9d0 8800af37fb00 819916a2 
82a6c9d0
[  403.118425]  8800af37fb40 810d5715 8802308e4200 

[  403.118429]  8802308e4a48 8802308e4a48 8802308e4200 
0001
[  403.118433] Call Trace:
[  403.118441]  [819916a2] dump_stack+0x4e/0x7a
[  403.118445]  [810d5715] print_circular_bug+0x1d5/0x2a0
[  403.118449]  [810d6a96] check_prevs_add+0x746/0x9f0
[  403.118455]  [8119c172] ? find_vmap_area+0x42/0x70
[  403.118459]  [810d733c] validate_chain.isra.39+0x5fc/0x9a0
[  403.118463]  [810d8bc3] __lock_acquire+0x4d3/0xd30
[  403.118468]  [810d9da7] lock_acquire+0xa7/0x160
[  403.118472]  [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.118476]  [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.118480]  [81999664] mutex_lock_interruptible_nested+0x64/0x640
[  403.118484]  [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.118488]  [a005a6c3] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.118493]  [810d8055] ? mark_held_locks+0x75/0xa0
[  403.118497]  [a005a6c3] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[  403.118502]  [a0022122] v4l2_mmap+0x62/0xa0 [videodev]
[  403.118506]  [81197270] mmap_region+0x3d0/0x5d0
[  403.118510]  [8119778d] do_mmap_pgoff+0x31d/0x400
[

Re: [PATCH v2 1/1] v4l: Event documentation fixes

On 08/06/2014 08:52 AM, Sakari Ailus wrote:
 Constify event type constants and correct motion detection event number
 (it's 6, not 5).
 
 Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com

Acked-by: Hans Verkuil hans.verk...@cisco.com

 ---
 Thanks for the review, Hans!
 
 Since v1:
 
 - No line breaks between constant and /constant. No other changes.
 
  Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 7 ---
  Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml | 2 +-
  2 files changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
 b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 index cb77325..b036f89 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 @@ -76,21 +76,22 @@
   entry/entry
   entryv4l2-event-vsync;/entry
  entrystructfieldvsync/structfield/entry
 - entryEvent data for event V4L2_EVENT_VSYNC.
 + entryEvent data for event constantV4L2_EVENT_VSYNC/constant.
  /entry
 /row
 row
   entry/entry
   entryv4l2-event-ctrl;/entry
  entrystructfieldctrl/structfield/entry
 - entryEvent data for event V4L2_EVENT_CTRL.
 + entryEvent data for event constantV4L2_EVENT_CTRL/constant.
  /entry
 /row
 row
   entry/entry
   entryv4l2-event-frame-sync;/entry
  entrystructfieldframe_sync/structfield/entry
 - entryEvent data for event V4L2_EVENT_FRAME_SYNC./entry
 + entryEvent data for event
 + constantV4L2_EVENT_FRAME_SYNC/constant./entry
 /row
 row
   entry/entry
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 9f60956..d7c9365 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -176,7 +176,7 @@
 /row
 row
   entryconstantV4L2_EVENT_MOTION_DET/constant/entry
 - entry5/entry
 + entry6/entry
   entry
 paraTriggered whenever the motion detection state for one or 
 more of the regions
 changes. This event has a v4l2-event-motion-det; associated with 
 it./para
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] v4l: Event documentation fixes

On 08/07/2014 08:50 AM, Hans Verkuil wrote:
 On 08/06/2014 08:52 AM, Sakari Ailus wrote:
 Constify event type constants and correct motion detection event number
 (it's 6, not 5).

 Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
 
 Acked-by: Hans Verkuil hans.verk...@cisco.com

Hmm, I did that already. Oh well, you can never have too many acks :-)

 
 ---
 Thanks for the review, Hans!

 Since v1:

 - No line breaks between constant and /constant. No other changes.

  Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 7 ---
  Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml | 2 +-
  2 files changed, 5 insertions(+), 4 deletions(-)

 diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
 b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 index cb77325..b036f89 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 @@ -76,21 +76,22 @@
  entry/entry
  entryv4l2-event-vsync;/entry
  entrystructfieldvsync/structfield/entry
 -entryEvent data for event V4L2_EVENT_VSYNC.
 +entryEvent data for event constantV4L2_EVENT_VSYNC/constant.
  /entry
/row
row
  entry/entry
  entryv4l2-event-ctrl;/entry
  entrystructfieldctrl/structfield/entry
 -entryEvent data for event V4L2_EVENT_CTRL.
 +entryEvent data for event constantV4L2_EVENT_CTRL/constant.
  /entry
/row
row
  entry/entry
  entryv4l2-event-frame-sync;/entry
  entrystructfieldframe_sync/structfield/entry
 -entryEvent data for event V4L2_EVENT_FRAME_SYNC./entry
 +entryEvent data for event
 +constantV4L2_EVENT_FRAME_SYNC/constant./entry
/row
row
  entry/entry
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 9f60956..d7c9365 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -176,7 +176,7 @@
/row
row
  entryconstantV4L2_EVENT_MOTION_DET/constant/entry
 -entry5/entry
 +entry6/entry
  entry
paraTriggered whenever the motion detection state for one or 
 more of the regions
changes. This event has a v4l2-event-motion-det; associated with 
 it./para

 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config and set_voltage for m88ds3103

Moikka!

That patch contains (too) many changes:
1) TS clock config option
2) TS clock polarity config option
3) start_ctrl() callback
4) set_voltage implementation
5) set_voltage() callback

Generally I am fine with 1, 2 and 4.

When you do that many different logical changes for existing driver, you
should split it is one patch per change.

Rest of the comments are between the code.


On 08/06/2014 07:27 AM, nibble.max wrote:
 Add some config parameters and set_voltage function for m88ds3103.
 
 Signed-off-by: Nibble Max nibble@gmail.com
 ---
   drivers/media/dvb-frontends/m88ds3103.c | 91 
 +++--
   drivers/media/dvb-frontends/m88ds3103.h | 37 --
   2 files changed, 96 insertions(+), 32 deletions(-)
 
 diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
 b/drivers/media/dvb-frontends/m88ds3103.c
 index dfe0c2f..df2f89c 100644
 --- a/drivers/media/dvb-frontends/m88ds3103.c
 +++ b/drivers/media/dvb-frontends/m88ds3103.c
 @@ -247,8 +247,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
   u8 u8tmp, u8tmp1, u8tmp2;
   u8 buf[2];
   u16 u16tmp, divide_ratio;
 - u32 tuner_frequency, target_mclk, ts_clk;
 + u32 tuner_frequency, target_mclk;
   s32 s32tmp;
 + fe_status_t status;
   dev_dbg(priv-i2c-dev,
   %s: delivery_system=%d modulation=%d frequency=%d 
 symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
   __func__, c-delivery_system,
 @@ -316,9 +317,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
   target_mclk = 144000;
   break;
   case M88DS3103_TS_PARALLEL:
 - case M88DS3103_TS_PARALLEL_12:
 - case M88DS3103_TS_PARALLEL_16:
 - case M88DS3103_TS_PARALLEL_19_2:
   case M88DS3103_TS_CI:
   if (c-symbol_rate  1800)
   target_mclk = 96000;
 @@ -352,33 +350,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
   switch (priv-cfg-ts_mode) {
   case M88DS3103_TS_SERIAL:
   u8tmp1 = 0x00;
 - ts_clk = 0;
 - u8tmp = 0x46;
 + u8tmp = 0x06;
   break;
   case M88DS3103_TS_SERIAL_D7:
   u8tmp1 = 0x20;
 - ts_clk = 0;
 - u8tmp = 0x46;
 + u8tmp = 0x06;
   break;
   case M88DS3103_TS_PARALLEL:
 - ts_clk = 24000;
 - u8tmp = 0x42;
 - break;
 - case M88DS3103_TS_PARALLEL_12:
 - ts_clk = 12000;
 - u8tmp = 0x42;
 - break;
 - case M88DS3103_TS_PARALLEL_16:
 - ts_clk = 16000;
 - u8tmp = 0x42;
 - break;
 - case M88DS3103_TS_PARALLEL_19_2:
 - ts_clk = 19200;
 - u8tmp = 0x42;
 + u8tmp = 0x02;
   break;
   case M88DS3103_TS_CI:
 - ts_clk = 6000;
 - u8tmp = 0x43;
 + u8tmp = 0x03;
   break;
   default:
   dev_dbg(priv-i2c-dev, %s: invalid ts_mode\n, __func__);
 @@ -386,6 +368,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
   goto err;
   }
   
 + if (priv-cfg-ts_clk_pol)
 + u8tmp |= 0x40;
 +
   /* TS mode */
   ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
   if (ret)
 @@ -399,8 +384,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
   goto err;
   }
   
 - if (ts_clk) {
 - divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
 + if (priv-cfg-ts_clk) {
 + divide_ratio = DIV_ROUND_UP(target_mclk, priv-cfg-ts_clk);
   u8tmp1 = divide_ratio / 2;
   u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
   } else {
 @@ -411,7 +396,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
   
   dev_dbg(priv-i2c-dev,
   %s: target_mclk=%d ts_clk=%d divide_ratio=%d\n,
 - __func__, target_mclk, ts_clk, divide_ratio);
 + __func__, target_mclk, priv-cfg-ts_clk, divide_ratio);
   
   u8tmp1--;
   u8tmp2--;
 @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
   
   priv-delivery_system = c-delivery_system;
   
 + if (priv-cfg-start_ctrl) {
 + for (len = 0; len  30 ; len++) {
 + m88ds3103_read_status(fe, status);
 + if (status  FE_HAS_LOCK) {
 + priv-cfg-start_ctrl(fe);
 + break;
 + }
 + msleep(20);
 + }
 + }
 +

What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
What is wrong with default DVB-core implementation? You should not need
to poll demod lock here and then call streaming control callback from
USB driver. If you implement

Re: [PATCH/RFC v4 00/21] LED / flash API integration

2014-08-07 Thread Jacek Anaszewski


Hi Sakari,

On 08/06/2014 08:53 AM, Sakari Ailus wrote:

Hi Jacek,

On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote:
...

1) Who should register V4L2 Flash sub-device?

LED Flash Class devices, after introduction of the Flash Manager,
are not tightly coupled with any media controller. They are maintained
by the Flash Manager and made available for dynamic assignment to
any media system they are connected to through multiplexing devices.

In the proposed rough solution, when support for V4L2 Flash sub-devices
is enabled, there is a v4l2_device created for them to register in.
This however implies that V4L2 Flash device will not be available
in any media controller, which calls its existence into question.

Therefore I'd like to consult possible ways of solving this issue.
The option I see is implementing a mechanism for moving V4L2 Flash
sub-devices between media controllers. A V4L2 Flash sub-device
would initially be assigned to one media system in the relevant
device tree binding, but it could be dynamically reassigned to
the other one. However I'm not sure if media controller design
is prepared for dynamic modifications of its graph and how many
modifications in the existing drivers this solution would require.


Do you have a use case where you would need to strobe a flash from multiple
media devices at different times, or is this entirely theoretical? Typically
flash controllers are connected to a single source of hardware strobe (if
there's one) since the flash LEDs are in fact mounted next to a specific
camera sensor.


I took into account such arrangements in response to your message [1], 
where you were considering configurations like one flash but two
cameras, one camera and two flashes. And you also called for 
proposing generic solution.


One flash and two (or more) cameras case is easily conceivable -
You even mentioned stereo cameras. One camera and many flashes
arrangement might be useful in case of some professional devices which
might be designed so that they would be able to apply different scene
lighting. I haven't heard about such devices, but as you said
such a configuration isn't unthinkable.


If this is a real issue the way to solve it would be to have a single media
device instead of many.


I was considering adding media device, that would be a representation
of a flash manager, gathering all the registered flashes. Nonetheless,
finally I came to conclusion that a v4l2-device alone should suffice,
just to provide a Flash Manager representation allowing for v4l2-flash 
sub-devices to register in.

All the features provided by the media device are useless in case
of a set of V4L2 Flash sub-devices. They couldn't have any linkage
in such a device. The only benefit from having media device gathering
V4L2 Flash devices would be possibility of listing them.


2) Consequences of locking the Flash Manager during flash strobe

In case a LED Flash Class device depends on muxes involved in
routing the other LED Flash Class device's strobe signals,
the Flash Manager must be locked for the time of strobing
to prevent reconfiguration of the strobe signal routing
by the other device.


I wouldn't be concerned of this in particular. It's more important we do
actully have V4L2 flash API supported by LED flash drivers and that they do
implement the API correctly.

It's at least debatable whether you should try to prevent user space from
doing silly things or not. With complex devices it may relatively easily
lead to wrecking havoc with actual use cases which we certainly do not want.

In this case, if you just prevent changing the routing (do you have a use
case for it?) while strobing, someone else could still change the routing
just before you strobe.


Originally I started to implementing this so that strobe signal routing
was altered upon setting strobe source. With such an implementation the 
use case would be as follows:


1. Process 1 sets strobe source to external
2. Process 2 sets strobe source to software
3. Process 1 strobes the flash, unaware that strobe source setting has
   been changed

To avoid such problems I changed the implementation so that the
routing is set in the led_flash_manager_setup_strobe function called
from led_set_flash_strobe and led_set_external_strobe functions.
led_flash_manager_setup_strobe sets strobe signal routing
and strobes the flash under lock and holds it for the flash timeout
period, which prevents spurious reconfiguration.

Nonetheless, I agree that trying to handle this problem is troublesome,
and would affect current V4L2 Flash SPI semantics. If you don't share
my concerns I am happy to leave this locking solution out :)

Best Regards,
Jacek Anaszewski

[1] http://www.spinics.net/lists/linux-leds/msg01617.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v4 00/21] LED / flash API integration

2014-08-07 Thread Jacek Anaszewski


On 08/07/2014 10:21 AM, Jacek Anaszewski wrote:

Hi Sakari,

On 08/06/2014 08:53 AM, Sakari Ailus wrote:

Hi Jacek,

On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote:
...

1) Who should register V4L2 Flash sub-device?

LED Flash Class devices, after introduction of the Flash Manager,
are not tightly coupled with any media controller. They are maintained
by the Flash Manager and made available for dynamic assignment to
any media system they are connected to through multiplexing devices.

In the proposed rough solution, when support for V4L2 Flash sub-devices
is enabled, there is a v4l2_device created for them to register in.
This however implies that V4L2 Flash device will not be available
in any media controller, which calls its existence into question.

Therefore I'd like to consult possible ways of solving this issue.
The option I see is implementing a mechanism for moving V4L2 Flash
sub-devices between media controllers. A V4L2 Flash sub-device
would initially be assigned to one media system in the relevant
device tree binding, but it could be dynamically reassigned to
the other one. However I'm not sure if media controller design
is prepared for dynamic modifications of its graph and how many
modifications in the existing drivers this solution would require.


Do you have a use case where you would need to strobe a flash from
multiple
media devices at different times, or is this entirely theoretical?
Typically
flash controllers are connected to a single source of hardware strobe (if
there's one) since the flash LEDs are in fact mounted next to a specific
camera sensor.


I took into account such arrangements in response to your message [1],
where you were considering configurations like one flash but two
cameras, one camera and two flashes. And you also called for
proposing generic solution.

One flash and two (or more) cameras case is easily conceivable -
You even mentioned stereo cameras. One camera and many flashes
arrangement might be useful in case of some professional devices which
might be designed so that they would be able to apply different scene
lighting. I haven't heard about such devices, but as you said
such a configuration isn't unthinkable.


If this is a real issue the way to solve it would be to have a single
media
device instead of many.


I was considering adding media device, that would be a representation
of a flash manager, gathering all the registered flashes. Nonetheless,
finally I came to conclusion that a v4l2-device alone should suffice,
just to provide a Flash Manager representation allowing for v4l2-flash
sub-devices to register in.
All the features provided by the media device are useless in case
of a set of V4L2 Flash sub-devices. They couldn't have any linkage
in such a device. The only benefit from having media device gathering
V4L2 Flash devices would be possibility of listing them.


2) Consequences of locking the Flash Manager during flash strobe

In case a LED Flash Class device depends on muxes involved in
routing the other LED Flash Class device's strobe signals,
the Flash Manager must be locked for the time of strobing
to prevent reconfiguration of the strobe signal routing
by the other device.


I wouldn't be concerned of this in particular. It's more important we do
actully have V4L2 flash API supported by LED flash drivers and that
they do
implement the API correctly.

It's at least debatable whether you should try to prevent user space from
doing silly things or not. With complex devices it may relatively easily
lead to wrecking havoc with actual use cases which we certainly do not
want.

In this case, if you just prevent changing the routing (do you have a use
case for it?) while strobing, someone else could still change the routing
just before you strobe.


Originally I started to implementing this so that strobe signal routing
was altered upon setting strobe source. With such an implementation the
use case would be as follows:

1. Process 1 sets strobe source to external
2. Process 2 sets strobe source to software
3. Process 1 strobes the flash, unaware that strobe source setting has
been changed


It is of course too generic use case. The more specific one could
be the situation when there are many users in the system that
want to take the picture in the same time. It is not valid in
case of mobile devices though.


To avoid such problems I changed the implementation so that the
routing is set in the led_flash_manager_setup_strobe function called
from led_set_flash_strobe and led_set_external_strobe functions.
led_flash_manager_setup_strobe sets strobe signal routing
and strobes the flash under lock and holds it for the flash timeout
period, which prevents spurious reconfiguration.

Nonetheless, I agree that trying to handle this problem is troublesome,
and would affect current V4L2 Flash SPI semantics. If you don't share
my concerns I am happy to leave this locking solution out :)

Best Regards,
Jacek Anaszewski

[1]

Re: Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config andset_voltage for m88ds3103

Moikka!
Thanks for your review.
Moikka!

That patch contains (too) many changes:
1) TS clock config option
2) TS clock polarity config option
3) start_ctrl() callback
4) set_voltage implementation
5) set_voltage() callback

Generally I am fine with 1, 2 and 4.

When you do that many different logical changes for existing driver, you
should split it is one patch per change.

Rest of the comments are between the code.


On 08/06/2014 07:27 AM, nibble.max wrote:
 Add some config parameters and set_voltage function for m88ds3103.
 
 Signed-off-by: Nibble Max nibble@gmail.com
 ---
   drivers/media/dvb-frontends/m88ds3103.c | 91 
 +++--
   drivers/media/dvb-frontends/m88ds3103.h | 37 --
   2 files changed, 96 insertions(+), 32 deletions(-)
 
 diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
 b/drivers/media/dvb-frontends/m88ds3103.c
 index dfe0c2f..df2f89c 100644
 --- a/drivers/media/dvb-frontends/m88ds3103.c
 +++ b/drivers/media/dvb-frontends/m88ds3103.c
 @@ -247,8 +247,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
  u8 u8tmp, u8tmp1, u8tmp2;
  u8 buf[2];
  u16 u16tmp, divide_ratio;
 -u32 tuner_frequency, target_mclk, ts_clk;
 +u32 tuner_frequency, target_mclk;
  s32 s32tmp;
 +fe_status_t status;
  dev_dbg(priv-i2c-dev,
  %s: delivery_system=%d modulation=%d frequency=%d 
 symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
  __func__, c-delivery_system,
 @@ -316,9 +317,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
  target_mclk = 144000;
  break;
  case M88DS3103_TS_PARALLEL:
 -case M88DS3103_TS_PARALLEL_12:
 -case M88DS3103_TS_PARALLEL_16:
 -case M88DS3103_TS_PARALLEL_19_2:
  case M88DS3103_TS_CI:
  if (c-symbol_rate  1800)
  target_mclk = 96000;
 @@ -352,33 +350,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
  switch (priv-cfg-ts_mode) {
  case M88DS3103_TS_SERIAL:
  u8tmp1 = 0x00;
 -ts_clk = 0;
 -u8tmp = 0x46;
 +u8tmp = 0x06;
  break;
  case M88DS3103_TS_SERIAL_D7:
  u8tmp1 = 0x20;
 -ts_clk = 0;
 -u8tmp = 0x46;
 +u8tmp = 0x06;
  break;
  case M88DS3103_TS_PARALLEL:
 -ts_clk = 24000;
 -u8tmp = 0x42;
 -break;
 -case M88DS3103_TS_PARALLEL_12:
 -ts_clk = 12000;
 -u8tmp = 0x42;
 -break;
 -case M88DS3103_TS_PARALLEL_16:
 -ts_clk = 16000;
 -u8tmp = 0x42;
 -break;
 -case M88DS3103_TS_PARALLEL_19_2:
 -ts_clk = 19200;
 -u8tmp = 0x42;
 +u8tmp = 0x02;
  break;
  case M88DS3103_TS_CI:
 -ts_clk = 6000;
 -u8tmp = 0x43;
 +u8tmp = 0x03;
  break;
  default:
  dev_dbg(priv-i2c-dev, %s: invalid ts_mode\n, __func__);
 @@ -386,6 +368,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
  goto err;
  }
   
 +if (priv-cfg-ts_clk_pol)
 +u8tmp |= 0x40;
 +
  /* TS mode */
  ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
  if (ret)
 @@ -399,8 +384,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
  goto err;
  }
   
 -if (ts_clk) {
 -divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
 +if (priv-cfg-ts_clk) {
 +divide_ratio = DIV_ROUND_UP(target_mclk, priv-cfg-ts_clk);
  u8tmp1 = divide_ratio / 2;
  u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
  } else {
 @@ -411,7 +396,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
   
  dev_dbg(priv-i2c-dev,
  %s: target_mclk=%d ts_clk=%d divide_ratio=%d\n,
 -__func__, target_mclk, ts_clk, divide_ratio);
 +__func__, target_mclk, priv-cfg-ts_clk, divide_ratio);
   
  u8tmp1--;
  u8tmp2--;
 @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)
   
  priv-delivery_system = c-delivery_system;
   
 +if (priv-cfg-start_ctrl) {
 +for (len = 0; len  30 ; len++) {
 +m88ds3103_read_status(fe, status);
 +if (status  FE_HAS_LOCK) {
 +priv-cfg-start_ctrl(fe);
 +break;
 +}
 +msleep(20);
 +}
 +}
 +

What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
What is wrong with default DVB-core implementation? You should not need
to poll demod lock here and then call streaming control callback from
USB driver. If you implement .streaming_ctrl() callback to DVB USB
driver, it

Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config andset_voltage for m88ds3103

Moikka!

On 08/07/2014 12:31 PM, nibble.max wrote:
 @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)

 priv-delivery_system = c-delivery_system;

 +   if (priv-cfg-start_ctrl) {
 +   for (len = 0; len  30 ; len++) {
 +   m88ds3103_read_status(fe, status);
 +   if (status  FE_HAS_LOCK) {
 +   priv-cfg-start_ctrl(fe);
 +   break;
 +   }
 +   msleep(20);
 +   }
 +   }
 +

 What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
 What is wrong with default DVB-core implementation? You should not need
 to poll demod lock here and then call streaming control callback from
 USB driver. If you implement .streaming_ctrl() callback to DVB USB
 driver, it is called automatically for you.
 It is nothing with streaming_ctrl of DVB USB driver.
 It relates with the hardware chip problem.
 The m88ds3103 will not output ts clock when it powers up at the first time.
 It starts to output ts clock as soon as it locks the signal.
 But the slave fifo of Cypress usb chip really need this clock to work.
 If there is no this clock, the salve fifo will stop.
 start_ctrl logic is used to restart the salve fifo when the ts clock is valid.

OK. Then we have to find out some solution... Is there anyone who has a
nice idea how to signal USB interface driver when demod gains a lock?
Sure USB driver could poll read_status() too, but it does not sound good
solution neither.

How about overriding FE .read_status() callback. It is called all the
time by DVB-core when frontend is open. Hook .read_status() to USB
interface driver, then call original .read_status() (implemented by
m88ds3103 driver), and after each call check if status is LOCKED or NOT
LOCKED. When status changes from NOT LOCKED to LOCKED call that board
specific routine which restarts TS FIFO. No change for demod driver
needed at all.

regards
Antto

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

Casino

2014-08-07 Thread Herbert Meadows

Casino International
http://michelle-cash-money.com

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v4 06/21] leds: add API for setting torch brightness

2014-08-07 Thread Jacek Anaszewski


Hi Sakari,

On 08/04/2014 02:50 PM, Sakari Ailus wrote:

Hi Jacek,

Thank you for your continued efforts on this!

On Mon, Aug 04, 2014 at 02:35:26PM +0200, Jacek Anaszewski wrote:

On 07/16/2014 11:54 PM, Sakari Ailus wrote:

Hi Jacek,

Jacek Anaszewski wrote:
...

diff --git a/include/linux/leds.h b/include/linux/leds.h
index 1a130cc..9bea9e6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -44,11 +44,21 @@ struct led_classdev {
  #define LED_BLINK_ONESHOT_STOP(1  18)
  #define LED_BLINK_INVERT(1  19)
  #define LED_SYSFS_LOCK(1  20)
+#define LED_DEV_CAP_TORCH(1  21)

  /* Set LED brightness level */
  /* Must not sleep, use a workqueue if needed */
  void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+/*
+ * Set LED brightness immediately - it is required for flash led
+ * devices as they require setting torch brightness to have
immediate
+ * effect. brightness_set op cannot be used for this purpose because
+ * the led drivers schedule a work queue task in it to allow for
+ * being called from led-triggers, i.e. from the timer irq context.
+ */


Do we need to classify actual devices based on this? I think it's rather
a different API behaviour between the LED and the V4L2 APIs.

On devices that are slow to control, the behaviour should be asynchronous
over the LED API and synchronous when accessed through the V4L2 API. How
about implementing the work queue, as I have suggested, in the
framework, so
that individual drivers don't need to care about this and just implement
the
synchronous variant of this op? A flag could be added to distinguish
devices
that are fast so that the work queue isn't needed.

It'd be nice to avoid individual drivers having to implement multiple
ops to
do the same thing, just for differing user space interfacs.



It is not only the matter of a device controller speed. If a flash
device is to be made accessible from the LED subsystem, then it
should be also compatible with led-triggers. Some of led-triggers
call brightness_set op from the timer irq context and thus no
locking in the callback can occur. This requirement cannot be
met i.e. if i2c bus is to be used. This is probably the primary
reason for scheduling work queue tasks in brightness_set op.

Having the above in mind, setting a brightness in a work queue
task must be possible for all LED Class Flash drivers, regardless
whether related devices have fast or slow controller.

Let's recap the cost of possible solutions then:

1) Moving the work queues to the LED framework

   - it would probably require extending led_set_brightness and
 __led_set_brightness functions by a parameter indicating whether it
 should call brightness_set op in the work queue task or directly;
   - all existing triggers would have to be updated accordingly;
   - work queues would have to be removed from all the LED drivers;

2) adding led_set_torch_brightness API

   - no modifications in existing drivers and triggers would be required
   - instead, only the modifications from the discussed patch would
 be required

Solution 1 looks cleaner but requires much more modifications.


How about a combination of the two, i.e. option 1 with the old op remaining
there for compatibility with the old drivers (with a comment telling it's
deprecated)?

This way new drivers will benefit from having to implement this just once,
and modifications to the existing drivers could be left for later.


It's OK for me, but the opinion from the LED side guys is needed here
as well.


The downside is that any old drivers wouldn't get V4L2 flash API but that's
entirely acceptable in my opinion since these would hardly be needed in use
cases that would benefit from V4L2 flash API.


In the version 4 of the patch set I changed the implementation, so that
a flash led driver must call led_classdev_flash_register to get
registered as a LED Flash Class device and v4l2_flash_init to get
V4L2 Flash API. In effect old drivers will have no chance to get V4L2
Flash API either way.

Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config andset_voltagefor m88ds3103


Moikka!

On 08/07/2014 12:31 PM, nibble.max wrote:
 @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)

priv-delivery_system = c-delivery_system;

 +  if (priv-cfg-start_ctrl) {
 +  for (len = 0; len  30 ; len++) {
 +  m88ds3103_read_status(fe, status);
 +  if (status  FE_HAS_LOCK) {
 +  priv-cfg-start_ctrl(fe);
 +  break;
 +  }
 +  msleep(20);
 +  }
 +  }
 +

 What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
 What is wrong with default DVB-core implementation? You should not need
 to poll demod lock here and then call streaming control callback from
 USB driver. If you implement .streaming_ctrl() callback to DVB USB
 driver, it is called automatically for you.
 It is nothing with streaming_ctrl of DVB USB driver.
 It relates with the hardware chip problem.
 The m88ds3103 will not output ts clock when it powers up at the first time.
 It starts to output ts clock as soon as it locks the signal.
 But the slave fifo of Cypress usb chip really need this clock to work.
 If there is no this clock, the salve fifo will stop.
 start_ctrl logic is used to restart the salve fifo when the ts clock is 
 valid.

OK. Then we have to find out some solution... Is there anyone who has a
nice idea how to signal USB interface driver when demod gains a lock?
Sure USB driver could poll read_status() too, but it does not sound good
solution neither.

How about overriding FE .read_status() callback. It is called all the
time by DVB-core when frontend is open. Hook .read_status() to USB
interface driver, then call original .read_status() (implemented by
m88ds3103 driver), and after each call check if status is LOCKED or NOT
LOCKED. When status changes from NOT LOCKED to LOCKED call that board
specific routine which restarts TS FIFO. No change for demod driver
needed at all.

It sounds a good idea.
Try to remove start_ctrl() and set_voltage() callback from demod driver
and send the patch for m88ds3103 later.
regards
Antto

-- 
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] au0828-input: Be sure that IR is enabled at polling

When the DVB code sets the frontend, it disables the IR
INT, probably due to some hardware bug, as there's no code
there at au8522 frontend that writes on register 0xe0.

Fixing it at au8522 code is hard, as it doesn't know if the
IR is enabled or disabled, and just restoring the value of
register 0xe0 could cause other nasty effects. So, better
to add a hack at au0828-input polling interval to enable int,
if disabled.

Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
 drivers/media/usb/au0828/au0828-input.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index 94d29c2a6fcf..b4475706dfd2 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 reg, 
int val,
 static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 value)
 {
int rc;
-   char buf;
+   char buf, oldbuf;
 
rc = au8522_rc_read(ir, reg, -1, buf, 1);
if (rc  0)
return rc;
 
+   oldbuf = buf;
buf = (buf  ~mask) | (value  mask);
 
+   /* Nothing to do, just return */
+   if (buf == oldbuf)
+   return 0;
+
return au8522_rc_write(ir, reg, buf);
 }
 
@@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
 
/* Check IR int */
rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
-   if (rc  0 || !(buf[0]  (1  4)))
+   if (rc  0 || !(buf[0]  (1  4))) {
+   /* Be sure that IR is enabled */
+   au8522_rc_set(ir, 0xe0, 1  4);
return 0;
+   }
 
/* Something arrived. Get the data */
rc = au8522_rc_read(ir, 0xe3, 0x11, buf, sizeof(buf));
-- 
1.9.3

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] au0828-input: Be sure that IR is enabled at polling

2014-08-07 Thread Devin Heitmueller

On Thu, Aug 7, 2014 at 9:46 AM, Mauro Carvalho Chehab
m.che...@samsung.com wrote:
 When the DVB code sets the frontend, it disables the IR
 INT, probably due to some hardware bug, as there's no code
 there at au8522 frontend that writes on register 0xe0.

 Fixing it at au8522 code is hard, as it doesn't know if the
 IR is enabled or disabled, and just restoring the value of
 register 0xe0 could cause other nasty effects. So, better
 to add a hack at au0828-input polling interval to enable int,
 if disabled.

 Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
 ---
  drivers/media/usb/au0828/au0828-input.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/usb/au0828/au0828-input.c 
 b/drivers/media/usb/au0828/au0828-input.c
 index 94d29c2a6fcf..b4475706dfd2 100644
 --- a/drivers/media/usb/au0828/au0828-input.c
 +++ b/drivers/media/usb/au0828/au0828-input.c
 @@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 reg, 
 int val,
  static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 value)
  {
 int rc;
 -   char buf;
 +   char buf, oldbuf;

 rc = au8522_rc_read(ir, reg, -1, buf, 1);
 if (rc  0)
 return rc;

 +   oldbuf = buf;
 buf = (buf  ~mask) | (value  mask);

 +   /* Nothing to do, just return */
 +   if (buf == oldbuf)
 +   return 0;
 +
 return au8522_rc_write(ir, reg, buf);
  }

 @@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)

 /* Check IR int */
 rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
 -   if (rc  0 || !(buf[0]  (1  4)))
 +   if (rc  0 || !(buf[0]  (1  4))) {
 +   /* Be sure that IR is enabled */
 +   au8522_rc_set(ir, 0xe0, 1  4);

Shouldn't this be a call to au8522_rc_andor()  rather than au8522_rc_set()?

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] au0828-input: Be sure that IR is enabled at polling

Em Thu, 07 Aug 2014 10:00:31 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 On Thu, Aug 7, 2014 at 9:46 AM, Mauro Carvalho Chehab
 m.che...@samsung.com wrote:
  When the DVB code sets the frontend, it disables the IR
  INT, probably due to some hardware bug, as there's no code
  there at au8522 frontend that writes on register 0xe0.
 
  Fixing it at au8522 code is hard, as it doesn't know if the
  IR is enabled or disabled, and just restoring the value of
  register 0xe0 could cause other nasty effects. So, better
  to add a hack at au0828-input polling interval to enable int,
  if disabled.
 
  Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
  ---
   drivers/media/usb/au0828/au0828-input.c | 12 ++--
   1 file changed, 10 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/media/usb/au0828/au0828-input.c 
  b/drivers/media/usb/au0828/au0828-input.c
  index 94d29c2a6fcf..b4475706dfd2 100644
  --- a/drivers/media/usb/au0828/au0828-input.c
  +++ b/drivers/media/usb/au0828/au0828-input.c
  @@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 
  reg, int val,
   static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 
  value)
   {
  int rc;
  -   char buf;
  +   char buf, oldbuf;
 
  rc = au8522_rc_read(ir, reg, -1, buf, 1);
  if (rc  0)
  return rc;
 
  +   oldbuf = buf;
  buf = (buf  ~mask) | (value  mask);
 
  +   /* Nothing to do, just return */
  +   if (buf == oldbuf)
  +   return 0;
  +
  return au8522_rc_write(ir, reg, buf);
   }
 
  @@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
 
  /* Check IR int */
  rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
  -   if (rc  0 || !(buf[0]  (1  4)))
  +   if (rc  0 || !(buf[0]  (1  4))) {
  +   /* Be sure that IR is enabled */
  +   au8522_rc_set(ir, 0xe0, 1  4);
 
 Shouldn't this be a call to au8522_rc_andor()  rather than au8522_rc_set()?

Well, au8522_rc_set is defined as:

#define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), (bit), 
(bit))

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] au0828-input: Be sure that IR is enabled at polling

2014-08-07 Thread Devin Heitmueller

 Well, au8522_rc_set is defined as:

 #define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), (bit), 
 (bit))

Ah, ok.  It's just a really poorly named macro.  Nevermind then.

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

Multiple devices with same SMBus address

2014-08-07 Thread Jean-Michel Hautbois

Hi,

I have a custom board which has two LMH0303 SDI drivers on the same
i2c bus. They are connected in some daisy chain form, like on the
schematics in the datasheet on page 9 :
http://www.ti.com/lit/ds/symlink/lmh0303.pdf

My problem is how to declare these devices in the DT in order to set
the new adress of the first one when probed.

I thought that something like that could do the trick but it seems crappy :

lmh0303@17 {
new-addr = 0x16;
rsti_n = gpio1_17; /* GPIO signal connected to the RSTI signal
of the first LMH0303 */
};
lmh0303@17 {
/* Nothing to do right now */
};

This is a draft thought :).

Maybe would it also be possible do define a super device like this :
lmh0303@17 {
lmh0303_1 {
new-addr = 0x16;
rsti_n = gpio1_17; /* GPIO signal connected to the RSTI
signal of the first LMH0303 */
};
lmh0303_2 {
};
};

This would be something like the gpio-leds binding...
But there is probably already a nice way to do that :-) ?

Thanks for your advices !
JM
--
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] au0828-input: Be sure that IR is enabled at polling

Em Thu, 07 Aug 2014 10:14:45 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

  Well, au8522_rc_set is defined as:
 
  #define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), 
  (bit), (bit))
 
 Ah, ok.  It's just a really poorly named macro.  Nevermind then.

Yep. calling it au8522_rc_setbits would likely be better. I tried to
stick with the same name convention as this macro:

drivers/media/usb/au0828/au0828.h:#define au0828_set(dev, reg, bit) 
au0828_andor(dev, (reg), (bit), (bit))

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: omap3isp device tree support

2014-08-07 Thread Alaganraj Sandhanam

Hi Sakari,

Thanks for the patches. I'll try this...

ThanksRegards,
Alagan

On Thu, Aug 7, 2014 at 5:48 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Alaganraj,

On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote:
Hi Laurent,

Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
omap3isp/dt branch?
I took 3 patches from this branch, fixed
error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
by changing to of_graph_get_next_endpoint.

while booting i'm getting below msg
[1.558471] of_graph_get_next_endpoint(): no port node found in
/ocp/omap3_isp@480bc000
[1.567169] omap3isp 480bc000.omap3_isp: no port node at
/ocp/omap3_isp@480bc000

omap3isp/dt is not working branch?

My patches, while experimental, may be helpful for you. Perhaps. At the
moment the issue is IOMMU; Hiroshi Doyu had some patches to get that
attached to the ISP but for various reasons they didn't make it to the
mainline kernel.

You can find my patches here:

URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt

PLEASE do no clone the entire tree, but add that as a remote to an existing
tree. The patches are on top of the linux-omap master branch.

I think I've gotten through to sensor sub-device registration with these and
the smiapp driver. I'll try to send some of the omap3isp and possibly also
smiapp patches for review soon. It's unlikely to be a complete set, though.

--
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: 3.15.6 USB issue with pwc cam

2014-08-07 Thread Udo van den Heuvel

On 2014-08-04 11:17, Laurent Pinchart wrote:
 (CC'ing Hans de Goede, the pwc maintainer, and the linux-media mailing list)
 
 On Saturday 02 August 2014 15:10:01 Udo van den Heuvel wrote:
 Hello,

 I moved a PWC webcam to a USB3 port, and this happened:

I get similar stuff when trying to use a Logitech C615 cam.
See attachment for full dmesg of errors but excerpt below:

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command
completion code 0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at
drivers/media/v4l2-core/videobuf2-core.c:2011
__vb2_queue_cancel+0x102/0x170 [videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE
xt_tcpudp nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables
ip6table_filter ip6_tables x_tables eeprom it87 hwmon_vid ext2
snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi ppdev pwc
videobuf2_vmalloc videobuf2_memops kvm_amd kvm v4l2_common
videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq
snd_seq_device microcode snd_pcm parport_serial parport_pc parport
snd_timer k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd
auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic
usbhid ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon
bitblit cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit
xhci_hcd backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm: skype Tainted: GW
3.15.8 #6
[80346.835254] Hardware name: Gigabyte Technology Co., Ltd. To be filled
by O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013
[80346.835257]   79d580f4 814f2373

[80346.835262]  81069fe1  88040ec532e8

[80346.835267]  88040ec530d8 8803f0c46f00 a041d832
88040ec530d8
[80346.835272] Call Trace:
[80346.835283]  [814f2373] ? dump_stack+0x4a/0x75
[80346.835289]  [81069fe1] ? warn_slowpath_common+0x81/0xb0
[80346.835299]  [a041d832] ? __vb2_queue_cancel+0x102/0x170
[videobuf2_core]
[80346.835307]  [a041f53d] ? vb2_internal_streamoff+0x1d/0x50
[videobuf2_core]
[80346.835314]  [a06140d5] ? uvc_queue_enable+0x75/0xb0 [uvcvideo]
[80346.835321]  [a0619091] ? uvc_video_enable+0x141/0x1a0
[uvcvideo]
[80346.835327]  [a0615e1f] ? uvc_v4l2_do_ioctl+0xd6f/0x1580
[uvcvideo]
[80346.835339]  [a0448bc0] ? video_usercopy+0x1f0/0x490 [videodev]
[80346.835345]  [a06150b0] ?
uvc_v4l2_set_streamparm.isra.12+0x1c0/0x1c0 [uvcvideo]
[80346.835352]  [81091d9f] ? preempt_count_add+0x3f/0x90
[80346.835356]  [814f73ee] ? _raw_spin_lock+0xe/0x30
[80346.835360]  [814f748d] ? _raw_spin_unlock+0xd/0x30
[80346.835367]  [8110f77e] ? __pte_alloc+0xce/0x170
[80346.835376]  [a04447df] ? v4l2_ioctl+0x11f/0x160 [videodev]
[80346.835386]  [a04527b6] ? do_video_ioctl+0x246/0x1330
[videodev]
[80346.835392]  [8111999a] ? mmap_region+0x15a/0x5a0
[80346.835402]  [a0453922] ? v4l2_compat_ioctl32+0x82/0xb8
[videodev]
[80346.835408]  [81186182] ? compat_SyS_ioctl+0x132/0x1120
[80346.835414]  [81105833] ? vm_mmap_pgoff+0xe3/0x120
[80346.835421]  [814f97c5] ? cstar_dispatch+0x7/0x1a
[80346.835424] ---[ end trace 44e3d272b6c91a71 ]---
[80346.835427] [ cut here ]


What is wrong here?

Kind regards,
Udo

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command completion code 
0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at 
drivers/media/v4l2-core/videobuf2-core.c:2011 __vb2_queue_cancel+0x102/0x170 
[videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse 
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns 
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE xt_tcpudp 
nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables ip6table_filter 
ip6_tables x_tables eeprom it87 hwmon_vid ext2 snd_usb_audio snd_usbmidi_lib 
snd_hwdep snd_rawmidi ppdev pwc videobuf2_vmalloc videobuf2_memops kvm_amd kvm 
v4l2_common videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev 
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq 
snd_seq_device microcode snd_pcm parport_serial parport_pc parport snd_timer 
k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd auth_rpcgss

[PATCH 3/3] au0828: Enable IR for HVR-850.

HVR-850 also has a remote. Enable it.

Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
 drivers/media/usb/au0828/au0828-cards.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/au0828/au0828-cards.c 
b/drivers/media/usb/au0828/au0828-cards.c
index 2c6b7da137ed..b6c9d1f466bd 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -46,6 +46,7 @@ struct au0828_board au0828_boards[] = {
.name   = Hauppauge HVR850,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
+   .has_ir_i2c = 1,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
.input = {
{
-- 
1.9.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 1/3] au0828: no need to sleep at the IR code.

This sleep was doing some debouncing on the original driver.
This is not needed on Linux, because the RC core and the input
layer already takes care of it.

Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
 drivers/media/usb/au0828/au0828-input.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index d527446d008f..53d2c59355f2 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -136,8 +136,6 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
/* Disable IR */
au8522_rc_clear(ir, 0xe0, 1  4);
 
-   usleep_range(45000, 46000);
-
/* Enable IR */
au8522_rc_set(ir, 0xe0, 1  4);
 
-- 
1.9.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 2/3] au0828: add an option to disable IR via modprobe parameter

The IR code increases the power consumption of the device.
Allow to disable it via modprobe parameter.

Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
 drivers/media/usb/au0828/au0828-input.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index 53d2c59355f2..94d29c2a6fcf 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -25,6 +25,10 @@
 #include linux/slab.h
 #include media/rc-core.h
 
+static int disable_ir;
+module_param(disable_ir,int, 0444);
+MODULE_PARM_DESC(disable_ir, disable infrared remote support);
+
 #include au0828.h
 
 struct au0828_rc {
@@ -274,7 +278,7 @@ int au0828_rc_register(struct au0828_dev *dev)
int err = -ENOMEM;
u16 i2c_rc_dev_addr = 0;
 
-   if (!dev-board.has_ir_i2c)
+   if (!dev-board.has_ir_i2c || disable_ir)
return 0;
 
i2c_rc_dev_addr = au0828_probe_i2c_ir(dev);
-- 
1.9.3

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] sp2: Add I2C driver for CIMaX SP2 common interface module




On 08/06/2014 10:05 AM, Olli Salonen wrote:

Driver for the CIMaX SP2 common interface chip. It is very much based on
the existing cimax2 driver for cx23885, but should be more reusable. The
product has been sold with name Atmel T90FJR as well and the data sheets
for that chip seem to be publicly available.

It seems that the USB device that I have and the cx23885 based devices will
need to interact differently with the chip for the CAM operations. Thus
there is one callback function that is passed on to the sp2 driver
(see function sp2_ci_op_cam for that one).

IRQ functionality is not included currently (not needed by USB devices
and I don't have a PCIe device for development).

Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
  drivers/media/dvb-frontends/Makefile   |   1 +
  drivers/media/dvb-frontends/sp2.c  | 411 +
  drivers/media/dvb-frontends/sp2.h  |  54 +
  drivers/media/dvb-frontends/sp2_priv.h |  49 
  4 files changed, 515 insertions(+)
  create mode 100644 drivers/media/dvb-frontends/sp2.c
  create mode 100644 drivers/media/dvb-frontends/sp2.h
  create mode 100644 drivers/media/dvb-frontends/sp2_priv.h

diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index edf103d..3498b95 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_DVB_DRXK) += drxk.o
  obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
  obj-$(CONFIG_DVB_SI2165) += si2165.o
  obj-$(CONFIG_DVB_A8293) += a8293.o
+obj-$(CONFIG_DVB_SP2) += sp2.o
  obj-$(CONFIG_DVB_TDA10071) += tda10071.o
  obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
  obj-$(CONFIG_DVB_RTL2832) += rtl2832.o
diff --git a/drivers/media/dvb-frontends/sp2.c 
b/drivers/media/dvb-frontends/sp2.c
new file mode 100644
index 000..c1b4d7e
--- /dev/null
+++ b/drivers/media/dvb-frontends/sp2.c
@@ -0,0 +1,411 @@
+/*
+ * CIMaX SP2/SP2HF (Atmel T90FJR) CI driver
+ *
+ * Copyright (C) 2014 Olli Salonen olli.salo...@iki.fi
+ *
+ * Heavily based on CIMax2(R) SP2 driver in conjunction with NetUp Dual
+ * DVB-S2 CI card (cimax2) with following copyrights:
+ *
+ *  Copyright (C) 2009 NetUP Inc.
+ *  Copyright (C) 2009 Igor M. Liplianin liplia...@netup.ru
+ *  Copyright (C) 2009 Abylay Ospan aos...@netup.ru
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ */
+
+#include sp2_priv.h
+
+static int sp2_read_i2c(struct sp2 *s, u8 reg, u8 *buf, int len)
+{
+   int ret;
+   struct i2c_client *client = s-client;
+   struct i2c_adapter *adap = client-adapter;
+   struct i2c_msg msg[] = {
+   {
+   .addr = client-addr,
+   .flags = 0,
+   .buf = reg,
+   .len = 1
+   }, {
+   .addr = client-addr,
+   .flags  = I2C_M_RD,
+   .buf = buf,
+   .len = len
+   }
+   };
+
+   ret = i2c_transfer(adap, msg, 2);
+
+   if (ret != 2) {
+   dev_err(client-dev, i2c read error, reg = 0x%02x, status = 
%d\n,
+   reg, ret);
+   return -1;
+   }


Could you define error code here? I know a lot of old drivers were using 
just -1, but for new driver we could try do better. Return possible 
error from i2c_transfer() and if it returns wrong amount of messages (0 
or 1 in that case) then change -EIO.


I looked from I2C documentation and I think -EIO fits best

Documentation/i2c/fault-codes

EIO
This rather vague error means something went wrong when
performing an I/O operation.  Use a more specific fault
code when you can.



+
+   dev_dbg(s-client-dev, addr=0x%04x, reg = 0x%02x, data = %02x\n,
+   client-addr, reg, buf[0]);
+
+   return 0;
+}
+
+static int sp2_write_i2c(struct sp2 *s, u8 reg, u8 *buf, int len)
+{
+   int ret;
+   u8 buffer[35];
+   struct i2c_client *client = s-client;
+   struct i2c_adapter *adap = client-adapter;
+   struct i2c_msg msg = {
+   .addr = client-addr,
+   .flags = 0,
+   .buf = buffer[0],
+   .len = len + 1
+   };
+
+   if ((len + 1)  sizeof(buffer)) {
+   dev_err(client-dev, i2c wr reg=%02x: len=%d is too big!\n,
+   reg, len);
+   return -EINVAL;
+   }
+
+   buffer[0] = reg;
+

Re: [PATCH] em28xx: fix compiler warnings

2014-08-07 Thread Frank Schäfer


Am 07.08.2014 um 08:45 schrieb Hans Verkuil:
 On 08/05/2014 05:18 PM, Frank Schäfer wrote:
 Hi Hans,

 Am 05.08.2014 um 09:00 schrieb Hans Verkuil:
 Fix three compiler warnings:

 drivers/media/usb/em28xx/em28xx-input.c: In function 
 ‘em28xx_i2c_ir_handle_key’:
 drivers/media/usb/em28xx/em28xx-input.c:318:1: warning: the frame size of 
 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
   CC [M]  drivers/media/usb/em28xx/em28xx-dvb.o
 drivers/media/usb/em28xx/em28xx-camera.c: In function 
 ‘em28xx_probe_sensor_micron’:
 drivers/media/usb/em28xx/em28xx-camera.c:199:1: warning: the frame size of 
 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
 drivers/media/usb/em28xx/em28xx-camera.c: In function 
 ‘em28xx_probe_sensor_omnivision’:
 drivers/media/usb/em28xx/em28xx-camera.c:304:1: warning: the frame size of 
 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  }
  ^
 Hmmm... I don't get these weird warnings.
 How can I reproduce them ?
 I'm using gcc 4.9.1 and I'm compiling the kernel using just a regular make 
 command.
 In my .config I have CONFIG_FRAME_WARN=1024.
Weird. With gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388]
I get much smaller frame sizes:

...
drivers/media/usb/em28xx/em28xx-input.c: In function
‘em28xx_i2c_ir_handle_key’:
drivers/media/usb/em28xx/em28xx-input.c:318:1: warning: the frame size
of 424 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...
drivers/media/usb/em28xx/em28xx-camera.c: In function
‘em28xx_probe_sensor_micron’:
drivers/media/usb/em28xx/em28xx-camera.c:199:1: warning: the frame size
of 432 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...
drivers/media/usb/em28xx/em28xx-camera.c: In function
‘em28xx_probe_sensor_omnivision’:
drivers/media/usb/em28xx/em28xx-camera.c:304:1: warning: the frame size
of 428 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...


Anyway, I really don't think a framesize of 1096 is a problem.

 Note: there is no way the code in em28xx_i2c_ir_handle_key() is correct: 
 it's
 using an almost completely uninitialized i2c_client struct with random 
 flags,
 dev and name fields. Can't this turned into a proper i2c_client struct in
 struct em28xx? At least with this patch it's no longer random data.
 Why do you think the client setup is random ?
 Well, this is the code:

   struct i2c_client client;
  
   client.adapter = ir-dev-i2c_adap[dev-def_i2c_bus];
   client.addr = ir-i2c_dev_addr;

 All other fields of the client struct are undefined, but it is used as is. 
 That
 can't be right. With my patch the i2c_client is either that that was used by 
 the
 probe, or it is all zero. Which is still better than having random values.
Take a closer look at the code:

1.) sensor probing:

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

dev-i2c_client[bus] is initialized on bus registration in
em28xx_i2c_register():

dev-i2c_client[bus] = em28xx_client_template;
dev-i2c_client[bus].adapter = dev-i2c_adap[bus];

em28xx_client_template is defined static:

static struct i2c_client em28xx_client_template = {
.name = em28xx internal,
};

So nothing is random or undefined here.


2.) i2c rc key polling:

em28xx_i2c_ir_handle_key() passes the client structure to one of the 4
get_key functions

rc = ir-get_key_i2c(client, protocol, scancode);

which either call

i2c_transfer(client-adapter, msg, len)

directly or the helper function

i2c_master_recv(client, buf, len))

which creates an i2c message before calling i2c_transfer().
The only members used from the i2c_client struct are

msg.addr = client-addr;
msg.flags = client-flags  I2C_M_TEN;

So the only fields from struct i2c_client which need to be setup are
adapter and addr and flags.
Adapter an addres are initialized properly to

client.adapter = ir-dev-i2c_adap[dev-def_i2c_bus];
client.addr = ir-i2c_dev_addr;

The only thing which is indeed missing here and needs to be fixed is

client.flags = 0;


 Which fields do you think are wrong ? AFAICS this patch doesn't change
 any fields.

 What's wrong with using local i2c_client variables ?
 Nothing, except that they take a lot of stack space which the compiler 
 complains about.
Well, it warns because you are forcing a warning.

 The stack in the kernel is limited, so this should be avoided.
Limited to what ? 8k ? So what's the problem ?

 Indeed, the way the driver currently tracks i2c clients / subdevices is
 ... let's say improvable.
 But IMHO, we should go the opposite direction and get rid of the
 i2c_clients in the main device struct.
 They are in fact just temporary helpers and dangerous to use with
 devices with multiple i2c clients on the same bus.
 Feel free to find another solution, but allocating i2c_client structs on the
 stack is not the right solution.
Putting temporary helper variables which are even unused by most devices
into the main device struct is definitely is the wrong

Re: [PATCH 1/3] sp2: Add I2C driver for CIMaX SP2 common interface module

2014-08-07 Thread Olli Salonen

Thank you Antti for the review. I'll submit another version of the
patch in the coming days.

Cheers,
-olli

On 7 August 2014 19:28, Antti Palosaari cr...@iki.fi wrote:
 Reviewed-by: Antti Palosaari cr...@iki.fi

 None of those findings are critical. However I hope you double check and fix
 if there is any relevant enough.

 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 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

Moikka!
Biggest issue is that CIMax2 SP2 driver. Olli put all that stuff to own
I2C driver recently. Could you took SP2 from patchwork and use it instead:
https://patchwork.linuxtv.org/patch/25206/
https://patchwork.linuxtv.org/patch/25210/

It is not yet in mainline, but there should not be any big changes
coming to that driver.

regards
Antti

On 08/06/2014 07:36 AM, nibble.max wrote:
 add dvb-usb-v2 driver for DVBSky dvb-s2 box
 
 Signed-off-by: Nibble Max nibble@gmail.com
 ---
   drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
   drivers/media/usb/dvb-usb-v2/Makefile |   3 +
   drivers/media/usb/dvb-usb-v2/dvbsky.c | 872 
 ++
   3 files changed, 881 insertions(+)
 
 diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
 b/drivers/media/usb/dvb-usb-v2/Kconfig
 index 66645b0..8107c8d 100644
 --- a/drivers/media/usb/dvb-usb-v2/Kconfig
 +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
 @@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
   help
 Say Y here to support the Realtek RTL28xxU DVB USB receiver.
   
 +config DVB_USB_DVBSKY
 + tristate DVBSky USB support
 + depends on DVB_USB_V2
 + select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
 + help
 +   Say Y here to support the USB receivers from DVBSky.
 diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
 b/drivers/media/usb/dvb-usb-v2/Makefile
 index bc38f03..f10d4df 100644
 --- a/drivers/media/usb/dvb-usb-v2/Makefile
 +++ b/drivers/media/usb/dvb-usb-v2/Makefile
 @@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
   dvb-usb-rtl28xxu-objs := rtl28xxu.o
   obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
   
 +dvb-usb-dvbsky-objs := dvbsky.o
 +obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
 +
   ccflags-y += -I$(srctree)/drivers/media/dvb-core
   ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
   ccflags-y += -I$(srctree)/drivers/media/tuners
 diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
 b/drivers/media/usb/dvb-usb-v2/dvbsky.c
 new file mode 100644
 index 000..c86927f
 --- /dev/null
 +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
 @@ -0,0 +1,872 @@
 +/*
 + * Driver for DVBSky USB2.0 receiver
 + *
 + * Copyright (C) 2013 Max nibble nibble@gmail.com
 + *
 + * CIMax code is copied and modified from:
 + * CIMax2(R) SP2 driver in conjunction with NetUp Dual DVB-S2 CI card
 + * Copyright (C) 2009 NetUP Inc.
 + * Copyright (C) 2009 Igor M. Liplianin liplia...@netup.ru
 + * Copyright (C) 2009 Abylay Ospan aos...@netup.ru
 + *
 + *This program is free software; you can redistribute it and/or modify
 + *it under the terms of the GNU General Public License as published by
 + *the Free Software Foundation; either version 2 of the License, or
 + *(at your option) any later version.
 + *
 + *This program is distributed in the hope that it will be useful,
 + *but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *GNU General Public License for more details.
 + *
 + *You should have received a copy of the GNU General Public License
 + *along with this program; if not, write to the Free Software
 + *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +
 +#include dvb_ca_en50221.h
 +#include dvb_usb.h
 +#include m88ds3103.h
 +#include m88ts2022.h
 +
 +static int dvbsky_debug;
 +module_param(dvbsky_debug, int, 0644);
 +MODULE_PARM_DESC(dvbsky_debug, Activates dvbsky usb debugging (default:0));
 +
 +#define DVBSKY_MSG_DELAY 0/*2000*/
 +#define DVBSKY_CI_CTL0x04
 +#define DVBSKY_CI_RD 1
 +
 +#define dprintk(args...) \
 + do { \
 + if (dvbsky_debug) \
 + printk(KERN_INFO dvbsky_usb:  args); \
 + } while (0)
 +
 +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 +
 +struct dvbsky_state {
 + struct mutex stream_mutex;
 + u8 has_ci;
 + u8 ci_attached;
 + struct dvb_ca_en50221 ci;
 + unsigned long next_status_checked_time;
 + u8 ci_i2c_addr;
 + u8 current_ci_flag;
 + int ci_status;
 + struct i2c_client *i2c_client_tuner;
 +};
 +
 +static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
 +{
 + struct dvbsky_state *state = d_to_priv(d);
 + int ret;
 + u8 obuf_pre[3] = { 0x37, 0, 0 };
 + u8 obuf_post[3] = { 0x36, 3, 0 };
 + dprintk(%s() -off \n, __func__);
 + mutex_lock(state-stream_mutex);
 + ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
 + if (!ret  onoff) {
 + msleep(10);
 + ret = dvb_usbv2_generic_write(d, obuf_post, 3);
 + dprintk(%s() -on \n, __func__);
 + }
 + mutex_unlock(state-stream_mutex);
 + return ret;
 +}
 +
 +/* CI opertaions */
 +static int dvbsky_ci_read_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
 + u8 *buf, int len)
 +{
 + int ret;
 + struct i2c_msg msg[] = {
 + {
 +

Re: [media:v4l_for_linus 393/499] tuner-core.c:undefined reference to `xc5000_attach'


Mauro,
could you look that one? There is now multiple reports for ~all those 
silicon tuners which are used by tuner.ko module (CONFIG MEDIA_TUNER). 
Even it blames SDR Kconfig tuner patch I made, it is not the real issue. 
In my understanding issue is that tuner.ko is build-in and those tuner 
drivers it uses are build as a module. I think those used tuners 
(xc5000, xc4000, etc.) should be defaulted to same as MEDIA_TUNER when 
!MEDIA_SUBDRV_AUTOSELECT.



regards
Antti



On 08/06/2014 09:04 AM, kbuild test robot wrote:

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus
head:   0f3bf3dc1ca394a8385079a5653088672b65c5c4
commit: f5b44da1ac4146e06147a5df3058f4c265c932ec [393/499] [media] Kconfig: fix 
tuners build warnings
config: x86_64-randconfig-s1-08061342 (attached as .config)

All error/warnings:

drivers/built-in.o: In function `set_type':

tuner-core.c:(.text+0x32ed52): undefined reference to `xc5000_attach'
tuner-core.c:(.text+0x32f123): undefined reference to `xc5000_attach'

tuner-core.c:(.text+0x32f1e6): undefined reference to `xc4000_attach'

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

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:   Fri Aug  8 04:00:28 CEST 2014
git branch: test
git hash:   0f3bf3dc1ca394a8385079a5653088672b65c5c4
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-16-g1db35d0
host hardware:  x86_64
host os:3.15-7.slh.3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driverfor DVBSky dvb-s2 box

Moikka!
Moikka!
Biggest issue is that CIMax2 SP2 driver. Olli put all that stuff to own
I2C driver recently. Could you took SP2 from patchwork and use it instead:
https://patchwork.linuxtv.org/patch/25206/
https://patchwork.linuxtv.org/patch/25210/
Yes, the CIMax2 SP2 code here is the same as Olli's.
But Olli comes to make a standard i2c driver, so I will remove the ci code from 
dvbsky usb driver.
As Olli finish the code ready, I will use his code for ci part.

It is not yet in mainline, but there should not be any big changes
coming to that driver.

regards
Antti

On 08/06/2014 07:36 AM, nibble.max wrote:
 add dvb-usb-v2 driver for DVBSky dvb-s2 box
 
 Signed-off-by: Nibble Max nibble@gmail.com
 ---
   drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
   drivers/media/usb/dvb-usb-v2/Makefile |   3 +
   drivers/media/usb/dvb-usb-v2/dvbsky.c | 872 
 ++
   3 files changed, 881 insertions(+)
 
 diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
 b/drivers/media/usb/dvb-usb-v2/Kconfig
 index 66645b0..8107c8d 100644
 --- a/drivers/media/usb/dvb-usb-v2/Kconfig
 +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
 @@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
  help
Say Y here to support the Realtek RTL28xxU DVB USB receiver.
   
 +config DVB_USB_DVBSKY
 +tristate DVBSky USB support
 +depends on DVB_USB_V2
 +select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
 +help
 +  Say Y here to support the USB receivers from DVBSky.
 diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
 b/drivers/media/usb/dvb-usb-v2/Makefile
 index bc38f03..f10d4df 100644
 --- a/drivers/media/usb/dvb-usb-v2/Makefile
 +++ b/drivers/media/usb/dvb-usb-v2/Makefile
 @@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
   dvb-usb-rtl28xxu-objs := rtl28xxu.o
   obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
   
 +dvb-usb-dvbsky-objs := dvbsky.o
 +obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
 +
   ccflags-y += -I$(srctree)/drivers/media/dvb-core
   ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
   ccflags-y += -I$(srctree)/drivers/media/tuners
 diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
 b/drivers/media/usb/dvb-usb-v2/dvbsky.c
 new file mode 100644
 index 000..c86927f
 --- /dev/null
 +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
 @@ -0,0 +1,872 @@
 +/*
 + * Driver for DVBSky USB2.0 receiver
 + *
 + * Copyright (C) 2013 Max nibble nibble@gmail.com
 + *
 + * CIMax code is copied and modified from:
 + * CIMax2(R) SP2 driver in conjunction with NetUp Dual DVB-S2 CI card
 + * Copyright (C) 2009 NetUP Inc.
 + * Copyright (C) 2009 Igor M. Liplianin liplia...@netup.ru
 + * Copyright (C) 2009 Abylay Ospan aos...@netup.ru
 + *
 + *This program is free software; you can redistribute it and/or modify
 + *it under the terms of the GNU General Public License as published by
 + *the Free Software Foundation; either version 2 of the License, or
 + *(at your option) any later version.
 + *
 + *This program is distributed in the hope that it will be useful,
 + *but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *GNU General Public License for more details.
 + *
 + *You should have received a copy of the GNU General Public License
 + *along with this program; if not, write to the Free Software
 + *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +
 +#include dvb_ca_en50221.h
 +#include dvb_usb.h
 +#include m88ds3103.h
 +#include m88ts2022.h
 +
 +static int dvbsky_debug;
 +module_param(dvbsky_debug, int, 0644);
 +MODULE_PARM_DESC(dvbsky_debug, Activates dvbsky usb debugging 
 (default:0));
 +
 +#define DVBSKY_MSG_DELAY0/*2000*/
 +#define DVBSKY_CI_CTL   0x04
 +#define DVBSKY_CI_RD1
 +
 +#define dprintk(args...) \
 +do { \
 +if (dvbsky_debug) \
 +printk(KERN_INFO dvbsky_usb:  args); \
 +} while (0)
 +
 +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 +
 +struct dvbsky_state {
 +struct mutex stream_mutex;
 +u8 has_ci;
 +u8 ci_attached;
 +struct dvb_ca_en50221 ci;
 +unsigned long next_status_checked_time;
 +u8 ci_i2c_addr;
 +u8 current_ci_flag;
 +int ci_status;
 +struct i2c_client *i2c_client_tuner;
 +};
 +
 +static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
 +{
 +struct dvbsky_state *state = d_to_priv(d);
 +int ret;
 +u8 obuf_pre[3] = { 0x37, 0, 0 };
 +u8 obuf_post[3] = { 0x36, 3, 0 };
 +dprintk(%s() -off \n, __func__);
 +mutex_lock(state-stream_mutex);
 +ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
 +if (!ret  onoff) {
 +msleep(10);
 +ret = dvb_usbv2_generic_write(d, obuf_post, 3);
 +dprintk(%s() -on \n, __func__);
 +}
 +mutex_unlock(state-stream_mutex);
 +return ret;
 +}
 +
 +/* CI opertaions */
 +static int dvbsky_ci_read_i2c(struct

3.15.8 USB issue with uvc cam

2014-08-07 Thread Udo van den Heuvel

Hello,

I get WARNINGs when trying to use a Logitech C615 cam.
See attachment for full dmesg of errors but excerpt below:

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command
completion code 0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at
drivers/media/v4l2-core/videobuf2-core.c:2011
__vb2_queue_cancel+0x102/0x170 [videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE
xt_tcpudp nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables
ip6table_filter ip6_tables x_tables eeprom it87 hwmon_vid ext2
snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi ppdev pwc
videobuf2_vmalloc videobuf2_memops kvm_amd kvm v4l2_common
videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq
snd_seq_device microcode snd_pcm parport_serial parport_pc parport
snd_timer k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd
auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic
usbhid ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon
bitblit cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit
xhci_hcd backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm: skype Tainted: GW
3.15.8 #6
[80346.835254] Hardware name: Gigabyte Technology Co., Ltd. To be filled
by O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013
[80346.835257]   79d580f4 814f2373

[80346.835262]  81069fe1  88040ec532e8

[80346.835267]  88040ec530d8 8803f0c46f00 a041d832
88040ec530d8
[80346.835272] Call Trace:
[80346.835283]  [814f2373] ? dump_stack+0x4a/0x75
[80346.835289]  [81069fe1] ? warn_slowpath_common+0x81/0xb0
[80346.835299]  [a041d832] ? __vb2_queue_cancel+0x102/0x170
[videobuf2_core]
[80346.835307]  [a041f53d] ? vb2_internal_streamoff+0x1d/0x50
[videobuf2_core]
[80346.835314]  [a06140d5] ? uvc_queue_enable+0x75/0xb0 [uvcvideo]
[80346.835321]  [a0619091] ? uvc_video_enable+0x141/0x1a0
[uvcvideo]
[80346.835327]  [a0615e1f] ? uvc_v4l2_do_ioctl+0xd6f/0x1580
[uvcvideo]
[80346.835339]  [a0448bc0] ? video_usercopy+0x1f0/0x490 [videodev]
[80346.835345]  [a06150b0] ?
uvc_v4l2_set_streamparm.isra.12+0x1c0/0x1c0 [uvcvideo]
[80346.835352]  [81091d9f] ? preempt_count_add+0x3f/0x90
[80346.835356]  [814f73ee] ? _raw_spin_lock+0xe/0x30
[80346.835360]  [814f748d] ? _raw_spin_unlock+0xd/0x30
[80346.835367]  [8110f77e] ? __pte_alloc+0xce/0x170
[80346.835376]  [a04447df] ? v4l2_ioctl+0x11f/0x160 [videodev]
[80346.835386]  [a04527b6] ? do_video_ioctl+0x246/0x1330
[videodev]
[80346.835392]  [8111999a] ? mmap_region+0x15a/0x5a0
[80346.835402]  [a0453922] ? v4l2_compat_ioctl32+0x82/0xb8
[videodev]
[80346.835408]  [81186182] ? compat_SyS_ioctl+0x132/0x1120
[80346.835414]  [81105833] ? vm_mmap_pgoff+0xe3/0x120
[80346.835421]  [814f97c5] ? cstar_dispatch+0x7/0x1a
[80346.835424] ---[ end trace 44e3d272b6c91a71 ]---
[80346.835427] [ cut here ]


What is wrong here?

Kind regards,
Udo


[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command completion code 
0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at 
drivers/media/v4l2-core/videobuf2-core.c:2011 __vb2_queue_cancel+0x102/0x170 
[videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse 
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns 
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE xt_tcpudp 
nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables ip6table_filter 
ip6_tables x_tables eeprom it87 hwmon_vid ext2 snd_usb_audio snd_usbmidi_lib 
snd_hwdep snd_rawmidi ppdev pwc videobuf2_vmalloc videobuf2_memops kvm_amd kvm 
v4l2_common videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev 
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq 
snd_seq_device microcode snd_pcm parport_serial parport_pc parport snd_timer 
k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic usbhid 
ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon bitblit 
cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit xhci_hcd 
backlight

[PATCH 1/4 v2] support for DVBSky dvb-s2 usb: Add ts clock and clock polarity, lnb set voltage for m88ds3103

Add ts clock and clock polarity, lnb set voltage.

Signed-off-by: Nibble Max nibble@gmail.com
---
 drivers/media/dvb-frontends/m88ds3103.c | 77 +
 drivers/media/dvb-frontends/m88ds3103.h | 25 ---
 2 files changed, 70 insertions(+), 32 deletions(-)

diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
b/drivers/media/dvb-frontends/m88ds3103.c
index dfe0c2f..142f9a6 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -247,7 +247,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
u8 u8tmp, u8tmp1, u8tmp2;
u8 buf[2];
u16 u16tmp, divide_ratio;
-   u32 tuner_frequency, target_mclk, ts_clk;
+   u32 tuner_frequency, target_mclk;
s32 s32tmp;
dev_dbg(priv-i2c-dev,
%s: delivery_system=%d modulation=%d frequency=%d 
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
@@ -316,9 +316,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
target_mclk = 144000;
break;
case M88DS3103_TS_PARALLEL:
-   case M88DS3103_TS_PARALLEL_12:
-   case M88DS3103_TS_PARALLEL_16:
-   case M88DS3103_TS_PARALLEL_19_2:
case M88DS3103_TS_CI:
if (c-symbol_rate  1800)
target_mclk = 96000;
@@ -352,33 +349,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
switch (priv-cfg-ts_mode) {
case M88DS3103_TS_SERIAL:
u8tmp1 = 0x00;
-   ts_clk = 0;
-   u8tmp = 0x46;
+   u8tmp = 0x06;
break;
case M88DS3103_TS_SERIAL_D7:
u8tmp1 = 0x20;
-   ts_clk = 0;
-   u8tmp = 0x46;
+   u8tmp = 0x06;
break;
case M88DS3103_TS_PARALLEL:
-   ts_clk = 24000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_12:
-   ts_clk = 12000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_16:
-   ts_clk = 16000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_19_2:
-   ts_clk = 19200;
-   u8tmp = 0x42;
+   u8tmp = 0x02;
break;
case M88DS3103_TS_CI:
-   ts_clk = 6000;
-   u8tmp = 0x43;
+   u8tmp = 0x03;
break;
default:
dev_dbg(priv-i2c-dev, %s: invalid ts_mode\n, __func__);
@@ -386,6 +367,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
 
+   if (priv-cfg-ts_clk_pol)
+   u8tmp |= 0x40;
+
/* TS mode */
ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
if (ret)
@@ -399,8 +383,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
 
-   if (ts_clk) {
-   divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
+   if (priv-cfg-ts_clk) {
+   divide_ratio = DIV_ROUND_UP(target_mclk, priv-cfg-ts_clk);
u8tmp1 = divide_ratio / 2;
u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
} else {
@@ -411,7 +395,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
 
dev_dbg(priv-i2c-dev,
%s: target_mclk=%d ts_clk=%d divide_ratio=%d\n,
-   __func__, target_mclk, ts_clk, divide_ratio);
+   __func__, target_mclk, priv-cfg-ts_clk, divide_ratio);
 
u8tmp1--;
u8tmp2--;
@@ -1053,6 +1037,44 @@ err:
return ret;
 }
 
+static int m88ds3103_set_voltage(struct dvb_frontend *fe,
+   fe_sec_voltage_t voltage)
+{
+   struct m88ds3103_priv *priv = fe-demodulator_priv;
+   u8 data;
+
+   dev_dbg(priv-i2c-dev, %s: pin_ctrl = (%02x)\n,
+   __func__, priv-cfg-pin_ctrl);
+
+   m88ds3103_rd_reg(priv, 0xa2, data);
+
+   if (priv-cfg-pin_ctrl  0x80) { /*If control pin is assigned.*/
+   data = ~0x03; /* bit0 V/H, bit1 off/on */
+   if (priv-cfg-pin_ctrl  0x02)
+   data |= 0x02;
+
+   switch (voltage) {
+   case SEC_VOLTAGE_18:
+if ((priv-cfg-pin_ctrl  0x01) == 0)
+   data |= 0x01;
+break;
+   case SEC_VOLTAGE_13:
+if (priv-cfg-pin_ctrl  0x01)
+   data |= 0x01;
+break;
+   case SEC_VOLTAGE_OFF:
+if (priv-cfg-pin_ctrl  0x02)
+   data = ~0x02;
+else
+   data |= 0x02;
+break;
+   }
+   }
+   m88ds3103_wr_reg(priv, 0xa2, data);
+
+

[PATCH 3/4 v2] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box, no ci support.

remove ci support part in v1 patch.
hook demod read status and set voltage operations.

Signed-off-by: Nibble Max nibble@gmail.com
---
 drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
 drivers/media/usb/dvb-usb-v2/Makefile |   3 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 455 ++
 3 files changed, 464 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 66645b0..8107c8d 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
help
  Say Y here to support the Realtek RTL28xxU DVB USB receiver.
 
+config DVB_USB_DVBSKY
+   tristate DVBSky USB support
+   depends on DVB_USB_V2
+   select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y here to support the USB receivers from DVBSky.
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
b/drivers/media/usb/dvb-usb-v2/Makefile
index bc38f03..f10d4df 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
 dvb-usb-rtl28xxu-objs := rtl28xxu.o
 obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
 
+dvb-usb-dvbsky-objs := dvbsky.o
+obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
+
 ccflags-y += -I$(srctree)/drivers/media/dvb-core
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
 ccflags-y += -I$(srctree)/drivers/media/tuners
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
new file mode 100644
index 000..2db363e
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -0,0 +1,455 @@
+/*
+ * Driver for DVBSky USB2.0 receiver
+ *
+ * Copyright (C) 2013 Max nibble nibble@gmail.com
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include dvb_usb.h
+#include m88ds3103.h
+#include m88ts2022.h
+
+static int dvbsky_debug;
+module_param(dvbsky_debug, int, 0644);
+MODULE_PARM_DESC(dvbsky_debug, Activates dvbsky usb debugging (default:0));
+
+#define DVBSKY_MSG_DELAY   0/*2000*/
+
+#define dprintk(args...) \
+   do { \
+   if (dvbsky_debug) \
+   printk(KERN_INFO dvbsky_usb:  args); \
+   } while (0)
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+struct dvbsky_state {
+   struct mutex stream_mutex;
+   u8 last_lock;
+   struct i2c_client *i2c_client_tuner;
+   int (*fe_set_voltage)(struct dvb_frontend *fe,
+   fe_sec_voltage_t voltage);
+   int (*fe_read_status)(struct dvb_frontend *fe,
+   fe_status_t *status);
+};
+
+static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
+{
+   struct dvbsky_state *state = d_to_priv(d);
+   int ret;
+   u8 obuf_pre[3] = { 0x37, 0, 0 };
+   u8 obuf_post[3] = { 0x36, 3, 0 };
+   dprintk(%s() -off \n, __func__);
+   mutex_lock(state-stream_mutex);
+   ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
+   if (!ret  onoff) {
+   msleep(10);
+   ret = dvb_usbv2_generic_write(d, obuf_post, 3);
+   dprintk(%s() -on \n, __func__);
+   }
+   mutex_unlock(state-stream_mutex);
+   return ret;
+}
+
+static int dvbsky_streaming_ctrl(struct dvb_frontend *fe, int onoff)
+{
+   struct dvb_usb_device *d = fe_to_d(fe);
+   /*dprintk(%s() %d\n, __func__, onoff);*/
+   return dvbsky_stream_ctrl(d, (onoff == 0) ? 0 : 1);
+}
+
+/* GPIO */
+static int dvbsky_gpio_ctrl(struct dvb_usb_device *d, u8 gport, u8 value)
+{
+   int ret;
+   u8 obuf[64], ibuf[64];
+   obuf[0] = 0x0e;
+   obuf[1] = gport;
+   obuf[2] = value;
+   ret = dvb_usbv2_generic_rw(d, obuf, 3, ibuf, 1);
+   if (ret)
+   dev_err(d-udev-dev, %s: %s()  \
+   failed=%d\n, KBUILD_MODNAME, __func__, ret);
+   return ret;
+}
+
+/* I2C */
+static int dvbsky_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+   int num)
+{
+   struct dvb_usb_device *d = i2c_get_adapdata(adap);
+   int ret = 0;
+   u8 ibuf[64], obuf[64];
+
+   if (mutex_lock_interruptible(d-i2c_mutex)  0)
+   return -EAGAIN;
+
+   if (num  2) {
+

Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

2014-08-07 Thread Olli Salonen

Hi Max,

nibble.max nibble.max at gmail.com writes:
 diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
 index 66645b0..8107c8d 100644
 --- a/drivers/media/usb/dvb-usb-v2/Kconfig
 +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
  at  at  -141,3 +141,9  at  at  config DVB_USB_RTL28XXU
   help
 Say Y here to support the Realtek RTL28xxU DVB USB receiver.
 
 +config DVB_USB_DVBSKY
 + tristate DVBSky USB support
 + depends on DVB_USB_V2
 + select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
 + help
 +   Say Y here to support the USB receivers from DVBSky.

Shouldn't the MEDIA_TUNER_M88TS2022 also be selected in Kconfig?

Cheers,
-olli



--
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: Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

Hello Olli,
Hi Max,

nibble.max nibble.max at gmail.com writes:
 diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
 index 66645b0..8107c8d 100644
 --- a/drivers/media/usb/dvb-usb-v2/Kconfig
 +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
  at  at  -141,3 +141,9  at  at  config DVB_USB_RTL28XXU
  help
Say Y here to support the Realtek RTL28xxU DVB USB receiver.
 
 +config DVB_USB_DVBSKY
 +tristate DVBSky USB support
 +depends on DVB_USB_V2
 +select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
 +help
 +  Say Y here to support the USB receivers from DVBSky.

Shouldn't the MEDIA_TUNER_M88TS2022 also be selected in Kconfig?
Yes, I miss it. It should be selected in Kconfig.
Thanks.

Cheers,
-olli



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4 v3] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box, no ci support.