Re: [RFCv2 PATCH 02/10] v4l2: add matrix support.

[Hans Verkuil]

On 08/14/2013 04:33 PM, Sakari Ailus wrote:
 Hi Hans,
 
 Thanks for the set!
 
 On Mon, Aug 12, 2013 at 12:58:25PM +0200, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 This patch adds core support for matrices: querying, getting and setting.

 Two initial matrix types are defined for motion detection (defining regions
 and thresholds).
 
 I requested in the past that no new IOCTLs would be added for an essential
 extension of V4L2 control-like functionality. I understand developing a more
 generic framework does not answer to the problems at hand right now, so I
 think it's certainly fine to continue with matrix IOCTLs, too. But we still
 should think a little about extensibility a little bit.
 
 How about using the same ID space as the controls do for matrices, for
 instance, so we won't get one more? The selections and controls have no ID
 collisions at the moment.

Fair enough. That certainly doesn't hurt.

 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/v4l2-core/v4l2-dev.c   |  3 ++
  drivers/media/v4l2-core/v4l2-ioctl.c | 23 -
  include/media/v4l2-ioctl.h   |  8 +
  include/uapi/linux/videodev2.h   | 64 
 
  4 files changed, 97 insertions(+), 1 deletion(-)

 diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
 b/drivers/media/v4l2-core/v4l2-dev.c
 index c8859d6..5e58df6 100644
 --- a/drivers/media/v4l2-core/v4l2-dev.c
 +++ b/drivers/media/v4l2-core/v4l2-dev.c
 @@ -598,6 +598,9 @@ static void determine_valid_ioctls(struct video_device 
 *vdev)
  SET_VALID_IOCTL(ops, VIDIOC_UNSUBSCRIBE_EVENT, 
 vidioc_unsubscribe_event);
  if (ops-vidioc_enum_freq_bands || ops-vidioc_g_tuner || 
 ops-vidioc_g_modulator)
  set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
 +SET_VALID_IOCTL(ops, VIDIOC_QUERY_MATRIX, vidioc_query_matrix);
 +SET_VALID_IOCTL(ops, VIDIOC_G_MATRIX, vidioc_g_matrix);
 +SET_VALID_IOCTL(ops, VIDIOC_S_MATRIX, vidioc_s_matrix);
  
  if (is_vid) {
  /* video specific ioctls */
 diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
 b/drivers/media/v4l2-core/v4l2-ioctl.c
 index 68e6b5e..47debfc 100644
 --- a/drivers/media/v4l2-core/v4l2-ioctl.c
 +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
 @@ -549,7 +549,7 @@ static void v4l_print_cropcap(const void *arg, bool 
 write_only)
  const struct v4l2_cropcap *p = arg;
  
  pr_cont(type=%s, bounds wxh=%dx%d, x,y=%d,%d, 
 -defrect wxh=%dx%d, x,y=%d,%d\n, 
 +defrect wxh=%dx%d, x,y=%d,%d, 
  pixelaspect %d/%d\n,
  prt_names(p-type, v4l2_type_names),
  p-bounds.width, p-bounds.height,
 @@ -831,6 +831,24 @@ static void v4l_print_freq_band(const void *arg, bool 
 write_only)
  p-rangehigh, p-modulation);
  }
  
 +static void v4l_print_query_matrix(const void *arg, bool write_only)
 +{
 +const struct v4l2_query_matrix *p = arg;
 +
 +pr_cont(type=0x%x, columns=%u, rows=%u, elem_min=%lld, elem_max=%lld, 
 elem_size=%u\n,
 +p-type, p-columns, p-rows,
 +p-elem_min.val, p-elem_max.val, p-elem_size);
 +}
 +
 +static void v4l_print_matrix(const void *arg, bool write_only)
 +{
 +const struct v4l2_matrix *p = arg;
 +
 +pr_cont(type=0x%x, wxh=%dx%d, x,y=%d,%d, matrix=%p\n,
 +p-type, p-rect.width, p-rect.height,
 +p-rect.top, p-rect.left, p-matrix);
 +}
 +
  static void v4l_print_u32(const void *arg, bool write_only)
  {
  pr_cont(value=%u\n, *(const u32 *)arg);
 @@ -2055,6 +2073,9 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
  IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap, 
 v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
  IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
 v4l_print_freq_band, 0),
  IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
 v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
 +IOCTL_INFO_STD(VIDIOC_QUERY_MATRIX, vidioc_query_matrix, 
 v4l_print_query_matrix, INFO_FL_CLEAR(v4l2_query_matrix, ref)),
 +IOCTL_INFO_STD(VIDIOC_G_MATRIX, vidioc_g_matrix, v4l_print_matrix, 
 INFO_FL_CLEAR(v4l2_matrix, matrix)),
 +IOCTL_INFO_STD(VIDIOC_S_MATRIX, vidioc_s_matrix, v4l_print_matrix, 
 INFO_FL_PRIO | INFO_FL_CLEAR(v4l2_matrix, matrix)),
  };
  #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
  
 diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
 index e0b74a4..7e4538e 100644
 --- a/include/media/v4l2-ioctl.h
 +++ b/include/media/v4l2-ioctl.h
 @@ -271,6 +271,14 @@ struct v4l2_ioctl_ops {
  int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
  const struct v4l2_event_subscription 
 *sub);
  
 +/* Matrix ioctls */
 +int (*vidioc_query_matrix) (struct file *file, void *fh,
 +struct v4l2_query_matrix *qmatrix);
 +int 

Re: [RFCv2 PATCH 02/10] v4l2: add matrix support.

[Sakari Ailus]

Hi Hans,

On Thu, Aug 15, 2013 at 08:35:01AM +0200, Hans Verkuil wrote:
 On 08/14/2013 04:33 PM, Sakari Ailus wrote:
...
  + * @columns:  number of columns in the matrix
  + * @rows: number of rows in the matrix
  
  Two dimensions only? How about one or three? I could imagine use for one, at
  the very least.
 
 For one you just set rows to 1. A vector is after all a matrix of one row.
 Should we need a third dimension, then there are enough reserved fields to 
 make
 that possible. I can't think of a single use-case that would require a three
 dimensional matrix.

Fine for me.

  + * @elem_min: minimum matrix element value
  + * @elem_max: maximum matrix element value
  + * @elem_size:size in bytes each matrix element
  + * @reserved: future extensions, applications and drivers must zero 
  this.
  + */
  +struct v4l2_query_matrix {
  +  __u32 type;
  +  union {
  +  __u32 raw[4];
  +  } ref;
  +  __u32 columns;
  +  __u32 rows;
  +  union {
  +  __s64 val;
  +  __u64 uval;
  +  __u32 raw[4];
  +  } elem_min;
  +  union {
  +  __s64 val;
  +  __u64 uval;
  +  __u32 raw[4];
  +  } elem_max;
  
  How about step; do you think it'd make sense to specify that? I have to
  admit the step in controls hasn't been extemely useful to me: much of the
  time the value of the control should have just been divided by the step,
  with the exception of controls that have a standardised unit, but even then
  step won't do good on them since there's typically no 1:1 mapping between
  possible values and the actual values which leads the driver writer choosing
  step of one.
 
 You just explained why I decided against adding a step :-)
 
 I also can't really see a use-case for a step in a matrix.

I agree --- I brought it up mostly since controls already do have step.

  +  __u32 elem_size;
  +  __u32 reserved[12];
  +} __attribute__ ((packed));
  +
  +/**
  + * struct v4l2_matrix - VIDIOC_G/S_MATRIX argument
  + * @type: matrix type
  + * @ref:  reference to some object (if any) owning the matrix
  + * @rect: which part of the matrix to get/set
  
  In some cases it might be possible to choose the size of the matrix. If this
  isn't supported now, do you have ideas how to add it? Perhaps using rect
  woulnd't be possible. A new IOCTL could be one possibility as well; that'd
  make it quite clear and drivers not supporting it wouldn't implement it. I
  think it might quite well make it together with S_MATRIX, though, e.g. a
  flags field with a flag telling that the dimension fields are valid.
 
 Would it be an idea to add a flags field to both v4l2_matrix and 
 v4l2_query_matrix?
 We don't have flags yet, but that makes it easy to add. For a feature such as 
 you
 describe it would be easy enough to implement that by setting an e.g.
 V4L2_MATRIX_FL_NEW_SIZE flag. In query_matrix you would than have a
 V4L2_QMATRIX_FL_HAS_NEW_SIZE (or perhaps in query_matrix it should be called
 'capabilities' instead).
 
 I can also just leave it out and use one of the reserved fields when such a 
 feature
 is needed.

I propose adding the flags fields once they're actually needed.

  + * @matrix:   pointer to the matrix of size (in bytes):
  + *elem_size * rect.width * rect.height
  + * @reserved: future extensions, applications and drivers must zero 
  this.
  + */
  +struct v4l2_matrix {
  +  __u32 type;
  +  union {
  +  __u32 raw[4];
  +  } ref;
  +  struct v4l2_rect rect;
  +  void __user *matrix;
  +  __u32 reserved[12];
  +} __attribute__ ((packed));
  +
   /*
*I O C T L   C O D E S   F O R   V I D E O   D E V I C E S
*
  @@ -1946,6 +2004,12 @@ struct v4l2_create_buffers {
  Never use these in applications! */
   #define VIDIOC_DBG_G_CHIP_INFO  _IOWR('V', 102, struct v4l2_dbg_chip_info)
   
  +/* Experimental, these three ioctls may change over the next couple of 
  kernel
  +   versions. */
  +#define VIDIOC_QUERY_MATRIX   _IOWR('V', 103, struct 
  v4l2_query_matrix)
  +#define VIDIOC_G_MATRIX   _IOWR('V', 104, struct v4l2_matrix)
  +#define VIDIOC_S_MATRIX   _IOWR('V', 105, struct v4l2_matrix)
  +
   /* Reminder: when adding new ioctls please add support for them to
  drivers/media/video/v4l2-compat-ioctl32.c as well! */
   
  
 
 Thanks for the review!
 
 I'll prepare a new version this weekend dropping the ref fields and 
 integrating the ID
 space into that of the controls.

Thanks! :-)

-- 
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: How to express planar formats with mediabus format code?

[Su Jiaquan]

Hi Laurent / Guennadi,

On Sat, Aug 10, 2013 at 1:06 AM, Su Jiaquan jiaquan@gmail.com wrote:
 Hi Laurent / Guennadi,

 On Fri, Aug 9, 2013 at 5:12 AM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
 Hi,

 On Tuesday 06 August 2013 17:18:14 Su Jiaquan wrote:
 Hi Guennadi,

 Thanks for the reply! Please see my description inline.

 On Mon, Aug 5, 2013 at 5:02 AM, Guennadi Liakhovetski wrote:
  On Sun, 4 Aug 2013, Su Jiaquan wrote:
  Hi,
 
  I know the title looks crazy, but here is our problem:
 
  In our SoC based ISP, the hardware can be divide to several blocks.
  Some blocks can do color space conversion(raw to YUV interleave/planar),
  others can do the pixel re-order(interleave/planar/semi-planar
  conversion, UV planar switch). We use one subdev to describe each of
  them, then came the problem: How can we express the planar formats with
  mediabus format code?
 
  Could you please explain more exactly what you mean? How are those your
  blocks connected? How do they exchange data? If they exchange data over a
  serial bus, then I don't think planar formats make sense, right? Or do
  your blocks really output planes one after another, reordering data
  internally? That would be odd... If OTOH your blocks output data to RAM,
  and the next block takes data from there, then you use V4L2_PIX_FMT_*
  formats to describe them and any further processing block should be a
  mem2mem device. Wouldn't this work?

 These two hardware blocks are both located inside of ISP, and is connected
 by a hardware data bus.

 Actually, there are three blocks inside ISP: One is close to sensor, and can
 do color space conversion(RGB-YUV), we call it IPC; The other two are at
 back end, which are basically DMA Engine, and they are identical. When data
 flow out of IPC, it can go into each one of these DMA Engines and finally
 into RAM. Whether the DMA Engine is turned on/off and the output format can
 be controlled independently. Since they are DMA Engines, they have some
 basic pixel reordering ability(i.e. interleave-planar/semi-planar).

 In our H/W design, when we want to get YUV semi-planar format, the IPC
 output should be configured to interleave, and the DMA engine will do the
 interleave-semi-planar job. If we want planar / interleave format, the IPC
 will output planar format directly, DMA engine simply send the data to RAM,
 and don't do any re-order. So in the planar output case, media-bus formats
 can't express the format of the data between IPC and DMA Engine, that's the
 problem we meet.

 If the format between the two subdevs is really planar, I don't see any
 problem defining a media bus pixel code for it. You will have to properly
 document the format of course.

 I'm a bit surprised that the IPC could output planar data. It would need to
 buffer a whole image to do so, do you need to give it a temporary system RAM
 buffer ?

 We want to adopt a formal solution before we send our patch to the
 community, that's where our headache comes.

 --
 Regards,

 Laurent Pinchart


 Thanks for the reply!

 Actually, we don't need to buffer the frame inside IPC, there are
 three channels in the data bus. When transfering interleave format,
 only one channel is used, for planar formats, three channels send one
 planar each, and to difference address(Let me confirm this with our
 H/W team and get back to you later). So the planars is not sent one
 after an other, but in parallel.

 This may be a bit different from the planar formats as people think it
 should be. Can we use planar format to describe it? Since this won't
 cause any misunderstanding given it's used in this special case.
 Please advice.

 Thanks a lot!

 Jiaquan

I have to say I'm sorry for the wrong information. I just double
checked with hardware team, and turns out there is only one channel
for the data bus between IPC and ispdma.
If ispdma output planar format, the data format between IPC and ispdma
should be configured to a special format, that is not the same with
any know media-bus format.
So I think what we need is to define vendor-specific media-bus code.
Since others any want to do the same thing, shall we define a base
address for the vendor specific formats? For example:

enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 0x0001,

...

/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+   V4L2_MBUS_FMT_PRIVATE_BASE = 0xF001,
};

If you are OK with this, I'll prepare a patch to add it

Thanks!

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

Re: [PATCH] media: st-rc: Add ST remote control driver

[Mark Rutland]

On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
 From: Srinivas Kandagatla srinivas.kandaga...@st.com
 
 This patch adds support to ST RC driver, which is basically a IR/UHF
 receiver and transmitter. This IP is common across all the ST parts for
 settop box platforms. IRB is embedded in ST COMMS IP block.
 It supports both Rx  Tx functionality.
 
 In this driver adds only Rx functionality via LIRC codec.

Is there anything that additionally needs to be in the dt to support Tx
functionality?

 
 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
 ---
 Hi Chehab,
 
 This is a very simple rc driver for IRB controller found in STi ARM CA9 SOCs.
 STi ARM SOC support went in 3.11 recently.
 This driver is a raw driver which feeds data to lirc codec for the user lircd
 to decode the keys.
 
 This patch is based on git://linuxtv.org/media_tree.git master branch.
 
 Comments?
 
 Thanks,
 srini
 
  Documentation/devicetree/bindings/media/st-rc.txt |   18 +
  drivers/media/rc/Kconfig  |   10 +
  drivers/media/rc/Makefile |1 +
  drivers/media/rc/st_rc.c  |  371 
 +
  4 files changed, 400 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
  create mode 100644 drivers/media/rc/st_rc.c
 
 diff --git a/Documentation/devicetree/bindings/media/st-rc.txt 
 b/Documentation/devicetree/bindings/media/st-rc.txt
 new file mode 100644
 index 000..57f9ee8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/st-rc.txt
 @@ -0,0 +1,18 @@
 +Device-Tree bindings for ST IR and UHF receiver
 +
 +Required properties:
 +   - compatible: should be st,rc.

That rc should be made more specific, and it seems like this is a
subset of a larger block of IP (the ST COMMS IP block). Is this really a
standalone piece of hardware, or is it always in the larger comms block?

What's the full name of this unit as it appears in documentation?

 +   - st,uhfmode: boolean property to indicate if reception is in UHF.

That's not a very clear name. Is this a physical property of the device
(i.e. it's wired to either an IR receiver or a UHF receiver), or is this
a choice as to how it's used at runtime?

If it's fixed property of how the device is wired, it might make more
sense to have a string mode property that's either uhf or infared.

 +   - reg: base physical address of the controller and length of memory
 +   mapped  region.
 +   - interrupts: interrupt number to the cpu. The interrupt specifier
 +   format depends on the interrupt controller parent.
 +
 +Example node:
 +
 +   rc: rc@fe518000 {
 +   compatible  = st,rc;
 +   reg = 0xfe518000 0x234;
 +   interrupts  =  0 203 0;
 +   };
 +

[...]

 +++ b/drivers/media/rc/st_rc.c
 @@ -0,0 +1,371 @@
 +/*
 + * Copyright (C) 2013 STMicroelectronics Limited
 + * Author: Srinivas Kandagatla srinivas.kandaga...@st.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.
 + */
 +#include linux/kernel.h
 +#include linux/clk.h
 +#include linux/interrupt.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include media/rc-core.h
 +#include linux/pinctrl/consumer.h
 +
 +struct st_rc_device {
 +   struct device   *dev;
 +   int irq;
 +   int irq_wake;
 +   struct clk  *sys_clock;
 +   void*base;  /* Register base address */
 +   void*rx_base;/* RX Register base address 
 */
 +   struct rc_dev   *rdev;
 +   booloverclocking;
 +   int sample_mult;
 +   int sample_div;
 +   boolrxuhfmode;
 +};

[...]

 +static void st_rc_hardware_init(struct st_rc_device *dev)
 +{
 +   int baseclock, freqdiff;
 +   unsigned int rx_max_symbol_per = MAX_SYMB_TIME;
 +   unsigned int rx_sampling_freq_div;
 +
 +   clk_prepare_enable(dev-sys_clock);

This clock should be defined in the binding.

 +   baseclock = clk_get_rate(dev-sys_clock);
 +
 +   /* IRB input pins are inverted internally from high to low. */
 +   writel(1, dev-rx_base + IRB_RX_POLARITY_INV);
 +
 +   rx_sampling_freq_div = baseclock / IRB_SAMPLE_FREQ;
 +   writel(rx_sampling_freq_div, dev-base + IRB_SAMPLE_RATE_COMM);
 +
 +   freqdiff = baseclock - (rx_sampling_freq_div * IRB_SAMPLE_FREQ);
 +   if (freqdiff) { /* over clocking, workout the adjustment factors */
 +   dev-overclocking = 

[PATCH] [media] gspca-ov534: don't call sd_start() from sd_init()

[Antonio Ospite]

sd_start() operates on device controls but after the conversion to the
v4l2 control framework in commits 62bba5d and 1bd7d6a controls are
initialized in sd_init_controls() which is called _after_ sd_init():

The change fixes a NULL pointer dereference for Hercules Blog Webcam;
the problem is observable since 3.6:

  gspca_main: v2.14.0 registered
  gspca_main: ov534-2.14.0 probing 06f8:3002
  BUG: unable to handle kernel NULL pointer dereference at 0050
  IP: [a03c1b01] v4l2_ctrl_g_ctrl+0x11/0x60 [videodev]
  PGD 0
  Oops:  [#1] SMP
  Modules linked in: gspca_ov534(+) gspca_main videodev rfcomm bnep ppdev 
bluetooth binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek stir4200 irda 
crc_ccitt usblp snd_hda_intel snd_hda_codec snd_hwdep snd_pcm hid_generic 
snd_page_alloc snd_seq_midi snd_seq_midi_event usbhid snd_rawmidi snd_seq 
snd_seq_device snd_timer hid i915 snd psmouse drm_kms_helper serio_raw mei_me 
drm mei soundcore video i2c_algo_bit lpc_ich mac_hid coretemp lp parport 
firewire_ohci firewire_core crc_itu_t ahci libahci alx mdio r8169 mii [last 
unloaded: parport_pc]
  CPU: 3 PID: 4352 Comm: modprobe Not tainted 3.11.0-031100rc2-generic 
#201307211535
  Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77-DS3H, 
BIOS F9 09/19/2012
  task: 8801c20f9770 ti: 8801ceaa task.ti: 8801ceaa
  RIP: 0010:[a03c1b01]  [a03c1b01] 
v4l2_ctrl_g_ctrl+0x11/0x60 [videodev]
  RSP: 0018:8801ceaa1af8  EFLAGS: 00010292
  RAX: 0001 RBX:  RCX: 0001988b
  RDX: 0001988a RSI: a032745a RDI: 
  RBP: 8801ceaa1b28 R08: 00017380 R09: ea0008419d80
  R10: 81538f5a R11: 0002 R12: a03273dc
  R13: a03273dc R14:  R15: a03270a0
  FS:  7f72d564a740() GS:88021f38() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 0050 CR3: 0001bd1f CR4: 001407e0
  Stack:
   8801ceaa1b28 a0325cff 880101f4 8801ceb44000
   a03273dc 8801ceb44000 8801ceaa1b58 a032688e
   8801ceb44000 a03274f0 a03274f0 8801ceb44380
  Call Trace:
   [a0325cff] ? sccb_w_array+0x3f/0x80 [gspca_ov534]
   [a032688e] sd_start+0xce/0x2b0 [gspca_ov534]
   [a0326bf9] sd_init+0x189/0x1e8 [gspca_ov534]
   [a02a0c95] gspca_dev_probe2+0x285/0x410 [gspca_main]
   [a02a0e58] gspca_dev_probe+0x38/0x60 [gspca_main]
   [a0325081] sd_probe+0x21/0x30 [gspca_ov534]
   [8153c960] usb_probe_interface+0x1c0/0x2f0
   [8148758c] really_probe+0x6c/0x330
   [814879d7] driver_probe_device+0x47/0xa0
   [81487adb] __driver_attach+0xab/0xb0
   [81487a30] ? driver_probe_device+0xa0/0xa0
   [814857be] bus_for_each_dev+0x5e/0x90
   [8148714e] driver_attach+0x1e/0x20
   [81486bdc] bus_add_driver+0x10c/0x290
   [8148805d] driver_register+0x7d/0x160
   [8153b590] usb_register_driver+0xa0/0x160
   [a0067000] ? 0xa0066fff
   [a006701e] sd_driver_init+0x1e/0x1000 [gspca_ov534]
   [8100212a] do_one_initcall+0xfa/0x1b0
   [810578c3] ? set_memory_nx+0x43/0x50
   [81712e8d] do_init_module+0x80/0x1d1
   [810d2079] load_module+0x4c9/0x5f0
   [810cf7b0] ? add_kallsyms+0x210/0x210
   [810d2254] SyS_init_module+0xb4/0x100
   [817333ef] tracesys+0xe1/0xe6
  Code: a0 09 00 00 48 c7 c7 30 c3 3c a0 e8 7a 38 ca e0 eb cf 0f 1f 84 00 00 00 
00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 28 8b 47 50 83 e8 05 83 
f8 02 77 09 80 b8 20 8c 3c a0 00 74 1d 48
  RIP  [a03c1b01] v4l2_ctrl_g_ctrl+0x11/0x60 [videodev]
   RSP 8801ceaa1af8
  CR2: 0050
  ---[ end trace 6786f15abfd2ac90 ]---

Original bug report from:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173723/

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Tested-by: Yaroslav Zakharuk slav...@gmail.com
Cc: sta...@vger.kernel.org # 3.6+
---
 drivers/media/usb/gspca/ov534.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/gspca/ov534.c b/drivers/media/usb/gspca/ov534.c
index 2e28c81..03a33c4 100644
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1305,8 +1305,7 @@ static int sd_init(struct gspca_dev *gspca_dev)
ov534_set_led(gspca_dev, 1);
sccb_w_array(gspca_dev, sensor_init[sd-sensor].val,
sensor_init[sd-sensor].len);
-   if (sd-sensor == SENSOR_OV767x)
-   sd_start(gspca_dev);
+
sd_stopN(gspca_dev);
 /* set_frame_rate(gspca_dev);  */
 
-- 
1.8.4.rc2

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

Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

Op 12-08-13 17:43, Rob Clark schreef:
 On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 A fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.

 A driver must allocate a fence context for each execution ring that can
 run in parallel. The function for this takes an argument with how many
 contexts to allocate:
   + fence_context_alloc()

 A fence is transient, one-shot deal.  It is allocated and attached
 to one or more dma-buf's.  When the one that attached it is done, with
 the pending operation, it can signal the fence:
   + fence_signal()

 To have a rough approximation whether a fence is fired, call:
   + fence_is_signaled()

 The dma-buf-mgr handles tracking, and waiting on, the fences associated
 with a dma-buf.

 The one pending on the fence can add an async callback:
   + fence_add_callback()

 The callback can optionally be cancelled with:
   + fence_remove_callback()

 To wait synchronously, optionally with a timeout:
   + fence_wait()
   + fence_wait_timeout()

 A default software-only implementation is provided, which can be used
 by drivers attaching a fence to a buffer when they have no other means
 for hw sync.  But a memory backed fence is also envisioned, because it
 is common that GPU's can write to, or poll on some memory location for
 synchronization.  For example:

   fence = custom_get_fence(...);
   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
 dma_buf *fence_buf = fence-sync_buf;
 get_dma_buf(fence_buf);

 ... tell the hw the memory location to wait ...
 custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
   } else {
 /* fall-back to sw sync * /
 fence_add_callback(fence, my_cb);
   }

 On SoC platforms, if some other hw mechanism is provided for synchronizing
 between IP blocks, it could be supported as an alternate implementation
 with it's own fence ops in a similar way.

 enable_signaling callback is used to provide sw signaling in case a cpu
 waiter is requested or no compatible hardware signaling could be used.

 The intention is to provide a userspace interface (presumably via eventfd)
 later, to be used in conjunction with dma-buf's mmap support for sw access
 to buffers (or for userspace apps that would prefer to do their own
 synchronization).

 v1: Original
 v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
 that dma-fence didn't need to care about the sw-hw signaling path
 (it can be handled same as sw-sw case), and therefore the fence-ops
 can be simplified and more handled in the core.  So remove the signal,
 add_callback, cancel_callback, and wait ops, and replace with a simple
 enable_signaling() op which can be used to inform a fence supporting
 hw-hw signaling that one or more devices which do not support hw
 signaling are waiting (and therefore it should enable an irq or do
 whatever is necessary in order that the CPU is notified when the
 fence is passed).
 v3: Fix locking fail in attach_fence() and get_fence()
 v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
 we decided that we need to be able to attach one fence to N dma-buf's,
 so using the list_head in dma-fence struct would be problematic.
 v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
 v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
 comments
 about checking if fence fired or not. This is broken by design.
 waitqueue_active during destruction is now fatal, since the signaller
 should be holding a reference in enable_signalling until it signalled
 the fence. Pass the original dma_fence_cb along, and call __remove_wait
 in the dma_fence_callback handler, so that no cleanup needs to be
 performed.
 v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
 fence wasn't signaled yet, for example for hardware fences that may
 choose to signal blindly.
 v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
 header and fixed include mess. dma-fence.h now includes dma-buf.h
 All members are now initialized, so kmalloc can be used for
 allocating a dma-fence. More documentation added.
 v9: Change compiler bitfields to flags, change return type of
 enable_signaling to bool. Rework dma_fence_wait. Added
 dma_fence_is_signaled and dma_fence_wait_timeout.
 s/dma// and change exports to non GPL. Added fence_is_signaled and
 

[PATCH] fence: dma-buf cross-device synchronization (v13)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence-sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this should 

Re: [PATCH v5 01/13] [media] exynos5-is: Adding media device driver for exynos5

[Sylwester Nawrocki]

Hi,

Thanks for the update. I'd like to possibly queue it for 3.12
once the review comments are addressed and the DT maintainers
are OK with that.

W dniu 2013-08-14 06:46, Arun Kumar K pisze:

From: Shaik Ameer Basha shaik.am...@samsung.com

This patch adds support for media device for EXYNOS5 SoCs.
The current media device supports the following ips to connect
through the media controller framework.

* MIPI-CSIS
   Support interconnection(subdev interface) between devices

* FIMC-LITE
   Support capture interface from device(Sensor, MIPI-CSIS) to memory
   Support interconnection(subdev interface) between devices

* FIMC-IS
   Camera post-processing IP having multiple sub-nodes.

G-Scaler will be added later to the current media device.

The media device creates two kinds of pipelines for connecting
the above mentioned IPs.
The pipeline0 is uses Sensor, MIPI-CSIS and FIMC-LITE which captures
image data and dumps to memory.
Pipeline1 uses FIMC-IS components for doing post-processing
operations on the captured image and give scaled YUV output.

Pipeline0
   ++ +---+ +---+ ++
   | Sensor | -- | MIPI-CSIS | -- | FIMC-LITE | -- | Memory |
   ++ +---+ +---+ ++

Pipeline1
  ++  ++ +---+ +---+
  | Memory | --  |  ISP   | -- |SCC| -- |SCP|
  ++  ++ +---+ +---+

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
  .../devicetree/bindings/media/exynos5-mdev.txt |  130 +++
  drivers/media/platform/exynos5-is/exynos5-mdev.c   | 1218 
  drivers/media/platform/exynos5-is/exynos5-mdev.h   |  160 +++
  3 files changed, 1508 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/exynos5-mdev.txt
  create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c
  create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h

diff --git a/Documentation/devicetree/bindings/media/exynos5-mdev.txt 
b/Documentation/devicetree/bindings/media/exynos5-mdev.txt
new file mode 100644
index 000..007ce21
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-mdev.txt
@@ -0,0 +1,130 @@
+Samsung EXYNOS5 SoC Camera Subsystem
+
+
+The Exynos5 SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC-LITE,
+MIPI CSIS and FIMC-IS.
+
+The sub-subdevices are defined as child nodes of the common 'camera' node which


That statement is not true any more, the sub-devices are now referenced
by phandles.


+also includes common properties of the whole subsystem not really specific to
+any single sub-device, like common camera port pins or the CAMCLK clock outputs
+for external image sensors attached to an SoC.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible   : must be samsung,exynos5-fimc, simple-bus


s/exynos5/exynos5250. And simple-bus is not needed.


+- clocks   : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names  : must contain sclk_bayer entry



+- csis : list of phandles to the mipi-csis device nodes
+- fimc-lite: list of phandles to the fimc-lite device nodes
+- fimc-is  : phandle to the fimc-is device node


These properties should be prefixed with samsung,.


+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named default.
+
+'parallel-ports' node
+-
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A, camera B, MIPI-CSI2 and RGB bay inputs.


MIPI CSI-2 is a serial bus, it doesn't belong to the parallel-ports
node. Thus only 1,2,5 should be listed in this section. My apologies
if I wasn't clear enough in my previous comments.


+'reg' property in the port nodes specifies the input type:
+ 1 - parallel camport A
+ 2 - parallel camport B
+ 3 - serial MIPI CSI-2 port 0
+ 4 - serial MIPI CSI-2 port 1
+ 5 - RGB camera bay
+
+3, 4 are already described in samsung-mipi-csis.txt
+
+Image sensor nodes
+--
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
+using the common video interfaces bindings, defined in video-interfaces.txt.



+The implementation of this bindings requires clock-frequency property to be
+present in the sensor device nodes.


That statement is not valid any more. The clock is now handled by
the sensor drivers and if clock-frequency property is not present
a default value will be used. So you need to drop this sentence.


+Example:
+
+   aliases {
+   fimc-lite0 = fimc_lite_0
+   };
+
+   /* 

[PATCH 03/12] adv7604: pixel-clock depends on deep-color-mode

[Hans Verkuil]

From: Martin Bugge marbu...@cisco.com

The frequency calculation has to take deep-color mode into account.

While we're at it, also log the deep-color mode in log_status.

Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/adv7604.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d093092..6ffe25a 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -992,6 +992,11 @@ static inline bool no_lock_tmds(struct v4l2_subdev *sd)
return (io_read(sd, 0x6a)  0xe0) != 0xe0;
 }
 
+static inline bool is_hdmi(struct v4l2_subdev *sd)
+{
+   return hdmi_read(sd, 0x05)  0x80;
+}
+
 static inline bool no_lock_sspd(struct v4l2_subdev *sd)
 {
/* TODO channel 2 */
@@ -1244,12 +1249,21 @@ static int adv7604_query_dv_timings(struct v4l2_subdev 
*sd,
V4L2_DV_INTERLACED : V4L2_DV_PROGRESSIVE;
 
if (DIGITAL_INPUT) {
+   uint32_t freq;
+
timings-type = V4L2_DV_BT_656_1120;
 
bt-width = (hdmi_read(sd, 0x07)  0x0f) * 256 + hdmi_read(sd, 
0x08);
bt-height = (hdmi_read(sd, 0x09)  0x0f) * 256 + hdmi_read(sd, 
0x0a);
-   bt-pixelclock = (hdmi_read(sd, 0x06) * 100) +
+   freq = (hdmi_read(sd, 0x06) * 100) +
((hdmi_read(sd, 0x3b)  0x30)  4) * 25;
+   if (is_hdmi(sd)) {
+   /* adjust for deep color mode */
+   unsigned bits_per_channel = ((hdmi_read(sd, 0x0b)  
0x60)  4) + 8;
+
+   freq = freq * 8 / bits_per_channel;
+   }
+   bt-pixelclock = freq;
bt-hfrontporch = (hdmi_read(sd, 0x20)  0x03) * 256 +
hdmi_read(sd, 0x21);
bt-hsync = (hdmi_read(sd, 0x22)  0x03) * 256 +
@@ -1637,7 +1651,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
u8 avi_len;
u8 avi_ver;
 
-   if (!(hdmi_read(sd, 0x05)  0x80)) {
+   if (!is_hdmi(sd)) {
v4l2_info(sd, receive DVI-D signal (AVI infoframe not 
supported)\n);
return;
}
@@ -1698,6 +1712,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
RGB limited range (16-235),
RGB full range (0-255),
};
+   char *deep_color_mode_txt[4] = {
+   8-bits per channel,
+   10-bits per channel,
+   12-bits per channel,
+   16-bits per channel (not supported)
+   };
 
v4l2_info(sd, -Chip status-\n);
v4l2_info(sd, Chip power: %s\n, no_power(sd) ? off : on);
@@ -1756,7 +1776,9 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
v4l2_info(sd, -HDMI status-\n);
v4l2_info(sd, HDCP encrypted content: %s\n,
hdmi_read(sd, 0x05)  0x40 ? true : false);
-
+   if (is_hdmi(sd))
+   v4l2_info(sd, deep color mode: %s\n,
+   deep_color_mode_txt[(hdmi_read(sd, 
0x0b)  5)  0x3]);
print_avi_infoframe(sd);
}
 
-- 
1.8.3.2

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

[PATCH 02/12] adv7604: debounce format change notifications

[Hans Verkuil]

From: Mats Randgaard matra...@cisco.com

The bridge driver is only notified when the input status has changed
since the previous interrupt.

Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/adv7604.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 3ec7ec0..d093092 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -77,6 +77,7 @@ struct adv7604_state {
struct delayed_work delayed_work_enable_hotplug;
bool connector_hdmi;
bool restart_stdi_once;
+   u32 prev_input_status;
 
/* i2c clients */
struct i2c_client *i2c_avlink;
@@ -1535,6 +1536,7 @@ static int adv7604_isr(struct v4l2_subdev *sd, u32 
status, bool *handled)
 {
struct adv7604_state *state = to_state(sd);
u8 fmt_change, fmt_change_digital, tx_5v;
+   u32 input_status;
 
/* format change */
fmt_change = io_read(sd, 0x43)  0x98;
@@ -1545,9 +1547,18 @@ static int adv7604_isr(struct v4l2_subdev *sd, u32 
status, bool *handled)
io_write(sd, 0x6c, fmt_change_digital);
if (fmt_change || fmt_change_digital) {
v4l2_dbg(1, debug, sd,
-   %s: ADV7604_FMT_CHANGE, fmt_change = 0x%x, 
fmt_change_digital = 0x%x\n,
+   %s: fmt_change = 0x%x, fmt_change_digital = 0x%x\n,
__func__, fmt_change, fmt_change_digital);
-   v4l2_subdev_notify(sd, ADV7604_FMT_CHANGE, NULL);
+
+   adv7604_g_input_status(sd, input_status);
+   if (input_status != state-prev_input_status) {
+   v4l2_dbg(1, debug, sd,
+   %s: input_status = 0x%x, prev_input_status = 
0x%x\n,
+   __func__, input_status, 
state-prev_input_status);
+   state-prev_input_status = input_status;
+   v4l2_subdev_notify(sd, ADV7604_FMT_CHANGE, NULL);
+   }
+
if (handled)
*handled = true;
}
@@ -1953,6 +1964,10 @@ static int adv7604_probe(struct i2c_client *client,
return -ENOMEM;
}
 
+   /* initialize variables */
+   state-restart_stdi_once = true;
+   state-prev_input_status = ~0;
+
/* platform data */
if (!pdata) {
v4l_err(client, No platform data!\n);
@@ -2036,7 +2051,6 @@ static int adv7604_probe(struct i2c_client *client,
v4l2_err(sd, failed to create all i2c clients\n);
goto err_i2c;
}
-   state-restart_stdi_once = true;
 
/* work queues */
state-work_queues = create_singlethread_workqueue(client-name);
-- 
1.8.3.2

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

[PATCH 01/12] v4l2-dv-timings: fix CVT calculation

[Hans Verkuil]

From: Martin Bugge marbu...@cisco.com

This patch fixes two errors that caused incorrect format detections:

The first bug is in the calculation of the vertical backporch: the combined
period of vsync and backporch must *exceed* a certain minimum value, and not
be equal to it.

The second bug is a rounding error in the reduced blanking calculation:
expand the ideal_duty_cylce to be in parts per ten thousand to avoid
rounding errors.

Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/v4l2-dv-timings.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index f20b316..72cf224 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -286,14 +286,14 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned 
hfreq, unsigned vsync,
/* Vertical */
if (reduced_blanking) {
v_fp = CVT_RB_V_FPORCH;
-   v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+   v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 199) / 100;
v_bp -= vsync + v_fp;
 
if (v_bp  CVT_RB_MIN_V_BPORCH)
v_bp = CVT_RB_MIN_V_BPORCH;
} else {
v_fp = CVT_MIN_V_PORCH_RND;
-   v_bp = (CVT_MIN_VSYNC_BP * hfreq + 99) / 100 - vsync;
+   v_bp = (CVT_MIN_VSYNC_BP * hfreq + 199) / 100 - vsync;
 
if (v_bp  CVT_MIN_V_BPORCH)
v_bp = CVT_MIN_V_BPORCH;
@@ -337,17 +337,16 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned 
hfreq, unsigned vsync,
 
frame_width = image_width + CVT_RB_H_BLANK;
} else {
+   unsigned ideal_duty_cycle_per_myriad =
+   100 * CVT_C_PRIME - (CVT_M_PRIME * 10) / hfreq;
int h_blank;
-   unsigned ideal_duty_cycle = CVT_C_PRIME - (CVT_M_PRIME * 1000) 
/ hfreq;
 
-   h_blank = (image_width * ideal_duty_cycle + (100 - 
ideal_duty_cycle) / 2) /
-   (100 - ideal_duty_cycle);
-   h_blank = h_blank - h_blank % (2 * CVT_CELL_GRAN);
+   if (ideal_duty_cycle_per_myriad  2000)
+   ideal_duty_cycle_per_myriad = 2000;
 
-   if (h_blank * 100 / image_width  20) {
-   h_blank = image_width / 5;
-   h_blank = (h_blank + 0x7)  ~0x7;
-   }
+   h_blank = image_width * ideal_duty_cycle_per_myriad /
+   (1 - ideal_duty_cycle_per_myriad);
+   h_blank = (h_blank / (2 * CVT_CELL_GRAN)) * 2 * CVT_CELL_GRAN;
 
pix_clk = (image_width + h_blank) * hfreq;
pix_clk = (pix_clk / CVT_PXL_CLK_GRAN) * CVT_PXL_CLK_GRAN;
-- 
1.8.3.2

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

[PATCH 00/12] dv-timings/adv7604/ad9389b fixes

[Hans Verkuil]

This patch series builds on top of the for-v3.12 pull request:

http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/67690

It applies a bunch of fixes from Cisco's internal tree and it adds the
v4l2_print_dv_timings helper function.

Regards,

Hans

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

[PATCH 09/12] ad9389b: change initial register configuration in ad9389b_setup()

[Hans Verkuil]

From: Mats Randgaard matra...@cisco.com

- register 0x17: CSC scaling factor was set to +/- 2.0. This register
  is set by ad9389b_csc_conversion_mode() to the right value.
- register 0x3b: bits for pixel repetition and CSC was set to zero,
  but that is the default value.

Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/ad9389b.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index d78fd3d..92cdb25 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -894,11 +894,9 @@ static void ad9389b_setup(struct v4l2_subdev *sd)
ad9389b_wr_and_or(sd, 0x15, 0xf1, 0x0);
/* Output format: RGB 4:4:4 */
ad9389b_wr_and_or(sd, 0x16, 0x3f, 0x0);
-   /* CSC fixed point: +/-2, 1st order interpolation 4:2:2 - 4:4:4 up
-  conversion, Aspect ratio: 16:9 */
-   ad9389b_wr_and_or(sd, 0x17, 0xe1, 0x0e);
-   /* Disable pixel repetition and CSC */
-   ad9389b_wr_and_or(sd, 0x3b, 0x9e, 0x0);
+   /* 1st order interpolation 4:2:2 - 4:4:4 up conversion,
+  Aspect ratio: 16:9 */
+   ad9389b_wr_and_or(sd, 0x17, 0xf9, 0x06);
/* Output format: RGB 4:4:4, Active Format Information is valid. */
ad9389b_wr_and_or(sd, 0x45, 0xc7, 0x08);
/* Underscanned */
-- 
1.8.3.2

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

[PATCH 08/12] adv7604: corrected edid crc-calculation

[Hans Verkuil]

From: Martin Bugge marbu...@cisco.com

Signed-off-by: Martin Bugge marbu...@cisco.com
Reviewed-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/ad9389b.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 545aabb..d78fd3d 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -983,12 +983,12 @@ static void ad9389b_check_monitor_present_status(struct 
v4l2_subdev *sd)
 
 static bool edid_block_verify_crc(u8 *edid_block)
 {
-   int i;
u8 sum = 0;
+   int i;
 
-   for (i = 0; i  127; i++)
-   sum += *(edid_block + i);
-   return ((255 - sum + 1) == edid_block[127]);
+   for (i = 0; i  128; i++)
+   sum += edid_block[i];
+   return sum == 0;
 }
 
 static bool edid_segment_verify_crc(struct v4l2_subdev *sd, u32 segment)
-- 
1.8.3.2

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

[PATCH 10/12] v4l2-dv-timings: add v4l2_print_dv_timings helper

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Drivers often have to log the contents of a dv_timings struct. Adding
this helper will make it easier for drivers to do so.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/v4l2-dv-timings.c | 49 +++
 include/media/v4l2-dv-timings.h   |  9 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 72cf224..917e58c 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -223,6 +223,55 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
 }
 EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
 
+void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
+  const struct v4l2_dv_timings *t, bool detailed)
+{
+   const struct v4l2_bt_timings *bt = t-bt;
+   u32 htot, vtot;
+
+   if (t-type != V4L2_DV_BT_656_1120)
+   return;
+
+   htot = V4L2_DV_BT_FRAME_WIDTH(bt);
+   vtot = V4L2_DV_BT_FRAME_HEIGHT(bt);
+
+   if (prefix == NULL)
+   prefix = ;
+
+   pr_info(%s: %s%ux%u%s%u (%ux%u)\n, dev_prefix, prefix,
+   bt-width, bt-height, bt-interlaced ? i : p,
+   (htot * vtot)  0 ? ((u32)bt-pixelclock / (htot * vtot)) : 0,
+   htot, vtot);
+
+   if (!detailed)
+   return;
+
+   pr_info(%s: horizontal: fp = %u, %ssync = %u, bp = %u\n,
+   dev_prefix, bt-hfrontporch,
+   (bt-polarities  V4L2_DV_HSYNC_POS_POL) ? + : -,
+   bt-hsync, bt-hbackporch);
+   pr_info(%s: vertical: fp = %u, %ssync = %u, bp = %u\n,
+   dev_prefix, bt-vfrontporch,
+   (bt-polarities  V4L2_DV_VSYNC_POS_POL) ? + : -,
+   bt-vsync, bt-vbackporch);
+   pr_info(%s: pixelclock: %llu\n, dev_prefix, bt-pixelclock);
+   pr_info(%s: flags (0x%x):%s%s%s%s\n, dev_prefix, bt-flags,
+   (bt-flags  V4L2_DV_FL_REDUCED_BLANKING) ?
+REDUCED_BLANKING : ,
+   (bt-flags  V4L2_DV_FL_CAN_REDUCE_FPS) ?
+CAN_REDUCE_FPS : ,
+   (bt-flags  V4L2_DV_FL_REDUCED_FPS) ?
+REDUCED_FPS : ,
+   (bt-flags  V4L2_DV_FL_HALF_LINE) ?
+HALF_LINE : );
+   pr_info(%s: standards (0x%x):%s%s%s%s\n, dev_prefix, bt-standards,
+   (bt-standards  V4L2_DV_BT_STD_CEA861) ?   CEA : ,
+   (bt-standards  V4L2_DV_BT_STD_DMT) ?   DMT : ,
+   (bt-standards  V4L2_DV_BT_STD_CVT) ?   CVT : ,
+   (bt-standards  V4L2_DV_BT_STD_GTF) ?   GTF : );
+}
+EXPORT_SYMBOL_GPL(v4l2_print_dv_timings);
+
 /*
  * CVT defines
  * Based on Coordinated Video Timings Standard
diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 4c7bb54..696e5c2 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -76,6 +76,15 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings 
*measured,
  const struct v4l2_dv_timings *standard,
  unsigned pclock_delta);
 
+/** v4l2_print_dv_timings() - log the contents of a dv_timings struct
+  * @dev_prefix:device prefix for each log line.
+  * @prefix:   additional prefix for each log line, may be NULL.
+  * @t:the timings data.
+  * @detailed: if true, give a detailed log.
+  */
+void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
+  const struct v4l2_dv_timings *t, bool detailed);
+
 /** v4l2_detect_cvt - detect if the given timings follow the CVT standard
  * @frame_height - the total height of the frame (including blanking) in lines.
  * @hfreq - the horizontal frequency in Hz.
-- 
1.8.3.2

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

[PATCH 04/12] adv7604: improve log_status for HDMI/DVI-D signals

[Hans Verkuil]

From: Mats Randgaard matra...@cisco.com

Don't log if there is no signal.

If there is a signal, then also log HDCP and audio status.

Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/adv7604.c | 44 +++-
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 6ffe25a..34fcdf3 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1758,6 +1758,9 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
adv7604_print_timings(sd, timings, Detected format:, true);
adv7604_print_timings(sd, state-timings, Configured format:, true);
 
+   if (no_signal(sd))
+   return 0;
+
v4l2_info(sd, -Color space-\n);
v4l2_info(sd, RGB quantization range ctrl: %s\n,

rgb_quantization_range_txt[state-rgb_quantization_range]);
@@ -1767,18 +1770,41 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
(reg_io_0x02  0x02) ? RGB : YCbCr,
(reg_io_0x02  0x04) ? (16-235) : (0-255),
((reg_io_0x02  0x04) ^ (reg_io_0x02  0x01)) ?
-   enabled : disabled);
+   enabled : disabled);
v4l2_info(sd, Color space conversion: %s\n,
csc_coeff_sel_rb[cp_read(sd, 0xfc)  4]);
 
-   /* Digital video */
-   if (DIGITAL_INPUT) {
-   v4l2_info(sd, -HDMI status-\n);
-   v4l2_info(sd, HDCP encrypted content: %s\n,
-   hdmi_read(sd, 0x05)  0x40 ? true : false);
-   if (is_hdmi(sd))
-   v4l2_info(sd, deep color mode: %s\n,
-   deep_color_mode_txt[(hdmi_read(sd, 
0x0b)  5)  0x3]);
+   if (!DIGITAL_INPUT)
+   return 0;
+
+   v4l2_info(sd, -%s status-\n, is_hdmi(sd) ? HDMI : DVI-D);
+   v4l2_info(sd, HDCP encrypted content: %s\n, (hdmi_read(sd, 0x05)  
0x40) ? true : false);
+   v4l2_info(sd, HDCP keys read: %s%s\n,
+   (hdmi_read(sd, 0x04)  0x20) ? yes : no,
+   (hdmi_read(sd, 0x04)  0x10) ? ERROR : );
+   if (!is_hdmi(sd)) {
+   bool audio_pll_locked = hdmi_read(sd, 0x04)  0x01;
+   bool audio_sample_packet_detect = hdmi_read(sd, 0x18)  0x01;
+   bool audio_mute = io_read(sd, 0x65)  0x40;
+
+   v4l2_info(sd, Audio: pll %s, samples %s, %s\n,
+   audio_pll_locked ? locked : not locked,
+   audio_sample_packet_detect ? detected : not 
detected,
+   audio_mute ? muted : enabled);
+   if (audio_pll_locked  audio_sample_packet_detect) {
+   v4l2_info(sd, Audio format: %s\n,
+   (hdmi_read(sd, 0x07)  0x20) ? 
multi-channel : stereo);
+   }
+   v4l2_info(sd, Audio CTS: %u\n, (hdmi_read(sd, 0x5b)  12) +
+   (hdmi_read(sd, 0x5c)  8) +
+   (hdmi_read(sd, 0x5d)  0xf0));
+   v4l2_info(sd, Audio N: %u\n, ((hdmi_read(sd, 0x5d)  0x0f)  
16) +
+   (hdmi_read(sd, 0x5e)  8) +
+   hdmi_read(sd, 0x5f));
+   v4l2_info(sd, AV Mute: %s\n, (hdmi_read(sd, 0x04)  0x40) ? 
on : off);
+
+   v4l2_info(sd, Deep color mode: %s\n, 
deep_color_mode_txt[(hdmi_read(sd, 0x0b)  0x60)  5]);
+
print_avi_infoframe(sd);
}
 
-- 
1.8.3.2

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

[PATCH 07/12] ad9389b: trigger edid re-read by power-cycle chip

[Hans Verkuil]

From: Martin Bugge marbu...@cisco.com

Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/ad9389b.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 52384e8..545aabb 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -855,8 +855,10 @@ static void ad9389b_edid_handler(struct work_struct *work)
 * (DVI connectors are particularly prone to this problem). */
if (state-edid.read_retries) {
state-edid.read_retries--;
-   /* EDID read failed, trigger a retry */
-   ad9389b_wr(sd, 0xc9, 0xf);
+   v4l2_dbg(1, debug, sd, %s: edid read failed\n, 
__func__);
+   state-have_monitor = false;
+   ad9389b_s_power(sd, false);
+   ad9389b_s_power(sd, true);
queue_delayed_work(state-work_queue,
state-edid_handler, EDID_DELAY);
return;
@@ -1019,7 +1021,6 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev 
*sd)
segment = ad9389b_rd(sd, 0xc4);
if (segment = EDID_MAX_SEGM) {
v4l2_err(sd, edid segment number too big\n);
-   state-have_monitor = false;
return false;
}
v4l2_dbg(1, debug, sd, %s: got segment %d\n, __func__, segment);
-- 
1.8.3.2

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

[PATCH 11/12] ad9389b/adv7604/ths8200: use new v4l2_print_dv_timings helper.

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

These three drivers all have code to log the dv_timings contents. Replace
that code with the new helper function.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/ad9389b.c | 17 +++--
 drivers/media/i2c/adv7604.c | 61 ++---
 drivers/media/i2c/ths8200.c | 38 ++--
 3 files changed, 14 insertions(+), 102 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 92cdb25..1c6d352 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -443,20 +443,11 @@ static int ad9389b_log_status(struct v4l2_subdev *sd)
vic_detect, vic_sent);
}
}
-   if (state-dv_timings.type == V4L2_DV_BT_656_1120) {
-   struct v4l2_bt_timings *bt = bt = state-dv_timings.bt;
-   u32 frame_width = V4L2_DV_BT_FRAME_WIDTH(bt);
-   u32 frame_height = V4L2_DV_BT_FRAME_HEIGHT(bt);
-   u32 frame_size = frame_width * frame_height;
-
-   v4l2_info(sd, timings: %ux%u%s%u (%ux%u). Pix freq. = %u Hz. 
Polarities = 0x%x\n,
-   bt-width, bt-height, bt-interlaced ? i : p,
-   frame_size  0 ?  (unsigned)bt-pixelclock / frame_size 
: 0,
-   frame_width, frame_height,
-   (unsigned)bt-pixelclock, bt-polarities);
-   } else {
+   if (state-dv_timings.type == V4L2_DV_BT_656_1120)
+   v4l2_print_dv_timings(sd-name, timings: ,
+   state-dv_timings, false);
+   else
v4l2_info(sd, no timings set\n);
-   }
return 0;
 }
 
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e732c9b..ba8602c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1051,53 +1051,6 @@ static int adv7604_g_input_status(struct v4l2_subdev 
*sd, u32 *status)
 
 /* --- */
 
-static void adv7604_print_timings(struct v4l2_subdev *sd,
- struct v4l2_dv_timings *timings,
- const char *txt, bool detailed)
-{
-   struct v4l2_bt_timings *bt = timings-bt;
-   u32 htot, vtot;
-
-   if (timings-type != V4L2_DV_BT_656_1120)
-   return;
-
-   htot = htotal(bt);
-   vtot = vtotal(bt);
-
-   v4l2_info(sd, %s %dx%d%s%d (%dx%d),
-   txt, bt-width, bt-height, bt-interlaced ? i : p,
-   (htot * vtot)  0 ? ((u32)bt-pixelclock /
-   (htot * vtot)) : 0,
-   htot, vtot);
-
-   if (!detailed)
-   return;
-
-   v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
-   bt-hfrontporch,
-   (bt-polarities  V4L2_DV_HSYNC_POS_POL) ? + : -,
-   bt-hsync, bt-hbackporch);
-   v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
-   bt-vfrontporch,
-   (bt-polarities  V4L2_DV_VSYNC_POS_POL) ? + : -,
-   bt-vsync, bt-vbackporch);
-   v4l2_info(sd, pixelclock: %lld\n, bt-pixelclock);
-   v4l2_info(sd, flags (0x%x):%s%s%s%s\n, bt-flags,
-   (bt-flags  V4L2_DV_FL_REDUCED_BLANKING) ?
-Reduced blanking, : ,
-   (bt-flags  V4L2_DV_FL_CAN_REDUCE_FPS) ?
-Can reduce FPS, : ,
-   (bt-flags  V4L2_DV_FL_REDUCED_FPS) ?
-Reduced FPS, : ,
-   (bt-flags  V4L2_DV_FL_HALF_LINE) ?
-Half line, : );
-   v4l2_info(sd, standards (0x%x):%s%s%s%s\n, bt-standards,
-   (bt-standards  V4L2_DV_BT_STD_CEA861) ?   CEA, : ,
-   (bt-standards  V4L2_DV_BT_STD_DMT) ?   DMT, : ,
-   (bt-standards  V4L2_DV_BT_STD_CVT) ?   CVT : ,
-   (bt-standards  V4L2_DV_BT_STD_GTF) ?   GTF : );
-}
-
 struct stdi_readback {
u16 bl, lcf, lcvs;
u8 hs_pol, vs_pol;
@@ -1360,8 +1313,8 @@ found:
}
 
if (debug  1)
-   adv7604_print_timings(sd, timings,
-   adv7604_query_dv_timings:, true);
+   v4l2_print_dv_timings(sd-name, adv7604_query_dv_timings: ,
+ timings, true);
 
return 0;
 }
@@ -1403,8 +1356,8 @@ static int adv7604_s_dv_timings(struct v4l2_subdev *sd,
 
 
if (debug  1)
-   adv7604_print_timings(sd, timings,
-   adv7604_s_dv_timings:, true);
+   v4l2_print_dv_timings(sd-name, adv7604_s_dv_timings: ,
+ timings, true);
return 0;
 }
 
@@ -1770,8 

[PATCH 06/12] ad9389b: no monitor if EDID is wrong

[Hans Verkuil]

From: Mats Randgaard matra...@cisco.com

state-have_monitor is set to false if the EDID that is read from
the monitor has too many segments or wrong CRC.

Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/ad9389b.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 7e68d8f..52384e8 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -1019,6 +1019,7 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev 
*sd)
segment = ad9389b_rd(sd, 0xc4);
if (segment = EDID_MAX_SEGM) {
v4l2_err(sd, edid segment number too big\n);
+   state-have_monitor = false;
return false;
}
v4l2_dbg(1, debug, sd, %s: got segment %d\n, __func__, segment);
@@ -1032,6 +1033,8 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev 
*sd)
}
if (!edid_segment_verify_crc(sd, segment)) {
/* edid crc error, force reread of edid segment */
+   v4l2_err(sd, %s: edid crc error\n, __func__);
+   state-have_monitor = false;
ad9389b_s_power(sd, false);
ad9389b_s_power(sd, true);
return false;
-- 
1.8.3.2

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

[PATCH 05/12] adv7604: print flags and standards in timing information

[Hans Verkuil]

From: Mats Randgaard matra...@cisco.com

Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/adv7604.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 34fcdf3..e732c9b 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1052,7 +1052,8 @@ static int adv7604_g_input_status(struct v4l2_subdev *sd, 
u32 *status)
 /* --- */
 
 static void adv7604_print_timings(struct v4l2_subdev *sd,
-   struct v4l2_dv_timings *timings, const char *txt, bool detailed)
+ struct v4l2_dv_timings *timings,
+ const char *txt, bool detailed)
 {
struct v4l2_bt_timings *bt = timings-bt;
u32 htot, vtot;
@@ -1069,18 +1070,32 @@ static void adv7604_print_timings(struct v4l2_subdev 
*sd,
(htot * vtot)) : 0,
htot, vtot);
 
-   if (detailed) {
-   v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
-   bt-hfrontporch,
-   (bt-polarities  V4L2_DV_HSYNC_POS_POL) ? + 
: -,
-   bt-hsync, bt-hbackporch);
-   v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
-   bt-vfrontporch,
-   (bt-polarities  V4L2_DV_VSYNC_POS_POL) ? + 
: -,
-   bt-vsync, bt-vbackporch);
-   v4l2_info(sd, pixelclock: %lld, flags: 0x%x, standards: 
0x%x\n,
-   bt-pixelclock, bt-flags, bt-standards);
-   }
+   if (!detailed)
+   return;
+
+   v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
+   bt-hfrontporch,
+   (bt-polarities  V4L2_DV_HSYNC_POS_POL) ? + : -,
+   bt-hsync, bt-hbackporch);
+   v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
+   bt-vfrontporch,
+   (bt-polarities  V4L2_DV_VSYNC_POS_POL) ? + : -,
+   bt-vsync, bt-vbackporch);
+   v4l2_info(sd, pixelclock: %lld\n, bt-pixelclock);
+   v4l2_info(sd, flags (0x%x):%s%s%s%s\n, bt-flags,
+   (bt-flags  V4L2_DV_FL_REDUCED_BLANKING) ?
+Reduced blanking, : ,
+   (bt-flags  V4L2_DV_FL_CAN_REDUCE_FPS) ?
+Can reduce FPS, : ,
+   (bt-flags  V4L2_DV_FL_REDUCED_FPS) ?
+Reduced FPS, : ,
+   (bt-flags  V4L2_DV_FL_HALF_LINE) ?
+Half line, : );
+   v4l2_info(sd, standards (0x%x):%s%s%s%s\n, bt-standards,
+   (bt-standards  V4L2_DV_BT_STD_CEA861) ?   CEA, : ,
+   (bt-standards  V4L2_DV_BT_STD_DMT) ?   DMT, : ,
+   (bt-standards  V4L2_DV_BT_STD_CVT) ?   CVT : ,
+   (bt-standards  V4L2_DV_BT_STD_GTF) ?   GTF : );
 }
 
 struct stdi_readback {
-- 
1.8.3.2

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

[PATCH 12/12] v4l2-dv-timings: rename v4l_match_dv_timings to v4l2_match_dv_timings

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

It's the only function in v4l2-dv-timings.c with the v4l prefix instead
of v4l2. Make it consistent with the other functions.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/i2c/adv7604.c   |  4 ++--
 drivers/media/platform/s5p-tv/hdmi_drv.c  |  2 +-
 drivers/media/usb/hdpvr/hdpvr-video.c |  2 +-
 drivers/media/v4l2-core/v4l2-dv-timings.c | 12 ++--
 include/media/v4l2-dv-timings.h   |  8 
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index ba8602c..a1a9d1e 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -763,7 +763,7 @@ static int find_and_set_predefined_video_timings(struct 
v4l2_subdev *sd,
int i;
 
for (i = 0; predef_vid_timings[i].timings.bt.width; i++) {
-   if (!v4l_match_dv_timings(timings, 
predef_vid_timings[i].timings,
+   if (!v4l2_match_dv_timings(timings, 
predef_vid_timings[i].timings,
DIGITAL_INPUT ? 25 : 100))
continue;
io_write(sd, 0x00, predef_vid_timings[i].vid_std); /* video std 
*/
@@ -1183,7 +1183,7 @@ static void 
adv7604_fill_optional_dv_timings_fields(struct v4l2_subdev *sd,
int i;
 
for (i = 0; adv7604_timings[i].bt.width; i++) {
-   if (v4l_match_dv_timings(timings, adv7604_timings[i],
+   if (v4l2_match_dv_timings(timings, adv7604_timings[i],
DIGITAL_INPUT ? 25 : 100)) {
*timings = adv7604_timings[i];
break;
diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c 
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 1b34c36..4ad9374 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -625,7 +625,7 @@ static int hdmi_s_dv_timings(struct v4l2_subdev *sd,
int i;
 
for (i = 0; i  ARRAY_SIZE(hdmi_timings); i++)
-   if (v4l_match_dv_timings(hdmi_timings[i].dv_timings,
+   if (v4l2_match_dv_timings(hdmi_timings[i].dv_timings,
timings, 0))
break;
if (i == ARRAY_SIZE(hdmi_timings)) {
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
b/drivers/media/usb/hdpvr/hdpvr-video.c
index e68245a..0500c417 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -642,7 +642,7 @@ static int vidioc_s_dv_timings(struct file *file, void *_fh,
if (dev-status != STATUS_IDLE)
return -EBUSY;
for (i = 0; i  ARRAY_SIZE(hdpvr_dv_timings); i++)
-   if (v4l_match_dv_timings(timings, hdpvr_dv_timings + i, 0))
+   if (v4l2_match_dv_timings(timings, hdpvr_dv_timings + i, 0))
break;
if (i == ARRAY_SIZE(hdpvr_dv_timings))
return -EINVAL;
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 917e58c..1a9d393 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -181,7 +181,7 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
 
for (i = 0; i  ARRAY_SIZE(timings); i++) {
if (v4l2_dv_valid_timings(timings + i, cap) 
-   v4l_match_dv_timings(t, timings + i, pclock_delta)) {
+   v4l2_match_dv_timings(t, timings + i, pclock_delta)) {
*t = timings[i];
return true;
}
@@ -191,16 +191,16 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
 EXPORT_SYMBOL_GPL(v4l2_find_dv_timings_cap);
 
 /**
- * v4l_match_dv_timings - check if two timings match
+ * v4l2_match_dv_timings - check if two timings match
  * @t1 - compare this v4l2_dv_timings struct...
  * @t2 - with this struct.
  * @pclock_delta - the allowed pixelclock deviation.
  *
  * Compare t1 with t2 with a given margin of error for the pixelclock.
  */
-bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
- const struct v4l2_dv_timings *t2,
- unsigned pclock_delta)
+bool v4l2_match_dv_timings(const struct v4l2_dv_timings *t1,
+  const struct v4l2_dv_timings *t2,
+  unsigned pclock_delta)
 {
if (t1-type != t2-type || t1-type != V4L2_DV_BT_656_1120)
return false;
@@ -221,7 +221,7 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
return true;
return false;
 }
-EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+EXPORT_SYMBOL_GPL(v4l2_match_dv_timings);
 
 void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
   const struct v4l2_dv_timings *t, bool detailed)
diff --git 

Re: [PATCH] dma-buf: Expose buffer size to userspace

[Daniel Vetter]

On Mon, Aug 05, 2013 at 04:22:00PM +1000, Christopher James Halse Rogers wrote:
 Each dma-buf has an associated size and it's reasonable for userspace
 to want to know what it is.
 
 Since userspace already has an fd, expose the size using the
 size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
 idiom.
 
 Signed-off-by: Christopher James Halse Rogers 
 christopher.halse.rog...@canonical.com

Yeah, loosk good to me and rather useful, so (with the dma-buf docs
improved as suggested below):

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

I've also written some small prime tests in igt, so also:

Tested-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---
 
 I've run into a point in the radeon DRM userspace where I need the
 size of a dma-buf. I could add a radeon-specific mechanism to get that,
 but this seems like something that would be more generally useful.
 
 I'm not entirely sure about supporting both SEEK_END and SEEK_CUR; this
 is somewhat of an abuse of lseek, as seeking obviously doesn't make sense.
 It's the obivous idiom for getting the size of what's on the other end of a
 file descriptor, though.
 
 I didn't notice anywhere to document this; Documentation/dma-buf-api didn't
 seem like the right place. Is there somewhere I've overlooked?

I think adding a section about various other userspace interfaces exposed
below the mmap support section would be good. Feel free to squash in the
belo diff for v2.

Cheers, Daniel

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0b23261..b3a8aa2 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).
 
+Other Interfaces Exposed to Userspace on the dma-buf FD
+--
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+  with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allowe
+  the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+  llseek operation will report -EINVAL.
+
+  If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+  cases. Userspace can use this to detect support for discovering the dma-buf
+  size using llsee.
+
 Miscellaneous notes
 ---
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] fence: dma-buf cross-device synchronization (v14)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence-sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this should 

Re: [PATCH] fence: dma-buf cross-device synchronization (v13)

[Marcin Ślusarz]

2013/8/15 Maarten Lankhorst maarten.lankho...@canonical.com:
 A fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.

 A driver must allocate a fence context for each execution ring that can
 run in parallel. The function for this takes an argument with how many
 contexts to allocate:
   + fence_context_alloc()

 A fence is transient, one-shot deal.  It is allocated and attached
 to one or more dma-buf's.  When the one that attached it is done, with
 the pending operation, it can signal the fence:
   + fence_signal()

 To have a rough approximation whether a fence is fired, call:
   + fence_is_signaled()

 The dma-buf-mgr handles tracking, and waiting on, the fences associated
 with a dma-buf.

 The one pending on the fence can add an async callback:
   + fence_add_callback()

 The callback can optionally be cancelled with:
   + fence_remove_callback()

 To wait synchronously, optionally with a timeout:
   + fence_wait()
   + fence_wait_timeout()

 A default software-only implementation is provided, which can be used
 by drivers attaching a fence to a buffer when they have no other means
 for hw sync.  But a memory backed fence is also envisioned, because it
 is common that GPU's can write to, or poll on some memory location for
 synchronization.  For example:

   fence = custom_get_fence(...);
   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
 dma_buf *fence_buf = fence-sync_buf;
 get_dma_buf(fence_buf);

 ... tell the hw the memory location to wait ...
 custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
   } else {
 /* fall-back to sw sync * /
 fence_add_callback(fence, my_cb);
   }

 On SoC platforms, if some other hw mechanism is provided for synchronizing
 between IP blocks, it could be supported as an alternate implementation
 with it's own fence ops in a similar way.

 enable_signaling callback is used to provide sw signaling in case a cpu
 waiter is requested or no compatible hardware signaling could be used.

 The intention is to provide a userspace interface (presumably via eventfd)
 later, to be used in conjunction with dma-buf's mmap support for sw access
 to buffers (or for userspace apps that would prefer to do their own
 synchronization).

 v1: Original
 v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
 that dma-fence didn't need to care about the sw-hw signaling path
 (it can be handled same as sw-sw case), and therefore the fence-ops
 can be simplified and more handled in the core.  So remove the signal,
 add_callback, cancel_callback, and wait ops, and replace with a simple
 enable_signaling() op which can be used to inform a fence supporting
 hw-hw signaling that one or more devices which do not support hw
 signaling are waiting (and therefore it should enable an irq or do
 whatever is necessary in order that the CPU is notified when the
 fence is passed).
 v3: Fix locking fail in attach_fence() and get_fence()
 v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
 we decided that we need to be able to attach one fence to N dma-buf's,
 so using the list_head in dma-fence struct would be problematic.
 v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
 v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
 comments
 about checking if fence fired or not. This is broken by design.
 waitqueue_active during destruction is now fatal, since the signaller
 should be holding a reference in enable_signalling until it signalled
 the fence. Pass the original dma_fence_cb along, and call __remove_wait
 in the dma_fence_callback handler, so that no cleanup needs to be
 performed.
 v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
 fence wasn't signaled yet, for example for hardware fences that may
 choose to signal blindly.
 v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
 header and fixed include mess. dma-fence.h now includes dma-buf.h
 All members are now initialized, so kmalloc can be used for
 allocating a dma-fence. More documentation added.
 v9: Change compiler bitfields to flags, change return type of
 enable_signaling to bool. Rework dma_fence_wait. Added
 dma_fence_is_signaled and dma_fence_wait_timeout.
 s/dma// and change exports to non GPL. Added fence_is_signaled and
 fence_enable_sw_signaling calls, add ability to override default
 wait operation.
 v10: 

Re: [PATCH] media: st-rc: Add ST remote control driver

[Srinivas KANDAGATLA]

Thanks Mark for your comments.

On 15/08/13 09:49, Mark Rutland wrote:
 On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
 From: Srinivas Kandagatla srinivas.kandaga...@st.com

 This patch adds support to ST RC driver, which is basically a IR/UHF
 receiver and transmitter. This IP is common across all the ST parts for
 settop box platforms. IRB is embedded in ST COMMS IP block.
 It supports both Rx  Tx functionality.

 In this driver adds only Rx functionality via LIRC codec.
 
 Is there anything that additionally needs to be in the dt to support Tx
 functionality?

We need an additional boolean property for TX enable.

+

Two more configurable parameters for TX sub-carrier frequency and
duty-cycle. By default driver can set the sub carrier frequency to be
38Khz and duty cycle as 50%.
However I don't have strong use case to make these configurable.

So, I think just one boolean property to enable tx should be Ok.

 

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
 ---
 Hi Chehab,

 This is a very simple rc driver for IRB controller found in STi ARM CA9 SOCs.
 STi ARM SOC support went in 3.11 recently.
 This driver is a raw driver which feeds data to lirc codec for the user lircd
 to decode the keys.

 This patch is based on git://linuxtv.org/media_tree.git master branch.

 Comments?

 Thanks,
 srini

  Documentation/devicetree/bindings/media/st-rc.txt |   18 +
  drivers/media/rc/Kconfig  |   10 +
  drivers/media/rc/Makefile |1 +
  drivers/media/rc/st_rc.c  |  371 
 +
  4 files changed, 400 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
  create mode 100644 drivers/media/rc/st_rc.c

 diff --git a/Documentation/devicetree/bindings/media/st-rc.txt 
 b/Documentation/devicetree/bindings/media/st-rc.txt
 new file mode 100644
 index 000..57f9ee8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/st-rc.txt
 @@ -0,0 +1,18 @@
 +Device-Tree bindings for ST IR and UHF receiver
 +
 +Required properties:
 +   - compatible: should be st,rc.
 
 That rc should be made more specific, and it seems like this is a
 subset of a larger block of IP (the ST COMMS IP block). Is this really a
 standalone piece of hardware, or is it always in the larger comms block?
COMMS block is a collection of communication peripherals, and IRB(Infra
red blaster) is always part of the COMMS block.

May renaming the compatible to st,comms-rc might be more clear.

 
 What's the full name of this unit as it appears in documentation?
It is always refered as the Communication sub-system (COMMS) which is a
collection of communication peripherals like UART, I2C, SPI, IRB.

 
 +   - st,uhfmode: boolean property to indicate if reception is in UHF.
 
 That's not a very clear name. Is this a physical property of the device
 (i.e. it's wired to either an IR receiver or a UHF receiver), or is this
 a choice as to how it's used at runtime?

Its both, some boards have IR and others UHF receivers, So it becomes
board choice here.
And also the driver has different register set for UHF receiver and IR
receiver. This options selects which registers to use depending on mode
of reception.

 
 If it's fixed property of how the device is wired, it might make more
 sense to have a string mode property that's either uhf or infared.

Am ok with either approaches.

 
 +   - reg: base physical address of the controller and length of memory
 +   mapped  region.
 +   - interrupts: interrupt number to the cpu. The interrupt specifier
 +   format depends on the interrupt controller parent.
 +
 +Example node:
 +
 +   rc: rc@fe518000 {
 +   compatible  = st,rc;
 +   reg = 0xfe518000 0x234;
 +   interrupts  =  0 203 0;
 +   };
 +
 
 [...]
 
 +++ b/drivers/media/rc/st_rc.c
 @@ -0,0 +1,371 @@
 +/*
 + * Copyright (C) 2013 STMicroelectronics Limited
 + * Author: Srinivas Kandagatla srinivas.kandaga...@st.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.
 + */
 +#include linux/kernel.h
 +#include linux/clk.h
 +#include linux/interrupt.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include media/rc-core.h
 +#include linux/pinctrl/consumer.h
 +
 +struct st_rc_device {
 +   struct device   *dev;
 +   int irq;
 +   int irq_wake;
 +   struct clk  *sys_clock;
 +   void*base;  /* Register base address */
 +   void*rx_base;/* RX Register base address 
 */
 +   struct rc_dev   

Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Rob Clark]

On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Op 12-08-13 17:43, Rob Clark schreef:
 On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 +
[snip]
 +/**
 + * fence_add_callback - add a callback to be called when the fence
 + * is signaled
 + * @fence: [in]the fence to wait on
 + * @cb:[in]the callback to register
 + * @func:  [in]the function to call
 + * @priv:  [in]the argument to pass to function
 + *
 + * cb will be initialized by fence_add_callback, no initialization
 + * by the caller is required. Any number of callbacks can be registered
 + * to a fence, but a callback can only be registered to one fence at a 
 time.
 + *
 + * Note that the callback can be called from an atomic context.  If
 + * fence is already signaled, this function will return -ENOENT (and
 + * *not* call the callback)
 + *
 + * Add a software callback to the fence. Same restrictions apply to
 + * refcount as it does to fence_wait, however the caller doesn't need to
 + * keep a refcount to fence afterwards: when software access is enabled,
 + * the creator of the fence is required to keep the fence alive until
 + * after it signals with fence_signal. The callback itself can be called
 + * from irq context.
 + *
 + */
 +int fence_add_callback(struct fence *fence, struct fence_cb *cb,
 +  fence_func_t func, void *priv)
 +{
 +   unsigned long flags;
 +   int ret = 0;
 +   bool was_set;
 +
 +   if (WARN_ON(!fence || !func))
 +   return -EINVAL;
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, fence-flags))
 +   return -ENOENT;
 +
 +   spin_lock_irqsave(fence-lock, flags);
 +
 +   was_set = test_and_set_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, 
 fence-flags);
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, fence-flags))
 +   ret = -ENOENT;
 +   else if (!was_set  !fence-ops-enable_signaling(fence)) {
 +   __fence_signal(fence);
 +   ret = -ENOENT;
 +   }
 +
 +   if (!ret) {
 +   cb-func = func;
 +   cb-priv = priv;
 +   list_add_tail(cb-node, fence-cb_list);
 since the user is providing the 'struct fence_cb', why not drop the
 priv  func args, and have some cb-initialize macro, ie.

 INIT_FENCE_CB(foo-fence, cbfxn);

 and I guess we can just drop priv and let the user embed fence in
 whatever structure they like.  Ie. make it look a bit how work_struct
 works.
 I don't mind killing priv. But a INIT_FENCE_CB macro is silly, when all it 
 would do is set cb-func.
 So passing it as  an argument to fence_add_callback is fine, unless you have 
 a better reason to
 do so.

 INIT_WORK seems to have a bit more initialization than us, it seems work can 
 be more complicated
 than callbacks, because the callbacks can only be called once and work can be 
 rescheduled multiple times.

yeah, INIT_WORK does more.. although maybe some day we want
INIT_FENCE_CB to do more (ie. if we add some debug features to help
catch misuse of fence/fence-cb's).  And if nothing else, having it
look a bit like other constructs that we have in the kernel seems
useful.  And with my point below, you'd want INIT_FENCE_CB to do a
INIT_LIST_HEAD(), so it is (very) slightly more than just setting the
fxn ptr.

 maybe also, if (!list_empty(cb-node) return -EBUSY?
 I think checking for list_empty(cb-node) is a terrible idea. This is no 
 different from any other list corruption,
 and it's a programming error. Not a runtime error. :-)

I was thinking for crtc and page-flip, embed the fence_cb in the crtc.
 You should only use the cb once at a time, but in this case you might
want to re-use it for the next page flip.  Having something to catch
cb mis-use in this sort of scenario seems useful.

maybe how I am thinking to use fence_cb is not quite what you had in
mind.  I'm not sure.  I was trying to think how I could just directly
use fence/fence_cb in msm for everything (imported dmabuf or just
regular 'ol gem buffers).

 cb-node.next/prev may be NULL, which would fail with this check. The 
 contents of cb-node are undefined
 before fence_add_callback is called. Calling fence_remove_callback on a fence 
 that hasn't been added is
 undefined too. Calling fence_remove_callback works, but I'm thinking of 
 changing the list_del_init to list_del,
 which would make calling fence_remove_callback twice a fatal error if 
 CONFIG_DEBUG_LIST is enabled,
 and a possible memory corruption otherwise.
 ...
 +
[snip]
 +
 +/**
 + * fence context counter: each execution context should have its own
 + * fence context, this allows checking if fences belong to the same
 + * context or not. One device can have multiple separate contexts,
 + * and they're used if some engine can run independently of another.
 + */
 +extern atomic_t fence_context_counter;
 context-alloc should not be in the critical path.. I'd think probably

Re: [PATCH] media: st-rc: Add ST remote control driver

[Mark Rutland]

On Thu, Aug 15, 2013 at 01:57:13PM +0100, Srinivas KANDAGATLA wrote:
 Thanks Mark for your comments.
 
 On 15/08/13 09:49, Mark Rutland wrote:
  On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
  From: Srinivas Kandagatla srinivas.kandaga...@st.com
 
  This patch adds support to ST RC driver, which is basically a IR/UHF
  receiver and transmitter. This IP is common across all the ST parts for
  settop box platforms. IRB is embedded in ST COMMS IP block.
  It supports both Rx  Tx functionality.
 
  In this driver adds only Rx functionality via LIRC codec.
  
  Is there anything that additionally needs to be in the dt to support Tx
  functionality?
 
 We need an additional boolean property for TX enable.

Why? Becuase you might not have something wired up for Tx?

What needs to be present physically for Tx support?

 
 +
 
 Two more configurable parameters for TX sub-carrier frequency and
 duty-cycle. By default driver can set the sub carrier frequency to be
 38Khz and duty cycle as 50%.
 However I don't have strong use case to make these configurable.
 
 So, I think just one boolean property to enable tx should be Ok.
 
  
 
  Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
  ---
  Hi Chehab,
 
  This is a very simple rc driver for IRB controller found in STi ARM CA9 
  SOCs.
  STi ARM SOC support went in 3.11 recently.
  This driver is a raw driver which feeds data to lirc codec for the user 
  lircd
  to decode the keys.
 
  This patch is based on git://linuxtv.org/media_tree.git master branch.
 
  Comments?
 
  Thanks,
  srini
 
   Documentation/devicetree/bindings/media/st-rc.txt |   18 +
   drivers/media/rc/Kconfig  |   10 +
   drivers/media/rc/Makefile |1 +
   drivers/media/rc/st_rc.c  |  371 
  +
   4 files changed, 400 insertions(+), 0 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
   create mode 100644 drivers/media/rc/st_rc.c
 
  diff --git a/Documentation/devicetree/bindings/media/st-rc.txt 
  b/Documentation/devicetree/bindings/media/st-rc.txt
  new file mode 100644
  index 000..57f9ee8
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/media/st-rc.txt
  @@ -0,0 +1,18 @@
  +Device-Tree bindings for ST IR and UHF receiver
  +
  +Required properties:
  +   - compatible: should be st,rc.
  
  That rc should be made more specific, and it seems like this is a
  subset of a larger block of IP (the ST COMMS IP block). Is this really a
  standalone piece of hardware, or is it always in the larger comms block?
 COMMS block is a collection of communication peripherals, and IRB(Infra
 red blaster) is always part of the COMMS block.
 
 May renaming the compatible to st,comms-rc might be more clear.

Given the actual name of the hardware seems to include irb, I think
irb makes more sense than rc in the compatible string. Is there no
more specific name than Infra Red Blaster?

 
  
  What's the full name of this unit as it appears in documentation?
 It is always refered as the Communication sub-system (COMMS) which is a
 collection of communication peripherals like UART, I2C, SPI, IRB.

Ok, are those separate IP blocks within a container, or is anything
shared? Does the COMMS block have any registers shared between those
units, for example?

 
  
  +   - st,uhfmode: boolean property to indicate if reception is in UHF.
  
  That's not a very clear name. Is this a physical property of the device
  (i.e. it's wired to either an IR receiver or a UHF receiver), or is this
  a choice as to how it's used at runtime?
 
 Its both, some boards have IR and others UHF receivers, So it becomes
 board choice here.

When you say it's both, what do you mean? Is it possible for a unit to
be wired with both IR and UHF support simultaneously, even if the Linux
driver can't handle that?

The dt should encode information about the hardware, not the way you
intend to use the hardware at the present moment in time.

 And also the driver has different register set for UHF receiver and IR
 receiver. This options selects which registers to use depending on mode
 of reception.

Ok, but that's an implementation issue. If you described that IR *may*
be used, and UHF *may* be used, the driver can choose what to do based
on that.

 
  
  If it's fixed property of how the device is wired, it might make more
  sense to have a string mode property that's either uhf or infared.
 
 Am ok with either approaches.

It sounds like we may need separate properties as mentioned above, or a
supported-modes list, perhaps.

 
  
  +   - reg: base physical address of the controller and length of memory
  +   mapped  region.
  +   - interrupts: interrupt number to the cpu. The interrupt specifier
  +   format depends on the interrupt controller parent.
  +
  +Example node:
  +
  +   rc: rc@fe518000 {
  +   compatible  = st,rc;
  +   

Re: [PATCH] media: st-rc: Add ST remote control driver

[Pawel Moll]

On Wed, 2013-08-14 at 18:27 +0100, Srinivas KANDAGATLA wrote:
 +Device-Tree bindings for ST IR and UHF receiver
 +
 +Required properties:
 +   - compatible: should be st,rc.
 +   - st,uhfmode: boolean property to indicate if reception is in UHF.
 +   - reg: base physical address of the controller and length of memory
 +   mapped  region.
 +   - interrupts: interrupt number to the cpu. The interrupt specifier
 +   format depends on the interrupt controller parent.
 +
 +Example node:
 +
 +   rc: rc@fe518000 {
 +   compatible  = st,rc;
 +   reg = 0xfe518000 0x234;
 +   interrupts  =  0 203 0;
 +   };

So is st,uhfmode required or optional after all? If the former, the
example is wrong (doesn't specify required property). But as far as I
understand it's really optional...

Paweł


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

Re: [PATCH] media: st-rc: Add ST remote control driver

[Srinivas KANDAGATLA]

On 15/08/13 14:30, Pawel Moll wrote:
 On Wed, 2013-08-14 at 18:27 +0100, Srinivas KANDAGATLA wrote:
 +Device-Tree bindings for ST IR and UHF receiver
 +
 +Required properties:
 +   - compatible: should be st,rc.
 +   - st,uhfmode: boolean property to indicate if reception is in UHF.
 +   - reg: base physical address of the controller and length of memory
 +   mapped  region.
 +   - interrupts: interrupt number to the cpu. The interrupt specifier
 +   format depends on the interrupt controller parent.
 +
 +Example node:
 +
 +   rc: rc@fe518000 {
 +   compatible  = st,rc;
 +   reg = 0xfe518000 0x234;
 +   interrupts  =  0 203 0;
 +   };
 
 So is st,uhfmode required or optional after all? If the former, the
 example is wrong (doesn't specify required property). But as far as I
 understand it's really optional...


You are right, I will move this to optional properties section.

Thanks,
srini
 
 Paweł
 
 
 

--
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] fence: dma-buf cross-device synchronization (v13)

[Maarten Lankhorst]

Op 15-08-13 14:45, Marcin Ślusarz schreef:
 2013/8/15 Maarten Lankhorst maarten.lankho...@canonical.com:
 A fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.

 A driver must allocate a fence context for each execution ring that can
 run in parallel. The function for this takes an argument with how many
 contexts to allocate:
   + fence_context_alloc()

 A fence is transient, one-shot deal.  It is allocated and attached
 to one or more dma-buf's.  When the one that attached it is done, with
 the pending operation, it can signal the fence:
   + fence_signal()

 To have a rough approximation whether a fence is fired, call:
   + fence_is_signaled()

 The dma-buf-mgr handles tracking, and waiting on, the fences associated
 with a dma-buf.

 The one pending on the fence can add an async callback:
   + fence_add_callback()

 The callback can optionally be cancelled with:
   + fence_remove_callback()

 To wait synchronously, optionally with a timeout:
   + fence_wait()
   + fence_wait_timeout()

 A default software-only implementation is provided, which can be used
 by drivers attaching a fence to a buffer when they have no other means
 for hw sync.  But a memory backed fence is also envisioned, because it
 is common that GPU's can write to, or poll on some memory location for
 synchronization.  For example:

   fence = custom_get_fence(...);
   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
 dma_buf *fence_buf = fence-sync_buf;
 get_dma_buf(fence_buf);

 ... tell the hw the memory location to wait ...
 custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
   } else {
 /* fall-back to sw sync * /
 fence_add_callback(fence, my_cb);
   }

 On SoC platforms, if some other hw mechanism is provided for synchronizing
 between IP blocks, it could be supported as an alternate implementation
 with it's own fence ops in a similar way.

 enable_signaling callback is used to provide sw signaling in case a cpu
 waiter is requested or no compatible hardware signaling could be used.

 The intention is to provide a userspace interface (presumably via eventfd)
 later, to be used in conjunction with dma-buf's mmap support for sw access
 to buffers (or for userspace apps that would prefer to do their own
 synchronization).

 v1: Original
 v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
 that dma-fence didn't need to care about the sw-hw signaling path
 (it can be handled same as sw-sw case), and therefore the fence-ops
 can be simplified and more handled in the core.  So remove the signal,
 add_callback, cancel_callback, and wait ops, and replace with a simple
 enable_signaling() op which can be used to inform a fence supporting
 hw-hw signaling that one or more devices which do not support hw
 signaling are waiting (and therefore it should enable an irq or do
 whatever is necessary in order that the CPU is notified when the
 fence is passed).
 v3: Fix locking fail in attach_fence() and get_fence()
 v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
 we decided that we need to be able to attach one fence to N dma-buf's,
 so using the list_head in dma-fence struct would be problematic.
 v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
 v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
 comments
 about checking if fence fired or not. This is broken by design.
 waitqueue_active during destruction is now fatal, since the signaller
 should be holding a reference in enable_signalling until it signalled
 the fence. Pass the original dma_fence_cb along, and call __remove_wait
 in the dma_fence_callback handler, so that no cleanup needs to be
 performed.
 v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
 fence wasn't signaled yet, for example for hardware fences that may
 choose to signal blindly.
 v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
 header and fixed include mess. dma-fence.h now includes dma-buf.h
 All members are now initialized, so kmalloc can be used for
 allocating a dma-fence. More documentation added.
 v9: Change compiler bitfields to flags, change return type of
 enable_signaling to bool. Rework dma_fence_wait. Added
 dma_fence_is_signaled and dma_fence_wait_timeout.
 s/dma// and change exports to non GPL. Added fence_is_signaled and
 fence_enable_sw_signaling calls, add ability to 

OMAP3 ISP DQBUF hangs

[Tom]

Hello,

I'm working with an OMAP3 DM3730 processor module with a ov3640 camera
module attached on parallel interface. I'm using Linux 3.5 and an
application which builds the pipeline and grabs an image like the
media-ctl and the yavta tools.

I configured the pipeline to:

sensor-ccdc-memory

When I call ioctl with DQBUF the calling functions are:

isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait -
wait_event_interruptible

The last function waits until the state of the buffer will be reseted
somehow. Can someone tell my which function sets the state of the buffer? Am
I missing an interrupt?

Best Regards, Tom

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

Re: [PATCH] media: st-rc: Add ST remote control driver

[Srinivas KANDAGATLA]

On 15/08/13 14:29, Mark Rutland wrote:
 On Thu, Aug 15, 2013 at 01:57:13PM +0100, Srinivas KANDAGATLA wrote:
 Thanks Mark for your comments.

 On 15/08/13 09:49, Mark Rutland wrote:
 On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
 From: Srinivas Kandagatla srinivas.kandaga...@st.com

 This patch adds support to ST RC driver, which is basically a IR/UHF
 receiver and transmitter. This IP is common across all the ST parts for
 settop box platforms. IRB is embedded in ST COMMS IP block.
 It supports both Rx  Tx functionality.

 In this driver adds only Rx functionality via LIRC codec.

 Is there anything that additionally needs to be in the dt to support Tx
 functionality?

 We need an additional boolean property for TX enable.
 
 Why? Becuase you might not have something wired up for Tx?
Yes.
 
 What needs to be present physically for Tx support?
An IR transmitter LEDs need to be physically connected.
Also driver need to know about this to setup the IP to do tx.
 

 +

 Two more configurable parameters for TX sub-carrier frequency and
 duty-cycle. By default driver can set the sub carrier frequency to be
 38Khz and duty cycle as 50%.
 However I don't have strong use case to make these configurable.

 So, I think just one boolean property to enable tx should be Ok.


 +Device-Tree bindings for ST IR and UHF receiver
 +
 +Required properties:
 +   - compatible: should be st,rc.

 That rc should be made more specific, and it seems like this is a
 subset of a larger block of IP (the ST COMMS IP block). Is this really a
 standalone piece of hardware, or is it always in the larger comms block?
 COMMS block is a collection of communication peripherals, and IRB(Infra
 red blaster) is always part of the COMMS block.

 May renaming the compatible to st,comms-rc might be more clear.
 
 Given the actual name of the hardware seems to include irb, I think
 irb makes more sense than rc in the compatible string. Is there no
 more specific name than Infra Red Blaster?

There is'nt, its always referred as IRB.

I will rename the compatible to st,comms-irb does this sound Ok?
 


 What's the full name of this unit as it appears in documentation?
 It is always refered as the Communication sub-system (COMMS) which is a
 collection of communication peripherals like UART, I2C, SPI, IRB.
 
 Ok, are those separate IP blocks within a container, or is anything
 shared? Does the COMMS block have any registers shared between those
 units, for example?
No, registers are not shared across the IP blocks.
 


 +   - st,uhfmode: boolean property to indicate if reception is in UHF.

 That's not a very clear name. Is this a physical property of the device
 (i.e. it's wired to either an IR receiver or a UHF receiver), or is this
 a choice as to how it's used at runtime?

 Its both, some boards have IR and others UHF receivers, So it becomes
 board choice here.
 
 When you say it's both, what do you mean? Is it possible for a unit to
 be wired with both IR and UHF support simultaneously, even if the Linux
 driver can't handle that?
 
I meant that this property is physical property of the device(board
wired up to either IR or UHF receiver) and also choice on how the IP is
configured.

 The dt should encode information about the hardware, not the way you
 intend to use the hardware at the present moment in time.
Ok.
 
 And also the driver has different register set for UHF receiver and IR
 receiver. This options selects which registers to use depending on mode
 of reception.
 
 Ok, but that's an implementation issue. If you described that IR *may*
 be used, and UHF *may* be used, the driver can choose what to do based
 on that.
 


 If it's fixed property of how the device is wired, it might make more
 sense to have a string mode property that's either uhf or infared.

 Am ok with either approaches.
 
 It sounds like we may need separate properties as mentioned above, or a
 supported-modes list, perhaps.

I think having rx-mode and tx-mode properties makes more sense rather
than supported-modes.

like:
rx-mode = uhf;

or

rx-mode = infrared;

Similarly tx-mode.

 


 +   - reg: base physical address of the controller and length of memory
 +   mapped  region.
 +   - interrupts: interrupt number to the cpu. The interrupt specifier
 +   format depends on the interrupt controller parent.
 +
 +Example node:
 +
 +   rc: rc@fe518000 {
 +   compatible  = st,rc;
 +   reg = 0xfe518000 0x234;
 +   interrupts  =  0 203 0;
 +   };
 +

 [...]

 +++ b/drivers/media/rc/st_rc.c
 @@ -0,0 +1,371 @@
 +/*
 + * Copyright (C) 2013 STMicroelectronics Limited
 + * Author: Srinivas Kandagatla srinivas.kandaga...@st.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 

Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

Op 15-08-13 15:14, Rob Clark schreef:
 On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 Op 12-08-13 17:43, Rob Clark schreef:
 On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 +
 [snip]
 +/**
 + * fence_add_callback - add a callback to be called when the fence
 + * is signaled
 + * @fence: [in]the fence to wait on
 + * @cb:[in]the callback to register
 + * @func:  [in]the function to call
 + * @priv:  [in]the argument to pass to function
 + *
 + * cb will be initialized by fence_add_callback, no initialization
 + * by the caller is required. Any number of callbacks can be registered
 + * to a fence, but a callback can only be registered to one fence at a 
 time.
 + *
 + * Note that the callback can be called from an atomic context.  If
 + * fence is already signaled, this function will return -ENOENT (and
 + * *not* call the callback)
 + *
 + * Add a software callback to the fence. Same restrictions apply to
 + * refcount as it does to fence_wait, however the caller doesn't need to
 + * keep a refcount to fence afterwards: when software access is enabled,
 + * the creator of the fence is required to keep the fence alive until
 + * after it signals with fence_signal. The callback itself can be called
 + * from irq context.
 + *
 + */
 +int fence_add_callback(struct fence *fence, struct fence_cb *cb,
 +  fence_func_t func, void *priv)
 +{
 +   unsigned long flags;
 +   int ret = 0;
 +   bool was_set;
 +
 +   if (WARN_ON(!fence || !func))
 +   return -EINVAL;
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, fence-flags))
 +   return -ENOENT;
 +
 +   spin_lock_irqsave(fence-lock, flags);
 +
 +   was_set = test_and_set_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, 
 fence-flags);
 +
 +   if (test_bit(FENCE_FLAG_SIGNALED_BIT, fence-flags))
 +   ret = -ENOENT;
 +   else if (!was_set  !fence-ops-enable_signaling(fence)) {
 +   __fence_signal(fence);
 +   ret = -ENOENT;
 +   }
 +
 +   if (!ret) {
 +   cb-func = func;
 +   cb-priv = priv;
 +   list_add_tail(cb-node, fence-cb_list);
 since the user is providing the 'struct fence_cb', why not drop the
 priv  func args, and have some cb-initialize macro, ie.

 INIT_FENCE_CB(foo-fence, cbfxn);

 and I guess we can just drop priv and let the user embed fence in
 whatever structure they like.  Ie. make it look a bit how work_struct
 works.
 I don't mind killing priv. But a INIT_FENCE_CB macro is silly, when all it 
 would do is set cb-func.
 So passing it as  an argument to fence_add_callback is fine, unless you have 
 a better reason to
 do so.

 INIT_WORK seems to have a bit more initialization than us, it seems work can 
 be more complicated
 than callbacks, because the callbacks can only be called once and work can 
 be rescheduled multiple times.
 yeah, INIT_WORK does more.. although maybe some day we want
 INIT_FENCE_CB to do more (ie. if we add some debug features to help
 catch misuse of fence/fence-cb's).  And if nothing else, having it
 look a bit like other constructs that we have in the kernel seems
 useful.  And with my point below, you'd want INIT_FENCE_CB to do a
 INIT_LIST_HEAD(), so it is (very) slightly more than just setting the
 fxn ptr.
I don't think list is a good idea for that.
 maybe also, if (!list_empty(cb-node) return -EBUSY?
 I think checking for list_empty(cb-node) is a terrible idea. This is no 
 different from any other list corruption,
 and it's a programming error. Not a runtime error. :-)
 I was thinking for crtc and page-flip, embed the fence_cb in the crtc.
  You should only use the cb once at a time, but in this case you might
 want to re-use it for the next page flip.  Having something to catch
 cb mis-use in this sort of scenario seems useful.

 maybe how I am thinking to use fence_cb is not quite what you had in
 mind.  I'm not sure.  I was trying to think how I could just directly
 use fence/fence_cb in msm for everything (imported dmabuf or just
 regular 'ol gem buffers).


 cb-node.next/prev may be NULL, which would fail with this check. The 
 contents of cb-node are undefined
 before fence_add_callback is called. Calling fence_remove_callback on a 
 fence that hasn't been added is
 undefined too. Calling fence_remove_callback works, but I'm thinking of 
 changing the list_del_init to list_del,
 which would make calling fence_remove_callback twice a fatal error if 
 CONFIG_DEBUG_LIST is enabled,
 and a possible memory corruption otherwise.
 ...
 +
 [snip]
 +
 +/**
 + * fence context counter: each execution context should have its own
 + * fence context, this allows checking if fences belong to the same
 + * context or not. One device can have multiple separate contexts,
 + * and they're used if some engine can run independently of another.
 + */
 +extern 

Re: [PATCH] media: st-rc: Add ST remote control driver

[Mark Rutland]

On Thu, Aug 15, 2013 at 03:06:14PM +0100, Srinivas KANDAGATLA wrote:
 On 15/08/13 14:29, Mark Rutland wrote:
  On Thu, Aug 15, 2013 at 01:57:13PM +0100, Srinivas KANDAGATLA wrote:
  Thanks Mark for your comments.
 
  On 15/08/13 09:49, Mark Rutland wrote:
  On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
  From: Srinivas Kandagatla srinivas.kandaga...@st.com
 
  This patch adds support to ST RC driver, which is basically a IR/UHF
  receiver and transmitter. This IP is common across all the ST parts for
  settop box platforms. IRB is embedded in ST COMMS IP block.
  It supports both Rx  Tx functionality.
 
  In this driver adds only Rx functionality via LIRC codec.
 
  Is there anything that additionally needs to be in the dt to support Tx
  functionality?
 
  We need an additional boolean property for TX enable.
  
  Why? Becuase you might not have something wired up for Tx?
 Yes.
  
  What needs to be present physically for Tx support?
 An IR transmitter LEDs need to be physically connected.

Ok.

 Also driver need to know about this to setup the IP to do tx.
  
 
  +
 
  Two more configurable parameters for TX sub-carrier frequency and
  duty-cycle. By default driver can set the sub carrier frequency to be
  38Khz and duty cycle as 50%.
  However I don't have strong use case to make these configurable.
 
  So, I think just one boolean property to enable tx should be Ok.
 
 
  +Device-Tree bindings for ST IR and UHF receiver
  +
  +Required properties:
  +   - compatible: should be st,rc.
 
  That rc should be made more specific, and it seems like this is a
  subset of a larger block of IP (the ST COMMS IP block). Is this really a
  standalone piece of hardware, or is it always in the larger comms block?
  COMMS block is a collection of communication peripherals, and IRB(Infra
  red blaster) is always part of the COMMS block.
 
  May renaming the compatible to st,comms-rc might be more clear.
  
  Given the actual name of the hardware seems to include irb, I think
  irb makes more sense than rc in the compatible string. Is there no
  more specific name than Infra Red Blaster?
 
 There is'nt, its always referred as IRB.
 
 I will rename the compatible to st,comms-irb does this sound Ok?

That sounds fine.

  
 
 
  What's the full name of this unit as it appears in documentation?
  It is always refered as the Communication sub-system (COMMS) which is a
  collection of communication peripherals like UART, I2C, SPI, IRB.
  
  Ok, are those separate IP blocks within a container, or is anything
  shared? Does the COMMS block have any registers shared between those
  units, for example?
 No, registers are not shared across the IP blocks.

Good to know.

  
 
 
  +   - st,uhfmode: boolean property to indicate if reception is in 
  UHF.
 
  That's not a very clear name. Is this a physical property of the device
  (i.e. it's wired to either an IR receiver or a UHF receiver), or is this
  a choice as to how it's used at runtime?
 
  Its both, some boards have IR and others UHF receivers, So it becomes
  board choice here.

Ok, so we can never have both wired up simultaneously? Any board will
have only one of the two wired up (and the other will be unusable
becasue it's not wired up).

  
  When you say it's both, what do you mean? Is it possible for a unit to
  be wired with both IR and UHF support simultaneously, even if the Linux
  driver can't handle that?
  
 I meant that this property is physical property of the device(board
 wired up to either IR or UHF receiver) and also choice on how the IP is
 configured.
 
  The dt should encode information about the hardware, not the way you
  intend to use the hardware at the present moment in time.
 Ok.
  
  And also the driver has different register set for UHF receiver and IR
  receiver. This options selects which registers to use depending on mode
  of reception.
  
  Ok, but that's an implementation issue. If you described that IR *may*
  be used, and UHF *may* be used, the driver can choose what to do based
  on that.
  
 
 
  If it's fixed property of how the device is wired, it might make more
  sense to have a string mode property that's either uhf or infared.
 
  Am ok with either approaches.
  
  It sounds like we may need separate properties as mentioned above, or a
  supported-modes list, perhaps.
 
 I think having rx-mode and tx-mode properties makes more sense rather
 than supported-modes.
 
 like:
 rx-mode = uhf;
 
 or
 
 rx-mode = infrared;
 
 Similarly tx-mode.

That makes sense to me.

 
  
 
 
  +   - reg: base physical address of the controller and length of 
  memory
  +   mapped  region.
  +   - interrupts: interrupt number to the cpu. The interrupt 
  specifier
  +   format depends on the interrupt controller parent.
  +
  +Example node:
  +
  +   rc: rc@fe518000 {
  +   compatible  = st,rc;
  +   reg = 0xfe518000 0x234;
  +   interrupts  =  

Re: [PATCH v5 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation

[Sylwester Nawrocki]

W dniu 2013-08-14 06:46, Arun Kumar K pisze:

The patch adds the DT binding documentation for Samsung
Exynos5 SoC series imaging subsystem (FIMC-IS).

Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
  .../devicetree/bindings/media/exynos5-fimc-is.txt  |   47 
  1 file changed, 47 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt

diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt 
b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
new file mode 100644
index 000..bfd36df
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
@@ -0,0 +1,47 @@
+Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS)
+--
+
+The camera subsystem on Samsung Exynos5 SoC has some changes relative
+to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and
+FIMC-LITE IPs but has a much improved version of FIMC-IS which can
+handle sensor controls and camera post-processing operations. The
+Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many
+post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two
+dedicated scalers (SCC and SCP).
+
+fimc-is node
+
+
+Required properties:
+
+- compatible: must be samsung,exynos5250-fimc-is
+- reg   : physical base address and size of the memory mapped
+  registers
+- interrupt-parent  : parent interrupt controller
+- interrupts: fimc-is interrupt to the parent combiner


Is it really only one interrupt or two as in case of Exynos4x12 ?
Also it's probably more appropriate to say interrupt controller
instead of combiner, not including details of the the FIMC-IS external 
interrupt controller in this binding.



+- clocks: list of clock specifiers, corresponding to entries in
+  clock-names property;
+- clock-names   : must contain isp, mcu_isp, isp_div0, isp_div1,
+  isp_divmpwm, mcu_isp_div0, mcu_isp_div1 entries,
+  matching entries in the clocks property.
+- pmu   : phandle to the fimc-is pmu node describing the register
+  base and size for FIMC-IS PMU.


This property needs to be prefixed with samsung,.


+
+i2c-isp (ISP I2C bus controller) nodes
+--
+
+Required properties:
+
+- compatible   : should be samsung,exynos4212-i2c-isp for Exynos4212,
+ Exynos4412 and Exynos5250 SoCs;
+- reg  : physical base address and length of the registers set;
+- clocks   : must contain gate clock specifier for this controller;
+- clock-names  : must contain i2c_isp entry.
+
+For the i2c-isp node, it is required to specify a pinctrl state named 
default,
+according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
+
+Device tree nodes of the image sensors' controlled directly by the FIMC-IS


nit: As pointed out already there is no need for the apostrophe.


+firmware must be child nodes of their corresponding ISP I2C bus controller 
node.
+The data link of these image sensors must be specified using the common video
+interfaces bindings, defined in video-interfaces.txt.


--
Thanks,
Sylwester
--
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

Fwd: scan reports wrong polarization for some multiplexes

[Tomi Mikkonen]

 Package: dvb-apps
  Version: Today's (15/08/2013) from mercurial

The output of scan reports wrong polarization for some channels. See
the example below for LBC News.

 ./scan -a 2 dvb-s/Astra-28.2E out.txt

~/dvb-apps/util/scan$ grep LBC out.txt
LBC 97.3:11223:v:0:27500:0:2312:52029
LBC News:11223:v:0:27500:0:2313:52031

On the screen (stderr), it finds polarization correctly (h) :

 tune to: 11222:h:0:27500
DVB-S IF freq is 1472170
0x0907 0xcb2a: pmt_pid 0x BSkyB -- Summer Hits TV (running)
0x0907 0xcb2d: pmt_pid 0x BSkyB -- Chat Box (running)
0x0907 0xcb2e: pmt_pid 0x BSkyB -- BT Sport 1 (running)
0x0907 0xcb3c: pmt_pid 0x BSkyB -- BFBS Radio (running)
0x0907 0xcb3d: pmt_pid 0x BSkyB -- LBC 97.3 (running)
0x0907 0xcb3e: pmt_pid 0x BSkyB -- Heart (running)
0x0907 0xcb3f: pmt_pid 0x BSkyB -- LBC News (running)
0x0907 0xcb48: pmt_pid 0x BSkyB -- SportxxxGirls (running)
0x0907 0xcb52: pmt_pid 0x BSkyB -- Northern Birds (running)
0x0907 0xcb58: pmt_pid 0x BSkyB -- Controversial tv (running)
0x0907 0xcb5c: pmt_pid 0x0106 BSkyB -- Heat (running)
0x0907 0xcb61: pmt_pid 0x010f BSkyB -- Magic (running)
0x0907 0xcb66: pmt_pid 0x0100 BSkyB -- Klear TV (running)
0x0907 0xcb70: pmt_pid 0x0109 BSkyB -- Extreme Sports (running, scrambled)
0x0907 0xcb75: pmt_pid 0x0110 BSkyB -- Muslim World (running)
0x0907 0xcb21: pmt_pid 0x0108 BSkyB -- UCB TV (running)
0x0907 0xcb22: pmt_pid 0x0107 BSkyB -- horror ch+1 (running)
0x0907 0xcb24: pmt_pid 0x010d BSkyB -- Ummah TV (running)
0x0907 0xcb25: pmt_pid 0x010b BSkyB -- Sony TV (running)
0x0907 0xcb26: pmt_pid 0x0122 BSkyB -- Jewelry Maker (running)
0x0907 0xcb27: pmt_pid 0x0102 BSkyB -- CBS Action (running)
0x0907 0xcb28: pmt_pid 0x0101 BSkyB -- Get Lucky TV (running)
WARNING: filter timeout pid 0x0105
Network Name 'ASTRA'
Network Name 'ASTRA'
 tune to: 11223:v:0:27500
DVB-S IF freq is 1473670
0x 0xcf7e: pmt_pid 0x0106 BSkyB -- Jeem.TV (running)
0x 0xcf9b: pmt_pid 0x0112 BSkyB -- NHK World HD (running)
0x 0xcf9c: pmt_pid 0x0103 BSkyB -- RT HD (running)
0x 0xcf9d: pmt_pid 0x0100 BSkyB -- ARISE News HD (running)
Network Name 'ASTRA'
Network Name 'ASTRA'

I suspect close frequencies are mixed somehow even when polarization
is different.

I'm using 3.5.0-37-generic in Ubuntu 12.04.2 LTS server. The tuner
card is TBS-6984.
--
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

DVR card SAA7134/SAA7135HL unknown

[Jody Gugelhupf]

hi all :)
trying to get this 8 channel dvr card to work in linux, but I get this:

Board is currently unknown. You might try to use the card=nr
saa7134: insmod option to specify which board do you have, but this is
saa7134: somewhat risky, as might damage your card. It is better to ask
saa7134: for support at linux-media@vger.kernel.org.

so here I am. I have not tried to set the card myself as I don't know what 
number to use. Was hoping I could get some help here to get it working. Some 
info I collected so far can be found here http://pastebin.ca/2430477 any ideas 
what I might try next or what card to specify?
thank you in advance for any help.
jody
--
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

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu Aug 15 19:00:19 CEST 2013
git branch: test
git hash:   dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d
gcc version:i686-linux-gcc (GCC) 4.8.1
sparse version: v0.4.5-rc1
host hardware:  x86_64
host os:3.9-7.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.31.14-i686: WARNINGS
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: OK
linux-3.10-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: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-2.6.31.14-x86_64: WARNINGS
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: OK
linux-3.10-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: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse version: v0.4.5-rc1
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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