[GIT PATCHES FOR 2.6.38]
Hi Mauro, These patches remove s_config legacy support, replace it with new internal operations (also needed for the upcoming subdev device nodes) and finally rename has_new to is_new and document that control framework flag. My original RFC also converted OLPC drivers, but those are scheduled for 2.6.39. It needs a bit more testing and I intend to improve the handling of autofoo/foo type of controls in the control framework. Regards, Hans The following changes since commit 04c3fafd933379fbc8b1fa55ea9b65281af416f7: Hans Verkuil (1): [media] vivi: convert to the control framework and add test controls are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git s_config2 Hans Verkuil (3): v4l2-subdev: remove core.s_config and v4l2_i2c_new_subdev_cfg() v4l2-subdev: add (un)register internal ops v4l2-ctrls: v4l2_ctrl_handler_setup must set is_new to 1 Documentation/video4linux/v4l2-controls.txt | 12 drivers/media/video/cafe_ccic.c | 11 +++- drivers/media/video/cx25840/cx25840-core.c | 22 ++-- drivers/media/video/em28xx/em28xx-cards.c | 18 --- drivers/media/video/ivtv/ivtv-i2c.c |9 +++- drivers/media/video/mt9v011.c | 54 --- drivers/media/video/mt9v011.h | 36 - drivers/media/video/ov7670.c| 74 --- drivers/media/video/sr030pc30.c | 10 drivers/media/video/v4l2-common.c | 19 +-- drivers/media/video/v4l2-ctrls.c| 20 --- drivers/media/video/v4l2-device.c | 14 - include/media/mt9v011.h | 17 ++ include/media/v4l2-common.h | 13 + include/media/v4l2-ctrls.h |6 ++- include/media/v4l2-subdev.h | 23 +++-- 16 files changed, 174 insertions(+), 184 deletions(-) delete mode 100644 drivers/media/video/mt9v011.h create mode 100644 include/media/mt9v011.h -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: Interconnection of different DVB adapters (was: Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver)
On Tuesday 11 January 2011 02:32:14 Andreas Oberritter wrote: > On 01/10/2011 06:20 PM, Oliver Endriss wrote: > > On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote: > >> On 01/10/2011 10:36 AM, Oliver Endriss wrote: > >>> From: Ralph Metzler > >>> > >>> Driver for the Common Interface Controller CXD2099AR. > >>> Supports the CI of the cineS2 DVB-S2. > >>> > >>> For now, data is passed through '/dev/dvb/adapterX/sec0': > >>> - Encrypted data must be written to 'sec0'. > >>> - Decrypted data can be read from 'sec0'. > >>> - Setup the CAM using device 'ca0'. > >> > >> Nack. In DVB API terms, "sec" stands for satellite equipment control, > >> and if I remember correctly, sec0 already existed in the first versions > >> of the API and that's why its leftovers can be abused by this driver. > >> > >> The interfaces for writing data are dvr0 and demux0. If they don't fit > >> for decryption of recorded data, then they should be extended. > >> > >> For decryption of live data, no new user interface needs to be created. > > > > There was an attempt to find a solution for the problem in thread > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html > > > > As that discussion did not come to a final solution, and the driver is > > still experimental, I left the original patch 'as is'. > > Thanks for the pointer. My impression from the quoted thread is that the > most desired and viable solution was to create a ca device node which > can be virtually connected on demand to a demux or dvr device of another > adapter, but there was no intent to put the required amount of work into > it. Attaching a CI to a single frontend is easy. In this case we could simply attach the CI to the first frontend of the card, and we are done. The intention was to allow decryption of streams from more than one frontend _at_the_same_time_. That might require multiplexing partial TS streams into a new one, passing it to the CAM and demultiplexing the decrypted stream again. The idea was to perform these operations in userspace, while the kernel provides a simple interface which - accepts an encrypted stream and - delivers the decrypted stream. sec0 was chosen because it exists and it is currently unused. It can be renamed anytime, if we reach an agreement. > That's fair, but IMHO not suitable for submission to the mainline > kernel. > > This definitely needs more thought. If this is the common opinion, I will simply strip the CI support from the driver again. The stv0900x and ngene patches are too important to be delayed. > Maybe the adapter-based scheme currently in use needs to be revised > thoroughly. The "budget" type of adapters are basically just frontends > and we should be able to interconnect those (and also other) frontends > with CIs, demuxes and decoders of different adapters, if the underlying > buses allow it. Is this something the media controller and mem2mem APIs > are trying to solve for V4L? If yes, this could become interesting for > DVB, too. Honestly, I have little motivation to work on things, which I do not use. I do not care about CAM stuff. I am just submitting the code I received... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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
Interconnection of different DVB adapters (was: Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver)
On 01/10/2011 06:20 PM, Oliver Endriss wrote: > On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote: >> On 01/10/2011 10:36 AM, Oliver Endriss wrote: >>> From: Ralph Metzler >>> >>> Driver for the Common Interface Controller CXD2099AR. >>> Supports the CI of the cineS2 DVB-S2. >>> >>> For now, data is passed through '/dev/dvb/adapterX/sec0': >>> - Encrypted data must be written to 'sec0'. >>> - Decrypted data can be read from 'sec0'. >>> - Setup the CAM using device 'ca0'. >> >> Nack. In DVB API terms, "sec" stands for satellite equipment control, >> and if I remember correctly, sec0 already existed in the first versions >> of the API and that's why its leftovers can be abused by this driver. >> >> The interfaces for writing data are dvr0 and demux0. If they don't fit >> for decryption of recorded data, then they should be extended. >> >> For decryption of live data, no new user interface needs to be created. > > There was an attempt to find a solution for the problem in thread > http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html > > As that discussion did not come to a final solution, and the driver is > still experimental, I left the original patch 'as is'. Thanks for the pointer. My impression from the quoted thread is that the most desired and viable solution was to create a ca device node which can be virtually connected on demand to a demux or dvr device of another adapter, but there was no intent to put the required amount of work into it. That's fair, but IMHO not suitable for submission to the mainline kernel. This definitely needs more thought. Maybe the adapter-based scheme currently in use needs to be revised thoroughly. The "budget" type of adapters are basically just frontends and we should be able to interconnect those (and also other) frontends with CIs, demuxes and decoders of different adapters, if the underlying buses allow it. Is this something the media controller and mem2mem APIs are trying to solve for V4L? If yes, this could become interesting for DVB, too. Regards, Andreas -- 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: Debug code in HG repositories
On Monday 10 January 2011 13:27:09 Mauro Carvalho Chehab wrote:
> > ...
> > diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c
> > /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
> > --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10
> > 10:01:49.0 -0200
> > +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10
> > 10:02:05.0 -0200
> > @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
> > NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
> > NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
> > NGENE_ID(0x1461, 0x062e, ngene_info_m780),
> > +#if 0 /* not (yet?) supported */
> > + NGENE_ID(0x18c3, 0x, ngene_info_appboard),
> > + NGENE_ID(0x18c3, 0x0004, ngene_info_appboard),
> > + NGENE_ID(0x18c3, 0x8011, ngene_info_appboard),
> > + NGENE_ID(0x18c3, 0x8015, ngene_info_appboard_ntsc),
> > + NGENE_ID(0x153b, 0x1167, ngene_info_terratec),
> > + NGENE_ID(0x18c3, 0x0030, ngene_info_python),
> > + NGENE_ID(0x18c3, 0x0052, ngene_info_sidewinder),
> > + NGENE_ID(0x18c3, 0x8f00, ngene_info_racer),
> > + NGENE_ID(0x18c3, 0x0041, ngene_info_viper_v1),
> > + NGENE_ID(0x18c3, 0x0042, ngene_info_viper_v2),
> > + NGENE_ID(0x14f3, 0x0041, ngene_info_vbox_v1),
> > + NGENE_ID(0x14f3, 0x0043, ngene_info_vbox_v2),
> > + NGENE_ID(0x18c3, 0xabcd, ngene_info_s2),
> > + NGENE_ID(0x18c3, 0xabc2, ngene_info_s2_b),
> > + NGENE_ID(0x18c3, 0xabc3, ngene_info_s2_b),
> > + NGENE_ID(0x18c3, 0x0001, ngene_info_appboard),
> > + NGENE_ID(0x18c3, 0x0005, ngene_info_appboard),
> > + NGENE_ID(0x18c3, 0x0009, ngene_info_appboard_atsc),
> > + NGENE_ID(0x18c3, 0x000b, ngene_info_appboard_atsc),
> > + NGENE_ID(0x18c3, 0x0010, ngene_info_shrek_50_fp),
> > + NGENE_ID(0x18c3, 0x0011, ngene_info_shrek_60_fp),
> > + NGENE_ID(0x18c3, 0x0012, ngene_info_shrek_50),
> > + NGENE_ID(0x18c3, 0x0013, ngene_info_shrek_60),
> > + NGENE_ID(0x18c3, 0x, ngene_info_hognose),
> > +#endif
> > {0}
> > };
> > MODULE_DEVICE_TABLE(pci, ngene_id_tbl);
>
> It is probably a good idea to backport this one. I would change it to #if 1,
> to allow
> people to test (or I would create a CONFIG_NGENE_EXPERIMENTAL to enable such
> support).
Nack, it would not work. If you have a look at a really unstripped ;-)
version of the file, you will notice that you have to invest a
considerable amount of effort to get these card types running.
This kind of stuff should be added one by one, whenever someone is
working on it.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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: Debug code in HG repositories
On Monday 10 January 2011 13:04:54 Mauro Carvalho Chehab wrote: > Em 07-01-2011 21:56, Oliver Endriss escreveu: > > ... > > There are large pieces of driver code which are currently unused, and > > nobody can tell whether they will ever be needed. > > > > On the other hand a developer spent days writing this stuff, and now it > > does not exist anymore - without any trace! > > > > The problem is not, that it is missing in the current snapshot, but > > that it has never been in the git repository, and there is no way to > > recover it. > > The Mercurial tree will stay there forever. We still have there the old CVS > trees used by DVB and V4L development. > > > > Afaics, the only way to preserve this kind of code is 'out-of-tree'. > > It is a shame... :-( > > I see your point. It is harder for people to re-use that code, as they are not > upstream. The main problem is that they do not even know that the code exists. Maybe I should add some comment to the driver, that someone should look into the HG repository, before he starts re-inventing the wheel. > It is easy to recover the changes with: > > $ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped > $ gentree.pl 2.6.37 linux/ /tmp/not_stripped > $ diff -upr /tmp/stripped/ /tmp/not_stripped/ >/tmp/revert_removed_code.patch > > As a reference and further discussions, I'm enclosing the diff. The resulting diff is far from complete. In fact, the most interesting parts are missing. Apparently, the command gentree.pl 2.6.37 linux/ /tmp/not_stripped stripped all '#if 0' blocks, which are not followed by a comment. Just compare the original ngene_av.c with the resulting version in /tmp/non_stripped. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] v4l2-ctrls: Add V4L2_CID_NIGHT_MODE control to support night mode
On Mon, 10 Jan 2011, Roberto Rodriguez Alcala wrote:
> From: Roberto Rodriguez Alcala
>
>
> Signed-off-by: Roberto Rodriguez Alcala
> ---
> drivers/media/video/v4l2-ctrls.c |2 ++
> include/linux/videodev2.h|2 ++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index 8f81efc..7a8934e 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -365,6 +365,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_PRIVACY: return "Privacy";
> case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
> case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
> + case V4L2_CID_NIGHT_MODE: return "Night mode";
After you have clarified questions, asked by Hans, if this patch is going
to be accepted in more or less unchanged form, please, in the above line
and...
>
> /* FM Radio Modulator control */
> /* Keep the order of the 'case's the same as in videodev2.h! */
> @@ -418,6 +419,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
> case V4L2_CID_FOCUS_AUTO:
> case V4L2_CID_PRIVACY:
> + case V4L2_CID_NIGHT_MODE:
> case V4L2_CID_AUDIO_LIMITER_ENABLED:
> case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
> case V4L2_CID_PILOT_TONE_ENABLED:
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 5f6f470..0df8a9f 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1300,6 +1300,8 @@ enum v4l2_exposure_auto_type {
> #define V4L2_CID_IRIS_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+17)
> #define V4L2_CID_IRIS_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+18)
>
> +#define V4L2_CID_NIGHT_MODE
> (V4L2_CID_CAMERA_CLASS_BASE+19)
> +
in this one use TABs and not spaces for indentation, just like other lines
do.
> /* FM Modulator class control IDs */
> #define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
> #define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
> --
> 1.7.3.2
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] v4l2-ctrls: Add V4L2_CID_NIGHT_MODE control to support night mode
On Monday, January 10, 2011 23:18:26 Roberto Rodriguez Alcala wrote:
> From: Roberto Rodriguez Alcala
>
>
> Signed-off-by: Roberto Rodriguez Alcala
> ---
> drivers/media/video/v4l2-ctrls.c |2 ++
> include/linux/videodev2.h|2 ++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index 8f81efc..7a8934e 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -365,6 +365,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_PRIVACY: return "Privacy";
> case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
> case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
> + case V4L2_CID_NIGHT_MODE: return "Night mode";
"Night Mode" (capital 'M', like in all the other strings).
>
> /* FM Radio Modulator control */
> /* Keep the order of the 'case's the same as in videodev2.h! */
> @@ -418,6 +419,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
> case V4L2_CID_FOCUS_AUTO:
> case V4L2_CID_PRIVACY:
> + case V4L2_CID_NIGHT_MODE:
> case V4L2_CID_AUDIO_LIMITER_ENABLED:
> case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
> case V4L2_CID_PILOT_TONE_ENABLED:
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 5f6f470..0df8a9f 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1300,6 +1300,8 @@ enum v4l2_exposure_auto_type {
> #define V4L2_CID_IRIS_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+17)
> #define V4L2_CID_IRIS_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+18)
>
> +#define V4L2_CID_NIGHT_MODE
> (V4L2_CID_CAMERA_CLASS_BASE+19)
> +
> /* FM Modulator class control IDs */
> #define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
> #define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
>
This control also needs to be documented in
Documentation/DocBook/v4l/controls.xml.
However, reading up a bit on this I wonder whether this shouldn't be a 'Camera
Mode'
menu control since there can be a lot of different modes:
http://www.digital-photography-school.com/digital-camera-modes
Also, how does this relate to controls like EXPOSURE_AUTO? Will selecting
manual exposure automatically turn off Night Mode? Or the inverse, will
selecting Night Mode automatically turn on autoexposure?
How is this done in the ov7670?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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] ov7670: Allow configuration of night mode
From: Roberto Rodriguez Alcala
Signed-off-by: Roberto Rodriguez Alcala
---
drivers/media/video/ov7670.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index c881a64..cfe96e5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -1255,6 +1255,36 @@ static int ov7670_s_gain(struct v4l2_subdev *sd, int
value)
}
/*
+ * Get or Set Night Mode.
+ */
+static int ov7670_g_nightmode(struct v4l2_subdev *sd, __s32 *value)
+{
+ int ret;
+ unsigned char com11;
+
+ ret = ov7670_read(sd, REG_COM11, &com11);
+ *value = (com11 & COM11_NIGHT) != 0;
+ return ret;
+}
+
+static int ov7670_s_nightmode(struct v4l2_subdev *sd, int value)
+{
+ int ret;
+ unsigned char com11;
+
+ ret = ov7670_read(sd, REG_COM11, &com11);
+ if (ret == 0) {
+ if (value)
+ com11 |= COM11_NIGHT;
+ else
+ com11 &= ~COM11_NIGHT;
+ ret = ov7670_write(sd, REG_COM11, com11);
+ }
+ return ret;
+}
+
+
+/*
* Tweak autogain.
*/
static int ov7670_g_autogain(struct v4l2_subdev *sd, __s32 *value)
@@ -1382,6 +1412,8 @@ static int ov7670_queryctrl(struct v4l2_subdev *sd,
return v4l2_ctrl_query_fill(qc, 0, 65535, 1, 500);
case V4L2_CID_EXPOSURE_AUTO:
return v4l2_ctrl_query_fill(qc, 0, 1, 1, 0);
+ case V4L2_CID_NIGHT_MODE:
+ return v4l2_ctrl_query_fill(qc, 0, 1, 1, 0);
}
return -EINVAL;
}
@@ -1409,6 +1441,8 @@ static int ov7670_g_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
return ov7670_g_exp(sd, &ctrl->value);
case V4L2_CID_EXPOSURE_AUTO:
return ov7670_g_autoexp(sd, &ctrl->value);
+ case V4L2_CID_NIGHT_MODE:
+ return ov7670_g_nightmode(sd, &ctrl->value);
}
return -EINVAL;
}
@@ -1437,6 +1471,8 @@ static int ov7670_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
case V4L2_CID_EXPOSURE_AUTO:
return ov7670_s_autoexp(sd,
(enum v4l2_exposure_auto_type) ctrl->value);
+ case V4L2_CID_NIGHT_MODE:
+ return ov7670_s_nightmode(sd, ctrl->value);
}
return -EINVAL;
}
--
1.7.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add Camera Control Class to Support Night Mode Feature
Hi, I'm sending this patch proposing to add a Camera Control Class to support Night Mode because there are a lot of cameras with that feature, and the implemented ones currently non stantard work arounds, like enabling it in certain resolutions or using another control class like WHITE_BALANCE. Also, I couldn't find a Control class suitable for that, because the efects of this feature varies from camera to camera like reduce frame rate by 1/4, enabling IR LEDs, etc. This Patch includes the implementation for ov7670 and if you agree I can send the patched for other cameras also. Thank You, Roberto -- 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] v4l2-ctrls: Add V4L2_CID_NIGHT_MODE control to support night mode
From: Roberto Rodriguez Alcala
Signed-off-by: Roberto Rodriguez Alcala
---
drivers/media/video/v4l2-ctrls.c |2 ++
include/linux/videodev2.h|2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8f81efc..7a8934e 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -365,6 +365,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+ case V4L2_CID_NIGHT_MODE: return "Night mode";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -418,6 +419,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
+ case V4L2_CID_NIGHT_MODE:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
case V4L2_CID_PILOT_TONE_ENABLED:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5f6f470..0df8a9f 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1300,6 +1300,8 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_NIGHT_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debug code in HG repositories
Mauro, A few comments in-line. Vide infra. On Mon, 10 Jan 2011, Mauro Carvalho Chehab wrote: > Em 07-01-2011 21:42, Theodore Kilgore escreveu: > > >> Have you tried Mauro's media_build tree? I had to use it today to test a > >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we > > should > >> promote this more. > > > > Probably a good idea. I have been too busy to know about it, myself. And I > > even do try to keep up with what is going on. > > > >> I could add backwards compatibility builds to my > > daily > >> build script that uses this in order to check for which kernel versions > >> this compiles if there is sufficient interest. > > > > Nice, but don't bust your behind with a thing like that. Back when we were > > discussing the idea of getting off of hg and onto git, I suggested > > approximately the previous three minor versions of the kernel, no > > more. And if there was a serious problem with 2.(current_release - 1) or > > 2.(current_release - 2) such as instability or security issues, whatever, > > then just drop that one. I think that to do this is reasonable if you or > > anyone else has the time and needed skills. More than this is not > > reasonable under any circumstances. > > I think Hans can enable it. The backport effort on media-build is a way > easier than with -hg. For example, in order to support kernel 2.6.31 (the > oldest > one on that tree), we need only 10 patches. The patches themself are simple: > > $ wc -l *.patch >61 v2.6.31_nodename.patch > 540 v2.6.32_kfifo.patch >42 v2.6.33_input_handlers_are_int.patch >70 v2.6.33_pvrusb2_sysfs.patch >40 v2.6.34_dvb_net.patch >22 v2.6.34_fix_define_warnings.patch >16 v2.6.35_firedtv_handle_fcp.patch > 104 v2.6.35_i2c_new_probed_device.patch > 145 v2.6.35_work_handler.patch > 104 v2.6.36_input_getkeycode.patch > 1144 total > > And almost all patches are trivial. Great. I am glad Hans is able to do that. I also think that before some changes were made things had reached the point of being both ridiculous and impossible. People doing the work were being run ragged, and demands for legacy support were obviously unreasonable. I forget what all of the issues were in the pre-2.6.20 kernels. I vaguely recall there were some really bad ones. One of them that I have personal knowledge about was a major error in the USB Mass Storage module, detected and fixed somewhere around 2.6.18. Namely, if a device says it is Class 08 the spec says the first pair of bulk endpoints will be used. Before the fix, last pair was being searched instead. The mistake is not confronted very often, of course, because few USB devices have more than one pair of bulk endpoints. But for those that do, ouch. In fact, the hardware which brought the mistake to daylight was the same camera which is supported in gspca/jeilinj.c. In still mode as a standard mass storage device, that camera uses the first pair of bulk endpoints. As it is supposed to do. But until things were fixed, the mass storage support was attempting to use the second pair, which did not work out very well. The second pair of the bulk endpoints gets used only in webcam mode for passing commands and responses. The point of the above story is that sometimes in kernel development things are changed from wrong to right. Those who petulantly want their favorite ancient kernel to be supported simply ought to understand and accept out of hand. Should any kernel prior to the fixing of the above problem continue in use in any environment where it needs to support USB mass storage devices? Obviously not. The moral for the present and future is obvious, too. > > > Now, as to the question of switching over to and using git, here are my > > recent personal experiences: > > > > I started to do this switch-over only about a month ago, having been too > > busy for several months previous due to an illness in the family. I found > > that everything had changed in the meantime, and the hg trees had gone > > away. > > > > Issue 0: This issue came up just as I was deciding to switch from 32 to 64 > > bit computing, so a lot of other stuff needed to be fixed or upgraded at > > the same time. I was busy. Well, lots of people are busy, and for lots of > > reasons. > > > > Issue 1: Which git tree? For someone who is going to get in at the > > beginning, this is not obvious. This issue got solved, of course, but it > > was the first one to face. For an outsider, I suspect that even this is > > somewhat intimidating. > > It is now well-indicated at the top of the git page at linuxtv.org. Nice. > > > Issue 2: Problems totally unrelated to drivers/media rendered the new > > kernel unusable for very a long time, approximately a couple of weeks. I > > think I can call myself experienced in kernel configuration and > > compilation, and also not a total neophyte as a developer. The issue was a > > rather evil interact
Re: [RFC V9 3/7] drivers:media:radio: wl128x: FM Driver Common sources
Hi Manjunatha,
Thanks for all the work, it looks much better now!
I found a few little things here, but otherwise you can stick a
Reviewed-by: Hans Verkuil
tag in the whole driver series.
On Monday, January 10, 2011 14:04:56 manjunatha_ha...@ti.com wrote:
> From: Manjunatha Halli
>
> These are the sources for the common interfaces required by the
> FM V4L2 driver for TI WL127x and WL128x chips.
>
> These implement the FM channel-8 protocol communication with the
> chip. This makes use of the Shared Transport as its transport.
>
> Signed-off-by: Manjunatha Halli
> ---
> drivers/media/radio/wl128x/fmdrv_common.c | 1693
> +
> drivers/media/radio/wl128x/fmdrv_common.h | 402 +++
> 2 files changed, 2095 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c
> create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h
>
> diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
> b/drivers/media/radio/wl128x/fmdrv_common.c
> new file mode 100644
> index 000..46f5fe4
> --- /dev/null
> +++ b/drivers/media/radio/wl128x/fmdrv_common.c
> +u32 fmc_set_freq(struct fmdev *fmdev, u32 freq_to_set)
> +{
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + return fm_rx_set_freq(fmdev, freq_to_set);
> + break;
'break' after a 'return' can be removed. This is repeated several times.
> +
> + case FM_MODE_TX:
> + return fm_tx_set_freq(fmdev, freq_to_set);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +u32 fmc_get_freq(struct fmdev *fmdev, u32 *cur_tuned_frq)
> +{
> + if (fmdev->rx.freq == FM_UNDEFINED_FREQ) {
> + fmerr("RX frequency is not set\n");
> + return -EPERM;
> + }
> + if (cur_tuned_frq == NULL) {
> + fmerr("Invalid memory\n");
> + return -ENOMEM;
> + }
> +
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + *cur_tuned_frq = fmdev->rx.freq;
> + break;
> +
> + case FM_MODE_TX:
> + *cur_tuned_frq = 0; /* TODO : Change this later */
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +u32 fmc_set_region(struct fmdev *fmdev, u8 region_to_set)
> +{
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + return fm_rx_set_region(fmdev, region_to_set);
> + break;
> +
> + case FM_MODE_TX:
> + return fm_tx_set_region(fmdev, region_to_set);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +u32 fmc_set_mute_mode(struct fmdev *fmdev, u8 mute_mode_toset)
> +{
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + return fm_rx_set_mute_mode(fmdev, mute_mode_toset);
> + break;
> +
> + case FM_MODE_TX:
> + return fm_tx_set_mute_mode(fmdev, mute_mode_toset);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +u32 fmc_set_stereo_mono(struct fmdev *fmdev, u16 mode)
> +{
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + return fm_rx_set_stereo_mono(fmdev, mode);
> + break;
> +
> + case FM_MODE_TX:
> + return fm_tx_set_stereo_mono(fmdev, mode);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +u32 fmc_set_rds_mode(struct fmdev *fmdev, u8 rds_en_dis)
> +{
> + switch (fmdev->curr_fmmode) {
> + case FM_MODE_RX:
> + return fm_rx_set_rds_mode(fmdev, rds_en_dis);
> + break;
> +
> + case FM_MODE_TX:
> + return fm_tx_set_rds_mode(fmdev, rds_en_dis);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +/* Sends power off command to the chip */
> +static u32 fm_power_down(struct fmdev *fmdev)
> +{
> + u16 payload;
> + u32 ret = 0;
> +
> + if (!test_bit(FM_CORE_READY, &fmdev->flag)) {
> + fmerr("FM core is not ready\n");
> + return -EPERM;
> + }
> + if (fmdev->curr_fmmode == FM_MODE_OFF) {
> + fmdbg("FM chip is already in OFF state\n");
> + return ret;
> + }
> +
> + payload = 0x0;
> + ret = fmc_send_cmd(fmdev, FM_POWER_MODE, REG_WR, &payload,
> + sizeof(payload), NULL, NULL);
> + if (ret < 0)
> + return ret;
> +
> + ret = fmc_release(fmdev);
Just do 'return fmc_release(fmdev);' here.
> +
> + return ret;
> +}
> +
> +/* Reads init command from FM firmware file and loads to the chip */
> +static u32 fm_download_firmware(struct fmdev *fmdev, const u8 *fw_name)
> +{
> + const struct firmware *fw_entry;
> + struct bts_header *fw_header;
> + struct bts_action *action;
> + struct bts_action_delay *delay;
> + u8 *fw_data;
> + int ret, fw_len, cmd_cn
Re: [PATCH 01/18] Altera FPGA firmware download module.
В сообщении от 5 января 2011 12:26:03 автор Laurent Pinchart написал: > Hi, > > On Friday 31 December 2010 16:04:13 Ben Gamari wrote: > > On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab wrote: > > > > I understand this. However, a complete JTAG state machine in the > > > > kernel, plus an Altera firmware parser, seems to be a lot of code > > > > that could live in userspace. > > > > > > Moving it to userspace would mean a kernel driver that would depend on > > > an userspace daemon^Wfirmware loader to work. I would NAK such > > > designs. > > > > Why? I agree that JTAG is a lot to place in the kernel and is much > > better suited to be in user space. What exactly is your objection to > > depending on a userspace utility? There is no shortage of precedent for > > loading firmware in userspace (e.g. fx2 usb devices). > > I agree with this. Mauro, why would a userspace firmware loader be such a > bad idea ? > > > > > If I understand it correctly the driver assumes the firmware is in an > > > > Altera proprietary format. If we really want JTAG code in the kernel > > > > we should at least split the file parser and the TAP access code. > > > > > > Agreed, but I don't think this would be a good reason to block the code > > > merge for .38. > > > > I agree with the above isn't good reason to block it but if there is > > still debate about the general architecture of the code (see above), > > then it seems aren't ready yet. The code looks very nice, but I'm not at > > all convinced that it needs to be in the kernel. Just my two-tenths of a > > cent. We all realize, that FPGA programming not belongs to DVB only, it is more common. But my intention to write driver for DVB and V4L device... Yes, it needed for DVB device to work, and it works on real hardware. FPGA model used in device has not flash memory. So every time the so-called "firmware" has to be loaded on early device initialization stage. Then FPGA itself drives CI and hardware PID filter. Fhysically, FPGA JTAG interface connected to cx23885 GPIO lines. Take a look on media/dvb/dvb-usb drivers. There is a lot of FX2 firmware dependant devices, but no one of them uses userspace utilities to push firmware inside. If someone has something to put on table, I mean code implementation, then put it on. Everithing is possible to change, but it is needed to begin with something. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: [GIT PATCHES FOR 2.6.38] usbvision BKL removal and cleanup
Hi Hans, Le Wed, 29 Dec 2010 17:56:36 +0100, Hans Verkuil a écrit : > Hi Mauro, > > The first patch converts usbvision to core-assisted locking, the > others do a big coding style cleanup. > > I want to clean up this driver in the future, so the first step is to > fix all the coding style violations first. That way I can actually > read the source code :-) > Good intention. This is something I wanted to do but lack of time. There is a compression algorithm in this driver that should go into userspace. I think this is the hardest part. I can help for the cleanup but cannot lead it right now. Regards, Thierry -- 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: Maybe I'll hack on lirc_zilog.c this coming weekend (Re: Enable IR on hdpvr)
On Jan 10, 2011, at 7:12 AM, Andy Walls wrote: > On Mon, 2011-01-10 at 01:05 -0500, Jarod Wilson wrote: >> On Jan 9, 2011, at 7:36 PM, Jason Gauthier wrote: > >> There's a bit more to it than just the one line change. Here's the patch >> we're >> carrying in the Fedora kernels to enable it: >> >> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch >> > > BTW, I plan to work on lirc_zilog.c this coming weekend, with my PVR-150 > and HVR-1600 as test units. If there are any lirc_zilog.c patches you > have developed that are not in the media_tree.git repo, could you point > me to them before then? Don't have any, so you should be good to go. /me still needs to do further testing w/the hdpvr and hvr-1950... -- Jarod Wilson ja...@wilsonet.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: Enable IR on hdpvr
On Jan 10, 2011, at 9:25 AM, Jason Gauthier wrote: >>> >>> I did simply try changing: >>> >>> /* until i2c is working properly */ >>> retval = 0; /* hdpvr_register_i2c_ir(dev); */ >>> if (retval < 0) >>> >>> so that it would register with i2c. >>> Doing so returns a positive registration with I2C, but the lirc_zilog >>> driver doesn't see the chip when it loads. (The lirc_zilog is now in >>> the kernel, yay) > >> There's a bit more to it than just the one line change. Here's the patch >> we're carrying in the Fedora kernels to enable it: > >> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch > >> Janne, I've heard many success stories w/the hdpvr IR lately, and almost no >> reports of lockups, so I'm thinking a firmware update may have helped out >> >here, and thus, maybe its time we just go ahead and push this patch along >> upstream? We still require someone to load lirc_zilog manually, so it seems >> like a >fairly low-risk thing to do. > > Thanks. What source tree is this against? I see the patch is dated 09/2009. > Manually comparing to my .37 source tree it does not appear to match up. > I don't mind bringing in a third source tree to compare against to see if I > can make this work on .37, I just don't know which one! Bah. Yeah, sorry, that wasn't the current patch in Fedora 14. This is: http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable-2.patch Its atop the F14 2.6.35.10 kernel, which has a fairly recent v4l/dvb backport on top of it, so it should be pretty close to matching the current v4l/dvb code... -- Jarod Wilson ja...@wilsonet.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
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Jan 10 19:00:35 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Monday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. 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: [InfraSchlot SPAM Check] Re: [PATCH] DVB Satellite Channel Routing support for DVB-S
Hello Oliver, Am 10.01.2011 um 18:28 schrieb Oliver Endriss: > Ack, this stuff should be implemented as a userspace library. > (Btw, there is an experimental unicable patch for VDR.) Yes, there is. I have not testet it as I am going to use MythTV, but for what I have read in some forums, many people have problems using that patch. This is why I decided to make a kernel implementation for my system. But I agree it could also be implemented as a wrapper application between frontend device and viewer application (the quick and dirty way) or native support in a userspace library (which will take some time until it is used in all DVB applications). What I thought makes my solution attractive is, that you can even use dvbscan, szap etc. without modification, which works perfectly in my setup. But anyway the purpose might be too special to have it inside the kernel. Regards, Thomas-- 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: [RFCv2 PATCH 0/5] Use control framework in cafe_ccic and s_config removal
On Monday, January 10, 2011 12:08:42 Hans Verkuil wrote: > > Hi, > > > >>> Another reason why s_config is a bad idea. > > > > Thanks a lot for working on this. I had a quick look and don't have > > any objections. > > > >>> This has been extensively tested on my humble OLPC laptop (and it took > >>> me 4-5 > >>> hours just to get the damn thing up and running with these drivers). > > > > In future, come into irc.oftc.net #olpc-devel and talk to me (dsd) or > > cjb (Chris Ball), we'll get you up and running in less time! > > If you have a link to some instructions on how to get the latest kernel up > and running for olpc, then that would be handy :-) > > > I'll test the via-camera patch unless Jon beats me too it, but won't > > be immediately. If you are ever interested in doing more in-depth work > > on that driver, please drop me a mail and we will send you a XO-1.5. > > It's just for ongoing V4L2 maintenance (such as this sort of work). > > > > > Also, perhaps you are interested in working on this bug, which is > > probably reproducible with cafe_ccic too: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg23841.html > > I'll see if I can reproduce this with cafe_ccic. Weird that I haven't seen > this before. The code looks fishy: my first guess is that sd->flags should > be put in a local variable before it is being tested. > > I must have missed that bug report the first time around. I'm pretty sure that this simple patch will fix it: diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index 7fe6f92..83a2e69 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -100,6 +100,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) is a platform bus, then it is never deleted. */ if (client) i2c_unregister_device(client); + continue; } #endif #if defined(CONFIG_SPI) @@ -108,6 +109,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) if (spi) spi_unregister_device(spi); + continue; } #endif } If you have time, then I'd appreciate it if you could check that this fixes it for via_camera. I'll try to test with on cafe_ccic as well some time this week. This bug is only triggered when a i2c module is unloaded on a platform i2c bus. This doesn't happen on PCI/USB i2c busses, which is the reason why I never saw it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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] DVB Satellite Channel Routing support for DVB-S
Am 10.01.2011 um 16:54 schrieb Andreas Oberritter: > >> - In many TV recording applications there is no support for SCR and it would >> be harder to implement in these. For VDR, there is a patch which is >> difficult to configure and has some technical limitations. In MythTV and >> XMBC I could not find any support for SCR. Their Wiki pages or forums say, >> that there are no plans for Unicable support as it would take huge changes. > > Many of these applications didn't or don't support DiSEqC 1.1 > (uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still, > we don't put this logic into the kernel to make their life easier. > Don't add unneeded complexity to the kernel. I think this is the point we are talking about and I understand the feature might not be critical enough to justify a kernel implementation. Regards, Thomas-- 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 07/16] ngene: CXD2099AR Common Interface driver
On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote: > On 01/10/2011 10:36 AM, Oliver Endriss wrote: > > From: Ralph Metzler > > > > Driver for the Common Interface Controller CXD2099AR. > > Supports the CI of the cineS2 DVB-S2. > > > > For now, data is passed through '/dev/dvb/adapterX/sec0': > > - Encrypted data must be written to 'sec0'. > > - Decrypted data can be read from 'sec0'. > > - Setup the CAM using device 'ca0'. > > Nack. In DVB API terms, "sec" stands for satellite equipment control, > and if I remember correctly, sec0 already existed in the first versions > of the API and that's why its leftovers can be abused by this driver. > > The interfaces for writing data are dvr0 and demux0. If they don't fit > for decryption of recorded data, then they should be extended. > > For decryption of live data, no new user interface needs to be created. There was an attempt to find a solution for the problem in thread http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html As that discussion did not come to a final solution, and the driver is still experimental, I left the original patch 'as is'. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] DVB Satellite Channel Routing support for DVB-S
On Monday 10 January 2011 16:54:14 Andreas Oberritter wrote: > On 01/10/2011 04:07 PM, Thomas Schlöter wrote: > >>> I decided this should be supported by the kernel frontend code as it is > >>> impossible to send that special DiSEqC / voltage sequence from userspace. > >> > >> Why do you think that's impossible? There's a userspace implementation > >> in Enigma2. > > > > I think the kernel implementation would be superior for two reasons: > > - There are some timing requirements regarding the 14/18V transitions and > > the DiSEqC message which could perform better directly from the frontend > > code, > > Unless there's proof, I won't believe that. We're not talking about > nanoseconds, but milliseconds, and it's about setting registers of slow > I2C devices. The same timing requirements are valid for each and every > backwards compatible DiSEqC sequence, which is the most common setting. > > > - In many TV recording applications there is no support for SCR and it > > would be harder to implement in these. For VDR, there is a patch which is > > difficult to configure and has some technical limitations. In MythTV and > > XMBC I could not find any support for SCR. Their Wiki pages or forums say, > > that there are no plans for Unicable support as it would take huge changes. > > Many of these applications didn't or don't support DiSEqC 1.1 > (uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still, > we don't put this logic into the kernel to make their life easier. Don't > add unneeded complexity to the kernel. > > Of course, one could decide to start a reusable library to take care of > that stuff. Honestly, I don't know whether such a library exists today. > > If you find the patch was simple enough to be applied to the kernel, it > must be as simple to patch your favourite application, even in a > platform independent way (not taking into account the required changes > to the UI, which have to be done anyway). Ack, this stuff should be implemented as a userspace library. (Btw, there is an experimental unicable patch for VDR.) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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 03/16] ngene: Firmware 18 support
On Monday 10 January 2011 15:00:18 Bjørn Mork wrote:
> Oliver Endriss writes:
>
> > + case 18:
> > + size = 0;
> > + fw_name = "ngene_18.fw";
> > + break;
> > }
> >
> > if (request_firmware(&fw, fw_name, &dev->pci_dev->dev) < 0) {
> > @@ -1266,6 +1270,8 @@ static int ngene_load_firm(struct ngene *dev)
> > ": Copy %s to your hotplug directory!\n", fw_name);
> > return -1;
> > }
> > + if (size == 0)
> > + size = fw->size;
> > if (size != fw->size) {
> > printk(KERN_ERR DEVICE_NAME
> > ": Firmware %s has invalid size!", fw_name);
>
>
> Just a stupid question: Why remove the size verification for version 18
> while keeping it for the other firmware revisions?
Good point. This was handy when the firmware was developed.
I will submit an additional patch which adds a size check for Fw18.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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] DVB Satellite Channel Routing support for DVB-S
On 01/10/2011 04:07 PM, Thomas Schlöter wrote: >>> I decided this should be supported by the kernel frontend code as it is >>> impossible to send that special DiSEqC / voltage sequence from userspace. >> >> Why do you think that's impossible? There's a userspace implementation >> in Enigma2. > > I think the kernel implementation would be superior for two reasons: > - There are some timing requirements regarding the 14/18V transitions and the > DiSEqC message which could perform better directly from the frontend code, Unless there's proof, I won't believe that. We're not talking about nanoseconds, but milliseconds, and it's about setting registers of slow I2C devices. The same timing requirements are valid for each and every backwards compatible DiSEqC sequence, which is the most common setting. > - In many TV recording applications there is no support for SCR and it would > be harder to implement in these. For VDR, there is a patch which is difficult > to configure and has some technical limitations. In MythTV and XMBC I could > not find any support for SCR. Their Wiki pages or forums say, that there are > no plans for Unicable support as it would take huge changes. Many of these applications didn't or don't support DiSEqC 1.1 (uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still, we don't put this logic into the kernel to make their life easier. Don't add unneeded complexity to the kernel. Of course, one could decide to start a reusable library to take care of that stuff. Honestly, I don't know whether such a library exists today. If you find the patch was simple enough to be applied to the kernel, it must be as simple to patch your favourite application, even in a platform independent way (not taking into account the required changes to the UI, which have to be done anyway). Regards, Andreas -- 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 5/8] davinci vpbe: platform specific additions
Hi Manju,
Please CC linux-arm-ker...@lists.infradead.org for mach-davinci
patches.
On Mon, Jan 10, 2011 at 18:57:37, Hadli, Manjunath wrote:
> This patch implements the overall device creation for the Video
> display driver.
>
> Signed-off-by: Manjunath Hadli
> Acked-by: Muralidharan Karicheri
> Acked-by: Hans Verkuil
> ---
> arch/arm/mach-davinci/dm644x.c | 172
> +--
> arch/arm/mach-davinci/include/mach/dm644x.h | 13 ++-
> 2 files changed, 172 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 9a2376b..f2d24fb 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -5,7 +5,7 @@
> *
> * 2007 (c) Deep Root Systems, LLC. This file is licensed under
> * the terms of the GNU General Public License version 2. This program
> - * is licensed "as is" without any warranty of any kind, whether express
> + * is licensed without any warranty of any kind, whether express
Please don't change the license text of existing licenses.
> * or implied.
> */
> #include
> @@ -590,8 +590,8 @@ static struct resource dm644x_vpss_resources[] = {
> {
> /* VPSS Base address */
> .name = "vpss",
> - .start = 0x01c73400,
> - .end= 0x01c73400 + 0xff,
> + .start = DM644X_VPSS_REG_BASE,
> + .end= DM644X_VPSS_REG_BASE + 0xff,
> .flags = IORESOURCE_MEM,
> },
> };
> @@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
> };
>
> static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +
Random new line?
> static struct resource dm644x_ccdc_resource[] = {
> /* CCDC Base address */
> {
> @@ -654,6 +655,138 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
> vpfe_capture_dev.dev.platform_data = cfg;
> }
>
> +static struct resource dm644x_osd_resources[] = {
> + {
> + .start = DM644X_OSD_REG_BASE,
> + .end= DM644X_OSD_REG_BASE + 0x1ff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
> +
> +static struct osd_platform_data osd_data = {
> + .vpbe_type = DM644X_VPBE,
> + .field_inv_wa_enable = 0,
No need of zero initialization.
> +};
> +
> +static struct platform_device dm644x_osd_dev = {
> + .name = VPBE_OSD_SUBDEV_NAME,
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm644x_osd_resources),
> + .resource = dm644x_osd_resources,
> + .dev = {
> + .dma_mask = &dm644x_osd_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = &osd_data,
> + },
> +};
> +
> +static struct resource dm644x_venc_resources[] = {
> + /* venc registers io space */
> + {
> + .start = DM644X_VENC_REG_BASE,
> + .end= DM644X_VENC_REG_BASE + 0x17f,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
> +
> +#define VPSS_CLKCTL 0x01C40044
There is already a DAVINCI_SYSTEM_MODULE_BASE defined. This
should be defined as an offset from that base.
> +
> +static void __iomem *vpss_clkctl_reg;
> +
> +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64
> mode)
> +{
> + int ret = 0;
> +
> + if (NULL == vpss_clkctl_reg)
> + return -EINVAL;
> + switch (type) {
> + case VPBE_ENC_STD:
> + writel(0x18, vpss_clkctl_reg);
> + break;
> + case VPBE_ENC_DV_PRESET:
> + switch ((unsigned int)mode) {
> + case V4L2_DV_480P59_94:
> + case V4L2_DV_576P50:
> + writel(0x19, vpss_clkctl_reg);
Additional space in indentation.
> + break;
> + case V4L2_DV_720P60:
> + case V4L2_DV_1080I60:
> + case V4L2_DV_1080P30:
> + /*
> + * For HD, use external clock source since
> + * HD requires higher clock rate
> + */
> + writel(0xa, vpss_clkctl_reg);
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> + break;
> + default:
> + ret = -EINVAL;
> + }
> + return ret;
> +}
> +
> +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
> +
> +static struct resource dm644x_v4l2_disp_resources[] = {
> + {
> + .start = IRQ_VENCINT,
> + .end= IRQ_VENCINT,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device vpbe_v4l2_display = {
dm644x_vpbe_v4l2_display
> + .name = "vpbe-v4l2",
> + .id = -1,
>
Re: [PATCH] DVB Satellite Channel Routing support for DVB-S
Hallo Andreas, Am 10.01.2011 um 14:09 schrieb Andreas Oberritter: > Hallo Thomas, > > thank you for your contribution. However, I'm against applying it. > > On 01/10/2011 05:19 AM, Thomas Schlöter wrote: >> I have developed some modifications to the 2.6.37 DVB frontend code to >> support DVB satellite channel routing (aka "SCR", "Unicable", "EN50494"). >> Following this standard, all satellite tuners share the same cable and each >> of them has a fixed intermediate frequency it is supposed to tune to. >> Zapping is done by sending a special DiSEqC message while SEC voltage is >> temporarily pulled from 14 to 18 volts. This message includes the tuner's ID >> from 0 to 7, the frequency, band and polarisation to tune to as well as one >> out of two satellite positions. >> >> I decided this should be supported by the kernel frontend code as it is >> impossible to send that special DiSEqC / voltage sequence from userspace. > > Why do you think that's impossible? There's a userspace implementation > in Enigma2. I think the kernel implementation would be superior for two reasons: - There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code, - In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes. > >> Additionally, it adds fully transparent support for SCR to arbitrary >> applications that use the DVB API, such as MythTV, VDR, xine etc. > > That statement is not true, because you have to configure Unicable LNBs, > which you do using dvb-scr-setup.c. Sure, you have to configure Unicable LNBs as you have to configure for example Universal LNBs. So the viewer software has to be aware of your DVB setup's parameters. If you want to have a configuration menu in the viewer software, this software only needs to send a simple ioctl message to the frontend to configure Unicable. If you want to use Unicable with viewers that do not support it, you only have to set your parameters at boot time using dvb-scr-setup.c. That way, they are also a bit more protected against unintentional changes. In a Unicable system, all participants have interferences if there is one participant using bad settings. So if you start a DVB viewer which is badly or not yet configured, all other participants are disturbed. If you configure your Unicable system using e.g. an init-script, it is impossible to disturb anyone by starting some "Non-Unicable" software. This can be compared to the setup of serial ports, I think. As far as I know, there is a setup utility to have the parameters set (probably at boot time), afterwards you start the actual application. Regards, Thomas -- 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: soc_camera Client Driver with Multiple I2C Addresses
On Tue, 28 Dec 2010 08:55:41 +0100 (CET), Guennadi Liakhovetski wrote: > Hi Charles > > (linux-i2c added to cc) > > On Mon, 27 Dec 2010, Charles D. Krebs wrote: > > > Guennadi, > > > > I'm developing a driver for a video receiver chip that has register > > banks on multiple I2C addresses on the same bus. The data output is > > parallel and I will be connecting it to the sh host interface. > > Overall, the device appears to be suitable as a client driver to > > soc_camera. > > > > I'm following the model for the MT9T112 driver, and this works just fine > > for communicating to any one of the device's I2C addresses. > > > > How would you recommend registering more than one I2C address to an > > soc_camera client driver? > > Honestly - don't know. The soc-camera model for now is pretty simple and > in some senses restrictive. But in principle, it should be possible to > code your case within its scope too. One of the possibilities would be to > register your platform data with one "main" i2c unit / address, and then > let the sensor register the rest in its probe. Is your chip configuration > fixed? Always the same number of i2c units with the same addresses? Or can > it vary? Maybe something like a multi-function device (drivers/mfd) would > suit your purpose well? > > In fact, I think, it shouldn't be too complicated. As suggested above, > provide (but don't register, just follow other soc-camera platforms) one > main i2c device in the platform data, register the rest in your main > probe(), which will call your further probe()s. The easiest would be to > keep just one soc-camera instance and one v4l2-subdeice, but if you want, > you can explore the possibility of creating several v4l2-subdevices. If you simply need to handle a device which several I2C addresses, you can consider one the main address, and register the secondary addresses in your probe() function using i2c_new_dummy(). See drivers/misc/eeprom/at24.c for an example of how this is done. I'm not sure I understand the problem at hand exactly though, so my advice might be inappropriate. -- Jean Delvare -- 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: Enable IR on hdpvr
>> >> I did simply try changing: >> >> /* until i2c is working properly */ >> retval = 0; /* hdpvr_register_i2c_ir(dev); */ >> if (retval < 0) >> >> so that it would register with i2c. >> Doing so returns a positive registration with I2C, but the lirc_zilog >> driver doesn't see the chip when it loads. (The lirc_zilog is now in >> the kernel, yay) >There's a bit more to it than just the one line change. Here's the patch we're >carrying in the Fedora kernels to enable it: >http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch >Janne, I've heard many success stories w/the hdpvr IR lately, and almost no >reports of lockups, so I'm thinking a firmware update may have helped out >>here, and thus, maybe its time we just go ahead and push this patch along >upstream? We still require someone to load lirc_zilog manually, so it seems >like a >fairly low-risk thing to do. Thanks. What source tree is this against? I see the patch is dated 09/2009. Manually comparing to my .37 source tree it does not appear to match up. I don't mind bringing in a third source tree to compare against to see if I can make this work on .37, I just don't know which one! -- 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/PATCH v7 01/12] media: Media device node support
Hi Greg,
On Thursday 06 January 2011 23:19:12 Greg KH wrote:
> On Fri, Dec 24, 2010 at 12:59:38PM +0100, Laurent Pinchart wrote:
> > On Thursday 23 December 2010 04:32:53 Greg KH wrote:
> > > On Mon, Dec 20, 2010 at 12:36:24PM +0100, Laurent Pinchart wrote:
> > > > +config MEDIA_CONTROLLER
> > > > + bool "Media Controller API (EXPERIMENTAL)"
> > > > + depends on EXPERIMENTAL
> > > > + ---help---
> > > > + Enable the media controller API used to query media devices
> > > > internal +topology and configure it dynamically.
> > > > +
> > > > + This API is mostly used by camera interfaces in embedded
> > > > platforms.
> > >
> > > That's nice, but why should I enable this? Or will drivers enable it
> > > automatically?
> >
> > Drivers depending on the media controller API will enable this, yes. The
> > option will probably removed later when the API won't be deemed as
> > experimental anymore.
> >
> > > > +#define MEDIA_NUM_DEVICES 256
> > >
> > > Why this limit?
> >
> > Because I'm using a bitmap to store the used minor numbers, and I thus
> > need a limit. I could get rid of it of it by using a linked list, but
> > that will not be efficient (you could argue that the list will hold a
> > few entries only most of the time, but in that case a limit of 256
> > minors wouldn't be a problem
> >
> > :-)).
>
> As it's only needed to be looked up at open() time, why not just make it
> dynamic?
How so ? With include/linux/idr.h ?
> > > > +/* Override for the open function */
> > > > +static int media_open(struct inode *inode, struct file *filp)
> > > > +{
> > > > + struct media_devnode *mdev;
> > > > + int ret;
> > > > +
> > > > + /* Check if the media device is available. This needs to be done
> > > > with + * the media_devnode_lock held to prevent an open/unregister
> > > > race: + * without the lock, the device could be unregistered and
> > > > freed between + * the media_devnode_is_registered() and
> > > > get_device() calls, leading to + * a crash.
> > > > +*/
> > > > + mutex_lock(&media_devnode_lock);
> > > > + mdev = container_of(inode->i_cdev, struct media_devnode, cdev);
> > >
> > > By virtue of having the reference to the module held by the vfs, this
> > > shouldn't ever go away, even if the lock is not held.
> >
> > inode->i_cdev is set to NULL by cdev_default_release() which can be
> > called from media_devnode_unregister(). I could move to container_of
> > outside the lock, but in that case I would have to check for mdev ==
> > NULL || !mdev_devnode_is_registered(mdev) (or move the NULL check inside
> > mdev_devnode_is_registered). Is that what you would like ?
>
> As container_of _ALWAYS_ returns a valid pointer, you can't check it for
> NULL. I don't know, it just doesn't seem correct here, but if you are sure
> it's working properly, I'll not push the issue.
I haven't found any issue with it. I'm not sure why it would be incorrect to
be honest. Am I missing something ?
> > > Then that's fine, but you can put the lock after the container_of(),
> > > right?
> >
> > If I add a NULL check (as explained above), yes.
>
> Again, you can't check for NULL as the result of container_of() that
> does not work (hint, container_of() is just pointer math, without ever
> looking at the original pointer value.)
Yes, my bad, I meant inode->i_cdev == NULL ||
!mdev_devnode_is_registered(mdev). If I moved the container_of outside of the
locked section I would need to add an extra check inside, and I don't think
the resulting locked section will get any smaller.
> > > > + /* and increase the device refcount */
> > > > + get_device(&mdev->dev);
> > >
> > > How is that holding anything into memory?
> >
> > That will prevent the device instance from being freed until the device
> > is closed, thereby holding both the device instance and the cdev
> > instance in memory.
>
> Tricky :)
Tell me about it. I've spent lots of time on this issue in V4L2 a while ago.
Fortunately refcount nightmares are getting less frequent ;-)
> > > Anyway, it looks like what you really want is an "easier" way to handle
> > > a cdev and a struct device that will export the proper information to
> > > userspace, right?
> > >
> > > Why not do this generically, fixing up the cdev interface (which really
> > > needs it) and not tie it to media devices at all, making it possible
> > > for _everyone_ to use this type of infrastructure?
> > >
> > > That seems like the better thing to do here.
> >
> > Sounds like a good idea. You're a better cdev expert than me, so could
> > you give me a few pointers ? Do you want me to create a new object that
> > will hold a struct cdev and a struct device together, or to embed the
> > device structure into the existing cdev structure ?
>
> I don't really know, all I know is that cdev is a difficult thing to
> handle at times, but not everyone who uses it needs a struct device.
> B
Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver
On 01/10/2011 10:36 AM, Oliver Endriss wrote: > From: Ralph Metzler > > Driver for the Common Interface Controller CXD2099AR. > Supports the CI of the cineS2 DVB-S2. > > For now, data is passed through '/dev/dvb/adapterX/sec0': > - Encrypted data must be written to 'sec0'. > - Decrypted data can be read from 'sec0'. > - Setup the CAM using device 'ca0'. Nack. In DVB API terms, "sec" stands for satellite equipment control, and if I remember correctly, sec0 already existed in the first versions of the API and that's why its leftovers can be abused by this driver. The interfaces for writing data are dvr0 and demux0. If they don't fit for decryption of recorded data, then they should be extended. For decryption of live data, no new user interface needs to be created. Regards, Andreas -- 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 03/16] ngene: Firmware 18 support
Oliver Endriss writes:
> + case 18:
> + size = 0;
> + fw_name = "ngene_18.fw";
> + break;
> }
>
> if (request_firmware(&fw, fw_name, &dev->pci_dev->dev) < 0) {
> @@ -1266,6 +1270,8 @@ static int ngene_load_firm(struct ngene *dev)
> ": Copy %s to your hotplug directory!\n", fw_name);
> return -1;
> }
> + if (size == 0)
> + size = fw->size;
> if (size != fw->size) {
> printk(KERN_ERR DEVICE_NAME
> ": Firmware %s has invalid size!", fw_name);
Just a stupid question: Why remove the size verification for version 18
while keeping it for the other firmware revisions?
Bjørn
--
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 5/8] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
arch/arm/mach-davinci/dm644x.c | 172 +--
arch/arm/mach-davinci/include/mach/dm644x.h | 13 ++-
2 files changed, 172 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..f2d24fb 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -5,7 +5,7 @@
*
* 2007 (c) Deep Root Systems, LLC. This file is licensed under
* the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
+ * is licensed without any warranty of any kind, whether express
* or implied.
*/
#include
@@ -590,8 +590,8 @@ static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = "vpss",
- .start = 0x01c73400,
- .end= 0x01c73400 + 0xff,
+ .start = DM644X_VPSS_REG_BASE,
+ .end= DM644X_VPSS_REG_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
};
@@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +655,138 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+ .field_inv_wa_enable = 0,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = &dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &osd_data,
+ },
+};
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = DM644X_VENC_REG_BASE,
+ .end= DM644X_VENC_REG_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+ int ret = 0;
+
+ if (NULL == vpss_clkctl_reg)
+ return -EINVAL;
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+ writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = "vpbe-v4l2",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = &vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .nu
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Mon, 2011-01-10 at 13:56 +0100, Lawrence Rust wrote: > On Mon, 2011-01-10 at 07:39 -0500, Andy Walls wrote: > You know what, life's too short. I've spent far too long on this at the > expense of far more interesting projects. Every time I put some effort > in someone says just one more thing... I get the message. With all due respect, I don't think that you do. The message is *not* "Lawrence we don't won't your patches here , because we're an exclusive club" nor "Lawrence, we don't find your time and talent valuable" All of my comments stem from *one* high level requirement: Don't break the code for existing boards - especially popular ones for which I have some level of maintenance responsibility. How you satisfy that requirement is up to you. Just as you don't have a lot of time to do all the analysis and testing to ensure that requirement is met; I don't have time to clean up every patch that doesn't meet that requirement. The time and effort you don't expend gets pushed off to me or someone else. I have tried to provide you with constructive criticism and guidance. I will not do your work for you. Regards, Andy -- 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] DVB Satellite Channel Routing support for DVB-S
Hallo Thomas, thank you for your contribution. However, I'm against applying it. On 01/10/2011 05:19 AM, Thomas Schlöter wrote: > I have developed some modifications to the 2.6.37 DVB frontend code to > support DVB satellite channel routing (aka "SCR", "Unicable", "EN50494"). > Following this standard, all satellite tuners share the same cable and each > of them has a fixed intermediate frequency it is supposed to tune to. Zapping > is done by sending a special DiSEqC message while SEC voltage is temporarily > pulled from 14 to 18 volts. This message includes the tuner's ID from 0 to 7, > the frequency, band and polarisation to tune to as well as one out of two > satellite positions. > > I decided this should be supported by the kernel frontend code as it is > impossible to send that special DiSEqC / voltage sequence from userspace. Why do you think that's impossible? There's a userspace implementation in Enigma2. > Additionally, it adds fully transparent support for SCR to arbitrary > applications that use the DVB API, such as MythTV, VDR, xine etc. That statement is not true, because you have to configure Unicable LNBs, which you do using dvb-scr-setup.c. Regards, Andreas -- 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: Debug code in HG repositories
On Mon, Jan 10, 2011 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote: > Em 07-01-2011 21:42, Theodore Kilgore escreveu: > > >> Have you tried Mauro's media_build tree? I had to use it today to test a > >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we > > should > >> promote this more. > > > > Probably a good idea. I have been too busy to know about it, myself. And I > > even do try to keep up with what is going on. > > > >> I could add backwards compatibility builds to my > > daily > >> build script that uses this in order to check for which kernel versions > >> this compiles if there is sufficient interest. ... > I think Hans can enable it. The backport effort on media-build is a way > easier than with -hg. For example, in order to support kernel 2.6.31 (the > oldest > one on that tree), we need only 10 patches. The patches themself are simple: > > $ wc -l *.patch >61 v2.6.31_nodename.patch > 540 v2.6.32_kfifo.patch >42 v2.6.33_input_handlers_are_int.patch >70 v2.6.33_pvrusb2_sysfs.patch >40 v2.6.34_dvb_net.patch >22 v2.6.34_fix_define_warnings.patch >16 v2.6.35_firedtv_handle_fcp.patch > 104 v2.6.35_i2c_new_probed_device.patch > 145 v2.6.35_work_handler.patch > 104 v2.6.36_input_getkeycode.patch > 1144 total > > And almost all patches are trivial. FWIW, linux-wireless developers maintain a generic compat tree used for backporting wireless drivers: http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary I suppose it might be useful to share this between linux-wireless and linux-media? (It is used together with three other trees to autobuild the compat-wireless releases. http://wireless.kernel.org/en/users/Download It works like that: - compat.git: generic backporting layer - compat-wireless-2.6.git: build system - compat-user.git: autobuild scripts called via cron - wireless-testing.git: linux-wireless development tree (wireless-testing.git is based on latest stable kernel but with the wireless code from linux-next) compat-wireless releases are not meant for development, but they can be used as a build system together with a wireless-testing.git tree and a few symlinks.) Johannes -- 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: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Mon, 2011-01-10 at 07:39 -0500, Andy Walls wrote: [snip] > I do see one problem with your patch at the moment: > > diff --git a/include/media/wm8775.c b/include/media/wm8775.c > ... > + sd->grp_id = WM8775_GID; /* subdev group id */ > ... > diff --git a/include/media/wm8775.h b/include/media/wm8775.h > ... > +/* subdev group ID */ > +#define WM8775_GID (1 << 0) > + > ... > > > The wm8775 module probably should not define WM8775_GID and definitely > should not set sd->grp_id. The sd->grp_id is for the bridge driver's > use for that v4l2_subdev instance. Some bridge drivers may expect it to > be 0 unless they set it themselves. The group ID values should be > defined in the bridge driver, and the sd->grp_id field should be set by > the bridge driver. > > You would want to do that in cx88. See cx23885, ivtv, and cx18 as > examples of bridge drivers that use the group id field. You know what, life's too short. I've spent far too long on this at the expense of far more interesting projects. Every time I put some effort in someone says just one more thing... I get the message. I'll just keep the patch for my personal use. For those that are interested I'll maintain a copy here: http://www.softsystem.co.uk/download/patches/nova-2.6.37.patch -- Lawrence -- 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: difference mchehab/new_build.git to media_build.git ?
Em 09-01-2011 02:01, Vincent McIntyre escreveu: >> There's no difference. It started out at mchehab/new_build.git, then got >> moved >> to media_build.git, but there's a symlink in place to keep from breaking >> things >> for people who originally checked it out at the old location. >> >> The move essentially promoted it from "something Mauro's tinkering with" to >> "something generally useful for a wider audience". And its also being worked >> on >> by more people than just Mauro now (myself included). > > Thanks for clarifying this. Doesn't this justify a one-line NEWS item? > I can understand not wanting to mention it while still experimental, but > now... I was actually waiting for someone to manifest as being the maintainer of it, before doing that announcement, but it is probably fine to add it. I can add it later, but I'm a little busy this week. So, if someone could prepare me the news text (in HTML, if possible), this would help a lot. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v13 5/8] davinci vpbe: platform specific additions
On Mon, Jan 10, 2011 at 18:21:34, Hadli, Manjunath wrote: > On Mon, Jan 10, 2011 at 17:25:33, Nori, Sekhar wrote: > > On Mon, Jan 10, 2011 at 16:58:41, Sergei Shtylyov wrote: > > > > > > + > > > > +#define OSD_REG_SIZE 0x01ff > > > > +#define VENC_REG_SIZE 0x017f > > > > > > Well, actually that's not the size but "limit" -- sizes should be > > > 0x200 and 0x180 respectively... > > > > In most resource definitions on DaVinci, these are not even #defined. Just > > add the limit directly to the base to derive the .end > > > > Thanks, > > Sekhar > > > Ok. I shall keep the numbers as is. Thanks. You can look at some existing resource definitions in arch/arm/mach-davinci/devices.c to see the format being used. Regards, Sekhar -- 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: difference mchehab/new_build.git to media_build.git ?
Em 09-01-2011 16:23, CityK escreveu: > vincent.mcintyre wrote: >> Thanks for clarifying this. Doesn't this justify a one-line NEWS item? >> I can understand not wanting to mention it while still experimental, but >> now... > > Last night (well, actually the wee wee hours of this morning), I took the > time to: > - add a news announcement regarding media_build on the front page of the wiki > - update the > http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > article accordingly Thanks for the changes! You can add a "more advanced" approach. That's what I currently do here: $ git clone git://linuxtv.org/media_build.git $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git media_tree $ cd media_tree $ git remote add linuxtv git://linuxtv.org/media_tree.git $ git remote update $ git checkout -b media-master remotes/linuxtv/staging/for_v2.6.38-rc1 $ cd ../media_build/linux $ make dir DIR=../media_tree $ cd .. The "make dir" target will associate the development git tree with the media_tree, in a way that, if you change a file or update the media_tree, the new_build scripts will sync its copy with the media_tree ones, re-applying the patches if needed, before building the targets. You should try it. It helps a lot if you need to keep your drivers in track with the upstream ones. > I suspect that what has precluded any earlier case of a widely visible > announcement being made, beyond those tidbits that have appeared on the > mailing list, is a combination of: > - the necessity for having someone actually find and take time to perform > such an administrative task > - and, amongst most, a case of general unfamiliarity with the new system > - and, a question of maintainership of the new system and whether or not its > status is still classified as experimental or has reached maturity > - and, access rights required to modify the Linuxtv proper website in regards > to these developments True. Btw, as we don't have anyone dedicated to maintain the media_build, I gave write rights to other people for the media_build tree. As I found it useful to myself, I'm also keeping it on a reasonable stable (although I only use the "make dir" way, so I probably won't notice a bug with make untar and related targets). If someone has time and interests on helping to maintaining it, please ping me. > Speaking of time, I've now expended all of mine, and then some (as per > usual), which I can devote to this matter. > Hopefully someone can take a look and correct any mistakes I've made or add > any points I've overlooked on the wiki. > As well, hopefully someone else can take care of the other parts of the > website that need to be updated. Thanks! Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v13 5/8] davinci vpbe: platform specific additions
On Mon, Jan 10, 2011 at 17:25:33, Nori, Sekhar wrote: > On Mon, Jan 10, 2011 at 16:58:41, Sergei Shtylyov wrote: > > > > + > > > +#define OSD_REG_SIZE 0x01ff > > > +#define VENC_REG_SIZE0x017f > > > > Well, actually that's not the size but "limit" -- sizes should be > > 0x200 and 0x180 respectively... > > In most resource definitions on DaVinci, these are not even #defined. Just > add the limit directly to the base to derive the .end > > Thanks, > Sekhar > Ok. I shall keep the numbers as is. Thanks, -Manju -- 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
[RFC V9 6/7] drivers:media:radio: wl128x: Kconfig & Makefile for wl128x driver
From: Manjunatha Halli Signed-off-by: Manjunatha Halli --- drivers/media/radio/wl128x/Kconfig | 17 + drivers/media/radio/wl128x/Makefile |6 ++ 2 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/Kconfig create mode 100644 drivers/media/radio/wl128x/Makefile diff --git a/drivers/media/radio/wl128x/Kconfig b/drivers/media/radio/wl128x/Kconfig new file mode 100644 index 000..749f67b --- /dev/null +++ b/drivers/media/radio/wl128x/Kconfig @@ -0,0 +1,17 @@ +# +# TI's wl128x FM driver based on TI's ST driver. +# +menu "Texas Instruments WL128x FM driver (ST based)" +config RADIO_WL128X + tristate "Texas Instruments WL128x FM Radio" + depends on VIDEO_V4L2 && RFKILL + select TI_ST + help + Choose Y here if you have this FM radio chip. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux 2 API. Information on + this API and pointers to "v4l2" programs may be found at + . + +endmenu diff --git a/drivers/media/radio/wl128x/Makefile b/drivers/media/radio/wl128x/Makefile new file mode 100644 index 000..32a0ead --- /dev/null +++ b/drivers/media/radio/wl128x/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for TI's shared transport driver based wl128x +# FM radio. +# +obj-$(CONFIG_RADIO_WL128X) += fm_drv.o +fm_drv-objs:= fmdrv_common.o fmdrv_rx.o fmdrv_tx.o fmdrv_v4l2.o -- 1.5.6.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
[RFC V9 1/7] drivers:media:radio: wl128x: fmdrv common header file
From: Manjunatha Halli
These are common headers used in FM submodules (FM V4L2,
FM common, FM Rx,and FM TX).
Signed-off-by: Manjunatha Halli
---
drivers/media/radio/wl128x/fmdrv.h | 242
1 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv.h
diff --git a/drivers/media/radio/wl128x/fmdrv.h
b/drivers/media/radio/wl128x/fmdrv.h
new file mode 100644
index 000..4cb527d
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv.h
@@ -0,0 +1,242 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ *
+ * Common header for all FM driver sub-modules.
+ *
+ * Copyright (C) 2011 Texas Instruments
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FM_DRV_VERSION"0.09"
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME "ti_fmdrv"
+#define FM_DRV_CARD_SHORT_NAME"TI FM Radio"
+#define FM_DRV_CARD_LONG_NAME "Texas Instruments FM Radio"
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING 1
+#define FM_FW_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY 4
+#define FM_AF_SWITCH_INPROGRESS 5
+#define FM_CORE_TX_XMITING 6
+
+#define FM_TUNE_COMPLETE 0x1
+#define FM_BAND_LIMIT0x2
+
+#define FM_DRV_TX_TIMEOUT (5*HZ) /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+#define fmerr(format, ...) \
+printk(KERN_ERR "fmdrv: " format,## __VA_ARGS__)
+#ifdef DEBUG
+#define fmdbg(format, ...) \
+printk(KERN_DEBUG "fmdrv: " format,## __VA_ARGS__)
+#else /* DEBUG */
+#define fmdbg(format, ...)
+#endif
+enum {
+ FM_MODE_OFF,
+ FM_MODE_TX,
+ FM_MODE_RX,
+ FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX 8 /* 4 Group * 2 Bytes */
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+ union {
+ struct {
+ u8 buff[FM_RX_RDS_INFO_FIELD_MAX];
+ } groupdatabuff;
+ struct {
+ u16 pidata;
+ u8 blk_b[2];
+ u8 blk_c[2];
+ u8 blk_d[2];
+ } groupgeneral;
+ struct {
+ u16 pidata;
+ u8 blk_b[2];
+ u8 af[2];
+ u8 ps[2];
+ } group0A;
+ struct {
+ u16 pi[2];
+ u8 blk_b[2];
+ u8 ps[2];
+ } group0B;
+ } data;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+ u32 chanl_space;
+ u32 bot_freq;
+ u32 top_freq;
+ u8 fm_band;
+};
+struct fmdev;
+typedef void (*int_handler_prototype) (struct fmdev *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+ u8 stage;
+ u16 flag; /* FM interrupt flag */
+ u16 mask; /* FM interrupt mask */
+ /* Interrupt process timeout handler */
+ struct timer_list timer;
+ u8 retry;
+ int_handler_prototype *handlers;
+};
+
+/* RDS info */
+struct fm_rds {
+ u8 flag;/* RX RDS on/off status */
+ u8 last_blk_idx;/* Last received RDS block */
+
+ /* RDS buffer */
+ wait_queue_head_t read_queue;
+ u32 buf_size; /* Size is always multiple of 3 */
+ u32 wr_idx;
+ u32 rd_idx;
+ u8 *buff;
+};
+
+#define FM_RDS_MAX_AF_LIST 25
+
+/*
+ * Current RX channel Alternate Frequency cache.
+ * This info is used to switch to other freq (AF)
+ * when current channel signal strengh is below RSSI threshold.
+ */
+struct tuned_station_info {
+ u16 picode;
+ u32 af_cache[FM_RDS_MAX_AF_LIST];
+ u8 afcache_size;
+ u8 af_list_max;
+};
+
+/* FM RX mode info */
+struct fm_rx {
+ struct region_info region; /* Current selected band */
+ u32 freq; /* Current RX frq
[RFC V9 5/7] drivers:media:radio: wl128x: FM driver TX sources
From: Manjunatha Halli
This has implementation for FM TX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli
---
drivers/media/radio/wl128x/fmdrv_tx.c | 433 +
drivers/media/radio/wl128x/fmdrv_tx.h | 37 +++
2 files changed, 470 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h
diff --git a/drivers/media/radio/wl128x/fmdrv_tx.c
b/drivers/media/radio/wl128x/fmdrv_tx.c
new file mode 100644
index 000..b66f535
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_tx.c
@@ -0,0 +1,433 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM TX functionality.
+ *
+ * Copyright (C) 2011 Texas Instruments
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_tx.h"
+
+u32 fm_tx_set_stereo_mono(struct fmdev *fmdev, u16 mode)
+{
+ u16 payload;
+ u32 ret = 0;
+
+ if (fmdev->curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ if (fmdev->tx_data.aud_mode == mode)
+ return ret;
+
+ fmdbg("stereo mode: %d\n", mode);
+
+ /* Set Stereo/Mono mode */
+ payload = (1 - mode);
+ ret = fmc_send_cmd(fmdev, MONO_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ fmdev->tx_data.aud_mode = mode;
+
+ return ret;
+}
+
+static u32 set_rds_text(struct fmdev *fmdev, u8 *rds_text)
+{
+ u16 payload;
+ u32 ret;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_SET, REG_WR, rds_text,
+ strlen(rds_text), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Scroll mode */
+ payload = (u16)0x1;
+ ret = fmc_send_cmd(fmdev, DISPLAY_MODE, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static u32 set_rds_data_mode(struct fmdev *fmdev, u8 mode)
+{
+ u16 payload;
+ u32 ret;
+
+ /* Setting unique PI TODO: how unique? */
+ payload = (u16)0xcafe;
+ ret = fmc_send_cmd(fmdev, PI_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Set decoder id */
+ payload = (u16)0xa;
+ ret = fmc_send_cmd(fmdev, DI_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* TODO: RDS_MODE_GET? */
+ return 0;
+}
+
+static u32 set_rds_len(struct fmdev *fmdev, u8 type, u16 len)
+{
+ u16 payload;
+ u32 ret;
+
+ len |= type << 8;
+ payload = len;
+ ret = fmc_send_cmd(fmdev, RDS_CONFIG_DATA_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* TODO: LENGTH_GET? */
+ return 0;
+}
+
+u32 fm_tx_set_rds_mode(struct fmdev *fmdev, u8 rds_en_dis)
+{
+ u16 payload;
+ u32 ret;
+ u8 rds_text[] = "Zoom2\n";
+
+ if (fmdev->curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ fmdbg("rds_en_dis:%d(E:%d, D:%d)\n", rds_en_dis,
+ FM_RDS_ENABLE, FM_RDS_DISABLE);
+
+ if (rds_en_dis == FM_RDS_ENABLE) {
+ /* Set RDS length */
+ set_rds_len(fmdev, 0, strlen(rds_text));
+
+ /* Set RDS text */
+ set_rds_text(fmdev, rds_text);
+
+ /* Set RDS mode */
+ set_rds_data_mode(fmdev, 0x0);
+ }
+
+ /* Send command to enable RDS */
+ if (rds_en_dis == FM_RDS_ENABLE)
+ payload = 0x01;
+ else
+ payload = 0x00;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_ENB, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ if (rds_en_dis == FM_RDS_ENABLE) {
+ /* Set RDS length */
+ set_rds_len(fmdev, 0, strlen(rds_text));
+
+ /* Set RDS text */
+ set_rds_text(fmdev, rds_text);
+ }
+ fmdev->tx_data.rds.
[RFC V9 0/7] FM V4L2 drivers for WL128x
From: Manjunatha Halli Mauro and the list, This is the v9 version of the TI WL128x FM V4L2 drivers patchset. This introduces wl128x folder under the drivers/media/radio which cater to FM core on Texas Instrument's WL128x (also compatible with WL127x) WiLink chipsets. WL128x's FM can work in either Rx or Tx mode, and V4L2 interfaces are provided for both. ** patch description ** Texas Instrument's WL128x chipset packs BT, FM, GPS and WLAN in a single die with BT, FM and GPS being interfaced over a single UART. This driver works on top of the shared transport line discipline driver. This driver can also be made use for the WL127x version of the chip which packs BT, FM and WLAN only. Comments on the last version of the patches have been taken care, such as, - using the 'early return' constructs where applicable. - Renaming all the variables based on scope and frequency of use. - Use of 'temp' pointers wherever required insted of breaking the lines. - printing the error messages at the lowest level,and just propagate the error code up without repeating the error message. Thanks & Regards, Manjunatha Halli Manjunatha Halli (7): drivers:media:radio: wl128x: fmdrv common header file drivers:media:radio: wl128x: FM Driver V4L2 sources drivers:media:radio: wl128x: FM Driver Common sources drivers:media:radio: wl128x: FM driver RX sources drivers:media:radio: wl128x: FM driver TX sources drivers:media:radio: wl128x: Kconfig & Makefile for wl128x driver drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver. drivers/media/radio/Kconfig |3 + drivers/media/radio/Makefile |1 + drivers/media/radio/wl128x/Kconfig| 17 + drivers/media/radio/wl128x/Makefile |6 + drivers/media/radio/wl128x/fmdrv.h| 242 drivers/media/radio/wl128x/fmdrv_common.c | 1693 + drivers/media/radio/wl128x/fmdrv_common.h | 402 +++ drivers/media/radio/wl128x/fmdrv_rx.c | 876 +++ drivers/media/radio/wl128x/fmdrv_rx.h | 59 + drivers/media/radio/wl128x/fmdrv_tx.c | 433 drivers/media/radio/wl128x/fmdrv_tx.h | 37 + drivers/media/radio/wl128x/fmdrv_v4l2.c | 594 ++ drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 + 13 files changed, 4396 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/Kconfig create mode 100644 drivers/media/radio/wl128x/Makefile create mode 100644 drivers/media/radio/wl128x/fmdrv.h create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h -- 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
[RFC V9 2/7] drivers:media:radio: wl128x: FM Driver V4L2 sources
From: Manjunatha Halli
This module interfaces V4L2 subsystem and FM common module.
It registers itself with V4L2 as Radio module.
Signed-off-by: Manjunatha Halli
---
drivers/media/radio/wl128x/fmdrv_v4l2.c | 594 +++
drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 ++
2 files changed, 627 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
new file mode 100644
index 000..9eb20e9
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -0,0 +1,594 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This file provides interfaces to V4L2 subsystem.
+ *
+ * This module registers with V4L2 subsystem as Radio
+ * data system interface (/dev/radio). During the registration,
+ * it will expose two set of function pointers.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Raja Mani
+ * Author: Manjunatha Halli
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_v4l2.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+#include "fmdrv_tx.h"
+
+static struct video_device *gradio_dev;
+static u8 radio_disconnected;
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ u8 rds_mode;
+ int ret;
+ struct fmdev *fmdev;
+
+ fmdev = video_drvdata(file);
+
+ if (!radio_disconnected) {
+ fmerr("FM device is already disconnected\n");
+ return -EIO;
+ }
+
+ /* Turn on RDS mode , if it is disabled */
+ ret = fm_rx_get_rds_mode(fmdev, &rds_mode);
+ if (ret < 0) {
+ fmerr("Unable to read current rds mode\n");
+ return ret;
+ }
+
+ if (rds_mode == FM_RDS_DISABLE) {
+ ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+ if (ret < 0) {
+ fmerr("Failed to enable rds mode\n");
+ return ret;
+ }
+ }
+
+ /* Copy RDS data from internal buffer to user buffer */
+ ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+
+ return ret;
+}
+
+/* Write TX RDS data */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ struct tx_rds rds;
+ int ret;
+ struct fmdev *fmdev;
+
+ ret = copy_from_user(&rds, buf, sizeof(rds));
+ fmdbg("(%d)type: %d, text %s, af %d\n",
+ ret, rds.text_type, rds.text, rds.af_freq);
+
+ fmdev = video_drvdata(file);
+ fm_tx_set_radio_text(fmdev, rds.text, rds.text_type);
+ fm_tx_set_af(fmdev, rds.af_freq);
+
+ return 0;
+}
+
+static u32 fm_v4l2_fops_poll(struct file *file, struct poll_table_struct *pts)
+{
+ int ret;
+ struct fmdev *fmdev;
+
+ fmdev = video_drvdata(file);
+ ret = fmc_is_rds_data_available(fmdev, file, pts);
+ if (ret < 0)
+ return POLLIN | POLLRDNORM;
+
+ return 0;
+}
+
+/*
+ * Handle open request for "/dev/radioX" device.
+ * Start with FM RX mode as default.
+ */
+static int fm_v4l2_fops_open(struct file *file)
+{
+ int ret;
+ struct fmdev *fmdev = NULL;
+
+ /* Don't allow multiple open */
+ if (radio_disconnected) {
+ fmerr("FM device is already opened\n");
+ return -EBUSY;
+ }
+
+ fmdev = video_drvdata(file);
+
+ ret = fmc_prepare(fmdev);
+ if (ret < 0) {
+ fmerr("Unable to prepare FM CORE\n");
+ return ret;
+ }
+
+ fmdbg("Load FM RX firmware..\n");
+
+ ret = fmc_set_mode(fmdev, FM_MODE_RX);
+ if (ret < 0) {
+ fmerr("Unable to load FM RX firmware\n");
+ return ret;
+ }
+ radio_disconnected = 1;
+
+ return ret;
+}
+
+static int fm_v4l2_fops_release(struct file *file)
+{
[RFC V9 4/7] drivers:media:radio: wl128x: FM driver RX sources
From: Manjunatha Halli
This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module
Signed-off-by: Manjunatha Halli
---
drivers/media/radio/wl128x/fmdrv_rx.c | 876 +
drivers/media/radio/wl128x/fmdrv_rx.h | 59 +++
2 files changed, 935 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c
create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h
diff --git a/drivers/media/radio/wl128x/fmdrv_rx.c
b/drivers/media/radio/wl128x/fmdrv_rx.c
new file mode 100644
index 000..c2cb213
--- /dev/null
+++ b/drivers/media/radio/wl128x/fmdrv_rx.c
@@ -0,0 +1,876 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM RX functionality.
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Raja Mani
+ * Author: Manjunatha Halli
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+
+void fm_rx_reset_rds_cache(struct fmdev *fmdev)
+{
+ fmdev->rx.rds.flag = FM_RDS_DISABLE;
+ fmdev->rx.rds.last_blk_idx = 0;
+ fmdev->rx.rds.wr_idx = 0;
+ fmdev->rx.rds.rd_idx = 0;
+
+ if (fmdev->rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+ fmdev->irq_info.mask |= FM_LEV_EVENT;
+}
+
+void fm_rx_reset_station_info(struct fmdev *fmdev)
+{
+ fmdev->rx.stat_info.picode = FM_NO_PI_CODE;
+ fmdev->rx.stat_info.afcache_size = 0;
+ fmdev->rx.stat_info.af_list_max = 0;
+}
+
+u32 fm_rx_set_freq(struct fmdev *fmdev, u32 freq)
+{
+ unsigned long timeleft;
+ u16 payload, curr_frq, frq_index, intr_flag;
+ u32 curr_frq_in_khz;
+ u32 ret, resp_len;
+
+ if (fmdev->curr_fmmode != FM_MODE_RX)
+ return -EPERM;
+
+ if (freq < fmdev->rx.region.bot_freq || freq >
fmdev->rx.region.top_freq) {
+ fmerr("Invalid frequency %d\n", freq);
+ return -EINVAL;
+ }
+
+ /* Set audio enable */
+ payload = FM_RX_AUDIO_ENABLE_I2S_AND_ANALOG;
+
+ ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Set hilo to automatic selection */
+ payload = FM_RX_IFFREQ_HILO_AUTOMATIC;
+ ret = fmc_send_cmd(fmdev, HILO_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Calculate frequency index to write */
+ frq_index = (freq - fmdev->rx.region.bot_freq) / FM_FREQ_MUL;
+
+ /* Set frequency index */
+ payload = frq_index;
+ ret = fmc_send_cmd(fmdev, FREQ_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Read flags - just to clear any pending interrupts if we had */
+ ret = fmc_send_cmd(fmdev, FLAG_GET, REG_RD, NULL, 2, NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Enable FR, BL interrupts */
+ intr_flag = fmdev->irq_info.mask;
+ fmdev->irq_info.mask = (FM_FR_EVENT | FM_BL_EVENT);
+ payload = fmdev->irq_info.mask;
+ ret = fmc_send_cmd(fmdev, INT_MASK_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Start tune */
+ payload = FM_TUNER_PRESET_MODE;
+ ret = fmc_send_cmd(fmdev, TUNER_MODE_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ goto exit;
+
+ /* Wait for tune ended interrupt */
+ init_completion(&fmdev->maintask_comp);
+ timeleft = wait_for_completion_timeout(&fmdev->maintask_comp,
+ FM_DRV_TX_TIMEOUT);
+ if (!timeleft) {
+ fmerr("Timeout(%d sec),didn't get tune ended int\n",
+ jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000);
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+
+ /* Read freq back to confirm */
+ ret = fmc_send_cmd(fmdev, FREQ_SET, REG_RD, NULL, 2, &curr_frq,
&resp_len);
+ if (ret < 0)
+ goto exit;
+
+ curr_frq = be16_to_cpu(curr_frq);
+ curr_frq_in
[RFC V9 7/7] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver.
From: Manjunatha Halli Signed-off-by: Manjunatha Halli --- drivers/media/radio/Kconfig |3 +++ drivers/media/radio/Makefile |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 83567b8..4529bc7 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -452,4 +452,7 @@ config RADIO_TIMBERDALE found behind the Timberdale FPGA on the Russellville board. Enabling this driver will automatically select the DSP and tuner. +# TI's ST based wl128x FM radio +source "drivers/media/radio/wl128x/Kconfig" + endif # RADIO_ADAPTERS diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index f615583..b71f448 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o +obj-$(CONFIG_RADIO_WL128X) += wl128x/ EXTRA_CFLAGS += -Isound -- 1.5.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Sat, 2011-01-08 at 19:45 +0100, Lawrence Rust wrote: > On Sat, 2011-01-08 at 09:22 -0500, Andy Walls wrote: > Thanks for the info on the PVR-150. It largely confirmed what I had > surmised - that the two cards disagree about serial audio data format. > Before my patch, the wm8775 was programmed for Philips mode but the > CX25843 on the PVR-150 is setup for Sony I2S mode!! On the Nova-S, the > cx23883 is setup (in cx88-tvaudio.c) for Philips mode. The patch > changed the wm8775 to Sony I2S mode because the existing setup gave > noise, indicative of a mismatch. > > It is my belief that either the wm8775 datasheet is wrong or there are > inverters on the SCLK lines between the wm8775 and cx25843/23883. It is > also plausible that Conexant have it wrong and both their datasheets are > wrong. > > Anyway, I have revised the patch (attached) so that the wm8775 is kept > in Philips mode (to please the PVR-150) and the cx23883 on the Nove-S is > now switched to Sony I2S mode (like the PVR-150) and this works fine. I will try and review and test this coming weekend. > The change is trivial, just 2 lines, so they're shouldn't be any other > consequences. However, could this affect any other cards? That is the problem with code reuse, for multiple board models, in all the I2C modules. It makes code increasingly more difficult to maintain as more different board models are supported and tested. But now there is infrastructure in place to pass board specific info down to the I2C v4l2_subdevice drivers. If the wm8775 driver were changed to provide a wm8775-specific platform-data structure for bridge drivers to use, bridge drivers could fill it out and call v4l2_i2c_new_subdev_board() to instantiate the wm8775 device instance specific to the board: Nova-S, PVR-150, or whatever. See the interaction between the ivtv and cx25840 module in this patch as an example: https://patchwork.kernel.org/patch/465571/ (Not all of the details are visible in the patch, since some were already there for the .s_config call in cx25840.) Obviously, the wm8775 module would need code added to take different actions when passed different platform data. However, that the best way to make sure one doesn't accidentally affect other boards. > NB I have only tested this patch on my Nova-S, no other. I do see one problem with your patch at the moment: diff --git a/include/media/wm8775.c b/include/media/wm8775.c ... + sd->grp_id = WM8775_GID; /* subdev group id */ ... diff --git a/include/media/wm8775.h b/include/media/wm8775.h ... +/* subdev group ID */ +#define WM8775_GID (1 << 0) + ... The wm8775 module probably should not define WM8775_GID and definitely should not set sd->grp_id. The sd->grp_id is for the bridge driver's use for that v4l2_subdev instance. Some bridge drivers may expect it to be 0 unless they set it themselves. The group ID values should be defined in the bridge driver, and the sd->grp_id field should be set by the bridge driver. You would want to do that in cx88. See cx23885, ivtv, and cx18 as examples of bridge drivers that use the group id field. Regards, Andy -- 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: Enable IR on hdpvr
On Mon, Jan 10, 2011 at 01:05:10AM -0500, Jarod Wilson wrote: > > There's a bit more to it than just the one line change. Here's the patch we're > carrying in the Fedora kernels to enable it: > > http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch > > Janne, I've heard many success stories w/the hdpvr IR lately, and almost no > reports > of lockups, so I'm thinking a firmware update may have helped out here, and > thus, > maybe its time we just go ahead and push this patch along upstream? We still > require someone to load lirc_zilog manually, so it seems like a fairly > low-risk > thing to do. Ack, go ahead. I haven't checked IR for a long time. Janne -- 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: Debug code in HG repositories
Em 07-01-2011 23:02, Vincent McIntyre escreveu: > On 1/8/11, Hans Verkuil wrote: > >> Have you tried Mauro's media_build tree? I had to use it today to test a >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should >> promote this more. I could add backwards compatibility builds to my daily >> build script that uses this in order to check for which kernel versions >> this compiles if there is sufficient interest. >> > > As an end-user I would be interested in seeing this added, since it > will allow faster detection of breakage in the older versions. For > instance building against 2.6.32 fails like this: > > CC [M] /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o > /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In > function 'hdpvr_new_i2c_ir': > /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error: > too many arguments to function 'i2c_new_probed_device' > make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o] > Error 1 > make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2 > make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic' > make[2]: *** [default] Error 2 > make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build' > make: *** [default] Error 2 > > It's unclear that adding this would cause a lot of extra work; the > patches that need to be applied are quite few - a tribute to the > design work! That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a patch that removes the extra parameter. I'll double check and add a fix if I found something wrong. > For what it's worth, I've attached the shell script I use to pull > updates and do a new build. > Doing the initial setup is well explained by the > linuxtv.org/media_tree.git page, > but this script may be of use to end users wanting to track development. Thanks for your script, but it seems specific to your environment. Could you please make it more generic and perhaps patch the existing build.sh script? It would be nice to have some optional parameters there, to make life easier for end-users. Thanks! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debug code in HG repositories
Em 10-01-2011 10:04, Mauro Carvalho Chehab escreveu:
> Em 07-01-2011 21:56, Oliver Endriss escreveu:
>> On Friday 07 January 2011 22:06:30 Hans Verkuil wrote:
>>> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote:
On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss wrote:
> Hi guys,
>
> are you aware that there is a lot of '#if 0' code in the HG repositories
> which is not in GIT?
> As a reference and further discussions, I'm enclosing the diff.
It is now easier to comment on what we have inside the #if 0 code. Let me add
my comments about that.
A general comment after my review is that most of the commented code should
be just discarded, but I agree with Oliver that there are some things there
that we want to preserve.
>
> ---
>
> diff -upr /tmp/stripped/drivers/media/common/tuners/tea5767.c
> /tmp/not_stripped/drivers/media/common/tuners/tea5767.c
> --- /tmp/stripped/drivers/media/common/tuners/tea5767.c 2011-01-10
> 10:01:50.0 -0200
> +++ /tmp/not_stripped/drivers/media/common/tuners/tea5767.c 2011-01-10
> 10:02:06.0 -0200
> @@ -371,6 +371,9 @@ int tea5767_autodetection(struct i2c_ada
> struct tuner_i2c_props i2c = { .adap = i2c_adap, .addr = i2c_addr };
> unsigned char buffer[7] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
> int rc;
> +#if 0 /* Needed if uncomment I2C send code below */
> + int div;
> +#endif
>
> if ((rc = tuner_i2c_xfer_recv(&i2c, buffer, 7))< 5) {
> printk(KERN_WARNING "It is not a TEA5767. Received %i
> bytes.\n", rc);
> @@ -394,7 +397,42 @@ int tea5767_autodetection(struct i2c_ada
> return -EINVAL;
> }
>
> +#if 0/* Not working for TEA5767 in Beholder Columbus card */
> + /* It seems that tea5767 returns 0xff after the 5th byte */
> + if ((buffer[5] != 0xff) || (buffer[6] != 0xff)) {
> + printk(KERN_WARNING "Returned more than 5 bytes. It is not a
> TEA5767\n");
> + return -EINVAL;
> + }
> +#endif
> +
> +#if 0 /*Sometimes, this code doesn't work */
> + /* Sets tuner at some freq (87.5 MHz) and see if it is ok */
> + div = ((87500 * 4000 + 70 + 225000) + 16768) >> 15;
> + buffer[0] = ((div >> 8) & 0x3f) | TEA5767_MUTE;
> + buffer[1] = div & 0xff;
> + buffer[2] = TEA5767_PORT1_HIGH;
> + buffer[3] = TEA5767_PORT2_HIGH | TEA5767_HIGH_CUT_CTRL |
> + TEA5767_ST_NOISE_CTL;
> + buffer[4] = 0;
> +
> + if (5 != (rc = tuner_i2c_xfer_send(&i2c, buffer, 5)))
> + printk(KERN_WARNING "i2c i/o error: rc == %d (should be 5)\n",
> rc);
> +
> + msleep(15);
> +
> + if (5 != (rc = tuner_i2c_xfer_recv(&i2c, buffer, 5))) {
> + printk(KERN_WARNING "It is not a TEA5767. Received %i
> bytes.\n", rc);
> + return -EINVAL;
> + }
>
> + /* Initial freq for 32.768KHz clock */
> + if ((buffer[1] != (div & 0xff) ) || ((buffer[0] & 0x3f) != ((div >> 8)
> & 0x3f))) {
> + printk(KERN_WARNING "It is not a TEA5767. div=%d, Return: %02x
> %02x %02x %02x %02x\n",
> +
> div,buffer[0],buffer[1],buffer[2],buffer[3],buffer[4]);
> + tea5767_status_dump(buffer);
> + return -EINVAL;
> + }
> +#endif
> return 0;
> }
>
> @@ -443,6 +481,10 @@ struct dvb_frontend *tea5767_attach(stru
> {
> struct tea5767_priv *priv = NULL;
>
> +#if 0 /* By removing autodetection allows forcing TEA chip */
> + if (tea5767_autodetection(i2c_adap, i2c_addr) == -EINVAL)
> + return -EINVAL;
> +#endif
> priv = kzalloc(sizeof(struct tea5767_priv), GFP_KERNEL);
> if (priv == NULL)
> return NULL;
All the #if 0 code there are obsolete. The detection tests
were moved to other place.
> diff -upr /tmp/stripped/drivers/media/common/tuners/tuner-simple.c
> /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c
> --- /tmp/stripped/drivers/media/common/tuners/tuner-simple.c 2011-01-10
> 10:01:50.0 -0200
> +++ /tmp/not_stripped/drivers/media/common/tuners/tuner-simple.c
> 2011-01-10 10:02:06.0 -0200
> @@ -161,6 +161,12 @@ static inline int tuner_afcstatus(const
> return (status & TUNER_AFC) - 2;
> }
>
> +#if 0 /* unused */
> +static inline int tuner_mode(const int status)
> +{
> + return (status & TUNER_MODE) >> 3;
> +}
> +#endif
>
> static int simple_get_status(struct dvb_frontend *fe, u32 *status)
> {
No idea about that. Too old for me to remember, but I don't think
we should backport it.
> diff -upr /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c
> /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c
> --- /tmp/stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10
> 10:01:49.0 -0200
> +++ /tmp/not_stripped/drivers/media/dvb/ngene/ngene-cards.c 2011-01-10
> 10:02:05.0 -0200
> @@ -272,6 +272,32 @@ static const struct pci_device_id ngene_
> NGENE_ID(0x18c3, 0xdd1
Maybe I'll hack on lirc_zilog.c this coming weekend (Re: Enable IR on hdpvr)
On Mon, 2011-01-10 at 01:05 -0500, Jarod Wilson wrote: > On Jan 9, 2011, at 7:36 PM, Jason Gauthier wrote: > There's a bit more to it than just the one line change. Here's the patch we're > carrying in the Fedora kernels to enable it: > > http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch > BTW, I plan to work on lirc_zilog.c this coming weekend, with my PVR-150 and HVR-1600 as test units. If there are any lirc_zilog.c patches you have developed that are not in the media_tree.git repo, could you point me to them before then? Regards, Andy -- 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: Enable IR on hdpvr
On Mon, 2011-01-10 at 01:05 -0500, Jarod Wilson wrote: > On Jan 9, 2011, at 7:36 PM, Jason Gauthier wrote: > Janne, I've heard many success stories w/the hdpvr IR lately, and almost no > reports > of lockups, so I'm thinking a firmware update may have helped out here, and > thus, > maybe its time we just go ahead and push this patch along upstream? We still > require someone to load lirc_zilog manually, so it seems like a fairly > low-risk > thing to do. FYI, the code I added to hdpvr-i2c.c will perform 2 accesses to the chip to check for existence, by virtue of a call to i2c_new_probed_device() (or whatever it is called). The I2C subsystem tries to talk the chip to see if it exists. If you are really concerned about corner cases that may hang, add a module option to hdpvr to disable I2C and/or IR in the hdpvr driver. With that users in the field can work-around the problem without rebuilding modules. Regards, Andy -- 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: Debug code in HG repositories
Em 07-01-2011 21:56, Oliver Endriss escreveu: > On Friday 07 January 2011 22:06:30 Hans Verkuil wrote: >> On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote: >>> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss wrote: Hi guys, are you aware that there is a lot of '#if 0' code in the HG repositories which is not in GIT? When drivers were submitted to the kernel from HG, the '#if 0' stuff was stripped, unless it was marked as 'keep'... This was fine, when development was done with HG. As GIT is being used now, that code will be lost, as soon as the HG repositories have been removed... Any opinions how this should be handled? CU Oliver >>> >>> I complained about this months ago. The problem is that when we were >>> using HG, the HG repo was a complete superset of what went into Git >>> (including development/debug code). But now that we use Git, neither >>> is a superset of the other. >>> >>> If you base your changes on Git, you have to add back in all the >>> portability code (and any "#if 0" you added as the maintainer for >>> development/debugging). Oh, and regular users cannot test any of your >>> changes because they aren't willing to upgrade their entire kernel. >>> >>> If you base your changes on Hg, nothing merges cleanly when submitted >>> upstream so your patches get rejected. >>> >>> Want to know why we are seeing regressions all over the place? >>> Because *NOBODY* is testing the code until after the kernel goes >>> stable (since while many are willing to install a v4l-dvb tree, very >>> few will are willing to upgrade their entire kernel just to test one >>> driver). We've probably lost about 98% of our user base of testers. >> >> Have you tried Mauro's media_build tree? I had to use it today to test a >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should >> promote this more. I could add backwards compatibility builds to my daily >> build script that uses this in order to check for which kernel versions >> this compiles if there is sufficient interest. >> >>> Oh, and users have to git clone 500M+ of data, and not everybody in >>> the world has bandwidth fast enough to make that worth their time (it >>> took me several hours last time I did it). >> >> Currently the media_build tree copies the drivers from a git tree. Which, as >> you say, can be a big problem for non-developers. But all it really needs are >> the media drivers. So perhaps it might be a good idea to make a daily >> snapshot >> of the drivers and make it available for download on linuxtv.org. That >> archive >> is only 3.5 MB, so much easier to download. >> >>> Anyway, I've beaten this horse to death and it's fallen on deaf ears. >>> Merge overhead has reached the point where it's just not worth my >>> time/effort to submit anything upstream anymore. >> >> The hg tree is dead. Douglas Landgraf tried to maintain it, but it's just too >> much work. Any attempt to work from the hg tree is doomed. The media_build >> seems to be a viable alternative. As a developer you still have to go through >> the painful process of cloning the git repo, but it is a one time thing. Once >> it's cloned then you only have to follow the new commits, which is much, much >> faster. >> >> And regarding regressions: I'm amazed how few regressions we have considering >> the furious rate of development. The media subsystem is still one of the most >> active subsystems in the kernel and probably will remain so for the >> forseeable >> future as well. > > Regressions can be detected only if you have enough testers! > > With the current situation, it is very likely that regressions will not > show up before major linux distributions switch to a new kernel. > Afaics the user base is neglectible at the moment. So you can expect > that regressions will show up months after release of a new kernel. Fedora code is released on every 6 months, generally with the newest code from V4L/DVB. Fedora rawhide always have the latest kernel. I'm sure that other distros have similar development procedures. So, even if nobody is using media_build.git, there are many users with access to the latest code, that come to them via distros. There are very few regressions reported. Of course, it would be great if more people start using media_build.git, as we'll have more testers. > > Anyway, this is off-topic. I was not talking about regressions. > >> It would be a shame not to submit patches upstream, that never ends well in >> the long run. >> >> With respect to '#if 0': for the most part I'd say: good riddance. In my >> many years of experience as a SW engineer I have never seen anyone actually >> turn on '#if 0' code once it's been in the code for more than, say, a year. >> Usually people just leave it there because they are too lazy to remove it, >> or they don't understand what it is for and are too scared to remove it. >> >> If it is code partial
RE: [PATCH v13 5/8] davinci vpbe: platform specific additions
On Mon, Jan 10, 2011 at 16:58:41, Sergei Shtylyov wrote: > > + > > +#define OSD_REG_SIZE 0x01ff > > +#define VENC_REG_SIZE 0x017f > > Well, actually that's not the size but "limit" -- sizes should be 0x200 > and 0x180 respectively... In most resource definitions on DaVinci, these are not even #defined. Just add the limit directly to the base to derive the .end Thanks, Sekhar -- 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: Debug code in HG repositories
Em 07-01-2011 21:42, Theodore Kilgore escreveu: >> Have you tried Mauro's media_build tree? I had to use it today to test a >> driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we > should >> promote this more. > > Probably a good idea. I have been too busy to know about it, myself. And I > even do try to keep up with what is going on. > >> I could add backwards compatibility builds to my > daily >> build script that uses this in order to check for which kernel versions >> this compiles if there is sufficient interest. > > Nice, but don't bust your behind with a thing like that. Back when we were > discussing the idea of getting off of hg and onto git, I suggested > approximately the previous three minor versions of the kernel, no > more. And if there was a serious problem with 2.(current_release - 1) or > 2.(current_release - 2) such as instability or security issues, whatever, > then just drop that one. I think that to do this is reasonable if you or > anyone else has the time and needed skills. More than this is not > reasonable under any circumstances. I think Hans can enable it. The backport effort on media-build is a way easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest one on that tree), we need only 10 patches. The patches themself are simple: $ wc -l *.patch 61 v2.6.31_nodename.patch 540 v2.6.32_kfifo.patch 42 v2.6.33_input_handlers_are_int.patch 70 v2.6.33_pvrusb2_sysfs.patch 40 v2.6.34_dvb_net.patch 22 v2.6.34_fix_define_warnings.patch 16 v2.6.35_firedtv_handle_fcp.patch 104 v2.6.35_i2c_new_probed_device.patch 145 v2.6.35_work_handler.patch 104 v2.6.36_input_getkeycode.patch 1144 total And almost all patches are trivial. > Now, as to the question of switching over to and using git, here are my > recent personal experiences: > > I started to do this switch-over only about a month ago, having been too > busy for several months previous due to an illness in the family. I found > that everything had changed in the meantime, and the hg trees had gone > away. > > Issue 0: This issue came up just as I was deciding to switch from 32 to 64 > bit computing, so a lot of other stuff needed to be fixed or upgraded at > the same time. I was busy. Well, lots of people are busy, and for lots of > reasons. > > Issue 1: Which git tree? For someone who is going to get in at the > beginning, this is not obvious. This issue got solved, of course, but it > was the first one to face. For an outsider, I suspect that even this is > somewhat intimidating. It is now well-indicated at the top of the git page at linuxtv.org. > Issue 2: Problems totally unrelated to drivers/media rendered the new > kernel unusable for very a long time, approximately a couple of weeks. I > think I can call myself experienced in kernel configuration and > compilation, and also not a total neophyte as a developer. The issue was a > rather evil interaction between the new kernel, the new X driver for the > ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in > X. It came about that if KMS was turned on then the video would cut off > completely halfway through the boot procedure, and if KMS was turned off > then I could not run X. I could use the distro kernel 2.6.35.7 and a > locally compiled 2.6.35.7 as well just fine, but I could not safely submit > a patch based on it. And my patches could not be tested against the git > kernel because I could not run the git kernel. This problem was ultimately > solved, and I was able to submit a rather small patch to add a camera to > an existing driver, on Christmas Eve. Yeah, KMS also affected me for some time on -git builds, until it become more stable. The solution I used were to not start X on my test machine during that period of time. Anyway, with media_build tree, you can compile it against your 2.6.35.7 kernel. Depending on what you're doing, this should be ok. Yet, with BKL changes, the better for developers is to use kernel 2.6.37 or upper, in orderto be sure that the driver will work properly without BKL and without any race/dead lock issue. > Issue 3: I still need to grab the git tree for libv4l and start using it. > I have not even begun this. For some of the reasons why I am behind > schedule, see previous items. You should really use it, as some webcam fixes happen there (like some sensors mounted with vflip/hflip). Fedora ships it by default, and most applications there calls it. Not sure why some distros are still not shipping it properly. > The point is, problems similar to those which hit me could hit anybody at > any time and "anybody" means exactly what it says. This was not the first > time that I have installed a development kernel. It was the first time I > had any serious problems after doing so. Now, it is also true that after I > finally got the issues worked through I was pleased with the results and > would still run
Re: [PATCH v13 5/8] davinci vpbe: platform specific additions
Hello. On 10-01-2011 13:23, Manjunath Hadli wrote: This patch implements the overall device creation for the Video display driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil [...] diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 9a2376b..3cc5f7c 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c [...] @@ -654,6 +655,138 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg) [...] + +#define VPSS_CLKCTLSYS_VPSS_CLKCTL What's the point? Why not just use SYS_VPSS_CLKCTL? diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 5a1b26d..46385e7 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h [...] @@ -40,8 +43,19 @@ #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600 #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800 +/* VPBE register base addresses */ +#define DM644X_VENC_REG_BASE 0x01C72400 +#define DM644X_OSD_REG_BASE0x01C72600 + +#define OSD_REG_SIZE 0x01ff +#define VENC_REG_SIZE 0x017f Well, actually that's not the size but "limit" -- sizes should be 0x200 and 0x180 respectively... WBR, Sergei -- 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: Debug code in HG repositories
Em 07-01-2011 19:06, Hans Verkuil escreveu: > On Friday, January 07, 2011 21:13:31 Devin Heitmueller wrote: >> On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss wrote: >>> Hi guys, >>> >>> are you aware that there is a lot of '#if 0' code in the HG repositories >>> which is not in GIT? >>> >>> When drivers were submitted to the kernel from HG, the '#if 0' stuff was >>> stripped, unless it was marked as 'keep'... >>> >>> This was fine, when development was done with HG. >>> >>> As GIT is being used now, that code will be lost, as soon as the HG >>> repositories have been removed... >>> >>> Any opinions how this should be handled? Oliver, There are some code there that it may make sense to bring back to -git and to upstream, or to convert into some of the new kernel tracing facilities, but we need to review them, as there are some codes inside the #if 0 that are simply dead code, where people were intending to use some alternative way to implement the driver, but gave up and just forgot to clean up the mess. Several of those code don't even compile today, due to the kABI changes. With respect to debug printk messages, I dunno if you've already used, but dev_dbg() functions (and other similar ones) are very interesting: depending on the way you compile your kernel, they're converted into dynamic_printk's, and they can be enabled/disabled via /sys/kernel/debug/. It is a way better than just adding normal printk's, as you can tell the kernel to enable just the debug message at some line. For example: $ cat /sys/kernel/debug/dynamic_debug/control |grep cx231xx /home/v4l/new_build/v4l/cx231xx-input.c:93 [cx231xx]cx231xx_ir_init - "Trying to bind ir at bus %d, addr 0x%02x\012" /home/v4l/new_build/v4l/cx231xx-input.c:57 [cx231xx]cx231xx_ir_init - "%s\012" /home/v4l/new_build/v4l/cx231xx-input.c:45 [cx231xx]get_key_isdbt - "scancode = %02x\012" /home/v4l/new_build/v4l/cx231xx-input.c:32 [cx231xx]get_key_isdbt - "%s\012" by using: # echo "file cx231xx-input.c +p" > /sys/kernel/debug/dynamic_debug/control All the above debug lines will be enabled. You can do, instead: # echo "file cx231xx-input.c line 45 +p" > /sys/kernel/debug/dynamic_debug/control If you're interested just at the scancode printk line. At least on the distros I use (RHEL6 and Fedora 14), dynamic printk support is enabled by default on kernel, so, this is very useful to me, as I don't need to recompile the entire kernel to test. >>> >>> CU >>> Oliver >> >> I complained about this months ago. The problem is that when we were >> using HG, the HG repo was a complete superset of what went into Git >> (including development/debug code). But now that we use Git, neither >> is a superset of the other. >> >> If you base your changes on Git, you have to add back in all the >> portability code (and any "#if 0" you added as the maintainer for >> development/debugging). Oh, and regular users cannot test any of your >> changes because they aren't willing to upgrade their entire kernel. >> >> If you base your changes on Hg, nothing merges cleanly when submitted >> upstream so your patches get rejected. >> >> Want to know why we are seeing regressions all over the place? >> Because *NOBODY* is testing the code until after the kernel goes >> stable (since while many are willing to install a v4l-dvb tree, very >> few will are willing to upgrade their entire kernel just to test one >> driver). We've probably lost about 98% of our user base of testers. > > Have you tried Mauro's media_build tree? I had to use it today to test a > driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should > promote this more. I could add backwards compatibility builds to my daily > build script that uses this in order to check for which kernel versions > this compiles if there is sufficient interest. I'm using it currently on most of my tests. I know that there are several users using it. >> Oh, and users have to git clone 500M+ of data, and not everybody in >> the world has bandwidth fast enough to make that worth their time (it >> took me several hours last time I did it). > > Currently the media_build tree copies the drivers from a git tree. Which, as > you say, can be a big problem for non-developers. But all it really needs are > the media drivers. So perhaps it might be a good idea to make a daily snapshot > of the drivers and make it available for download on linuxtv.org. That archive > is only 3.5 MB, so much easier to download. No, you don't need to have it. Have you looked at the build.sh script? It downloads and compiles everything using the latest tarball from: http://linuxtv.org/downloads/drivers/ Currently, the archive has 3.3Mb. The tarball is updated when a change is done on the latest development branch (It is still pointing to staging/for_v2.6.38, as I didn't finish to add the backport to linux-next changes). >> Anyway, I've beaten this horse to death and it's fallen on deaf ears. >> Merge overhead has reached the poin
Re: [GIT PULL FOR 2.6.38] Control framework fixes
> Hi Mauro, > > The following changes since commit > 0a97a683049d83deaf636d18316358065417d87b: > > [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 > -0200) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git ctrl-framework > > Could you please include them in the next pull request for 2.6.38 ? The > second > one is a bug fix and has been reviewed by Hans. For both patches: Reviewed-by: Hans Verkuil > > Laurent Pinchart (2): > v4l: Include linux/videodev2.h in media/v4l2-ctrls.h > v4l: Fix a use-before-set in the control framework > > drivers/media/video/v4l2-ctrls.c |2 +- > include/media/v4l2-ctrls.h |1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: [RFCv2 PATCH 0/5] Use control framework in cafe_ccic and s_config removal
> Hi, > >>> Another reason why s_config is a bad idea. > > Thanks a lot for working on this. I had a quick look and don't have > any objections. > >>> This has been extensively tested on my humble OLPC laptop (and it took >>> me 4-5 >>> hours just to get the damn thing up and running with these drivers). > > In future, come into irc.oftc.net #olpc-devel and talk to me (dsd) or > cjb (Chris Ball), we'll get you up and running in less time! If you have a link to some instructions on how to get the latest kernel up and running for olpc, then that would be handy :-) > I'll test the via-camera patch unless Jon beats me too it, but won't > be immediately. If you are ever interested in doing more in-depth work > on that driver, please drop me a mail and we will send you a XO-1.5. It's just for ongoing V4L2 maintenance (such as this sort of work). > > Also, perhaps you are interested in working on this bug, which is > probably reproducible with cafe_ccic too: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg23841.html I'll see if I can reproduce this with cafe_ccic. Weird that I haven't seen this before. The code looks fishy: my first guess is that sd->flags should be put in a local variable before it is being tested. I must have missed that bug report the first time around. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
[GIT PULL FOR 2.6.38] Control framework fixes
Hi Mauro, The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git ctrl-framework Could you please include them in the next pull request for 2.6.38 ? The second one is a bug fix and has been reviewed by Hans. Laurent Pinchart (2): v4l: Include linux/videodev2.h in media/v4l2-ctrls.h v4l: Fix a use-before-set in the control framework drivers/media/video/v4l2-ctrls.c |2 +- include/media/v4l2-ctrls.h |1 + 2 files changed, 2 insertions(+), 1 deletions(-) -- 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: RFC: Move the deprecated et61x251 and sn9c102 to staging
Em 10-01-2011 08:28, Hans de Goede escreveu: > Hi, > > On 01/10/2011 02:33 AM, Mauro Carvalho Chehab wrote: >> Em 09-01-2011 10:02, Hans de Goede escreveu: > > > >>> I've managed to make some time to also sort out the sn9c1xx usb ids >>> situation. I've just send a pull request which includes patches cleaning >>> things up. After this there are only 5 usb-ids left which will default to >>> sn9c102 when both are compiled in, and only 3 of those are not supported >>> by gspca. >> >> Good! >>> >>> So if we move the sn9c102 driver to staging we will loose support for >>> only 3 usb-ids. IOW I think it is time to move it to staging :) >> >> This would be a regression. >> > > Yes, although I wonder if anyone will notice. Fedora has had the sn9c102 > driver disabled for 3 releases now and I've received (and fixed) a single > bug in all that time about a cam not supported by gspca_sonixb which > was supported by sn9c102 > >>> Note I can write a patch to add untested support for these 3 to the >>> sonixb driver, given my experience with adding support for the hv7131d >>> based on the sn9c102 code, that should be doable. But it will be >>> completely untested :( >> >> I think that the better would be to add support for it at gspca, but wait for >> some feedback before considering it working. > > Well I've never seen these cams in the wild. sonixb cams with vga sensors > are quite rare because they cannot do more then 7.5-10 fps. So most cam > makers did the smart thing and went with a sonixj bridge for vga sensors. > > Anyways I'll do a gspca patch for adding support for the missing 3 models > (as time permits). And then we can ship that (and make it the default > if both are compiled in) for 1 or 2 cycles before moving the sn9c102 driver > to staging. Assuming we don't receive any negative feedback in those > 2 cycles (or manage to fix found bugs). It seems perfect to me. > > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] Use control framework in cafe_ccic and s_config removal
Hi, >> Another reason why s_config is a bad idea. Thanks a lot for working on this. I had a quick look and don't have any objections. >> This has been extensively tested on my humble OLPC laptop (and it took me 4-5 >> hours just to get the damn thing up and running with these drivers). In future, come into irc.oftc.net #olpc-devel and talk to me (dsd) or cjb (Chris Ball), we'll get you up and running in less time! I'll test the via-camera patch unless Jon beats me too it, but won't be immediately. If you are ever interested in doing more in-depth work on that driver, please drop me a mail and we will send you a XO-1.5. Also, perhaps you are interested in working on this bug, which is probably reproducible with cafe_ccic too: http://www.mail-archive.com/linux-media@vger.kernel.org/msg23841.html Thanks! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl
Hi Guennadi,
On Monday 10 January 2011 09:20:05 Guennadi Liakhovetski wrote:
> On Sun, 9 Jan 2011, Qing Xu wrote:
> > On Fri, 7 Jan 2011, Guennadi Liakhovetski wrote:
> > > On Fri, 7 Jan 2011, Qing Xu wrote:
> > > > pass VIDIOC_ENUM_FRAMESIZES down to sub device drivers. So far no
> > > > special handling in soc-camera core.
> > >
> > > Hm, no, guess what? I don't think this can work. The parameter, that
> > > this routine gets from the user struct v4l2_frmsizeenum contains a
> > > member pixel_format, which is a fourcc code. Whereas subdevices don't
> > > deal with them, they deal with mediabus codes. It is the same problem
> > > as with old s/g/try/enum_fmt, which we replaced with respective mbus
> > > variants. So, we either have to add our own .enum_mbus_framesizes
> > > video subdevice operation, or we abuse this one, but interpret the
> > > pixel_format field as a media-bus code.
> > >
> > > Currently I only see one subdev driver, that implements this API:
> > > ov7670.c, and it just happily ignores the pixel_format altogether...
> > >
> > > Hans, Laurent, what do you think?
> > >
> > > In the soc-camera case you will have to use
> > > soc_camera_xlate_by_fourcc() to convert to media-bus code from fourcc.
> > > A nit-pick: please, follow the style of the file, that you patch and
> > > don't add double empty lines between functions.
> > >
> > > A side question: why do you need this format at all? Is it for some
> > > custom
> > >
> > > Sorry, I meant to ask - what do you need this operation / ioctl() for?
> >
> > Before we launch camera application, we will use enum-frame-size ioctl
> > to get all frame size that the sensor supports, and show all options in
> > UI menu, then the customers could choose a size, and tell camera driver.
>
> And if the camera supports ranges of sizes? Or doesn't implement this
> ioctl() at all? Remember, that this is an optional ioctl(). Would your
> application just fail? Or you could provide a slider to let the user
> select a size from a range, then just issue an s_fmt and use whatever it
> returns... This is something you'd do for a generic application
>
> > If use mbus structure pass to sensor, we need to modify the second
> > parameter definition, it will contain both mbus code information and
> > width/height ingotmation:
> > int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
> > *fsize);
> >
> > or use g_mbus_fmt instead:
> > int (*g_mbus_fmt)(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
> > *fmt); soc_camera_enum_framesizes()
> > {
> >
> > ...
> > return v4l2_subdev_call(sd, video, g_mbus_fmt, fsize);//typo, I
> > mean "g_mbus_fmt"
> >
> > }
> >
> > What do you think?
>
> In any case therer needs to be a possibility for host drivers to override
> this routine, so, please, do something similar, to what default_g_crop() /
> default_s_crop() / default_cropcap() / default_g_parm() / default_s_parm()
> do: add a host operation and provide a default implementation for it. And
> since noone seems to care enough, I think, we can just abuse struct
> v4l2_frmsizeenum for now, just make sure to rewrite pixel_format to a
> media-bus code, and restore it before returning to the caller.
I like the .enum_mbus_framesizes better, but I could live with a hack until if
you convert soc_camera to use subdev pad-level operations when the MC will be
available.
--
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
[PATCH v13 8/8] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the "LogicPD" +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 7/8] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/Kconfig | 22 ++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate "DM644X VPBE HW module" + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate "VPBE V4L2 Display driver" + select VIDEO_DM644X_VPBE + default y + help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 6/8] davinci vpbe: board specific additions
This patch implements tables for display timings,outputs and
other board related functionalities.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
arch/arm/mach-davinci/board-dm644x-evm.c | 86 --
1 files changed, 70 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..8abef65 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -5,7 +5,7 @@
*
* 2007 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
+ * is licensed without any warranty of any kind, whether express
* or implied.
*/
#include
@@ -176,18 +176,6 @@ static struct platform_device davinci_evm_nandflash_device
= {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = "davincifb",
- .id = -1,
- .dev = {
- .dma_mask = &davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -337,7 +325,6 @@ static struct pcf857x_platform_data pcf_data_u2 = {
.teardown = evm_led_teardown,
};
-
/* U18 - A/V clock generator and user switch */
static int sw_gpio;
@@ -404,7 +391,6 @@ static struct pcf857x_platform_data pcf_data_u18 = {
.teardown = evm_u18_teardown,
};
-
/* U35 - various I/O signals used to manage USB, CF, ATA, etc */
static int
@@ -616,8 +602,73 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First that from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = "ntsc",
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = "Component",
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = "480p59_94",
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = "dm644x-vpbe-display",
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
- &davinci_fb_device,
&rtc_dev,
};
@@ -630,6 +681,9 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(&vpfe_cfg);
+
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(&vpbe_display_cfg);
dm6
[PATCH v13 5/8] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
arch/arm/mach-davinci/dm644x.c | 168 +--
arch/arm/mach-davinci/include/mach/dm644x.h | 18 +++-
2 files changed, 175 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..3cc5f7c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -5,7 +5,7 @@
*
* 2007 (c) Deep Root Systems, LLC. This file is licensed under
* the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
+ * is licensed without any warranty of any kind, whether express
* or implied.
*/
#include
@@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +655,138 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + OSD_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+ .field_inv_wa_enable = 0,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = &dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &osd_data,
+ },
+};
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = DM644X_VENC_REG_BASE,
+ .end= DM644X_VENC_REG_BASE + VENC_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTLSYS_VPSS_CLKCTL
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+ int ret = 0;
+
+ if (NULL == vpss_clkctl_reg)
+ return -EINVAL;
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+ writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = "vpbe-v4l2",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = &vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
+ .resource = dm644x_venc_resources,
+ .dev = {
+ .dma_mask = &dm644x_venc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &dm644x_venc_pdata,
+ },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
[PATCH v13 4/8] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe_venc.c | 556 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 177
include/media/davinci/vpbe_venc.h| 41 ++
3 files changed, 774 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..1131e2d
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,556 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include "vpbe_venc_regs.h"
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level 0-2");
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return readl(venc->venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+ writel(val, (venc->venc_base + offset));
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) & ~mask) | (val & mask);
+
+ venc_write(sd, offset, new_val);
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, venc->vdaccfg_reg);
+
+ val = readl(venc->vdaccfg_reg);
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ int ret = 0;
+
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, "Setting output to Composite\n");
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, "Setting output to S-Video\n");
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, "venc_enabledigitaloutput\n");
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd, VENC_LCDOUT, 0);
+ venc_write(sd, VENC_HSPLS, 0);
+ venc_write(sd, VENC_HSTART, 0);
+ venc_write(sd, VENC_HVALID, 0);
+ venc_write(sd, VENC_HINT, 0);
+ venc_write(sd, VENC_VSPLS, 0);
+ venc_write(sd, VENC_VSTART, 0);
+ venc_write(sd, VENC_VVALID, 0);
+ venc_write(sd, VENC_VINT, 0);
+ venc_write(sd,
[PATCH v13 3/8] davinci vpbe: OSD(On Screen Display) block
This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe_osd.c | 1216 +++
drivers/media/video/davinci/vpbe_osd_regs.h | 364
include/media/davinci/vpbe_osd.h| 397 +
3 files changed, 1977 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 include/media/davinci/vpbe_osd.h
diff --git a/drivers/media/video/davinci/vpbe_osd.c
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..bbc43ea
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1216 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include "vpbe_osd_regs.h"
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+ struct osd_state *osd = sd;
+ return readl(osd->osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+ struct osd_state *osd = sd;
+ writel(val, osd->osd_base + offset);
+ return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd->osd_base + offset;
+ u32 val = readl(addr) | mask;
+
+ writel(val, addr);
+ return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+ u32 addr = osd->osd_base + offset;
+ u32 val = readl(addr) & ~mask;
+
+ writel(val, addr);
+ return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd->osd_base + offset;
+ u32 new_val = (readl(addr) & ~mask) | (val & mask);
+ writel(new_val, addr);
+ return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+ ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446. The fb_base_phys and
+ * lconfig parameters apply to the vid0 window. This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ * 0 otherwise
+ */
+static int _osd_dm6446_vid0_pingpong(struct osd_state *sd,
+int field_inversion,
+unsigned long fb_base_phys,
+const struct osd_layer_config *lconfig)
+{
+ struct osd_platform_data *pdata;
+
[PATCH v13 2/8] davinci vpbe: VPBE display driver
This patch implements the core functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe.c | 826
include/media/davinci/vpbe.h | 185
2 files changed, 1011 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..d3aaf1e
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define VPBE_DEFAULT_OUTPUT"Composite"
+#define VPBE_DEFAULT_MODE "ntsc"
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)");
+MODULE_PARM_DESC(def_mode, "vpbe output mode name (default:ntsc");
+MODULE_PARM_DESC(debug, "Debug level 0-1");
+
+MODULE_DESCRIPTION("TI DMXXX VPBE Display controller");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Texas Instruments");
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+ int index = vpbe_dev->current_sd_index;
+
+ return ((index == 0) ? &vpbe_config->venc :
+ &vpbe_config->ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+ char *encoder_name = vpbe_config->outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, vpbe_config->venc.module_name))
+ return 0;
+
+ for (i = 0; i < vpbe_config->num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+vpbe_config->ext_encoders[i].module_name))
+ return i+1;
+ }
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap->bounds.left = 0;
+ cropcap->bounds.top = 0;
+ cropcap->bounds.width = vpbe_dev->current_timings.xres;
+ cropcap->bounds.height = vpbe_dev->current_timings.yres;
+ cropcap->defrect = cropcap->bounds;
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+ int temp_index = output->index;
+
+ if (temp_index >= vpbe_config->num_outputs)
+ return -EINVAL;
+
+ *output = vpbe_config->outputs[temp_index].output;
+
[PATCH v13 0/8] davinci vpbe: dm6446 v4l2 driver
version13 : addressed Sergei's and Bjarn Forsman's comments on: 1. Fixing the module patams typo. 2. Removal of unused macros 3. Minor changes in the GPL licensing header. The GPL now reads: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation version 2. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil Manjunath Hadli (8): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: board specific additions davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ arch/arm/mach-davinci/board-dm644x-evm.c | 86 +- arch/arm/mach-davinci/dm644x.c| 168 ++- arch/arm/mach-davinci/include/mach/dm644x.h | 18 +- drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 826 ++ drivers/media/video/davinci/vpbe_display.c| 2084 + drivers/media/video/davinci/vpbe_osd.c| 1216 ++ drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 556 +++ drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 185 +++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 + include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 41 + 17 files changed, 6445 insertions(+), 27 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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: Move the deprecated et61x251 and sn9c102 to staging
Hi, On 01/10/2011 02:33 AM, Mauro Carvalho Chehab wrote: Em 09-01-2011 10:02, Hans de Goede escreveu: I've managed to make some time to also sort out the sn9c1xx usb ids situation. I've just send a pull request which includes patches cleaning things up. After this there are only 5 usb-ids left which will default to sn9c102 when both are compiled in, and only 3 of those are not supported by gspca. Good! So if we move the sn9c102 driver to staging we will loose support for only 3 usb-ids. IOW I think it is time to move it to staging :) This would be a regression. Yes, although I wonder if anyone will notice. Fedora has had the sn9c102 driver disabled for 3 releases now and I've received (and fixed) a single bug in all that time about a cam not supported by gspca_sonixb which was supported by sn9c102 Note I can write a patch to add untested support for these 3 to the sonixb driver, given my experience with adding support for the hv7131d based on the sn9c102 code, that should be doable. But it will be completely untested :( I think that the better would be to add support for it at gspca, but wait for some feedback before considering it working. Well I've never seen these cams in the wild. sonixb cams with vga sensors are quite rare because they cannot do more then 7.5-10 fps. So most cam makers did the smart thing and went with a sonixj bridge for vga sensors. Anyways I'll do a gspca patch for adding support for the missing 3 models (as time permits). And then we can ship that (and make it the default if both are compiled in) for 1 or 2 cycles before moving the sn9c102 driver to staging. Assuming we don't receive any negative feedback in those 2 cycles (or manage to fix found bugs). Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/16] ngene: Support up to 4 tuners
Support up to 4 tuners for cineS2 v5, duoflex & mystique v2.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c | 174 +++--
1 files changed, 143 insertions(+), 31 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 4692a41..5e6b85c 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -48,20 +48,27 @@
static int tuner_attach_stv6110(struct ngene_channel *chan)
{
+ struct i2c_adapter *i2c;
struct stv090x_config *feconf = (struct stv090x_config *)
chan->dev->card_info->fe_config[chan->number];
struct stv6110x_config *tunerconf = (struct stv6110x_config *)
chan->dev->card_info->tuner_config[chan->number];
struct stv6110x_devctl *ctl;
- ctl = dvb_attach(stv6110x_attach, chan->fe, tunerconf,
-&chan->i2c_adapter);
+ /* tuner 1+2: i2c adapter #0, tuner 3+4: i2c adapter #1 */
+ if (chan->number < 2)
+ i2c = &chan->dev->channel[0].i2c_adapter;
+ else
+ i2c = &chan->dev->channel[1].i2c_adapter;
+
+ ctl = dvb_attach(stv6110x_attach, chan->fe, tunerconf, i2c);
if (ctl == NULL) {
printk(KERN_ERR DEVICE_NAME ": No STV6110X found!\n");
return -ENODEV;
}
feconf->tuner_init = ctl->tuner_init;
+ feconf->tuner_sleep = ctl->tuner_sleep;
feconf->tuner_set_mode = ctl->tuner_set_mode;
feconf->tuner_set_frequency = ctl->tuner_set_frequency;
feconf->tuner_get_frequency = ctl->tuner_get_frequency;
@@ -78,20 +85,31 @@ static int tuner_attach_stv6110(struct ngene_channel *chan)
static int demod_attach_stv0900(struct ngene_channel *chan)
{
+ struct i2c_adapter *i2c;
struct stv090x_config *feconf = (struct stv090x_config *)
chan->dev->card_info->fe_config[chan->number];
- chan->fe = dvb_attach(stv090x_attach,
- feconf,
- &chan->i2c_adapter,
- chan->number == 0 ? STV090x_DEMODULATOR_0 :
- STV090x_DEMODULATOR_1);
+ /* tuner 1+2: i2c adapter #0, tuner 3+4: i2c adapter #1 */
+ /* Note: Both adapters share the same i2c bus, but the demod */
+ /* driver requires that each demod has its own i2c adapter */
+ if (chan->number < 2)
+ i2c = &chan->dev->channel[0].i2c_adapter;
+ else
+ i2c = &chan->dev->channel[1].i2c_adapter;
+
+ chan->fe = dvb_attach(stv090x_attach, feconf, i2c,
+ (chan->number & 1) == 0 ? STV090x_DEMODULATOR_0
+ : STV090x_DEMODULATOR_1);
if (chan->fe == NULL) {
printk(KERN_ERR DEVICE_NAME ": No STV0900 found!\n");
return -ENODEV;
}
- if (!dvb_attach(lnbh24_attach, chan->fe, &chan->i2c_adapter, 0,
+ /* store channel info */
+ if (feconf->tuner_i2c_lock)
+ chan->fe->analog_demod_priv = chan;
+
+ if (!dvb_attach(lnbh24_attach, chan->fe, i2c, 0,
0, chan->dev->card_info->lnb[chan->number])) {
printk(KERN_ERR DEVICE_NAME ": No LNBH24 found!\n");
dvb_frontend_detach(chan->fe);
@@ -101,6 +119,71 @@ static int demod_attach_stv0900(struct ngene_channel *chan)
return 0;
}
+static void cineS2_tuner_i2c_lock(struct dvb_frontend *fe, int lock)
+{
+ struct ngene_channel *chan = fe->analog_demod_priv;
+
+ if (lock)
+ down(&chan->dev->pll_mutex);
+ else
+ up(&chan->dev->pll_mutex);
+}
+
+static int cineS2_probe(struct ngene_channel *chan)
+{
+ struct i2c_adapter *i2c;
+ struct stv090x_config *fe_conf;
+ u8 buf[3];
+ struct i2c_msg i2c_msg = { .flags = 0, .buf = buf };
+ int rc;
+
+ /* tuner 1+2: i2c adapter #0, tuner 3+4: i2c adapter #1 */
+ if (chan->number < 2)
+ i2c = &chan->dev->channel[0].i2c_adapter;
+ else
+ i2c = &chan->dev->channel[1].i2c_adapter;
+
+ fe_conf = chan->dev->card_info->fe_config[chan->number];
+ i2c_msg.addr = fe_conf->address;
+
+ /* probe demod */
+ i2c_msg.len = 2;
+ buf[0] = 0xf1;
+ buf[1] = 0x00;
+ rc = i2c_transfer(i2c, &i2c_msg, 1);
+ if (rc != 1)
+ return -ENODEV;
+
+ /* demod found, attach it */
+ rc = demod_attach_stv0900(chan);
+ if (rc < 0 || chan->number < 2)
+ return rc;
+
+ /* demod #2: reprogram outputs DPN1 & DPN2 */
+ i2c_msg.len = 3;
+ buf[0] = 0xf1;
+ switch (chan->number) {
+ case 2:
+ buf[1] = 0x5c;
+ buf[2] = 0xc2;
+ break;
+ case 3:
+ buf[1] = 0x61
[PATCH 07/16] ngene: CXD2099AR Common Interface driver
From: Ralph Metzler
Driver for the Common Interface Controller CXD2099AR.
Supports the CI of the cineS2 DVB-S2.
For now, data is passed through '/dev/dvb/adapterX/sec0':
- Encrypted data must be written to 'sec0'.
- Decrypted data can be read from 'sec0'.
- Setup the CAM using device 'ca0'.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/Makefile |2 +-
drivers/media/dvb/ngene/cxd2099.c | 574 +
drivers/media/dvb/ngene/cxd2099.h | 32 ++
drivers/media/dvb/ngene/ngene-cards.c |6 +-
drivers/media/dvb/ngene/ngene-core.c | 110 +--
drivers/media/dvb/ngene/ngene-dvb.c | 70 -
drivers/media/dvb/ngene/ngene.h | 19 ++
7 files changed, 782 insertions(+), 31 deletions(-)
create mode 100644 drivers/media/dvb/ngene/cxd2099.c
create mode 100644 drivers/media/dvb/ngene/cxd2099.h
diff --git a/drivers/media/dvb/ngene/Makefile b/drivers/media/dvb/ngene/Makefile
index 0608aab..00d12d6 100644
--- a/drivers/media/dvb/ngene/Makefile
+++ b/drivers/media/dvb/ngene/Makefile
@@ -2,7 +2,7 @@
# Makefile for the nGene device driver
#
-ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o
+ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o cxd2099.o
obj-$(CONFIG_DVB_NGENE) += ngene.o
diff --git a/drivers/media/dvb/ngene/cxd2099.c
b/drivers/media/dvb/ngene/cxd2099.c
new file mode 100644
index 000..b49186c
--- /dev/null
+++ b/drivers/media/dvb/ngene/cxd2099.c
@@ -0,0 +1,574 @@
+/*
+ * cxd2099.c: Driver for the CXD2099AR Common Interface Controller
+ *
+ * Copyright (C) 2010 DigitalDevices UG
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, 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 Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cxd2099.h"
+
+#define MAX_BUFFER_SIZE 248
+
+struct cxd {
+ struct dvb_ca_en50221 en;
+
+ struct i2c_adapter *i2c;
+ u8 adr;
+ u8 regs[0x23];
+ u8 lastaddress;
+ u8 clk_reg_f;
+ u8 clk_reg_b;
+ intmode;
+ u32bitrate;
+ intready;
+ intdr;
+ intslot_stat;
+
+ u8 amem[1024];
+ intamem_read;
+
+ intcammode;
+ struct mutex lock;
+};
+
+static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
+u8 reg, u8 data)
+{
+ u8 m[2] = {reg, data};
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
+
+ if (i2c_transfer(adapter, &msg, 1) != 1) {
+ printk(KERN_ERR "Failed to write to I2C register %...@%02x!\n",
+ reg, adr);
+ return -1;
+ }
+ return 0;
+}
+
+static int i2c_write(struct i2c_adapter *adapter, u8 adr,
+u8 *data, u8 len)
+{
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
+
+ if (i2c_transfer(adapter, &msg, 1) != 1) {
+ printk(KERN_ERR "Failed to write to I2C!\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
+ u8 reg, u8 *val)
+{
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = ®, .len = 1 },
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1 } };
+
+ if (i2c_transfer(adapter, msgs, 2) != 2) {
+ printk(KERN_ERR "error in i2c_read_reg\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int i2c_read(struct i2c_adapter *adapter, u8 adr,
+ u8 reg, u8 *data, u8 n)
+{
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = ®, .len = 1 },
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = data, .len = n } };
+
+ if (i2c_transfer(adapter, msgs, 2) != 2) {
+ printk(KERN_ERR "error in i2c_read\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int read_block(struct cxd *ci, u8 adr, u8 *data, u8 n)
+{
+ int status;
+
+ status = i2c_write_reg(ci->i
[PATCH 11/16] get_dvb_firmware: ngene_18.fw added
Add download link for ngene firmware rev 18.
Signed-off-by: Oliver Endriss
---
Documentation/dvb/get_dvb_firmware |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 59690de..3348d31 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -556,6 +556,9 @@ sub ngene {
my $hash1 = "d798d5a757121174f0dbc5f2833c0c85";
my $file2 = "ngene_17.fw";
my $hash2 = "26b687136e127b8ac24b81e0eeafc20b";
+my $url2 = "http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/";;
+my $file3 = "ngene_18.fw";
+my $hash3 = "ebce3ea769a53e3e0b0197c3b3f127e3";
checkstandard();
@@ -565,7 +568,10 @@ sub ngene {
wgetfile($file2, $url . $file2);
verify($file2, $hash2);
-"$file1, $file2";
+wgetfile($file3, $url2 . $file3);
+verify($file3, $hash3);
+
+"$file1, $file2, $file3";
}
sub az6027{
--
1.6.5.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 02/16] stv090x: Optional external lock routine
Card driver may supply its own lock routine now.
Signed-off-by: Oliver Endriss
Signed-off-by: Manu Abraham
---
drivers/media/dvb/frontends/stv090x.c | 21 -
drivers/media/dvb/frontends/stv090x.h |1 +
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index df59207..57e229a 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -767,8 +767,12 @@ static int stv090x_i2c_gate_ctrl(struct stv090x_state
*state, int enable)
* In case of any error, the lock is unlocked and exit within the
* relevant operations themselves.
*/
- if (enable)
- mutex_lock(&state->internal->tuner_lock);
+ if (enable) {
+ if (state->config->tuner_i2c_lock)
+ state->config->tuner_i2c_lock(&state->frontend, 1);
+ else
+ mutex_lock(&state->internal->tuner_lock);
+ }
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
@@ -784,13 +788,20 @@ static int stv090x_i2c_gate_ctrl(struct stv090x_state
*state, int enable)
goto err;
}
- if (!enable)
- mutex_unlock(&state->internal->tuner_lock);
+ if (!enable) {
+ if (state->config->tuner_i2c_lock)
+ state->config->tuner_i2c_lock(&state->frontend, 0);
+ else
+ mutex_unlock(&state->internal->tuner_lock);
+ }
return 0;
err:
dprintk(FE_ERROR, 1, "I/O error");
- mutex_unlock(&state->internal->tuner_lock);
+ if (state->config->tuner_i2c_lock)
+ state->config->tuner_i2c_lock(&state->frontend, 0);
+ else
+ mutex_unlock(&state->internal->tuner_lock);
return -1;
}
diff --git a/drivers/media/dvb/frontends/stv090x.h
b/drivers/media/dvb/frontends/stv090x.h
index dd1b93a..20cf69c 100644
--- a/drivers/media/dvb/frontends/stv090x.h
+++ b/drivers/media/dvb/frontends/stv090x.h
@@ -97,6 +97,7 @@ struct stv090x_config {
int (*tuner_get_bbgain) (struct dvb_frontend *fe, u32 *gain);
int (*tuner_set_refclk) (struct dvb_frontend *fe, u32 refclk);
int (*tuner_get_status) (struct dvb_frontend *fe, u32 *status);
+ void (*tuner_i2c_lock) (struct dvb_frontend *fe, int lock);
};
#if defined(CONFIG_DVB_STV090x) || (defined(CONFIG_DVB_STV090x_MODULE) &&
defined(MODULE))
--
1.6.5.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 03/16] ngene: Firmware 18 support
Small modifications for firmware 18.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 3a7ef71..e2546f1 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1257,6 +1257,10 @@ static int ngene_load_firm(struct ngene *dev)
fw_name = "ngene_17.fw";
dev->cmd_timeout_workaround = true;
break;
+ case 18:
+ size = 0;
+ fw_name = "ngene_18.fw";
+ break;
}
if (request_firmware(&fw, fw_name, &dev->pci_dev->dev) < 0) {
@@ -1266,6 +1270,8 @@ static int ngene_load_firm(struct ngene *dev)
": Copy %s to your hotplug directory!\n", fw_name);
return -1;
}
+ if (size == 0)
+ size = fw->size;
if (size != fw->size) {
printk(KERN_ERR DEVICE_NAME
": Firmware %s has invalid size!", fw_name);
@@ -1364,7 +1370,7 @@ static int ngene_start(struct ngene *dev)
if (stat < 0)
goto fail;
- if (dev->card_info->fw_version == 17) {
+ if (dev->card_info->fw_version >= 17) {
u8 tsin4_config[6] = {
3072 / 64, 3072 / 64, 0, 3072 / 64, 3072 / 64, 0};
u8 default_config[6] = {
@@ -1373,7 +1379,7 @@ static int ngene_start(struct ngene *dev)
if (dev->card_info->io_type[3] == NGENE_IO_TSIN)
bconf = tsin4_config;
- dprintk(KERN_DEBUG DEVICE_NAME ": FW 17 buffer config\n");
+ dprintk(KERN_DEBUG DEVICE_NAME ": FW 17+ buffer config\n");
stat = ngene_command_config_free_buf(dev, bconf);
} else {
int bconf = BUFFER_CONFIG_4422;
--
1.6.5.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 14/16] stv090x: Fix losing lock in dual DVB-S2 mode
Do not clear registers ACLC/BCLC in DVB-S2 mode for Cut <= 20.
Otherwise, the demod could lose the lock periodically.
Verified with cineS2 and Duoflex.
Signed-off-by: Oliver Endriss
Signed-off-by: Manu Abraham
---
drivers/media/dvb/frontends/stv090x.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index 57e229a..1675c2a 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -2894,10 +2894,12 @@ static int stv090x_optimize_track(struct stv090x_state
*state)
STV090x_SETFIELD_Px(reg, DVBS2_ENABLE_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, DMDCFGMD, reg) < 0)
goto err;
- if (STV090x_WRITE_DEMOD(state, ACLC, 0) < 0)
- goto err;
- if (STV090x_WRITE_DEMOD(state, BCLC, 0) < 0)
- goto err;
+ if (state->internal->dev_ver >= 0x30) {
+ if (STV090x_WRITE_DEMOD(state, ACLC, 0) < 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, BCLC, 0) < 0)
+ goto err;
+ }
if (state->frame_len == STV090x_LONG_FRAME) {
reg = STV090x_READ_DEMOD(state, DMDMODCOD);
modcod = STV090x_GETFIELD_Px(reg, DEMOD_MODCOD_FIELD);
--
1.6.5.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 15/16] ngene: Improved channel initialisation and release
Refactored code for channel initialisation and release:
- Do not create device nodes which are not required.
- Better error handling.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c | 109 ++
drivers/media/dvb/ngene/ngene.h |2 +
2 files changed, 60 insertions(+), 51 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 02118f2..4e1fc12 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1431,25 +1431,24 @@ static void release_channel(struct ngene_channel *chan)
{
struct dvb_demux *dvbdemux = &chan->demux;
struct ngene *dev = chan->dev;
- struct ngene_info *ni = dev->card_info;
- int io = ni->io_type[chan->number];
- if (chan->dev->cmd_timeout_workaround && chan->running)
+ if (chan->running)
set_transfer(chan, 0);
tasklet_kill(&chan->demux_tasklet);
- if (chan->number >= 2 && chan->number <= 3 && dev->ci.en)
- return;
+ if (chan->ci_dev) {
+ dvb_unregister_device(chan->ci_dev);
+ chan->ci_dev = NULL;
+ }
- if (io & (NGENE_IO_TSIN | NGENE_IO_TSOUT)) {
- if (chan->ci_dev)
- dvb_unregister_device(chan->ci_dev);
- if (chan->fe) {
- dvb_unregister_frontend(chan->fe);
- dvb_frontend_detach(chan->fe);
- chan->fe = NULL;
- }
+ if (chan->fe) {
+ dvb_unregister_frontend(chan->fe);
+ dvb_frontend_detach(chan->fe);
+ chan->fe = NULL;
+ }
+
+ if (chan->has_demux) {
dvb_net_release(&chan->dvbnet);
dvbdemux->dmx.close(&dvbdemux->dmx);
dvbdemux->dmx.remove_frontend(&dvbdemux->dmx,
@@ -1458,9 +1457,12 @@ static void release_channel(struct ngene_channel *chan)
&chan->mem_frontend);
dvb_dmxdev_release(&chan->dmxdev);
dvb_dmx_release(&chan->demux);
+ chan->has_demux = false;
+ }
- if (chan->number == 0 || !one_adapter)
- dvb_unregister_adapter(&dev->adapter[chan->number]);
+ if (chan->has_adapter) {
+ dvb_unregister_adapter(&dev->adapter[chan->number]);
+ chan->has_adapter = false;
}
}
@@ -1478,12 +1480,27 @@ static int init_channel(struct ngene_channel *chan)
chan->type = io;
chan->mode = chan->type;/* for now only one mode */
+ if (io & NGENE_IO_TSIN) {
+ chan->fe = NULL;
+ if (ni->demod_attach[nr]) {
+ ret = ni->demod_attach[nr](chan);
+ if (ret < 0)
+ goto err;
+ }
+ if (chan->fe && ni->tuner_attach[nr]) {
+ ret = ni->tuner_attach[nr](chan);
+ if (ret < 0)
+ goto err;
+ }
+ }
+
+ if (!dev->ci.en && (io & NGENE_IO_TSOUT))
+ return 0;
+
if (io & (NGENE_IO_TSIN | NGENE_IO_TSOUT)) {
if (nr >= STREAM_AUDIOIN1)
chan->DataFormatFlags = DF_SWAP32;
- if (nr >= 2 && nr <= 3 && dev->ci.en)
- return 0;
if (nr == 0 || !one_adapter || dev->first_adapter == NULL) {
adapter = &dev->adapter[nr];
ret = dvb_register_adapter(adapter, "nGene",
@@ -1491,13 +1508,32 @@ static int init_channel(struct ngene_channel *chan)
&chan->dev->pci_dev->dev,
adapter_nr);
if (ret < 0)
- return ret;
+ goto err;
if (dev->first_adapter == NULL)
dev->first_adapter = adapter;
- } else {
+ chan->has_adapter = true;
+ } else
adapter = dev->first_adapter;
- }
+ }
+
+ if (dev->ci.en && (io & NGENE_IO_TSOUT)) {
+ dvb_ca_en50221_init(adapter, dev->ci.en, 0, 1);
+ set_transfer(chan, 1);
+ set_transfer(&chan->dev->channel[2], 1);
+ dvb_register_device(adapter, &chan->ci_dev,
+ &ngene_dvbdev_ci, (void *) chan,
+ DVB_DEVICE_SEC);
+ if (!chan->ci_dev)
+ goto err;
+ }
+ if (chan->fe) {
+ if (dvb_register_frontend(adapter, chan->fe) < 0)
+ goto err;
+ chan->has_demux = true;
+ }
+
+
[PATCH 12/16] ngene: Fix copy-paste error
Signed-off-by: Oliver Endriss --- drivers/media/dvb/ngene/ngene-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c index b370bd2..02118f2 100644 --- a/drivers/media/dvb/ngene/ngene-core.c +++ b/drivers/media/dvb/ngene/ngene-core.c @@ -47,7 +47,7 @@ MODULE_PARM_DESC(one_adapter, "Use only one adapter."); static int shutdown_workaround; module_param(shutdown_workaround, int, 0644); -MODULE_PARM_DESC(one_adapter, "Activate workaround for shutdown problem with some chipsets."); +MODULE_PARM_DESC(shutdown_workaround, "Activate workaround for shutdown problem with some chipsets."); static int debug; module_param(debug, int, 0444); -- 1.6.5.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 16/16] stv090x: 22kHz workaround must also be performed for the 2nd frontend
22kHz workaround must also be performed for the 2nd frontend.
Signed-off-by: Oliver Endriss
Signed-off-by: Manu Abraham
---
drivers/media/dvb/frontends/stv090x.c | 26 +++---
1 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index 1675c2a..6c4c6ef 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4688,10 +4688,6 @@ static int stv090x_setup(struct dvb_frontend *fe)
if (stv090x_write_reg(state, STV090x_TSTRES0, 0x00) < 0)
goto err;
- /* workaround for stuck DiSEqC output */
- if (config->diseqc_envelope_mode)
- stv090x_send_diseqc_burst(fe, SEC_MINI_A);
-
return 0;
err:
dprintk(FE_ERROR, 1, "I/O error");
@@ -4762,11 +4758,6 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
state->internal = temp_int->internal;
state->internal->num_used++;
dprintk(FE_INFO, 1, "Found Internal Structure!");
- dprintk(FE_ERROR, 1, "Attaching %s demodulator(%d) Cut=0x%02x",
- state->device == STV0900 ? "STV0900" : "STV0903",
- demod,
- state->internal->dev_ver);
- return &state->frontend;
} else {
state->internal = kmalloc(sizeof(struct stv090x_internal),
GFP_KERNEL);
@@ -4777,15 +4768,20 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
state->internal->i2c_adap = state->i2c;
state->internal->i2c_addr = state->config->address;
dprintk(FE_INFO, 1, "Create New Internal Structure!");
- }
- mutex_init(&state->internal->demod_lock);
- mutex_init(&state->internal->tuner_lock);
+ mutex_init(&state->internal->demod_lock);
+ mutex_init(&state->internal->tuner_lock);
- if (stv090x_setup(&state->frontend) < 0) {
- dprintk(FE_ERROR, 1, "Error setting up device");
- goto error;
+ if (stv090x_setup(&state->frontend) < 0) {
+ dprintk(FE_ERROR, 1, "Error setting up device");
+ goto error;
+ }
}
+
+ /* workaround for stuck DiSEqC output */
+ if (config->diseqc_envelope_mode)
+ stv090x_send_diseqc_burst(&state->frontend, SEC_MINI_A);
+
dprintk(FE_ERROR, 1, "Attaching %s demodulator(%d) Cut=0x%02x",
state->device == STV0900 ? "STV0900" : "STV0903",
demod,
--
1.6.5.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 09/16] ngene: Add net device
From: Ralph Metzler
Add dvb net device.
Note that the physical address must be setup manually.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c |3 +++
drivers/media/dvb/ngene/ngene.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 672f7fe..b370bd2 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1450,6 +1450,7 @@ static void release_channel(struct ngene_channel *chan)
dvb_frontend_detach(chan->fe);
chan->fe = NULL;
}
+ dvb_net_release(&chan->dvbnet);
dvbdemux->dmx.close(&dvbdemux->dmx);
dvbdemux->dmx.remove_frontend(&dvbdemux->dmx,
&chan->hw_frontend);
@@ -1503,6 +1504,8 @@ static int init_channel(struct ngene_channel *chan)
ret = my_dvb_dmxdev_ts_card_init(&chan->dmxdev, &chan->demux,
&chan->hw_frontend,
&chan->mem_frontend, adapter);
+ ret = dvb_net_init(adapter, &chan->dvbnet, &chan->demux.dmx);
+
if (dev->ci.en && (io&NGENE_IO_TSOUT)) {
dvb_ca_en50221_init(adapter, dev->ci.en, 0, 1);
set_transfer(chan, 1);
diff --git a/drivers/media/dvb/ngene/ngene.h b/drivers/media/dvb/ngene/ngene.h
index c1bb810..5894abd 100644
--- a/drivers/media/dvb/ngene/ngene.h
+++ b/drivers/media/dvb/ngene/ngene.h
@@ -39,6 +39,7 @@
#include "dvb_ca_en50221.h"
#include "dvb_frontend.h"
#include "dvb_ringbuffer.h"
+#include "dvb_net.h"
#include "cxd2099.h"
#define DEVICE_NAME "ngene"
@@ -642,6 +643,7 @@ struct ngene_channel {
struct dvb_frontend *fe;
struct dmxdev dmxdev;
struct dvb_demux demux;
+ struct dvb_netdvbnet;
struct dmx_frontend hw_frontend;
struct dmx_frontend mem_frontend;
int users;
--
1.6.5.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 10/16] ngene: Enable CI for Mystique SaTiX-S2 Dual (v2)
Enable CI for Mystique SaTiX-S2 Dual (v2).
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 6d87427..fcf4be9 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -303,7 +303,8 @@ static struct ngene_info ngene_info_satixS2 = {
static struct ngene_info ngene_info_satixS2v2 = {
.type = NGENE_SIDEWINDER,
.name = "Mystique SaTiX-S2 Dual (v2)",
- .io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN},
+ .io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN,
+ NGENE_IO_TSOUT},
.demod_attach = {demod_attach_stv0900, demod_attach_stv0900,
cineS2_probe, cineS2_probe},
.tuner_attach = {tuner_attach_stv6110, tuner_attach_stv6110,
tuner_attach_stv6110, tuner_attach_stv6110},
.fe_config = {&fe_cineS2, &fe_cineS2, &fe_cineS2_2, &fe_cineS2_2},
--
1.6.5.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 13/16] stv090x: Fixed typos in register macros
Fixed typos in register macros. Signed-off-by: Oliver Endriss Signed-off-by: Manu Abraham --- drivers/media/dvb/frontends/stv090x_reg.h | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/media/dvb/frontends/stv090x_reg.h b/drivers/media/dvb/frontends/stv090x_reg.h index 2502855..93741ee 100644 --- a/drivers/media/dvb/frontends/stv090x_reg.h +++ b/drivers/media/dvb/frontends/stv090x_reg.h @@ -1327,10 +1327,10 @@ #define STV090x_WIDTH_Px_NOSPLHT_UNNORMED_FIELD8 #define STV090x_Px_NOSPLHy(__x, __y) (0xf48f - (__x - 1) * 0x200 - __y * 0x1) -#define STv090x_P1_NOSPLH0 STV090x_Px_NOSPLHy(1, 0) -#define STv090x_P1_NOSPLH1 STV090x_Px_NOSPLHy(1, 1) -#define STv090x_P2_NOSPLH0 STV090x_Px_NOSPLHy(2, 0) -#define STv090x_P2_NOSPLH1 STV090x_Px_NOSPLHy(2, 1) +#define STV090x_P1_NOSPLH0 STV090x_Px_NOSPLHy(1, 0) +#define STV090x_P1_NOSPLH1 STV090x_Px_NOSPLHy(1, 1) +#define STV090x_P2_NOSPLH0 STV090x_Px_NOSPLHy(2, 0) +#define STV090x_P2_NOSPLH1 STV090x_Px_NOSPLHy(2, 1) #define STV090x_OFFST_Px_NOSPLH_UNNORMED_FIELD 0 #define STV090x_WIDTH_Px_NOSPLH_UNNORMED_FIELD 8 @@ -1406,7 +1406,7 @@ #define STV090x_Px_BCLC2S28(__x) (0xf49d - (__x - 1) * 0x200) #define STV090x_P1_BCLC2S28STV090x_Px_BCLC2S28(1) -#define STV090x_P2_BCLC2S28STV090x_Px_BCLC2S28(1) +#define STV090x_P2_BCLC2S28STV090x_Px_BCLC2S28(2) #define STV090x_OFFST_Px_CAR2S2_8_BETA_M_FIELD 4 #define STV090x_WIDTH_Px_CAR2S2_8_BETA_M_FIELD 2 #define STV090x_OFFST_Px_CAR2S2_8_BETA_E_FIELD 0 @@ -1414,7 +1414,7 @@ #define STV090x_Px_BCLC2S216A(__x) (0xf49e - (__x - 1) * 0x200) #define STV090x_P1_BCLC2S216A STV090x_Px_BCLC2S216A(1) -#define STV090x_P2_BCLC2S216A STV090x_Px_BCLC2S216A(1) +#define STV090x_P2_BCLC2S216A STV090x_Px_BCLC2S216A(2) #define STV090x_OFFST_Px_CAR2S2_16A_BETA_M_FIELD 4 #define STV090x_WIDTH_Px_CAR2S2_16A_BETA_M_FIELD 2 #define STV090x_OFFST_Px_CAR2S2_16A_BETA_E_FIELD 0 @@ -1422,7 +1422,7 @@ #define STV090x_Px_BCLC2S232A(__x) (0xf49f - (__x - 1) * 0x200) #define STV090x_P1_BCLC2S232A STV090x_Px_BCLC2S232A(1) -#define STV090x_P2_BCLC2S232A STV090x_Px_BCLC2S232A(1) +#define STV090x_P2_BCLC2S232A STV090x_Px_BCLC2S232A(2) #define STV090x_OFFST_Px_CAR2S2_32A_BETA_M_FIELD 4 #define STV090x_WIDTH_Px_CAR2S2_32A_BETA_M_FIELD 2 #define STV090x_OFFST_Px_CAR2S2_32A_BETA_E_FIELD 0 @@ -1602,7 +1602,7 @@ #define STV090x_Px_CCIACC(__x) (0xf4c4 - (__x - 1) * 0x200) #define STV090x_P1_CCIACC STV090x_Px_CCIACC(1) -#define STV090x_P2_CCIACC STV090x_Px_CCIACC(1) +#define STV090x_P2_CCIACC STV090x_Px_CCIACC(2) #define STV090x_OFFST_Px_CCI_VALUE_FIELD 0 #define STV090x_WIDTH_Px_CCI_VALUE_FIELD 8 -- 1.6.5.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 06/16] ngene: Clean-up driver initialisation (part 1)
If tuner initialisation failed, the frontend node was not removed.
When the frontend was opened, a kernel oops occurred...
This is the first step to improve error handling during initialisation.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |1 +
drivers/media/dvb/ngene/ngene-core.c | 35
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 5e6b85c..fc93d10 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -113,6 +113,7 @@ static int demod_attach_stv0900(struct ngene_channel *chan)
0, chan->dev->card_info->lnb[chan->number])) {
printk(KERN_ERR DEVICE_NAME ": No LNBH24 found!\n");
dvb_frontend_detach(chan->fe);
+ chan->fe = NULL;
return -ENODEV;
}
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 83fd74e..7ce8737 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1481,23 +1481,32 @@ static int init_channel(struct ngene_channel *chan)
if (io & NGENE_IO_TSIN) {
chan->fe = NULL;
- if (ni->demod_attach[nr])
- ni->demod_attach[nr](chan);
+ if (ni->demod_attach[nr]) {
+ ret = ni->demod_attach[nr](chan);
+ if (ret < 0)
+ goto err_fe;
+ }
+ if (chan->fe && ni->tuner_attach[nr]) {
+ ret = ni->tuner_attach[nr](chan);
+ if (ret < 0)
+ goto err_fe;
+ }
if (chan->fe) {
- if (dvb_register_frontend(adapter, chan->fe) < 0) {
- if (chan->fe->ops.release)
- chan->fe->ops.release(chan->fe);
- chan->fe = NULL;
- }
+ if (dvb_register_frontend(adapter, chan->fe) < 0)
+ goto err_fe;
}
- if (chan->fe && ni->tuner_attach[nr])
- if (ni->tuner_attach[nr] (chan) < 0) {
- printk(KERN_ERR DEVICE_NAME
- ": Tuner attach failed on channel %d!\n",
- nr);
- }
}
return ret;
+
+err_fe:
+ if (chan->fe) {
+ dvb_frontend_detach(chan->fe);
+ chan->fe = NULL;
+ }
+/* FIXME: this causes an oops... */
+/* release_channel(chan);*/
+/* return ret; */
+ return 0;
}
static int init_channels(struct ngene *dev)
--
1.6.5.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 08/16] ngene: Shutdown workaround
From: Ralph Metzler
Implement shutdown workaround for some chipsets.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |1 +
drivers/media/dvb/ngene/ngene-core.c | 37 +
drivers/media/dvb/ngene/ngene.h |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 93e6f9e..6d87427 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -436,6 +436,7 @@ static struct pci_driver ngene_pci_driver = {
.probe = ngene_probe,
.remove = __devexit_p(ngene_remove),
.err_handler = &ngene_errors,
+ .shutdown= ngene_shutdown,
};
static __init int module_init_ngene(void)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 3948e1c..672f7fe 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -45,6 +45,10 @@ static int one_adapter = 1;
module_param(one_adapter, int, 0444);
MODULE_PARM_DESC(one_adapter, "Use only one adapter.");
+static int shutdown_workaround;
+module_param(shutdown_workaround, int, 0644);
+MODULE_PARM_DESC(one_adapter, "Activate workaround for shutdown problem with
some chipsets.");
+
static int debug;
module_param(debug, int, 0444);
MODULE_PARM_DESC(debug, "Print debugging information.");
@@ -1573,6 +1577,39 @@ static void cxd_detach(struct ngene *dev)
ci->en = 0;
}
+/***/
+/* workaround for shutdown failure */
+/***/
+
+static void ngene_unlink(struct ngene *dev)
+{
+ struct ngene_command com;
+
+ com.cmd.hdr.Opcode = CMD_MEM_WRITE;
+ com.cmd.hdr.Length = 3;
+ com.cmd.MemoryWrite.address = 0x910c;
+ com.cmd.MemoryWrite.data = 0xff;
+ com.in_len = 3;
+ com.out_len = 1;
+
+ down(&dev->cmd_mutex);
+ ngwritel(0, NGENE_INT_ENABLE);
+ ngene_command_mutex(dev, &com);
+ up(&dev->cmd_mutex);
+}
+
+void ngene_shutdown(struct pci_dev *pdev)
+{
+ struct ngene *dev = (struct ngene *)pci_get_drvdata(pdev);
+
+ if (!dev || !shutdown_workaround)
+ return;
+
+ printk(KERN_INFO DEVICE_NAME ": shutdown workaround...\n");
+ ngene_unlink(dev);
+ pci_disable_device(pdev);
+}
+
//
/* device probe/remove calls /
//
diff --git a/drivers/media/dvb/ngene/ngene.h b/drivers/media/dvb/ngene/ngene.h
index f783406..c1bb810 100644
--- a/drivers/media/dvb/ngene/ngene.h
+++ b/drivers/media/dvb/ngene/ngene.h
@@ -881,6 +881,7 @@ struct ngene_buffer {
int __devinit ngene_probe(struct pci_dev *pci_dev,
const struct pci_device_id *id);
void __devexit ngene_remove(struct pci_dev *pdev);
+void ngene_shutdown(struct pci_dev *pdev);
int ngene_command(struct ngene *dev, struct ngene_command *com);
int ngene_command_gpio_set(struct ngene *dev, u8 select, u8 level);
void set_transfer(struct ngene_channel *chan, int state);
--
1.6.5.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 00/16] ngene/stv090x: Important fixes and enhancements
[PATCH 01/16] stv090x: make sleep/wakeup specific to the demod path [PATCH 02/16] stv090x: Optional external lock routine [PATCH 03/16] ngene: Firmware 18 support [PATCH 04/16] ngene: Fixes for TS input over I2S [PATCH 05/16] ngene: Support up to 4 tuners [PATCH 06/16] ngene: Clean-up driver initialisation (part 1) [PATCH 07/16] ngene: CXD2099AR Common Interface driver [PATCH 08/16] ngene: Shutdown workaround [PATCH 09/16] ngene: Add net device [PATCH 10/16] ngene: Enable CI for Mystique SaTiX-S2 Dual (v2) [PATCH 11/16] get_dvb_firmware: ngene_18.fw added [PATCH 12/16] ngene: Fix copy-paste error [PATCH 13/16] stv090x: Fixed typos in register macros [PATCH 14/16] stv090x: Fix losing lock in dual DVB-S2 mode [PATCH 15/16] ngene: Improved channel initialisation and release [PATCH 16/16] stv090x: 22kHz workaround must also be performed for the 2nd frontend -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/16] stv090x: make sleep/wakeup specific to the demod path
From: Andreas Regel
The STV0900 features two demodulator paths in one chip. Thus it is not
possible to use the generic power off function of the chip when sending
one of them to standby. The other path will stop working in that case.
The sleep function now switches off functionality specific to the demod
path. The global stuff is only switched off, when both paths are in
sleep mode. The wakeup function always turns on the global functionality
and then works specific to the path.
Signed-off-by: Andreas Regel
Signed-off-by: Oliver Endriss
Signed-off-by: Manu Abraham
---
drivers/media/dvb/frontends/stv090x.c | 211 +
1 files changed, 185 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index 425e7a4..df59207 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3846,6 +3846,7 @@ static int stv090x_sleep(struct dvb_frontend *fe)
{
struct stv090x_state *state = fe->demodulator_priv;
u32 reg;
+ u8 full_standby = 0;
if (stv090x_i2c_gate_ctrl(state, 1) < 0)
goto err;
@@ -3858,24 +3859,119 @@ static int stv090x_sleep(struct dvb_frontend *fe)
if (stv090x_i2c_gate_ctrl(state, 0) < 0)
goto err;
- dprintk(FE_DEBUG, 1, "Set %s to sleep",
- state->device == STV0900 ? "STV0900" : "STV0903");
+ dprintk(FE_DEBUG, 1, "Set %s(%d) to sleep",
+ state->device == STV0900 ? "STV0900" : "STV0903",
+ state->demod);
- reg = stv090x_read_reg(state, STV090x_SYNTCTRL);
- STV090x_SETFIELD(reg, STANDBY_FIELD, 0x01);
- if (stv090x_write_reg(state, STV090x_SYNTCTRL, reg) < 0)
- goto err;
+ mutex_lock(&state->internal->demod_lock);
- reg = stv090x_read_reg(state, STV090x_TSTTNR1);
- STV090x_SETFIELD(reg, ADC1_PON_FIELD, 0);
- if (stv090x_write_reg(state, STV090x_TSTTNR1, reg) < 0)
- goto err;
+ switch (state->demod) {
+ case STV090x_DEMODULATOR_0:
+ /* power off ADC 1 */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR1);
+ STV090x_SETFIELD(reg, ADC1_PON_FIELD, 0);
+ if (stv090x_write_reg(state, STV090x_TSTTNR1, reg) < 0)
+ goto err;
+ /* power off DiSEqC 1 */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR2);
+ STV090x_SETFIELD(reg, DISEQC1_PON_FIELD, 0);
+ if (stv090x_write_reg(state, STV090x_TSTTNR2, reg) < 0)
+ goto err;
+
+ /* check whether path 2 is already sleeping, that is when
+ ADC2 is off */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR3);
+ if (STV090x_GETFIELD(reg, ADC2_PON_FIELD) == 0)
+ full_standby = 1;
+
+ /* stop clocks */
+ reg = stv090x_read_reg(state, STV090x_STOPCLK1);
+ /* packet delineator 1 clock */
+ STV090x_SETFIELD(reg, STOP_CLKPKDT1_FIELD, 1);
+ /* ADC 1 clock */
+ STV090x_SETFIELD(reg, STOP_CLKADCI1_FIELD, 1);
+ /* FEC clock is shared between the two paths, only stop it
+ when full standby is possible */
+ if (full_standby)
+ STV090x_SETFIELD(reg, STOP_CLKFEC_FIELD, 1);
+ if (stv090x_write_reg(state, STV090x_STOPCLK1, reg) < 0)
+ goto err;
+ reg = stv090x_read_reg(state, STV090x_STOPCLK2);
+ /* sampling 1 clock */
+ STV090x_SETFIELD(reg, STOP_CLKSAMP1_FIELD, 1);
+ /* viterbi 1 clock */
+ STV090x_SETFIELD(reg, STOP_CLKVIT1_FIELD, 1);
+ /* TS clock is shared between the two paths, only stop it
+ when full standby is possible */
+ if (full_standby)
+ STV090x_SETFIELD(reg, STOP_CLKTS_FIELD, 1);
+ if (stv090x_write_reg(state, STV090x_STOPCLK2, reg) < 0)
+ goto err;
+ break;
+ case STV090x_DEMODULATOR_1:
+ /* power off ADC 2 */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR3);
+ STV090x_SETFIELD(reg, ADC2_PON_FIELD, 0);
+ if (stv090x_write_reg(state, STV090x_TSTTNR3, reg) < 0)
+ goto err;
+ /* power off DiSEqC 2 */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR4);
+ STV090x_SETFIELD(reg, DISEQC2_PON_FIELD, 0);
+ if (stv090x_write_reg(state, STV090x_TSTTNR4, reg) < 0)
+ goto err;
+
+ /* check whether path 1 is already sleeping, that is when
+ ADC1 is off */
+ reg = stv090x_read_reg(state, STV090x_TSTTNR1);
+ if (STV090x_GETFIELD(reg,
[PATCH 04/16] ngene: Fixes for TS input over I2S
Fix TS input over I2S.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c |4 ++--
drivers/media/dvb/ngene/ngene-dvb.c |5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index e2546f1..83fd74e 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -143,7 +143,7 @@ static void demux_tasklet(unsigned long data)
}
} else {
if (chan->HWState == HWSTATE_RUN) {
- u32 Flags = 0;
+ u32 Flags = chan->DataFormatFlags;
IBufferExchange *exch1 = chan->pBufferExchange;
IBufferExchange *exch2 = chan->pBufferExchange2;
if (Cur->ngeneBuffer.SR.Flags & 0x01)
@@ -474,7 +474,7 @@ static u8 SPDIFConfiguration[10] = {
/* Set NGENE I2S Config to transport stream compatible mode */
-static u8 TS_I2SConfiguration[4] = { 0x3E, 0x1A, 0x00, 0x00 }; /*3e 18 00 00
?*/
+static u8 TS_I2SConfiguration[4] = { 0x3E, 0x18, 0x00, 0x00 };
static u8 TS_I2SOutConfiguration[4] = { 0x80, 0x20, 0x00, 0x00 };
diff --git a/drivers/media/dvb/ngene/ngene-dvb.c
b/drivers/media/dvb/ngene/ngene-dvb.c
index 3832e59..8bb1593 100644
--- a/drivers/media/dvb/ngene/ngene-dvb.c
+++ b/drivers/media/dvb/ngene/ngene-dvb.c
@@ -65,8 +65,11 @@ void *tsin_exchange(void *priv, void *buf, u32 len, u32
clock, u32 flags)
struct ngene_channel *chan = priv;
- if (chan->users > 0)
+ if (chan->users > 0) {
+ if (flags & DF_SWAP32)
+ swap_buffer(buf, len);
dvb_dmx_swfilter(&chan->demux, buf, len);
+ }
return NULL;
}
--
1.6.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] cx23885 errors on Tevii S470
Maybe try the build instructions here: http://www.linuxtv.org/wiki/index.php/TeVii_S470 The driver clearly does not work properly, maybe with a different build it will work. Hans - Oorspronkelijk bericht - Van: "Josu Lazkano" Aan: linux-...@linuxtv.org Verzonden: Maandag 10 januari 2011 00:59:06 Onderwerp: [linux-dvb] cx23885 errors on Tevii S470 Hello list, this is my first post on this mail list. I have a Tevii S470 PCIe DVB-S2 card, I use it with MythTV on a Debian Squeeze (2.6.32-5) machine. I am getting some freeze on channel jump and sometimes I must restart MythTV frontend to get it working. I am using Tevii beta drivers: http://tevii.com/100315_Beta_linux_tevii_ds3000.rar This the dmesg output: [ 4328.642850] cx23885[0]: mpeg risc op code error [ 4328.642873] cx23885[0]: TS1 B - dma channel status dump [ 4328.642883] cx23885[0]: cmds: init risc lo : 0x321af000 [ 4328.642891] cx23885[0]: cmds: init risc hi : 0x [ 4328.642899] cx23885[0]: cmds: cdt base : 0x00010580 [ 4328.642907] cx23885[0]: cmds: cdt size : 0x000a [ 4328.642916] cx23885[0]: cmds: iq base: 0x00010400 [ 4328.642924] cx23885[0]: cmds: iq size: 0x0010 [ 4328.642932] cx23885[0]: cmds: risc pc lo : 0x316c90f0 [ 4328.642939] cx23885[0]: cmds: risc pc hi : 0x [ 4328.642947] cx23885[0]: cmds: iq wr ptr : 0x410c [ 4328.642956] cx23885[0]: cmds: iq rd ptr : 0x4103 [ 4328.642963] cx23885[0]: cmds: cdt current: 0x000105a8 [ 4328.642972] cx23885[0]: cmds: pci target lo : 0x316cd920 [ 4328.642982] cx23885[0]: cmds: pci target hi : 0x [ 4328.642989] cx23885[0]: cmds: line / byte: 0x030e [ 4328.642996] cx23885[0]: risc0: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643012] cx23885[0]: risc1: 0x316cd920 [ INVALID irq1 22 21 19 18 resync 14 12 count=2336 ] [ 4328.643033] cx23885[0]: risc2: 0x [ INVALID count=0 ] [ 4328.643043] cx23885[0]: risc3: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643057] cx23885[0]: (0x00010400) iq 0: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643072] cx23885[0]: iq 1: 0x316cd920 [ arg #1 ] [ 4328.643080] cx23885[0]: iq 2: 0x [ arg #2 ] [ 4328.643087] cx23885[0]: (0x0001040c) iq 3: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643101] cx23885[0]: iq 4: 0x316cdc10 [ arg #1 ] [ 4328.643109] cx23885[0]: iq 5: 0x [ arg #2 ] [ 4328.643117] cx23885[0]: (0x00010418) iq 6: 0x18000100 [ write sol count=256 ] [ 4328.643130] cx23885[0]: iq 7: 0x316cdf00 [ arg #1 ] [ 4328.643138] cx23885[0]: iq 8: 0x [ arg #2 ] [ 4328.643145] cx23885[0]: (0x00010424) iq 9: 0x140001f0 [ write eol count=496 ] [ 4328.643158] cx23885[0]: iq a: 0x316cc000 [ arg #1 ] [ 4328.643166] cx23885[0]: iq b: 0x [ arg #2 ] [ 4328.643173] cx23885[0]: (0x00010430) iq c: 0x [ INVALID count=0 ] [ 4328.643185] cx23885[0]: (0x00010434) iq d: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643199] cx23885[0]: iq e: 0x316cd630 [ arg #1 ] [ 4328.643207] cx23885[0]: iq f: 0x [ arg #2 ] [ 4328.643213] cx23885[0]: fifo: 0x5000 -> 0x6000 [ 4328.643219] cx23885[0]: ctrl: 0x00010400 -> 0x10460 [ 4328.643226] cx23885[0]: ptr1_reg: 0x58f0 [ 4328.643233] cx23885[0]: ptr2_reg: 0x000105b8 [ 4328.643240] cx23885[0]: cnt1_reg: 0x0002 [ 4328.643247] cx23885[0]: cnt2_reg: 0x0003 [ 4328.643279] cx23885[0]: mpeg risc op code error [ 4328.643287] cx23885[0]: TS1 B - dma channel status dump [ 4328.643295] cx23885[0]: cmds: init risc lo : 0x321af000 [ 4328.643303] cx23885[0]: cmds: init risc hi : 0x [ 4328.643312] cx23885[0]: cmds: cdt base : 0x00010580 [ 4328.643319] cx23885[0]: cmds: cdt size : 0x000a [ 4328.643328] cx23885[0]: cmds: iq base: 0x00010400 [ 4328.643335] cx23885[0]: cmds: iq size: 0x0010 [ 4328.643343] cx23885[0]: cmds: risc pc lo : 0x316c90f0 [ 4328.643352] cx23885[0]: cmds: risc pc hi : 0x [ 4328.643361] cx23885[0]: cmds: iq wr ptr : 0x410c [ 4328.643369] cx23885[0]: cmds: iq rd ptr : 0x4103 [ 4328.643377] cx23885[0]: cmds: cdt current: 0x000105a8 [ 4328.643386] cx23885[0]: cmds: pci target lo : 0x316cd920 [ 4328.643395] cx23885[0]: cmds: pci target hi : 0x [ 4328.643403] cx23885[0]: cmds: line / byte: 0x030e [ 4328.643411] cx23885[0]: risc0: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643425] cx23885[0]: risc1: 0x316cd920 [ INVALID irq1 22 21 19 18 resync 14 12 count=2336 ] [ 4328.643446] cx23885[0]: risc2: 0x [ INVALID count=0 ] [ 4328.643457] cx23885[0]: risc3: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643470] cx23885[0]: (0x00010400) iq 0: 0x1c0002f0 [ write sol eol count=752 ] [ 4328.643485] cx23885[0]: iq 1: 0x316cd920 [ arg #1 ] [ 4328.643493] cx23885[0]: iq 2: 0x [ arg #2 ] [ 4328.643500] cx23885[0]: (0x0001040c) iq 3: 0x1c0002f0 [ writ
RE: [PATCH] [media] v4l: soc-camera: add enum-frame-size ioctl
On Sun, 9 Jan 2011, Qing Xu wrote:
> On Mon, 10 Jan 2011, Qing Xu wrote:
>
> > On Fri, 7 Jan 2011, Guennadi Liakhovetski wrote:
>
> > On Fri, 7 Jan 2011, Qing Xu wrote:
> >
> > > pass VIDIOC_ENUM_FRAMESIZES down to sub device drivers. So far no
> > > special handling in soc-camera core.
> >
> > Hm, no, guess what? I don't think this can work. The parameter, that this
> > routine gets from the user struct v4l2_frmsizeenum contains a member
> > pixel_format, which is a fourcc code. Whereas subdevices don't deal with
> > them, they deal with mediabus codes. It is the same problem as with old
> > s/g/try/enum_fmt, which we replaced with respective mbus variants. So, we
> > either have to add our own .enum_mbus_framesizes video subdevice
> > operation, or we abuse this one, but interpret the pixel_format field as a
> > media-bus code.
> >
> > Currently I only see one subdev driver, that implements this API:
> > ov7670.c, and it just happily ignores the pixel_format altogether...
> >
> > Hans, Laurent, what do you think?
> >
> > In the soc-camera case you will have to use soc_camera_xlate_by_fourcc()
> > to convert to media-bus code from fourcc. A nit-pick: please, follow the
> > style of the file, that you patch and don't add double empty lines between
> > functions.
> >
> > A side question: why do you need this format at all? Is it for some custom
>
> > Sorry, I meant to ask - what do you need this operation / ioctl() for?
>
> Hi Guennadi,
>
> Before we launch camera application, we will use enum-frame-size ioctl
> to get all frame size that the sensor supports, and show all options in
> UI menu, then the customers could choose a size, and tell camera driver.
And if the camera supports ranges of sizes? Or doesn't implement this
ioctl() at all? Remember, that this is an optional ioctl(). Would your
application just fail? Or you could provide a slider to let the user
select a size from a range, then just issue an s_fmt and use whatever it
returns... This is something you'd do for a generic application
> If use mbus structure pass to sensor, we need to modify the second
> parameter definition, it will contain both mbus code information and
> width/height ingotmation:
> int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
> *fsize);
>
> or use g_mbus_fmt instead:
> int (*g_mbus_fmt)(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *fmt);
> soc_camera_enum_framesizes()
> {
> ...
> return v4l2_subdev_call(sd, video, g_mbus_fmt, fsize);//typo, I mean
> "g_mbus_fmt"
> }
>
> What do you think?
In any case therer needs to be a possibility for host drivers to override
this routine, so, please, do something similar, to what default_g_crop() /
default_s_crop() / default_cropcap() / default_g_parm() / default_s_parm()
do: add a host operation and provide a default implementation for it. And
since noone seems to care enough, I think, we can just abuse struct
v4l2_frmsizeenum for now, just make sure to rewrite pixel_format to a
media-bus code, and restore it before returning to the caller.
Thanks
Guennadi
> Thanks!
> Qing
>
> > application? What is your use-case, that makes try_fmt / s_fmt
> > insufficient for you and how does enum_framesizes help you?
> >
> > Thanks
> > Guennadi
> >
> > >
> > > Signed-off-by: Kassey Lee
> > > Signed-off-by: Qing Xu
> > > ---
> > > drivers/media/video/soc_camera.c | 11 +++
> > > 1 files changed, 11 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/media/video/soc_camera.c
> > > b/drivers/media/video/soc_camera.c
> > > index 052bd6d..11715fb 100644
> > > --- a/drivers/media/video/soc_camera.c
> > > +++ b/drivers/media/video/soc_camera.c
> > > @@ -145,6 +145,16 @@ static int soc_camera_s_std(struct file *file, void
> > > *priv, v4l2_std_id *a)
> > > return v4l2_subdev_call(sd, core, s_std, *a);
> > > }
> > >
> > > +static int soc_camera_enum_framesizes(struct file *file, void *fh,
> > > +struct v4l2_frmsizeenum *fsize)
> > > +{
> > > + struct soc_camera_device *icd = file->private_data;
> > > + struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
> > > +
> > > + return v4l2_subdev_call(sd, video, enum_framesizes, fsize);
> > > +}
> > > +
> > > +
> > > static int soc_camera_reqbufs(struct file *file, void *priv,
> > > struct v4l2_requestbuffers *p)
> > > {
> > > @@ -1302,6 +1312,7 @@ static const struct v4l2_ioctl_ops
> > > soc_camera_ioctl_ops = {
> > > .vidioc_g_input = soc_camera_g_input,
> > > .vidioc_s_input = soc_camera_s_input,
> > > .vidioc_s_std= soc_camera_s_std,
> > > + .vidioc_enum_framesizes = soc_camera_enum_framesizes,
> > > .vidioc_reqbufs = soc_camera_reqbufs,
> > > .vidioc_try_fmt_vid_cap = soc_camera_try_fmt_vid_cap,
> > > .vidioc_querybuf = soc_camera_querybuf,
> > > --
> > > 1.6.3.3
> > >
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
>
Technisat Skystar USB plus works
Hello, I own a Technisat Skystar USB Plus DVB-S receiver. It's a rebranded Technotrend Connect S-2400, but the device-ID is different. Output of lsusb: Bus 001 Device 012: ID 0b48:3009 TechnoTrend AG I changed the device-ID of the Technotrend Connect s-2400 in /media_build/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h from 0x3006 to 0x3009. #define USB_PID_TECHNOTREND_CONNECT_S2400 0x3009 After building and installing the drivers and a reboot the device works without problems with Ubuntu 10.10. Please add support for the Technotrend Connect S-2400 with PID 0x3009 to the v4l-sources. Greetings Carsten Wehmeier -- 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
