Re: [PATCH v2 4/7] FMTx: si4713: Add files to handle si4713 i2c device
On Tue, 2009-05-12 at 08:22 +0300, Eero Nurkkala wrote:
+ /* Australia */
+ {
+ .channel_spacing= 20,
+ .bottom_frequency = 8750,
+ .top_frequency = 10800,
+ .preemphasis= 1,
+ .region = 1,
+ },
Hi,
Australia must be 88.1 - 107.9 with 10 channel spacing.
- Eero
--
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 v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
Hi Eero,
On Tue, May 12, 2009 at 06:49:25AM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu)
wrote:
On Mon, 2009-05-11 at 11:31 +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
+enum v4l2_fmtx_preemphasis {
+ V4L2_FMTX_PREEMPHASIS_75_uS = 0,
+ V4L2_FMTX_PREEMPHASIS_50_uS = 1,
+ V4L2_FMTX_PREEMPHASIS_DISABLED = 2,
+};
Hello there,
Would it make more sense to make:
V4L2_FMTX_PREEMPHASIS_DISABLED as zero (false). In my opinion,
that would be more clear.
Indeed,
Something like:
enum v4l2_fmtx_preemphasis {
V4L2_FMTX_PREEMPHASIS_DISABLED = 0,
V4L2_FMTX_PREEMPHASIS_50_uS = 1,
V4L2_FMTX_PREEMPHASIS_75_uS = 2,
};
looks better?
- Eero
--
Eduardo Valentin
--
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
about exact usage of definition - Control Flags in videodev.h
Hello Hans, Nice to meet u on the mailing-list. I'm an engineer of camera device driver, and work with Nathaniel(Dongsoo, Kim). I'm wondering about how to use the Control Flags defined in the videodev2.h. The Control Flags defined in the videodev2.h is the following as you know, /* Control flags */ #define V4L2_CTRL_FLAG_DISABLED 0x0001 #define V4L2_CTRL_FLAG_GRABBED 0x0002 #define V4L2_CTRL_FLAG_READ_ONLY0x0004 #define V4L2_CTRL_FLAG_UPDATE 0x0008 #define V4L2_CTRL_FLAG_INACTIVE 0x0010 #define V4L2_CTRL_FLAG_SLIDER 0x0020 I tryed to find the usage of this definitions in the directories of drivers/media/video include/, but I didn't. Actually, I need to use this definitions for checking of ISP status. So, I wanna know exact usage of this definitions to make the generic driver code. i'll appreciate your answer beforehand. Thanks to read. Regard, riverful (HeungJun, Kim) -- 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 v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
On Tue, May 12, 2009 at 04:17:03AM +0200, ext Mauro Carvalho Chehab wrote:
Em Mon, 11 May 2009 12:31:43 +0300
Eduardo Valentin eduardo.valen...@nokia.com escreveu:
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/linux/videodev2.h | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ebb2ea6..7559299 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -803,6 +803,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FMTX 0x009b/* FM Radio Modulator class
controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,50 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS(V4L2_CTRL_CLASS_FMTX |
1)
+
+#define V4L2_CID_RDS_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME
(V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FMTX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD
(V4L2_CID_FMTX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME
(V4L2_CID_FMTX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FMTX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE + 16)
+
+#define V4L2_CID_REGION
(V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_region {
+ V4L2_FMTX_REGION_USA= 0,
+ V4L2_FMTX_REGION_AUSTRALIA = 1,
+ V4L2_FMTX_REGION_EUROPE = 2,
+ V4L2_FMTX_REGION_JAPAN = 3,
+ V4L2_FMTX_REGION_JAPAN_WIDE_BAND= 4,
+};
Hmm... the region is not just a derived parameter, based on
preemphasis/frequencies, and channel stepping? What this parameter controls?
Hi Mauro, I thought in the opposite way. The other parameters are derived
from the region parameter. So, you just set the region, then it will affect
the frequency range, channel stepping and preemphasis.
However, there was some resistance to have this inside kernel
(in previous discussion). One suggested to use database in user land
(or similar thing). In that case, driver(s) would
report its constraints based on device values, not in region settings.
But, this patch set is proposing to have it inside the kernel as you can see.
I'd like to hear more opinions though.
+#define V4L2_CID_REGION_BOTTOM_FREQUENCY (V4L2_CID_FMTX_CLASS_BASE + 18)
+#define V4L2_CID_REGION_TOP_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE + 19)
+#define V4L2_CID_REGION_PREEMPHASIS
(V4L2_CID_FMTX_CLASS_BASE + 20)
+enum v4l2_fmtx_preemphasis {
+ V4L2_FMTX_PREEMPHASIS_75_uS = 0,
+ V4L2_FMTX_PREEMPHASIS_50_uS = 1,
+ V4L2_FMTX_PREEMPHASIS_DISABLED = 2,
+};
+#define V4L2_CID_REGION_CHANNEL_SPACING
(V4L2_CID_FMTX_CLASS_BASE + 21)
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FMTX_CLASS_BASE + 22)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FMTX_CLASS_BASE + 23)
+
/*
* T U N I N G
*/
Cheers,
Mauro
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
Re: about exact usage of definition - Control Flags in videodev.h
On Tuesday 12 May 2009 08:12:35 Kim, Heung Jun wrote: Hello Hans, Nice to meet u on the mailing-list. I'm an engineer of camera device driver, and work with Nathaniel(Dongsoo, Kim). I'm wondering about how to use the Control Flags defined in the videodev2.h. The Control Flags defined in the videodev2.h is the following as you know, /* Control flags */ #define V4L2_CTRL_FLAG_DISABLED 0x0001 #define V4L2_CTRL_FLAG_GRABBED0x0002 #define V4L2_CTRL_FLAG_READ_ONLY 0x0004 #define V4L2_CTRL_FLAG_UPDATE 0x0008 #define V4L2_CTRL_FLAG_INACTIVE 0x0010 #define V4L2_CTRL_FLAG_SLIDER 0x0020 I tryed to find the usage of this definitions in the directories of drivers/media/video include/, but I didn't. Actually, I need to use this definitions for checking of ISP status. So, I wanna know exact usage of this definitions to make the generic driver code. i'll appreciate your answer beforehand. Thanks to read. Regard, riverful (HeungJun, Kim) The V4L2 API spec is here: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html And you can find a description of these flags here: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#VIDIOC-QUERYCTRL Let me know if you have questions not answered in the spec. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
Hi Mauro,
On Tue, May 12, 2009 at 04:12:31AM +0200, ext Mauro Carvalho Chehab wrote:
Em Mon, 11 May 2009 12:31:43 +0300
Eduardo Valentin eduardo.valen...@nokia.com escreveu:
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Eduardo,
Please provide us a patch also for V4L2 API for the new API controls you're
adding. I'll hold the analysis of the patch series until you provide us the
docs. So, there's no need to resubmit the entire patch series.
The V4L2 API is maintained together with the mercurial development tree, at:
http://linuxtv.org/hg/v4l-dvb/
Right. That's something I was looking for. Thanks for the directions. I'll
submit the docs then.
under v4l2-spec/ directory.
Cheers,
Mauro.
---
include/linux/videodev2.h | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ebb2ea6..7559299 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -803,6 +803,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FMTX 0x009b/* FM Radio Modulator class
controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,50 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS(V4L2_CTRL_CLASS_FMTX |
1)
+
+#define V4L2_CID_RDS_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME
(V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FMTX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD
(V4L2_CID_FMTX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME
(V4L2_CID_FMTX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FMTX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE + 16)
+
+#define V4L2_CID_REGION
(V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_region {
+ V4L2_FMTX_REGION_USA= 0,
+ V4L2_FMTX_REGION_AUSTRALIA = 1,
+ V4L2_FMTX_REGION_EUROPE = 2,
+ V4L2_FMTX_REGION_JAPAN = 3,
+ V4L2_FMTX_REGION_JAPAN_WIDE_BAND= 4,
+};
+#define V4L2_CID_REGION_BOTTOM_FREQUENCY (V4L2_CID_FMTX_CLASS_BASE + 18)
+#define V4L2_CID_REGION_TOP_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE + 19)
+#define V4L2_CID_REGION_PREEMPHASIS
(V4L2_CID_FMTX_CLASS_BASE + 20)
+enum v4l2_fmtx_preemphasis {
+ V4L2_FMTX_PREEMPHASIS_75_uS = 0,
+ V4L2_FMTX_PREEMPHASIS_50_uS = 1,
+ V4L2_FMTX_PREEMPHASIS_DISABLED = 2,
+};
+#define V4L2_CID_REGION_CHANNEL_SPACING
(V4L2_CID_FMTX_CLASS_BASE + 21)
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FMTX_CLASS_BASE + 22)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FMTX_CLASS_BASE + 23)
+
/*
* T U N I N G
*/
Cheers,
Mauro
--
Eduardo Valentin
--
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 v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
On Tuesday 12 May 2009 08:10:43 Eduardo Valentin wrote:
On Tue, May 12, 2009 at 04:17:03AM +0200, ext Mauro Carvalho Chehab wrote:
Em Mon, 11 May 2009 12:31:43 +0300
Eduardo Valentin eduardo.valen...@nokia.com escreveu:
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/linux/videodev2.h | 45
+ 1 files changed, 45
insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ebb2ea6..7559299 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -803,6 +803,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098 /* Old-style 'user' controls
*/ #define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression
controls */ #define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class
controls */ +#define V4L2_CTRL_CLASS_FMTX 0x009b /* FM Radio
Modulator class controls */
#define V4L2_CTRL_ID_MASK (0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,50 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS (V4L2_CTRL_CLASS_FMTX |
1)
+
+#define V4L2_CID_RDS_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME
(V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FMTX_CLASS_BASE +
6) +#define
V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE +
8) +
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED
(V4L2_CID_FMTX_CLASS_BASE
+ 9) +#define
V4L2_CID_AUDIO_COMPRESSION_GAIN (V4L2_CID_FMTX_CLASS_BASE + 10)
+#define
V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FMTX_CLASS_BASE + 11)
+#define
V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME(V4L2_CID_FMTX_CLASS_BASE +
12) +#define
V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME (V4L2_CID_FMTX_CLASS_BASE +
13) +
+#define V4L2_CID_PILOT_TONE_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FMTX_CLASS_BASE +
15) +#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE
+ 16) +
+#define V4L2_CID_REGION
(V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_region {
+ V4L2_FMTX_REGION_USA= 0,
+ V4L2_FMTX_REGION_AUSTRALIA = 1,
+ V4L2_FMTX_REGION_EUROPE = 2,
+ V4L2_FMTX_REGION_JAPAN = 3,
+ V4L2_FMTX_REGION_JAPAN_WIDE_BAND= 4,
+};
Hmm... the region is not just a derived parameter, based on
preemphasis/frequencies, and channel stepping? What this parameter
controls?
Hi Mauro, I thought in the opposite way. The other parameters are derived
from the region parameter. So, you just set the region, then it will
affect the frequency range, channel stepping and preemphasis.
However, there was some resistance to have this inside kernel
(in previous discussion). One suggested to use database in user land
(or similar thing). In that case, driver(s) would
report its constraints based on device values, not in region settings.
But, this patch set is proposing to have it inside the kernel as you can
see.
I'd like to hear more opinions though.
I'm opposed to having this in the kernel. This is something that can go into
e.g. libv4l2util (in the v4l2-apps directory). If only because this is very
much application dependent. Your code assumes a few regions, but I think it
is much more common that applications will allow customers to select a
country, so that means you need a mapping from country to region. And some
countries may use a different range than you think (I doubt you know the
frequency ranges for all the countries in the world!) and having a table
for all countries in the kernel is simply not the right approach.
Also, such a table definitely does not belong with any particular driver,
but should be common code.
The only reason why such a table might end up in the kernel is if there
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-dev
On Mon, 11 May 2009, Mauro Carvalho Chehab wrote: Em Mon, 11 May 2009 22:09:26 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 9 May 2009 16:49:31 -0500 (CDT) Mike Isely is...@isely.net escreveu: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for various pvrusb2 changesets. Several have to do with IR as previously discussed with Jean Delvare. He's waiting for these changes. Other stuff is more of a miscellaneous / cleanup nature. Hmm... this one failed when importing on -git: Changeset: 11749 From: Greg Kroah-Hartman gre...@suse.de Commiter: Mike Isely is...@pobox.com Date: Fri May 01 22:36:33 2009 -0500 Subject: pvrusb2: remove driver_data direct access of struct device In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Priority: normal Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org $ patch -p1 -i 11749.patch patching file drivers/media/video/pvrusb2/pvrusb2-sysfs.c Reversed (or previously applied) patch detected! Assume -R? [n] It seems that you've got a Greg's patch, removed the parts that touch on other files, applied on your tree and asked me to merge it. Please, never do it, since this will cause merge problems when exporting the patches to git. Next time, just reply with an acked-by, and let Patchwork to add your ack on the original patch. I in fact did what you are asking for here (i.e. wait for it to show up on its own) before for another change that got rid of usb_settoggle(). It took a LONG time - WEEKS - for that fix to get back into v4l-dvb via the mechanism you just described. And this had the effect of breaking the v4l-dvb repository for a period of time when the kernel mainline then unpublished the usb_settoggle() function. I do NOT like to see that happen. That caused me to decide not to rely on what you are now telling me to do. I also disagree with this for another reason. What happens if, say, Greg generates a patch that I need before I can proceed with other changes? Do I just sit around and wait for it to trickle back before I can continue? That seems wrong. In addition in the past when there have been pvrusb2 changes generated from upstream you have asked if I was planning on pulling them in myself - which I've done in the past. It seems wrong on its face to tell me that I can't go get a patch that affects my driver. AND... In the case of the remove usb_settoggle() patch, I *DID* in fact add my acked-by to that patch. Greg dutifully took note of this and ensured it was part of the git patch. However when it got back into v4l-dvb, the acked-by attribution was missing. I complained about this to you and your response was that this was a fault of the pathway / mechanism and that I should basically accept this. So now you're telling me to do this anyway? Whatever. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 0/2] V4L: Add BCM2048 radio driver
On Monday 11 May 2009 08:41:17 ext-eero.nurkk...@nokia.com wrote: From: Eero Nurkkala ext-eero.nurkk...@nokia.com This patchset adds the BCM2048 radio driver code. BCM2048 is radio is integrated in the BCM2048 chipset that contains the Bluetooth also. There's quite some sysfs entries introduced here; But only a very few of them is meant to be used besides debugging/experimental purposes: rds (rds switch, off/on) fm_search_rssi_threshold (threshold for V4L2_CAP_HW_FREQ_SEEK) region (current region information) region_bottom_frequency region_top_frequency Unlike V4L2 suggests, the code has also a reference implementation for a partial RDS decoder; I understand that this should be done in userspace. However, the decoded RDS data may be read off from the sysfs nodes also: rds_pi (RDS PI code) rds_rt (RDS Radio Text) rds_ps (RDS PS) It would be nice to know, how RDS enabling/disabling takes place in V4L2. I've made an RFC which describes the finishing touches for the RDS API: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html I should have some time next week to finally implement this in the v4l-dvb tree. I recommend that you move the RDS decoder code into an rds library in the v4l2-apps directory of the v4l-dvb tree. As you say, the rds decoder implementation does not belong in the driver, but it would be very nice to have it as a library. Below is the list of all sysfs entries; However, like mentioned, only the above (8) sysfs nodes should be used along with the V4L2. The sysfs nodes below, with the exception of the 8 ones above, should only be used for debugging/experiments only. And they do a good job for such purposes ;) audio_route (DAC, I2S) dac_output (OFF, LEFT, RIGHT, LEFT/RIGHT) fm_af_frequency (Alternate Frequency) fm_best_tune_mode (Best tune mode; tuning method) fm_carrier_error (FM carrier error) fm_deemphasis (De-emphasis) fm_frequency (frequency) fm_hi_lo_injection (Injection control) fm_rds_flags (RDS IRQ flags) fm_rds_mask (RDS IRQ Mask) fm_rssi (Current channel RSSI level) fm_search_mode_direction (UP, DOWN) fm_search_rssi_threshold (HW seek threshold search level) fm_search_tune_mode (stop all, preset, hw seek, AF jump) mute (off, on) power_state (off, on) rds (off, on) rds_b_block_mask (RDS b block IRQ mask) rds_b_block_match (RDS b block IRQ match) rds_data (Raw RDS data for debugging) rds_pi (RDS PI code) rds_pi_mask (RDS PI mask) rds_pi_match (RDS PI match) rds_ps (RDS PS) rds_rt (RDS radiotext) rds_wline (RDS FIFO watermark level) region region_bottom_frequency region_top_frequency Such region tables do not belong in a driver IMHO. These too should go to a userspace library (libv4l2util? It already contains frequency tables for TV). A more general comment: this driver should be split into two parts: the radio tuner core should really be implemented using the tuner API similar to the tea5767 radio tuner driver. That way this radio tuner driver can be reused when it is placed on e.g. a TV tuner card. However, the tuner API is missing functionality for e.g. RDS. Alternatively, the core driver can be rewritten as an v4l2_subdev driver, again allowing reuse in other drivers. I would like to see some input from others on this. I think that it would help the integration of v4l and dvb enormously if dvb starts using the standard i2c kernel API: that API offers all the functionality that dvb needs now that it no longer uses autoprobing. Perhaps a topic for the Plumbers conference later this year? Regards, Hans All comments are very welcome! Like mentioned, I'm aware of the somewhat ugly set of syfs nodes. For debugging/experiments, I would guess they're not that bad; but for real usage, they should be integrated into the V4L2? Eero Nurkkala (2): V4L: Add BCM2048 radio driver V4L: Add BCM2048 radio driver Makefile and Kconfig dependencies drivers/media/radio/Kconfig | 10 + drivers/media/radio/Makefile|1 + drivers/media/radio/radio-bcm2048.c | 2613 +++ include/media/radio-bcm2048.h | 30 + 4 files changed, 2654 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-bcm2048.c create mode 100644 include/media/radio-bcm2048.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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 v2 0/7] [RFC] FM Transmitter (si4713) and another changes
On Monday 11 May 2009 11:31:42 Eduardo Valentin wrote: Hello all, It took a few but I'm resending the FM transmitter driver again. Sorry for this delay, but I had another things to give attention. Anyway, after reading the API and re-writing the code I came up with the following 7 patches. Three of them are in the v4l2 API. The other 4 are for the si4713 device. It is because of the first 3 patches that I'm sending this as a RFC. The first and second patches, as suggested before, are creating another v4l2 extended controls class, the V4L2_CTRL_CLASS_FMTX. At this first interaction, I've put all si4713 device extra properties there. But I think that some of the can be moved to private class (V4L2_CID_PRIVATE_BASE). That's the case of the region related things. Comments are wellcome. The third patch came *maybe* because I've misunderstood something. But I realized that the v4l2-subdev helper functions for I2C devices assumes that the bridge device will create an I2C adaptor. And in that case, only I2C address and its type are suffient. But in this case, makes no sense to me to create an adaptor for the si4713 platform device driver. This is the case where the device (si4713) is connected to an existing adaptor. That's why I've realized that currently there is no way to pass I2C board info using the current v4l2 I2C helper functions. Other info like irq line and platform data are not passed to subdevices. So, that's why I've created that patch. I've made several changes to the v4l2-subdev helpers: you now pass the i2c adapter directly. I've also fixed the unregister code to properly unregister any i2c client so you can safely rmmod and modprobe the i2c module. What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Regards, Hans The remaining patches are the si4713 device driver itself. As suggested, I've splited the driver into i2c driver and v4l2 radio driver. The first one is exporting it self as a v4l2 subdev as well. Now it is composed by the si4713.c and si4713-subdev.c. But in the future versions I think I'll merge both and remove the si4713.c (by reducing lots of things), because it was mainly designed to be used by the sysfs interface. I've also keeped the sysfs interface (besides the extended control interface). The v4l2 radio driver became a platform driver which is mainly a wrapper to the I2C subdevice. Again here I've found some problem with the device remove. Because, as the I2C helper function assumes the bridge device will create an adaptor, then when the bridge removes the adaptor, its devices will be removed as well. So, when re-inserting the driver, registration will be good. However, if we use an existing adaptor, then we need to remove the i2c client manually. Otherwise it will fail when re-inserting the device. As I said before, comments are wellcome. I'm mostly to be misunderstanding something from the API. BR, Eduardo Valentin (7): v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls v4l2: video device: Add FMTX controls default configurations v4l2_subdev i2c: Add i2c board info to v4l2_i2c_new_subdev FMTx: si4713: Add files to handle si4713 i2c device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries FMTx: si4713: Add document file Documentation/video4linux/si4713.txt | 132 ++ drivers/media/radio/Kconfig | 22 + drivers/media/radio/Makefile |3 + drivers/media/radio/radio-si4713.c | 345 ++ drivers/media/radio/radio-si4713.h | 48 + drivers/media/radio/si4713-subdev.c | 1045 drivers/media/radio/si4713.c | 2250 ++ drivers/media/radio/si4713.h | 295 + drivers/media/video/v4l2-common.c| 99 ++- include/linux/videodev2.h| 45 + include/media/v4l2-common.h |6 + 11 files changed, 4284 insertions(+), 6 deletions(-) create mode 100644 Documentation/video4linux/si4713.txt create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713-subdev.c create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH 0/2] V4L: Add BCM2048 radio driver
On Tue, 2009-05-12 at 08:51 +0200, ext Hans Verkuil wrote: I recommend that you move the RDS decoder code into an rds library in the v4l2-apps directory of the v4l-dvb tree. As you say, the rds decoder implementation does not belong in the driver, but it would be very nice to have it as a library. Quick question, is there a RDS decoder library already out there? Or would it be the case it needs to be done from the scratch? Such region tables do not belong in a driver IMHO. These too should go to a userspace library (libv4l2util? It already contains frequency tables for TV). That's correct. Is there a link to this library? A more general comment: this driver should be split into two parts: the radio tuner core should really be implemented using the tuner API similar to the tea5767 radio tuner driver. That way this radio tuner driver can be reused when it is placed on e.g. a TV tuner card. However, the tuner API is missing functionality for e.g. RDS. Alternatively, the core driver can be rewritten as an v4l2_subdev driver, again allowing reuse in other drivers. Hmm. This chip is integrated on Bluetooth silicon, so could you please elaborate how it could be reused with a TV tuner? (Maybe I didn't just get the point, or if the manufacturer decides to integrate (in the future) the chip with TV tuner card, or someone wishes to use other manufacturers' TV tuner, but this radio chip at the same time?) I would like to see some input from others on this. I think that it would help the integration of v4l and dvb enormously if dvb starts using the standard i2c kernel API: that API offers all the functionality that dvb needs now that it no longer uses autoprobing. Perhaps a topic for the Plumbers conference later this year? All comments welcome, - Eero -- 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 0/2] V4L: Add BCM2048 radio driver
On Tuesday 12 May 2009 09:03:42 Eero Nurkkala wrote: On Tue, 2009-05-12 at 08:51 +0200, ext Hans Verkuil wrote: I recommend that you move the RDS decoder code into an rds library in the v4l2-apps directory of the v4l-dvb tree. As you say, the rds decoder implementation does not belong in the driver, but it would be very nice to have it as a library. Quick question, is there a RDS decoder library already out there? Or would it be the case it needs to be done from the scratch? Yes, here: http://rdsd.berlios.de/ However, it's badly written and overly complicated. We need something much simpler, doing just the basic decoding. Such region tables do not belong in a driver IMHO. These too should go to a userspace library (libv4l2util? It already contains frequency tables for TV). That's correct. Is there a link to this library? It's in the v4l2-apps directory of the main v4l-dvb repository. A more general comment: this driver should be split into two parts: the radio tuner core should really be implemented using the tuner API similar to the tea5767 radio tuner driver. That way this radio tuner driver can be reused when it is placed on e.g. a TV tuner card. However, the tuner API is missing functionality for e.g. RDS. Alternatively, the core driver can be rewritten as an v4l2_subdev driver, again allowing reuse in other drivers. Hmm. This chip is integrated on Bluetooth silicon, so could you please elaborate how it could be reused with a TV tuner? (Maybe I didn't just get the point, or if the manufacturer decides to integrate (in the future) the chip with TV tuner card, or someone wishes to use other manufacturers' TV tuner, but this radio chip at the same time?) Hmm, I need to think about this. BTW, is there a datasheet of some kind available for this chip? Regards, Hans I would like to see some input from others on this. I think that it would help the integration of v4l and dvb enormously if dvb starts using the standard i2c kernel API: that API offers all the functionality that dvb needs now that it no longer uses autoprobing. Perhaps a topic for the Plumbers conference later this year? All comments welcome, - Eero -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 3/3] OMAP2/3 V4L2 Display Driver
Hi Inki,
I was on vacation just came,
Below are my comments.
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 6:19 PM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Thank you Shah, Hardik.
I have patched your driver through that git.
but your patch recognizes video2 layer as video1 device node in case
that DSS2 has fb0 and fb1.
[Shah, Hardik] There is no need to change the nodes. If there is only one
video device present than it should be /dev/video1 and not /dev/video2. Its
upto the driver to use which video pipeline 1 or 2. So let the node
nomenclature be same.
Regards,
Hardik
you said my patch will give rise to couple of more bugs related to
global_alpha and pixel formats
maybe that would be because of vout-vid_info.id = k + vout_count;
so I have applied your patch to my way.
this patch is more flexible and recognizes video2 layer correctly as
video2 device node.
--
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2204,7 +2204,7 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2212,6 +2212,8 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
struct omap2video_device *vid_dev = container_of(v4l2_dev, struct
omap2video_device, v4l2_dev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2225,12 +2227,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_dev = vid_dev;
- /* Select video2 if only 1 overlay is controlled by V4L2 */
- if (pdev-num_resources == 1)
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 2];
- else
- /* Else select video1 and video2 one by one. */
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k +
vout_count];
vout-vid_info.num_overlays = 1;
vout-vid_info.id = k + 1;
vid_dev-num_videos++;
@@ -2253,7 +2250,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) 0) {
printk(KERN_ERR VOUT_NAME : could not register
Video for Linux device\n);
vfd-minor = -1
--
--
-
2009/4/30 Shah, Hardik hardik.s...@ti.com:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
Re: [PATCH v2 0/7] [RFC] FM Transmitter (si4713) and another changes
On Tue, May 12, 2009 at 09:03:18AM +0200, ext Hans Verkuil wrote: On Monday 11 May 2009 11:31:42 Eduardo Valentin wrote: Hello all, It took a few but I'm resending the FM transmitter driver again. Sorry for this delay, but I had another things to give attention. Anyway, after reading the API and re-writing the code I came up with the following 7 patches. Three of them are in the v4l2 API. The other 4 are for the si4713 device. It is because of the first 3 patches that I'm sending this as a RFC. The first and second patches, as suggested before, are creating another v4l2 extended controls class, the V4L2_CTRL_CLASS_FMTX. At this first interaction, I've put all si4713 device extra properties there. But I think that some of the can be moved to private class (V4L2_CID_PRIVATE_BASE). That's the case of the region related things. Comments are wellcome. The third patch came *maybe* because I've misunderstood something. But I realized that the v4l2-subdev helper functions for I2C devices assumes that the bridge device will create an I2C adaptor. And in that case, only I2C address and its type are suffient. But in this case, makes no sense to me to create an adaptor for the si4713 platform device driver. This is the case where the device (si4713) is connected to an existing adaptor. That's why I've realized that currently there is no way to pass I2C board info using the current v4l2 I2C helper functions. Other info like irq line and platform data are not passed to subdevices. So, that's why I've created that patch. I've made several changes to the v4l2-subdev helpers: you now pass the i2c adapter directly. I've also fixed the unregister code to properly unregister any i2c client so you can safely rmmod and modprobe the i2c module. Right. I will check those. What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Yes, sure. Well, a simple set_power procedure is an example of things that I see as platform specific. Which may be passed by platform data structures. In some platform a set power / reset line may be done by a simple gpio. but in others it may be a different procedure. Regards, Hans The remaining patches are the si4713 device driver itself. As suggested, I've splited the driver into i2c driver and v4l2 radio driver. The first one is exporting it self as a v4l2 subdev as well. Now it is composed by the si4713.c and si4713-subdev.c. But in the future versions I think I'll merge both and remove the si4713.c (by reducing lots of things), because it was mainly designed to be used by the sysfs interface. I've also keeped the sysfs interface (besides the extended control interface). The v4l2 radio driver became a platform driver which is mainly a wrapper to the I2C subdevice. Again here I've found some problem with the device remove. Because, as the I2C helper function assumes the bridge device will create an adaptor, then when the bridge removes the adaptor, its devices will be removed as well. So, when re-inserting the driver, registration will be good. However, if we use an existing adaptor, then we need to remove the i2c client manually. Otherwise it will fail when re-inserting the device. As I said before, comments are wellcome. I'm mostly to be misunderstanding something from the API. BR, Eduardo Valentin (7): v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls v4l2: video device: Add FMTX controls default configurations v4l2_subdev i2c: Add i2c board info to v4l2_i2c_new_subdev FMTx: si4713: Add files to handle si4713 i2c device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries FMTx: si4713: Add document file Documentation/video4linux/si4713.txt | 132 ++ drivers/media/radio/Kconfig | 22 + drivers/media/radio/Makefile |3 + drivers/media/radio/radio-si4713.c | 345 ++ drivers/media/radio/radio-si4713.h | 48 + drivers/media/radio/si4713-subdev.c | 1045 drivers/media/radio/si4713.c | 2250 ++ drivers/media/radio/si4713.h | 295 + drivers/media/video/v4l2-common.c| 99 ++- include/linux/videodev2.h| 45 + include/media/v4l2-common.h |6 + 11 files changed, 4284 insertions(+), 6 deletions(-) create mode 100644 Documentation/video4linux/si4713.txt create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713-subdev.c create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.h
Re: [PATCH v2 0/7] [RFC] FM Transmitter (si4713) and another changes
On Tue, May 12, 2009 at 09:33:31AM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: On Tue, May 12, 2009 at 09:03:18AM +0200, ext Hans Verkuil wrote: On Monday 11 May 2009 11:31:42 Eduardo Valentin wrote: Hello all, It took a few but I'm resending the FM transmitter driver again. Sorry for this delay, but I had another things to give attention. Anyway, after reading the API and re-writing the code I came up with the following 7 patches. Three of them are in the v4l2 API. The other 4 are for the si4713 device. It is because of the first 3 patches that I'm sending this as a RFC. The first and second patches, as suggested before, are creating another v4l2 extended controls class, the V4L2_CTRL_CLASS_FMTX. At this first interaction, I've put all si4713 device extra properties there. But I think that some of the can be moved to private class (V4L2_CID_PRIVATE_BASE). That's the case of the region related things. Comments are wellcome. The third patch came *maybe* because I've misunderstood something. But I realized that the v4l2-subdev helper functions for I2C devices assumes that the bridge device will create an I2C adaptor. And in that case, only I2C address and its type are suffient. But in this case, makes no sense to me to create an adaptor for the si4713 platform device driver. This is the case where the device (si4713) is connected to an existing adaptor. That's why I've realized that currently there is no way to pass I2C board info using the current v4l2 I2C helper functions. Other info like irq line and platform data are not passed to subdevices. So, that's why I've created that patch. I've made several changes to the v4l2-subdev helpers: you now pass the i2c adapter directly. I've also fixed the unregister code to properly unregister any i2c client so you can safely rmmod and modprobe the i2c module. Right. I will check those. What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Yes, sure. Well, a simple set_power procedure is an example of things that I see as platform specific. Which may be passed by platform data structures. In some platform a set power / reset line may be done by a simple gpio. but in others it may be a different procedure. Also, the IRQ line value can also be passed to device driver using the i2c board info. That's another way of use of this i2c board info. Regards, Hans The remaining patches are the si4713 device driver itself. As suggested, I've splited the driver into i2c driver and v4l2 radio driver. The first one is exporting it self as a v4l2 subdev as well. Now it is composed by the si4713.c and si4713-subdev.c. But in the future versions I think I'll merge both and remove the si4713.c (by reducing lots of things), because it was mainly designed to be used by the sysfs interface. I've also keeped the sysfs interface (besides the extended control interface). The v4l2 radio driver became a platform driver which is mainly a wrapper to the I2C subdevice. Again here I've found some problem with the device remove. Because, as the I2C helper function assumes the bridge device will create an adaptor, then when the bridge removes the adaptor, its devices will be removed as well. So, when re-inserting the driver, registration will be good. However, if we use an existing adaptor, then we need to remove the i2c client manually. Otherwise it will fail when re-inserting the device. As I said before, comments are wellcome. I'm mostly to be misunderstanding something from the API. BR, Eduardo Valentin (7): v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls v4l2: video device: Add FMTX controls default configurations v4l2_subdev i2c: Add i2c board info to v4l2_i2c_new_subdev FMTx: si4713: Add files to handle si4713 i2c device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries FMTx: si4713: Add document file Documentation/video4linux/si4713.txt | 132 ++ drivers/media/radio/Kconfig | 22 + drivers/media/radio/Makefile |3 + drivers/media/radio/radio-si4713.c | 345 ++ drivers/media/radio/radio-si4713.h | 48 + drivers/media/radio/si4713-subdev.c | 1045 drivers/media/radio/si4713.c | 2250 ++ drivers/media/radio/si4713.h | 295 + drivers/media/video/v4l2-common.c| 99 ++- include/linux/videodev2.h| 45 + include/media/v4l2-common.h |6 + 11 files changed, 4284 insertions(+), 6 deletions(-) create
Re: [PATCH v2 0/7] [RFC] FM Transmitter (si4713) and another changes
On Tue, May 12, 2009 at 09:03:18AM +0200, ext Hans Verkuil wrote: On Monday 11 May 2009 11:31:42 Eduardo Valentin wrote: Hello all, It took a few but I'm resending the FM transmitter driver again. Sorry for this delay, but I had another things to give attention. Anyway, after reading the API and re-writing the code I came up with the following 7 patches. Three of them are in the v4l2 API. The other 4 are for the si4713 device. It is because of the first 3 patches that I'm sending this as a RFC. The first and second patches, as suggested before, are creating another v4l2 extended controls class, the V4L2_CTRL_CLASS_FMTX. At this first interaction, I've put all si4713 device extra properties there. But I think that some of the can be moved to private class (V4L2_CID_PRIVATE_BASE). That's the case of the region related things. Comments are wellcome. The third patch came *maybe* because I've misunderstood something. But I realized that the v4l2-subdev helper functions for I2C devices assumes that the bridge device will create an I2C adaptor. And in that case, only I2C address and its type are suffient. But in this case, makes no sense to me to create an adaptor for the si4713 platform device driver. This is the case where the device (si4713) is connected to an existing adaptor. That's why I've realized that currently there is no way to pass I2C board info using the current v4l2 I2C helper functions. Other info like irq line and platform data are not passed to subdevices. So, that's why I've created that patch. I've made several changes to the v4l2-subdev helpers: you now pass the i2c adapter directly. I've also fixed the unregister code to properly unregister any i2c client so you can safely rmmod and modprobe the i2c module. Right. I will check those. What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Yes, sure. Well, a simple set_power procedure is an example of things that I see as platform specific. Which may be passed by platform data structures. In some platform a set power / reset line may be done by a simple gpio. but in others it may be a different procedure. The v4l2_device struct has a notify callback: you can use that one instead. That way the subdev driver doesn't have to have any knowledge about the platform it is used in. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v2 0/7] [RFC] FM Transmitter (si4713) and another changes
On Tue, May 12, 2009 at 09:50:22AM +0200, ext Hans Verkuil wrote: On Tue, May 12, 2009 at 09:03:18AM +0200, ext Hans Verkuil wrote: On Monday 11 May 2009 11:31:42 Eduardo Valentin wrote: Hello all, It took a few but I'm resending the FM transmitter driver again. Sorry for this delay, but I had another things to give attention. Anyway, after reading the API and re-writing the code I came up with the following 7 patches. Three of them are in the v4l2 API. The other 4 are for the si4713 device. It is because of the first 3 patches that I'm sending this as a RFC. The first and second patches, as suggested before, are creating another v4l2 extended controls class, the V4L2_CTRL_CLASS_FMTX. At this first interaction, I've put all si4713 device extra properties there. But I think that some of the can be moved to private class (V4L2_CID_PRIVATE_BASE). That's the case of the region related things. Comments are wellcome. The third patch came *maybe* because I've misunderstood something. But I realized that the v4l2-subdev helper functions for I2C devices assumes that the bridge device will create an I2C adaptor. And in that case, only I2C address and its type are suffient. But in this case, makes no sense to me to create an adaptor for the si4713 platform device driver. This is the case where the device (si4713) is connected to an existing adaptor. That's why I've realized that currently there is no way to pass I2C board info using the current v4l2 I2C helper functions. Other info like irq line and platform data are not passed to subdevices. So, that's why I've created that patch. I've made several changes to the v4l2-subdev helpers: you now pass the i2c adapter directly. I've also fixed the unregister code to properly unregister any i2c client so you can safely rmmod and modprobe the i2c module. Right. I will check those. What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Yes, sure. Well, a simple set_power procedure is an example of things that I see as platform specific. Which may be passed by platform data structures. In some platform a set power / reset line may be done by a simple gpio. but in others it may be a different procedure. The v4l2_device struct has a notify callback: you can use that one instead. That way the subdev driver doesn't have to have any knowledge about the platform it is used in. Right. I see. But in that case the brigde driver would be bound to a board specific? For instance of this very driver, I wrote a platform driver just to make its radio interface. But I don't think it is a good idea to bound the platform driver to a board specific creating a notification handler just to set the power of the i2c chip. I see this procedure as a board specific thing. As well as the IRQ line for instance. That configuration is also board specific. Which is usually passed using i2c board info. Correct me if I'm wrong. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Eduardo Valentin -- 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] dma: fix ipu_idmac.c to not discard the last queued buffer
This also fixes the case of a single queued buffer, for example, when taking a
single frame snapshot with the mx3_camera driver.
Reported-by: Agustin gatoguan...@yahoo.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Subject: Re: Grabbing single stills on MX31 - Re: Solved? - Re:
soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Mon, 11 May 2009, Agustin wrote:
On Thu, 7 May 2009, Guennadi Liakhovetski wrote:
On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote:
...
I thought about the fact that I was only queuing one buffer, and that
this might be a corner case as sample code uses a lot of them. And that
in the older code that funny things could happen in the handler if we
ran out of buffers, though they didn't happen.
So I have queued an extra buffer and voila, got it working.
So thanks again!
However, this could be a bug in ipu_idmac (or some other point), as
using a single buffer is very plausible, specially when grabbing huge
stills.
Great, thanks for testing and debugging! Ok, so, I will have to test this
case some time...
Agustin, does this patch fix your problem? Dan, please, pull it as soon as
we get a tested-by from Agustin.
This workaround (queuing 2 buffers when needing only one) is having the
side effect of greatly increasing the time taken.
I did several tests playing with camera vertical blanking and looking at
capture times:
Vblank / real / user / sys time:
0 / real0m 0.90s / user0m 0.00s / sys 0m 0.34s
1 frame / real0m 1.04s / user0m 0.00s / sys 0m 0.34s
2 frames / real0m 1.18s / user0m 0.00s / sys 0m 0.33s
2.5 (max)/ real0m 1.23s / user0m 0.00s / sys 0m 0.35s
I think the second frame is being captured altogether, and its dma
transfer is not allowing any other process to run meanwhile.
(VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.)
I don't quite understand this. What exactly are you doing above? You
submit 2 buffers and change vertical blanking? Where do you change the
blanking - in the driver? How exactly?
Do you think it will be too hard to fix?
The blanking issue or the 1-buffer problem?
Thanks
Guennadi
drivers/dma/ipu/ipu_idmac.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 3a4deea..9a5bc1a 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1272,7 +1272,8 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(ichan-lock);
if (unlikely(chan_id != IDMAC_SDC_0 chan_id != IDMAC_SDC_1
-((curbuf chan_id) 1) == ichan-active_buffer)) {
+((curbuf chan_id) 1) == ichan-active_buffer
+!list_is_last(ichan-queue.next, ichan-queue))) {
int i = 100;
/* This doesn't help. See comment in ipu_disable_channel() */
--
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
Re: [PATCH v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
Em Tue, 12 May 2009 09:10:43 +0300
Eduardo Valentin eduardo.valen...@nokia.com escreveu:
On Tue, May 12, 2009 at 04:17:03AM +0200, ext Mauro Carvalho Chehab wrote:
Em Mon, 11 May 2009 12:31:43 +0300
Eduardo Valentin eduardo.valen...@nokia.com escreveu:
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/linux/videodev2.h | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ebb2ea6..7559299 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -803,6 +803,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098 /* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099 /* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a/* Camera class
controls */
+#define V4L2_CTRL_CLASS_FMTX 0x009b /* FM Radio Modulator class
controls */
#define V4L2_CTRL_ID_MASK (0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,50 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS (V4L2_CTRL_CLASS_FMTX |
1)
+
+#define V4L2_CID_RDS_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME
(V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FMTX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD
(V4L2_CID_FMTX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME
(V4L2_CID_FMTX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED
(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FMTX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FMTX_CLASS_BASE + 16)
+
+#define V4L2_CID_REGION
(V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_region {
+ V4L2_FMTX_REGION_USA= 0,
+ V4L2_FMTX_REGION_AUSTRALIA = 1,
+ V4L2_FMTX_REGION_EUROPE = 2,
+ V4L2_FMTX_REGION_JAPAN = 3,
+ V4L2_FMTX_REGION_JAPAN_WIDE_BAND= 4,
+};
Hmm... the region is not just a derived parameter, based on
preemphasis/frequencies, and channel stepping? What this parameter controls?
Hi Mauro, I thought in the opposite way. The other parameters are derived
from the region parameter. So, you just set the region, then it will affect
the frequency range, channel stepping and preemphasis.
However, there was some resistance to have this inside kernel
(in previous discussion). One suggested to use database in user land
(or similar thing). In that case, driver(s) would
report its constraints based on device values, not in region settings.
But, this patch set is proposing to have it inside the kernel as you can see.
The point is that the region and the other parameters are interrelated. So,
you're specifying the same thing twice. In order to follow the V4L2 spirit,
where video standards aren't determined by a Country based table, but, instead,
by their technical differences, IMO, we should remove this. Also, I don't doubt
that some countries would come with new settings as they deploy some digital
radio
broadcast standard.
I'd like to hear more opinions though.
Yes, it would be nice to have more opinions about the API changes.
Cheers,
Mauro
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 v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
Em Tue, 12 May 2009 08:26:40 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: The only reason why such a table might end up in the kernel is if there are legal requirements forcing strict control on what is allowed for an FM transmitter in each country, and in that case a similar mechanism as is used for wifi should be used. I know we discussed this earlier, but I've forgotten the exact name of that API. If the usage of FM transmission is for very short range transmissions (for example, to listen to a phone call inside your car stereo, or to listen to your baby's room noises or to see him while you're in the kitchen), I doubt that there are any legal requirements. Such usage is called by the regulatory agencies as secondary usage[1]. The secondary usage for FM and for their adjacent frequencies (the TV range) should allow such domestic usage [2]. In general, the restriction for secondary usage is just the power level, to avoid interferences with the primary usage. In general, the secondary usage for TV and FM ranges are the same (and both ranges are adjacent). On the other hand, for FM primary usage, e. g. a FM broadcaster, the restriction is that you should transmit _ONLY_ at the authorized frequency, at the specified maximum power (that may have a different max power during the day or during the night), using strict shapes for frequency shift, and for modulation levels. It also restricts the location of the FM station, and the characteristics of the antenna beams. Such constraints require application, infrastructure and hardware control that couldn't be done at kernel level. So, I don't see how legal issues might affect this driver. [1] Maybe the specific term may change from country to country, but the idea remains the same, since this concept exists on ITU-R regulations. [2] I'm not aware of any country that forbids the usage of FM/TV ranges for domestic usage. Yet, if such country does exist, then the usage of this module should be forbidden at such country, no matter what frequency you're generating. So, again, it seems pointless to add such restriction in kernel. 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
[PATCH] [0905_01] Siano: smsusb - update license
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1242126057 -10800 # Node ID 766d02fa7c5c42cc6480eaefb14c7dd6f9c0d370 # Parent 8d37e850566419e7905e66f875b9384d96bf340d [0905_01] Siano: smsusb - update license From: Uri Shkolnik u...@siano-ms.com This patch updates the license of the USB interface driver Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 8d37e8505664 -r 766d02fa7c5c linux/drivers/media/dvb/siano/smsusb.c --- a/linux/drivers/media/dvb/siano/smsusb.cMon May 11 09:37:41 2009 -0700 +++ b/linux/drivers/media/dvb/siano/smsusb.cTue May 12 14:00:57 2009 +0300 @@ -1,23 +1,23 @@ -/* - * Driver for the Siano SMS1xxx USB dongle - * - * author: Anatoly Greenblat - * - * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc. - * - * 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; - * - * Software distributed under the License is distributed on an AS IS - * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. - * - * 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., 675 Mass Ave, Cambridge, MA 02139, USA. - */ +/ + +Siano Mobile Silicon, Inc. +MDTV receiver kernel modules. +Copyright (C) 2005-2009, Uri Shkolnik, Anatoly Greenblat + +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 2 of the License, or +(at your option) any later version. + + 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, see http://www.gnu.org/licenses/. + +/ #include linux/kernel.h #include linux/init.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
[PATCH] [0905_02] Siano: smsusb - handle byte ordering and big endianity
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1242127626 -10800 # Node ID 26c02c133d7e1f9932c1968f669ab0bfaf2761fa # Parent 766d02fa7c5c42cc6480eaefb14c7dd6f9c0d370 [0905_02] Siano: smsusb - handle byte ordering and big endianity From: Uri Shkolnik u...@siano-ms.com This patch adds support for byte ordering and big endianity handling for the USB interface driver Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 766d02fa7c5c -r 26c02c133d7e linux/drivers/media/dvb/siano/smsusb.c --- a/linux/drivers/media/dvb/siano/smsusb.cTue May 12 14:00:57 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smsusb.cTue May 12 14:27:06 2009 +0300 @@ -26,6 +26,7 @@ along with this program. If not, see h #include smscoreapi.h #include sms-cards.h +#include smsendian.h static int sms_dbg; module_param_named(debug, sms_dbg, int, 0644); @@ -180,6 +181,7 @@ static int smsusb_sendrequest(void *cont struct smsusb_device_t *dev = (struct smsusb_device_t *) context; int dummy; + smsendian_handle_message_header((struct SmsMsgHdr_ST *)buffer); return usb_bulk_msg(dev-udev, usb_sndbulkpipe(dev-udev, 2), buffer, size, dummy, 1000); } @@ -337,8 +339,8 @@ static int smsusb_init_device(struct usb case SMS_VEGA: dev-buffer_size = USB2_BUFFER_SIZE; dev-response_alignment = - dev-udev-ep_in[1]-desc.wMaxPacketSize - - sizeof(struct SmsMsgHdr_ST); + le16_to_cpu(dev-udev-ep_in[1]-desc.wMaxPacketSize) - + sizeof(struct SmsMsgHdr_ST); params.flags |= SMS_DEVICE_FAMILY2; break; -- 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] dibcom3000 (dvb) driver bug with ubuntu 9.04 (2.6.28 kernel)?
After many trials, I observe that the image quality is recovered when no other USB2.0 devices are connected to the GA-MA78GM mother board (WIFI dongle or Hard Drive). This problems seems to be releated to this bug http://bugzilla.kernel.org/show_bug.cgi?id=11599 and/or that one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256492. But it seems that the ehcd-hci bug is solved (but not for me!) Any idea? Julien --- En date de : Sam 2.5.09, julien de ROSNY m8...@yahoo.fr a écrit : De: julien de ROSNY m8...@yahoo.fr Objet: [linux-dvb] dibcom3000 (dvb) driver bug with ubuntu 9.04 (2.6.28 kernel)? À: linux-...@linuxtv.org Date: Samedi 2 Mai 2009, 0h07 Hello, Since a couple of years, I use a WinFast DTV Dongle (dib3000mc) on a ASUS (intel) laptop without any trouble. It works with ubuntu 8.04. The quality is perfect I use now the same dongle on a recent laptop PC based on a GA-MA78GM-US2H mother board and the quality of the image is very bad and the soft (me-tv) rebuffer very often. It is unlikely a probleme of signal strength, because on the same antenna plug, the dvb works very well with the laptop, and very bad with the desktop computer. See below some informations about the dvb with the two configrations : laptop and the desktop computer. I noticed that there are some differences between the loaded modules. i2c_core and usbcore are abscent with ubuntu 9.04. Is it normal? Morever if you carefully look at the dvbtraffic, it is lower for the LAPTOP for a same program. This is very repetive behaviour. It is not normal. Does anyone have an idea of whats wrong with the LAPTOP configuration. Thanks. Julien R. *** LAPTOP (GOOD image quality) uname -a : Linux portable 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux lsusb: Bus 005 Device 011: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) lsmod | grep dvb dvb_usb_dibusb_mc 6400 0 dvb_usb_dibusb_common 10756 1 dvb_usb_dibusb_mc dib3000mc 13960 2 dvb_usb_dibusb_common dvb_usb 19852 2 dvb_usb_dibusb_mc,dvb_usb_dibusb_common dvb_core 81404 1 dvb_usb i2c_core 24832 4 mt2060,dib3000mc,dibx000_common,dvb_usb usbcore 146412 5 dvb_usb_dibusb_mc,dvb_usb,ehci_hcd,uhci_hcd tzap ARTE status 1f | signal c058 | snr | ber | unc | FE_HAS_LOCK dvbtraffic 9 p/s 1 kb/s 14 kbit 0010 5 p/s 0 kb/s 8 kbit 0011 0 p/s 0 kb/s 1 kbit 0012 12 p/s 2 kb/s 19 kbit 0015 1 p/s 0 kb/s 2 kbit 006e 9 p/s 1 kb/s 14 kbit 0078 1697 p/s 311 kb/s 2553 kbit 0082 132 p/s 24 kb/s 198 kbit 008c 32 p/s 5 kb/s 49 kbit 00d2 9 p/s 1 kb/s 14 kbit 00dc 2189 p/s 401 kb/s 3292 kbit 00e6 132 p/s 24 kb/s 198 kbit 00f0 3 p/s 0 kb/s 5 kbit 0136 9 p/s 1 kb/s 14 kbit 0140 1527 p/s 280 kb/s 2296 kbit 014a 131 p/s 24 kb/s 197 kbit 0154 1 p/s 0 kb/s 2 kbit 01fe 9 p/s 1 kb/s 14 kbit 0208 2104 p/s 386 kb/s 3164 kbit 0212 131 p/s 24 kb/s 197 kbit 0213 132 p/s 24 kb/s 198 kbit 021c 1 p/s 0 kb/s 2 kbit 021d 2 p/s 0 kb/s 4 kbit 021e 2 p/s 0 kb/s 4 kbit 0262 9 p/s 1 kb/s 14 kbit 026c 1688 p/s 309 kb/s 2539 kbit 0276 132 p/s 24 kb/s 198 kbit 0280 2 p/s 0 kb/s 4 kbit 0294 13 p/s 2 kb/s 20 kbit 02c6 9 p/s 1 kb/s 14 kbit 02d0 5437 p/s 998 kb/s 8178 kbit 02da 131 p/s 24 kb/s 197 kbit 03f2 9 p/s 1 kb/s 14 kbit 1fff 823 p/s 151 kb/s 1239 kbit 2000 16557 p/s 3039 kb/s 24901 kbit DESKTOP (very bad image) system ubuntu jaunty Linux xxx 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux AMD Mother board GA-MA78GM-US2H (USB controler : amd sb700) lsusb Bus 001 Device 006: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) lsmod |grep dvb dvb_usb_dibusb_mc 13056 0 dvb_usb_dibusb_common 16772 1 dvb_usb_dibusb_mc dib3000mc 20488 2 dvb_usb_dibusb_common dvb_usb 24332 2 dvb_usb_dibusb_mc,dvb_usb_dibusb_common dvb_core 92032 1 dvb_usb tzap ARTE tuning to 586167000 Hz video pid 0x0208, audio pid 0x0212 status 1f | signal cbfc | snr | ber 001f | unc 0013 | FE_HAS_LOCK ... dvbtraffic 9 p/s 1 kb/s 14 kbit 0012 10 p/s 1 kb/s 16 kbit 0015 1 p/s 0 kb/s 2 kbit 006e 9 p/s 1 kb/s 14 kbit 0078 1757 p/s 322 kb/s 2643 kbit 0082 127 p/s 23 kb/s 191 kbit 008c 3 p/s 0 kb/s 5 kbit 00d2 9 p/s 1 kb/s 14
Re: [PATCH] dma: fix ipu_idmac.c to not discard the last queued buffer
On Tue, 12 May 2009, Guennadi Liakhovetski wrote:
This also fixes the case of a single queued buffer, for example, when taking a
single frame snapshot with the mx3_camera driver.
Reported-by: Agustin
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Agustin Ferrin Pozuelo
---
Subject: Re: Grabbing single stills on MX31 - Re: Solved? - Re:
soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Mon, 11 May 2009, Agustin wrote:
On Thu, 7 May 2009, Guennadi Liakhovetski wrote:
On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote:
...
I thought about the fact that I was only queuing one buffer, and that
this might be a corner case as sample code uses a lot of them. And that
in the older code that funny things could happen in the handler if we
ran out of buffers, though they didn't happen.
So I have queued an extra buffer and voila, got it working.
So thanks again!
However, this could be a bug in ipu_idmac (or some other point), as
using a single buffer is very plausible, specially when grabbing huge
stills.
Great, thanks for testing and debugging! Ok, so, I will have to test this
case some time...
Agustin, does this patch fix your problem? Dan, please, pull it as soon as
we get a tested-by from Agustin.
Yes it works. And it happens to save 33% of system CPU time in addition to
freeing a lot of memory bandwith. Timings after this fix:
Vblank / real/ user / sys time:
[any] / real 0.50s / user 0.00s / sys 0.22s
(Everything was for a 3888x1944x15bpp still)
This workaround (queuing 2 buffers when needing only one) is having the
side effect of greatly increasing the time taken.
I did several tests playing with camera vertical blanking and looking at
capture times:
Vblank / real / user / sys time:
0 / real0m 0.90s / user0m 0.00s / sys 0m 0.34s
1 frame / real0m 1.04s / user0m 0.00s / sys 0m 0.34s
2 frames / real0m 1.18s / user0m 0.00s / sys 0m 0.33s
2.5 (max)/ real0m 1.23s / user0m 0.00s / sys 0m 0.35s
I think the second frame is being captured altogether, and its dma
transfer is not allowing any other process to run meanwhile.
(VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.)
I don't quite understand this. What exactly are you doing above? You
submit 2 buffers and change vertical blanking? Where do you change the
blanking - in the driver? How exactly?
Do you think it will be too hard to fix?
The blanking issue or the 1-buffer problem?
Eh-eh, it was the same!
Thanks a lot!
--Agustín.
Thanks
Guennadi
drivers/dma/ipu/ipu_idmac.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 3a4deea..9a5bc1a 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1272,7 +1272,8 @@ static irqreturn_t idmac_interrupt(int irq, void
*dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(ichan-lock);
if (unlikely(chan_id != IDMAC_SDC_0 chan_id != IDMAC_SDC_1
- ((curbuf chan_id) 1) == ichan-active_buffer)) {
+ ((curbuf chan_id) 1) == ichan-active_buffer
+ !list_is_last(ichan-queue.next, ichan-queue))) {
int i = 100;
/* This doesn't help. See comment in ipu_disable_channel() */
--
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] videobuf-dma-contig: zero copy USERPTR V3 comments
From: Magnus Damm d...@igel.co.jp
This patch adds function descriptions to V3 of the V4L2
videobuf-dma-contig USERPTR zero copy patch.
Signed-off-by: Magnus Damm d...@igel.co.jp
---
drivers/media/video/videobuf-dma-contig.c | 16
1 file changed, 16 insertions(+)
--- 0005/drivers/media/video/videobuf-dma-contig.c
+++ work/drivers/media/video/videobuf-dma-contig.c 2009-05-12
21:14:40.0 +0900
@@ -110,6 +110,12 @@ static struct vm_operations_struct video
.close= videobuf_vm_close,
};
+/**
+ * videobuf_dma_contig_user_put() - reset pointer to user space buffer
+ * @mem: per-buffer private videobuf-dma-contig data
+ *
+ * This function resets the user space pointer
+ */
static void videobuf_dma_contig_user_put(struct videobuf_dma_contig_memory
*mem)
{
mem-is_userptr = 0;
@@ -117,6 +123,16 @@ static void videobuf_dma_contig_user_put
mem-size = 0;
}
+/**
+ * videobuf_dma_contig_user_get() - setup user space memory pointer
+ * @mem: per-buffer private videobuf-dma-contig data
+ * @vb: video buffer to map
+ *
+ * This function validates and sets up a pointer to user space memory.
+ * Only physically contiguous pfn-mapped memory is accepted.
+ *
+ * Returns 0 if successful.
+ */
static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
struct videobuf_buffer *vb)
{
--
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] videobuf-dma-contig: zero copy USERPTR support V3
On Mon, May 11, 2009 at 10:36 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Fri, 8 May 2009 13:06:58 -0700 Andrew Morton a...@linux-foundation.org escreveu: On Fri, 08 May 2009 17:53:10 +0900 Magnus Damm magnus.d...@gmail.com wrote: From: Magnus Damm d...@igel.co.jp This is V3 of the V4L2 videobuf-dma-contig USERPTR zero copy patch. Since videobuf-dma-contig is designed to handle physically contiguous memory, this patch modifies the videobuf-dma-contig code to only accept a user space pointer to physically contiguous memory. For now only VM_PFNMAP vmas are supported, so forget hotplug. On SuperH Mobile we use this with our sh_mobile_ceu_camera driver together with various multimedia accelerator blocks that are exported to user space using UIO. The UIO kernel code exports physically contiguous memory to user space and lets the user space application mmap() this memory and pass a pointer using the USERPTR interface for V4L2 zero copy operation. With this approach we support zero copy capture, hardware scaling and various forms of hardware encoding and decoding. Signed-off-by: Magnus Damm d...@igel.co.jp Acked-by: Mauro Carvalho Chehab mche...@redhat.com Thank you! What does it do, how does it do it and why does it do it? A good documentation is a really good idea here. There videobuf internals are very complex. A good documentation for it is very important to keep it updated. I've just posted a little patch that adds function descriptions, hopefully that is one step in the right direction. I would also suggest if you could also take a look at videobuf-vmalloc and implement a similar method to provide USERPTR. The vmalloc flavor can easily be tested with the virtual (vivi) video driver, so it helps people to better understand how videobuf works. It will also help the USB drivers that use videobuf to use USERPTR. Yeah, supporting USERPTR with vivi sounds like a good plan. I'm not sure how much work it involves though. The comment in the videobuf-vmalloc header says that the buffer code assumes that the driver does not touch the data, but I think that's exactly how vivi generates the frame data for us. =) I need to figure out the best way to grab references to user space pages and map them virtually contiguous like vmalloc does. This will take a bit of time, so don't expect anything submitted in time for v2.6.31. I've put it fairly high on my TODO list. Thanks for your help! / magnus -- 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] [0905_01_1] Siano: Makefile - add smsendian to build
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1242135753 -10800 # Node ID 697459f4baf6e95a906b852250699a18d1016724 # Parent 26c02c133d7e1f9932c1968f669ab0bfaf2761fa [0905_01_1] Siano: Makefile - add smsendian to build From: Uri Shkolnik u...@siano-ms.com Add smsendian component to the module build Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 26c02c133d7e -r 697459f4baf6 linux/drivers/media/dvb/siano/Makefile --- a/linux/drivers/media/dvb/siano/MakefileTue May 12 14:27:06 2009 +0300 +++ b/linux/drivers/media/dvb/siano/MakefileTue May 12 16:42:33 2009 +0300 @@ -1,4 +1,4 @@ sms1xxx-objs := smscoreapi.o sms-cards.o -sms1xxx-objs := smscoreapi.o sms-cards.o +sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o -- 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] [0905_01_2] Siano: make single kernel object (module)
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242137970 -10800
# Node ID db8bfae234d4730f18823ca0686762a13e7997c9
# Parent 126c0974c2db4e2777e5d9b068fa976fe3a59675
[0905_01_2] Siano: make single kernel object (module)
From: Uri Shkolnik u...@siano-ms.com
This patch consolidates the components to single
kernel object (module)
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 126c0974c2db -r db8bfae234d4 linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileTue May 12 16:47:51 2009 +0300
+++ b/linux/drivers/media/dvb/siano/MakefileTue May 12 17:19:30 2009 +0300
@@ -1,10 +1,8 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o smsusb.o smsdvb.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsdvb.o
-EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core -DSMS_DVB3_SUBSYS -DSMS_USB_DRV
EXTRA_CFLAGS += $(extra-cflags-y) $(extra-cflags-m)
diff -r 126c0974c2db -r db8bfae234d4 linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cTue May 12 16:47:51
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cTue May 12 17:19:30
2009 +0300
@@ -1321,8 +1321,8 @@ static int __init smscore_module_init(vo
}
#endif
-#if 0 /* def SMS_DVB_CLIENT */
- /* DVB Register */
+#ifdef SMS_DVB3_SUBSYS
+ /* DVB v.3 Register */
rc = smsdvb_register();
if (rc) {
sms_err(Error registering DVB client.\n);
@@ -1339,12 +1339,12 @@ static int __init smscore_module_init(vo
}
#endif
-#if 0 /* def SMS_USB_BUS_DRV */
+#ifdef SMS_USB_DRV
/* USB Register */
rc = smsusb_register();
if (rc) {
sms_err(Error registering USB bus driver.\n);
- goto sms_bus_drv_error;
+ goto sms_usb_drv_error;
}
#endif
@@ -1358,21 +1358,13 @@ static int __init smscore_module_init(vo
#endif
return rc;
-#if 0
-sms_bus_drv_error:
-#endif /* 0 */
-#if 0 /* def SMS_NET_CLIENT */
- smsnet_unregister();
-smsnet_error:
-#endif
-#if 0 /* def SMS_DVB_CLIENT */
+sms_usb_drv_error:
+#ifdef SMS_DVB3_SUBSYS
smsdvb_unregister();
smsdvb_error:
#endif
-#if 0 /* def SMS_CHAR_CLIENT */
- smschar_unregister();
-smschar_error:
-#endif
+
+
sms_debug(rc %d, rc);
return rc;
@@ -1380,14 +1372,15 @@ smschar_error:
static void __exit smscore_module_exit(void)
{
-#if 0 /* def SMS_CHAR_CLIENT */
- /* Char interface UnRegister */
- smschar_unregister();
+#ifdef SMS_DVB3_SUBSYS
+ /* DVB v.3 unregister */
+ smsdvb_unregister();
#endif
-#if 0 /* def SMS_DVB_CLIENT */
- /* DVB UnRegister */
- smsdvb_unregister();
+ /* Unegister interfaces objects */
+#ifdef SMS_USB_DRV
+ /* USB unregister */
+ smsusb_unregister();
#endif
#if 0 /* def SMS_NET_CLIENT */
diff -r 126c0974c2db -r db8bfae234d4 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 16:47:51
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 17:19:30
2009 +0300
@@ -35,7 +35,6 @@ along with this program. If not, see h
#include asm/page.h
#include compat.h
-#define SMS_DVB3_SUBSYS
#ifdef SMS_DVB3_SUBSYS
#include dmxdev.h
#include dvbdev.h
@@ -661,6 +660,15 @@ int smscore_get_board_id(struct smscore_
int smscore_led_state(struct smscore_device_t *core, int led);
+#ifdef SMS_DVB3_SUBSYS
+extern int smsdvb_register(void);
+extern void smsdvb_unregister(void);
+#endif
+
+#ifdef SMS_USB_DRV
+extern int smsusb_register(void);
+extern void smsusb_unregister(void);
+#endif
/* */
diff -r 126c0974c2db -r db8bfae234d4 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 16:47:51 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 17:19:30 2009 +0300
@@ -518,7 +518,7 @@ adapter_error:
return rc;
}
-int smsdvb_module_init(void)
+int smsdvb_register(void)
{
int rc;
@@ -532,7 +532,7 @@ int smsdvb_module_init(void)
return rc;
}
-void smsdvb_module_exit(void)
+void smsdvb_unregister(void)
{
smscore_unregister_hotplug(smsdvb_hotplug);
@@ -545,9 +545,6 @@ void smsdvb_module_exit(void)
kmutex_unlock(g_smsdvb_clientslock);
}
-module_init(smsdvb_module_init);
-module_exit(smsdvb_module_exit);
-
MODULE_DESCRIPTION(SMS DVB subsystem adaptation module);
MODULE_AUTHOR(Siano Mobile Silicon, INC. (u...@siano-ms.com));
MODULE_LICENSE(GPL);
diff -r 126c0974c2db -r db8bfae234d4 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cTue
[PATCH] [0905_03] Siano: smsusb - remove old backward support
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242136071 -10800
# Node ID 126c0974c2db4e2777e5d9b068fa976fe3a59675
# Parent 697459f4baf6e95a906b852250699a18d1016724
[0905_03] Siano: smsusb - remove old backward support
From: Uri Shkolnik u...@siano-ms.com
Remove backward support for kernel versions
older than 2.6.19.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 697459f4baf6 -r 126c0974c2db linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cTue May 12 16:42:33 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cTue May 12 16:47:51 2009 +0300
@@ -60,11 +60,7 @@ static int smsusb_submit_urb(struct smsu
static int smsusb_submit_urb(struct smsusb_device_t *dev,
struct smsusb_urb_t *surb);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 19)
static void smsusb_onresponse(struct urb *urb)
-#else
-static void smsusb_onresponse(struct urb *urb, struct pt_regs *regs)
-#endif
{
struct smsusb_urb_t *surb = (struct smsusb_urb_t *) urb-context;
struct smsusb_device_t *dev = surb-dev;
--
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] [0905_05] Siano: smsusb - lost buffers bug fix
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242138741 -10800
# Node ID ae0f17b305e7762643a9bc7f43c302c11f7b55b5
# Parent db8bfae234d4730f18823ca0686762a13e7997c9
[0905_05] Siano: smsusb - lost buffers bug fix
From: Uri Shkolnik u...@siano-ms.com
This patch fixes a problem were protocol buffers
have been lost during USB disconnect events.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r db8bfae234d4 -r ae0f17b305e7 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cTue May 12 17:19:30 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cTue May 12 17:32:21 2009 +0300
@@ -65,14 +65,14 @@ static void smsusb_onresponse(struct urb
struct smsusb_urb_t *surb = (struct smsusb_urb_t *) urb-context;
struct smsusb_device_t *dev = surb-dev;
- if (urb-status 0) {
- sms_err(error, urb status %d, %d bytes,
+ if (urb-status == -ESHUTDOWN) {
+ sms_err(error, urb status %d (-ESHUTDOWN), %d bytes,
urb-status, urb-actual_length);
return;
}
- if (urb-actual_length 0) {
- struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) surb-cb-p;
+ if ((urb-actual_length 0) (urb-status == 0)) {
+ struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)surb-cb-p;
smsendian_handle_message_header(phdr);
if (urb-actual_length = phdr-msgLength) {
@@ -111,7 +111,10 @@ static void smsusb_onresponse(struct urb
msglen %d actual %d,
phdr-msgLength, urb-actual_length);
}
- }
+ } else
+ sms_err(error, urb status %d, %d bytes,
+ urb-status, urb-actual_length);
+
exit_and_resubmit:
smsusb_submit_urb(dev, surb);
--
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] [0905_06] Siano: smsdvb - add big endian support
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242139255 -10800
# Node ID 291604c1821496dd4acd1d5411f8ea3ae955fd2c
# Parent ae0f17b305e7762643a9bc7f43c302c11f7b55b5
[0905_06] Siano: smsdvb - add big endian support
From: Uri Shkolnik u...@siano-ms.com
Add support for Siano protocol messages
with big endian systems.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r ae0f17b305e7 -r 291604c18214 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 17:32:21 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 17:40:55 2009 +0300
@@ -23,6 +23,7 @@ along with this program. If not, see h
#include linux/init.h
#include smscoreapi.h
+#include smsendian.h
#include sms-cards.h
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -59,6 +60,8 @@ static int smsdvb_onresponse(void *conte
struct smsdvb_client_t *client = (struct smsdvb_client_t *) context;
struct SmsMsgHdr_ST *phdr =
(struct SmsMsgHdr_ST *)(((u8 *) cb-p) + cb-offset);
+
+ smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);
switch (phdr-msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -149,6 +152,7 @@ static int smsdvb_start_feed(struct dvb_
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg);
return smsclient_sendrequest(client-smsclient,
PidMsg, sizeof(PidMsg));
}
@@ -169,6 +173,7 @@ static int smsdvb_stop_feed(struct dvb_d
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg);
return smsclient_sendrequest(client-smsclient,
PidMsg, sizeof(PidMsg));
}
@@ -177,7 +182,10 @@ static int smsdvb_sendrequest_and_wait(s
void *buffer, size_t size,
struct completion *completion)
{
- int rc = smsclient_sendrequest(client-smsclient, buffer, size);
+ int rc;
+
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer);
+ rc = smsclient_sendrequest(client-smsclient, buffer, size);
if (rc 0)
return rc;
--
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] videobuf-dma-contig: zero copy USERPTR support V3
Em Tue, 12 May 2009 22:30:37 +0900 Magnus Damm magnus.d...@gmail.com escreveu: What does it do, how does it do it and why does it do it? A good documentation is a really good idea here. There videobuf internals are very complex. A good documentation for it is very important to keep it updated. I've just posted a little patch that adds function descriptions, hopefully that is one step in the right direction. Good! I started a documentation of videobuf KABI at: ~/tokernel/wrk/linus/Documentation/video4linux/v4l2-framework.txt For now, it covers only the common code (offering a view for driver writers, not for videobuf writers), but I think we can extend it (or create a separate doc) with internal details. In the future, we should consider converting it to docbook and produce a complete V4L2 KABI doc. Feel free to add some notes there. I would also suggest if you could also take a look at videobuf-vmalloc and implement a similar method to provide USERPTR. The vmalloc flavor can easily be tested with the virtual (vivi) video driver, so it helps people to better understand how videobuf works. It will also help the USB drivers that use videobuf to use USERPTR. Yeah, supporting USERPTR with vivi sounds like a good plan. I'm not sure how much work it involves though. The comment in the videobuf-vmalloc header says that the buffer code assumes that the driver does not touch the data, but I think that's exactly how vivi generates the frame data for us. =) :) The rationale for that comment is that we shouldn't reformat the received data inside kernel (like doing format conversions), but, instead, let this task to happen at userspace if needed. With PCI, this is very clear: it just fills the frame data via DMA, and adds the corresponding meta-data to the videobuf structures at interrupt time. This is possible, since DMA generates IRQ only after receiving a complete frame, so meta-data can be added without troubles. Although videobuf-vmalloc itself doesn't touch at the data (behaving just like PCI videobuf's), this note is not quite true with the clients of videobuf-vmalloc (vivi and the USB drivers), since: 1) all USB drivers I know use a small transport layer over USB to indicate frame begin/end and eventually to multiplex with VBI and/or audio. So, the usb drivers need to get rid of the USB transport layer, providing only the stream data to userspace, and filling the meta-data based on the transport layer; 2) vivi produces the stream data. I need to figure out the best way to grab references to user space pages and map them virtually contiguous like vmalloc does. This will take a bit of time, so don't expect anything submitted in time for v2.6.31. I've put it fairly high on my TODO list. Thanks! Thanks for your help! Anytime. 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
[PATCH 0/3] Convert SuperH camera-enabled platforms to soc-camera as platform_device
Now that soc-camera compatibility patch is in the mainline, we can convert all platforms to the new scheme. This patch series converts SuperH boards. Unfortunately, the first patch has to also (slightly) modify two camera drivers, but that looks like a minor inconvenience to me, at least when compared to my original convert-all-at-once mega-patch. 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
[PATCH 1/3] soc-camera: unify i2c camera device platform data
Unify i2c camera device platform data to point to struct soc_camera_link
for a smooth transition to soc-camera as a platform driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/sh/boards/board-ap325rxa.c |2 +-
arch/sh/boards/mach-migor/setup.c |4 ++--
drivers/media/video/ov772x.c |6 --
drivers/media/video/tw9910.c |6 --
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index 39e4691..54c5cd1 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -414,7 +414,7 @@ static struct i2c_board_info __initdata
ap325rxa_i2c_devices[] = {
},
{
I2C_BOARD_INFO(ov772x, 0x21),
- .platform_data = ov7725_info,
+ .platform_data = ov7725_info.link,
},
};
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 1ee1de0..c4b97e1 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -430,11 +430,11 @@ static struct i2c_board_info migor_i2c_devices[] = {
},
{
I2C_BOARD_INFO(ov772x, 0x21),
- .platform_data = ov7725_info,
+ .platform_data = ov7725_info.link,
},
{
I2C_BOARD_INFO(tw9910, 0x45),
- .platform_data = tw9910_info,
+ .platform_data = tw9910_info.link,
},
};
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index c0d9112..0bce255 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -1067,10 +1067,12 @@ static int ov772x_probe(struct i2c_client *client,
struct i2c_adapter*adapter = to_i2c_adapter(client-dev.parent);
intret;
- info = client-dev.platform_data;
- if (!info)
+ if (!client-dev.platform_data)
return -EINVAL;
+ info = container_of(client-dev.platform_data,
+ struct ov772x_camera_info, link);
+
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(adapter-dev,
I2C-Adapter doesn't support
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index a399476..aa5065e 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -875,10 +875,12 @@ static int tw9910_probe(struct i2c_client *client,
const struct tw9910_scale_ctrl *scale;
int i, ret;
- info = client-dev.platform_data;
- if (!info)
+ if (!client-dev.platform_data)
return -EINVAL;
+ info = container_of(client-dev.platform_data,
+ struct tw9910_video_info, link);
+
if (!i2c_check_functionality(to_i2c_adapter(client-dev.parent),
I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(client-dev,
--
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 2/3] SH: convert ap325rxa to soc-camera as platform-device
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/sh/boards/board-ap325rxa.c | 50 +--
1 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index 54c5cd1..cd1fcc0 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -346,15 +346,6 @@ static int ov7725_power(struct device *dev, int mode)
return 0;
}
-static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
- .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
- .edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
- .link = {
- .power = ov7725_power,
- },
-};
-
static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
.flags = SH_CEU_FLAG_USE_8BIT_BUS,
};
@@ -399,25 +390,48 @@ static struct platform_device sdcard_cn3_device = {
},
};
-static struct platform_device *ap325rxa_devices[] __initdata = {
- smsc9118_device,
- ap325rxa_nor_flash_device,
- lcdc_device,
- ceu_device,
- nand_flash_device,
- sdcard_cn3_device,
-};
-
static struct i2c_board_info __initdata ap325rxa_i2c_devices[] = {
{
I2C_BOARD_INFO(pcf8563, 0x51),
},
+};
+
+static struct i2c_board_info ap325rxa_i2c_camera[] = {
{
I2C_BOARD_INFO(ov772x, 0x21),
+ },
+};
+
+static struct ov772x_camera_info ov7725_info = {
+ .buswidth = SOCAM_DATAWIDTH_8,
+ .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
+ .edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
+ .link = {
+ .power = ov7725_power,
+ .board_info = ap325rxa_i2c_camera[0],
+ .i2c_adapter_id = 0,
+ .module_name= ov772x,
+ },
+};
+
+static struct platform_device ap325rxa_camera = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
.platform_data = ov7725_info.link,
},
};
+static struct platform_device *ap325rxa_devices[] __initdata = {
+ smsc9118_device,
+ ap325rxa_nor_flash_device,
+ lcdc_device,
+ ceu_device,
+ nand_flash_device,
+ sdcard_cn3_device,
+ ap325rxa_camera,
+};
+
static struct spi_board_info ap325rxa_spi_devices[] = {
{
.modalias = mmc_spi,
--
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 3/3] SH: convert migor to soc-camera as platform-device
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/sh/boards/mach-migor/setup.c | 79 -
1 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index c4b97e1..785c3e1 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -381,21 +381,6 @@ static struct platform_device migor_ceu_device = {
},
};
-static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
- .link = {
- .power = ov7725_power,
- },
-};
-
-static struct tw9910_video_info tw9910_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
- .mpout= TW9910_MPO_FIELD,
- .link = {
- .power = tw9910_power,
- }
-};
-
struct spi_gpio_platform_data sdcard_cn9_platform_data = {
.sck = GPIO_PTD0,
.mosi = GPIO_PTD1,
@@ -410,16 +395,6 @@ static struct platform_device sdcard_cn9_device = {
},
};
-static struct platform_device *migor_devices[] __initdata = {
- smc91x_eth_device,
- sh_keysc_device,
- migor_lcdc_device,
- migor_ceu_device,
- migor_nor_flash_device,
- migor_nand_flash_device,
- sdcard_cn9_device,
-};
-
static struct i2c_board_info migor_i2c_devices[] = {
{
I2C_BOARD_INFO(rs5c372b, 0x32),
@@ -428,16 +403,66 @@ static struct i2c_board_info migor_i2c_devices[] = {
I2C_BOARD_INFO(migor_ts, 0x51),
.irq = 38, /* IRQ6 */
},
+};
+
+static struct i2c_board_info migor_i2c_camera[] = {
{
I2C_BOARD_INFO(ov772x, 0x21),
- .platform_data = ov7725_info.link,
},
{
I2C_BOARD_INFO(tw9910, 0x45),
- .platform_data = tw9910_info.link,
},
};
+static struct ov772x_camera_info ov7725_info = {
+ .buswidth = SOCAM_DATAWIDTH_8,
+ .link = {
+ .power = ov7725_power,
+ .board_info = migor_i2c_camera[0],
+ .i2c_adapter_id = 0,
+ .module_name= ov772x,
+ },
+};
+
+static struct tw9910_video_info tw9910_info = {
+ .buswidth = SOCAM_DATAWIDTH_8,
+ .mpout = TW9910_MPO_FIELD,
+ .link = {
+ .power = tw9910_power,
+ .board_info = migor_i2c_camera[1],
+ .i2c_adapter_id = 0,
+ .module_name= tw9910,
+ }
+};
+
+static struct platform_device migor_camera[] = {
+ {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = ov7725_info.link,
+ },
+ }, {
+ .name = soc-camera-pdrv,
+ .id = 1,
+ .dev= {
+ .platform_data = tw9910_info.link,
+ },
+ },
+};
+
+static struct platform_device *migor_devices[] __initdata = {
+ smc91x_eth_device,
+ sh_keysc_device,
+ migor_lcdc_device,
+ migor_ceu_device,
+ migor_nor_flash_device,
+ migor_nand_flash_device,
+ sdcard_cn9_device,
+ migor_camera[0],
+ migor_camera[1],
+};
+
static struct spi_board_info migor_spi_devices[] = {
{
.modalias = mmc_spi,
--
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] [0905_07] Siano: smsdvb - use 'push' status mechanism
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242142336 -10800
# Node ID 10143bda4ddae2b30af23adb15e536dc8bef7962
# Parent 291604c1821496dd4acd1d5411f8ea3ae955fd2c
[0905_07] Siano: smsdvb - use 'push' status mechanism
From: Uri Shkolnik u...@siano-ms.com
This patch replace the old method of pulling the device status by
sending get_statistics request, to push mode. This make status update
much faster, and reduce various operation time (UHF scan now takes 15s
instead of 2m). In order to make the change the following modification
have been applied:
1) core header - update statistics headers.
2) dvb adapter - omit the statistics request, add handling of
status indications.
3) core 'onresponse' - re-route messages addressed to other adapter
to the dvb adapter.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 291604c18214 -r 10143bda4dda linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cTue May 12 17:40:55
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cTue May 12 18:32:16
2009 +0300
@@ -904,15 +904,11 @@ smscore_client_t *smscore_find_client(st
*
*/
void smscore_onresponse(struct smscore_device_t *coredev,
- struct smscore_buffer_t *cb)
-{
- struct SmsMsgHdr_ST *phdr =
- (struct SmsMsgHdr_ST *)((u8 *) cb-p + cb-offset);
- struct smscore_client_t *client =
- smscore_find_client(coredev, phdr-msgType, phdr-msgDstId);
+ struct smscore_buffer_t *cb) {
+ struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) ((u8 *) cb-p
+ + cb-offset);
+ struct smscore_client_t *client;
int rc = -EBUSY;
-
-#if 1
static unsigned long last_sample_time; /* = 0; */
static int data_total; /* = 0; */
unsigned long time_now = jiffies_to_msecs(jiffies);
@@ -930,7 +926,16 @@ void smscore_onresponse(struct smscore_d
}
data_total += cb-size;
-#endif
+ /* Do we need to re-route? */
+ if ((phdr-msgType == MSG_SMS_HO_PER_SLICES_IND) ||
+ (phdr-msgType == MSG_SMS_TRANSMISSION_IND)) {
+ if (coredev-mode == DEVICE_MODE_DVBT_BDA)
+ phdr-msgDstId = DVBT_BDA_CONTROL_MSG_ID;
+ }
+
+
+ client = smscore_find_client(coredev, phdr-msgType, phdr-msgDstId);
+
/* If no client registered for type id,
* check for control client where type is not registered */
if (client)
diff -r 291604c18214 -r 10143bda4dda linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 17:40:55
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 18:32:16
2009 +0300
@@ -213,19 +213,15 @@ struct smscore_device_t {
#define MSG_SMS_INIT_DEVICE_RES579
#define MSG_SMS_ADD_PID_FILTER_REQ 601
#define MSG_SMS_ADD_PID_FILTER_RES 602
-#define MSG_SMS_REMOVE_PID_FILTER_REQ 603
-#define MSG_SMS_REMOVE_PID_FILTER_RES 604
-#define MSG_SMS_DAB_CHANNEL607
-#define MSG_SMS_GET_PID_FILTER_LIST_REQ608
-#define MSG_SMS_GET_PID_FILTER_LIST_RES609
-#define MSG_SMS_GET_STATISTICS_REQ 615
-#define MSG_SMS_GET_STATISTICS_RES 616
+#define MSG_SMS_REMOVE_PID_FILTER_REQ 603
+#define MSG_SMS_REMOVE_PID_FILTER_RES 604
+#define MSG_SMS_DAB_CHANNEL607
+#define MSG_SMS_GET_PID_FILTER_LIST_REQ608
+#define MSG_SMS_GET_PID_FILTER_LIST_RES609
#define MSG_SMS_HO_PER_SLICES_IND 630
-#define MSG_SMS_SET_ANTENNA_CONFIG_REQ 651
-#define MSG_SMS_SET_ANTENNA_CONFIG_RES 652
-#define MSG_SMS_GET_STATISTICS_EX_REQ 653
-#define MSG_SMS_GET_STATISTICS_EX_RES 654
-#define MSG_SMS_SLEEP_RESUME_COMP_IND 655
+#define MSG_SMS_SET_ANTENNA_CONFIG_REQ 651
+#define MSG_SMS_SET_ANTENNA_CONFIG_RES 652
+#define MSG_SMS_SLEEP_RESUME_COMP_IND 655
#define MSG_SMS_DATA_DOWNLOAD_REQ 660
#define MSG_SMS_DATA_DOWNLOAD_RES 661
#define MSG_SMS_SWDOWNLOAD_TRIGGER_REQ 664
@@ -347,225 +343,202 @@ struct SmsFirmware_ST {
u8 Payload[1];
};
-struct SMSHOSTLIB_STATISTICS_ST {
- u32 Reserved; /* Reserved */
+/* Statistics information returned as response for
+ * SmsHostApiGetStatistics_Req */
+struct SMSHOSTLIB_STATISTICS_S {
+ u32 Reserved; /* Reserved */
/* Common parameters */
- u32 IsRfLocked; /* 0 - not locked, 1 - locked */
- u32 IsDemodLocked; /* 0 - not locked, 1 - locked */
- u32 IsExternalLNAOn; /* 0 - external LNA off, 1 - external LNA on
[PATCH] [0905_08] Siano: smsdvb - move the dvb related included files
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1242142695 -10800 # Node ID 777b32ac3080215d26c35853ea41c1f8f992b70c # Parent 10143bda4ddae2b30af23adb15e536dc8bef7962 [0905_08] Siano: smsdvb - move the dvb related included files From: Uri Shkolnik u...@siano-ms.com This patch moves the DVB API related headers from the core, to the smbdvb (dvb adapter) which is the only component that uses these headers. Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 10143bda4dda -r 777b32ac3080 linux/drivers/media/dvb/siano/smscoreapi.h --- a/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 18:32:16 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smscoreapi.hTue May 12 18:38:15 2009 +0300 @@ -34,13 +34,6 @@ along with this program. If not, see h #include asm/page.h #include compat.h - -#ifdef SMS_DVB3_SUBSYS -#include dmxdev.h -#include dvbdev.h -#include dvb_demux.h -#include dvb_frontend.h -#endif #define kmutex_init(_p_) mutex_init(_p_) #define kmutex_lock(_p_) mutex_lock(_p_) diff -r 10143bda4dda -r 777b32ac3080 linux/drivers/media/dvb/siano/smsdvb.c --- a/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 18:32:16 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 18:38:15 2009 +0300 @@ -21,6 +21,11 @@ along with this program. If not, see h #include linux/module.h #include linux/init.h + +#include dmxdev.h +#include dvbdev.h +#include dvb_demux.h +#include dvb_frontend.h #include smscoreapi.h #include smsendian.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
[PATCH] [0905_09] Siano: smsdvb - small type fix
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1242143183 -10800 # Node ID 179c1575678e08b5626bb918ef300b3ecead633c # Parent 777b32ac3080215d26c35853ea41c1f8f992b70c [0905_09] Siano: smsdvb - small type fix From: Uri Shkolnik u...@siano-ms.com Fix type at the module description Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 777b32ac3080 -r 179c1575678e linux/drivers/media/dvb/siano/smsdvb.c --- a/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 18:38:15 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smsdvb.cTue May 12 18:46:23 2009 +0300 @@ -601,5 +601,5 @@ void smsdvb_unregister(void) } MODULE_DESCRIPTION(SMS DVB subsystem adaptation module); -MODULE_AUTHOR(Siano Mobile Silicon, INC. (u...@siano-ms.com)); +MODULE_AUTHOR(Siano Mobile Silicon, Inc. (u...@siano-ms.com)); MODULE_LICENSE(GPL); -- 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
Not only TV LV5H hybrid tv card
Hi, I have just bought the Not only TV (LV5H) tv-card which should be equipped with the em28xx chip - I'm trying to get it to work in ubuntu (8.10) but it doesn't work completely. I've attached the output from dmesg below. I'm a bit new to linux and don't know how to use the insmod command as suggested in the dmesg output Best Regards, Martin [ 2829.852110] usb 5-7: new high speed USB device using ehci_hcd and address 4 [ 2829.990101] usb 5-7: configuration #1 chosen from 1 choice [ 2829.990585] em28xx: New device USB 2883 Device @ 480 Mbps (eb1a:2883, interface 0, class 0) [ 2829.990601] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 2829.990709] em28xx #0: chip ID is em2882/em2883 [ 2830.082328] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 83 28 d0 12 65 03 6a 22 8c 10 [ 2830.082350] em28xx #0: i2c eeprom 10: 00 00 24 57 4e 37 41 00 60 00 00 00 02 00 00 00 [ 2830.082363] em28xx #0: i2c eeprom 20: 5e 00 01 00 f0 10 01 00 b8 00 00 00 5b 1e 00 00 [ 2830.082379] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 04 20 10 01 03 00 00 00 00 00 [ 2830.082395] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 d3 c4 00 00 [ 2830.082409] em28xx #0: i2c eeprom 50: 00 a2 b2 87 81 80 00 00 00 00 00 00 00 00 00 00 [ 2830.082427] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 2830.082442] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 33 00 20 00 44 00 [ 2830.082456] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 10 03 32 00 [ 2830.082471] em28xx #0: i2c eeprom 90: 30 00 30 00 37 00 31 00 30 00 00 00 00 00 00 00 [ 2830.082486] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082501] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082515] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082532] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082547] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082563] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2830.082580] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x516cc51d [ 2830.082583] em28xx #0: EEPROM info: [ 2830.082587] em28xx #0: AC97 audio (5 sample rates) [ 2830.082589] em28xx #0: 500mA max power [ 2830.082592] em28xx #0: Table at 0x24, strings=0x226a, 0x108c, 0x [ 2830.115222] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 2830.119718] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [ 2830.121606] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 2830.132857] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 2830.132868] em28xx #0: You may try to use card=n insmod option to workaround that. [ 2830.132873] em28xx #0: Please send an email with this log to: [ 2830.132878] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 2830.132884] em28xx #0: Board eeprom hash is 0x516cc51d [ 2830.132888] em28xx #0: Board i2c devicelist hash is 0x27e10080 [ 2830.132895] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 2830.132901] em28xx #0: card=0 - Unknown EM2800 video grabber [ 2830.132907] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 2830.132913] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 2830.132931] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 2830.132934] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 2830.132937] em28xx #0: card=5 - MSI VOX USB 2.0 [ 2830.132944] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 2830.132947] em28xx #0: card=7 - Leadtek Winfast USB II [ 2830.132950] em28xx #0: card=8 - Kworld USB2800 [ 2830.132956] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 2830.132960] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 2830.132964] em28xx #0: card=11 - Terratec Hybrid XS [ 2830.132967] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 2830.132970] em28xx #0: card=13 - Terratec Prodigy XS [ 2830.132980] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 2830.132984] em28xx #0: card=15 - V-Gear PocketTV [ 2830.132987] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 2830.132990] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 2830.132998] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 2830.133001] em28xx #0: card=19 - PointNix Intra-Oral Camera [ 2830.133004] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [ 2830.133008] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 2830.133011] em28xx #0: card=22 - Unknown EM2750/EM2751 webcam grabber [ 2830.133015] em28xx #0: card=23 - Huaqi DLCW-130 [ 2830.133017] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner [ 2830.133020] em28xx #0: card=25 - Gadmei UTV310 [ 2830.133027] em28xx #0: card=26 - Hercules Smart TV USB 2.0 [ 2830.133030] em28xx #0: card=27 - Pinnacle
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Tue May 12 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11758:8d37e8505664 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc4-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc4-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc4-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc4-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc4-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc4-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc4-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc4-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc4): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] dma: fix ipu_idmac.c to not discard the last queued buffer
On Tue, May 12, 2009 at 5:14 AM, Agustin gatoguan...@yahoo.com wrote: On Tue, 12 May 2009, Guennadi Liakhovetski wrote: This also fixes the case of a single queued buffer, for example, when taking a single frame snapshot with the mx3_camera driver. Reported-by: Agustin Signed-off-by: Guennadi Liakhovetski Signed-off-by: Agustin Ferrin Pozuelo Applied. -- 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: Not only TV LV5H hybrid tv card
On Tue, May 12, 2009 at 1:46 PM, Martin Kragelund martin.kragel...@gmail.com wrote: Hi, I have just bought the Not only TV (LV5H) tv-card which should be equipped with the em28xx chip - I'm trying to get it to work in ubuntu (8.10) but it doesn't work completely. I've attached the output from dmesg below. I'm a bit new to linux and don't know how to use the insmod command as suggested in the dmesg output Best Regards, Martin My queue of em28xx devices I'm adding support for is already three or four deep. Ask again in a couple of weeks and I will see what I can do to get this one working. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: XC5000 improvements: call for testers!
On May 6, 2009, at 10:55 PM, Devin Heitmueller wrote: If you do decide to narrow it down to a particular patch, please switch over to the following tree first: http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta2 I re-exported the patch series and recreated the tree without all the intermediate merges from the v4l-dvb tip. As a result, it will be much easier to bisect and determine which patch is causing the issue. I finally had some time to do some more testing with the beta2 tree and I think most of the issues I had were user error. Not exactly sure what I did wrong before but I am not seeing the reception issues or any regressions on the digital side anymore. I think why I thought I was seeing QAM64 was because I was using the wrong tuner. With the beta2 tree my 950q is now adapter1, before it was always adapter2. That could be part of what I thought was the reception regression as well. Thanks, Britney -- 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: XC5000 improvements: call for testers!
On Tue, May 12, 2009 at 4:50 PM, Britney Fransen britney.fran...@gmail.com wrote: I finally had some time to do some more testing with the beta2 tree and I think most of the issues I had were user error. Not exactly sure what I did wrong before but I am not seeing the reception issues or any regressions on the digital side anymore. I think why I thought I was seeing QAM64 was because I was using the wrong tuner. With the beta2 tree my 950q is now adapter1, before it was always adapter2. That could be part of what I thought was the reception regression as well. Thanks, Britney Hello Britney, Thank you for taking the time to isolate/debug the situation. The changes should have no effect on the order of adapter1/adapter2. Could have just been a coincidence or the order in which you plugged in the devices compared to what they usually are at boot time. Glad to see that there are no longer any issues. Once I get one outstanding Pinnacle 800i fix in, I will issue a PULL request and this will go into the mainline. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: XC5000 improvements: call for testers!
On May 12, 2009, at 3:56 PM, Devin Heitmueller wrote: Glad to see that there are no longer any issues. Once I get one outstanding Pinnacle 800i fix in, I will issue a PULL request and this will go into the mainline. Great! Any chance the QAM64 patch will make it in too? Britney -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/4] dvb-core: fix potential mutex_unlock without mutex_lock in dvb_dvr_read
From: Simon Arlott si...@fire.lp0.eu
dvb_dvr_read may unlock the dmxdev mutex and return -ENODEV, except this
function is a file op and will never be called with the mutex held.
There's existing mutex_lock and mutex_unlock around the actual read but
it's commented out. These should probably be uncommented but the read
blocks and this could block another non-blocking reader on the mutex
instead.
This change comments out the extra mutex_unlock.
[a...@linux-foundation.org: cleanups, simplification]
Signed-off-by: Simon Arlott si...@fire.lp0.eu
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/dvb/dvb-core/dmxdev.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff -puN
drivers/media/dvb/dvb-core/dmxdev.c~dvb-core-fix-potential-mutex_unlock-without-mutex_lock-in-dvb_dvr_read
drivers/media/dvb/dvb-core/dmxdev.c
---
a/drivers/media/dvb/dvb-core/dmxdev.c~dvb-core-fix-potential-mutex_unlock-without-mutex_lock-in-dvb_dvr_read
+++ a/drivers/media/dvb/dvb-core/dmxdev.c
@@ -244,19 +244,13 @@ static ssize_t dvb_dvr_read(struct file
{
struct dvb_device *dvbdev = file-private_data;
struct dmxdev *dmxdev = dvbdev-priv;
- int ret;
- if (dmxdev-exit) {
- mutex_unlock(dmxdev-mutex);
+ if (dmxdev-exit)
return -ENODEV;
- }
- //mutex_lock(dmxdev-mutex);
- ret = dvb_dmxdev_buffer_read(dmxdev-dvr_buffer,
-file-f_flags O_NONBLOCK,
-buf, count, ppos);
- //mutex_unlock(dmxdev-mutex);
- return ret;
+ return dvb_dmxdev_buffer_read(dmxdev-dvr_buffer,
+ file-f_flags O_NONBLOCK,
+ buf, count, ppos);
}
static int dvb_dvr_set_buffer_size(struct dmxdev *dmxdev,
_
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/4] radio-mr800.c: missing mutex include
From: Alessio Igor Bogani abog...@texware.it radio-mr800.c uses struct mutex, so while linux/mutex.h seems to be pulled in indirectly by one of the headers it already includes, the right thing is to include it directly. Signed-off-by: Alessio Igor Bogani abog...@texware.it Cc: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/radio/radio-mr800.c |1 + 1 file changed, 1 insertion(+) diff -puN drivers/media/radio/radio-mr800.c~radio-mr800c-missing-mutex-include drivers/media/radio/radio-mr800.c --- a/drivers/media/radio/radio-mr800.c~radio-mr800c-missing-mutex-include +++ a/drivers/media/radio/radio-mr800.c @@ -64,6 +64,7 @@ #include media/v4l2-ioctl.h #include linux/usb.h #include linux/version.h /* for KERNEL_VERSION MACRO */ +#include linux/mutex.h /* driver and module definitions */ #define DRIVER_AUTHOR Alexey Klimov klimov.li...@gmail.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
[patch 2/4] V4L/DVB: cimax2.c: fix / typo
From: Roel Kluin roel.kl...@gmail.com binary/logical and typo Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Abylay Ospan aos...@netup.ru Cc: Igor M. Liplianin liplia...@netup.ru Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/video/cx23885/cimax2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/media/video/cx23885/cimax2.c~v4l-dvb-cimax2c-fix-typo drivers/media/video/cx23885/cimax2.c --- a/drivers/media/video/cx23885/cimax2.c~v4l-dvb-cimax2c-fix-typo +++ a/drivers/media/video/cx23885/cimax2.c @@ -312,7 +312,7 @@ static void netup_read_ci_status(struct TS config = %02x\n, __func__, state-ci_i2c_addr, 0, buf[0], buf[32]); - if (buf[0] 1) + if (buf[0] 1) state-status = DVB_CA_EN50221_POLL_CAM_PRESENT | DVB_CA_EN50221_POLL_CAM_READY; else _ -- 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 4/4] zoran: fix /|| error
On Tue, May 12, 2009 at 4:39 PM, a...@linux-foundation.org wrote: From: Roel Kluin roel.kl...@gmail.com Fix /|| typo. `default_norm' can be 0 (PAL), 1 (NTSC) or 2 (SECAM), the condition tested was impossible. Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Andrew Morton a...@linux-foundation.org --- Hello, Was the patch actually tested against the hardware in question? While I agree that it looks ok, it can result in the default logic being inverted in some cases, which could expose other bugs and result in a regression. I just want to be confident that this patch was tested by somebody with the hardware and it isn't going into the codebase because it obviously cannot be right. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [patch 4/4] zoran: fix /|| error
Em Tue, 12 May 2009 17:18:20 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Tue, May 12, 2009 at 4:39 PM, a...@linux-foundation.org wrote: From: Roel Kluin roel.kl...@gmail.com Fix /|| typo. `default_norm' can be 0 (PAL), 1 (NTSC) or 2 (SECAM), the condition tested was impossible. Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Andrew Morton a...@linux-foundation.org --- Hello, Was the patch actually tested against the hardware in question? While I agree that it looks ok, it can result in the default logic being inverted in some cases, which could expose other bugs and result in a regression. I just want to be confident that this patch was tested by somebody with the hardware and it isn't going into the codebase because it obviously cannot be right. Hans and Jean worked on it. Both are at PAL area, so they won't notice such error without a standards generator, since the default is to assume that the signal is PAL. With this patch, PAL should keep working, but I can't see how NTSC or SECAM would work without it. Anyway, this patch were already committed on our tree, and it is on my linux-next tree since yesterday night. Hans, Could you please confirm that the patch is ok with your standards generator? 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 4/4] zoran: fix /|| error
On Tue, 12 May 2009, Mauro Carvalho Chehab wrote: Em Tue, 12 May 2009 17:18:20 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Tue, May 12, 2009 at 4:39 PM, a...@linux-foundation.org wrote: From: Roel Kluin roel.kl...@gmail.com Fix /|| typo. `default_norm' can be 0 (PAL), 1 (NTSC) or 2 (SECAM), the condition tested was impossible. Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Andrew Morton a...@linux-foundation.org --- Hello, Was the patch actually tested against the hardware in question? While I agree that it looks ok, it can result in the default logic being inverted in some cases, which could expose other bugs and result in a regression. I just want to be confident that this patch was tested by somebody with the hardware and it isn't going into the codebase because it obviously cannot be right. Hans and Jean worked on it. Both are at PAL area, so they won't notice such error without a standards generator, since the default is to assume that the signal is PAL. With this patch, PAL should keep working, but I can't see how NTSC or SECAM would work without it. NTSC works fine without it. The code with the bug was supposed to check for an out of range module parameter and fix it, but it was broken and did nothing. There is no problem if default_norm was set to an ok value, but if someone specified default_norm=42 then the driver wouldn't fix it and something bad might happen. Maybe it would read off the end of the norms array and crash? -- 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
[PULL] http://linuxtv.org/hg/~mkrufky/k2c2
Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/k2c2 for the following changesets: - cx23885: Add generic functions for driving GPIO's - cx23885: mark functions encoder_on_port[bc] as static inline - cx23885: Add preliminary support for the HVR1270 - cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1270 - cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1275 - cx23885: add ATSC/QAM tuning support for Hauppauge WinTV-HVR1255 - cx23885: add DVB-T tuning support for Hauppauge WinTV-HVR1210 - cx23885: update model matrix for k2c2 retail boards - cx23885: clean up struct names for Hauppauge WinTV-HVR127X devices Documentation/video4linux/CARDLIST.cx23885 |4 drivers/media/video/cx23885/cx23885-cards.c | 107 +- drivers/media/video/cx23885/cx23885-core.c | 86 +++- drivers/media/video/cx23885/cx23885-dvb.c | 92 drivers/media/video/cx23885/cx23885.h | 20 + 5 files changed, 297 insertions(+), 12 deletions(-) Cheers, Mike -- 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Hi Andy, Am Sonntag, den 10.05.2009, 19:39 -0400 schrieb Andy Walls: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 2 changesets: 01/02: cx18: Add missing newline to tuner detection error message http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=a107347b7d00 02/02: tveeprom: Point the TCL MNM05-4 tuner entry to an actual tuner definition http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=442f94c04f3d Reported-by: Matt Beadon matt.bea...@gmail.com Tested-by: Matt Beadon matt.bea...@gmail.com Matt has an HVR-1600 that has the TCL MNM05-4 tuner. Change 02/02 yields acceptable results for him. cx18/cx18-driver.c |2 +- tveeprom.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) call us whatever, but for tuners without radio support (FQ) we also have the entries Jarrod Wilson once added for the dual MCE 500 with one tea5767. That is this MK4 tuner=54 stuff, IIRC. (no tda9887) Might need better documentation these days. I'm still wondering, to which coasts we might ship with Dimitry's MK5. Cheers, Hermann -- 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
[snip] That is this MK4 tuner=54 stuff, IIRC. (no tda9887) sorry, that must have remind me to the real problems we had these days. The tuner=57 was meant. Hermann ;) -- 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
[PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
Mauro, Please pull from http://endr...@linuxtv.org/hg/~endriss/v4l-dvb for the following 5 changesets: 01/05: dvb-ttpci: Add TS replay capability http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=55fa4f709cf2 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d 03/05: dvb-ttpci: Fixed VIDEO_SLOWMOTION ioctl http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8861dce4bf05 04/05: dvb-ttpci: Fixed return code of av7110_av_start_play http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=da3ae7743446 05/05: dvb-ttpci: Some whitespace adjustments http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=0cf2638a9863 av7110_av.c | 124 1 file changed, 91 insertions(+), 33 deletions(-) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ -- 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
v4l-dvb rev 11757 broke building under Ubuntu Hardy
I am using v4l-dvb in order to add the cx18 driver under Ubuntu Hardy (8.04). The build is currently broken under Hardy, which uses kernel 2.6.24. I have traced the origin of the problem to revision 11757. As seen in the latest cron job output, the build produces the error when trying to compile adv7343.c: /usr/local/src/v4l-dvb/v4l/adv7343.c:506: error: array type has incomplete element type /usr/local/src/v4l-dvb/v4l/adv7343.c:518: warning: initialization from incompatible pointer type /usr/local/src/v4l-dvb/v4l/adv7343.c:520: error: unknown field 'id_table' specified in initializer Thanks for resolving this. David Ward -- 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
