[PATCH RFC v2 0/3] Add SDR at V4L2 API

[PATCH RFC v2 0/3] Add SDR at V4L2 API

[Mauro Carvalho Chehab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=true, Size: 5912 bytes --]

This is a version 2 of the V4L2 API bits to support Software Digital
Radio (SDR).


The changes from version 1 are:
	- fix compilation;
	- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
	  with the corresponding documentation;
	- remove legacy V4L1 buffer types from videobuf2.h.

With regards to VIDIOC_S_TUNER, what's currently defined there is
that, in contrary to what a radio device does, this ioctl would
set the input.

This patch adds the very basic stuff for SDR:

	- a separate devnode;
	- an VIDIOC_QUERYCAP caps for SDR;
	- a fourcc group for SDR;
	- a few DocBook bits.

What's missing:
	- SDR specific controls;
	- Sample rate config;
	...

As discussing DocBook changes inside the patch is hard, I'm adding here
the DocBook formatted changes.

The DocBook changes add the following bits:

At Chapter 1. Common API Elements, it adds:

<text>
Software Digital Radio (SDR) Tuners and Modulators
==================================================

Those devices are special types of Radio devices that don't have any 
analog demodulator. Instead, it samples the radio IF or baseband and 
sends the samples for userspace to demodulate. 

Tuners
======

SDR receivers can have one or more tuners sampling RF signals. Each 
tuner is associated with one or more inputs, depending on the number of 
RF connectors on the tuner. The type field of the respective struct 
v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to 
V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of 
the tuner input.

To query and change tuner properties applications use the VIDIOC_G_TUNER 
and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned 
by VIDIOC_G_TUNER also contains signal status information applicable 
when the tuner of the current SDR input is queried. In order to change 
the SDR input, VIDIOC_S_TUNER with a new SDR index should be called. 
Drivers must support both ioctls and set the V4L2_CAP_SDR and 
V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the 
VIDIOC_QUERYCAP ioctl.

Modulators
==========

To be defined.
</text>

At the end of Chapter 2. Image Formats, it adds:

<text>
SDR format struture
===================

Table 2.4. struct v4l2_sdr_format
=================================

__u32	sampleformat	The format of the samples used by the SDR device.
			This is a little endian four character code.

Table 2.5. SDR formats
======================

V4L2_SDR_FMT_I8Q8	Samples are given by a sequence of 8 bits in-phase(I)
			and 8 bits quadrature (Q) samples taken from a
			signal(t) represented by the following expression:
			signal(t) = I * cos(2π fc t) - Q * sin(2π fc t)
</text>

Of course, other formats will be needed at Table 2.5, as SDR could also 
be taken baseband samples, being, for example, a simple sequence of 
equally time-spaced digitalized samples of the signal in time.
SDR samples could also use other resolutions, use a non-linear
(A-law, u-law) ADC, or even compress the samples (with ADPCM, for 
example). So, this table will grow as newer devices get added, and an
userspace library may be required to convert them into some common
format.

At "Chapter 4. Interfaces", it adds the following text:

<text>
Software Digital Radio(SDR) Interface
=====================================

This interface is intended for Software Digital Radio (SDR) receivers 
and transmitters.

Conventionally V4L2 SDR devices are accessed through character device 
special files named /dev/sdr0 to/dev/radio255 and uses a dynamically 
allocated major/minor number.

Querying Capabilities
=====================

Devices supporting the radio interface set the V4L2_CAP_SDR and 
V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of 
struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other 
combinations of capability flags are reserved for future extensions. 

Supplemental Functions
======================

SDR receivers should support tuner ioctls.

SDR transmitter ioctl's will be defined in the future.

SDR devices should also support one or more of the following I/O ioctls: 
read or write, memory mapped IO, user memory IO and/or DMA buffers.

SDR devices can also support controls ioctls.

The SDR Input/Output are A/D or D/A samples taken from a modulated 
signal, and can eventually be packed by the hardware. They are generally 
encoded using cartesian in-phase/quadrature (I/Q) samples, to make 
demodulation easier. The format of the samples should be according with 
SDR format.
</text>

Note: "SDR format" on the last paragraph is an hyperlink to
Chapter 2. Image Formats.

At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:

<text>
Table A.93. Device Capabilities Flags
...
V4L2_CAP_SDR	0x00100000	The device is a Software Digital Radio. 
				For more information about SDR programming
				see the section called “Software Digital 
				Radio (SDR) Tuners and Modulators”.
</text>

Mauro Carvalho Chehab (3):
  [media] Add SDR at V4L2 API
  videodev2.h: Remove the unused old V4L1 buffer types
  [media] V4L2 api: Add a buffer capture type for SDR

 Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
 Documentation/DocBook/media/v4l/dev-capture.xml    | 26 ++++++++------
 Documentation/DocBook/media/v4l/io.xml             |  6 ++++
 Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
 Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
 .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
 drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
 drivers/media/v4l2-core/v4l2-ioctl.c               | 32 +++++++++++++++++
 include/media/v4l2-dev.h                           |  3 +-
 include/media/v4l2-ioctl.h                         |  8 +++++
 include/uapi/linux/videodev2.h                     | 33 +++++++----------
 11 files changed, 163 insertions(+), 32 deletions(-)

-- 
1.8.1.4

[PATCH RFC v2 1/3] [media] Add SDR at V4L2 API

[Mauro Carvalho Chehab]

Adds the basic API bits for Software Digital Radio (SDR) at the V4L2 API.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
 Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
 Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
 .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
 drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
 include/media/v4l2-dev.h                           |  3 +-
 include/uapi/linux/videodev2.h                     | 11 ++++++
 7 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index 1ddf354..f59c67d 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -513,6 +513,41 @@ the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl when the
 device has one or more modulators.</para>
     </section>
 
+  <section id="sdr_tuner">
+    <title>Software Digital Radio (SDR) Tuners and Modulators</title>
+
+    <para>Those devices are special types of Radio devices that don't
+have any analog demodulator. Instead, it samples the radio IF or baseband
+and sends the samples for userspace to demodulate.</para>
+    <section>
+      <title>Tuners</title>
+
+      <para>SDR receivers can have one or more tuners sampling RF signals.
+Each tuner is associated with one or more inputs, depending on the number
+of RF connectors on the tuner. The <structfield>type</structfield> field of
+the respective &v4l2-input; returned by the &VIDIOC-ENUMINPUT; ioctl is set to
+<constant>V4L2_INPUT_TYPE_TUNER</constant> and its
+<structfield>tuner</structfield> field contains the index number of
+the tuner input.</para>
+
+<para>To query and change tuner properties applications use the
+&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
+&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
+contains signal status information applicable when the tuner of the
+current SDR input is queried. In order to change the SDR input,
+<constant>VIDIOC_S_TUNER</constant> with a new SDR index should be called.
+Drivers must support both ioctls and set the
+<constant>V4L2_CAP_SDR</constant> and <constant>V4L2_CAP_TUNER</constant>
+flags in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para>
+    </section>
+
+    <section>
+      <title>Modulators</title>
+      <para>To be defined.</para>
+    </section>
+  </section>
+
+
     <section>
       <title>Radio Frequency</title>
 
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 99b8d2a..e30075e 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -203,6 +203,47 @@ codes can be used.</entry>
   </table>
 </section>
 
+<section>
+  <title>SDR format struture</title>
+  <table pgwide="1" frame="none" id="v4l2-sdr-format">
+    <title>struct <structname>v4l2_sdr_format</structname></title>
+    <tgroup cols="3">
+      &cs-str;
+      <tbody valign="top">
+	<row>
+	  <entry>__u32</entry>
+	  <entry><structfield>sampleformat</structfield></entry>
+	  <entry>The format of the samples used by the SDR device.
+		 This is a little endian
+		 <link linkend="v4l2-sdr-fourcc">
+		 four character code</link>.</entry>
+	</row>
+      </tbody>
+    </tgroup>
+  </table>
+  <table pgwide="1" frame="none" id="v4l2-sdr-fourcc">
+    <title>SDR formats</title>
+    <tgroup cols="2">
+      &cs-str;
+      <tbody valign="top">
+	<row>
+	  <entry><constant>V4L2_SDR_FMT_I8Q8</constant></entry>
+	  <entry>Samples are given by a sequence of 8 bits in-phase(I) and
+		  8 bits quadrature (Q) samples taken from a
+		  <emphasis>signal(t)</emphasis> represented by the following
+		 expression:
+		 <informalequation>
+		 <alt>signal(t) = I cos(2&pi; f t) - Q sin(2&pi; f t)</alt>
+		 <mathphrase><emphasis>signal(t) = I * cos(2&pi; f<subscript>c</subscript> t) - Q * sin(2&pi; f<subscript>c</subscript> t)</emphasis></mathphrase>
+		 </informalequation>
+	  </entry>
+	</row>
+      </tbody>
+    </tgroup>
+  </table>
+
+</section>
+
   <section>
     <title>Standard Image Formats</title>
 
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index bfc93cd..b53a5cf 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -521,6 +521,7 @@ and discussions on the V4L mailing list.</revremark>
     <section id="ttx"> &sub-dev-teletext; </section>
     <section id="radio"> &sub-dev-radio; </section>
     <section id="rds"> &sub-dev-rds; </section>
+    <section id="sdr"> &sub-dev-sdr; </section>
     <section id="event"> &sub-dev-event; </section>
     <section id="subdev"> &sub-dev-subdev; </section>
   </chapter>
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
index d5a3c97..97bb25a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
@@ -296,6 +296,13 @@ modulator programming see
 <xref linkend="tuner" />.</entry>
 	  </row>
 	  <row>
+	    <entry><constant>V4L2_CAP_SDR</constant></entry>
+	    <entry>0x00100000</entry>
+	    <entry>The device is a Software Digital Radio.
+		    For more information about SDR programming see
+<xref linkend="sdr_tuner" />.</entry>
+	  </row>
+	  <row>
 	    <entry><constant>V4L2_CAP_READWRITE</constant></entry>
 	    <entry>0x01000000</entry>
 	    <entry>The device supports the <link
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 5923c5d..a48e070 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -796,6 +796,9 @@ int __video_register_device(struct video_device *vdev, int type, int nr,
 	case VFL_TYPE_SUBDEV:
 		name_base = "v4l-subdev";
 		break;
+	case VFL_TYPE_SDR:
+		name_base = "sdr";
+		break;
 	default:
 		printk(KERN_ERR "%s called with unknown type: %d\n",
 		       __func__, type);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 95d1c91..95863bb 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -24,7 +24,8 @@
 #define VFL_TYPE_VBI		1
 #define VFL_TYPE_RADIO		2
 #define VFL_TYPE_SUBDEV		3
-#define VFL_TYPE_MAX		4
+#define VFL_TYPE_SDR		4
+#define VFL_TYPE_MAX		5
 
 /* Is this a receiver, transmitter or mem-to-mem? */
 /* Ignored for VFL_TYPE_SUBDEV. */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 97fb392..4aa24c3 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -284,6 +284,7 @@ struct v4l2_capability {
 #define V4L2_CAP_AUDIO			0x00020000  /* has audio support */
 #define V4L2_CAP_RADIO			0x00040000  /* is a radio device */
 #define V4L2_CAP_MODULATOR		0x00080000  /* has a modulator */
+#define V4L2_CAP_SDR			0x00100000  /* is a SDR device */
 
 #define V4L2_CAP_READWRITE              0x01000000  /* read/write systemcalls */
 #define V4L2_CAP_ASYNCIO                0x02000000  /* async I/O */
@@ -1700,6 +1701,15 @@ struct v4l2_pix_format_mplane {
 	__u8				reserved[11];
 } __attribute__ ((packed));
 
+
+struct v4l2_sdr_format {
+	__u32				sampleformat;
+};
+
+/*      Sample format						Description  */
+
+#define V4L2_SDR_FMT_I8Q8	v4l2_fourcc('I', '8', 'Q', '8') /* I 8bits, Q 8bits  */
+
 /**
  * struct v4l2_format - stream data format
  * @type:	enum v4l2_buf_type; type of the data stream
@@ -1718,6 +1728,7 @@ struct v4l2_format {
 		struct v4l2_window		win;     /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
 		struct v4l2_vbi_format		vbi;     /* V4L2_BUF_TYPE_VBI_CAPTURE */
 		struct v4l2_sliced_vbi_format	sliced;  /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
+		struct v4l2_sdr_format		fmt;	 /* V4L2_BUF_TYPE_SDR_CAPTURE */
 		__u8	raw_data[200];                   /* user-defined */
 	} fmt;
 };
-- 
1.8.1.4

[PATCH RFC v2 2/3] videodev2.h: Remove the unused old V4L1 buffer types

[Mauro Carvalho Chehab]

Those aren't used anywhere for a long time. Drop it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 include/uapi/linux/videodev2.h | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4aa24c3..5d8ee92 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -72,27 +72,6 @@
 #define VIDEO_MAX_FRAME               32
 #define VIDEO_MAX_PLANES               8
 
-#ifndef __KERNEL__
-
-/* These defines are V4L1 specific and should not be used with the V4L2 API!
-   They will be removed from this header in the future. */
-
-#define VID_TYPE_CAPTURE	1	/* Can capture */
-#define VID_TYPE_TUNER		2	/* Can tune */
-#define VID_TYPE_TELETEXT	4	/* Does teletext */
-#define VID_TYPE_OVERLAY	8	/* Overlay onto frame buffer */
-#define VID_TYPE_CHROMAKEY	16	/* Overlay by chromakey */
-#define VID_TYPE_CLIPPING	32	/* Can clip */
-#define VID_TYPE_FRAMERAM	64	/* Uses the frame buffer memory */
-#define VID_TYPE_SCALES		128	/* Scalable */
-#define VID_TYPE_MONOCHROME	256	/* Monochrome only */
-#define VID_TYPE_SUBCAPTURE	512	/* Can capture subareas of the image */
-#define VID_TYPE_MPEG_DECODER	1024	/* Can decode MPEG streams */
-#define VID_TYPE_MPEG_ENCODER	2048	/* Can encode MPEG streams */
-#define VID_TYPE_MJPEG_DECODER	4096	/* Can decode MJPEG streams */
-#define VID_TYPE_MJPEG_ENCODER	8192	/* Can encode MJPEG streams */
-#endif
-
 /*
  *	M I S C E L L A N E O U S
  */
-- 
1.8.1.4

[PATCH RFC v2 3/3] [media] V4L2 api: Add a buffer capture type for SDR

[Mauro Carvalho Chehab]

As SDR devices are not video, VBI or RDS devices, it needs
its own buffer type for capture. Add it at the V4L2 API.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 Documentation/DocBook/media/v4l/dev-capture.xml | 26 ++++++++++++--------
 Documentation/DocBook/media/v4l/io.xml          |  6 +++++
 drivers/media/v4l2-core/v4l2-ioctl.c            | 32 +++++++++++++++++++++++++
 include/media/v4l2-ioctl.h                      |  8 +++++++
 include/uapi/linux/videodev2.h                  |  3 ++-
 5 files changed, 64 insertions(+), 11 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/dev-capture.xml b/Documentation/DocBook/media/v4l/dev-capture.xml
index e1c5f94..7797d2d 100644
--- a/Documentation/DocBook/media/v4l/dev-capture.xml
+++ b/Documentation/DocBook/media/v4l/dev-capture.xml
@@ -44,7 +44,7 @@ all video capture devices.</para>
   </section>
 
   <section>
-    <title>Image Format Negotiation</title>
+    <title>Streaming Format Negotiation</title>
 
     <para>The result of a capture operation is determined by
 cropping and image format parameters. The former select an area of the
@@ -65,13 +65,18 @@ linkend="crop" />.</para>
 
     <para>To query the current image format applications set the
 <structfield>type</structfield> field of a &v4l2-format; to
-<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
-<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the
-&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
-the &v4l2-pix-format; <structfield>pix</structfield> or the
-&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
+<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
+<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> or
+<constant>V4L2_BUF_TYPE_VIDEO_SDR_CAPTURE</constant> or
+and call the &VIDIOC-G-FMT; ioctl with a pointer to this structure.</para>
+
+<para>Video drivers fill the &v4l2-pix-format; <structfield>pix</structfield>
+or the &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
 <structfield>fmt</structfield> union.</para>
 
+<para>SDR drivers fill the &v4l2-sdr-format; <structfield>sdr</structfield>
+member of the <structfield>fmt</structfield> union.</para>
+
     <para>To request different parameters applications set the
 <structfield>type</structfield> field of a &v4l2-format; as above and
 initialize all fields of the &v4l2-pix-format;
@@ -87,8 +92,9 @@ adjust the parameters and finally return the actual parameters as
 without disabling I/O or possibly time consuming hardware
 preparations.</para>
 
-    <para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
-are discussed in <xref linkend="pixfmt" />. See also the specification of the
+    <para>The contents of &v4l2-pix-format;, &v4l2-pix-format-mplane; and
+&v4l2-sdr-format; are discussed in <xref linkend="pixfmt" />.
+See also the specification of the
 <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
 and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
 capture devices must implement both the
@@ -100,9 +106,9 @@ returns default parameters as <constant>VIDIOC_G_FMT</constant> does.
   </section>
 
   <section>
-    <title>Reading Images</title>
+    <title>Reading streams</title>
 
-    <para>A video capture device may support the <link
+    <para>A video capture device or an SDR device may support the <link
 linkend="rw">read() function</link> and/or streaming (<link
 linkend="mmap">memory mapping</link> or <link
 linkend="userp">user pointer</link>) I/O. See <xref
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 2c4c068..0e69d31 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -1005,6 +1005,12 @@ should set this to 0.</entry>
 	    <entry>Buffer for video output overlay (OSD), see <xref
 		linkend="osd" />.</entry>
 	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry>
+	    <entry>8</entry>
+	    <entry>Buffer for Software Digital Radio (SDR) receivers, see <xref
+		linkend="sdr" />.</entry>
+	  </row>
 	</tbody>
       </tgroup>
     </table>
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index f81bda1..127a632 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -150,6 +150,7 @@ const char *v4l2_type_names[] = {
 	[V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY] = "vid-out-overlay",
 	[V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE] = "vid-cap-mplane",
 	[V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE] = "vid-out-mplane",
+	[V4L2_BUF_TYPE_SDR_CAPTURE] = "vid-out-mplane",
 };
 EXPORT_SYMBOL(v4l2_type_names);
 
@@ -242,6 +243,7 @@ static void v4l_print_format(const void *arg, bool write_only)
 	const struct v4l2_pix_format_mplane *mp;
 	const struct v4l2_vbi_format *vbi;
 	const struct v4l2_sliced_vbi_format *sliced;
+	const struct v4l2_sdr_format *sdr;
 	const struct v4l2_window *win;
 	const struct v4l2_clip *clip;
 	unsigned i;
@@ -323,6 +325,14 @@ static void v4l_print_format(const void *arg, bool write_only)
 				sliced->service_lines[0][i],
 				sliced->service_lines[1][i]);
 		break;
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		sdr = &p->fmt.sdr;
+		pr_cont("format=%c%c%c%c\n",
+			(sdr->sampleformat & 0xff),
+			(sdr->sampleformat >>  8) & 0xff,
+			(sdr->sampleformat >> 16) & 0xff,
+			(sdr->sampleformat >> 24) & 0xff);
+		break;
 	}
 }
 
@@ -898,6 +908,7 @@ static int check_fmt(struct file *file, enum v4l2_buf_type type)
 	const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
 	bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER;
 	bool is_vbi = vfd->vfl_type == VFL_TYPE_VBI;
+	bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR;
 	bool is_rx = vfd->vfl_dir != VFL_DIR_TX;
 	bool is_tx = vfd->vfl_dir != VFL_DIR_RX;
 
@@ -947,6 +958,10 @@ static int check_fmt(struct file *file, enum v4l2_buf_type type)
 		if (is_vbi && is_tx && ops->vidioc_g_fmt_sliced_vbi_out)
 			return 0;
 		break;
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		if (is_sdr && is_rx && ops->vidioc_g_fmt_sdr_cap)
+			return 0;
+		break;
 	default:
 		break;
 	}
@@ -1066,6 +1081,10 @@ static int v4l_enum_fmt(const struct v4l2_ioctl_ops *ops,
 		if (unlikely(!is_tx || !ops->vidioc_enum_fmt_vid_out_mplane))
 			break;
 		return ops->vidioc_enum_fmt_vid_out_mplane(file, fh, arg);
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		if (unlikely(!is_rx || !ops->vidioc_enum_fmt_sdr_cap))
+			break;
+		return ops->vidioc_enum_fmt_sdr_cap(file, fh, arg);
 	}
 	return -EINVAL;
 }
@@ -1120,6 +1139,10 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
 		if (unlikely(!is_tx || is_vid || !ops->vidioc_g_fmt_sliced_vbi_out))
 			break;
 		return ops->vidioc_g_fmt_sliced_vbi_out(file, fh, arg);
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		if (unlikely(!is_rx || !ops->vidioc_g_fmt_sdr_cap))
+			break;
+		return ops->vidioc_g_fmt_sdr_cap(file, fh, arg);
 	}
 	return -EINVAL;
 }
@@ -1184,6 +1207,10 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
 			break;
 		CLEAR_AFTER_FIELD(p, fmt.sliced);
 		return ops->vidioc_s_fmt_sliced_vbi_out(file, fh, arg);
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		if (unlikely(!is_rx || !ops->vidioc_s_fmt_sdr_cap))
+			break;
+		return ops->vidioc_s_fmt_sdr_cap(file, fh, arg);
 	}
 	return -EINVAL;
 }
@@ -1194,6 +1221,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
 	struct v4l2_format *p = arg;
 	struct video_device *vfd = video_devdata(file);
 	bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER;
+	bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR;
 	bool is_rx = vfd->vfl_dir != VFL_DIR_TX;
 	bool is_tx = vfd->vfl_dir != VFL_DIR_RX;
 
@@ -1248,6 +1276,10 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
 			break;
 		CLEAR_AFTER_FIELD(p, fmt.sliced);
 		return ops->vidioc_try_fmt_sliced_vbi_out(file, fh, arg);
+	case V4L2_BUF_TYPE_SDR_CAPTURE:
+		if (unlikely(!is_rx || !is_sdr || !ops->vidioc_try_fmt_sdr_cap))
+			break;
+		return ops->vidioc_try_fmt_sdr_cap(file, fh, arg);
 	}
 	return -EINVAL;
 }
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 931652f..731120a 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -40,6 +40,8 @@ struct v4l2_ioctl_ops {
 					      struct v4l2_fmtdesc *f);
 	int (*vidioc_enum_fmt_vid_out_mplane)(struct file *file, void *fh,
 					      struct v4l2_fmtdesc *f);
+	int (*vidioc_enum_fmt_sdr_cap)(struct file *file, void *fh,
+				       struct v4l2_fmtdesc *f);
 
 	/* VIDIOC_G_FMT handlers */
 	int (*vidioc_g_fmt_vid_cap)    (struct file *file, void *fh,
@@ -62,6 +64,8 @@ struct v4l2_ioctl_ops {
 					   struct v4l2_format *f);
 	int (*vidioc_g_fmt_vid_out_mplane)(struct file *file, void *fh,
 					   struct v4l2_format *f);
+	int (*vidioc_g_fmt_sdr_cap)(struct file *file, void *fh,
+				    struct v4l2_fmtdesc *f);
 
 	/* VIDIOC_S_FMT handlers */
 	int (*vidioc_s_fmt_vid_cap)    (struct file *file, void *fh,
@@ -84,6 +88,8 @@ struct v4l2_ioctl_ops {
 					   struct v4l2_format *f);
 	int (*vidioc_s_fmt_vid_out_mplane)(struct file *file, void *fh,
 					   struct v4l2_format *f);
+	int (*vidioc_s_fmt_sdr_cap)(struct file *file, void *fh,
+				    struct v4l2_fmtdesc *f);
 
 	/* VIDIOC_TRY_FMT handlers */
 	int (*vidioc_try_fmt_vid_cap)    (struct file *file, void *fh,
@@ -106,6 +112,8 @@ struct v4l2_ioctl_ops {
 					     struct v4l2_format *f);
 	int (*vidioc_try_fmt_vid_out_mplane)(struct file *file, void *fh,
 					     struct v4l2_format *f);
+	int (*vidioc_try_fmt_sdr_cap)(struct file *file, void *fh,
+				      struct v4l2_fmtdesc *f);
 
 	/* Buffer handlers */
 	int (*vidioc_reqbufs) (struct file *file, void *fh, struct v4l2_requestbuffers *b);
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 5d8ee92..974c49d 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -139,6 +139,7 @@ enum v4l2_buf_type {
 #endif
 	V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
 	V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
+	V4L2_BUF_TYPE_SDR_CAPTURE          = 11,
 	/* Deprecated, do not use */
 	V4L2_BUF_TYPE_PRIVATE              = 0x80,
 };
@@ -1707,7 +1708,7 @@ struct v4l2_format {
 		struct v4l2_window		win;     /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
 		struct v4l2_vbi_format		vbi;     /* V4L2_BUF_TYPE_VBI_CAPTURE */
 		struct v4l2_sliced_vbi_format	sliced;  /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
-		struct v4l2_sdr_format		fmt;	 /* V4L2_BUF_TYPE_SDR_CAPTURE */
+		struct v4l2_sdr_format		sdr;	 /* V4L2_BUF_TYPE_SDR_CAPTURE */
 		__u8	raw_data[200];                   /* user-defined */
 	} fmt;
 };
-- 
1.8.1.4

[PATCH RFCv1] [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER

[Mauro Carvalho Chehab]

SDR radio requires some other things at VIDIOC_[G|S]_TUNER.
Change the ioctl to support them.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 +++++++++++++---
 drivers/media/tuners/tuner-xc2028.c                |  2 ++
 include/uapi/linux/videodev2.h                     | 40 ++++++++++++++++++++--
 3 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 6cc8201..b8a3bcf 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -200,9 +200,10 @@ audio</entry>
 <constant>_SAP</constant> flag is cleared in the
 <structfield>capability</structfield> field, the corresponding
 <constant>V4L2_TUNER_SUB_</constant> flag must not be set
-here.</para><para>This field is valid only if this is the tuner of the
+here.</para>
+<para>This field is valid only for if this is the tuner of the
 current video input, or when the structure refers to a radio
-tuner.</para></entry>
+tuner. This field is not used by SDR tuners.</para></entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
@@ -216,7 +217,7 @@ unless the requested mode is invalid or unsupported. See <xref
 the selected and received audio programs do not
 match.</para><para>Currently this is the only field of struct
 <structname>v4l2_tuner</structname> applications can
-change.</para></entry>
+change. This field is not used by SDR tuners.</para></entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
@@ -234,7 +235,28 @@ settles at zero, &ie; range is what? --></entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
-	    <entry><structfield>reserved</structfield>[4]</entry>
+	    <entry><structfield>sample_rate</structfield></entry>
+	    <entry spanname="hspan">Sampling rate used by a SDR tuner, in Hz.
+		    This value is valid only for SDR tuners.</entry>
+	  </row>
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>bandwidth</structfield></entry>
+	    <entry spanname="hspan">Bandwidth allowed by the SDR tuner
+		    low-pass saw filter, in Hz. This value is valid only for
+		    SDR tuners.</entry>
+	  </row>
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>int_freq</structfield></entry>
+	    <entry spanname="hspan">Intermediate Frequency (IF) used by
+	    the tuner, in Hz. This value is valid only for
+	    <constant>VIDIOC_G_TUNER</constant>, and it is valid only
+	    on SDR tuners.</entry>
+	  </row>
+	  <row>
+	    <entry>__u32</entry>
+	    <entry><structfield>reserved</structfield>[3]</entry>
 	    <entry spanname="hspan">Reserved for future extensions. Drivers and
 applications must set the array to zero.</entry>
 	  </row>
diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c
index 878d2c4..c61163f 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1020,6 +1020,8 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */,
 	 * Maybe this might also be needed for DTV.
 	 */
 	switch (new_type) {
+	default:			/* SDR currently not supported */
+		goto ret;
 	case V4L2_TUNER_ANALOG_TV:
 		rc = send_seq(priv, {0x00, 0x00});
 
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 974c49d..765b646 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -160,6 +160,24 @@ enum v4l2_tuner_type {
 	V4L2_TUNER_RADIO	     = 1,
 	V4L2_TUNER_ANALOG_TV	     = 2,
 	V4L2_TUNER_DIGITAL_TV	     = 3,
+/*
+ * Even not decoding the signal, SDR tuners may require to adjust IF,
+ * low pass filters, center frequency, etc based on the signal envelope,
+ * and its bandwidth. While we might be using here the V4L2_STD_*
+ * types, plus DVB delsys, that doesn't seem to be the better thing to
+ * do, as:
+ *	1) it would require 64 bits for V4L2 std + 32 bits for DVB std;
+ *	2) non-TV types of envelopes won't work.
+ *
+ * So, add a separate enum to describe the possible types of SDR envelopes.
+ */
+	V4L2_TUNER_SDR_RADIO,		/* Generic non-optimized Radio range */
+	V4L2_TUNER_SDR_ATV_PAL,		/* Optimize for Analog TV, PAL */
+	V4L2_TUNER_SDR_ATV_NTSC,	/* Optimize for Analog TV, NTSC */
+	V4L2_TUNER_SDR_ATV_SECAM,	/* Optimize for Analog TV, SECAM */
+	V4L2_TUNER_SDR_DTV_ATSC,	/* Optimize for Digital TV, ATSC */
+	V4L2_TUNER_SDR_DTV_DVBT,	/* Optimize for Digital TV, DVB-T */
+	V4L2_TUNER_SDR_DTV_ISDBT,	/* Optimize for Digital TV, ISDB-T */
 };
 
 enum v4l2_memory {
@@ -1291,6 +1309,7 @@ struct v4l2_querymenu {
 /*
  *	T U N I N G
  */
+
 struct v4l2_tuner {
 	__u32                   index;
 	__u8			name[32];
@@ -1298,11 +1317,26 @@ struct v4l2_tuner {
 	__u32			capability;
 	__u32			rangelow;
 	__u32			rangehigh;
-	__u32			rxsubchans;
-	__u32			audmode;
+
+	union {
+		/* non-SDR tuners */
+		struct {
+			__u32	rxsubchans;
+			__u32	audmode;
+		};
+		/* SDR tuners - audio demod data makes no sense here */
+		struct {
+			__u32	sample_rate;	/* Sample rate, in Hz */
+			__u32	bandwidth;	/* Bandwidth, in Hz */
+		};
+	};
+
 	__s32			signal;
 	__s32			afc;
-	__u32			reserved[4];
+
+		__u32	int_freq;	/* Read Only - IF used, in Hz */
+	/* non-SDR tuners */
+	__u32		reserved[3];
 };
 
 struct v4l2_modulator {
-- 
1.8.1.4

Re: [PATCH RFCv1] [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER

[Mauro Carvalho Chehab]

Em Sat, 20 Apr 2013 17:10:49 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> SDR radio requires some other things at VIDIOC_[G|S]_TUNER.
> Change the ioctl to support them.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

As a convenience for reviewers, I'm posting the SDR API patches here:
	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/sdr

PS.: I rebase my experimental branches there when needed, as this is just a
scratch repository for me to experiment new things.


> ---
>  Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 +++++++++++++---
>  drivers/media/tuners/tuner-xc2028.c                |  2 ++
>  include/uapi/linux/videodev2.h                     | 40 ++++++++++++++++++++--
>  3 files changed, 65 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> index 6cc8201..b8a3bcf 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> @@ -200,9 +200,10 @@ audio</entry>
>  <constant>_SAP</constant> flag is cleared in the
>  <structfield>capability</structfield> field, the corresponding
>  <constant>V4L2_TUNER_SUB_</constant> flag must not be set
> -here.</para><para>This field is valid only if this is the tuner of the
> +here.</para>
> +<para>This field is valid only for if this is the tuner of the
>  current video input, or when the structure refers to a radio
> -tuner.</para></entry>
> +tuner. This field is not used by SDR tuners.</para></entry>
>  	  </row>
>  	  <row>
>  	    <entry>__u32</entry>
> @@ -216,7 +217,7 @@ unless the requested mode is invalid or unsupported. See <xref
>  the selected and received audio programs do not
>  match.</para><para>Currently this is the only field of struct
>  <structname>v4l2_tuner</structname> applications can
> -change.</para></entry>
> +change. This field is not used by SDR tuners.</para></entry>
>  	  </row>
>  	  <row>
>  	    <entry>__u32</entry>
> @@ -234,7 +235,28 @@ settles at zero, &ie; range is what? --></entry>
>  	  </row>
>  	  <row>
>  	    <entry>__u32</entry>
> -	    <entry><structfield>reserved</structfield>[4]</entry>
> +	    <entry><structfield>sample_rate</structfield></entry>
> +	    <entry spanname="hspan">Sampling rate used by a SDR tuner, in Hz.
> +		    This value is valid only for SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>bandwidth</structfield></entry>
> +	    <entry spanname="hspan">Bandwidth allowed by the SDR tuner
> +		    low-pass saw filter, in Hz. This value is valid only for
> +		    SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>int_freq</structfield></entry>
> +	    <entry spanname="hspan">Intermediate Frequency (IF) used by
> +	    the tuner, in Hz. This value is valid only for
> +	    <constant>VIDIOC_G_TUNER</constant>, and it is valid only
> +	    on SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>reserved</structfield>[3]</entry>
>  	    <entry spanname="hspan">Reserved for future extensions. Drivers and
>  applications must set the array to zero.</entry>
>  	  </row>
> diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c
> index 878d2c4..c61163f 100644
> --- a/drivers/media/tuners/tuner-xc2028.c
> +++ b/drivers/media/tuners/tuner-xc2028.c
> @@ -1020,6 +1020,8 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */,
>  	 * Maybe this might also be needed for DTV.
>  	 */
>  	switch (new_type) {
> +	default:			/* SDR currently not supported */
> +		goto ret;
>  	case V4L2_TUNER_ANALOG_TV:
>  		rc = send_seq(priv, {0x00, 0x00});
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 974c49d..765b646 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -160,6 +160,24 @@ enum v4l2_tuner_type {
>  	V4L2_TUNER_RADIO	     = 1,
>  	V4L2_TUNER_ANALOG_TV	     = 2,
>  	V4L2_TUNER_DIGITAL_TV	     = 3,
> +/*
> + * Even not decoding the signal, SDR tuners may require to adjust IF,
> + * low pass filters, center frequency, etc based on the signal envelope,
> + * and its bandwidth. While we might be using here the V4L2_STD_*
> + * types, plus DVB delsys, that doesn't seem to be the better thing to
> + * do, as:
> + *	1) it would require 64 bits for V4L2 std + 32 bits for DVB std;
> + *	2) non-TV types of envelopes won't work.
> + *
> + * So, add a separate enum to describe the possible types of SDR envelopes.
> + */
> +	V4L2_TUNER_SDR_RADIO,		/* Generic non-optimized Radio range */
> +	V4L2_TUNER_SDR_ATV_PAL,		/* Optimize for Analog TV, PAL */
> +	V4L2_TUNER_SDR_ATV_NTSC,	/* Optimize for Analog TV, NTSC */
> +	V4L2_TUNER_SDR_ATV_SECAM,	/* Optimize for Analog TV, SECAM */
> +	V4L2_TUNER_SDR_DTV_ATSC,	/* Optimize for Digital TV, ATSC */
> +	V4L2_TUNER_SDR_DTV_DVBT,	/* Optimize for Digital TV, DVB-T */
> +	V4L2_TUNER_SDR_DTV_ISDBT,	/* Optimize for Digital TV, ISDB-T */
>  };
>  
>  enum v4l2_memory {
> @@ -1291,6 +1309,7 @@ struct v4l2_querymenu {
>  /*
>   *	T U N I N G
>   */
> +
>  struct v4l2_tuner {
>  	__u32                   index;
>  	__u8			name[32];
> @@ -1298,11 +1317,26 @@ struct v4l2_tuner {
>  	__u32			capability;
>  	__u32			rangelow;
>  	__u32			rangehigh;
> -	__u32			rxsubchans;
> -	__u32			audmode;
> +
> +	union {
> +		/* non-SDR tuners */
> +		struct {
> +			__u32	rxsubchans;
> +			__u32	audmode;
> +		};
> +		/* SDR tuners - audio demod data makes no sense here */
> +		struct {
> +			__u32	sample_rate;	/* Sample rate, in Hz */
> +			__u32	bandwidth;	/* Bandwidth, in Hz */
> +		};
> +	};
> +
>  	__s32			signal;
>  	__s32			afc;
> -	__u32			reserved[4];
> +
> +		__u32	int_freq;	/* Read Only - IF used, in Hz */
> +	/* non-SDR tuners */
> +	__u32		reserved[3];
>  };
>  
>  struct v4l2_modulator {


-- 

Cheers,
Mauro

Re: [PATCH RFCv1] [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER

[Mauro Carvalho Chehab]

Em 20-04-2013 17:10, Mauro Carvalho Chehab escreveu:
> SDR radio requires some other things at VIDIOC_[G|S]_TUNER.
> Change the ioctl to support them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> ---
>   Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 +++++++++++++---
>   drivers/media/tuners/tuner-xc2028.c                |  2 ++
>   include/uapi/linux/videodev2.h                     | 40 ++++++++++++++++++++--
>   3 files changed, 65 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> index 6cc8201..b8a3bcf 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
> @@ -200,9 +200,10 @@ audio</entry>
>   <constant>_SAP</constant> flag is cleared in the
>   <structfield>capability</structfield> field, the corresponding
>   <constant>V4L2_TUNER_SUB_</constant> flag must not be set
> -here.</para><para>This field is valid only if this is the tuner of the
> +here.</para>
> +<para>This field is valid only for if this is the tuner of the
>   current video input, or when the structure refers to a radio
> -tuner.</para></entry>
> +tuner. This field is not used by SDR tuners.</para></entry>
>   	  </row>
>   	  <row>
>   	    <entry>__u32</entry>
> @@ -216,7 +217,7 @@ unless the requested mode is invalid or unsupported. See <xref
>   the selected and received audio programs do not
>   match.</para><para>Currently this is the only field of struct
>   <structname>v4l2_tuner</structname> applications can
> -change.</para></entry>
> +change. This field is not used by SDR tuners.</para></entry>
>   	  </row>
>   	  <row>
>   	    <entry>__u32</entry>
> @@ -234,7 +235,28 @@ settles at zero, &ie; range is what? --></entry>
>   	  </row>
>   	  <row>
>   	    <entry>__u32</entry>
> -	    <entry><structfield>reserved</structfield>[4]</entry>
> +	    <entry><structfield>sample_rate</structfield></entry>
> +	    <entry spanname="hspan">Sampling rate used by a SDR tuner, in Hz.
> +		    This value is valid only for SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>bandwidth</structfield></entry>
> +	    <entry spanname="hspan">Bandwidth allowed by the SDR tuner
> +		    low-pass saw filter, in Hz. This value is valid only for
> +		    SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>int_freq</structfield></entry>
> +	    <entry spanname="hspan">Intermediate Frequency (IF) used by
> +	    the tuner, in Hz. This value is valid only for
> +	    <constant>VIDIOC_G_TUNER</constant>, and it is valid only
> +	    on SDR tuners.</entry>
> +	  </row>
> +	  <row>
> +	    <entry>__u32</entry>
> +	    <entry><structfield>reserved</structfield>[3]</entry>
>   	    <entry spanname="hspan">Reserved for future extensions. Drivers and
>   applications must set the array to zero.</entry>
>   	  </row>
> diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c
> index 878d2c4..c61163f 100644
> --- a/drivers/media/tuners/tuner-xc2028.c
> +++ b/drivers/media/tuners/tuner-xc2028.c
> @@ -1020,6 +1020,8 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */,
>   	 * Maybe this might also be needed for DTV.
>   	 */
>   	switch (new_type) {
> +	default:			/* SDR currently not supported */
> +		goto ret;
>   	case V4L2_TUNER_ANALOG_TV:
>   		rc = send_seq(priv, {0x00, 0x00});
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 974c49d..765b646 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -160,6 +160,24 @@ enum v4l2_tuner_type {
>   	V4L2_TUNER_RADIO	     = 1,
>   	V4L2_TUNER_ANALOG_TV	     = 2,
>   	V4L2_TUNER_DIGITAL_TV	     = 3,
> +/*
> + * Even not decoding the signal, SDR tuners may require to adjust IF,
> + * low pass filters, center frequency, etc based on the signal envelope,
> + * and its bandwidth. While we might be using here the V4L2_STD_*
> + * types, plus DVB delsys, that doesn't seem to be the better thing to
> + * do, as:
> + *	1) it would require 64 bits for V4L2 std + 32 bits for DVB std;
> + *	2) non-TV types of envelopes won't work.
> + *
> + * So, add a separate enum to describe the possible types of SDR envelopes.
> + */
> +	V4L2_TUNER_SDR_RADIO,		/* Generic non-optimized Radio range */

> +	V4L2_TUNER_SDR_ATV_PAL,		/* Optimize for Analog TV, PAL */
> +	V4L2_TUNER_SDR_ATV_NTSC,	/* Optimize for Analog TV, NTSC */
> +	V4L2_TUNER_SDR_ATV_SECAM,	/* Optimize for Analog TV, SECAM */

Hmm... this will not work. There are several tuners that require to know
more about the standard than just the color encoding.

Ok, there are several tuners that also do PLL lock on the audio sub-carrier,
as they have there audio decoder like tda9887 (on analog tuners)
or an equivalent IP block on silicon tuners. I'm not even sure if such
tuners will work properly as SDR. Perhaps it is possible to program them
on a generic mode.

So, I'm starting to suspect that, in order to support SDR devices with
a TV tuner, it will need to allow selecting an analog standard.

Perhaps the best way is to use here, instead just one type for analog TV,
and accept VIDIOC_*_STD ioctls to fine tune, if tuner needs it.

On the next RFC, I'll just merge those three into:
	V4L2_TUNER_SDR_ATV

> +	V4L2_TUNER_SDR_DTV_ATSC,	/* Optimize for Digital TV, ATSC */
> +	V4L2_TUNER_SDR_DTV_DVBT,	/* Optimize for Digital TV, DVB-T */
> +	V4L2_TUNER_SDR_DTV_ISDBT,	/* Optimize for Digital TV, ISDB-T */
>   };
>
>   enum v4l2_memory {
> @@ -1291,6 +1309,7 @@ struct v4l2_querymenu {
>   /*
>    *	T U N I N G
>    */
> +
>   struct v4l2_tuner {
>   	__u32                   index;
>   	__u8			name[32];
> @@ -1298,11 +1317,26 @@ struct v4l2_tuner {
>   	__u32			capability;
>   	__u32			rangelow;
>   	__u32			rangehigh;
> -	__u32			rxsubchans;
> -	__u32			audmode;
> +
> +	union {
> +		/* non-SDR tuners */
> +		struct {
> +			__u32	rxsubchans;
> +			__u32	audmode;
> +		};
> +		/* SDR tuners - audio demod data makes no sense here */
> +		struct {
> +			__u32	sample_rate;	/* Sample rate, in Hz */
> +			__u32	bandwidth;	/* Bandwidth, in Hz */
> +		};
> +	};
> +
>   	__s32			signal;
>   	__s32			afc;
> -	__u32			reserved[4];
> +
> +		__u32	int_freq;	/* Read Only - IF used, in Hz */
> +	/* non-SDR tuners */
> +	__u32		reserved[3];
>   };
>
>   struct v4l2_modulator {
>

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Hans Verkuil]

Hi Mauro,

On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
> This is a version 2 of the V4L2 API bits to support Software Digital
> Radio (SDR).

It looks pretty good to me. Just one question though: what is your rationale
for choosing a new device name (/dev/sdrX) instead of using the existing
/dev/radioX?

I'm not saying I'm opposed to it, in fact I agree with it, but I think the
reasons for it should be stated explicitly.

Regards,

	Hans

> 
> 
> The changes from version 1 are:
> 	- fix compilation;
> 	- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
> 	  with the corresponding documentation;
> 	- remove legacy V4L1 buffer types from videobuf2.h.
> 
> With regards to VIDIOC_S_TUNER, what's currently defined there is
> that, in contrary to what a radio device does, this ioctl would
> set the input.
> 
> This patch adds the very basic stuff for SDR:
> 
> 	- a separate devnode;
> 	- an VIDIOC_QUERYCAP caps for SDR;
> 	- a fourcc group for SDR;
> 	- a few DocBook bits.
> 
> What's missing:
> 	- SDR specific controls;
> 	- Sample rate config;
> 	...
> 
> As discussing DocBook changes inside the patch is hard, I'm adding here
> the DocBook formatted changes.
> 
> The DocBook changes add the following bits:
> 
> At Chapter 1. Common API Elements, it adds:
> 
> <text>
> Software Digital Radio (SDR) Tuners and Modulators
> ==================================================
> 
> Those devices are special types of Radio devices that don't have any 
> analog demodulator. Instead, it samples the radio IF or baseband and 
> sends the samples for userspace to demodulate. 
> 
> Tuners
> ======
> 
> SDR receivers can have one or more tuners sampling RF signals. Each 
> tuner is associated with one or more inputs, depending on the number of 
> RF connectors on the tuner. The type field of the respective struct 
> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to 
> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of 
> the tuner input.
> 
> To query and change tuner properties applications use the VIDIOC_G_TUNER 
> and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned 
> by VIDIOC_G_TUNER also contains signal status information applicable 
> when the tuner of the current SDR input is queried. In order to change 
> the SDR input, VIDIOC_S_TUNER with a new SDR index should be called. 
> Drivers must support both ioctls and set the V4L2_CAP_SDR and 
> V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the 
> VIDIOC_QUERYCAP ioctl.
> 
> Modulators
> ==========
> 
> To be defined.
> </text>
> 
> At the end of Chapter 2. Image Formats, it adds:
> 
> <text>
> SDR format struture
> ===================
> 
> Table 2.4. struct v4l2_sdr_format
> =================================
> 
> __u32	sampleformat	The format of the samples used by the SDR device.
> 			This is a little endian four character code.
> 
> Table 2.5. SDR formats
> ======================
> 
> V4L2_SDR_FMT_I8Q8	Samples are given by a sequence of 8 bits in-phase(I)
> 			and 8 bits quadrature (Q) samples taken from a
> 			signal(t) represented by the following expression:
> 			signal(t) = I * cos(2Ï€ fc t) - Q * sin(2Ï€ fc t)
> </text>
> 
> Of course, other formats will be needed at Table 2.5, as SDR could also 
> be taken baseband samples, being, for example, a simple sequence of 
> equally time-spaced digitalized samples of the signal in time.
> SDR samples could also use other resolutions, use a non-linear
> (A-law, u-law) ADC, or even compress the samples (with ADPCM, for 
> example). So, this table will grow as newer devices get added, and an
> userspace library may be required to convert them into some common
> format.
> 
> At "Chapter 4. Interfaces", it adds the following text:
> 
> <text>
> Software Digital Radio(SDR) Interface
> =====================================
> 
> This interface is intended for Software Digital Radio (SDR) receivers 
> and transmitters.
> 
> Conventionally V4L2 SDR devices are accessed through character device 
> special files named /dev/sdr0 to/dev/radio255 and uses a dynamically 
> allocated major/minor number.
> 
> Querying Capabilities
> =====================
> 
> Devices supporting the radio interface set the V4L2_CAP_SDR and 
> V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of 
> struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other 
> combinations of capability flags are reserved for future extensions. 
> 
> Supplemental Functions
> ======================
> 
> SDR receivers should support tuner ioctls.
> 
> SDR transmitter ioctl's will be defined in the future.
> 
> SDR devices should also support one or more of the following I/O ioctls: 
> read or write, memory mapped IO, user memory IO and/or DMA buffers.
> 
> SDR devices can also support controls ioctls.
> 
> The SDR Input/Output are A/D or D/A samples taken from a modulated 
> signal, and can eventually be packed by the hardware. They are generally 
> encoded using cartesian in-phase/quadrature (I/Q) samples, to make 
> demodulation easier. The format of the samples should be according with 
> SDR format.
> </text>
> 
> Note: "SDR format" on the last paragraph is an hyperlink to
> Chapter 2. Image Formats.
> 
> At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
> 
> <text>
> Table A.93. Device Capabilities Flags
> ...
> V4L2_CAP_SDR	0x00100000	The device is a Software Digital Radio. 
> 				For more information about SDR programming
> 				see the section called “Software Digital 
> 				Radio (SDR) Tuners and Modulators”.
> </text>
> 
> Mauro Carvalho Chehab (3):
>   [media] Add SDR at V4L2 API
>   videodev2.h: Remove the unused old V4L1 buffer types
>   [media] V4L2 api: Add a buffer capture type for SDR
> 
>  Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
>  Documentation/DocBook/media/v4l/dev-capture.xml    | 26 ++++++++------
>  Documentation/DocBook/media/v4l/io.xml             |  6 ++++
>  Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
>  Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
>  .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
>  drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c               | 32 +++++++++++++++++
>  include/media/v4l2-dev.h                           |  3 +-
>  include/media/v4l2-ioctl.h                         |  8 +++++
>  include/uapi/linux/videodev2.h                     | 33 +++++++----------
>  11 files changed, 163 insertions(+), 32 deletions(-)
> 
> 

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Mauro Carvalho Chehab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252; format=flowed, Size: 9093 bytes --]

Em 21-04-2013 06:34, Hans Verkuil escreveu:
> Hi Mauro,
>
> On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
>> This is a version 2 of the V4L2 API bits to support Software Digital
>> Radio (SDR).
>
> It looks pretty good to me. Just one question though: what is your rationale
> for choosing a new device name (/dev/sdrX) instead of using the existing
> /dev/radioX?
>
> I'm not saying I'm opposed to it, in fact I agree with it, but I think the
> reasons for it should be stated explicitly.

Because a SDR radio is different than a normal radio device:

A normal radio device is actually radio and hardware demod. As the demod
is in hardware, several things that are required for the demodulate the
signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to
the device and aren't part of the API.

SDR radio, on the other hand, requires that every control needed by the
tuner to be exposed on userspace, as userspace needs to adjust the
software decoder to match them.

So, they're different.

Btw, it is also possible that the same device to offer analog TV,
digital TV, hardware-decoded radio and SDR. One example of such devices
are cx88. The existing drivers supports already hardware demodulers,
but the device also allows to export the collected samples to userspace.
It is just a matter of programming the cx88 RISC code to do that.

Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs)
and another one for IF signal capable of working up to 35.44 MHz sampling
rate (on "8x FSC PAL" supported mode). It would be easy to export its
output to userspace.

Btw, while seeking for more data about SDR this weekend, I discovered
one project doing exactly that:

	http://www.geocities.ws/how_chee/cx23881fc6.htm

I did a very quick look at its source code. It is limited, as it works
only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and
I'm not sure if it allows using both ADCs.

Yet, It shows that it is possible that a driver/subdrivers to offer
the 4 different types of devices:
	- analog TV;
	- digital TV;
	- radio;
	- SDR.

So, IMO we should not abuse of /dev/radio for SDR.

Regards,
Mauro

[1] The trick is to program the cx88 RISC to output data from the
samplers, instead of from the demods. We do that already for the
audio standard detection.

I've no idea if cx88 has any upper DMA maximum bandwidth. If it has,
that might be the reason to limit to 27MHz, 8 bits, but I suspect
that it was done that way just because it was easier.

Btw, I'm almost sure that other Conexant designs can also offer
similar interfaces.


>
> Regards,
>
> 	Hans
>
>>
>>
>> The changes from version 1 are:
>> 	- fix compilation;
>> 	- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
>> 	  with the corresponding documentation;
>> 	- remove legacy V4L1 buffer types from videobuf2.h.
>>
>> With regards to VIDIOC_S_TUNER, what's currently defined there is
>> that, in contrary to what a radio device does, this ioctl would
>> set the input.
>>
>> This patch adds the very basic stuff for SDR:
>>
>> 	- a separate devnode;
>> 	- an VIDIOC_QUERYCAP caps for SDR;
>> 	- a fourcc group for SDR;
>> 	- a few DocBook bits.
>>
>> What's missing:
>> 	- SDR specific controls;
>> 	- Sample rate config;
>> 	...
>>
>> As discussing DocBook changes inside the patch is hard, I'm adding here
>> the DocBook formatted changes.
>>
>> The DocBook changes add the following bits:
>>
>> At Chapter 1. Common API Elements, it adds:
>>
>> <text>
>> Software Digital Radio (SDR) Tuners and Modulators
>> ==================================================
>>
>> Those devices are special types of Radio devices that don't have any
>> analog demodulator. Instead, it samples the radio IF or baseband and
>> sends the samples for userspace to demodulate.
>>
>> Tuners
>> ======
>>
>> SDR receivers can have one or more tuners sampling RF signals. Each
>> tuner is associated with one or more inputs, depending on the number of
>> RF connectors on the tuner. The type field of the respective struct
>> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
>> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of
>> the tuner input.
>>
>> To query and change tuner properties applications use the VIDIOC_G_TUNER
>> and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned
>> by VIDIOC_G_TUNER also contains signal status information applicable
>> when the tuner of the current SDR input is queried. In order to change
>> the SDR input, VIDIOC_S_TUNER with a new SDR index should be called.
>> Drivers must support both ioctls and set the V4L2_CAP_SDR and
>> V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the
>> VIDIOC_QUERYCAP ioctl.
>>
>> Modulators
>> ==========
>>
>> To be defined.
>> </text>
>>
>> At the end of Chapter 2. Image Formats, it adds:
>>
>> <text>
>> SDR format struture
>> ===================
>>
>> Table 2.4. struct v4l2_sdr_format
>> =================================
>>
>> __u32	sampleformat	The format of the samples used by the SDR device.
>> 			This is a little endian four character code.
>>
>> Table 2.5. SDR formats
>> ======================
>>
>> V4L2_SDR_FMT_I8Q8	Samples are given by a sequence of 8 bits in-phase(I)
>> 			and 8 bits quadrature (Q) samples taken from a
>> 			signal(t) represented by the following expression:
>> 			signal(t) = I * cos(2π fc t) - Q * sin(2π fc t)
>> </text>
>>
>> Of course, other formats will be needed at Table 2.5, as SDR could also
>> be taken baseband samples, being, for example, a simple sequence of
>> equally time-spaced digitalized samples of the signal in time.
>> SDR samples could also use other resolutions, use a non-linear
>> (A-law, u-law) ADC, or even compress the samples (with ADPCM, for
>> example). So, this table will grow as newer devices get added, and an
>> userspace library may be required to convert them into some common
>> format.
>>
>> At "Chapter 4. Interfaces", it adds the following text:
>>
>> <text>
>> Software Digital Radio(SDR) Interface
>> =====================================
>>
>> This interface is intended for Software Digital Radio (SDR) receivers
>> and transmitters.
>>
>> Conventionally V4L2 SDR devices are accessed through character device
>> special files named /dev/sdr0 to/dev/radio255 and uses a dynamically
>> allocated major/minor number.
>>
>> Querying Capabilities
>> =====================
>>
>> Devices supporting the radio interface set the V4L2_CAP_SDR and
>> V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of
>> struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other
>> combinations of capability flags are reserved for future extensions.
>>
>> Supplemental Functions
>> ======================
>>
>> SDR receivers should support tuner ioctls.
>>
>> SDR transmitter ioctl's will be defined in the future.
>>
>> SDR devices should also support one or more of the following I/O ioctls:
>> read or write, memory mapped IO, user memory IO and/or DMA buffers.
>>
>> SDR devices can also support controls ioctls.
>>
>> The SDR Input/Output are A/D or D/A samples taken from a modulated
>> signal, and can eventually be packed by the hardware. They are generally
>> encoded using cartesian in-phase/quadrature (I/Q) samples, to make
>> demodulation easier. The format of the samples should be according with
>> SDR format.
>> </text>
>>
>> Note: "SDR format" on the last paragraph is an hyperlink to
>> Chapter 2. Image Formats.
>>
>> At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
>>
>> <text>
>> Table A.93. Device Capabilities Flags
>> ...
>> V4L2_CAP_SDR	0x00100000	The device is a Software Digital Radio.
>> 				For more information about SDR programming
>> 				see the section called “Software Digital
>> 				Radio (SDR) Tuners and Modulators”.
>> </text>
>>
>> Mauro Carvalho Chehab (3):
>>    [media] Add SDR at V4L2 API
>>    videodev2.h: Remove the unused old V4L1 buffer types
>>    [media] V4L2 api: Add a buffer capture type for SDR
>>
>>   Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
>>   Documentation/DocBook/media/v4l/dev-capture.xml    | 26 ++++++++------
>>   Documentation/DocBook/media/v4l/io.xml             |  6 ++++
>>   Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
>>   Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
>>   .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
>>   drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
>>   drivers/media/v4l2-core/v4l2-ioctl.c               | 32 +++++++++++++++++
>>   include/media/v4l2-dev.h                           |  3 +-
>>   include/media/v4l2-ioctl.h                         |  8 +++++
>>   include/uapi/linux/videodev2.h                     | 33 +++++++----------
>>   11 files changed, 163 insertions(+), 32 deletions(-)
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Hans Verkuil]

On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote:
> Em 21-04-2013 06:34, Hans Verkuil escreveu:
> > Hi Mauro,
> >
> > On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
> >> This is a version 2 of the V4L2 API bits to support Software Digital
> >> Radio (SDR).
> >
> > It looks pretty good to me. Just one question though: what is your rationale
> > for choosing a new device name (/dev/sdrX) instead of using the existing
> > /dev/radioX?
> >
> > I'm not saying I'm opposed to it, in fact I agree with it, but I think the
> > reasons for it should be stated explicitly.
> 
> Because a SDR radio is different than a normal radio device:
> 
> A normal radio device is actually radio and hardware demod. As the demod
> is in hardware, several things that are required for the demodulate the
> signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to
> the device and aren't part of the API.
> 
> SDR radio, on the other hand, requires that every control needed by the
> tuner to be exposed on userspace, as userspace needs to adjust the
> software decoder to match them.
> 
> So, they're different.
> 
> Btw, it is also possible that the same device to offer analog TV,
> digital TV, hardware-decoded radio and SDR. One example of such devices
> are cx88. The existing drivers supports already hardware demodulers,
> but the device also allows to export the collected samples to userspace.
> It is just a matter of programming the cx88 RISC code to do that.
> 
> Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs)
> and another one for IF signal capable of working up to 35.44 MHz sampling
> rate (on "8x FSC PAL" supported mode). It would be easy to export its
> output to userspace.
> 
> Btw, while seeking for more data about SDR this weekend, I discovered
> one project doing exactly that:
> 
> 	http://www.geocities.ws/how_chee/cx23881fc6.htm
> 
> I did a very quick look at its source code. It is limited, as it works
> only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and
> I'm not sure if it allows using both ADCs.
> 
> Yet, It shows that it is possible that a driver/subdrivers to offer
> the 4 different types of devices:
> 	- analog TV;
> 	- digital TV;
> 	- radio;
> 	- SDR.
> 
> So, IMO we should not abuse of /dev/radio for SDR.

I agree. I just wanted to have it explicit :-)

I also think we should provide and maintain a library doing the decoding for
SDR that is part of v4l-utils. Otherwise you'll end up with a big userspace
mess.

And we want this checked by v4l2-compliance, and qv4l2 should be able to use
the library so we have at least one application that can handle it.

Regards,

	Hans

> 
> Regards,
> Mauro
> 
> [1] The trick is to program the cx88 RISC to output data from the
> samplers, instead of from the demods. We do that already for the
> audio standard detection.
> 
> I've no idea if cx88 has any upper DMA maximum bandwidth. If it has,
> that might be the reason to limit to 27MHz, 8 bits, but I suspect
> that it was done that way just because it was easier.
> 
> Btw, I'm almost sure that other Conexant designs can also offer
> similar interfaces.
> 
> 
> >
> > Regards,
> >
> > 	Hans
> >
> >>
> >>
> >> The changes from version 1 are:
> >> 	- fix compilation;
> >> 	- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
> >> 	  with the corresponding documentation;
> >> 	- remove legacy V4L1 buffer types from videobuf2.h.
> >>
> >> With regards to VIDIOC_S_TUNER, what's currently defined there is
> >> that, in contrary to what a radio device does, this ioctl would
> >> set the input.
> >>
> >> This patch adds the very basic stuff for SDR:
> >>
> >> 	- a separate devnode;
> >> 	- an VIDIOC_QUERYCAP caps for SDR;
> >> 	- a fourcc group for SDR;
> >> 	- a few DocBook bits.
> >>
> >> What's missing:
> >> 	- SDR specific controls;
> >> 	- Sample rate config;
> >> 	...
> >>
> >> As discussing DocBook changes inside the patch is hard, I'm adding here
> >> the DocBook formatted changes.
> >>
> >> The DocBook changes add the following bits:
> >>
> >> At Chapter 1. Common API Elements, it adds:
> >>
> >> <text>
> >> Software Digital Radio (SDR) Tuners and Modulators
> >> ==================================================
> >>
> >> Those devices are special types of Radio devices that don't have any
> >> analog demodulator. Instead, it samples the radio IF or baseband and
> >> sends the samples for userspace to demodulate.
> >>
> >> Tuners
> >> ======
> >>
> >> SDR receivers can have one or more tuners sampling RF signals. Each
> >> tuner is associated with one or more inputs, depending on the number of
> >> RF connectors on the tuner. The type field of the respective struct
> >> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
> >> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of
> >> the tuner input.
> >>
> >> To query and change tuner properties applications use the VIDIOC_G_TUNER
> >> and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned
> >> by VIDIOC_G_TUNER also contains signal status information applicable
> >> when the tuner of the current SDR input is queried. In order to change
> >> the SDR input, VIDIOC_S_TUNER with a new SDR index should be called.
> >> Drivers must support both ioctls and set the V4L2_CAP_SDR and
> >> V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the
> >> VIDIOC_QUERYCAP ioctl.
> >>
> >> Modulators
> >> ==========
> >>
> >> To be defined.
> >> </text>
> >>
> >> At the end of Chapter 2. Image Formats, it adds:
> >>
> >> <text>
> >> SDR format struture
> >> ===================
> >>
> >> Table 2.4. struct v4l2_sdr_format
> >> =================================
> >>
> >> __u32	sampleformat	The format of the samples used by the SDR device.
> >> 			This is a little endian four character code.
> >>
> >> Table 2.5. SDR formats
> >> ======================
> >>
> >> V4L2_SDR_FMT_I8Q8	Samples are given by a sequence of 8 bits in-phase(I)
> >> 			and 8 bits quadrature (Q) samples taken from a
> >> 			signal(t) represented by the following expression:
> >> 			signal(t) = I * cos(2Ï€ fc t) - Q * sin(2Ï€ fc t)
> >> </text>
> >>
> >> Of course, other formats will be needed at Table 2.5, as SDR could also
> >> be taken baseband samples, being, for example, a simple sequence of
> >> equally time-spaced digitalized samples of the signal in time.
> >> SDR samples could also use other resolutions, use a non-linear
> >> (A-law, u-law) ADC, or even compress the samples (with ADPCM, for
> >> example). So, this table will grow as newer devices get added, and an
> >> userspace library may be required to convert them into some common
> >> format.
> >>
> >> At "Chapter 4. Interfaces", it adds the following text:
> >>
> >> <text>
> >> Software Digital Radio(SDR) Interface
> >> =====================================
> >>
> >> This interface is intended for Software Digital Radio (SDR) receivers
> >> and transmitters.
> >>
> >> Conventionally V4L2 SDR devices are accessed through character device
> >> special files named /dev/sdr0 to/dev/radio255 and uses a dynamically
> >> allocated major/minor number.
> >>
> >> Querying Capabilities
> >> =====================
> >>
> >> Devices supporting the radio interface set the V4L2_CAP_SDR and
> >> V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of
> >> struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other
> >> combinations of capability flags are reserved for future extensions.
> >>
> >> Supplemental Functions
> >> ======================
> >>
> >> SDR receivers should support tuner ioctls.
> >>
> >> SDR transmitter ioctl's will be defined in the future.
> >>
> >> SDR devices should also support one or more of the following I/O ioctls:
> >> read or write, memory mapped IO, user memory IO and/or DMA buffers.
> >>
> >> SDR devices can also support controls ioctls.
> >>
> >> The SDR Input/Output are A/D or D/A samples taken from a modulated
> >> signal, and can eventually be packed by the hardware. They are generally
> >> encoded using cartesian in-phase/quadrature (I/Q) samples, to make
> >> demodulation easier. The format of the samples should be according with
> >> SDR format.
> >> </text>
> >>
> >> Note: "SDR format" on the last paragraph is an hyperlink to
> >> Chapter 2. Image Formats.
> >>
> >> At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
> >>
> >> <text>
> >> Table A.93. Device Capabilities Flags
> >> ...
> >> V4L2_CAP_SDR	0x00100000	The device is a Software Digital Radio.
> >> 				For more information about SDR programming
> >> 				see the section called “Software Digital
> >> 				Radio (SDR) Tuners and Modulators�.
> >> </text>
> >>
> >> Mauro Carvalho Chehab (3):
> >>    [media] Add SDR at V4L2 API
> >>    videodev2.h: Remove the unused old V4L1 buffer types
> >>    [media] V4L2 api: Add a buffer capture type for SDR
> >>
> >>   Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
> >>   Documentation/DocBook/media/v4l/dev-capture.xml    | 26 ++++++++------
> >>   Documentation/DocBook/media/v4l/io.xml             |  6 ++++
> >>   Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
> >>   Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
> >>   .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
> >>   drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
> >>   drivers/media/v4l2-core/v4l2-ioctl.c               | 32 +++++++++++++++++
> >>   include/media/v4l2-dev.h                           |  3 +-
> >>   include/media/v4l2-ioctl.h                         |  8 +++++
> >>   include/uapi/linux/videodev2.h                     | 33 +++++++----------
> >>   11 files changed, 163 insertions(+), 32 deletions(-)
> >>
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Mauro Carvalho Chehab]

Em 21-04-2013 07:34, Hans Verkuil escreveu:
> On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote:
>> Em 21-04-2013 06:34, Hans Verkuil escreveu:
>>> Hi Mauro,
>>>
>>> On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
>>>> This is a version 2 of the V4L2 API bits to support Software Digital
>>>> Radio (SDR).
>>>
>>> It looks pretty good to me. Just one question though: what is your rationale
>>> for choosing a new device name (/dev/sdrX) instead of using the existing
>>> /dev/radioX?
>>>
>>> I'm not saying I'm opposed to it, in fact I agree with it, but I think the
>>> reasons for it should be stated explicitly.
>>
>> Because a SDR radio is different than a normal radio device:
>>
>> A normal radio device is actually radio and hardware demod. As the demod
>> is in hardware, several things that are required for the demodulate the
>> signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to
>> the device and aren't part of the API.
>>
>> SDR radio, on the other hand, requires that every control needed by the
>> tuner to be exposed on userspace, as userspace needs to adjust the
>> software decoder to match them.
>>
>> So, they're different.
>>
>> Btw, it is also possible that the same device to offer analog TV,
>> digital TV, hardware-decoded radio and SDR. One example of such devices
>> are cx88. The existing drivers supports already hardware demodulers,
>> but the device also allows to export the collected samples to userspace.
>> It is just a matter of programming the cx88 RISC code to do that.
>>
>> Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs)
>> and another one for IF signal capable of working up to 35.44 MHz sampling
>> rate (on "8x FSC PAL" supported mode). It would be easy to export its
>> output to userspace.
>>
>> Btw, while seeking for more data about SDR this weekend, I discovered
>> one project doing exactly that:
>>
>> 	http://www.geocities.ws/how_chee/cx23881fc6.htm
>>
>> I did a very quick look at its source code. It is limited, as it works
>> only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and
>> I'm not sure if it allows using both ADCs.
>>
>> Yet, It shows that it is possible that a driver/subdrivers to offer
>> the 4 different types of devices:
>> 	- analog TV;
>> 	- digital TV;
>> 	- radio;
>> 	- SDR.
>>
>> So, IMO we should not abuse of /dev/radio for SDR.
>
> I agree. I just wanted to have it explicit :-)

Sure. I'll summarize the above at the commit patch on a next version.

> I also think we should provide and maintain a library doing the decoding for
> SDR that is part of v4l-utils. Otherwise you'll end up with a big userspace
> mess.

I partially agree. I've seen some SDR usages that are experimental
app-specific stuff like GSM and ADSB receivers.

You can see a sample of such projects that use one of the existing
userspace libraries at:
	http://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps

In principle, I don't think it is worth to invest our time handling
all sorts of possible decoders at v4l-apps[1].

It makes more sense to offer instead low level library there to allow
applications to abstract from hardware differences, like doing
fourcc conversions.

There are at least two ways of outputting data on the known devices:
	- simple ADC samples in time domain;
	- IF using in-phase/quadrature (I/Q) samples.

Also, the number of bits can vary from device to device, being 8 bits
and 10 bits the most common ones. I think I saw some analog TV devices
using a 12 bits sampler somewhere, but I can't remember if it is
flexible enough to output sampled data to the DMA engine, or if they're
just simple I2C devices that output only decoded data via I2S.

Anyway, the low-level library should take care of those differences,
just like it is done at libv4l for image standards.

With time, the library may also provide a basic set of decoders for
more common analog radio standards: FM, AM DSB-FC, AM DSB-SC, AM SSB.

It may also provide analog TV decoders and even digital TV ones,
but writing them may take a lot of time. It could be good projects
for Google's Summer of Code and similar events.

I would love to have a set of those decodes there, as they can
offer a nice set of instrumentation tools to test what is being
received on some place and calibrate device drivers.

I would love even more to have SDR TX devices. With both TX and RX
working, one could send us a sample of what they're receiving on
some place, and this signal could be used by the developer to test
their devices, improving the driver to better receive such signals.

I suspect that low-cost SDR TX devices will come with time.

[1] Ok, if someone wants to add support for those app-specific decoders,
maintain it there and it doesn't offer any legal issues that would
restrict v4l-utils distribution, I'm not against to add it there.

>
> And we want this checked by v4l2-compliance, and qv4l2 should be able to use
> the library so we have at least one application that can handle it.
>
> Regards,
>
> 	Hans
>
>>
>> Regards,
>> Mauro
>>
>> [1] The trick is to program the cx88 RISC to output data from the
>> samplers, instead of from the demods. We do that already for the
>> audio standard detection.
>>
>> I've no idea if cx88 has any upper DMA maximum bandwidth. If it has,
>> that might be the reason to limit to 27MHz, 8 bits, but I suspect
>> that it was done that way just because it was easier.
>>
>> Btw, I'm almost sure that other Conexant designs can also offer
>> similar interfaces.
>>
>>
>>>
>>> Regards,
>>>
>>> 	Hans
>>>
>>>>
>>>>
>>>> The changes from version 1 are:
>>>> 	- fix compilation;
>>>> 	- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
>>>> 	  with the corresponding documentation;
>>>> 	- remove legacy V4L1 buffer types from videobuf2.h.
>>>>
>>>> With regards to VIDIOC_S_TUNER, what's currently defined there is
>>>> that, in contrary to what a radio device does, this ioctl would
>>>> set the input.
>>>>
>>>> This patch adds the very basic stuff for SDR:
>>>>
>>>> 	- a separate devnode;
>>>> 	- an VIDIOC_QUERYCAP caps for SDR;
>>>> 	- a fourcc group for SDR;
>>>> 	- a few DocBook bits.
>>>>
>>>> What's missing:
>>>> 	- SDR specific controls;
>>>> 	- Sample rate config;
>>>> 	...
>>>>
>>>> As discussing DocBook changes inside the patch is hard, I'm adding here
>>>> the DocBook formatted changes.
>>>>
>>>> The DocBook changes add the following bits:
>>>>
>>>> At Chapter 1. Common API Elements, it adds:
>>>>
>>>> <text>
>>>> Software Digital Radio (SDR) Tuners and Modulators
>>>> ==================================================
>>>>
>>>> Those devices are special types of Radio devices that don't have any
>>>> analog demodulator. Instead, it samples the radio IF or baseband and
>>>> sends the samples for userspace to demodulate.
>>>>
>>>> Tuners
>>>> ======
>>>>
>>>> SDR receivers can have one or more tuners sampling RF signals. Each
>>>> tuner is associated with one or more inputs, depending on the number of
>>>> RF connectors on the tuner. The type field of the respective struct
>>>> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
>>>> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of
>>>> the tuner input.
>>>>
>>>> To query and change tuner properties applications use the VIDIOC_G_TUNER
>>>> and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned
>>>> by VIDIOC_G_TUNER also contains signal status information applicable
>>>> when the tuner of the current SDR input is queried. In order to change
>>>> the SDR input, VIDIOC_S_TUNER with a new SDR index should be called.
>>>> Drivers must support both ioctls and set the V4L2_CAP_SDR and
>>>> V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the
>>>> VIDIOC_QUERYCAP ioctl.
>>>>
>>>> Modulators
>>>> ==========
>>>>
>>>> To be defined.
>>>> </text>
>>>>
>>>> At the end of Chapter 2. Image Formats, it adds:
>>>>
>>>> <text>
>>>> SDR format struture
>>>> ===================
>>>>
>>>> Table 2.4. struct v4l2_sdr_format
>>>> =================================
>>>>
>>>> __u32	sampleformat	The format of the samples used by the SDR device.
>>>> 			This is a little endian four character code.
>>>>
>>>> Table 2.5. SDR formats
>>>> ======================
>>>>
>>>> V4L2_SDR_FMT_I8Q8	Samples are given by a sequence of 8 bits in-phase(I)
>>>> 			and 8 bits quadrature (Q) samples taken from a
>>>> 			signal(t) represented by the following expression:
>>>> 			signal(t) = I * cos(2Ï€ fc t) - Q * sin(2Ï€ fc t)
>>>> </text>
>>>>
>>>> Of course, other formats will be needed at Table 2.5, as SDR could also
>>>> be taken baseband samples, being, for example, a simple sequence of
>>>> equally time-spaced digitalized samples of the signal in time.
>>>> SDR samples could also use other resolutions, use a non-linear
>>>> (A-law, u-law) ADC, or even compress the samples (with ADPCM, for
>>>> example). So, this table will grow as newer devices get added, and an
>>>> userspace library may be required to convert them into some common
>>>> format.
>>>>
>>>> At "Chapter 4. Interfaces", it adds the following text:
>>>>
>>>> <text>
>>>> Software Digital Radio(SDR) Interface
>>>> =====================================
>>>>
>>>> This interface is intended for Software Digital Radio (SDR) receivers
>>>> and transmitters.
>>>>
>>>> Conventionally V4L2 SDR devices are accessed through character device
>>>> special files named /dev/sdr0 to/dev/radio255 and uses a dynamically
>>>> allocated major/minor number.
>>>>
>>>> Querying Capabilities
>>>> =====================
>>>>
>>>> Devices supporting the radio interface set the V4L2_CAP_SDR and
>>>> V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of
>>>> struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other
>>>> combinations of capability flags are reserved for future extensions.
>>>>
>>>> Supplemental Functions
>>>> ======================
>>>>
>>>> SDR receivers should support tuner ioctls.
>>>>
>>>> SDR transmitter ioctl's will be defined in the future.
>>>>
>>>> SDR devices should also support one or more of the following I/O ioctls:
>>>> read or write, memory mapped IO, user memory IO and/or DMA buffers.
>>>>
>>>> SDR devices can also support controls ioctls.
>>>>
>>>> The SDR Input/Output are A/D or D/A samples taken from a modulated
>>>> signal, and can eventually be packed by the hardware. They are generally
>>>> encoded using cartesian in-phase/quadrature (I/Q) samples, to make
>>>> demodulation easier. The format of the samples should be according with
>>>> SDR format.
>>>> </text>
>>>>
>>>> Note: "SDR format" on the last paragraph is an hyperlink to
>>>> Chapter 2. Image Formats.
>>>>
>>>> At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
>>>>
>>>> <text>
>>>> Table A.93. Device Capabilities Flags
>>>> ...
>>>> V4L2_CAP_SDR	0x00100000	The device is a Software Digital Radio.
>>>> 				For more information about SDR programming
>>>> 				see the section called “Software Digital
>>>> 				Radio (SDR) Tuners and Modulators�.
>>>> </text>
>>>>
>>>> Mauro Carvalho Chehab (3):
>>>>     [media] Add SDR at V4L2 API
>>>>     videodev2.h: Remove the unused old V4L1 buffer types
>>>>     [media] V4L2 api: Add a buffer capture type for SDR
>>>>
>>>>    Documentation/DocBook/media/v4l/common.xml         | 35 ++++++++++++++++++
>>>>    Documentation/DocBook/media/v4l/dev-capture.xml    | 26 ++++++++------
>>>>    Documentation/DocBook/media/v4l/io.xml             |  6 ++++
>>>>    Documentation/DocBook/media/v4l/pixfmt.xml         | 41 ++++++++++++++++++++++
>>>>    Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
>>>>    .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
>>>>    drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
>>>>    drivers/media/v4l2-core/v4l2-ioctl.c               | 32 +++++++++++++++++
>>>>    include/media/v4l2-dev.h                           |  3 +-
>>>>    include/media/v4l2-ioctl.h                         |  8 +++++
>>>>    include/uapi/linux/videodev2.h                     | 33 +++++++----------
>>>>    11 files changed, 163 insertions(+), 32 deletions(-)
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Antti Palosaari]

You just jumped over all my previous hard work and introduced 
implementation, as I tried still to study and finalize all requirements....

http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt

I don't like that. I want just study all requirements and implement 
those as a once and correctly. That one does not meet very many of those 
listed requirements.

Antti



On 04/21/2013 02:10 PM, Mauro Carvalho Chehab wrote:
> Em 21-04-2013 07:34, Hans Verkuil escreveu:
>> On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote:
>>> Em 21-04-2013 06:34, Hans Verkuil escreveu:
>>>> Hi Mauro,
>>>>
>>>> On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
>>>>> This is a version 2 of the V4L2 API bits to support Software Digital
>>>>> Radio (SDR).
>>>>
>>>> It looks pretty good to me. Just one question though: what is your
>>>> rationale
>>>> for choosing a new device name (/dev/sdrX) instead of using the
>>>> existing
>>>> /dev/radioX?
>>>>
>>>> I'm not saying I'm opposed to it, in fact I agree with it, but I
>>>> think the
>>>> reasons for it should be stated explicitly.
>>>
>>> Because a SDR radio is different than a normal radio device:
>>>
>>> A normal radio device is actually radio and hardware demod. As the demod
>>> is in hardware, several things that are required for the demodulate the
>>> signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to
>>> the device and aren't part of the API.
>>>
>>> SDR radio, on the other hand, requires that every control needed by the
>>> tuner to be exposed on userspace, as userspace needs to adjust the
>>> software decoder to match them.
>>>
>>> So, they're different.
>>>
>>> Btw, it is also possible that the same device to offer analog TV,
>>> digital TV, hardware-decoded radio and SDR. One example of such devices
>>> are cx88. The existing drivers supports already hardware demodulers,
>>> but the device also allows to export the collected samples to userspace.
>>> It is just a matter of programming the cx88 RISC code to do that.
>>>
>>> Internally, cx2388x has 2 10 bits ADC, one for baseband (composite
>>> inputs)
>>> and another one for IF signal capable of working up to 35.44 MHz
>>> sampling
>>> rate (on "8x FSC PAL" supported mode). It would be easy to export its
>>> output to userspace.
>>>
>>> Btw, while seeking for more data about SDR this weekend, I discovered
>>> one project doing exactly that:
>>>
>>>     http://www.geocities.ws/how_chee/cx23881fc6.htm
>>>
>>> I did a very quick look at its source code. It is limited, as it works
>>> only at a fixed sample rate of 27 MHz provides only 8 bits
>>> samples[1], and
>>> I'm not sure if it allows using both ADCs.
>>>
>>> Yet, It shows that it is possible that a driver/subdrivers to offer
>>> the 4 different types of devices:
>>>     - analog TV;
>>>     - digital TV;
>>>     - radio;
>>>     - SDR.
>>>
>>> So, IMO we should not abuse of /dev/radio for SDR.
>>
>> I agree. I just wanted to have it explicit :-)
>
> Sure. I'll summarize the above at the commit patch on a next version.
>
>> I also think we should provide and maintain a library doing the
>> decoding for
>> SDR that is part of v4l-utils. Otherwise you'll end up with a big
>> userspace
>> mess.
>
> I partially agree. I've seen some SDR usages that are experimental
> app-specific stuff like GSM and ADSB receivers.
>
> You can see a sample of such projects that use one of the existing
> userspace libraries at:
>      http://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps
>
> In principle, I don't think it is worth to invest our time handling
> all sorts of possible decoders at v4l-apps[1].
>
> It makes more sense to offer instead low level library there to allow
> applications to abstract from hardware differences, like doing
> fourcc conversions.
>
> There are at least two ways of outputting data on the known devices:
>      - simple ADC samples in time domain;
>      - IF using in-phase/quadrature (I/Q) samples.
>
> Also, the number of bits can vary from device to device, being 8 bits
> and 10 bits the most common ones. I think I saw some analog TV devices
> using a 12 bits sampler somewhere, but I can't remember if it is
> flexible enough to output sampled data to the DMA engine, or if they're
> just simple I2C devices that output only decoded data via I2S.
>
> Anyway, the low-level library should take care of those differences,
> just like it is done at libv4l for image standards.
>
> With time, the library may also provide a basic set of decoders for
> more common analog radio standards: FM, AM DSB-FC, AM DSB-SC, AM SSB.
>
> It may also provide analog TV decoders and even digital TV ones,
> but writing them may take a lot of time. It could be good projects
> for Google's Summer of Code and similar events.
>
> I would love to have a set of those decodes there, as they can
> offer a nice set of instrumentation tools to test what is being
> received on some place and calibrate device drivers.
>
> I would love even more to have SDR TX devices. With both TX and RX
> working, one could send us a sample of what they're receiving on
> some place, and this signal could be used by the developer to test
> their devices, improving the driver to better receive such signals.
>
> I suspect that low-cost SDR TX devices will come with time.
>
> [1] Ok, if someone wants to add support for those app-specific decoders,
> maintain it there and it doesn't offer any legal issues that would
> restrict v4l-utils distribution, I'm not against to add it there.
>
>>
>> And we want this checked by v4l2-compliance, and qv4l2 should be able
>> to use
>> the library so we have at least one application that can handle it.
>>
>> Regards,
>>
>>     Hans
>>
>>>
>>> Regards,
>>> Mauro
>>>
>>> [1] The trick is to program the cx88 RISC to output data from the
>>> samplers, instead of from the demods. We do that already for the
>>> audio standard detection.
>>>
>>> I've no idea if cx88 has any upper DMA maximum bandwidth. If it has,
>>> that might be the reason to limit to 27MHz, 8 bits, but I suspect
>>> that it was done that way just because it was easier.
>>>
>>> Btw, I'm almost sure that other Conexant designs can also offer
>>> similar interfaces.
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>>     Hans
>>>>
>>>>>
>>>>>
>>>>> The changes from version 1 are:
>>>>>     - fix compilation;
>>>>>     - add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
>>>>>       with the corresponding documentation;
>>>>>     - remove legacy V4L1 buffer types from videobuf2.h.
>>>>>
>>>>> With regards to VIDIOC_S_TUNER, what's currently defined there is
>>>>> that, in contrary to what a radio device does, this ioctl would
>>>>> set the input.
>>>>>
>>>>> This patch adds the very basic stuff for SDR:
>>>>>
>>>>>     - a separate devnode;
>>>>>     - an VIDIOC_QUERYCAP caps for SDR;
>>>>>     - a fourcc group for SDR;
>>>>>     - a few DocBook bits.
>>>>>
>>>>> What's missing:
>>>>>     - SDR specific controls;
>>>>>     - Sample rate config;
>>>>>     ...
>>>>>
>>>>> As discussing DocBook changes inside the patch is hard, I'm adding
>>>>> here
>>>>> the DocBook formatted changes.
>>>>>
>>>>> The DocBook changes add the following bits:
>>>>>
>>>>> At Chapter 1. Common API Elements, it adds:
>>>>>
>>>>> <text>
>>>>> Software Digital Radio (SDR) Tuners and Modulators
>>>>> ==================================================
>>>>>
>>>>> Those devices are special types of Radio devices that don't have any
>>>>> analog demodulator. Instead, it samples the radio IF or baseband and
>>>>> sends the samples for userspace to demodulate.
>>>>>
>>>>> Tuners
>>>>> ======
>>>>>
>>>>> SDR receivers can have one or more tuners sampling RF signals. Each
>>>>> tuner is associated with one or more inputs, depending on the
>>>>> number of
>>>>> RF connectors on the tuner. The type field of the respective struct
>>>>> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
>>>>> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of
>>>>> the tuner input.
>>>>>
>>>>> To query and change tuner properties applications use the
>>>>> VIDIOC_G_TUNER
>>>>> and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned
>>>>> by VIDIOC_G_TUNER also contains signal status information applicable
>>>>> when the tuner of the current SDR input is queried. In order to change
>>>>> the SDR input, VIDIOC_S_TUNER with a new SDR index should be called.
>>>>> Drivers must support both ioctls and set the V4L2_CAP_SDR and
>>>>> V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the
>>>>> VIDIOC_QUERYCAP ioctl.
>>>>>
>>>>> Modulators
>>>>> ==========
>>>>>
>>>>> To be defined.
>>>>> </text>
>>>>>
>>>>> At the end of Chapter 2. Image Formats, it adds:
>>>>>
>>>>> <text>
>>>>> SDR format struture
>>>>> ===================
>>>>>
>>>>> Table 2.4. struct v4l2_sdr_format
>>>>> =================================
>>>>>
>>>>> __u32    sampleformat    The format of the samples used by the SDR
>>>>> device.
>>>>>             This is a little endian four character code.
>>>>>
>>>>> Table 2.5. SDR formats
>>>>> ======================
>>>>>
>>>>> V4L2_SDR_FMT_I8Q8    Samples are given by a sequence of 8 bits
>>>>> in-phase(I)
>>>>>             and 8 bits quadrature (Q) samples taken from a
>>>>>             signal(t) represented by the following expression:
>>>>>             signal(t) = I * cos(2Ï€ fc t) - Q * sin(2Ï€ fc t)
>>>>> </text>
>>>>>
>>>>> Of course, other formats will be needed at Table 2.5, as SDR could
>>>>> also
>>>>> be taken baseband samples, being, for example, a simple sequence of
>>>>> equally time-spaced digitalized samples of the signal in time.
>>>>> SDR samples could also use other resolutions, use a non-linear
>>>>> (A-law, u-law) ADC, or even compress the samples (with ADPCM, for
>>>>> example). So, this table will grow as newer devices get added, and an
>>>>> userspace library may be required to convert them into some common
>>>>> format.
>>>>>
>>>>> At "Chapter 4. Interfaces", it adds the following text:
>>>>>
>>>>> <text>
>>>>> Software Digital Radio(SDR) Interface
>>>>> =====================================
>>>>>
>>>>> This interface is intended for Software Digital Radio (SDR) receivers
>>>>> and transmitters.
>>>>>
>>>>> Conventionally V4L2 SDR devices are accessed through character device
>>>>> special files named /dev/sdr0 to/dev/radio255 and uses a dynamically
>>>>> allocated major/minor number.
>>>>>
>>>>> Querying Capabilities
>>>>> =====================
>>>>>
>>>>> Devices supporting the radio interface set the V4L2_CAP_SDR and
>>>>> V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of
>>>>> struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other
>>>>> combinations of capability flags are reserved for future extensions.
>>>>>
>>>>> Supplemental Functions
>>>>> ======================
>>>>>
>>>>> SDR receivers should support tuner ioctls.
>>>>>
>>>>> SDR transmitter ioctl's will be defined in the future.
>>>>>
>>>>> SDR devices should also support one or more of the following I/O
>>>>> ioctls:
>>>>> read or write, memory mapped IO, user memory IO and/or DMA buffers.
>>>>>
>>>>> SDR devices can also support controls ioctls.
>>>>>
>>>>> The SDR Input/Output are A/D or D/A samples taken from a modulated
>>>>> signal, and can eventually be packed by the hardware. They are
>>>>> generally
>>>>> encoded using cartesian in-phase/quadrature (I/Q) samples, to make
>>>>> demodulation easier. The format of the samples should be according
>>>>> with
>>>>> SDR format.
>>>>> </text>
>>>>>
>>>>> Note: "SDR format" on the last paragraph is an hyperlink to
>>>>> Chapter 2. Image Formats.
>>>>>
>>>>> At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
>>>>>
>>>>> <text>
>>>>> Table A.93. Device Capabilities Flags
>>>>> ...
>>>>> V4L2_CAP_SDR    0x00100000    The device is a Software Digital Radio.
>>>>>                 For more information about SDR programming
>>>>>                 see the section called “Software Digital
>>>>>                 Radio (SDR) Tuners and Modulators�.
>>>>> </text>
>>>>>
>>>>> Mauro Carvalho Chehab (3):
>>>>>     [media] Add SDR at V4L2 API
>>>>>     videodev2.h: Remove the unused old V4L1 buffer types
>>>>>     [media] V4L2 api: Add a buffer capture type for SDR
>>>>>
>>>>>    Documentation/DocBook/media/v4l/common.xml         | 35
>>>>> ++++++++++++++++++
>>>>>    Documentation/DocBook/media/v4l/dev-capture.xml    | 26
>>>>> ++++++++------
>>>>>    Documentation/DocBook/media/v4l/io.xml             |  6 ++++
>>>>>    Documentation/DocBook/media/v4l/pixfmt.xml         | 41
>>>>> ++++++++++++++++++++++
>>>>>    Documentation/DocBook/media/v4l/v4l2.xml           |  1 +
>>>>>    .../DocBook/media/v4l/vidioc-querycap.xml          |  7 ++++
>>>>>    drivers/media/v4l2-core/v4l2-dev.c                 |  3 ++
>>>>>    drivers/media/v4l2-core/v4l2-ioctl.c               | 32
>>>>> +++++++++++++++++
>>>>>    include/media/v4l2-dev.h                           |  3 +-
>>>>>    include/media/v4l2-ioctl.h                         |  8 +++++
>>>>>    include/uapi/linux/videodev2.h                     | 33
>>>>> +++++++----------
>>>>>    11 files changed, 163 insertions(+), 32 deletions(-)
>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-media" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
http://palosaari.fi/

Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API

[Mauro Carvalho Chehab]

Em 21-04-2013 09:03, Antti Palosaari escreveu:
> You just jumped over all my previous hard work and introduced implementation, as I tried still to study and finalize all requirements....

As it is posted on the topics, this is RFC. I'm sure changes will
be needed there before having it on some state that it can be merged.

>
> http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt

Well, we discussed there already:
	http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123

And I proposed several a few implementation details there. I'm just
going deeper and writing RFC patches to start test/implement it.

> I don't like that. I want just study all requirements and implement
> those as a once and correctly.

Ok, there are topics there yet to study, but in order to to that,
a real implementation is needed. Only implementing it is possible
to cover all that it is needed.

> That one does not meet very many of those listed requirements.

True. It doesn't cover anything that IMO it should be covered by V4L2
controls.

My focus right now is to implement support for:
	- set/get frequency;
	- get IF;
	- set/get standard envelope/bandwidth;
	- set/get sample rate (the real code will only show up
	  when start implementing a SDR driver - I'm yet far
	  behind this point);
	- get tuner frequency range.

Adding new controls are the easy task, as it doesn't require
core changes (well, except for a table there with the control
names).

However, adding core support for SDR is harder, as it requires
to work on several layers at the V4L2 core.

I'm working today on more patches for it, at tuner-core.
Lots of changes are required there, in order to allow
supporting the existing tuner.

My current plan is to test SDR with cx88, so, I need tuner-core
to work fine with it. I've coded only ~50% of what's needed,
and that represents:

  15 files changed, 379 insertions(+), 94 deletions(-)

Regards,
Mauro