[PATCH 0/2] Re: [RFC/PATCH] [media] dw2102: use symbolic names for dw2102_table indices

[Jonathan Nieder]

(-cc: Eduard)
Mauro Carvalho Chehab wrote:

 This looks like a good idea to me. From time to time, when conflict rises,
 sometimes those dvb-usb tables with the magic numbers got unnoticed
 conflicts.

 So, I'm picking this one.

Yay. :)

 It should be noticed that this is a common constructor used inside the
 dvb-usb drivers. IMHO, an approach like that should be extended to the
 other drivers as well.

Here's a few.  Many more to go.

Jonathan Nieder (2):
  [media] a800: use symbolic names for a800_table indices
  [media] af9005, af9015: use symbolic names for USB id table indices

 drivers/media/dvb/dvb-usb/a800.c   |   21 ++-
 drivers/media/dvb/dvb-usb/af9005.c |   14 ++-
 drivers/media/dvb/dvb-usb/af9015.c |  316 +++-
 3 files changed, 260 insertions(+), 91 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] [media] a800: use symbolic names for a800_table indices

[Jonathan Nieder]

The USB id table opens with a comment:

/* do not change the order of the ID table */

because the dvb_usb_device_properties::devices field makes use of USB
ids using hardcoded indices, as in a800_table[1].  Inserting new
USB ids before the end of the table can cause these indices to go
stale and the code to misbehave.

In the spirit of dw2102: use symbolic names for dw2102_table
indices, use symbolic names for the indices and C99-style
initializers to ensure they continue to refer to the entries they are
supposed to.  Now you can reorder entries in the id table without
fear.

Encouraged-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 drivers/media/dvb/dvb-usb/a800.c |   21 ++---
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index 2aef3c89e9fa..3f7ab144218b 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -110,11 +110,17 @@ static int a800_probe(struct usb_interface *intf,
   THIS_MODULE, NULL, adapter_nr);
 }
 
-/* do not change the order of the ID table */
+enum a800_table_entry {
+   AVERMEDIA_A800_COLD,
+   AVERMEDIA_A800_WARM
+};
+
 static struct usb_device_id a800_table [] = {
-/* 00 */   { USB_DEVICE(USB_VID_AVERMEDIA, 
USB_PID_AVERMEDIA_DVBT_USB2_COLD) },
-/* 01 */   { USB_DEVICE(USB_VID_AVERMEDIA, 
USB_PID_AVERMEDIA_DVBT_USB2_WARM) },
-   { } /* Terminating entry */
+   [AVERMEDIA_A800_COLD] = {USB_DEVICE(USB_VID_AVERMEDIA,
+   USB_PID_AVERMEDIA_DVBT_USB2_COLD)},
+   [AVERMEDIA_A800_WARM] = {USB_DEVICE(USB_VID_AVERMEDIA,
+   USB_PID_AVERMEDIA_DVBT_USB2_WARM)},
+   { }
 };
 MODULE_DEVICE_TABLE (usb, a800_table);
 
@@ -169,9 +175,10 @@ static struct dvb_usb_device_properties a800_properties = {
.generic_bulk_ctrl_endpoint = 0x01,
.num_device_descs = 1,
.devices = {
-   {   AVerMedia AverTV DVB-T USB 2.0 (A800),
-   { a800_table[0], NULL },
-   { a800_table[1], NULL },
+   {
+   .name = AVerMedia AverTV DVB-T USB 2.0 (A800),
+   .cold_ids = {a800_table[AVERMEDIA_A800_COLD], NULL},
+   .warm_ids = {a800_table[AVERMEDIA_A800_WARM], NULL},
},
}
 };
-- 
1.7.8.3

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

[PATCH 2/2] [media] af9005, af9015: use symbolic names for USB id table indices

[Jonathan Nieder]

The af9005_properties and af9015_properties tables make use of USB ids
from the USB id tables with hardcoded indices, as in
af9015_usb_table[30].  Adding new entries before the end breaks
such references, so everyone has had to carefully tiptoe to only add
entries at the end of the list.

In the spirit of dw2102: use symbolic names for dw2102_table
indices, use C99-style initializers with symbolic names for each
index to avoid this.  In the new regime, properties tables referring
to the USB ids have names like af9015_usb_table[CINERGY_T_STICK_RC]
that do not change meaning when items in the USB id table are
reordered.

Encouraged-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 drivers/media/dvb/dvb-usb/af9005.c |   23 ++-
 drivers/media/dvb/dvb-usb/af9015.c |  316 +++-
 2 files changed, 252 insertions(+), 87 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/af9005.c 
b/drivers/media/dvb/dvb-usb/af9005.c
index bd51a764351b..5d5e32f4e99d 100644
--- a/drivers/media/dvb/dvb-usb/af9005.c
+++ b/drivers/media/dvb/dvb-usb/af9005.c
@@ -977,11 +977,20 @@ static int af9005_usb_probe(struct usb_interface *intf,
   THIS_MODULE, NULL, adapter_nr);
 }
 
+enum af9005_usb_table_entry {
+   AFATECH_AF9005,
+   TERRATEC_AF9005,
+   ANSONIC_AF9005,
+};
+
 static struct usb_device_id af9005_usb_table[] = {
-   {USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9005)},
-   {USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_USB_XE)},
-   {USB_DEVICE(USB_VID_ANSONIC, USB_PID_ANSONIC_DVBT_USB)},
-   {0},
+   [AFATECH_AF9005] = {USB_DEVICE(USB_VID_AFATECH,
+   USB_PID_AFATECH_AF9005)},
+   [TERRATEC_AF9005] = {USB_DEVICE(USB_VID_TERRATEC,
+   USB_PID_TERRATEC_CINERGY_T_USB_XE)},
+   [ANSONIC_AF9005] = {USB_DEVICE(USB_VID_ANSONIC,
+   USB_PID_ANSONIC_DVBT_USB)},
+   { }
 };
 
 MODULE_DEVICE_TABLE(usb, af9005_usb_table);
@@ -1041,15 +1050,15 @@ static struct dvb_usb_device_properties 
af9005_properties = {
.num_device_descs = 3,
.devices = {
{.name = Afatech DVB-T USB1.1 stick,
-.cold_ids = {af9005_usb_table[0], NULL},
+.cold_ids = {af9005_usb_table[AFATECH_AF9005], NULL},
 .warm_ids = {NULL},
 },
{.name = TerraTec Cinergy T USB XE,
-.cold_ids = {af9005_usb_table[1], NULL},
+.cold_ids = {af9005_usb_table[TERRATEC_AF9005], NULL},
 .warm_ids = {NULL},
 },
{.name = Ansonic DVB-T USB1.1 stick,
-.cold_ids = {af9005_usb_table[2], NULL},
+.cold_ids = {af9005_usb_table[ANSONIC_AF9005], NULL},
 .warm_ids = {NULL},
 },
{NULL},
diff --git a/drivers/media/dvb/dvb-usb/af9015.c 
b/drivers/media/dvb/dvb-usb/af9015.c
index 7959053d54ed..e755d7637c22 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1343,49 +1343,112 @@ static int af9015_tuner_attach(struct dvb_usb_adapter 
*adap)
return ret;
 }
 
+enum af9015_usb_table_entry {
+   AFATECH_9015,
+   AFATECH_9016,
+   WINFAST_DTV_GOLD,
+   PINNACLE_PCTV_71E,
+   KWORLD_PLUSTV_399U,
+   TINYTWIN,
+   AZUREWAVE_TU700,
+   TERRATEC_AF9015,
+   KWORLD_PLUSTV_PC160,
+   AVERTV_VOLAR_X,
+   XTENSIONS_380U,
+   MSI_DIGIVOX_DUO,
+   AVERTV_VOLAR_X_REV2,
+   TELESTAR_STARSTICK_2,
+   AVERMEDIA_A309_USB,
+   MSI_DIGIVOX_MINI_III,
+   KWORLD_E396,
+   KWORLD_E39B,
+   KWORLD_E395,
+   TREKSTOR_DVBT,
+   AVERTV_A850,
+   AVERTV_A805,
+   CONCEPTRONIC_CTVDIGRCU,
+   KWORLD_MC810,
+   GENIUS_TVGO_DVB_T03,
+   KWORLD_399U_2,
+   KWORLD_PC160_T,
+   SVEON_STV20,
+   TINYTWIN_2,
+   WINFAST_DTV2000DS,
+   KWORLD_UB383_T,
+   KWORLD_E39A,
+   AVERMEDIA_A815M,
+   CINERGY_T_STICK_RC,
+   CINERGY_T_DUAL_RC,
+   AVERTV_A850T,
+   TINYTWIN_3,
+   SVEON_STV22,
+};
+
 static struct usb_device_id af9015_usb_table[] = {
-/*  0 */{USB_DEVICE(USB_VID_AFATECH,   USB_PID_AFATECH_AF9015_9015)},
-   {USB_DEVICE(USB_VID_AFATECH,   USB_PID_AFATECH_AF9015_9016)},
-   {USB_DEVICE(USB_VID_LEADTEK,   USB_PID_WINFAST_DTV_DONGLE_GOLD)},
-   {USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV71E)},
-   {USB_DEVICE(USB_VID_KWORLD_2,  USB_PID_KWORLD_399U)},
-/*  5 */{USB_DEVICE(USB_VID_VISIONPLUS,
-   USB_PID_TINYTWIN)},
-   {USB_DEVICE(USB_VID_VISIONPLUS,
-   USB_PID_AZUREWAVE_AD_TU700)},
-   {USB_DEVICE(USB_VID_TERRATEC,  USB_PID_TERRATEC_CINERGY_T_USB_XE_REV2)},
-   {USB_DEVICE(USB_VID_KWORLD_2,  

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
 Hi Sakari,
 
 On Friday 06 January 2012 12:27:03 Sakari Ailus wrote:
 Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi

 Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
 IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
 VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).

 VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.

 As those ioctls are experimental, should we deprecate them ?

 I'm also in favour of doing that. But I'll make it a separate patch.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---

  drivers/media/video/v4l2-subdev.c |   26 -
  include/linux/v4l2-subdev.h   |   45
  ++ include/media/v4l2-subdev.h   |
 5 
  3 files changed, 75 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/v4l2-subdev.c
 b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
 --- a/drivers/media/video/v4l2-subdev.c
 +++ b/drivers/media/video/v4l2-subdev.c
 @@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
 struct v4l2_subdev *sd) {

  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
  
/* Allocate try format and crop in the same memory block */

 -  fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
 +  fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop)
 + + sizeof(*fh-try_compose))

  * sd-entity.num_pads, GFP_KERNEL);

 Could you check how the 3 structures are aligned on 64-bit platforms ?
 I'm a bit worried about the compiler expecting a 64-bit alignment for
 one of them, and getting only a 32-bit alignment in the end.

 What about using kcalloc ?

 kcalloc won't make a difference --- see the implementation. Do you think
 this is really an issue in practice?
 
 It won't make a difference for the alignment, it's just that we allocate an 
 array, so kcalloc seemed right.
 
 If we want to ensure alignment I'd just allocate them separately. Or
 create a struct out of them locally, and get the pointers from that
 struct --- then the alignment would be the same as if those were part of
 a single struct. That achieves the desired result and also keeps error
 handling trivial.

 I wouldn't want to start relying on the alignment based on the sizes of
 these structures.
 
 Sounds good to me. Allocating them as part of a bigger structure internally 
 could be more efficient than separate allocations, but I'm fine with both.

On second thought, I think I'll combine them into a new anonymous struct
the field name of which I call pad, unless that requires too intrusive
changes in other drivers. How about that?

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Sakari Ailus]

Sakari Ailus wrote:
...
 On second thought, I think I'll combine them into a new anonymous struct
 the field name of which I call pad, unless that requires too intrusive
 changes in other drivers. How about that?

And the answer to that is no. The smia++ driver does store the format,
crop and compose values in arrays indexed by pad numbers which I think
is a natural thing for the driver to do. In many functiona the driver
uses internally it's trivial to choose the array either from driver's
internal data structure (V4L2_SUBDEV_FORMAT_ACTIVE) or the file handle
(V4L2_SUBDEV_FORMAT_TRY).

Alternatively a named struct could be created for the same, but the
drivers might not need all the fields at all, or choose to store them in
a different form.

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] DVBv5 tools version 0.0.1

[Mauro Carvalho Chehab]

As previously commented at the ML, I'm developing a set of tools
using DVBv5 API. Instead of starting from something existing,
I decided to start from scratch, in order to avoid polluting it
with DVBv3 legacy stuff. Of course, I did some research inside
the existing tools, in order to fill in the blanks, using the
dvb-apps tzap as a reference for the first real application on it,
but removing a large amount of code (file parsers, etc).

They're now on a good shape, at least for my own usage ;)

In order to test, you should use:

git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git

And then run make. the utils are inside utils/dvb.

I plan to do some cleanup at the patches later (basically, changing
the patch descriptions), and add it inside the v4l-utils, in order 
to have the basic tools I use for testing media devices into the
same place.

DVB TOOLS
=

This is a series of tools written to help testing and working with DVB,
using its latest V5 API. The tools can also work with the DVBv3 API.

The current tools are:

dvb-fe-tool - a simple test application, that reads from the frontend.
  it also allows to change the default delivery system.
  In the future, it may be used to change any property
  via command line.

dvb-format-convert - converts from zap and scan initial-tuning-data-file
  into the new format defined to work with DVBv5;

dvbv5-scan - a DVBv5 scan tool;

dvbv5-zap - a DVBv5 zap tool. It allow to tune into a DVB channel, and
to watch to a DVB service (e. g. receiving the video and audio
streams, via another application using the dvr device).

Each application code is very small, as most of the code are on some
generic code that will become a library in the future.

CONTENTS OF THE TREE


parse_string.c/parse_string.h: MPEG-TS string decoder with charset translator

Used to decode NIT/SDT service name, network provider and provider name.
It parses the charsets according with the DVB specs, converting them into
UTF-8 (or other charset), using iconv library.

descriptors.c/descriptors.h:  MPEG-TS descriptors parser

The code there is generig enough to decode the MPEG-TS descriptors,
with the DVB and other Digital TV extensions.

libscan.c/libscan/h: DVBv5 scanning library

This library is used to retrieve DVB information from the MPEG TS
headers, discovering the services associated to each DVB channel or
transponder. The services information is the basic info that most
DVB tools need to tune into a channel.

dvb-file.c/dvb-file.h: DVB file read/write library.

Allows parsing a DVB file (legacy or not) and to write data into a
DVB file (new format only).

dvb-fe.c/dvb-fe.h: DVB frontend library.

Allows talking with a DVB frontend via DVBv5 or DVBv3 API.

dvb-zap-format.c/dvb-legacy-channel-format.c:

Contains the data structures required in order to read from the legacy
formats (zap or scan initial-tuning-data-file).

dvb_frontend.h: DVBv5 frontend API.

This is just a copy of the newest linux/dvb/frontend.h header.
I opted to keep a copy there, in order to allow working with the tools
without needing to copy the latest header into /usr/include.

dvb-v5.h/dvb-v5-std.h:

Ancillary files linked into dvb-fe code, used to parse DVB tables. The
dvbv5.h is generated by a small perl util, from the DVB FE API file.

dvb-demux.c/dvb-demux.h: DVB demux library.

Used by the dvbv5-zap utility.

dvb-fe-tool.c, dvb-format-convert.c, dvbv5-zap.c, dvbv5-scan.c: tools code.

Basically, parses the options from userspace and calls the other code
to do what was requested by the user.

CHANNEL/SERVICE FILE FORMAT
===

Instead of having two different files, one for services, and another for
channels/transponders, I opted to use just one format for both. The
format is:

[channel]
key1=value1
key2=value2
key3=value3
...
keyn=valuen


lines with # are discarted by the parsers. Also, whitespaces/tabs before
the keys and before/after the equal sign.

Be careful: whitespace in the middle of the value are not discarded.

A typical service would be like:

[TV Brasil HD]
VCHANNEL = 2.2
SERVICE_ID = 16160
VIDEO_PID = 770
AUDIO_PID = 514 614
FREQUENCY = 479142857
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 600
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = NONE
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = NONE
ISDBT_LAYER_ENABLED = 7
ISDBT_PARTIAL_RECEPTION = 0
ISDBT_SOUND_BROADCASTING = 0
ISDBT_SB_SUBCHANNEL_ID = 0
ISDBT_SB_SEGMENT_IDX = 0
ISDBT_SB_SEGMENT_COUNT = 0
ISDBT_LAYERA_FEC = AUTO
ISDBT_LAYERA_MODULATION = QAM/AUTO
ISDBT_LAYERA_SEGMENT_COUNT = 0
ISDBT_LAYERA_TIME_INTERLEAVING = 0
ISDBT_LAYERB_FEC = AUTO
ISDBT_LAYERB_MODULATION = QAM/AUTO

[PATCH v3] cx23885: add Terratec Cinergy T PCIe dual

[linxutv]

From: Stefan Ringel linu...@stefanringel.de

Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
 drivers/media/video/cx23885/cx23885-cards.c |   11 ++
 drivers/media/video/cx23885/cx23885-dvb.c   |   53 +++
 drivers/media/video/cx23885/cx23885.h   |1 +
 3 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/cx23885/cx23885-cards.c 
b/drivers/media/video/cx23885/cx23885-cards.c
index dc7864e..3c01be9 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -492,6 +492,11 @@ struct cx23885_board cx23885_boards[] = {
CX25840_VIN7_CH3,
},
},
+   },
+   [CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL] = {
+   .name   = TerraTec Cinergy T PCIe Dual,
+   .portb  = CX23885_MPEG_DVB,
+   .portc  = CX23885_MPEG_DVB,
}
 };
 const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -696,6 +701,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x14f1,
.subdevice = 0x8502,
.card  = CX23885_BOARD_MYGICA_X8507,
+   }, {
+   .subvendor = 0x153b,
+   .subdevice = 0x117e,
+   .card  = CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL,
},
 };
 const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1458,6 +1467,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
break;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
ts1-gen_ctrl_val  = 0xc; /* Serial bus + punctured clock */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
@@ -1530,6 +1540,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_MPX885:
case CX23885_BOARD_MYGICA_X8507:
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_bus[2].i2c_adap,
cx25840, 0x88  1, NULL);
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c 
b/drivers/media/video/cx23885/cx23885-dvb.c
index a390622..af8a225 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -61,6 +61,8 @@
 #include cx23885-f300.h
 #include altera-ci.h
 #include stv0367.h
+#include drxk.h
+#include mt2063.h
 
 static unsigned int debug;
 
@@ -600,6 +602,24 @@ static struct xc5000_config netup_xc5000_config[] = {
},
 };
 
+static struct drxk_config terratec_drxk_config[] = {
+   {
+   .adr = 0x29,
+   .no_i2c_bridge = 1,
+   }, {
+   .adr = 0x2a,
+   .no_i2c_bridge = 1,
+   },
+};
+
+static struct mt2063_config terratec_mt2063_config[] = {
+   {
+   .tuner_address = 0x60,
+   }, {
+   .tuner_address = 0x67,
+   },
+};
+
 int netup_altera_fpga_rw(void *device, int flag, int data, int read)
 {
struct cx23885_dev *dev = (struct cx23885_dev *)device;
@@ -1115,6 +1135,39 @@ static int dvb_register(struct cx23885_tsport *port)
goto frontend_detach;
}
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
+   i2c_bus = dev-i2c_bus[0];
+   i2c_bus2 = dev-i2c_bus[1];
+
+   switch (port-nr) {
+   /* port b */
+   case 1:
+   fe0-dvb.frontend = dvb_attach(drxk_attach,
+   terratec_drxk_config[0],
+   i2c_bus-i2c_adap);
+   if (fe0-dvb.frontend != NULL) {
+   if (!dvb_attach(mt2063_attach,
+   fe0-dvb.frontend,
+   terratec_mt2063_config[0],
+   i2c_bus2-i2c_adap))
+   goto frontend_detach;
+   }
+   break;
+   /* port c */
+   case 2:
+   fe0-dvb.frontend = dvb_attach(drxk_attach,
+   terratec_drxk_config[1],
+   i2c_bus-i2c_adap);
+   if (fe0-dvb.frontend != NULL) {
+   if (!dvb_attach(mt2063_attach,
+   fe0-dvb.frontend,
+   terratec_mt2063_config[1],
+   

Re: [PATCH] v4l2: v4l2-fh: v4l2_fh_is_singular should use list head to test

[Mauro Carvalho Chehab]

On 05-01-2012 05:57, Sakari Ailus wrote:
 On Thu, Jan 05, 2012 at 10:52:02AM +0800, Scott Jiang wrote:
 2012/1/4 Sakari Ailus sakari.ai...@iki.fi:
 Hi Scott,

 Thanks for the patch.

 On Wed, Dec 21, 2011 at 10:30:54AM -0500, Scott Jiang wrote:
 list_is_singular accepts a list head to test whether a list has just one 
 entry.
 fh-list is the entry, fh-vdev-fh_list is the list head.

 Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
 ---
  drivers/media/video/v4l2-fh.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
 index 9e3fc04..8292c4a 100644
 --- a/drivers/media/video/v4l2-fh.c
 +++ b/drivers/media/video/v4l2-fh.c
 @@ -113,7 +113,7 @@ int v4l2_fh_is_singular(struct v4l2_fh *fh)
   if (fh == NULL || fh-vdev == NULL)
   return 0;
   spin_lock_irqsave(fh-vdev-fh_lock, flags);
 - is_singular = list_is_singular(fh-list);
 + is_singular = list_is_singular(fh-vdev-fh_list);
   spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
   return is_singular;
  }

 Is there an issue that this patch resolves, or am I missing something? As
 far as I can see, the list_is_singular() test returns the same result
 whether you are testing a list item which is part of the list, or its head
 in struct video_device.

 Yes, the result is the same. But I don't think it's a good example
 because it may abuse this api.
 Can anybody figure out what this api needs you to pass in?  I confess
 I am not sure about that.
 
 That's true; it's more correct (and intuitive as well) to use the real list
 head for the purpose. But if the implementation really changed I bet a huge
 number of other things would break as well.
 
 Acked-by: Sakari Ailus sakari.ai...@iki.fi
 
 Hans: you wrote the patch adding this code (dfddb244); what do you think?

All those list functions can operate on any node of the list, since the
list is circular. So, there's not a real head for the list.

The function implementation shows that:

static inline void INIT_LIST_HEAD(struct list_head *list)
{
list-next = list;
list-prev = list;
}

...

static inline int list_is_singular(const struct list_head *head)
{
return !list_empty(head)  (head-next == head-prev);
}

So, I prefer to not change it, _unless_ for some reason, you hit
a bug on it (for example, by not having one of the list pointers
filled).

Regards,
Mauro
 
 Regards,
 

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

[PATCH 2/4] cx231xx: fix crash after load/unload/load of module

[Thomas Petazzoni]

The following sequence of commands was triggering a kernel crash in
cdev_get():

 modprobe cx231xx
 rmmod cx231xx
 modprobe cx231xx
 v4l2grab -n 1

The problem was that cx231xx_usb_disconnect() was not doing anything
because the test:

if (!dev-udev)
return;

was reached (i.e, dev-udev was NULL).

This is due to the fact that the 'dev' pointer placed as intfdata into
the usb_interface structure had the wrong value, because
cx231xx_probe() was doing the usb_set_intfdata() on the wrong
usb_interface structure. For some reason, cx231xx_probe() was doing
the following:

static int cx231xx_usb_probe(struct usb_interface *interface,
 const struct usb_device_id *id)
{
struct usb_interface *lif = NULL;
[...]
/* store the current interface */
lif = interface;
[...]
/* store the interface 0 back */
lif = udev-actconfig-interface[0];
[...]
usb_set_intfdata(lif, dev);
[...]
retval = v4l2_device_register(interface-dev, dev-v4l2_dev);
[...]
}

So, the usb_set_intfdata() was done on udev-actconfig-interface[0]
and not on the 'interface' passed as argument to the -probe() and
-disconnect() hooks. Later on, v4l2_device_register() was
initializing the intfdata of the correct usb_interface structure as a
pointer to the v4l2_device structure.

Upon unregistration, the -disconnect() hook was getting the intfdata
of the usb_interface passed as argument... and casted it to a 'struct
cx231xx *' while it was in fact a 'struct v4l2_device *'.

The correct fix seems to just be to set the intfdata on the proper
interface from the beginning. Now, loading/unloading/reloading the
driver allows to use the device properly.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 53dae2a..bfcc8ab 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -1135,7 +1135,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
cx231xx_info(registering interface %d\n, ifnum);
 
/* save our data pointer in this interface device */
-   usb_set_intfdata(lif, dev);
+   usb_set_intfdata(interface, dev);
 
/*
 * AV device initialization - only done at the last interface
@@ -1157,7 +1157,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
v4l2_device_unregister(dev-v4l2_dev);
kfree(dev);
dev = NULL;
-   usb_set_intfdata(lif, NULL);
+   usb_set_intfdata(interface, NULL);
 
return retval;
}
-- 
1.7.4.1

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

[PATCH 3/4] cx231xx: remove useless 'lif' variable in cx231xx_usb_probe()

[Thomas Petazzoni]

Now that we set the intfdata on the right interface, the 'lif'
variable is useless.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index bfcc8ab..2a28882 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -1016,7 +1016,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
int i, isoc_pipe = 0;
char *speed;
char descr[255] = ;
-   struct usb_interface *lif = NULL;
struct usb_interface_assoc_descriptor *assoc_desc;
 
udev = usb_get_dev(interface_to_usbdev(interface));
@@ -1071,9 +1070,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
/* init CIR module TBD */
 
-   /* store the current interface */
-   lif = interface;
-
/*mode_tv: digital=1 or analog=0*/
dev-mode_tv = 0;
 
@@ -1113,9 +1109,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 le16_to_cpu(udev-descriptor.idProduct),
 dev-max_iad_interface_count);
 
-   /* store the interface 0 back */
-   lif = udev-actconfig-interface[0];
-
/* increment interface count */
dev-interface_count++;
 
-- 
1.7.4.1

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

[PATCH 4/4] cx231xx: simplify argument passing to cx231xx_init_dev()

[Thomas Petazzoni]

The 'struct cx231xx *' pointer was passed by reference to the
cx231xx_init_dev() function, for no reason. Instead, just pass it by
value, which is much more logical and simple.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 2a28882..6dbf2da 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -858,10 +858,9 @@ void cx231xx_release_resources(struct cx231xx *dev)
  * cx231xx_init_dev()
  * allocates and inits the device structs, registers i2c bus and v4l device
  */
-static int cx231xx_init_dev(struct cx231xx **devhandle, struct usb_device 
*udev,
+static int cx231xx_init_dev(struct cx231xx *dev, struct usb_device *udev,
int minor)
 {
-   struct cx231xx *dev = *devhandle;
int retval = -ENOMEM;
int errCode;
unsigned int maxh, maxw;
@@ -1144,7 +1143,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
return -EIO;
}
/* allocate device struct */
-   retval = cx231xx_init_dev(dev, udev, nr);
+   retval = cx231xx_init_dev(dev, udev, nr);
if (retval) {
cx231xx_devused = ~(1  dev-devno);
v4l2_device_unregister(dev-v4l2_dev);
-- 
1.7.4.1

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

[PATCH 1/4] cx231xx: use URB_NO_TRANSFER_DMA_MAP on URBs allocated with usb_alloc_urb()

[Thomas Petazzoni]

URBs allocated with usb_alloc_urb() are allocated from DMA-coherent
areas, and therefore it is not necessary to call dma_map_single() on
such buffers. Worst, on ARM, calling dma_map_single() on a
DMA-coherent buffer will trigger a BUG_ON() in
arch/arm/mm/dma-mapping.c.

Therefore, we mark all URBs allocated with usb_alloc_urb() with the
URB_NO_TRANSFER_DMA_MAP transfer_flags, so that the USB core does not
do dma_map_single()/dma_unmap_single() on those buffers.

This is similar to 882787ff8fdeb0be790547ee9b22b281095e95da for the
gspca driver, and has already been discussed on the linux-media list
in the past:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg37086.html.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-audio.c |4 ++--
 drivers/media/video/cx231xx/cx231xx-core.c  |4 ++--
 drivers/media/video/cx231xx/cx231xx-vbi.c   |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c 
b/drivers/media/video/cx231xx/cx231xx-audio.c
index 30d13c1..e0b2d5c 100644
--- a/drivers/media/video/cx231xx/cx231xx-audio.c
+++ b/drivers/media/video/cx231xx/cx231xx-audio.c
@@ -298,7 +298,7 @@ static int cx231xx_init_audio_isoc(struct cx231xx *dev)
urb-context = dev;
urb-pipe = usb_rcvisocpipe(dev-udev,
dev-adev.end_point_addr);
-   urb-transfer_flags = URB_ISO_ASAP;
+   urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
urb-transfer_buffer = dev-adev.transfer_buffer[i];
urb-interval = 1;
urb-complete = cx231xx_audio_isocirq;
@@ -356,7 +356,7 @@ static int cx231xx_init_audio_bulk(struct cx231xx *dev)
urb-context = dev;
urb-pipe = usb_rcvbulkpipe(dev-udev,
dev-adev.end_point_addr);
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
urb-transfer_buffer = dev-adev.transfer_buffer[i];
urb-complete = cx231xx_audio_bulkirq;
urb-transfer_buffer_length = sb_size;
diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index d4457f9..d4527f2 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -1071,7 +1071,7 @@ int cx231xx_init_isoc(struct cx231xx *dev, int 
max_packets,
 sb_size, cx231xx_isoc_irq_callback, dma_q, 1);
 
urb-number_of_packets = max_packets;
-   urb-transfer_flags = URB_ISO_ASAP;
+   urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
 
k = 0;
for (j = 0; j  max_packets; j++) {
@@ -1182,7 +1182,7 @@ int cx231xx_init_bulk(struct cx231xx *dev, int 
max_packets,
return -ENOMEM;
}
dev-video_mode.bulk_ctl.urb[i] = urb;
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
 
dev-video_mode.bulk_ctl.transfer_buffer[i] =
usb_alloc_coherent(dev-udev, sb_size, GFP_KERNEL,
diff --git a/drivers/media/video/cx231xx/cx231xx-vbi.c 
b/drivers/media/video/cx231xx/cx231xx-vbi.c
index 1c7a4da..852878d 100644
--- a/drivers/media/video/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/video/cx231xx/cx231xx-vbi.c
@@ -452,7 +452,7 @@ int cx231xx_init_vbi_isoc(struct cx231xx *dev, int 
max_packets,
return -ENOMEM;
}
dev-vbi_mode.bulk_ctl.urb[i] = urb;
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
 
dev-vbi_mode.bulk_ctl.transfer_buffer[i] =
kzalloc(sb_size, GFP_KERNEL);
-- 
1.7.4.1

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

[PATCH] em28xx: simplify argument passing to em28xx_init_dev()

[Thomas Petazzoni]

The 'struct em28xx *' pointer was passed by reference to the
em28xx_init_dev() function, for no reason. Instead, just pass it by
value, which is much more logical and simple.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/em28xx/em28xx-cards.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index 9b747c2..789054d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2832,11 +2832,10 @@ void em28xx_release_resources(struct em28xx *dev)
  * em28xx_init_dev()
  * allocates and inits the device structs, registers i2c bus and v4l device
  */
-static int em28xx_init_dev(struct em28xx **devhandle, struct usb_device *udev,
+static int em28xx_init_dev(struct em28xx *dev, struct usb_device *udev,
   struct usb_interface *interface,
   int minor)
 {
-   struct em28xx *dev = *devhandle;
int retval;
 
dev-udev = udev;
@@ -3226,7 +3225,7 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
/* allocate device struct */
mutex_init(dev-lock);
mutex_lock(dev-lock);
-   retval = em28xx_init_dev(dev, udev, interface, nr);
+   retval = em28xx_init_dev(dev, udev, interface, nr);
if (retval) {
mutex_unlock(dev-lock);
kfree(dev-alt_max_pkt_size);
-- 
1.7.4.1

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

Re: cx231xx: possible circular locking dependency detected on 3.2

[Thomas Petazzoni]

Le Fri, 6 Jan 2012 22:42:31 +0100,
Thomas Petazzoni thomas.petazz...@free-electrons.com a écrit :

 Hello,
 
 I'm running the Hauppauge USB-Live 2 device on an ARM OMAP3 platform.
 After loading the cx231xx driver and launching v4l2grab, I immediately
 get:
 
 [  407.087158] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  407.145477] 
 [  407.147064] ==
 [  407.153533] [ INFO: possible circular locking dependency detected ]
 [  407.160095] 3.2.0-7-gb928298 #18
 [  407.163848] ---

One code path is (mmap_sem taken before, video_device lock taken
afterwards) :

 - sys_mmap_pgoff()
grabs current-mm-mmap_sem at
http://lxr.free-electrons.com/source/mm/mmap.c#L

- do_mmap_pgoff()

   - mmap_region()

  - v4l2_mmap()
 grabs struct video_device-lock at 
 
http://lxr.free-electrons.com/source/drivers/media/video/v4l2-dev.c#L396

The other code path is (video_device taken first, mmap_sem taken
afterwards) :

 - v4l2_ioctl()
grabs video_device-lock at
http://lxr.free-electrons.com/source/drivers/media/video/v4l2-dev.c#L327

- video_ioctl2()

   - video_usercopy()

  - __video_do_ioctl()

 - videobuf_qbuf()
grabs current-mm-mmap_sem at

http://lxr.free-electrons.com/source/drivers/media/video/videobuf-core.c#L537

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Laurent Pinchart]

Hi Sakari,

On Saturday 07 January 2012 12:09:29 Sakari Ailus wrote:
 Sakari Ailus wrote:
 ...
 
  On second thought, I think I'll combine them into a new anonymous struct
  the field name of which I call pad, unless that requires too intrusive
  changes in other drivers. How about that?
 
 And the answer to that is no. The smia++ driver does store the format,
 crop and compose values in arrays indexed by pad numbers which I think
 is a natural thing for the driver to do. In many functiona the driver
 uses internally it's trivial to choose the array either from driver's
 internal data structure (V4L2_SUBDEV_FORMAT_ACTIVE) or the file handle
 (V4L2_SUBDEV_FORMAT_TRY).
 
 Alternatively a named struct could be created for the same, but the
 drivers might not need all the fields at all, or choose to store them in
 a different form.

Drivers should use the v4l2_subdev_get_try_format(), 
v4l2_subdev_get_try_crop() and v4l2_subdev_get_try_compose() functions to 
access TRY formats and selection rectangles on file handles, so they shouldn't 
care about the allocation details.

-- 
Regards,

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

Re: [PATCH 2/2] [media] af9005, af9015: use symbolic names for USB id table indices

[Luca Olivetti]

Al 07/01/12 09:11, En/na Jonathan Nieder ha escrit:
 The af9005_properties and af9015_properties tables make use of USB ids
 from the USB id tables with hardcoded indices, as in
 af9015_usb_table[30].  Adding new entries before the end breaks
 such references, so everyone has had to carefully tiptoe to only add
 entries at the end of the list.
 
 In the spirit of dw2102: use symbolic names for dw2102_table
 indices, use C99-style initializers with symbolic names for each
 index to avoid this.  In the new regime, properties tables referring
 to the USB ids have names like af9015_usb_table[CINERGY_T_STICK_RC]
 that do not change meaning when items in the USB id table are
 reordered.
 
 Encouraged-by: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com

Seems good to me, didn't know you could do that in C.

Acked-by: Luca Olivetti l...@ventoso.org

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

Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

[Sakari Ailus]

Laurent Pinchart wrote:
 Hi Sakari,
 
 On Saturday 07 January 2012 12:09:29 Sakari Ailus wrote:
 Sakari Ailus wrote:
 ...

 On second thought, I think I'll combine them into a new anonymous struct
 the field name of which I call pad, unless that requires too intrusive
 changes in other drivers. How about that?

 And the answer to that is no. The smia++ driver does store the format,
 crop and compose values in arrays indexed by pad numbers which I think
 is a natural thing for the driver to do. In many functiona the driver
 uses internally it's trivial to choose the array either from driver's
 internal data structure (V4L2_SUBDEV_FORMAT_ACTIVE) or the file handle
 (V4L2_SUBDEV_FORMAT_TRY).

 Alternatively a named struct could be created for the same, but the
 drivers might not need all the fields at all, or choose to store them in
 a different form.
 
 Drivers should use the v4l2_subdev_get_try_format(), 
 v4l2_subdev_get_try_crop() and v4l2_subdev_get_try_compose() functions to 
 access TRY formats and selection rectangles on file handles, so they 
 shouldn't 
 care about the allocation details.

Good point... That requires some changes as well, like introduction of
v4l2_subdev_get_try_compose(). :-)

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] DVBv5 tools version 0.0.1

[Honza Petrouš]

Hi Mauro.

2012/1/7 Mauro Carvalho Chehab mche...@redhat.com:
 As previously commented at the ML, I'm developing a set of tools
 using DVBv5 API. Instead of starting from something existing,
 I decided to start from scratch, in order to avoid polluting it
 with DVBv3 legacy stuff. Of course, I did some research inside
 the existing tools, in order to fill in the blanks, using the
 dvb-apps tzap as a reference for the first real application on it,
 but removing a large amount of code (file parsers, etc).

 They're now on a good shape, at least for my own usage ;)

 In order to test, you should use:

 git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git

 And then run make. the utils are inside utils/dvb.


Am I doing something wrong? After clone I can't find
dvb subdirectory inside utils:

[hop@localhost experimental-v4l-utils (master)]$ ll utils/
celkem 48
drwxr-xr-x 2 hop hop 4096 led  7 18:21 decode_tm6000/
drwxr-xr-x 3 hop hop 4096 led  7 18:21 keytable/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libmedia_dev/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libv4l2util/
-rw-r--r-- 1 hop hop  947 led  7 18:21 Makefile
drwxr-xr-x 2 hop hop 4096 led  7 18:21 qv4l2/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 rds/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-compliance/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-ctl/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-dbg/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-sysfs-path/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 xc3028-firmware/


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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:Sat Jan  7 19:05:21 CET 2012
git hash:2f78604a433a12571ec3e54054fbfacc7525b307
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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

Re: [ANNOUNCE] DVBv5 tools version 0.0.1

[Mauro Carvalho Chehab]

On 07-01-2012 15:29, Honza Petrouš wrote:
 Hi Mauro.
 
 2012/1/7 Mauro Carvalho Chehab mche...@redhat.com:
 As previously commented at the ML, I'm developing a set of tools
 using DVBv5 API. Instead of starting from something existing,
 I decided to start from scratch, in order to avoid polluting it
 with DVBv3 legacy stuff. Of course, I did some research inside
 the existing tools, in order to fill in the blanks, using the
 dvb-apps tzap as a reference for the first real application on it,
 but removing a large amount of code (file parsers, etc).

 They're now on a good shape, at least for my own usage ;)

 In order to test, you should use:

 git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git

 And then run make. the utils are inside utils/dvb.

 
 Am I doing something wrong? After clone I can't find
 dvb subdirectory inside utils:

Huh... sorry, you need to specify the branch as well. The correct
syntax would be:

git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git  dvbv5-0.0.1

it is likely that git clone has already fetched this branch as well,
so, now that you've cloned it, you can do:

git remote update
git checkout origin/dvbv5-0.0.1

In order to build, you need to run make two times (the first one
will run automake tools, and the second one will actually compile
everything).

After running the first make, you can just go to utils/dvb and run
make from there, if you don't want to compile everything.

 
 [hop@localhost experimental-v4l-utils (master)]$ ll utils/
 celkem 48
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 decode_tm6000/
 drwxr-xr-x 3 hop hop 4096 led  7 18:21 keytable/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 libmedia_dev/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 libv4l2util/
 -rw-r--r-- 1 hop hop  947 led  7 18:21 Makefile
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 qv4l2/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 rds/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-compliance/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-ctl/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-dbg/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-sysfs-path/
 drwxr-xr-x 2 hop hop 4096 led  7 18:21 xc3028-firmware/
 
 
 Honza
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH] em28xx: Fix: I2C_CLK write error message checks wrong return code

[Sascha Sommer]

Hello,

it looks like the return value check that is done after setting the I2C 
speed checks the wrong return code.

Attached patch fixes this problem.

Regards

Sascha

Fix: I2C_CLK write error message checks wrong return code

Signed-off-by: Sascha Sommer saschasom...@freenet.de

diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c
index 897a432..349e674 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3015,7 +3015,7 @@ static int em28xx_init_dev(struct em28xx **devhandle, struct usb_device *udev,
 
 	if (!dev-board.is_em2800) {
 		/* Resets I2C speed */
-		em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
+		retval = em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
 		if (retval  0) {
 			em28xx_errdev(%s: em28xx_write_reg failed!
    retval [%d]\n,

[PATCH] em28xx: Do not modify EM28XX_R06_I2C_CLK for em2800

[Sascha Sommer]

Hello,

writing the EM28XX_R06_I2C_CLK register leads to the problem that the 
i2c bus
on the Terratec Cinergy 200 USB is no longer usable when the system is 
rebooted.

The device needs to be unplugged in order to bring it back to life.
Attached patch conditionally disables the write in 
em28xx_pre_card_setup() like

it is already done in em28xx_card_setup().

Regards

Sascha

Do not modify EM28XX_R06_I2C_CLK for em2800
Modifying this register makes the Terratec Cinergy 200 USB unusable
after reboot.

Signed-off-by: Sascha Sommer saschasom...@freenet.de

diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c
index 897a432..0b2e6d5 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2287,7 +2287,8 @@ void em28xx_pre_card_setup(struct em28xx *dev)
 	/* Set the initial XCLK and I2C clock values based on the board
 	   definition */
 	em28xx_write_reg(dev, EM28XX_R0F_XCLK, dev-board.xclk  0x7f);
-	em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
+	if (!dev-board.is_em2800)
+		em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
 	msleep(50);
 
 	/* request some modules */

[PATCH] em28xx: increase maxwidth for em2800

[Sascha Sommer]

Hello,

The MaxPacketSize for em2800 based devices is too small to capture at 
full resolution.

Therefore scale down when the maximum frame size is selected.
The previous workaround that simply reduced the X resolution cannot be used
because it crops a part of the input as
the em2800 can only scale down with a factor of 0.5.

Regards

Sascha

The MaxPacketSize for em2800 based devices is too small to capture at full resolution.
Therefore scale down when the maximum frame size is selected.
The previous workaround that simply reduced the X resolution cannot be used
because it crops a part of the input as
the em2800 can only scale down with a factor of 0.5. 

reverts
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1ca31892e3af05ad3a72769e3c922cca3cde4f9d
and
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fb3de0398ab1bf270bc55f66945f82e61e50f6b6

Signed-off-by: Sascha Sommer saschasom...@freenet.de

diff --git a/drivers/media/video/em28xx/em28xx-video.c b/drivers/media/video/em28xx/em28xx-video.c
index 9b4557a..613300b 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1070,6 +1070,10 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv,
 		/* the em2800 can only scale down to 50% */
 		height = height  (3 * maxh / 4) ? maxh : maxh / 2;
 		width = width  (3 * maxw / 4) ? maxw : maxw / 2;
+/* MaxPacketSize for em2800 is too small to capture at full resolution
+ * use half of maxw as the scaler can only scale to 50% */
+		if (width == maxw  height == maxh)
+			width /= 2;
 	} else {
 		/* width must even because of the YUYV format
 		   height must be even because of interlacing */
@@ -2503,6 +2507,7 @@ int em28xx_register_analog_devices(struct em28xx *dev)
 {
   u8 val;
 	int ret;
+	unsigned int maxw;
 
 	printk(KERN_INFO %s: v4l2 driver version %s\n,
 		dev-name, EM28XX_VERSION);
@@ -2515,8 +2520,15 @@ int em28xx_register_analog_devices(struct em28xx *dev)
 
 	/* Analog specific initialization */
 	dev-format = format[0];
+
+	maxw = norm_maxw(dev);
+/* MaxPacketSize for em2800 is too small to capture at full resolution
+ * use half of maxw as the scaler can only scale to 50% */
+if (dev-board.is_em2800)
+maxw /= 2;
+
 	em28xx_set_video_format(dev, format[0].fourcc,
-norm_maxw(dev), norm_maxh(dev));
+maxw, norm_maxh(dev));
 
 	video_mux(dev, dev-ctl_input);
 
diff --git a/drivers/media/video/em28xx/em28xx.h b/drivers/media/video/em28xx/em28xx.h
index 7c3ebe2..22e252b 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -831,7 +831,7 @@ static inline unsigned int norm_maxw(struct em28xx *dev)
 	if (dev-board.is_webcam)
 		return dev-sensor_xres;
 
-	if (dev-board.max_range_640_480 || dev-board.is_em2800)
+	if (dev-board.max_range_640_480)
 		return 640;
 
 	return 720;

[PATCH] em28xx: Fix tuner_type for Terratec Cinergy 200 USB

[Sascha Sommer]

Hello,

the card definition of the Terratec Cinergy 200 USB uses the wrong
tuner type. Therefore some channels are currently missing.
Attached patch fixes this problem.

Regards

Sascha
Fix tuner type for the Terratec Cinergy 200 USB

Signed-off-by: Sascha Sommer saschasom...@freenet.de

diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c
index 897a432..59694e6 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1179,7 +1179,7 @@ struct em28xx_board em28xx_boards[] = {
 		.name = Terratec Cinergy 200 USB,
 		.is_em2800= 1,
 		.has_ir_i2c   = 1,
-		.tuner_type   = TUNER_LG_PAL_NEW_TAPC,
+		.tuner_type   = TUNER_LG_TALN,
 		.tda9887_conf = TDA9887_PRESENT,
 		.decoder  = EM28XX_SAA711X,
 		.input= { {

Re: [RFC 17/17] rm680: Add camera init

[Sakari Ailus]

Hi Laurent,

Thanks for the review!

Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:28:09 Sakari Ailus wrote:
 This currently introduces an extra file to the arch/arm/mach-omap2
 directory: board-rm680-camera.c. Keeping the device tree in mind, the
 context of the file could be represented as static data with one exception:
 the external clock to the sensor.

 This external clock is provided by the OMAP 3 SoC and required by the
 sensor. The issue is that the clock originates from the ISP and not from
 PRCM block as the other clocks and thus is not supported by the clock
 framework. Otherwise the sensor driver could just clk_get() and
 clk_enable() it, just like the regulators and gpios.
 
 This will hopefully be fixable with the new generic clock struct. Have you 
 had 
 a look at it lately BTW ?

Not since the ELc-E. It'd be nice to get that so we can get rid of the
final issue between OMAP 3 ISP and the device tree --- well, there may
be others but I can't say to know about them. :-)

 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 ---
  arch/arm/mach-omap2/Makefile |3 +-
  arch/arm/mach-omap2/board-rm680-camera.c |  408
 ++ arch/arm/mach-omap2/board-rm680.c| 
  42 +++
  3 files changed, 452 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/board-rm680-camera.c

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 69ab1c0..1444bc5 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -201,7 +201,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA) +=
 board-omap3pandora.o obj-$(CONFIG_MACH_OMAP_3430SDP) += 
 board-3430sdp.o
  obj-$(CONFIG_MACH_NOKIA_N8X0)   += board-n8x0.o
  obj-$(CONFIG_MACH_NOKIA_RM680)  += board-rm680.o \
 -   sdram-nokia.o
 +   sdram-nokia.o \
 +   board-rm680-camera.o
  obj-$(CONFIG_MACH_NOKIA_RX51)   += board-rx51.o \
 sdram-nokia.o \
 board-rx51-peripherals.o \
 diff --git a/arch/arm/mach-omap2/board-rm680-camera.c
 b/arch/arm/mach-omap2/board-rm680-camera.c new file mode 100644
 index 000..4cc1ced
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-rm680-camera.c
 @@ -0,0 +1,408 @@
 +/**
 + * arch/arm/mach-omap2/board-rm680-camera.c
 + *
 + * Copyright (C) 2010--2011 Nokia Corporation
 
 2012 ? :-)

Good point. I'll make the change for the rest of the files as well.

 + * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 + *
 + * Based on board-rx71-camera.c by Vimarsh Zutshi
 
 This one isn't upstream, I'm not sure if it's worth mentioning it.

It's still of historical importance; that is still publicly available if
not in mainline. If you really think I should remove it I will.

 + * Based on board-rx51-camera.c by Sakari Ailus
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +#include linux/delay.h
 +#include linux/mm.h
 +#include linux/platform_device.h
 +#include linux/videodev2.h
 +
 +#include linux/gpio.h
 +#include plat/omap-pm.h
 +
 +#include ../../../drivers/media/video/omap3isp/isp.h
 
 What do we still miss in media/omap3isp.h ?

I think it's mostly the xclk stuff. Everything else is where it should be.

 +#include media/omap3isp.h
 +#include media/smiapp.h
 +#include asm/mach-types.h
 +
 +#include ../../../drivers/media/video/smiapp.h
 
 Time to create media/smiapp.h ?

Now that you ask; the file is there and it contains all the necessary
definitions. I had forgotten to remove the line. ;-)

 +
 +#include devices.h
 +
 +#define SEC_CAMERA_RESET_GPIO   97
 +
 +#define RM680_PRI_SENSOR1
 +#define RM680_PRI_LENS  2
 +#define RM680_SEC_SENSOR3
 +#define MAIN_CAMERA_XCLKISP_XCLK_A
 +#define SEC_CAMERA_XCLK ISP_XCLK_B
 +
 +/*
 + *
 + * HW initialization
 + *
 + *
 + */
 +static int __init rm680_sec_camera_init(void)
 +{
 +if (gpio_request(SEC_CAMERA_RESET_GPIO, sec_camera reset) != 0) {
 +printk(KERN_INFO %s: unable to acquire secondary 
 +   camera reset gpio\n, __func__);
 +return -ENODEV;
 +}
 +
 +/* XSHUTDOWN off, reset  */
 +

Re: [RFC 13/17] omap3isp: Configure CSI-2 phy based on platform data

[Sakari Ailus]

Hi Laurent,

Thanks for the review!!!

Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:28:05 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi

 Configure CSI-2 phy based on platform data in the ISP driver rather than in
 platform code.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/isp.c   |   38 --
  drivers/media/video/omap3isp/isp.h   |3 -
  drivers/media/video/omap3isp/ispcsiphy.c |   83 +++
  drivers/media/video/omap3isp/ispcsiphy.h |4 ++
  4 files changed, 111 insertions(+), 17 deletions(-)

 diff --git a/drivers/media/video/omap3isp/isp.c
 b/drivers/media/video/omap3isp/isp.c index b818cac..6020fd7 100644
 --- a/drivers/media/video/omap3isp/isp.c
 +++ b/drivers/media/video/omap3isp/isp.c
 @@ -737,7 +737,7 @@ static int isp_pipeline_enable(struct isp_pipeline
 *pipe, struct isp_device *isp = pipe-output-isp;
  struct media_entity *entity;
  struct media_pad *pad;
 -struct v4l2_subdev *subdev;
 +struct v4l2_subdev *subdev = NULL, *prev_subdev;
  unsigned long flags;
  int ret;

 @@ -759,11 +759,41 @@ static int isp_pipeline_enable(struct isp_pipeline
 *pipe, break;

  entity = pad-entity;
 +prev_subdev = subdev;
  subdev = media_entity_to_v4l2_subdev(entity);

 -ret = v4l2_subdev_call(subdev, video, s_stream, mode);
 -if (ret  0  ret != -ENOIOCTLCMD)
 -return ret;
 +/* Configure CSI-2 receiver based on sensor format. */
 +if (prev_subdev == isp-isp_csi2a.subdev
 +|| prev_subdev == isp-isp_csi2c.subdev) {
 +struct v4l2_subdev_format fmt;
 +
 +fmt.pad = pad-index;
 +fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
 +ret = v4l2_subdev_call(subdev, pad, get_fmt,
 +   NULL, fmt);
 +if (ret  0)
 +return -EPIPE;
 +
 +ret = omap3isp_csiphy_config(
 +isp, prev_subdev, subdev,
 +fmt.format);
 +if (ret  0)
 +return -EPIPE;
 +
 +/* Start CSI-2 after configuration. */
 +ret = v4l2_subdev_call(prev_subdev, video,
 +   s_stream, mode);
 +if (ret  0  ret != -ENOIOCTLCMD)
 +return ret;
 +}
 +
 +/* Start any other subdev except the CSI-2 receivers. */
 +if (subdev != isp-isp_csi2a.subdev
 + subdev != isp-isp_csi2c.subdev) {
 +ret = v4l2_subdev_call(subdev, video, s_stream, mode);
 +if (ret  0  ret != -ENOIOCTLCMD)
 +return ret;
 +}
 
 What about moving this to the CSI2 s_stream subdev operation ?

Done.


  if (subdev == isp-isp_ccdc.subdev) {
  v4l2_subdev_call(isp-isp_aewb.subdev, video,
 diff --git a/drivers/media/video/omap3isp/isp.h
 b/drivers/media/video/omap3isp/isp.h index 705946e..c5935ae 100644
 --- a/drivers/media/video/omap3isp/isp.h
 +++ b/drivers/media/video/omap3isp/isp.h
 @@ -126,9 +126,6 @@ struct isp_reg {

  struct isp_platform_callback {
  u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
 -int (*csiphy_config)(struct isp_csiphy *phy,
 - struct isp_csiphy_dphy_cfg *dphy,
 - struct isp_csiphy_lanes_cfg *lanes);
  void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
  };

 diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
 b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..f027ece 100644
 --- a/drivers/media/video/omap3isp/ispcsiphy.c
 +++ b/drivers/media/video/omap3isp/ispcsiphy.c
 @@ -28,6 +28,8 @@
  #include linux/device.h
  #include linux/regulator/consumer.h

 +#include ../../../../arch/arm/mach-omap2/control.h
 +
 
 #include mach/control.h
 
 (untested) ?

I'm afraid it won't work. The above directory isn't in any include path
and likely shouldn't be. That file is included locally elsewhere, I believe.

I wonder what would be the right way to access that register definition
I need from the file:

OMAP343X_CTRL_BASE
OMAP3630_CONTROL_CAMERA_PHY_CTRL

  #include isp.h
  #include ispreg.h
  #include ispcsiphy.h
 @@ -138,15 +140,78 @@ static void csiphy_dphy_config(struct isp_csiphy
 *phy) isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
  }

 -static int csiphy_config(struct isp_csiphy *phy,
 - struct isp_csiphy_dphy_cfg *dphy,
 - struct isp_csiphy_lanes_cfg *lanes)
 +/*
 + * TCLK values are OK at their reset values
 + */
 +#define TCLK_TERM   0
 +#define TCLK_MISS   1
 +#define TCLK_SETTLE 14
 +
 +int 

Re: [RFC 17/17] rm680: Add camera init

[Sakari Ailus]

Hi Sylwester,

Thanks for the review!

Sylwester Nawrocki wrote:
 On 12/20/2011 09:28 PM, Sakari Ailus wrote:
 +
 +static int rm680_sec_camera_set_xshutdown(struct v4l2_subdev *subdev,
 u8 set)
 
 It may be more efficient to just use u32.

The function got removed already. ;-)

 +{
 +gpio_set_value(SEC_CAMERA_RESET_GPIO, !!set);
 +return 0;
 +}
 +
 ...
 +void __init rm680_camera_init(void)
 +{
 +struct isp_platform_data *pdata;
 +int rval;
 +
 +rval = rm680_camera_hw_init();
 +if (rval) {
 +printk(KERN_WARNING %s: unable to initialise camera\n,
 
 pr_warn is preferred for new code.

Fixed.

 +   __func__);
 +return;
 +}
 +
 +if (board_is_rm680())
 +pdata =rm680_isp_platform_data;
 +else
 +pdata =rm696_isp_platform_data;
 +
 +if (omap3_init_camera(pdata)  0)
 +printk(KERN_WARNING
 
 pr_warn

Ditto.

 +   %s: unable to register camera platform device\n,
 +   __func__);
 +}
 ...
 +static struct regulator_consumer_supply rm680_vaux2_consumers[] = {
 +REGULATOR_SUPPLY(VDD_CSIPHY1, omap3isp),/* OMAP ISP */
 +REGULATOR_SUPPLY(VDD_CSIPHY2, omap3isp),/* OMAP ISP */
 +{
 +.supply= vaux2,
 +},
 
 Could also be
 REGULATOR_SUPPLY(vaux2, NULL),

Fixed.

 +};
 +REGULATOR_INIT_DATA_FIXED(rm680_vaux2, 180);
 +
 +static struct regulator_consumer_supply rm680_vaux3_consumers[] = {
 +REGULATOR_SUPPLY(VANA, 2-0037),/* Main Camera Sensor */
 +REGULATOR_SUPPLY(VANA, 2-000e),/* Main Camera Lens */
 +REGULATOR_SUPPLY(VANA, 2-0010),/* Front Camera */
 +{
 +.supply= vaux3,
 +},
 
 and REGULATOR_SUPPLY(vaux3, NULL),

Ditto.

 +};
 
 -- 
 Regards,
 Sylwester
 


-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 16/17] smiapp: Add driver.

[Sakari Ailus]

Hi Sylwester,

Thanks for the review!!!

Sylwester Nawrocki wrote:
 Hi Sakari,
 
 I have a just a few comments below. It was rather brief a review, given the
 size of the patch.. :-)

Good points. I'll make the changes, as well as those Laurent pointed
out, and send a new version of the driver. I expect I'll be able to do
that early next week.

 On 12/20/2011 09:28 PM, Sakari Ailus wrote:
 Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as
 three subdevs, pixel array, binner and scaler --- in case the device has a
 scaler.

 Currently it relies on the board code for external clock handling. There is
 no fast way out of this dependency before the ISP drivers (omap3isp) among
 others will be able to export that clock through the clock framework
 instead.

 Signed-off-by: Sakari Ailussakari.ai...@maxwell.research.nokia.com
 ---
   drivers/media/video/Kconfig   |   13 +
   drivers/media/video/Makefile  |3 +
   drivers/media/video/smiapp-core.c | 2595 
 +
   drivers/media/video/smiapp-debug.h|   32 +
   drivers/media/video/smiapp-limits.c   |  132 ++
   drivers/media/video/smiapp-limits.h   |  128 ++
   drivers/media/video/smiapp-pll.c  |  664 +
   drivers/media/video/smiapp-quirk.c|  264 
   drivers/media/video/smiapp-quirk.h|   72 +
   drivers/media/video/smiapp-reg-defs.h |  733 ++
   drivers/media/video/smiapp-reg.h  |  119 ++
   drivers/media/video/smiapp-regs.c |  222 +++
   drivers/media/video/smiapp.h  |  250 
   include/media/smiapp-regs.h   |   51 +
   include/media/smiapp.h|   82 +
   15 files changed, 5360 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/video/smiapp-core.c
   create mode 100644 drivers/media/video/smiapp-debug.h
   create mode 100644 drivers/media/video/smiapp-limits.c
   create mode 100644 drivers/media/video/smiapp-limits.h
   create mode 100644 drivers/media/video/smiapp-pll.c
   create mode 100644 drivers/media/video/smiapp-quirk.c
   create mode 100644 drivers/media/video/smiapp-quirk.h
   create mode 100644 drivers/media/video/smiapp-reg-defs.h
   create mode 100644 drivers/media/video/smiapp-reg.h
   create mode 100644 drivers/media/video/smiapp-regs.c
   create mode 100644 drivers/media/video/smiapp.h
 
 How about creating new directory, e.g. drivers/media/video/smiapp/ ? 

Good question. When I started working on this, I just had a few files
which didn't justify creating a new directory. I think you're right; now
it's time for that.

   create mode 100644 include/media/smiapp-regs.h
   create mode 100644 include/media/smiapp.h

 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index 4e8a0c4..0aa8f13 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -524,6 +524,19 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.

 +config VIDEO_SMIAPP
 +tristate SMIA++/SMIA sensor support
 +depends on I2C  VIDEO_V4L2
 
 There is no dependency on VIDEO_V4L2_SUBDEV_API ?

Yes, there is.

 +---help---
 +  This is a generic driver for SMIA++/SMIA camera modules.
 +
 +config VIDEO_SMIAPP_DEBUG
 +bool Enable debugging for the generic SMIA++/SMIA driver
 +depends on VIDEO_SMIAPP
 +---help---
 +  Enable debugging output in the generic SMIA++/SMIA driver. If you
 +  are developing the driver you might want to enable this.
 +
   comment Flash devices

   config VIDEO_ADP1653
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index ddeaa6c..82a0cea 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -73,6 +73,9 @@ obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
   obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
   obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
   obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
 +smiapp-objs += smiapp-core.o smiapp-regs.o smiapp-pll.o \
 +   smiapp-quirk.o smiapp-limits.o
 +obj-$(CONFIG_VIDEO_SMIAPP)  += smiapp.o
   obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o

   obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
 diff --git a/drivers/media/video/smiapp-core.c 
 b/drivers/media/video/smiapp-core.c
 new file mode 100644
 index 000..1d15c1d
 --- /dev/null
 +++ b/drivers/media/video/smiapp-core.c
 @@ -0,0 +1,2595 @@
 +/*
 + * drivers/media/video/smiapp-core.c
 + *
 + * Generic driver for SMIA/SMIA++ compliant camera modules
 + *
 + * Copyright (C) 2010--2011 Nokia Corporation
 + * Contact: Sakari Ailussakari.ai...@maxwell.research.nokia.com
 + *
 + * Based on smiapp driver by Vimarsh Zutshi
 + * Based on jt8ev1.c by Vimarsh Zutshi
 + * Based on smia-sensor.c by Tuukka Toivonentuukka...@gmail.com
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of 

Re: [RFC 14/17] omap3isp: Use pixelrate from sensor media bus frameformat

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:28:06 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi

 Configure the ISP based on the pixelrate in media bus frame format.
 Previously the same was configured from the board code.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/isp.c |   24 +---
  drivers/media/video/omap3isp/isp.h |1 -
  2 files changed, 21 insertions(+), 4 deletions(-)

 diff --git a/drivers/media/video/omap3isp/isp.c
 b/drivers/media/video/omap3isp/isp.c index 6020fd7..92f9716 100644
 --- a/drivers/media/video/omap3isp/isp.c
 +++ b/drivers/media/video/omap3isp/isp.c
 @@ -749,10 +749,14 @@ static int isp_pipeline_enable(struct isp_pipeline
 *pipe,

  entity = pipe-output-video.entity;
  while (1) {
 -pad = entity-pads[0];
 -if (!(pad-flags  MEDIA_PAD_FL_SINK))
 +/*
 + * Is this an external subdev connected to us? If so,
 + * we're done.
 + */
 +if (subdev  subdev-host_priv)
  break;
 
 This doesn't seem to be related to the patch title. Should it be moved to a 
 separate patch ? You could also move the check to the bottom of the while 
 loop, it would allow you to remove the first part of the condition as subdev 
 will always be non-NULL then (or even possible as the while() condition).

The change got removed based on your other suggestions. ;-) The CSI-2
configuration moved to csi2_set_stream, so a lot of cruft got removed
from here.

 +pad = entity-pads[0];
  pad = media_entity_remote_source(pad);
  if (pad == NULL ||
  media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
 @@ -762,6 +766,21 @@ static int isp_pipeline_enable(struct isp_pipeline
 *pipe, prev_subdev = subdev;
  subdev = media_entity_to_v4l2_subdev(entity);

 +/* Configure CCDC pixel clock */
 +if (subdev-host_priv) {
 +struct v4l2_subdev_format fmt;
 +
 +fmt.pad = pad-index;
 +fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
 +ret = v4l2_subdev_call(subdev, pad, get_fmt,
 +   NULL, fmt);
 +if (ret  0)
 +return -EINVAL;
 +
 +isp_set_pixel_clock(isp,
 +fmt.format.pixelrate * 1000);
 +}
 +
  /* Configure CSI-2 receiver based on sensor format. */
  if (prev_subdev == isp-isp_csi2a.subdev

  || prev_subdev == isp-isp_csi2c.subdev) {

 @@ -2102,7 +2121,6 @@ static int isp_probe(struct platform_device *pdev)

  isp-autoidle = autoidle;
  isp-platform_cb.set_xclk = isp_set_xclk;
 -isp-platform_cb.set_pixel_clock = isp_set_pixel_clock;

  mutex_init(isp-isp_mutex);
  spin_lock_init(isp-stat_lock);
 diff --git a/drivers/media/video/omap3isp/isp.h
 b/drivers/media/video/omap3isp/isp.h index c5935ae..7d73a39 100644
 --- a/drivers/media/video/omap3isp/isp.h
 +++ b/drivers/media/video/omap3isp/isp.h
 @@ -126,7 +126,6 @@ struct isp_reg {

  struct isp_platform_callback {
  u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
 -void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
  };

  /*
 


-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 09/17] v4l: Add pad op for pipeline validation

[Sakari Ailus]

Hi Laurent,

Thanks for the review!!

Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:28:01 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi

 smiapp_pad_ops.validate_pipeline is intended to validate the full pipeline
 which is implemented by the driver to which the subdev implementing this op
 belongs to.
 
 Should this be documented in Documentation/video4linux/v4l2-framework.txt ?
 
 The validate_pipeline op must also call validate_pipeline on any external
 entity which is linked to its sink pads.
 
 I'm uncertain about this. Subdev drivers would then have to implement the 
 pipeline walk logic, resulting in duplicate code. Our current situation isn't 
 optimal either: walking the pipeline should be implemented in the media code. 
 Would it suit your needs if the validate_pipeline operation was replaced by a 
 validate_link operation, with a media_pipeline_validate() function in the 
 media core to walk the pipeline and call validate_link in each pad (or maybe 
 each sink pad) ?

Albeit I don't see the pipeline checking a big problem in the subdev
drivers, that does seem like a viable alternative --- it's definitely
more generic. Any benefit of that is directly bound to the existence of
generic pipeline validation function, which definitely shouldn't be too
difficult to write.

It is also true that in practice, I assume, considering the pipeline
validation inside subdev drivers, the SMIA++ driver is almost as complex
any sensor driver will get in the near future. But once a practice has
been established it's difficult to change that.

I'm for validate_link() op.

I assume that in the implementation the Media controller framework would
walk the pipeline and call entity specific link_validate() ops. We
already have link_setup() op there. Those would, in turn, check that the
link requirements are fulfilled. How does that sound like to you?

Regards,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 12/17] omap3isp: Add lane configuration to platform data

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
 On Tuesday 20 December 2011 21:28:04 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi

 Add lane configuration (order of clock and data lane) to platform data on
 both CCP2 and CSI-2.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/omap3isp/ispcsiphy.h |   15 ++-
  include/media/omap3isp.h |   15 +++
  2 files changed, 17 insertions(+), 13 deletions(-)

 diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
 b/drivers/media/video/omap3isp/ispcsiphy.h index 9596dc6..e93a661 100644
 --- a/drivers/media/video/omap3isp/ispcsiphy.h
 +++ b/drivers/media/video/omap3isp/ispcsiphy.h
 @@ -27,22 +27,11 @@
  #ifndef OMAP3_ISP_CSI_PHY_H
  #define OMAP3_ISP_CSI_PHY_H

 +#include media/omap3isp.h
 +
  struct isp_csi2_device;
  struct regulator;

 -struct csiphy_lane {
 -u8 pos;
 -u8 pol;
 -};
 -
 -#define ISP_CSIPHY2_NUM_DATA_LANES  2
 -#define ISP_CSIPHY1_NUM_DATA_LANES  1
 -
 -struct isp_csiphy_lanes_cfg {
 -struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
 -struct csiphy_lane clk;
 -};
 -
  struct isp_csiphy_dphy_cfg {
  u8 ths_term;
  u8 ths_settle;
 diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
 index e917b1d..8fe0bdf 100644
 --- a/include/media/omap3isp.h
 +++ b/include/media/omap3isp.h
 @@ -86,6 +86,19 @@ enum {
  ISP_CCP2_MODE_CCP2 = 1,
  };

 +struct csiphy_lane {
 +u8 pos;
 +u8 pol;
 +};
 +
 +#define ISP_CSIPHY2_NUM_DATA_LANES  2
 +#define ISP_CSIPHY1_NUM_DATA_LANES  1
 +
 +struct isp_csiphy_lanes_cfg {
 +struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
 +struct csiphy_lane clk;
 +};
 
 Could you please document the two structures using kerneldoc ?

Done.

 +
  /**
   * struct isp_ccp2_platform_data - CCP2 interface platform data
   * @strobe_clk_pol: Strobe/clock polarity
 @@ -105,6 +118,7 @@ struct isp_ccp2_platform_data {
  unsigned int ccp2_mode:1;
  unsigned int phy_layer:1;
  unsigned int vpclk_div:2;
 +struct isp_csiphy_lanes_cfg *lanecfg;
 
 Lane configuration is mandatory, what about embedding struct 
 isp_csiphy_lanes_cfg inside struct isp_ccp2_platform instead of having a 
 pointer ?

Done.

  };

  /**
 @@ -115,6 +129,7 @@ struct isp_ccp2_platform_data {
  struct isp_csi2_platform_data {
  unsigned crc:1;
  unsigned vpclk_div:2;
 +struct isp_csiphy_lanes_cfg *lanecfg;
 
 Same here.

Ditto.

  };

  struct isp_subdev_i2c_board_info {
 


-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 13/17] omap3isp: Configure CSI-2 phy based on platform data

[Laurent Pinchart]

Hi Sakari,

On Saturday 07 January 2012 23:51:24 Sakari Ailus wrote:
 Laurent Pinchart wrote:
  On Tuesday 20 December 2011 21:28:05 Sakari Ailus wrote:
  From: Sakari Ailus sakari.ai...@iki.fi
  
  Configure CSI-2 phy based on platform data in the ISP driver rather than
  in platform code.
  
  Signed-off-by: Sakari Ailus sakari.ai...@iki.fi

[snip]

  diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
  b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..f027ece 100644
  --- a/drivers/media/video/omap3isp/ispcsiphy.c
  +++ b/drivers/media/video/omap3isp/ispcsiphy.c
  @@ -28,6 +28,8 @@
  
   #include linux/device.h
   #include linux/regulator/consumer.h
  
  +#include ../../../../arch/arm/mach-omap2/control.h
  +
  
  #include mach/control.h
  
  (untested) ?
 
 I'm afraid it won't work. The above directory isn't in any include path
 and likely shouldn't be. That file is included locally elsewhere, I
 believe.

You're right, I spoke too fast.

 I wonder what would be the right way to access that register definition
 I need from the file:
 
   OMAP343X_CTRL_BASE
   OMAP3630_CONTROL_CAMERA_PHY_CTRL

Maybe the file (or part of it) should be moved to an include directory ?

   #include isp.h
   #include ispreg.h
   #include ispcsiphy.h
  
  @@ -138,15 +140,78 @@ static void csiphy_dphy_config(struct isp_csiphy
  *phy) isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
  
   }
  
  -static int csiphy_config(struct isp_csiphy *phy,
  -   struct isp_csiphy_dphy_cfg *dphy,
  -   struct isp_csiphy_lanes_cfg *lanes)
  +/*
  + * TCLK values are OK at their reset values
  + */
  +#define TCLK_TERM 0
  +#define TCLK_MISS 1
  +#define TCLK_SETTLE   14
  +
  +int omap3isp_csiphy_config(struct isp_device *isp,
  + struct v4l2_subdev *csi2_subdev,
  + struct v4l2_subdev *sensor,
  + struct v4l2_mbus_framefmt *sensor_fmt)
  
   {
  
  +  struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
  +  struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
  +  struct isp_csiphy_dphy_cfg csi2phy;
  +  int csi2_ddrclk_khz;
  +  struct isp_csiphy_lanes_cfg *lanes;
  
 unsigned int used_lanes = 0;
 unsigned int i;
  
  +  u32 cam_phy_ctrl;
  +
  +  if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
  +  || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
  +  lanes = subdevs-bus.ccp2.lanecfg;
  +  else
  +  lanes = subdevs-bus.csi2.lanecfg;
  
  Shouldn't lane configuration be retrieved from the sensor instead ?
  Sensors could use different lane configuration depending on the mode.
  This could also be implemented later when needed, but I don't think it
  would be too difficult to get it right now.
 
 I think we'd first need to standardise the CSI-2 bus configuration. I
 don't see a practical need to make the lane configuration dynamic. You
 could just use a lower frequency to achieve the same if you really need to.
 
 Ideally it might be nice to do but there's really nothing I know that
 required or even benefited from it --- at least for now.

Does this mean that lane configuration needs to be duplicated in board code, 
on for the SMIA++ platform data and one of the OMAP3 ISP platform data ?

-- 
Regards,

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

Re: [ANNOUNCE] DVBv5 tools version 0.0.1

[Mauro Carvalho Chehab]

On 07-01-2012 10:19, Mauro Carvalho Chehab wrote:
 As previously commented at the ML, I'm developing a set of tools
 using DVBv5 API. Instead of starting from something existing,
 I decided to start from scratch, in order to avoid polluting it
 with DVBv3 legacy stuff. Of course, I did some research inside
 the existing tools, in order to fill in the blanks, using the
 dvb-apps tzap as a reference for the first real application on it,
 but removing a large amount of code (file parsers, etc).
 
 They're now on a good shape, at least for my own usage ;)
 
 In order to test, you should use:
 
 git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git
 
 And then run make. the utils are inside utils/dvb.
 
 I plan to do some cleanup at the patches later (basically, changing
 the patch descriptions), and add it inside the v4l-utils, in order 
 to have the basic tools I use for testing media devices into the
 same place.
 
 DVB TOOLS
 =
 
 This is a series of tools written to help testing and working with DVB,
 using its latest V5 API. The tools can also work with the DVBv3 API.
 
 The current tools are:
 
 dvb-fe-tool - a simple test application, that reads from the frontend.
 it also allows to change the default delivery system.
 In the future, it may be used to change any property
 via command line.
 
 dvb-format-convert - converts from zap and scan initial-tuning-data-file
 into the new format defined to work with DVBv5;
 
 dvbv5-scan - a DVBv5 scan tool;
 
 dvbv5-zap - a DVBv5 zap tool. It allow to tune into a DVB channel, and
   to watch to a DVB service (e. g. receiving the video and audio
   streams, via another application using the dvr device).
 
 Each application code is very small, as most of the code are on some
 generic code that will become a library in the future.
 
 CONTENTS OF THE TREE
 
 
 parse_string.c/parse_string.h: MPEG-TS string decoder with charset translator
 
 Used to decode NIT/SDT service name, network provider and provider name.
 It parses the charsets according with the DVB specs, converting them into
 UTF-8 (or other charset), using iconv library.
 
 descriptors.c/descriptors.h:  MPEG-TS descriptors parser
 
 The code there is generig enough to decode the MPEG-TS descriptors,
 with the DVB and other Digital TV extensions.
 
 libscan.c/libscan/h: DVBv5 scanning library
 
 This library is used to retrieve DVB information from the MPEG TS
 headers, discovering the services associated to each DVB channel or
 transponder. The services information is the basic info that most
 DVB tools need to tune into a channel.
 
 dvb-file.c/dvb-file.h: DVB file read/write library.
 
 Allows parsing a DVB file (legacy or not) and to write data into a
 DVB file (new format only).
 
 dvb-fe.c/dvb-fe.h: DVB frontend library.
 
 Allows talking with a DVB frontend via DVBv5 or DVBv3 API.
 
 dvb-zap-format.c/dvb-legacy-channel-format.c:
 
 Contains the data structures required in order to read from the legacy
 formats (zap or scan initial-tuning-data-file).
 
 dvb_frontend.h: DVBv5 frontend API.
 
 This is just a copy of the newest linux/dvb/frontend.h header.
 I opted to keep a copy there, in order to allow working with the tools
 without needing to copy the latest header into /usr/include.
 
 dvb-v5.h/dvb-v5-std.h:
 
 Ancillary files linked into dvb-fe code, used to parse DVB tables. The
 dvbv5.h is generated by a small perl util, from the DVB FE API file.
 
 dvb-demux.c/dvb-demux.h: DVB demux library.
 
 Used by the dvbv5-zap utility.
 
 dvb-fe-tool.c, dvb-format-convert.c, dvbv5-zap.c, dvbv5-scan.c: tools code.
 
 Basically, parses the options from userspace and calls the other code
 to do what was requested by the user.
 
 CHANNEL/SERVICE FILE FORMAT
 ===
 
 Instead of having two different files, one for services, and another for
 channels/transponders, I opted to use just one format for both. The
 format is:
 
 [channel]
 key1=value1
 key2=value2
 key3=value3
 ...
 keyn=valuen
 
 
 lines with # are discarted by the parsers. Also, whitespaces/tabs before
 the keys and before/after the equal sign.
 
 Be careful: whitespace in the middle of the value are not discarded.
 
 A typical service would be like:
 
 [TV Brasil HD]
 VCHANNEL = 2.2
 SERVICE_ID = 16160
 VIDEO_PID = 770
 AUDIO_PID = 514 614
 FREQUENCY = 479142857
 MODULATION = QAM/AUTO
 BANDWIDTH_HZ = 600
 INVERSION = AUTO
 CODE_RATE_HP = AUTO
 CODE_RATE_LP = NONE
 GUARD_INTERVAL = AUTO
 TRANSMISSION_MODE = AUTO
 HIERARCHY = NONE
 ISDBT_LAYER_ENABLED = 7
 ISDBT_PARTIAL_RECEPTION = 0
 ISDBT_SOUND_BROADCASTING = 0
 ISDBT_SB_SUBCHANNEL_ID = 0
 ISDBT_SB_SEGMENT_IDX = 0
 ISDBT_SB_SEGMENT_COUNT = 0
 ISDBT_LAYERA_FEC = AUTO
 ISDBT_LAYERA_MODULATION = QAM/AUTO