Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes

[Tony Lindgren]

* Ivaylo Dimitrov  [160622 12:25]:
> ir-rx51 is a driver for Nokia N900 IR transmitter. The current series
> fixes the remaining problems in the driver:

Thanks for updating these.

Trierry, care to ack the PWM patch?

Mauro, do you want me to set up an immutable branch with all
these against v4.7-rc1 that we can all merge as needed?

If you want to set up the branch instead, please feel free
to add my ack.

Regards,

Tony
--
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: OK

[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 Jun 23 04:00:28 CEST 2016
git branch: test
git hash:   59f0bc11848f8f3242bc1fefae670e745929cd7b
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mtk: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

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

[BUG] au0828: dev->lock in au0828_usb_probe()

[Alexey Khoroshilov]

It is not quite clear what does mutex_lock(>lock) defend against.

If there is a chance that some other code can try to lock the mutex during 
probe(),
then 
  mutex_unlock(>lock);
  kfree(dev);
looks suspicious, because when that code get control form mutex_lock(dev->lock)
the dev could be already freed.

Otherwise, dev->lock should not be acquired so early.

Another problem is that on the path going via goto done
there is no mutex_unlock(>lock).

Found by Linux Driver Verification project (linuxtesting.org).

--
Alexey Khoroshilov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org

--
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 v5 0/9] Output raw touch data via V4L2

[Nick Dyer]

This is a series of patches to add output of raw touch diagnostic data via V4L2
to the Atmel maXTouch and Synaptics RMI4 drivers.

It's a rewrite of the previous implementation which output via debugfs: it now
uses a V4L2 device in a similar way to the sur40 driver.

We have a utility which can read the data and display it in a useful format:
https://github.com/ndyer/heatmap/commits/heatmap-v4l

These patches are also available from
https://github.com/ndyer/linux/commits/v4l-touch-2016-06-22

Changes in v5 (Hans Verkuil review):
- Update v4l2-core:
  - Add VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE and V4L2_CAP_TOUCH
  - Change V4L2_INPUT_TYPE_TOUCH_SENSOR to V4L2_INPUT_TYPE_TOUCH
  - Improve DocBook documentation
  - Add FMT definitions for touch data
  - Note this will need the latest version of the heatmap util
- Synaptics RMI4 driver:
  - Remove some less important non full frame report types
  - Switch report type names to const char * array
  - Move a static array to inside context struct
- Split sur40 changes to a separate commit

Changes in v4:
- Address nits from the input side in atmel_mxt_ts patches (Dmitry Torokhov)
- Add Synaptics RMI4 F54 support patch

Changes in v3:
- Address V4L2 review comments from Hans Verkuil
- Run v4l-compliance and fix all issues - needs minor patch here:
  https://github.com/ndyer/v4l-utils/commit/cf50469773f

Changes in v2:
- Split pixfmt changes into separate commit and add DocBook
- Introduce VFL_TYPE_TOUCH_SENSOR and /dev/v4l-touch
- Remove "single node" support for now, it may be better to treat it as
  metadata later
- Explicitly set VFL_DIR_RX
- Fix Kconfig

--
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 v5 1/9] [media] v4l2-core: Add support for touch devices

[Nick Dyer]

Some touch controllers send out touch data in a similar way to a
greyscale frame grabber.

Use a new device prefix v4l-touch for these devices, to stop generic
capture software from treating them as webcams.

Add formats:
- V4L2_TCH_FMT_DELTA_TD16 for signed 16-bit touch deltas
- V4L2_TCH_FMT_DELTA_TD08 for signed 16-bit touch deltas
- V4L2_TCH_FMT_TU16 for unsigned 16-bit touch data
- V4L2_TCH_FMT_TU08 for unsigned 8-bit touch data

This support will be used by:
* Atmel maXTouch (atmel_mxt_ts)
* Synaptics RMI4.
* sur40

Signed-off-by: Nick Dyer 
---
 Documentation/DocBook/media/v4l/dev-touch.xml  | 53 ++
 Documentation/DocBook/media/v4l/media-types.xml|  5 ++
 .../DocBook/media/v4l/pixfmt-tch-td08.xml  | 66 +
 .../DocBook/media/v4l/pixfmt-tch-td16.xml  | 82 ++
 .../DocBook/media/v4l/pixfmt-tch-tu08.xml  | 66 +
 .../DocBook/media/v4l/pixfmt-tch-tu16.xml  | 81 +
 Documentation/DocBook/media/v4l/pixfmt.xml | 13 
 Documentation/DocBook/media/v4l/v4l2.xml   |  1 +
 drivers/media/v4l2-core/v4l2-dev.c | 16 -
 drivers/media/v4l2-core/v4l2-ioctl.c   | 44 
 drivers/media/v4l2-core/videobuf2-v4l2.c   |  1 +
 include/media/v4l2-dev.h   |  3 +-
 include/uapi/linux/media.h |  2 +
 include/uapi/linux/videodev2.h | 10 +++
 14 files changed, 439 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/dev-touch.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-tch-td08.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-tch-td16.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-tch-tu08.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-tch-tu16.xml

diff --git a/Documentation/DocBook/media/v4l/dev-touch.xml 
b/Documentation/DocBook/media/v4l/dev-touch.xml
new file mode 100644
index 000..9e36328
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/dev-touch.xml
@@ -0,0 +1,53 @@
+Touch Devices
+
+Touch devices are accessed through character device special files
+  named /dev/v4l-touch0 to
+  /dev/v4l-touch255 with major number 81 and
+  dynamically allocated minor numbers 0 to 255.
+
+
+  Overview
+
+  Sensors may be Optical, or Projected Capacitive touch (PCT).
+
+  Processing is required to analyse the raw data and produce input
+events. In some systems, this may be performed on the ASIC and the raw data
+is purely a side-channel for diagnostics or tuning. In other systems, the
+ASIC is a simple analogue front end device which delivers touch data at
+high rate, and any touch processing must be done on the host.
+
+  For capacitive touch sensing, the touchscreen is composed of an array
+of horizontal and vertical conductors (alternatively called rows/columns,
+X/Y lines, or tx/rx). Mutual Capacitance measured is at the nodes where the
+conductors cross. Alternatively, Self Capacitance measures the signal from
+each column and row independently.
+
+  A touch input may be determined by comparing the raw capacitance
+measurement to a no-touch reference (or "baseline") measurement:
+
+  Delta = Raw - Reference
+
+  The reference measurement takes account of variations in the
+capacitance across the touch sensor matrix, for example
+manufacturing irregularities, environmental or edge effects.
+
+
+
+  Querying Capabilities
+
+  Devices supporting the touch interface set the
+V4L2_CAP_VIDEO_CAPTURE flag in the
+capabilities field of 
+returned by the  ioctl.
+
+  At least one of the read/write, streaming or asynchronous I/O methods
+must be supported.
+
+
+
+  Data Format Negotiation
+
+   A touch device may support read/write
+and/or streaming (memory mapping or
+user pointer) I/O.
+
diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
b/Documentation/DocBook/media/v4l/media-types.xml
index 5e3f20f..fb957c7 100644
--- a/Documentation/DocBook/media/v4l/media-types.xml
+++ b/Documentation/DocBook/media/v4l/media-types.xml
@@ -202,6 +202,11 @@
typically, /dev/swradio?
  
  
+   MEDIA_INTF_T_V4L_TOUCH
+   Device node interface for Touch device (V4L)
+   typically, /dev/v4l-touch?
+ 
+ 
MEDIA_INTF_T_ALSA_PCM_CAPTURE
Device node interface for ALSA PCM Capture
typically, /dev/snd/pcmC?D?c
diff --git a/Documentation/DocBook/media/v4l/pixfmt-tch-td08.xml 
b/Documentation/DocBook/media/v4l/pixfmt-tch-td08.xml
new file mode 100644
index 000..2483eb0
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-tch-td08.xml
@@ -0,0 +1,66 @@
+
+  
+V4L2_TCH_FMT_DELTA_TD08 ('TD08')
+
+  
+  
+V4L2_TCH_FMT_DELTA_TD08
+8-bit signed Touch Delta
+  
+  
+Description
+
+This format 

[PATCH v5 6/9] Input: atmel_mxt_ts - add diagnostic data support for mXT1386

[Nick Dyer]

The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 3f7e357..739d138 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -137,6 +137,10 @@ struct t9_range {
 #define MXT_DIAGNOSTIC_DELTAS  0x10
 #define MXT_DIAGNOSTIC_SIZE128
 
+#define MXT_FAMILY_1386160
+#define MXT1386_COLUMNS3
+#define MXT1386_PAGES_PER_COLUMN   8
+
 struct t37_debug {
 #ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
u8 mode;
@@ -2140,13 +2144,27 @@ recheck:
 static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
   unsigned int y)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
unsigned int ofs, page;
+   unsigned int col = 0;
+   unsigned int col_width;
+
+   if (info->family_id == MXT_FAMILY_1386) {
+   col_width = info->matrix_ysize / MXT1386_COLUMNS;
+   col = y / col_width;
+   y = y % col_width;
+   } else {
+   col_width = info->matrix_ysize;
+   }
 
-   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   ofs = (y + (x * col_width)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   page += col * MXT1386_PAGES_PER_COLUMN;
+
return get_unaligned_le16(>t37_buf[page].data[ofs]);
 }
 
@@ -2416,6 +2434,7 @@ static const struct video_device mxt_video_device = {
 
 static void mxt_debug_init(struct mxt_data *data)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
struct mxt_object *object;
int error;
@@ -2439,8 +2458,14 @@ static void mxt_debug_init(struct mxt_data *data)
 
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
-   dbg->t37_pages = DIV_ROUND_UP(data->xsize * data->info.matrix_ysize *
- sizeof(u16), sizeof(dbg->t37_buf->data));
+
+   if (info->family_id == MXT_FAMILY_1386)
+   dbg->t37_pages = MXT1386_COLUMNS * MXT1386_PAGES_PER_COLUMN;
+   else
+   dbg->t37_pages = DIV_ROUND_UP(data->xsize *
+ data->info.matrix_ysize *
+ sizeof(u16),
+ sizeof(dbg->t37_buf->data));
 
dbg->t37_buf = devm_kmalloc_array(>client->dev, dbg->t37_pages,
  sizeof(struct t37_debug), GFP_KERNEL);
-- 
2.5.0

--
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 v5 4/9] Input: atmel_mxt_ts - read touchscreen size

[Nick Dyer]

The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.

Note: this does not read the XORIGIN/YORIGIN fields so it assumes that
the touchscreen starts at (0,0)

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 42 +++-
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 7780d38..8ef61d7 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -103,6 +103,8 @@ struct t7_config {
 
 /* MXT_TOUCH_MULTI_T9 field */
 #define MXT_T9_CTRL0
+#define MXT_T9_XSIZE   3
+#define MXT_T9_YSIZE   4
 #define MXT_T9_ORIENT  9
 #define MXT_T9_RANGE   18
 
@@ -150,7 +152,9 @@ struct t37_debug {
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
 #define MXT_T100_TCHAUX3
+#define MXT_T100_XSIZE 9
 #define MXT_T100_XRANGE13
+#define MXT_T100_YSIZE 20
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
@@ -259,6 +263,8 @@ struct mxt_data {
unsigned int max_x;
unsigned int max_y;
bool xy_switch;
+   u8 xsize;
+   u8 ysize;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1714,6 +1720,18 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return -EINVAL;
 
error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
   object->start_address + MXT_T9_RANGE,
   sizeof(range), );
if (error)
@@ -1763,6 +1781,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
 
data->max_y = get_unaligned_le16(_y);
 
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
/* read orientation config */
error =  __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
@@ -2121,7 +2151,7 @@ static int mxt_convert_debug_pages(struct mxt_data *data, 
u16 *outbuf)
outbuf[i] = mxt_get_debug_value(data, x, y);
 
/* Next value */
-   if (++x >= data->info.matrix_xsize) {
+   if (++x >= data->xsize) {
x = 0;
y++;
}
@@ -2276,8 +2306,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->info.matrix_xsize;
-   f->height = data->info.matrix_ysize;
+   f->width = data->xsize;
+   f->height = data->ysize;
f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
@@ -2392,9 +2422,9 @@ static void mxt_debug_init(struct mxt_data *data)
dbg->t37_address = object->start_address;
 
/* Calculate size of data and allocate buffer */
-   dbg->t37_nodes = data->info.matrix_xsize * data->info.matrix_ysize;
-   dbg->t37_pages = DIV_ROUND_UP(dbg->t37_nodes * sizeof(u16),
- sizeof(dbg->t37_buf->data));
+   dbg->t37_nodes = data->xsize * data->ysize;
+   dbg->t37_pages = DIV_ROUND_UP(data->xsize * data->info.matrix_ysize *
+ sizeof(u16), sizeof(dbg->t37_buf->data));
 
dbg->t37_buf = devm_kmalloc_array(>client->dev, dbg->t37_pages,
  sizeof(struct t37_debug), GFP_KERNEL);
-- 
2.5.0

--
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 v5 2/9] Input: atmel_mxt_ts - add support for T37 diagnostic data

[Nick Dyer]

Atmel maXTouch devices have a T37 object which can be used to read raw
touch deltas from the device. This consists of an array of 16-bit
integers, one for each node on the touchscreen matrix.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/Kconfig|   6 ++
 drivers/input/touchscreen/atmel_mxt_ts.c | 159 +++
 2 files changed, 165 insertions(+)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 8ecdc38..da96ecf 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -115,6 +115,12 @@ config TOUCHSCREEN_ATMEL_MXT
  To compile this driver as a module, choose M here: the
  module will be called atmel_mxt_ts.
 
+config TOUCHSCREEN_ATMEL_MXT_T37
+   bool "Support T37 Diagnostic Data"
+   depends on TOUCHSCREEN_ATMEL_MXT
+   help
+ Say Y here if you want support for the T37 Diagnostic Data object.
+
 config TOUCHSCREEN_AUO_PIXCIR
tristate "AUO in-cell touchscreen using Pixcir ICs"
depends on I2C
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 5af7907..0048233 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -124,6 +124,19 @@ struct t9_range {
 #define MXT_COMMS_CTRL 0
 #define MXT_COMMS_CMD  1
 
+/* MXT_DEBUG_DIAGNOSTIC_T37 */
+#define MXT_DIAGNOSTIC_PAGEUP  0x01
+#define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_SIZE128
+
+struct t37_debug {
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+   u8 mode;
+   u8 page;
+   u8 data[MXT_DIAGNOSTIC_SIZE];
+#endif
+};
+
 /* Define for MXT_GEN_COMMAND_T6 */
 #define MXT_BOOT_VALUE 0xa5
 #define MXT_RESET_VALUE0x01
@@ -205,6 +218,14 @@ struct mxt_object {
u8 num_report_ids;
 } __packed;
 
+struct mxt_dbg {
+   u16 t37_address;
+   u16 diag_cmd_address;
+   struct t37_debug *t37_buf;
+   unsigned int t37_pages;
+   unsigned int t37_nodes;
+};
+
 /* Each client has this additional data */
 struct mxt_data {
struct i2c_client *client;
@@ -233,6 +254,7 @@ struct mxt_data {
u8 num_touchids;
u8 multitouch;
struct t7_config t7_cfg;
+   struct mxt_dbg dbg;
 
/* Cached parameters from object table */
u16 T5_address;
@@ -2043,6 +2065,141 @@ recheck:
return 0;
 }
 
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
+  unsigned int y)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int ofs, page;
+
+   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   page = ofs / MXT_DIAGNOSTIC_SIZE;
+   ofs %= MXT_DIAGNOSTIC_SIZE;
+
+   return get_unaligned_le16(>t37_buf[page].data[ofs]);
+}
+
+static int mxt_convert_debug_pages(struct mxt_data *data, u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int x = 0;
+   unsigned int y = 0;
+   unsigned int i;
+
+   for (i = 0; i < dbg->t37_nodes; i++) {
+   outbuf[i] = mxt_get_debug_value(data, x, y);
+
+   /* Next value */
+   if (++x >= data->info.matrix_xsize) {
+   x = 0;
+   y++;
+   }
+   }
+
+   return 0;
+}
+
+static int mxt_read_diagnostic_debug(struct mxt_data *data, u8 mode,
+u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   int retries = 0;
+   int page;
+   int ret;
+   u8 cmd = mode;
+   struct t37_debug *p;
+   u8 cmd_poll;
+
+   for (page = 0; page < dbg->t37_pages; page++) {
+   p = dbg->t37_buf + page;
+
+   ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
+   cmd);
+   if (ret)
+   return ret;
+
+   retries = 0;
+   msleep(20);
+wait_cmd:
+   /* Read back command byte */
+   ret = __mxt_read_reg(data->client, dbg->diag_cmd_address,
+sizeof(cmd_poll), _poll);
+   if (ret)
+   return ret;
+
+   /* Field is cleared once the command has been processed */
+   if (cmd_poll) {
+   if (retries++ > 100)
+   return -EINVAL;
+
+   msleep(20);
+   goto wait_cmd;
+   }
+
+   /* Read T37 page */
+   ret = __mxt_read_reg(data->client, dbg->t37_address,
+sizeof(struct t37_debug), p);
+   if (ret)
+   return ret;
+
+   if (p->mode != mode || p->page != page) {
+   dev_err(>client->dev, "T37 page mismatch\n");
+   return 

[PATCH v5 5/9] Input: atmel_mxt_ts - handle diagnostic data orientation

[Nick Dyer]

Invert the diagnostic data to match the orientation of the input device.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 8ef61d7..3f7e357 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -125,6 +125,8 @@ struct t9_range {
 
 /* MXT_TOUCH_MULTI_T9 orient */
 #define MXT_T9_ORIENT_SWITCH   (1 << 0)
+#define MXT_T9_ORIENT_INVERTX  (1 << 1)
+#define MXT_T9_ORIENT_INVERTY  (1 << 2)
 
 /* MXT_SPT_COMMSCONFIG_T18 */
 #define MXT_COMMS_CTRL 0
@@ -158,6 +160,8 @@ struct t37_debug {
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
+#define MXT_T100_CFG_INVERTY   BIT(6)
+#define MXT_T100_CFG_INVERTX   BIT(7)
 
 #define MXT_T100_TCHAUX_VECT   BIT(0)
 #define MXT_T100_TCHAUX_AMPL   BIT(1)
@@ -262,6 +266,8 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+   bool invertx;
+   bool inverty;
bool xy_switch;
u8 xsize;
u8 ysize;
@@ -1747,6 +1753,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return error;
 
data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
+   data->invertx = orient & MXT_T9_ORIENT_INVERTX;
+   data->inverty = orient & MXT_T9_ORIENT_INVERTY;
 
return 0;
 }
@@ -1801,6 +1809,8 @@ static int mxt_read_t100_config(struct mxt_data *data)
return error;
 
data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+   data->invertx = cfg & MXT_T100_CFG_INVERTX;
+   data->inverty = cfg & MXT_T100_CFG_INVERTY;
 
/* allocate aux bytes */
error =  __mxt_read_reg(client,
@@ -2145,13 +2155,19 @@ static int mxt_convert_debug_pages(struct mxt_data 
*data, u16 *outbuf)
struct mxt_dbg *dbg = >dbg;
unsigned int x = 0;
unsigned int y = 0;
-   unsigned int i;
+   unsigned int i, rx, ry;
 
for (i = 0; i < dbg->t37_nodes; i++) {
-   outbuf[i] = mxt_get_debug_value(data, x, y);
+   /* Handle orientation */
+   rx = data->xy_switch ? y : x;
+   ry = data->xy_switch ? x : y;
+   rx = data->invertx ? (data->xsize - 1 - rx) : rx;
+   ry = data->inverty ? (data->ysize - 1 - ry) : ry;
+
+   outbuf[i] = mxt_get_debug_value(data, rx, ry);
 
/* Next value */
-   if (++x >= data->xsize) {
+   if (++x >= (data->xy_switch ? data->ysize : data->xsize)) {
x = 0;
y++;
}
@@ -2306,8 +2322,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->xsize;
-   f->height = data->ysize;
+   f->width = data->xy_switch ? data->ysize : data->xsize;
+   f->height = data->xy_switch ? data->xsize : data->ysize;
f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
-- 
2.5.0

--
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 v5 7/9] Input: atmel_mxt_ts - add support for reference data

[Nick Dyer]

There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 58 
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 739d138..f733785 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -135,6 +135,7 @@ struct t9_range {
 /* MXT_DEBUG_DIAGNOSTIC_T37 */
 #define MXT_DIAGNOSTIC_PAGEUP  0x01
 #define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_REFS0x11
 #define MXT_DIAGNOSTIC_SIZE128
 
 #define MXT_FAMILY_1386160
@@ -249,6 +250,12 @@ struct mxt_dbg {
int input;
 };
 
+enum v4l_dbg_inputs {
+   MXT_V4L_INPUT_DELTAS,
+   MXT_V4L_INPUT_REFS,
+   MXT_V4L_INPUT_MAX,
+};
+
 static const struct v4l2_file_operations mxt_video_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
@@ -2273,6 +2280,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
u16 *ptr;
int ret;
+   u8 mode;
 
ptr = vb2_plane_vaddr(vb, 0);
if (!ptr) {
@@ -2280,7 +2288,18 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
goto fault;
}
 
-   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   switch (data->dbg.input) {
+   case MXT_V4L_INPUT_DELTAS:
+   default:
+   mode = MXT_DIAGNOSTIC_DELTAS;
+   break;
+
+   case MXT_V4L_INPUT_REFS:
+   mode = MXT_DIAGNOSTIC_REFS;
+   break;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, mode, ptr);
if (ret)
goto fault;
 
@@ -2325,11 +2344,20 @@ static int mxt_vidioc_querycap(struct file *file, void 
*priv,
 static int mxt_vidioc_enum_input(struct file *file, void *priv,
   struct v4l2_input *i)
 {
-   if (i->index > 0)
+   if (i->index >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
i->type = V4L2_INPUT_TYPE_TOUCH;
-   strlcpy(i->name, "Mutual References", sizeof(i->name));
+
+   switch (i->index) {
+   case MXT_V4L_INPUT_REFS:
+   strlcpy(i->name, "Mutual References", sizeof(i->name));
+   break;
+   case MXT_V4L_INPUT_DELTAS:
+   strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
+   break;
+   }
+
return 0;
 }
 
@@ -2337,12 +2365,16 @@ static int mxt_set_input(struct mxt_data *data, 
unsigned int i)
 {
struct v4l2_pix_format *f = >dbg.format;
 
-   if (i > 0)
+   if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
+   if (i == MXT_V4L_INPUT_DELTAS)
+   f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
+   else
+   f->pixelformat = V4L2_TCH_FMT_TU16;
+
f->width = data->xy_switch ? data->ysize : data->xsize;
f->height = data->xy_switch ? data->xsize : data->ysize;
-   f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
f->bytesperline = f->width * sizeof(u16);
@@ -2380,10 +2412,22 @@ static int mxt_vidioc_fmt(struct file *file, void 
*priv, struct v4l2_format *f)
 static int mxt_vidioc_enum_fmt(struct file *file, void *priv,
 struct v4l2_fmtdesc *fmt)
 {
-   if (fmt->index > 0 || fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   if (fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   return -EINVAL;
+
+   switch (fmt->index) {
+   case 0:
+   fmt->pixelformat = V4L2_TCH_FMT_TU16;
+   break;
+
+   case 1:
+   fmt->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
+   break;
+
+   default:
return -EINVAL;
+   }
 
-   fmt->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
return 0;
 }
 
-- 
2.5.0

--
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 v5 9/9] Input: sur40 - use new V4L2 touch input type

[Nick Dyer]

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/sur40.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index 880c40b..841e045 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -599,7 +599,7 @@ static int sur40_probe(struct usb_interface *interface,
sur40->vdev.queue = >queue;
video_set_drvdata(>vdev, sur40);
 
-   error = video_register_device(>vdev, VFL_TYPE_GRABBER, -1);
+   error = video_register_device(>vdev, VFL_TYPE_TOUCH, -1);
if (error) {
dev_err(>dev,
"Unable to register video subdevice.");
@@ -763,7 +763,7 @@ static int sur40_vidioc_enum_input(struct file *file, void 
*priv,
 {
if (i->index != 0)
return -EINVAL;
-   i->type = V4L2_INPUT_TYPE_CAMERA;
+   i->type = V4L2_INPUT_TYPE_TOUCH;
i->std = V4L2_STD_UNKNOWN;
strlcpy(i->name, "In-Cell Sensor", sizeof(i->name));
i->capabilities = 0;
@@ -794,7 +794,7 @@ static int sur40_vidioc_enum_fmt(struct file *file, void 
*priv,
if (f->index != 0)
return -EINVAL;
strlcpy(f->description, "8-bit greyscale", sizeof(f->description));
-   f->pixelformat = V4L2_PIX_FMT_GREY;
+   f->pixelformat = V4L2_TCH_FMT_TU08;
f->flags = 0;
return 0;
 }
@@ -802,7 +802,7 @@ static int sur40_vidioc_enum_fmt(struct file *file, void 
*priv,
 static int sur40_vidioc_enum_framesizes(struct file *file, void *priv,
struct v4l2_frmsizeenum *f)
 {
-   if ((f->index != 0) || (f->pixel_format != V4L2_PIX_FMT_GREY))
+   if ((f->index != 0) || (f->pixel_format != V4L2_TCH_FMT_TU08))
return -EINVAL;
 
f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
@@ -814,7 +814,7 @@ static int sur40_vidioc_enum_framesizes(struct file *file, 
void *priv,
 static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
struct v4l2_frmivalenum *f)
 {
-   if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+   if ((f->index > 1) || (f->pixel_format != V4L2_TCH_FMT_TU08)
|| (f->width  != sur40_video_format.width)
|| (f->height != sur40_video_format.height))
return -EINVAL;
@@ -903,7 +903,7 @@ static const struct video_device sur40_video_device = {
 };
 
 static const struct v4l2_pix_format sur40_video_format = {
-   .pixelformat = V4L2_PIX_FMT_GREY,
+   .pixelformat = V4L2_TCH_FMT_TU08,
.width  = SENSOR_RES_X / 2,
.height = SENSOR_RES_Y / 2,
.field = V4L2_FIELD_NONE,
-- 
2.5.0

--
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 v5 8/9] Input: synaptics-rmi4 - add support for F54 diagnostics

[Nick Dyer]

Function 54 implements access to various RMI4 diagnostic features.

This patch adds support for retrieving this data. It registers a V4L2
device to output the data to user space.

Signed-off-by: Nick Dyer 
---
 drivers/input/rmi4/Kconfig  |  11 +
 drivers/input/rmi4/Makefile |   1 +
 drivers/input/rmi4/rmi_bus.c|   3 +
 drivers/input/rmi4/rmi_driver.h |   1 +
 drivers/input/rmi4/rmi_f54.c| 730 
 5 files changed, 746 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_f54.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..f3418b6 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -61,3 +61,14 @@ config RMI4_F30
 
  Function 30 provides GPIO and LED support for RMI4 devices. This
  includes support for buttons on TouchPads and ClickPads.
+
+config RMI4_F54
+   bool "RMI4 Function 54 (Analog diagnostics)"
+   depends on RMI4_CORE
+   depends on VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
+   help
+ Say Y here if you want to add support for RMI4 function 54
+
+ Function 54 provides access to various diagnostic features in certain
+ RMI4 touch sensors.
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..0bafc85 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -7,6 +7,7 @@ rmi_core-$(CONFIG_RMI4_2D_SENSOR) += rmi_2d_sensor.o
 rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
 rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
+rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index b368b05..3aedc65 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -315,6 +315,9 @@ static struct rmi_function_handler *fn_handlers[] = {
 #ifdef CONFIG_RMI4_F30
_f30_handler,
 #endif
+#ifdef CONFIG_RMI4_F54
+   _f54_handler,
+#endif
 };
 
 static void __rmi_unregister_function_handlers(int start_idx)
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 6e140fa..8dfbebe 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -102,4 +102,5 @@ extern struct rmi_function_handler rmi_f01_handler;
 extern struct rmi_function_handler rmi_f11_handler;
 extern struct rmi_function_handler rmi_f12_handler;
 extern struct rmi_function_handler rmi_f30_handler;
+extern struct rmi_function_handler rmi_f54_handler;
 #endif
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
new file mode 100644
index 000..df4c821
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -0,0 +1,730 @@
+/*
+ * Copyright (c) 2012-2015 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define F54_NAME   "rmi4_f54"
+
+/* F54 data offsets */
+#define F54_REPORT_DATA_OFFSET  3
+#define F54_FIFO_OFFSET 1
+#define F54_NUM_TX_OFFSET   1
+#define F54_NUM_RX_OFFSET   0
+
+/* F54 commands */
+#define F54_GET_REPORT  1
+#define F54_FORCE_CAL   2
+
+/* Fixed sizes of reports */
+#define F54_QUERY_LEN  27
+
+/* F54 capabilities */
+#define F54_CAP_BASELINE   (1 << 2)
+#define F54_CAP_IMAGE8 (1 << 3)
+#define F54_CAP_IMAGE16(1 << 6)
+
+enum rmi_f54_report_type {
+   F54_REPORT_NONE = 0,
+   F54_8BIT_IMAGE = 1,
+   F54_16BIT_IMAGE = 2,
+   F54_RAW_16BIT_IMAGE = 3,
+   F54_TRUE_BASELINE = 9,
+   F54_FULL_RAW_CAP = 19,
+   F54_FULL_RAW_CAP_RX_COUPLING_COMP = 20,
+   F54_MAX_REPORT_TYPE,
+};
+
+const char *rmi_f54_report_type_names[] = {
+   [F54_REPORT_NONE]   = "No report",
+   [F54_8BIT_IMAGE]= "8 bit image",
+   [F54_16BIT_IMAGE]   = "16 bit image",
+   [F54_RAW_16BIT_IMAGE]   = "Raw 16 bit image",
+   [F54_TRUE_BASELINE] = "True baseline",
+   [F54_FULL_RAW_CAP]  = "Full raw cap",
+   [F54_FULL_RAW_CAP_RX_COUPLING_COMP]
+   = "Full raw cap RX coupling comp",
+   [F54_MAX_REPORT_TYPE]   = "Max report type",
+};
+
+#define f54_reptype_name(a) (((unsigned)(a)) < 
ARRAY_SIZE(rmi_f54_report_type_names) ? rmi_f54_report_type_names[a] : 
"unknown")
+
+struct rmi_f54_reports {
+   int start;
+   int size;
+};
+
+struct f54_data {
+   struct rmi_function *fn;
+
+   u8 qry[F54_QUERY_LEN];
+   u8 num_rx_electrodes;
+   u8 num_tx_electrodes;
+   u8 capabilities;
+   u16 

[PATCH v5 3/9] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[Nick Dyer]

Register a video device to output T37 diagnostic data.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/Kconfig|   6 +-
 drivers/input/touchscreen/atmel_mxt_ts.c | 244 +++
 2 files changed, 248 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index da96ecf..7c1c5ec 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -117,9 +117,11 @@ config TOUCHSCREEN_ATMEL_MXT
 
 config TOUCHSCREEN_ATMEL_MXT_T37
bool "Support T37 Diagnostic Data"
-   depends on TOUCHSCREEN_ATMEL_MXT
+   depends on TOUCHSCREEN_ATMEL_MXT && VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
help
- Say Y here if you want support for the T37 Diagnostic Data object.
+ Say Y here if you want support to output data from the T37
+ Diagnostic Data object using a V4L device.
 
 config TOUCHSCREEN_AUO_PIXCIR
tristate "AUO in-cell touchscreen using Pixcir ICs"
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0048233..7780d38 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* Firmware files */
 #define MXT_FW_NAME"maxtouch.fw"
@@ -224,6 +228,23 @@ struct mxt_dbg {
struct t37_debug *t37_buf;
unsigned int t37_pages;
unsigned int t37_nodes;
+
+   struct v4l2_device v4l2;
+   struct v4l2_pix_format format;
+   struct video_device vdev;
+   struct vb2_queue queue;
+   struct mutex lock;
+   int input;
+};
+
+static const struct v4l2_file_operations mxt_video_fops = {
+   .owner = THIS_MODULE,
+   .open = v4l2_fh_open,
+   .release = vb2_fop_release,
+   .unlocked_ioctl = video_ioctl2,
+   .read = vb2_fop_read,
+   .mmap = vb2_fop_mmap,
+   .poll = vb2_fop_poll,
 };
 
 /* Each client has this additional data */
@@ -279,6 +300,11 @@ struct mxt_data {
struct completion crc_completion;
 };
 
+struct mxt_vb2_buffer {
+   struct vb2_buffer   vb;
+   struct list_headlist;
+};
+
 static size_t mxt_obj_size(const struct mxt_object *obj)
 {
return obj->size_minus_one + 1;
@@ -1525,6 +1551,11 @@ static void mxt_free_input_device(struct mxt_data *data)
 
 static void mxt_free_object_table(struct mxt_data *data)
 {
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+   video_unregister_device(>dbg.vdev);
+   v4l2_device_unregister(>dbg.v4l2);
+#endif
+
kfree(data->object_table);
data->object_table = NULL;
kfree(data->msg_buf);
@@ -2157,10 +2188,191 @@ wait_cmd:
return mxt_convert_debug_pages(data, outbuf);
 }
 
+static int mxt_queue_setup(struct vb2_queue *q,
+  unsigned int *nbuffers, unsigned int *nplanes,
+  unsigned int sizes[], void *alloc_ctxs[])
+{
+   struct mxt_data *data = q->drv_priv;
+   size_t size = data->dbg.t37_nodes * sizeof(u16);
+
+   if (*nplanes)
+   return sizes[0] < size ? -EINVAL : 0;
+
+   *nplanes = 1;
+   sizes[0] = size;
+
+   return 0;
+}
+
+static void mxt_buffer_queue(struct vb2_buffer *vb)
+{
+   struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
+   u16 *ptr;
+   int ret;
+
+   ptr = vb2_plane_vaddr(vb, 0);
+   if (!ptr) {
+   dev_err(>client->dev, "Error acquiring frame ptr\n");
+   goto fault;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   if (ret)
+   goto fault;
+
+   vb2_set_plane_payload(vb, 0, data->dbg.t37_nodes * sizeof(u16));
+   vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+   return;
+
+fault:
+   vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+}
+
+/* V4L2 structures */
+static const struct vb2_ops mxt_queue_ops = {
+   .queue_setup= mxt_queue_setup,
+   .buf_queue  = mxt_buffer_queue,
+   .wait_prepare   = vb2_ops_wait_prepare,
+   .wait_finish= vb2_ops_wait_finish,
+};
+
+static const struct vb2_queue mxt_queue = {
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+   .io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ,
+   .buf_struct_size = sizeof(struct mxt_vb2_buffer),
+   .ops = _queue_ops,
+   .mem_ops = _vmalloc_memops,
+   .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
+   .min_buffers_needed = 1,
+};
+
+static int mxt_vidioc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+   struct mxt_data *data = video_drvdata(file);
+
+   strlcpy(cap->driver, "atmel_mxt_ts", sizeof(cap->driver));
+   strlcpy(cap->card, "atmel_mxt_ts touch", sizeof(cap->card));
+   snprintf(cap->bus_info, 

Re: [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

[Nick Dyer]

On 22/06/2016 21:38, Florian Echtler wrote:
> On Wed, 22 Jun 2016, Nick Dyer wrote:
> 
>> On 22/06/2016 12:48, Florian Echtler wrote:
>>> On 20.06.2016 14:00, Hans Verkuil wrote:
 On 06/17/2016 04:16 PM, Nick Dyer wrote:
>
> Use a new device prefix v4l-touch for these devices, to stop generic
> capture software from treating them as webcams.
>>
>>> Come to think of it, wouldn't it make sense to expose the other touch
>>> devices as generic frame grabbers, too, so you can easily view the debug
>>> output with any generic tool like cheese?
>>
>> While I like the idea of being able to use the generic tools, I think we
>> needed to do something to stop these devices turning up in e.g. video
>> conferencing software - it would cause a lot of confusion. There's nothing
>> stopping particular tools adding the necessary code to handle touch devices
>> if they feel their users want it.
> 
> Just to clarify: from the userspace point-of-view, would this change simply
> modify the prefix of the device node (i.e. /dev/video1 -> /dev/v4l-touch1),
> or would it somehow affect the API? If it's just the device node name, then
> that shouldn't be a problem after all, because e.g. reacTIVision requires
> you to specify the exact camera to be used anyway.

With the changes that Hans Verkuil has asked me to do:
* The device node is /dev/v4l-touch0-255
* There are several new formats eg. V4L2_TCH_FMT_DELTA_TD16 (16 bit deltas)
* I've defined new types VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE,
V4L2_INPUT_TYPE_TOUCH

We're just testing the changes, I hope to post an updated version soon.
--
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 v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

[Florian Echtler]

On Wed, 22 Jun 2016, Nick Dyer wrote:


On 22/06/2016 12:48, Florian Echtler wrote:

On 20.06.2016 14:00, Hans Verkuil wrote:

On 06/17/2016 04:16 PM, Nick Dyer wrote:


Use a new device prefix v4l-touch for these devices, to stop generic
capture software from treating them as webcams.



Come to think of it, wouldn't it make sense to expose the other touch
devices as generic frame grabbers, too, so you can easily view the debug
output with any generic tool like cheese?


While I like the idea of being able to use the generic tools, I think we
needed to do something to stop these devices turning up in e.g. video
conferencing software - it would cause a lot of confusion. There's nothing
stopping particular tools adding the necessary code to handle touch devices
if they feel their users want it.


Just to clarify: from the userspace point-of-view, would this change 
simply modify the prefix of the device node (i.e. /dev/video1 -> 
/dev/v4l-touch1), or would it somehow affect the API? If it's just the 
device node name, then that shouldn't be a problem after all, because e.g. 
reacTIVision requires you to specify the exact camera to be used anyway.


Florian
--
"_Nothing_ brightens up my morning. Coffee simply provides a shade of
grey just above the pitch-black of the infinite depths of the _abyss_."
--
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: dvb usb stick Hauppauge WinTV-soloHD

[Olli Salonen]

Hi Thomas,

I made some more investigation and figured out that you have a DVB-T2
mux at 642 MHz in Berlin, and can also see that your w_scan actually
locks on that DVB-T2 mux as you wrote. Sorry, I did not read properly
what you were saying in the beginning.

Then it should be just a question of finding software that will work
with your DVB-T2 channels as well. I've got no experience of VLC, but
as far as I have understood it should support DVB-T2 as well. I've
used dvbv5-zap and tvheadend with good success, but there are many
others as well. Basically it is important the software implements the
version 5 of the DVB API (DVBv5) instead of the older version 3.

Cheers,
-olli



On 22 June 2016 at 22:10, Olli Salonen  wrote:
> Hi Thomas,
>
> Ok, the correct firmwares are there:
> [  101.423697] si2168 11-0064: found a 'Silicon Labs Si2168-B40'
> [  101.428693] si2168 11-0064: downloading firmware from file
> 'dvb-demod-si2168-b40-01.fw'
> [  101.657999] si2168 11-0064: firmware version: 4.0.11
> [  101.661225] si2157 12-0060: found a 'Silicon Labs Si2157-A30'
> [  101.709738] si2157 12-0060: firmware version: 3.0.5
>
> Basically everything looks good. Does this work on a Windows computer
> using the same antenna cable and the same USB tuner?
>
> DVB-T2 support in w_scan has been evolving also, so make sure you've
> got quite recent version.
>
> I've found that dvbv5-scan does the best job when scanning for
> channels. However that needs initial scan table to start with. The
> initial scan tables for Berlin don't seem to contain any DVB-T2 muxes
> though: https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-t/de-Berlin
> This means they're probably a bit out  of date. If you know the DVB-T2
> mux details, you can add them yourself and try dvbv5-scan.
>
> Cheers,
> -olli
>
> On 18 June 2016 at 20:17, Thomas Stein  wrote:
>> Hi Olli.
>>
>> Thanks for your answer.
>>
>> Here we go.
>>
>> [0.00] Linux version 4.6.2 (root@rather) (gcc version 5.3.0 (Gentoo
>> 5.3.0 p1.0, pie-0.6.5) ) #3 SMP Sat Jun 18 13:34:40 CEST 2016
>> [0.00] Command line: BOOT_IMAGE=/kernel-4.6.2 root=/dev/sda3 ro
>> net.ifnames=0
>> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
>> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
>> registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832
>> bytes, using 'standard' format.
>> [0.00] x86/fpu: Using 'eager' FPU context switches.
>> [0.00] e820: BIOS-provided physical RAM map:
>> [0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
>> [0.00] BIOS-e820: [mem 0x0009d000-0x0009]
>> reserved
>> [0.00] BIOS-e820: [mem 0x000e-0x000f]
>> reserved
>> [0.00] BIOS-e820: [mem 0x0010-0xce20] usable
>> [0.00] BIOS-e820: [mem 0xce21-0xdcd3efff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xdcd3f000-0xdce7efff] ACPI
>> NVS
>> [0.00] BIOS-e820: [mem 0xdce7f000-0xdcefefff] ACPI
>> data
>> [0.00] BIOS-e820: [mem 0xdceff000-0xdfa0]
>> reserved
>> [0.00] BIOS-e820: [mem 0xf800-0xfbff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfe101000-0xfe112fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1]
>> reserved
>> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0xffc0-0x]
>> reserved
>> [0.00] BIOS-e820: [mem 0x0001-0x00021f5f] usable
>> [0.00] NX (Execute Disable) protection: active
>> [0.00] SMBIOS 2.7 present.
>> [0.00] DMI: LENOVO 20A7005MGE/20A7005MGE, BIOS GRET46WW (1.23 )
>> 11/04/2015
>> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
>> [0.00] e820: remove [mem 0x000a-0x000f] usable
>> [0.00] e820: last_pfn = 0x21f600 max_arch_pfn = 0x4
>> [0.00] MTRR default type: write-back
>> [0.00] MTRR fixed ranges enabled:
>> [0.00]   0-9 write-back
>> [0.00]   A-B uncachable
>> [0.00]   C-F write-protect
>> [0.00] MTRR variable ranges enabled:
>> [0.00]   0 base 00E000 mask 7FE000 uncachable
>> [0.00]   1 base 00DE00 mask 7FFE00 uncachable
>> [0.00]   2 

[RESEND PATCH v2 3/5] ir-rx51: use PWM framework instead of OMAP dmtimer

[Ivaylo Dimitrov]

Convert driver to use PWM framework instead of calling dmtimer functions
directly for PWM timer. Remove paragraph about writing to the Free Software
Foundation's mailing address while at it.

Signed-off-by: Ivaylo Dimitrov 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |  1 -
 arch/arm/mach-omap2/pdata-quirks.c   |  1 -
 drivers/media/rc/ir-rx51.c   | 85 ++--
 include/linux/platform_data/media/ir-rx51.h  |  2 -
 4 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a70739..e487575 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1242,7 +1242,6 @@ static struct pwm_omap_dmtimer_pdata __maybe_unused 
pwm_dmtimer_pdata = {
 #if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
 static struct lirc_rx51_platform_data rx51_lirc_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
-   .pwm_timer = 9, /* Use GPT 9 for CIR */
 #if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
.dmtimer = _dmtimer_pdata,
 #endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 6571ad9..278bb8f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -491,7 +491,6 @@ static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
 
 static struct lirc_rx51_platform_data __maybe_unused rx51_lirc_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
-   .pwm_timer = 9, /* Use GPT 9 for CIR */
 #if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
.dmtimer = _dmtimer_pdata,
 #endif
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index da839c3..5096ef3 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -12,13 +12,7 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
  */
-
 #include 
 #include 
 #include 
@@ -26,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -43,7 +38,7 @@
 #define TIMER_MAX_VALUE 0x
 
 struct lirc_rx51 {
-   pwm_omap_dmtimer *pwm_timer;
+   struct pwm_device *pwm;
pwm_omap_dmtimer *pulse_timer;
struct pwm_omap_dmtimer_pdata *dmtimer;
struct device*dev;
@@ -58,32 +53,28 @@ struct lirc_rx51 {
int wbuf[WBUF_LEN];
int wbuf_index;
unsigned long   device_is_open;
-   int pwm_timer_num;
 };
 
 static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
 {
-   lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
-   PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE);
+   pwm_enable(lirc_rx51->pwm);
 }
 
 static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
 {
-   lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
-   PWM_OMAP_DMTIMER_TRIGGER_NONE);
+   pwm_disable(lirc_rx51->pwm);
 }
 
 static int init_timing_params(struct lirc_rx51 *lirc_rx51)
 {
-   u32 load, match;
-
-   load = -(lirc_rx51->fclk_khz * 1000 / lirc_rx51->freq);
-   match = -(lirc_rx51->duty_cycle * -load / 100);
-   lirc_rx51->dmtimer->set_load(lirc_rx51->pwm_timer, 1, load);
-   lirc_rx51->dmtimer->set_match(lirc_rx51->pwm_timer, 1, match);
-   lirc_rx51->dmtimer->write_counter(lirc_rx51->pwm_timer, TIMER_MAX_VALUE 
- 2);
-   lirc_rx51->dmtimer->start(lirc_rx51->pwm_timer);
+   struct pwm_device *pwm = lirc_rx51->pwm;
+   int duty, period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, lirc_rx51->freq);
+
+   duty = DIV_ROUND_CLOSEST(lirc_rx51->duty_cycle * period, 100);
lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer, 0);
+
+   pwm_config(pwm, duty, period);
+
lirc_rx51->dmtimer->start(lirc_rx51->pulse_timer);
 
lirc_rx51->match = 0;
@@ -165,7 +156,7 @@ end:
/* Stop TX here */
lirc_rx51_off(lirc_rx51);
lirc_rx51->wbuf_index = -1;
-   lirc_rx51->dmtimer->stop(lirc_rx51->pwm_timer);
+
lirc_rx51->dmtimer->stop(lirc_rx51->pulse_timer);
lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer, 0);
wake_up_interruptible(_rx51->wqueue);
@@ -176,13 +167,13 @@ end:
 static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51)
 {
struct clk *clk_fclk;
-   int retval, pwm_timer = lirc_rx51->pwm_timer_num;
+   int retval;
 
-   lirc_rx51->pwm_timer = lirc_rx51->dmtimer->request_specific(pwm_timer);
-   if (lirc_rx51->pwm_timer == NULL) {
-

[RESEND PATCH v2 1/5] ir-rx51: Fix build after multiarch changes broke it

[Ivaylo Dimitrov]

The ir-rx51 driver for n900 has been disabled since the multiarch
changes as plat include directory no longer is SoC specific.

Let's fix it with minimal changes to pass the dmtimer calls in
pdata. Then the following changes can be done while things can
be tested to be working for each change:

1. Change the non-pwm dmtimer to use just hrtimer if possible

2. Change the pwm dmtimer to use Linux PWM API with the new
   drivers/pwm/pwm-omap-dmtimer.c and remove the direct calls
   to dmtimer functions

3. Parse configuration from device tree and drop the pdata

Note compilation of this depends on the previous patch
"ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51".

Cc: Mauro Carvalho Chehab 
Cc: Neil Armstrong 
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren 
Signed-off-by: Ivaylo Dimitrov 
Acked-by: Pavel Machek 
---
 drivers/media/rc/Kconfig   |  2 +-
 drivers/media/rc/ir-rx51.c | 99 +-
 2 files changed, 54 insertions(+), 47 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index bd4d685..370e16e 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -336,7 +336,7 @@ config IR_TTUSBIR
 
 config IR_RX51
tristate "Nokia N900 IR transmitter diode"
-   depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && 
!ARCH_MULTIPLATFORM
+   depends on OMAP_DM_TIMER && PWM_OMAP_DMTIMER && ARCH_OMAP2PLUS && LIRC
---help---
   Say Y or M here if you want to enable support for the IR
   transmitter diode built in the Nokia N900 (RX51) device.
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 4e1711a..da839c3 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -19,6 +19,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -26,11 +27,9 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 #include 
+#include 
 #include 
 
 #define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE |  \
@@ -44,8 +43,9 @@
 #define TIMER_MAX_VALUE 0x
 
 struct lirc_rx51 {
-   struct omap_dm_timer *pwm_timer;
-   struct omap_dm_timer *pulse_timer;
+   pwm_omap_dmtimer *pwm_timer;
+   pwm_omap_dmtimer *pulse_timer;
+   struct pwm_omap_dmtimer_pdata *dmtimer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
wait_queue_head_t wqueue;
@@ -63,14 +63,14 @@ struct lirc_rx51 {
 
 static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
 {
-   omap_dm_timer_set_pwm(lirc_rx51->pwm_timer, 0, 1,
- OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE);
+   lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
+   PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE);
 }
 
 static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
 {
-   omap_dm_timer_set_pwm(lirc_rx51->pwm_timer, 0, 1,
- OMAP_TIMER_TRIGGER_NONE);
+   lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
+   PWM_OMAP_DMTIMER_TRIGGER_NONE);
 }
 
 static int init_timing_params(struct lirc_rx51 *lirc_rx51)
@@ -79,12 +79,12 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
 
load = -(lirc_rx51->fclk_khz * 1000 / lirc_rx51->freq);
match = -(lirc_rx51->duty_cycle * -load / 100);
-   omap_dm_timer_set_load(lirc_rx51->pwm_timer, 1, load);
-   omap_dm_timer_set_match(lirc_rx51->pwm_timer, 1, match);
-   omap_dm_timer_write_counter(lirc_rx51->pwm_timer, TIMER_MAX_VALUE - 2);
-   omap_dm_timer_start(lirc_rx51->pwm_timer);
-   omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
-   omap_dm_timer_start(lirc_rx51->pulse_timer);
+   lirc_rx51->dmtimer->set_load(lirc_rx51->pwm_timer, 1, load);
+   lirc_rx51->dmtimer->set_match(lirc_rx51->pwm_timer, 1, match);
+   lirc_rx51->dmtimer->write_counter(lirc_rx51->pwm_timer, TIMER_MAX_VALUE 
- 2);
+   lirc_rx51->dmtimer->start(lirc_rx51->pwm_timer);
+   lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer, 0);
+   lirc_rx51->dmtimer->start(lirc_rx51->pulse_timer);
 
lirc_rx51->match = 0;
 
@@ -100,15 +100,15 @@ static int pulse_timer_set_timeout(struct lirc_rx51 
*lirc_rx51, int usec)
BUG_ON(usec < 0);
 
if (lirc_rx51->match == 0)
-   counter = omap_dm_timer_read_counter(lirc_rx51->pulse_timer);
+   counter = 
lirc_rx51->dmtimer->read_counter(lirc_rx51->pulse_timer);
else
counter = lirc_rx51->match;
 
counter += (u32)(lirc_rx51->fclk_khz * usec / (1000));
-   omap_dm_timer_set_match(lirc_rx51->pulse_timer, 1, counter);
-   omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer,
-OMAP_TIMER_INT_MATCH);
-   if 

[RESEND PATCH v2 0/5] ir-rx51 driver fixes

[Ivaylo Dimitrov]

ir-rx51 is a driver for Nokia N900 IR transmitter. The current series
fixes the remaining problems in the driver:

 - replace GP timer 9 with PWM framework usage
 - replace pulse width timer dmtimer usage with hrtimer
 - add DT support to the driver
 - add driver to the board DTS

Patch 2 is needed so the driver to function correctly, without it PWM
refuses to set the needed carrier frequency.

Changes compared to v1:
 - removed [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime
   functions when not needed.
 - DT compatible string changed to "nokia,n900-ir"

Ivaylo Dimitrov (5):
  ir-rx51: Fix build after multiarch changes broke it
  pwm: omap-dmtimer: Allow for setting dmtimer clock source
  ir-rx51: use PWM framework instead of OMAP dmtimer
  ir-rx51: add DT support to driver
  ir-rx51: use hrtimer instead of dmtimer

 .../devicetree/bindings/media/nokia,n900-ir|  20 ++
 .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt   |   4 +
 arch/arm/mach-omap2/board-rx51-peripherals.c   |   5 -
 arch/arm/mach-omap2/pdata-quirks.c |  10 +-
 drivers/media/rc/Kconfig   |   2 +-
 drivers/media/rc/ir-rx51.c | 229 +++--
 drivers/pwm/pwm-omap-dmtimer.c |  12 +-
 include/linux/platform_data/media/ir-rx51.h|   3 -
 8 files changed, 111 insertions(+), 174 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/nokia,n900-ir

-- 
1.9.1

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

[RESEND PATCH v2 4/5] ir-rx51: add DT support to driver

[Ivaylo Dimitrov]

With the upcoming removal of legacy boot, lets add support to one of the
last N900 drivers remaining without it. As the driver still uses omap
dmtimer, add auxdata as well.

Signed-off-by: Ivaylo Dimitrov 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/nokia,n900-ir  | 20 
 arch/arm/mach-omap2/pdata-quirks.c   |  6 +-
 drivers/media/rc/ir-rx51.c   | 11 ++-
 3 files changed, 31 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/nokia,n900-ir

diff --git a/Documentation/devicetree/bindings/media/nokia,n900-ir 
b/Documentation/devicetree/bindings/media/nokia,n900-ir
new file mode 100644
index 000..13a18ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nokia,n900-ir
@@ -0,0 +1,20 @@
+Device-Tree bindings for LIRC TX driver for Nokia N900(RX51)
+
+Required properties:
+   - compatible: should be "nokia,n900-ir".
+   - pwms: specifies PWM used for IR signal transmission.
+
+Example node:
+
+   pwm9: dmtimer-pwm@9 {
+   compatible = "ti,omap-dmtimer-pwm";
+   ti,timers = <>;
+   ti,clock-source = <0x00>; /* timer_sys_ck */
+   #pwm-cells = <3>;
+   };
+
+   ir: n900-ir {
+   compatible = "nokia,n900-ir";
+
+   pwms = < 0 26316 0>; /* 38000 Hz */
+   };
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 278bb8f..0d7b05a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -273,8 +273,6 @@ static struct platform_device omap3_rom_rng_device = {
},
 };
 
-static struct platform_device rx51_lirc_device;
-
 static void __init nokia_n900_legacy_init(void)
 {
hsmmc2_internal_input_clk();
@@ -293,10 +291,7 @@ static void __init nokia_n900_legacy_init(void)
 
pr_info("RX-51: Registering OMAP3 HWRNG device\n");
platform_device_register(_rom_rng_device);
-
}
-
-   platform_device_register(_lirc_device);
 }
 
 static void __init omap3_tao3530_legacy_init(void)
@@ -531,6 +526,7 @@ static struct of_dev_auxdata omap_auxdata_lookup[] 
__initdata = {
   _iommu_pdata),
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x4809c000, "4809c000.mmc", 
_pdata[0]),
OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x480b4000, "480b4000.mmc", 
_pdata[1]),
+   OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _lirc_data),
/* Only on am3517 */
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 5096ef3..1cbb43d 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -478,6 +479,14 @@ static int lirc_rx51_remove(struct platform_device *dev)
return lirc_unregister_driver(lirc_rx51_driver.minor);
 }
 
+static const struct of_device_id lirc_rx51_match[] = {
+   {
+   .compatible = "nokia,n900-ir",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, lirc_rx51_match);
+
 struct platform_driver lirc_rx51_platform_driver = {
.probe  = lirc_rx51_probe,
.remove = lirc_rx51_remove,
@@ -485,7 +494,7 @@ struct platform_driver lirc_rx51_platform_driver = {
.resume = lirc_rx51_resume,
.driver = {
.name   = DRIVER_NAME,
-   .owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(lirc_rx51_match),
},
 };
 module_platform_driver(lirc_rx51_platform_driver);
-- 
1.9.1

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

[RESEND PATCH v2 2/5] pwm: omap-dmtimer: Allow for setting dmtimer clock source

[Ivaylo Dimitrov]

OMAP GP timers can have different input clocks that allow different PWM
frequencies. However, there is no other way of setting the clock source but
through clocks or clock-names properties of the timer itself. This limits
PWM functionality to only the frequencies allowed by the particular clock
source. Allowing setting the clock source by PWM rather than by timer
allows different PWMs to have different ranges by not hard-wiring the clock
source to the timer.

Signed-off-by: Ivaylo Dimitrov 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt |  4 
 drivers/pwm/pwm-omap-dmtimer.c | 12 +++-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt 
b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
index 5befb53..2e53324 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
@@ -9,6 +9,10 @@ Required properties:
 
 Optional properties:
 - ti,prescaler: Should be a value between 0 and 7, see the timers datasheet
+- ti,clock-source: Set dmtimer parent clock, values between 0 and 2:
+  - 0x00 - high-frequency system clock (timer_sys_ck)
+  - 0x01 - 32-kHz always-on clock (timer_32k_ck)
+  - 0x02 - external clock (timer_ext_ck, OMAP2 only)
 
 Example:
pwm9: dmtimer-pwm@9 {
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 3e95090..5ad42f3 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -245,7 +245,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
struct pwm_omap_dmtimer_chip *omap;
struct pwm_omap_dmtimer_pdata *pdata;
pwm_omap_dmtimer *dm_timer;
-   u32 prescaler;
+   u32 v;
int status;
 
pdata = dev_get_platdata(>dev);
@@ -306,10 +306,12 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
if (pm_runtime_active(>dm_timer_pdev->dev))
omap->pdata->stop(omap->dm_timer);
 
-   /* setup dmtimer prescaler */
-   if (!of_property_read_u32(pdev->dev.of_node, "ti,prescaler",
-   ))
-   omap->pdata->set_prescaler(omap->dm_timer, prescaler);
+   if (!of_property_read_u32(pdev->dev.of_node, "ti,prescaler", ))
+   omap->pdata->set_prescaler(omap->dm_timer, v);
+
+   /* setup dmtimer clock source */
+   if (!of_property_read_u32(pdev->dev.of_node, "ti,clock-source", ))
+   omap->pdata->set_source(omap->dm_timer, v);
 
omap->chip.dev = >dev;
omap->chip.ops = _omap_dmtimer_ops;
-- 
1.9.1

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

[RESEND PATCH v2 5/5] ir-rx51: use hrtimer instead of dmtimer

[Ivaylo Dimitrov]

Drop dmtimer usage for pulse timer in favor of hrtimer. That allows
removing PWM dmitimer platform data usage.

Signed-off-by: Ivaylo Dimitrov 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   4 -
 arch/arm/mach-omap2/pdata-quirks.c   |   3 -
 drivers/media/rc/ir-rx51.c   | 166 ++-
 include/linux/platform_data/media/ir-rx51.h  |   1 -
 4 files changed, 37 insertions(+), 137 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e487575..a5ab712 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1242,10 +1242,6 @@ static struct pwm_omap_dmtimer_pdata __maybe_unused 
pwm_dmtimer_pdata = {
 #if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
 static struct lirc_rx51_platform_data rx51_lirc_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   .dmtimer = _dmtimer_pdata,
-#endif
-
 };
 
 static struct platform_device rx51_lirc_device = {
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 0d7b05a..7cc672b 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -486,9 +486,6 @@ static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
 
 static struct lirc_rx51_platform_data __maybe_unused rx51_lirc_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   .dmtimer = _dmtimer_pdata,
-#endif
 };
 
 static struct platform_device __maybe_unused rx51_lirc_device = {
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 1cbb43d..82fb6f2 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -22,10 +22,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 
 #define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE |  \
@@ -36,32 +36,26 @@
 
 #define WBUF_LEN 256
 
-#define TIMER_MAX_VALUE 0x
-
 struct lirc_rx51 {
struct pwm_device *pwm;
-   pwm_omap_dmtimer *pulse_timer;
-   struct pwm_omap_dmtimer_pdata *dmtimer;
+   struct hrtimer timer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
wait_queue_head_t wqueue;
 
-   unsigned long   fclk_khz;
unsigned intfreq;   /* carrier frequency */
unsigned intduty_cycle; /* carrier duty cycle */
-   unsigned intirq_num;
-   unsigned intmatch;
int wbuf[WBUF_LEN];
int wbuf_index;
unsigned long   device_is_open;
 };
 
-static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
+static inline void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
 {
pwm_enable(lirc_rx51->pwm);
 }
 
-static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
+static inline void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
 {
pwm_disable(lirc_rx51->pwm);
 }
@@ -72,61 +66,21 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
int duty, period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, lirc_rx51->freq);
 
duty = DIV_ROUND_CLOSEST(lirc_rx51->duty_cycle * period, 100);
-   lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer, 0);
 
pwm_config(pwm, duty, period);
 
-   lirc_rx51->dmtimer->start(lirc_rx51->pulse_timer);
-
-   lirc_rx51->match = 0;
-
return 0;
 }
 
-#define tics_after(a, b) ((long)(b) - (long)(a) < 0)
-
-static int pulse_timer_set_timeout(struct lirc_rx51 *lirc_rx51, int usec)
+static enum hrtimer_restart lirc_rx51_timer_cb(struct hrtimer *timer)
 {
-   int counter;
-
-   BUG_ON(usec < 0);
-
-   if (lirc_rx51->match == 0)
-   counter = 
lirc_rx51->dmtimer->read_counter(lirc_rx51->pulse_timer);
-   else
-   counter = lirc_rx51->match;
-
-   counter += (u32)(lirc_rx51->fclk_khz * usec / (1000));
-   lirc_rx51->dmtimer->set_match(lirc_rx51->pulse_timer, 1, counter);
-   lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer,
-  PWM_OMAP_DMTIMER_INT_MATCH);
-   if (tics_after(lirc_rx51->dmtimer->read_counter(lirc_rx51->pulse_timer),
-  counter)) {
-   return 1;
-   }
-   return 0;
-}
+   struct lirc_rx51 *lirc_rx51 =
+   container_of(timer, struct lirc_rx51, timer);
+   ktime_t now;
 
-static irqreturn_t lirc_rx51_interrupt_handler(int irq, void *ptr)
-{
-   unsigned int retval;
-   struct lirc_rx51 *lirc_rx51 = ptr;
-
-   retval = lirc_rx51->dmtimer->read_status(lirc_rx51->pulse_timer);
-   if (!retval)
-   return IRQ_NONE;
-
-   if (retval & ~PWM_OMAP_DMTIMER_INT_MATCH)
-   dev_err_ratelimited(lirc_rx51->dev,
-   ": 

Re: dvb usb stick Hauppauge WinTV-soloHD

[Olli Salonen]

Hi Thomas,

Ok, the correct firmwares are there:
[  101.423697] si2168 11-0064: found a 'Silicon Labs Si2168-B40'
[  101.428693] si2168 11-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
[  101.657999] si2168 11-0064: firmware version: 4.0.11
[  101.661225] si2157 12-0060: found a 'Silicon Labs Si2157-A30'
[  101.709738] si2157 12-0060: firmware version: 3.0.5

Basically everything looks good. Does this work on a Windows computer
using the same antenna cable and the same USB tuner?

DVB-T2 support in w_scan has been evolving also, so make sure you've
got quite recent version.

I've found that dvbv5-scan does the best job when scanning for
channels. However that needs initial scan table to start with. The
initial scan tables for Berlin don't seem to contain any DVB-T2 muxes
though: https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-t/de-Berlin
This means they're probably a bit out  of date. If you know the DVB-T2
mux details, you can add them yourself and try dvbv5-scan.

Cheers,
-olli

On 18 June 2016 at 20:17, Thomas Stein  wrote:
> Hi Olli.
>
> Thanks for your answer.
>
> Here we go.
>
> [0.00] Linux version 4.6.2 (root@rather) (gcc version 5.3.0 (Gentoo
> 5.3.0 p1.0, pie-0.6.5) ) #3 SMP Sat Jun 18 13:34:40 CEST 2016
> [0.00] Command line: BOOT_IMAGE=/kernel-4.6.2 root=/dev/sda3 ro
> net.ifnames=0
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832
> bytes, using 'standard' format.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
> [0.00] BIOS-e820: [mem 0x0009d000-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0xce20] usable
> [0.00] BIOS-e820: [mem 0xce21-0xdcd3efff]
> reserved
> [0.00] BIOS-e820: [mem 0xdcd3f000-0xdce7efff] ACPI
> NVS
> [0.00] BIOS-e820: [mem 0xdce7f000-0xdcefefff] ACPI
> data
> [0.00] BIOS-e820: [mem 0xdceff000-0xdfa0]
> reserved
> [0.00] BIOS-e820: [mem 0xf800-0xfbff]
> reserved
> [0.00] BIOS-e820: [mem 0xfe101000-0xfe112fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1]
> reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff]
> reserved
> [0.00] BIOS-e820: [mem 0xffc0-0x]
> reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00021f5f] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.7 present.
> [0.00] DMI: LENOVO 20A7005MGE/20A7005MGE, BIOS GRET46WW (1.23 )
> 11/04/2015
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x21f600 max_arch_pfn = 0x4
> [0.00] MTRR default type: write-back
> [0.00] MTRR fixed ranges enabled:
> [0.00]   0-9 write-back
> [0.00]   A-B uncachable
> [0.00]   C-F write-protect
> [0.00] MTRR variable ranges enabled:
> [0.00]   0 base 00E000 mask 7FE000 uncachable
> [0.00]   1 base 00DE00 mask 7FFE00 uncachable
> [0.00]   2 base 00DD00 mask 7FFF00 uncachable
> [0.00]   3 base 00DCF0 mask 70 uncachable
> [0.00]   4 disabled
> [0.00]   5 disabled
> [0.00]   6 disabled
> [0.00]   7 disabled
> [0.00]   8 disabled
> [0.00]   9 disabled
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
> [0.00] e820: last_pfn = 0xce210 max_arch_pfn = 0x4
> [0.00] found SMP MP-table at [mem 0x000f0100-0x000f010f] mapped at
> [880f0100]
> [0.00] Scanning 1 areas for low memory corruption
> [0.00] Base memory trampoline at [88097000] 97000 size 24576
> [0.00] Using GB pages for direct mapping
> [0.00] BRK [0x02101000, 0x02101fff] PGTABLE
> [0.00] BRK [0x02102000, 0x02102fff] PGTABLE
> [0.00] BRK [0x02103000, 

Re: Problems with Si2168 DVB-C card (cx23885)

[Torbjorn Jansson]

On 2016-06-22 15:57, Hurda wrote:



kernel: si2168 8-0064: found a 'Silicon Labs Si2168-B40'
kernel: si2168 8-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
kernel: si2168 8-0064: firmware version: 4.0.19


Distribution is Arch. Kernel version is 4.6.2.


IIRC you have to use firmware-version 4.0.11 in pre-4.8-kernels.
http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-B40/4.0.11/
There was a message on this mailing list a few weeks ago (May 21st,
regarding DVBSky T330).

Might work with that.


i got a similar card but for dvb-t2 i also found out that one of the 
firmware files must be a specific version.
the one i got from dvbskys firmware package did not work at all except 
with their binary blob driver.


but i'm not yet able to properly test my card since i'm still on 4.4 
kernel (fedora 22) and media_build is broken when modprobing cx23885 
module, dmesg complains about duplicate symbol and modprobe fails with 
exec format error.



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

Re: [PATCH 1/2] [media] v4l: vsp1: Split pad operations between rpf and wpf

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Wednesday 22 Jun 2016 02:19:24 Niklas Söderlund wrote:
> This is done in preparation to move s_stream from v4l2_subdev_video_ops
> to v4l2_subdev_pad_ops. Only wpf implements s_stream so it will no
> longer be possible to share the v4l2_subdev_pad_ops once s_stream is
> moved.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/vsp1/vsp1_rpf.c  | 12 +-
>  drivers/media/platform/vsp1/vsp1_rwpf.c | 40 +++--
>  drivers/media/platform/vsp1/vsp1_rwpf.h | 20 +
>  drivers/media/platform/vsp1/vsp1_wpf.c  | 12 +-
>  4 files changed, 57 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
> b/drivers/media/platform/vsp1/vsp1_rpf.c index 49168db..fabe8b2 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> @@ -38,8 +38,18 @@ static inline void vsp1_rpf_write(struct vsp1_rwpf *rpf,
>   * V4L2 Subdevice Operations
>   */
> 
> +const struct v4l2_subdev_pad_ops vsp1_rpf_pad_ops = {

This should be static const.

> + .init_cfg = vsp1_entity_init_cfg,
> + .enum_mbus_code = vsp1_rwpf_enum_mbus_code,
> + .enum_frame_size = vsp1_rwpf_enum_frame_size,
> + .get_fmt = vsp1_subdev_get_pad_format,
> + .set_fmt = vsp1_rwpf_set_format,
> + .get_selection = vsp1_rwpf_get_selection,
> + .set_selection = vsp1_rwpf_set_selection,
> +};
> +
>  static struct v4l2_subdev_ops rpf_ops = {
> - .pad= _rwpf_pad_ops,
> + .pad= _rpf_pad_ops,
>  };
> 
>  /*
> ---
> -- diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c
> b/drivers/media/platform/vsp1/vsp1_rwpf.c index 3b6e032..ff03b9c 100644
> --- a/drivers/media/platform/vsp1/vsp1_rwpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
> @@ -31,9 +31,9 @@ struct v4l2_rect *vsp1_rwpf_get_crop(struct vsp1_rwpf
> *rwpf, * V4L2 Subdevice Pad Operations
>   */
> 
> -static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
> - struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_mbus_code_enum *code)
> +int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
> +  struct v4l2_subdev_pad_config *cfg,
> +  struct v4l2_subdev_mbus_code_enum *code)
>  {
>   static const unsigned int codes[] = {
>   MEDIA_BUS_FMT_ARGB_1X32,
> @@ -48,9 +48,9 @@ static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
> -  struct v4l2_subdev_pad_config *cfg,
> -  struct v4l2_subdev_frame_size_enum *fse)
> +int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
> +   struct v4l2_subdev_pad_config *cfg,
> +   struct v4l2_subdev_frame_size_enum *fse)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
> 
> @@ -59,9 +59,9 @@ static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev
> *subdev, rwpf->max_height);
>  }
> 
> -static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
> - struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_format *fmt)
> +int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
> +  struct v4l2_subdev_pad_config *cfg,
> +  struct v4l2_subdev_format *fmt)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
>   struct v4l2_subdev_pad_config *config;
> @@ -113,9 +113,9 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
> -struct v4l2_subdev_pad_config *cfg,
> -struct v4l2_subdev_selection *sel)
> +int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_selection *sel)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
>   struct v4l2_subdev_pad_config *config;
> @@ -150,9 +150,9 @@ static int vsp1_rwpf_get_selection(struct v4l2_subdev
> *subdev, return 0;
>  }
> 
> -static int vsp1_rwpf_set_selection(struct v4l2_subdev *subdev,
> -struct v4l2_subdev_pad_config *cfg,
> -struct v4l2_subdev_selection *sel)
> +int vsp1_rwpf_set_selection(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_selection *sel)
>  {
>   struct vsp1_rwpf *rwpf = to_rwpf(subdev);
>   struct v4l2_subdev_pad_config *config;
> @@ 

Re: [PATCH/RFC v2 1/4] v4l: Add metadata buffer type and format

[Laurent Pinchart]

Hello,

On Tuesday 24 May 2016 19:26:32 Sakari Ailus wrote:
> On Tue, May 24, 2016 at 05:36:42PM +0200, Hans Verkuil wrote:
> > On 05/24/2016 05:28 PM, Sakari Ailus wrote:
> > > Hi Hans,
> > > 
> > >> Should it be mentioned here that changing the video format might change
> > >> the buffersize? In case the buffersize is always a multiple of the
> > >> width?
> > > 
> > > Isn't that the case in general, as with pixel formats? buffersize could
> > > also be something else than a multiple of width (there's no width for
> > > metadata formats) due to e.g. padding required by hardware.
> > 
> > Well, I don't think it is obvious that the metadata buffersize depends on
> > the video width. Perhaps developers who are experienced with CSI know
> > this, but if you know little or nothing about CSI, then it can be
> > unexpected (hey, that was the case for me!).
> > 
> > I think it doesn't hurt to mention this relation.
> 
> Ah, I think I misunderstood you first.
> 
> Typically the metadata width is the same as the image data width, that's
> true. And it's how the hardware works. This is still visible in the media
> bus format and the solution belongs rather to how multiple streams over a
> single link are supported.

Let me clarify on this.

In the general case there's no concept of metadata width when stored in 
memory. The two most common use cases for metadata store register values (or 
similar) information, or statistics. The former is just a byte stream in some 
kind of TLV (Type Length Value) format. The latter a set of values or arrays 
computed either on the full image or on subwindows, possibly laid out as a 
grid.

When transported over a bus, however, metadata can sometimes have a width and 
height. That's the case for CSI-2, which is a line-oriented format. Metadata 
then need to be broken into chunks transmitted in a CSI-2 line packet, even if 
they don't correspond to a line of an image. The line width on the bus is just 
the number of bytes transmitted in a single packet, which could be chosen 
freely (within the range allowed by CSI-2). In practice, to simplify the 
implementation, the line width is chosen to be identical to the line width of 
the image frames that the metadata correspond to, but that's not a requirement 
of either CSI-2 or the metadata format itself.

We thus need to expose metadata width and height on subdevs to ensure proper 
configuration of the transmitter and receiver, but that's not strictly 
mandatory on video nodes.

The metadata buffer size itself doesn't depend on the width and height of the 
corresponding image frames. A histogram using 64 bins on 3 components will be 
stored exactly the same way regardless of whether it's computed on a VGA or 
1080p frame. The buffer size depends on the configuration of the metadata 
source only, which in the case of the histogram generator in the VSP would 
include a control that decides whether to compute the histogram with 64 bins 
or 256 bins (the latter needs a 4 times larger buffer).

For metadata computed on a variable number of subwindows the buffer size will 
depend on the number of subwindows, which will in turn be possibly influenced 
by the size of the image. It could make sense to use fewer subwindows to 
compute AF data on a VGA image than on a 4k image. That is not however a 
requirement, and there's no direct mapping between image size and metadata 
size, the number of subwindows being usually configured by userspace.

I hope this clarifies the problem. Please let me know if you have additional 
questions or thoughts, and if you see anything that should be worded 
differently in the documentation (or even structures that should get new 
fields).

> It's just that setting the image media bus format affects the metadata media
> bus format. I guess that could be mentioned albeit it's hardware specific,
> on some sensors metadata width is independent of the image width. Even then
> this is not where I'd put it. I'd get back to the topic when documenting
> how the API for multiple streams over a single link works.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH/RFC v2 1/4] v4l: Add metadata buffer type and format

[Laurent Pinchart]

Hi Hans,

Thank you for the review.

On Monday 23 May 2016 12:09:16 Hans Verkuil wrote:
> On 05/12/2016 02:18 AM, Laurent Pinchart wrote:
> > The metadata buffer type is used to transfer metadata between userspace
> > and kernelspace through a V4L2 buffers queue. It comes with a new
> > metadata capture capability and format description.
> 
> Thanks for the patch! I have some comments/suggestions below:
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  Documentation/DocBook/media/v4l/dev-meta.xml  | 93 ++
> >  Documentation/DocBook/media/v4l/v4l2.xml  |  1 +
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 ++
> >  drivers/media/v4l2-core/v4l2-dev.c| 16 +++--
> >  drivers/media/v4l2-core/v4l2-ioctl.c  | 34 ++
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  |  3 +
> >  include/media/v4l2-ioctl.h|  8 +++
> >  include/uapi/linux/videodev2.h| 14 
> >  8 files changed, 182 insertions(+), 6 deletions(-)
> >  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> > 
> > diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> > b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> > index ..9b5b1fba2007
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> > @@ -0,0 +1,93 @@
> > +  Metadata Interface
> > +
> > +  
> > +Experimental
> > +This is an  experimental 
> 
> No space before/after 'experimental'. It will look ugly in the docbook (I
> tried it :-) ).

Will be fixed in the next version.

> > +interface and may change in the future.
> > +  
> > +
> > +  
> > +Metadata refers to any non-image data that supplements video frames with
> > +additional information. This may include statistics computed over the
> > +image or frame capture parameters supplied by the image source. This
> > +interface is intended for transfer of metadata to userspace and control
> > +of that operation.
>
> I think it can also be in the other direction. I'm thinking of metadata
> needed by codecs. I'm not sure if it should be mentioned that this is not
> supported at the moment and that the ML should be contacted for more info
> if someone wants this.

Metadata for codecs make sense, but given that the topic hasn't been 
researched yet, I've kept metadata support focused on the capture side only 
for now. I propose revisiting the topic if (or rather when) someone needs 
metadata support on output video nodes.

> > +  
> > +
> > +  
> > +The metadata interface is implemented on video capture devices. The
> > device can
>
> s/on/for/?

I meant "on video capture device nodes", I'll fix that.
 
> > +be dedicated to metadata or can implement both video and metadata capture
> > +as specified in its reported capabilities.
> > +  
> > +
> > +  
> > +Querying Capabilities
> > +
> > +
> > +Devices supporting the metadata interface set the
> > +V4L2_CAP_META_CAPTURE flag in the
> > +capabilities field of 
> > +returned by the  ioctl. That flag means the device can
> > +capture metadata to memory.
> > +
> 
> I know this is a copy and paste from the other interface descriptions, but
> it is rather outdated. I would write this instead:
> 
>  
> Device nodes supporting the metadata interface set the
> V4L2_CAP_META_CAPTURE flag in the
> device_caps field of 
> returned by the  ioctl. That flag means the device node can
> capture metadata to memory.
>  

Will be fixed in the next version.
 
> Any driver using this will be recent and always have a valid device_caps
> field (which, as you know, didn't exist in old kernels).
> 
> I find the capabilities field fairly useless in most cases due to the fact
> that it contains the capabilities of all device nodes created by the device
> driver.

I agree.

> > +
> > +At least one of the read/write or streaming I/O methods must be
> > supported.
> > +
> > +  
> > +
> > +  
> > +Data Format Negotiation
> > +
> > +
> > +The metadata device uses the format ioctls
> > to +select the capture format. The metadata buffer content format is
> > bound to that +selectable format. In addition to the basic
> > +format ioctls, the  ioctl
> > +must be supported as well.
> > +
> > +
> > +
> > +To use the format ioctls applications set
> > the +type field of a  to
> > +V4L2_BUF_TYPE_META_CAPTURE and use the
> >  +meta member of the
> > fmt +union as needed per the desired
> > operation.
> > +Currently there are two fields, dataformat and
> > +buffersize, of struct  that
> > are +used. Content of the dataformat is the
> > V4L2 FourCC +code of the data format. The
> > buffersize field is the +maximum buffer size
> > in bytes required for data transfer, set by the driver in +order to
> > inform applications.
> 
> Should it be mentioned here that changing the video format might change the
> buffersize? In case the buffersize is always a multiple of the width?

I'll 

Re: Problems with Si2168 DVB-C card (cx23885)

[Hurda]

kernel: si2168 8-0064: found a 'Silicon Labs Si2168-B40'
kernel: si2168 8-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
kernel: si2168 8-0064: firmware version: 4.0.19


Distribution is Arch. Kernel version is 4.6.2.


IIRC you have to use firmware-version 4.0.11 in pre-4.8-kernels.
http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-B40/4.0.11/
There was a message on this mailing list a few weeks ago (May 21st, regarding 
DVBSky T330).


Might work with that.
--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

[Pierre-Louis Bossart]

On 6/21/16 12:40 PM, Richard Cochran wrote:

On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:

You can experiment with the 'dma' and 'link' timestamps today on any
HDaudio-based device. Like I said the synchronized part has not been
upstreamed yet (delays + dependency on ART-to-TSC conversions that made it
in the kernel recently)


Can you point me to any open source apps using the dma/link
timestamps?


Those timestamps are only used in custom applications at the moment, not 
'mainstream' open source.
It takes time for new kernel capabilities to trickle into userspace, 
applications usually align on the lowest hardware common denominator. In 
addition, most applications don't access the kernel directly but go 
through an audio server or HAL which needs to be updated as well so it's 
a two-level dependency. These timestamps can be directly mappped to the 
Android AudioTrack.getTimeStamp API though.


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

Problems with Si2168 DVB-C card (cx23885)

[Florian Lindner]

Hello,

I bought a TechnoTrend TT-budget CT2-4500 [1,2] DVB-C card and connected
it to my cable, using no CI. A TV connected on the same cable is
working, but the card is not.

I have installed the driver package from openelec [3,4] which includes
all firmware (Version 1 and 2) mentioned in [5] (according to
linuxtv.org my card is an OEM version of the DVB Sky T980C).

The outputs look ok to me:

$ dmesg | grep -i dvb
[   75.856005] cx23885_dvb_register() allocating 1 frontend(s)
[   75.856006] cx23885[0]: cx23885 based dvb card
[   75.995381] DVB: registering new adapter (cx23885[0])
[   75.995388] cx23885 :03:00.0: DVB: registering adapter 0 frontend
0 (Silicon Labs Si2168)...

$ lspci | grep -i cx23885
03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI
Video and Audio Decoder (rev 04)

$ ls /dev/dvb/adapter0/
ca0  demux0  dvr0  frontend0  net0

$ lspci -vvvnn
03:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
Subsystem: Technotrend Systemtechnik GmbH TT-budget CT2-4500 CI
[13c2:3013]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128-
WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: cx23885
Kernel modules: cx23885

$ dvb-fe-tool -d DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A

prints these messages to the journal:

kernel: si2168 8-0064: found a 'Silicon Labs Si2168-B40'
kernel: si2168 8-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
kernel: si2168 8-0064: firmware version: 4.0.19
kernel: si2157 10-0060: found a 'Silicon Labs Si2157-A30'
kernel: si2157 10-0060: firmware version: 3.0.5


$ dvb-fe-tool
Device Silicon Labs Si2168 (/dev/dvb/adapter0/frontend0) capabilities:
 CAN_2G_MODULATION
 CAN_FEC_1_2
 CAN_FEC_2_3
 CAN_FEC_3_4
 CAN_FEC_5_6
 CAN_FEC_7_8
 CAN_FEC_AUTO
 CAN_GUARD_INTERVAL_AUTO
 CAN_HIERARCHY_AUTO
 CAN_INVERSION_AUTO
 CAN_MULTISTREAM
 CAN_MUTE_TS
 CAN_QAM_16
 CAN_QAM_32
 CAN_QAM_64
 CAN_QAM_128
 CAN_QAM_256
 CAN_QAM_AUTO
 CAN_QPSK
 CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.10, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems:
 DVBT
 DVBT2
[DVBC/ANNEX_A]



However dvb-fe-tool --femon says it has no signal:

$ dvb-fe-tool --femon
   (0x00) Signal= 0,00dBm
[...going on...]


and wx_scan finds no channels

$ w_scan -f c -c DE
w_scan -f c -c DE
w_scan version 20141122 (compiled for DVB API 5.10)
using settings for GERMANY
DVB cable
DVB-C
scan type CABLE, channellist 7
output format vdr-2.0
output charset 'UTF-8', use -C  to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> CABLE "Silicon Labs Si2168": very
good :-))

Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.10
frontend 'Silicon Labs Si2168' supports
INVERSION_AUTO
QAM_AUTO
FEC_AUTO
FREQ (42.00MHz ... 870.00MHz)
SRATE (1.000MSym/s ... 7.200MSym/s)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
73000: sr6900 (time: 00:00.019) sr6875 (time: 00:01.529)
[...]


Distribution is Arch. Kernel version is 4.6.2.



As a (possible unrelated) side not: the remote also does not work.

Next step for me would be to use a Windows machine to test the card.

Although, it seems everything is fine, except that there is no signal.

Thanks for any advice!
Florian


[1] http://www.technotrend.eu/2984/TT-budget_CT2-4500_CI.html
[2] https://www.linuxtv.org/wiki/index.php/TechnoTrend_TT-budget_CT2-4500_CI
[3] https://github.com/OpenELEC/dvb-firmware/tree/master/firmware
[4] https://aur.archlinux.org/packages/openelec-dvb-firmware/
[5] https://www.linuxtv.org/wiki/index.php/DVBSky_T980C



--
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 v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

[Nick Dyer]

On 22/06/2016 12:48, Florian Echtler wrote:
> On 20.06.2016 14:00, Hans Verkuil wrote:
>> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>>> Some touch controllers send out raw touch data in a similar way to a
>>> greyscale frame grabber. Add a new device type for these devices.
>>>
>>> Use a new device prefix v4l-touch for these devices, to stop generic
>>> capture software from treating them as webcams.
>>>
>>> Signed-off-by: Nick Dyer 
>>> ---
>>>  drivers/input/touchscreen/sur40.c|  4 ++--
>>>  drivers/media/v4l2-core/v4l2-dev.c   | 13 ++---
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 15 ++-
>>>  include/media/v4l2-dev.h |  3 ++-
>>>  include/uapi/linux/videodev2.h   |  1 +
> 
> Generally a good idea in my opinion, but I think the SUR40 is a special
> case: the whole point of putting in a V4L2 driver was that software like
> reacTIVision, which already has a V4L2 interface, can then use that
> device like any other camera.

Thanks. I see that reactivision definitely uses this already
(https://github.com/mkalten/reacTIVision/issues/3 ) and we don't want to
break it - I've split the sur40.c change out of this patch now so it can be
considered separately.

> Come to think of it, wouldn't it make sense to expose the other touch
> devices as generic frame grabbers, too, so you can easily view the debug
> output with any generic tool like cheese?

While I like the idea of being able to use the generic tools, I think we
needed to do something to stop these devices turning up in e.g. video
conferencing software - it would cause a lot of confusion. There's nothing
stopping particular tools adding the necessary code to handle touch devices
if they feel their users want it.

Also, the RMI4 and Atmel mXT touchscreens output signed data, which
unfortunately would confuse the generic tools.
--
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: camera application for testing (was Re: v4l subdevs without big device)

[Pavel Machek]

Hi!

> > I think libv4l itself has algorithms to control at least some of these. It
> > relies on the image data so the CPU time consumption will be high.
> > 
> > AFAIR Laurent has also worked on implementing some algorithms that use the
> > histogram and some of the statistics. Add him to cc list.
> 
> http://git.ideasonboard.org/omap3-isp-live.git
> 
> That's outdated and might not run or compile anymore. The code is
> more of a

Lets see, it compiles with this hack:

index 6f3ffbe..935f41d 100644
--- a/isp/v4l2.c
+++ b/isp/v4l2.c
@@ -292,7 +292,7 @@ struct v4l2_device *v4l2_open(const char *devname)
 * driver (>= v3.19) will set both CAPTURE and OUTPUT in the
 * capabilities field.
 */
-   capabilities = cap.device_caps ? : cap.capabilities;
+   capabilities = /* cap.device_caps ? : */ cap.capabilities;
 
if (capabilities & V4L2_CAP_VIDEO_CAPTURE)
dev->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;


I can try to run it, but I guess I'll need kernel with camera support.

pavel@n900:/my/omap3-isp-live$ LD_LIBRARY_PATH=isp ./snapshot
media_open: Can't open media device /dev/media0
error: unable to open media device /dev/media0
Segmentation fault (core dumped)

I tried again on kernel with camera:

pavel@n900:/my/omap3-isp-live$ LD_LIBRARY_PATH=isp ./snapshot
error: unable to locate sensor.
Segmentation fault (core dumped)
pavel@n900:/my/omap3-isp-live$

Here's the fix for coredump:

diff --git a/isp/subdev.c b/isp/subdev.c
index 9b36234..c74514e 100644
--- a/isp/subdev.c
+++ b/isp/subdev.c
@@ -75,6 +75,8 @@ int v4l2_subdev_open(struct media_entity *entity)
 
 void v4l2_subdev_close(struct media_entity *entity)
 {
+  if (!entity)
+return;
if (entity->fd == -1)
return;

Let me investigate some more.

> proof of concept implementation, but it could be used as a starting point. 
> With an infinite amount of free time I'd love to work on an open-source 
> project for computational cameras, integrating it with libv4l.

For the record, I pushed my code to

https://gitlab.com/pavelm/fcam-dev

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

[Florian Echtler]

On 20.06.2016 14:00, Hans Verkuil wrote:
> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>> Some touch controllers send out raw touch data in a similar way to a
>> greyscale frame grabber. Add a new device type for these devices.
>>
>> Use a new device prefix v4l-touch for these devices, to stop generic
>> capture software from treating them as webcams.
>>
>> Signed-off-by: Nick Dyer 
>> ---
>>  drivers/input/touchscreen/sur40.c|  4 ++--
>>  drivers/media/v4l2-core/v4l2-dev.c   | 13 ++---
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 15 ++-
>>  include/media/v4l2-dev.h |  3 ++-
>>  include/uapi/linux/videodev2.h   |  1 +

Generally a good idea in my opinion, but I think the SUR40 is a special
case: the whole point of putting in a V4L2 driver was that software like
reacTIVision, which already has a V4L2 interface, can then use that
device like any other camera.

Come to think of it, wouldn't it make sense to expose the other touch
devices as generic frame grabbers, too, so you can easily view the debug
output with any generic tool like cheese?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



signature.asc
Description: OpenPGP digital signature

[PATCH v3] [media] adv7604: Add support for hardware reset

[Dragos Bogdan]

The part can be reset by a low pulse on the RESET pin (i.e. a hardware
reset) with a minimum width of 5 ms. It is recommended to wait 5 ms
after the low pulse before an I2C write is performed to the part.
For safety reasons, the delays will be between 5 and 10 ms.

The RESET pin can be tied high, so the GPIO is optional.

Signed-off-by: Dragos Bogdan 
Reviewed-by: Lars-Peter Clausen 
Acked-by: Laurent Pinchart 
---
Changes since v2:
 - adv76xx_reset() is now a void function (it always returned 0).

Changes since v1:
 - Replace mdelay() with usleep_range();
 - Limit the comments to 75 characters per line.

 drivers/media/i2c/adv7604.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 41a1bfc..ab4f933 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -164,6 +164,7 @@ struct adv76xx_state {
struct adv76xx_platform_data pdata;
 
struct gpio_desc *hpd_gpio[4];
+   struct gpio_desc *reset_gpio;
 
struct v4l2_subdev sd;
struct media_pad pads[ADV76XX_PAD_MAX];
@@ -2996,6 +2997,19 @@ static int configure_regmaps(struct adv76xx_state *state)
return 0;
 }
 
+static void adv76xx_reset(struct adv76xx_state *state)
+{
+   if (state->reset_gpio) {
+   /* ADV76XX can be reset by a low reset pulse of minimum 5 ms. */
+   gpiod_set_value_cansleep(state->reset_gpio, 0);
+   usleep_range(5000, 1);
+   gpiod_set_value_cansleep(state->reset_gpio, 1);
+   /* It is recommended to wait 5 ms after the low pulse before */
+   /* an I2C write is performed to the ADV76XX. */
+   usleep_range(5000, 1);
+   }
+}
+
 static int adv76xx_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
@@ -3059,6 +3073,12 @@ static int adv76xx_probe(struct i2c_client *client,
if (state->hpd_gpio[i])
v4l_info(client, "Handling HPD %u GPIO\n", i);
}
+   state->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
+   GPIOD_OUT_HIGH);
+   if (IS_ERR(state->reset_gpio))
+   return PTR_ERR(state->reset_gpio);
+
+   adv76xx_reset(state);
 
state->timings = cea640x480;
state->format = adv76xx_format_info(state, MEDIA_BUS_FMT_YUYV8_2X8);
-- 
2.1.4

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

Re: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

[Pavel Machek]

Hi!

I tried to capture 1.2Mpix images, then scale them down to 800x600
using hardware... and results were  kernel dying.

[12552.400146] [] (isp_video_start_streaming) from
[] (vb2_start_streaming+0x5c/0x154)
[12552.400146] [] (vb2_start_streaming) from []
(vb2_core_streamon+0x104/0x160)
[12552.400177] [] (vb2_core_streamon) from []
(isp_video_streamon+0x17c/0x27c)
[12552.400207] [] (isp_video_streamon) from []
(v4l_streamon+0x18/0x1c)
[12552.400238] [] (v4l_streamon) from []
(__video_do_ioctl+0x24c/0x2e8)
[12552.400268] [] (__video_do_ioctl) from []
(video_usercopy+0x110/0x600)
[12552.400299] [] (video_usercopy) from []
(v4l2_ioctl+0x98/0xb8)
[12552.400329] [] (v4l2_ioctl) from []
(do_vfs_ioctl+0x80/0x948)
[12552.400329] [] (do_vfs_ioctl) from []
(SyS_ioctl+0x64/0x74)
[12552.400360] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x3c)
[12552.400390] ---[ end trace b4627b34449829a7 ]---
[12552.400421] In-band Error seen by MPU  at address 0
[12552.400421] [ cut here ]
[12552.400451] WARNING: CPU: 0 PID: 3936 at
drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xcc/0x124
[12552.400482] Modules linked in:
[12552.400482] CPU: 0 PID: 3936 Comm: mplayer Tainted: GW
4.6.0-177572-g501bb64-dirty #360
[12552.400512] Hardware name: Nokia RX-51 board

I did more experiments before, and usually it does not end like
this. Usually, when I set up capture with greater resolution than cca
800x600, I get 4 copies of image above each other.

If you know how to get images with greater resolution, let me know.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

[Sakari Ailus]

Hi Pavel,

On Tue, Jun 21, 2016 at 08:05:49PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > First, I re-did pipeline setup in python, it seems slightly less hacky
> > > > then in shell.
> > > > 
> > > > I tried to modify fcam-dev to work with the new interface, but was not
> > > > successful so far. I can post patches if someone is interested
> > > > (mplayer works for me, but that's not too suitable for taking photos).
> > > > 
> > > > I tried to get gstreamer to work, with something like:
> > > 
> > > While trying to debug gstreamer, I ran v4l2-compliance, and it seems
> > > to suggest that QUERYCAP is required... but it is not present on
> > > /dev/video2 or video6.
> > 
> > It's not saying that it wouldn't be present, but the content appears wrong.
> > It should have the real bus information there rather than just "media".
> > 
> > See e.g. drivers/media/platform/vsp1/vsp1_drv.c . I suppose that should be
> > right.
> > 
> > Feel free to submit a patch. :-)
> 
> For now I'd not know what to change, sorry :-(. Perhaps we can debug
> it after the support is merged into mainline.

A single line change to change the bus field contents to the actual bus
address.

grep -A1 platform: drivers/media/platform/vsp1/vsp1_drv.c

> 
> Another weirdness:
> 
> yavta, on v4l-subdev12 :
> 
> control 0x00a40906 `Sensivity' min 0 max 0 step 1 default 0 current 65536.
> 
> Min and max being the same, I don't think I can control the
> sensitivity. I guess I'll have to provid  more light for the tests for
> now...

That control should be removed. I think I concluded its value is the same
for all the modes...

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