How to interpret SNR, BER, Signal Strength from TT C-1501
Hello to all, can anybody tell me please, how to interpret SNR, BER and Signal Strength returned from the DVB API? I'm using the TT-budget C-1501. Or can anybody tell me, where I can find a documentation about this dbv-c card? Thanks a lot, Martin -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 -- 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
DViCO FusionHDTV DVB-T Hybrid Tuning Regression
Hi, I've been trying to track down a driver regression in my DViCO FusionHDTV DVB-T Hybrid card that makes it impossible to tune to DVB stations. In recent kernels (anything in past year) the card is detected and /dev/dvb tree is created but attempting to scan for channels only results in a 'tuning failed!!!'. Tuning works quite happily on the 2.6.17 kernel (very old) but appears to have broken somewhere around 2.6.22. Bisecting the v4l-dvb tree has the card turning at r4675, unable to compile r4676 and r4677, then no /dev/dvb tree being created until r5333 where tuning no longer works. I've had a look at these diffs and guess it's possible that it broke during the refactor at r4676, but being unable to test the card between r4676 and r5332 makes it quite hard to narrow down (I'm also unsure why r5333, apparently a change to the saa7134 code would have fixed the missing /dev/dvb tree). I'm a bit stuck at this point, but I do have a test machine set up and quite happy to put some time into helping fix this. Regards, David Coles -- 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
[SOLVED] Re: TT-S1500 budget-ci registeration
Thomas Kernen wrote: Thomas Kernen wrote: Hello to all, I'm currently testing a TT-S1500 budget card with the TT budget CI adapter with vl4 tree and kernel 2.6.28. When I modprobe budget_ci, the CI adapter seems to be detected but not registered in /dev/dvb/adapter3/ca0 as I would have expected it to be. Instead I see the following output: [ 148.664846] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:11:09.0/input/input5 Any suggestions/ideas what the cause may be and how I can attempt to solve this? Thanks Thomas -- And I realised I cut and pasted the wrong line: I was expecting to see budget_ci: CI interface initialised after the other line but nothing of the like did appear. Nor any line indicating an error. As one can see from the lspci the drivers claim to be in use: 11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Device 1017 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 123 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 23 Region 0: Memory at d022 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_ci dvb Kernel modules: budget-ci Am I missing a point here? I can't find anything that addresses this in the LinuxTV wiki or in the archives of the mailing list. It would appear that I enjoy speaking to myself on this mailer ;-) Anyway, good news is that the issue had to do with a defective cable that was bridging the Budget CI and the TT S-1500. It is now functional and descrambles the Viaccess streams I needed to test against. Later today I will update the wiki pages with the details of my setup: [8.850659] saa7146: register extension 'budget_ci dvb'. [8.850678] budget_ci dvb :11:08.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [8.850695] saa7146: found saa7146 @ mem c20001198000 (revision 1, irq 22) (0x13c2,0x1017). [8.850698] saa7146 (0): dma buffer size 192512 [8.850700] DVB: registering new adapter (TT-Budget/S-1500 PCI) [8.910869] adapter has MAC addr = 00:d0:5c:64:c2:55 [8.911046] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:11:08.0/input/input4 [8.972616] budget_ci: CI interface initialised [9.335816] LNBx2x attached on addr=8DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)... [9.340535] dvb_ca adapter 0: DVB CAM detected and initialised successfully CAM Application type: 01 CAM Application manufacturer: 02ca CAM Manufacturer code: 3000 CAM Menu string: PowerCam_HD V2.0.4 Hopefully this might be useful to others too. Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 0/9] FM Transmitter (si4713) and another changes
Hi Hans, On Sun, Jun 14, 2009 at 01:37:20PM +0200, ext Hans Verkuil wrote: On Friday 12 June 2009 19:30:31 Eduardo Valentin wrote: Hello all, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. Difference from version #6 is that now I've added added lots of comments made by Hans. Here is a list of changes: - Reduce card type string - Remove unused ext controls - Remove s/g_audio and add s/g_audout and enumaudout - remove g/s_input - remove s/g_tuner and add s/g_modulator on subdev and platform driver - reduce function names - Update documentation - remove a few unused and empty lines - remove sysfs interface - rename dev_to_v4l2 to si4713_to_v4l2 (and vice-versa) macros - Remove disabled controls - Add string support - remove v4l2_i2c_driver_data - Join si4713.c with si4713-subdev.c - move platform data to include/media - update documentation And now this series is based on two of Hans' trees: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2. http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-str. The first tree has refactoring of v4l2 i2c helper functions. The second one has string support for extended controls, which is used in this driver. So, now the series includes changes to add the new v4l2 FMTX extended controls (and its documetation) and si4713 i2c and platform drivers (and its documentation as well). Besides that, there is also a patch to add g_modulator to v4l2-subdev and a patch to add support for fm tx class in v4l2-ctl util. In the TODO list there are two things: i. the signal level measurement property is missing. ii. Re-factor the driver so all that get/set internal functions are removed. I believe those TODO's can be done later on, if there is still time to get this driver merged into this window. But of course, this is my opinion, I will understand also if you ask to do them before merge it. I think the refactoring should be done first. I don't believe it is that much work and experience shows that it is better to do this right away while you are still motivated :-) hehehe.. Yes, that's what I was expecting :-). No problem. I've started it. I will resend the series once I've completed the re-factoring and I 've made some testing after that. I hope tomorrow or so. The string control support should not go into 2.6.31. I would like to do that only in the v4l-dvb tree (so it will appear in 2.6.32) since I want to give that a bit more time to mature. I implemented it very quickly and I do not feel comfortable queueing this for 2.6.31. Right. Yes, better to test the stuff a bit more. In addition it is still unclear if Mauro will merge my v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will hamper the development of this and other embedded platforms. Ok. I also need to add a new V4L2_CAP_MODULATOR (which needs a review as well). And finally I realized that we need to add some v4l2_modulator capabilities for the RDS encoder similar to the upcoming v4l2_tuner RDS capabilities as is described in this RFC: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html I haven't had time to implement this RFC and I know that is not going to make 2.6.31. It's now almost at the top of my TODO list, so it should go in soon (pending unforeseen circumstances). Ok. I'll take a look at it. As a result of rereading this RFC I also started to wonder about whether the si4713 supports the MMBS functionality. Do you know anything about that? No. Not that I know. Can you point some link? Taken all together I think that 2.6.31 is probably not feasible. If it was another two weeks until the merge window, then it would. But the merge window is already open, and there are just too many little TODOs for this driver. And it's also a new API, so we need to be more careful than usual. Yes. Sure. Regards, Hans With these series, the driver is now functional through the v4l2 extended controls changes. Here is an output of v4l2-ctl: # v4l2-ctl -d /dev/radio0 -l --all Driver Info: Driver name : radio-si4713 Card type : Silicon Labs Si4713 Modulator Bus info : Driver version: 0 Capabilities : 0x0008 Modulator Audio output: 0 (FM Modulator Audio Out) Frequency: 1552000 (97000.00 MHz) Video Standard = 0x Modulator: Name : FM Modulator Capabilities : 62.5 Hz stereo Frequency range : 76.0 MHz - 108.0 MHz Available subchannels: mono stereo User Controls mute (bool) : default=1 value=0 FM Radio Modulator Controls rds_feature_enabled (bool) : default=1 value=1 rds_program_id (int) : min=0
Re: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Sun, Jun 14, 2009 at 06:59:13PM +0200, ext Hans Verkuil wrote:
On Sunday 14 June 2009 18:23:41 Trent Piepho wrote:
On Sun, 14 Jun 2009, Eduardo Valentin wrote:
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX |
1)
+
+#define V4L2_CID_RDS_ENABLED
(V4L2_CID_FM_TX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY
(V4L2_CID_FM_TX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME
(V4L2_CID_FM_TX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FM_TX_CLASS_BASE + 5)
I think these RDS controls should be renamed to V4L2_CID_RDS_TX_. This
makes
it clear that these controls relate to the RDS transmitter instead of a
receiver. I would not be surprised to see similar controls appear for
an RDS
receiver in the future.
So there should there be different controls to set the same thing, one set
for tx and another for rx?
Sure. Say some RDS decoder stores the PI in a register. I can imagine that
we add a V4L2_CID_RDS_RX_PI control for that. Whereas a V4L2_CID_RDS_TX_PI
control will return the PI sent out by the encoder.
Currently no such controls exist (or are needed) for an RDS decoder, but I
wouldn't be surprised at all if we need them at some point in the future.
+#define V4L2_CID_PREEMPHASIS
(V4L2_CID_FM_TX_CLASS_BASE + 17)
+enum v4l2_fm_tx_preemphasis {
+ V4L2_FM_TX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FM_TX_PREEMPHASIS_50_uS = 1,
+ V4L2_FM_TX_PREEMPHASIS_75_uS = 2,
+};
I suggest renaming this to V4L2_CID_FM_TX_PREEMPHASIS. There is already
a
similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in
the
future, so I think this name should be more specific to the FM_TX API.
The cx88 driver could get support for setting the fm preemphasis via a
control. I added support via a module option, but a control would be
better. You're saying it shouldn't use this fm preemphasis control?
Correct. This set the pre-emphasis when transmitting. For receiving you want
a separate control. Although the enum should be made generic. So FM_TX can be
removed from the enum.
Why should we have one rx and one tx control for this? Because you can have
both receivers and transmitters in one device and you want independent control
of the two.
Yes, agreed here. There is the possibility to have receiver and transmitter
both in the same device. So, I think it is better to have separated controls.
It is my believe that the other fm_tx controls are unambiguously transmitter
related, so I don't think they need a TX prefix. It doesn't hurt if someone
can double check that, though.
hmm.. I see no problem removing the fmtx prefix of the preemphasis
enum. But, if it is becoming a generic enum, better to check if its
meaning is the same of existing emphasis enum for mpeg.
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
--
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: [PATCHv7 0/9] FM Transmitter (si4713) and another changes
On Tuesday 16 June 2009 12:47:14 Eduardo Valentin wrote: Hi Hans, On Sun, Jun 14, 2009 at 01:37:20PM +0200, ext Hans Verkuil wrote: snip I think the refactoring should be done first. I don't believe it is that much work and experience shows that it is better to do this right away while you are still motivated :-) hehehe.. Yes, that's what I was expecting :-). No problem. I've started it. I will resend the series once I've completed the re-factoring and I 've made some testing after that. I hope tomorrow or so. The string control support should not go into 2.6.31. I would like to do that only in the v4l-dvb tree (so it will appear in 2.6.32) since I want to give that a bit more time to mature. I implemented it very quickly and I do not feel comfortable queueing this for 2.6.31. Right. Yes, better to test the stuff a bit more. In addition it is still unclear if Mauro will merge my v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will hamper the development of this and other embedded platforms. Ok. I also need to add a new V4L2_CAP_MODULATOR (which needs a review as well). And finally I realized that we need to add some v4l2_modulator capabilities for the RDS encoder similar to the upcoming v4l2_tuner RDS capabilities as is described in this RFC: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html I haven't had time to implement this RFC and I know that is not going to make 2.6.31. It's now almost at the top of my TODO list, so it should go in soon (pending unforeseen circumstances). Ok. I'll take a look at it. I've worked on this yesterday. You can take a look at my v4l-dvb-rds tree. Both the API and the documentation of it in the v4l2-spec is in there. I started work on updating the few RDS decoders that we have, but that is not yet in that tree. As a result of rereading this RFC I also started to wonder about whether the si4713 supports the MMBS functionality. Do you know anything about that? No. Not that I know. Can you point some link? http://www.rds.org.uk/rdsfrdsrbds.html But I've just read here: http://www.rds.org.uk/rds98/pdf/rdsForum_standards_090414_8.pdf that MMBS is discontinued. I'll need to investigate this further, but if this is indeed true then this can be removed completely from our RDS decoder and encoder APIs. 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: [PATCHv7 0/9] FM Transmitter (si4713) and another changes
On Tue, Jun 16, 2009 at 01:01:51PM +0200, ext Hans Verkuil wrote: On Tuesday 16 June 2009 12:47:14 Eduardo Valentin wrote: Hi Hans, On Sun, Jun 14, 2009 at 01:37:20PM +0200, ext Hans Verkuil wrote: snip I think the refactoring should be done first. I don't believe it is that much work and experience shows that it is better to do this right away while you are still motivated :-) hehehe.. Yes, that's what I was expecting :-). No problem. I've started it. I will resend the series once I've completed the re-factoring and I 've made some testing after that. I hope tomorrow or so. The string control support should not go into 2.6.31. I would like to do that only in the v4l-dvb tree (so it will appear in 2.6.32) since I want to give that a bit more time to mature. I implemented it very quickly and I do not feel comfortable queueing this for 2.6.31. Right. Yes, better to test the stuff a bit more. In addition it is still unclear if Mauro will merge my v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will hamper the development of this and other embedded platforms. Ok. I also need to add a new V4L2_CAP_MODULATOR (which needs a review as well). And finally I realized that we need to add some v4l2_modulator capabilities for the RDS encoder similar to the upcoming v4l2_tuner RDS capabilities as is described in this RFC: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html I haven't had time to implement this RFC and I know that is not going to make 2.6.31. It's now almost at the top of my TODO list, so it should go in soon (pending unforeseen circumstances). Ok. I'll take a look at it. I've worked on this yesterday. You can take a look at my v4l-dvb-rds tree. Both the API and the documentation of it in the v4l2-spec is in there. I started work on updating the few RDS decoders that we have, but that is not yet in that tree. As a result of rereading this RFC I also started to wonder about whether the si4713 supports the MMBS functionality. Do you know anything about that? No. Not that I know. Can you point some link? http://www.rds.org.uk/rdsfrdsrbds.html But I've just read here: http://www.rds.org.uk/rds98/pdf/rdsForum_standards_090414_8.pdf that MMBS is discontinued. I'll need to investigate this further, but if this is indeed true then this can be removed completely from our RDS decoder and encoder APIs. Yes, better to double check. At least with si4713, I haven't heard anything about this. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Tuesday 16 June 2009 12:52:34 Eduardo Valentin wrote: It is my believe that the other fm_tx controls are unambiguously transmitter related, so I don't think they need a TX prefix. It doesn't hurt if someone can double check that, though. hmm.. I see no problem removing the fmtx prefix of the preemphasis enum. But, if it is becoming a generic enum, better to check if its meaning is the same of existing emphasis enum for mpeg. It has the same meaning, but unfortunately the mpeg enum is already a public API and so cannot be changed. I never realized at the time that that enum is more generic than I thought. But at least this enum can be made generic. 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: [PATCHv7 7/9] FMTx: si4713: Add files to handle si4713 i2c device
On Tuesday 16 June 2009 13:06:09 Eduardo Valentin wrote: On Sun, Jun 14, 2009 at 02:31:55PM +0200, ext Hans Verkuil wrote: + if (rval 0) + goto exit; + + /* TODO: How to set frequency to measure current signal length */ Huh? I don't understand this TODO. The todo is about the property this device had, to report signal length 'signal length' or 'signal strength'? If it is the former, then I don't understand what you mean with that term. of a freq. It used to work like: user echoes the freq on sysfs entry. when reading the same entry, it reports the signal noise there. This is something which I still don't know the proper place to put. I thought in another ext control. But I don't know if this fix into the fm tx controls. Maybe I should use a private one ? I need to understand this better first. 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: [PATCHv7 7/9] FMTx: si4713: Add files to handle si4713 i2c device
On Tue, 2009-06-16 at 13:22 +0200, ext Hans Verkuil wrote: On Tuesday 16 June 2009 13:06:09 Eduardo Valentin wrote: On Sun, Jun 14, 2009 at 02:31:55PM +0200, ext Hans Verkuil wrote: + if (rval 0) + goto exit; + + /* TODO: How to set frequency to measure current signal length */ Huh? I don't understand this TODO. The todo is about the property this device had, to report signal length 'signal length' or 'signal strength'? If it is the former, then I don't understand what you mean with that term. of a freq. It used to work like: user echoes the freq on sysfs entry. when reading the same entry, it reports the signal noise there. This is something which I still don't know the proper place to put. I thought in another ext control. But I don't know if this fix into the fm tx controls. Maybe I should use a private one ? I need to understand this better first. Regards, Hans Transmitter turns into a receiver and measures the RSSI level of the frequency. If it's high ( -90 -100dB), it's probably not a good idea to transmit any on such frequency as the interference is too great. - 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] Add the DTV_ISDB_TS_ID property for ISDB-S
Hi Hirano,
Em Fri, 08 May 2009 00:24:11 +0900
hiranot...@zng.info escreveu:
# HG changeset patch
# User HIRANO Takahito hiranot...@zng.info
# Date 1235532786 -32400
# Node ID 5e6932c1b659d6bfea781a81d06098e85c6ff203
# Parent fe524e0a64126791bdf3dd94a50bdcdb0592ef7f
Add the DTV_ISDB_TS_ID property for ISDB-S
In ISDB-S, time-devision duplex is used to multiplexing several waves
in the same frequency. Each wave is identified by its own transport
stream ID, or TS ID. We need to provide some way to specify this ID
from user applications to handle ISDB-S frontends.
This code has been tested with Earthsoft PT1 driver, which is under
development at:
http://bitbucket.org/hiranotaka/dvb-pt1/
API changes should be submitted together with the driver. This allows us to
better understand driver needs.
So, please re-submit this when you'll be ready to submit your driver.
Thanks,
Mauro.
Signed-off-by: HIRANO Takahito hiranot...@zng.info
diff -r fe524e0a6412 -r 5e6932c1b659
linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Tue May 05 08:50:54
2009 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Feb 25 12:33:06
2009 +0900
@@ -946,6 +946,11 @@
.cmd= DTV_TRANSMISSION_MODE,
.set= 1,
},
+ [DTV_ISDB_TS_ID] = {
+ .name = DTV_ISDB_TS_ID,
+ .cmd= DTV_ISDB_TS_ID,
+ .set= 1,
+ },
/* Get */
[DTV_DISEQC_SLAVE_REPLY] = {
.name = DTV_DISEQC_SLAVE_REPLY,
@@ -1354,6 +1359,9 @@
case DTV_HIERARCHY:
tvp-u.data = fe-dtv_property_cache.hierarchy;
break;
+ case DTV_ISDB_TS_ID:
+ tvp-u.data = fe-dtv_property_cache.isdb_ts_id;
+ break;
default:
r = -1;
}
@@ -1460,6 +1468,9 @@
case DTV_HIERARCHY:
fe-dtv_property_cache.hierarchy = tvp-u.data;
break;
+ case DTV_ISDB_TS_ID:
+ fe-dtv_property_cache.isdb_ts_id = tvp-u.data;
+ break;
default:
r = -1;
}
diff -r fe524e0a6412 -r 5e6932c1b659
linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Tue May 05 08:50:54
2009 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Feb 25 12:33:06
2009 +0900
@@ -355,6 +355,7 @@
fe_modulation_t isdb_layerc_modulation;
u32 isdb_layerc_segment_width;
#endif
+ u32 isdb_ts_id;
};
struct dvb_frontend {
diff -r fe524e0a6412 -r 5e6932c1b659 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h Tue May 05 08:50:54 2009 -0300
+++ b/linux/include/linux/dvb/frontend.h Wed Feb 25 12:33:06 2009 +0900
@@ -307,7 +307,9 @@
#define DTV_TRANSMISSION_MODE39
#define DTV_HIERARCHY40
-#define DTV_MAX_COMMAND DTV_HIERARCHY
+#define DTV_ISDB_TS_ID 41
+
+#define DTV_MAX_COMMAND DTV_ISDB_TS_ID
typedef enum fe_pilot {
PILOT_ON,
--
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
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: [PATCHv7 7/9] FMTx: si4713: Add files to handle si4713 i2c device
On Tue, Jun 16, 2009 at 01:30:08PM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: On Tue, 2009-06-16 at 13:22 +0200, ext Hans Verkuil wrote: On Tuesday 16 June 2009 13:06:09 Eduardo Valentin wrote: On Sun, Jun 14, 2009 at 02:31:55PM +0200, ext Hans Verkuil wrote: + if (rval 0) + goto exit; + + /* TODO: How to set frequency to measure current signal length */ Huh? I don't understand this TODO. The todo is about the property this device had, to report signal length 'signal length' or 'signal strength'? If it is the former, then I don't understand what you mean with that term. of a freq. It used to work like: user echoes the freq on sysfs entry. when reading the same entry, it reports the signal noise there. This is something which I still don't know the proper place to put. I thought in another ext control. But I don't know if this fix into the fm tx controls. Maybe I should use a private one ? I need to understand this better first. Regards, Hans Transmitter turns into a receiver and measures the RSSI level of the frequency. If it's high ( -90 -100dB), it's probably not a good idea to transmit any on such frequency as the interference is too great. Yes, sorry I've made some really bad phrasing. It is Strength. It is a feature to measure Received Signal Strength Indication (RSSI). As mentioned by Eero, it's not a good idea to transmit any on freq which the measurement is being done. - 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
Re: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Tue, Jun 16, 2009 at 01:18:57PM +0200, ext Hans Verkuil wrote: On Tuesday 16 June 2009 12:52:34 Eduardo Valentin wrote: It is my believe that the other fm_tx controls are unambiguously transmitter related, so I don't think they need a TX prefix. It doesn't hurt if someone can double check that, though. hmm.. I see no problem removing the fmtx prefix of the preemphasis enum. But, if it is becoming a generic enum, better to check if its meaning is the same of existing emphasis enum for mpeg. It has the same meaning, but unfortunately the mpeg enum is already a public API and so cannot be changed. I never realized at the time that that enum is more generic than I thought. But at least this enum can be made generic. Yes, sure. 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 -- 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: [PATCHv7 7/9] FMTx: si4713: Add files to handle si4713 i2c device
On Tue, 2009-06-16 at 13:50 +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: Yes, sorry I've made some really bad phrasing. It is Strength. It is a feature to measure Received Signal Strength Indication (RSSI). As mentioned by Eero, it's not a good idea to transmit any on freq which the measurement is being done. It can't transmit any while this measuring is taking place - it's not a good idea to transmit any, if the measurement has been taking place and it is discovered that there's already a strong radio signal (on freq x). So it can be used to find out a channel that's good for transmission =) - 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] [09051_49] Siano: smscore - upgrade firmware loading engine
The README.patches file in v4l-dvb clearly states that it is OK to use version
checking to allow backporting.
k) Sometimes it is necessary to introduce some testing code inside a
module or remove parts that are not yet finished. Also, compatibility
tests may be required to provide backporting.
To allow compatibility tests, linux/version.h is automatically
included by the building system. This allows adding tests like:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)
#include linux/mutex.h
#else
#include asm/semaphore.h
#endif
The patch allows older version of the kernel, and embedded platforms, that
choose not to include the request firmware mechanism to continue working with
the Siano driver.
As for the SMS_HOSTLIB_SUBSYS, the Siano driver supports standards which are
not currently implemented in V4L (i.e. CMMB). I see no reason why we should
create a duplicate driver for DVB-T and CMMB, if the codebase is exactly the
same.
Best regards,
Udi Atar
-Original Message-
From: linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Michael Krufky
Sent: Tuesday, May 19, 2009 7:24 PM
To: Uri Shkolnik
Cc: LinuxML; Mauro Carvalho Chehab
Subject: Re: [PATCH] [09051_49] Siano: smscore - upgrade firmware loading engine
On Tue, May 19, 2009 at 11:43 AM, Uri Shkolnik uri...@yahoo.com wrote:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242748115 -10800
# Node ID 4d75f9d1c4f96d65a8ad312c21e488a212ee58a3
# Parent cfb4106f3ceaee9fe8f7e3acc9d4adec1baffe5e
[09051_49] Siano: smscore - upgrade firmware loading engine
From: Uri Shkolnik u...@siano-ms.com
Upgrade the firmware loading (download and switching) engine.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r cfb4106f3cea -r 4d75f9d1c4f9
linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.c Tue May 19 18:38:07
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.c Tue May 19 18:48:35
2009 +0300
@@ -28,7 +28,7 @@
#include linux/dma-mapping.h
#include linux/delay.h
#include linux/io.h
-
+#include linux/uaccess.h
#include linux/firmware.h
#include linux/wait.h
#include asm/byteorder.h
@@ -36,7 +36,13 @@
#include smscoreapi.h
#include sms-cards.h
#include smsir.h
-#include smsendian.h
+#define MAX_GPIO_PIN_NUMBER 31
+
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 10)
+#define REQUEST_FIRMWARE_SUPPORTED
+#else
+#define DEFAULT_FW_FILE_PATH /lib/firmware
+#endif
static int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
@@ -459,8 +465,6 @@ static int smscore_init_ir(struct smscor
msg-msgData[0] = coredev-ir.controller;
msg-msgData[1] = coredev-ir.timeout;
- smsendian_handle_tx_message(
- (struct SmsMsgHdr_ST2 *)msg);
rc = smscore_sendrequest_and_wait(coredev, msg,
msg-xMsgHeader. msgLength,
coredev-ir_init_done);
@@ -486,12 +490,16 @@ static int smscore_init_ir(struct smscor
*/
int smscore_start_device(struct smscore_device_t *coredev)
{
- int rc = smscore_set_device_mode(
- coredev, smscore_registry_getmode(coredev-devpath));
+ int rc;
+
+#ifdef REQUEST_FIRMWARE_SUPPORTED
+ rc = smscore_set_device_mode(coredev, smscore_registry_getmode(
+ coredev-devpath));
if (rc 0) {
- sms_info(set device mode faile , rc %d, rc);
+ sms_info(set device mode failed , rc %d, rc);
return rc;
}
+#endif
kmutex_lock(g_smscore_deviceslock);
@@ -632,11 +640,14 @@ static int smscore_load_firmware_from_fi
loadfirmware_t loadfirmware_handler)
{
int rc = -ENOENT;
+ u8 *fw_buf;
+ u32 fw_buf_size;
+
+#ifdef REQUEST_FIRMWARE_SUPPORTED
const struct firmware *fw;
- u8 *fw_buffer;
- if (loadfirmware_handler == NULL !(coredev-device_flags
- SMS_DEVICE_FAMILY2))
+ if (loadfirmware_handler == NULL !(coredev-device_flags
+ SMS_DEVICE_FAMILY2))
return -EINVAL;
rc = request_firmware(fw, filename, coredev-device);
@@ -645,26 +656,36 @@ static int smscore_load_firmware_from_fi
return rc;
}
sms_info(read FW %s, size=%zd, filename, fw-size);
- fw_buffer = kmalloc(ALIGN(fw-size, SMS_ALLOC_ALIGNMENT),
- GFP_KERNEL | GFP_DMA);
-
[PATCH] USB interrupt support for radio-si470x FM radio driver
Please find below my attempt at removing 'manual' polling from the
radio-si470x USB FM radio driver, by moving to URB interrupt callback
handlers.
This code significantly improves RDS reception - radiotext in
particular - and improves audio quality on my Silabs FM USB dongle, as
lots of pops and clicks have now disappeared. Your mileage may vary.
Issues remain when userspace programs do V4L ioctl calls to the
dongle: this creates clicks in the audio.
I am by no means a professional driver writer and the code below is
most probably in need of a proper review by someone more experienced
than me in writing Linux USB drivers. It does not raise issues on the
machines where I have tested it, but this is hardly proof it's good.
Any help will be much appreciated. It is only tested on the dongle I
own, a Silabs Reference Design FM receiver dongle.
Last: there are a few bits left commented out in my patched version,
those are kept to help code review if someone wants to help, they
should probably be removed from a final release.
Thanks for your feedback!
Signed-off-by: Edouard Lafargue edou...@lafargue.name
diff -Nur ../radio-si470x.c radio-si470x.c
--- ../radio-si470x.c 2008-12-25 00:26:37.0 +0100
+++ radio-si470x.c 2009-06-16 14:20:07.0 +0200
@@ -97,9 +97,14 @@
* - add support for KWorld USB FM Radio FM700
* - blacklisted KWorld radio in hid-core.c and hid-ids.h
*
+ * 2009-06-16 Edouard Lafargue edou...@lafargue.name
+ * Version 1.0.9
+ * - add support for interrupt mode for RDS endpoint, instead of
polling.
+ *
* ToDo:
* - add firmware download/update support
- * - RDS support: interrupt mode, instead of polling
+ * - RDS support: debug interrupt mode and use of URBs further!
+ * - Use URBs for all USB communications
* - add LED status output (check if that's not already done in firmware)
*/
@@ -107,10 +112,10 @@
/* driver definitions */
#define DRIVER_AUTHOR Tobias Lorenz tobias.lor...@gmx.net
#define DRIVER_NAME radio-si470x
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 8)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9)
#define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver
#define DRIVER_DESC USB radio driver for Si470x FM Radio Receivers
-#define DRIVER_VERSION 1.0.8
+#define DRIVER_VERSION 1.0.9
/* kernel includes */
@@ -207,13 +212,14 @@
MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*);
/* RDS poll frequency */
-static unsigned int rds_poll_time = 40;
+/* TODO: remove this since not used anymore as we now use the interrupt URB */
+/* static unsigned int rds_poll_time = 40; */
/* 40 is used by the original USBRadio.exe */
/* 50 is used by radio-cadet */
/* 75 should be okay */
/* 80 is the usual RDS receive interval */
-module_param(rds_poll_time, uint, 0644);
-MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*);
+/* module_param(rds_poll_time, uint, 0644); */
+/* MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*); */
@@ -440,6 +446,12 @@
struct usb_interface *intf;
struct video_device *videodev;
+ /* Interrupt endpoint handling */
+ char*int_in_buffer;
+ struct usb_endpoint_descriptor *int_in_endpoint;
+ struct urb *int_in_urb;
+ int int_in_running;
+
/* driver management */
unsigned int users;
unsigned char disconnected;
@@ -578,37 +590,6 @@
}
-/*
- * si470x_get_rds_registers - read rds registers
- */
-static int si470x_get_rds_registers(struct si470x_device *radio)
-{
- unsigned char buf[RDS_REPORT_SIZE];
- int retval;
- int size;
- unsigned char regnr;
-
- buf[0] = RDS_REPORT;
-
- retval = usb_interrupt_msg(radio-usbdev,
- usb_rcvintpipe(radio-usbdev, 1),
- (void *) buf, sizeof(buf), size, usb_timeout);
- if (size != sizeof(buf))
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- return size differs: %d != %zu\n, size, sizeof(buf));
- if (retval 0)
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- usb_interrupt_msg returned %d\n, retval);
-
- if (retval = 0)
- for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++)
- radio-registers[STATUSRSSI + regnr] =
- get_unaligned_be16(
- buf[regnr * RADIO_REGISTER_SIZE + 1]);
-
- return (retval 0) ? -EINVAL : 0;
-}
-
/*
* si470x_set_chan - set the channel
@@ -882,105 +863,118 @@
**/
/*
- * si470x_rds - rds processing function
+ * si470x_int_in_callback - rds callback and processing function
+ *
+ * TODO: do we need to use mutex locks in some sections?
*/
-static void si470x_rds(struct si470x_device
OMAP patches for linux-media
Hi Sakari and others, I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. However, it is hard to track all those discussions and be sure what patches are ready for merging and what patches are just RFC. On the development model we use here, we have driver maintainers that are responsible to discuss about improvements on their drivers. They are generally the driver authors or the one that first started submitting the patches for that driver(s). One of the roles of the driver maintainers is to collect the patches for the drivers they maintain, merge on their trees, and periodically ask the patch merge. One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big patch. Every time I receive a big patch I need to postpone its analysis and open a big window on my schedule to analyze it. Of course, this means to postpone it, and generally results on lots of comments going back to developer, that, in turn, will need to do lots of changes and return me back with another big patch for me to analyze again, resulting on a long period of time for merging it. As you, Sakari, was the first one that started merging the OMAP drivers, I was expecting that you would be the one that will handle the figure of the driver maintainer for OMAP. I even created you an account at linuxtv for you to create your trees there and ask me to merge from it. Unfortunately, you haven't sent me any pull requests yet along this year. This is concerning me a lot, since, at the end, I'll need to review big piles of patches and/or drivers when you decide to submit the final version. So, I decided to send you this email, c/c a random list of people that I believe are involved on the submit and/or review process of those patches, in the hope to better understand and to discuss what's happening and how can we speedup the merge process of those patches. 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] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Could you please, describe in more detail how you merged them? However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there, convert it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one, and finally make it work with soc-camera. This way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP patches for linux-media
From: Mauro Carvalho Chehab [mche...@infradead.org] Sent: Tuesday, June 16, 2009 8:40 AM To: Sakari Ailus Cc: Jadav, Brijesh R; Subrahmanya, Chaithrika; David Cohen; Curran, Dominic; Eduardo Valentin; Eero Nurkkala; Felipe Balbi; Shah, Hardik; Nagalla, Hari; Hadli, Manjunath; Mikko Hurskainen; Karicheri, Muralidharan; Menon, Nishanth; R, Sivaraj; Paulraj, Sandeep; Aguirre Rodriguez, Sergio Alberto; Tomi Valkeinen; Tuukka Toivonen; Hiremath, Vaibhav; Hans Verkuil; Linux Media Mailing List Subject: OMAP patches for linux-media Hi Sakari and others, I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. However, it is hard to track all those discussions and be sure what patches are ready for merging and what patches are just RFC. On the development model we use here, we have driver maintainers that are responsible to discuss about improvements on their drivers. They are generally the driver authors or the one that first started submitting the patches for that driver(s). One of the roles of the driver maintainers is to collect the patches for the drivers they maintain, merge on their trees, and periodically ask the patch merge. One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big patch. Every time I receive a big patch I need to postpone its analysis and open a big window on my schedule to analyze it. Of course, this means to postpone it, and generally results on lots of comments going back to developer, that, in turn, will need to do lots of changes and return me back with another big patch for me to analyze again, resulting on a long period of time for merging it. As you, Sakari, was the first one that started merging the OMAP drivers, I was expecting that you would be the one that will handle the figure of the driver maintainer for OMAP. I even created you an account at linuxtv for you to create your trees there and ask me to merge from it. Unfortunately, you haven't sent me any pull requests yet along this year. This is concerning me a lot, since, at the end, I'll need to review big piles of patches and/or drivers when you decide to submit the final version. So, I decided to send you this email, c/c a random list of people that I believe are involved on the submit and/or review process of those patches, in the hope to better understand and to discuss what's happening and how can we speedup the merge process of those patches. Hi Mauro, We are currently going through an internal debugging process on new found issues while testing the driver on a proprietary HW/SW platform. As there is priority for us to find stability in this platforms, we had to put aside a bit the maintenance of the shared patches. One maybe important news is that I'll be creating a new tree soon to host current OMAP3 and future OMAP4 camera drivers for upstream from TI perspective. My main task will be to maintain this tree in TI, and take care of upstreaming and fixing patches for acceptance by both linux-omap and linux-media lists. Some of the known to-dos are: - v4l2_subdev conversion - Regulator framework usage - ISP registration as a memory to memory device. I hope to resume this task soon, and keep in touch with the community on the latest version of patches. I'll let you know when the next version is ready for merge. Thanks for your concern and time on this. Regards, Sergio 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 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
Hans, Thanks for the response. snip Polarities have to be set for each side, that's correct. The other parameters are common for both. Although I can think of scenarios where the bus width can differ between host and subdev (e.g. subdev sends data on 8 pins and the host captures on 10 with the least significant two pins pulled low). But that's probably really paranoid of me :-) [MK] You are right on width. The MT9T001/31 sensor has 10 bits and MT9P031 has 12 bits, but on DM355 we the vpfe will take in only 10 bits and on DM365 it takes 12 bits. But this is applicable only on the host (vpfe) side though (at least in this case) , not on sub device side. snip First of all, this isn't a blocking issue at all. This is more a nice-to-have. The reason I mentioned it is because of how we use this (or the dm646x to be precise) at my work: the dm646x is connected to our FPGA so we had to make dummy encoder/decoder drivers to allow it to work with that driver. What made that somewhat annoying is that those dummy drivers really didn't do anything since the FPGA isn't programmed from the linux kernel at all. So we have basically dead code in our kernel just to satisfy a dm646x driver requirement. And you are right: a subdev is bus independent, so it is perfectly possible to make a dummy subdev instead. The key phrase was really 'doesn't require any setup'. It would be nice to be able to use this driver 'standalone' without requiring a subdev. Something to think about. And apologies for my poor review comment, that was phrased rather badly. [MK] This is the first version of the driver and I assure you that there are opportunities to improve the driver as we add more features. Since many of the other activities like adding camera interface, supporting resizer/previewer are dependent on this, it is important for us to get this to the kernel tree as quickly as possible. So I would prefer to keep it as is now and change it part of later patches. If this can go in 2.6.31, that will be really great. snip Don't use these PRIVATE_BASE controls. See also this post regarding the current situation regarding private controls: http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg07999.html [MK] Looks like it is better to add it to TBD and address it when I add camera interface support. OK, but please make sure it is revisited. Improving the control handling code in the v4l2 framework is very high on my TODO list since it is getting really annoying to implement in drivers. And the inconsistent driver support isn't helping applications either. [MK] Sure. I will add it to the TODO list and address it later. I really hope I'll have time for it in the next few weeks. 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] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Could you please, describe in more detail how you merged them? Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything. Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision. However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there, That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier). convert it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one, That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev. While it would be nice to get a single driver working for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev) So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms. *looks hopefully in the direction of Jonathan Corbet and other olpc owners* and finally make it work with soc-camera. This way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound? Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten. I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers. The original posting I made was as close as you can reasonably get to Jonathan's original driver. http://patchwork.kernel.org/patch/12192/ At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that. I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test. Jonathan -- 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: Leadtek Winfast DTV-1000S
On Sun, Jun 7, 2009 at 6:39 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Montag, den 08.06.2009, 07:59 +1000 schrieb pau...@planar.id.au: That is fantastic news. Not only will it be coming soon, but I don't have to do it myself!! How will we know when the test repository is created - will it be announced on this list? Thanks, Paul Henry Wu did send modified saa7134 files with support for this card on Tuesday off list. Mike replied, that he will set up a test repository as soon he gets some time for doing so. Paul, give Mike some time for it. There are much more variables in question, that can be different on devices now seen in the wild for the first time and a proper framework must be employed. If you can't wait, ask Mike do send you the files, seems they are recent enough for current v4l-dvb, but better is to wait and start with some unified testing base. Cheers, Hermann Hello all, Apologies for the delay -- I've been extremely busy over the past few weeks, but that's nothing new :-P Anyhow, I pushed up some code almost 2 weeks ago that should cover the DTV1000S in all variations. Thanks to Terry Wu for the baseband video gpio setup. I haven't had time to ask anybody to test this yet, so I'd appreciate it if you can provide some general feedback. This change only adds support for the new card, so I am not interested in anybody's experience with other boards -- this ONLY relates to the DTV1000S. Terry's patches copy the device specific setup from the Hauppauge HVR1110 -- this is actually dangerous, as the HVR1110 GPIO / LNA setup could cause problems when used on other boards. Terry's patches also support a version of the board with a TDA18271c2 -- I don't know if such a board actually exists, but the way that Terry did it doesn't allow for supporting both variations in a single kernel. If the c2 version of the board actually exists, the code that I pushed will work on board boards. I'd like to see dmesg output while using my tree -- please include full device initialization, starting with the line, Linux video capture interface: v2.00 up till the end. I am especially interested to see whether or not the TDA8295 driver attaches successfully -- I have a feeling that there actually is no TDA8295 on that board, but I don't know for sure, offhand. Please test the following tree: http://kernellabs.com/hg/~mkrufky/dtv1000s - saa7134: add initial DVB-T support for the Leadtek DTV1000S - saa7134: add support for baseband video capture on Leadtek DTV1000S Documentation/video4linux/CARDLIST.saa7134 |1 drivers/media/video/saa7134/saa7134-cards.c | 22 + drivers/media/video/saa7134/saa7134-dvb.c | 39 ++ drivers/media/video/saa7134/saa7134.h |1 4 files changed, 63 insertions(+) Cheers, Mike Krufky -- 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: OMAP patches for linux-media
Hi Mauro, [snip] I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. [MK] I along with Chaithrika are working with Hans Verkuil to get the DaVinci video drivers added to open source. I believe VPIF display driver for DM6467 is ready for merge. The VPFE capture driver for DM355 and DM6446 is almost ready. I will be creating the version 3 (hopefully final) version of the patch and review the same in the list. Do you think these patches can be merged to 2.6.31? This will be of great help to us if this can be done since we have other works lined up based on these and our customers are waiting for this for a very long time. [snip] One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big [MK] With that in mind, we began our porting work with minimum set of features and stripped off many of the features so that we can add them incrementally. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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 V2] poll method lose race condition
Em Mon, 01 Jun 2009 10:05:04 +0800
Figo.zhang figo1...@gmail.com escreveu:
bttv-driver.c,cx23885-video.c,cx88-video.c: poll method lose race condition
for capture video.
In v2, use the clear logic.Thanks to Trent Piepho's help.
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/bt8xx/bttv-driver.c | 20
drivers/media/video/cx23885/cx23885-video.c | 15 +++
drivers/media/video/cx88/cx88-video.c | 15 +++
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 23b7499..8d20528 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -3152,6 +3152,7 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
struct bttv_fh *fh = file-private_data;
struct bttv_buffer *buf;
enum v4l2_field field;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!check_alloc_btres(fh-btv,fh,RESOURCE_VBI))
@@ -3160,9 +3161,10 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
}
if (check_btres(fh,RESOURCE_VIDEO_STREAM)) {
+ mutex_lock(fh-cap.vb_lock);
/* streaming capture */
if (list_empty(fh-cap.stream))
- return POLLERR;
+ return done;
Here, you're keeping the mutex locked. Maybe you wanted to do a goto done ?
buf = list_entry(fh-cap.stream.next,struct
bttv_buffer,vb.stream);
} else {
/* read() capture */
@@ -3170,16 +3172,16 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
if (NULL == fh-cap.read_buf) {
/* need to capture a new frame */
if (locked_btres(fh-btv,RESOURCE_VIDEO_STREAM))
- goto err;
+ goto done;
fh-cap.read_buf = videobuf_sg_alloc(fh-cap.msize);
if (NULL == fh-cap.read_buf)
- goto err;
+ goto done;
fh-cap.read_buf-memory = V4L2_MEMORY_USERPTR;
field = videobuf_next_field(fh-cap);
if (0 !=
fh-cap.ops-buf_prepare(fh-cap,fh-cap.read_buf,field)) {
kfree (fh-cap.read_buf);
fh-cap.read_buf = NULL;
- goto err;
+ goto done;
}
fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf);
fh-cap.read_off = 0;
@@ -3191,11 +3193,13 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
-err:
+ rc = POLLIN|POLLRDNORM;
+ else
+ rc = 0;
+
+done:
mutex_unlock(fh-cap.vb_lock);
- return POLLERR;
+ return rc;
}
static int bttv_open(struct file *file)
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 68068c6..f542493 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -796,6 +796,7 @@ static unsigned int video_poll(struct file *file,
{
struct cx23885_fh *fh = file-private_data;
struct cx23885_buffer *buf;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!res_get(fh-dev, fh, RESOURCE_VBI))
@@ -803,23 +804,29 @@ static unsigned int video_poll(struct file *file,
return videobuf_poll_stream(file, fh-vbiq, wait);
}
+ mutex_lock(fh-vidq.vb_lock);
if (res_check(fh, RESOURCE_VIDEO)) {
/* streaming capture */
if (list_empty(fh-vidq.stream))
- return POLLERR;
+ goto done;
buf = list_entry(fh-vidq.stream.next,
struct cx23885_buffer, vb.stream);
} else {
/* read() capture */
buf = (struct cx23885_buffer *)fh-vidq.read_buf;
if (NULL == buf)
- return POLLERR;
+ goto done;
}
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
+ rc = POLLIN|POLLRDNORM;
+ else
+ rc = 0;
+
+done:
+ mutex_unlock(fh-vidq.vb_lock);
+ return rc;
}
static int video_release(struct file *file)
diff --git
Re: [PULL] generic image bounds setting and alignment function
On Sat, 30 May 2009, Trent Piepho wrote:
Mauro,
Please pull from http://linuxtv.org/hg/~tap/v4l-dvb
This series adds a function for bounding and alignment image sizes and
modifies a number of drivers to use it. It came up when the pxa patches to
deal with the alignment issues for that driver were posted. I haven't
tested these patches for pxa.
for the following 14 changesets:
01/14: compat: handle __fls
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273
02/14: v4l2: Create helper function for bounding and aligning images
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d
I am sorry, I will not bother with saving, reformatting, pasting... Just
wanted to ask about this place:
+ if (walign + halign salign) {
+ /* Max walign where there is still a valid width */
+ unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
I cannot follow correctness of the above, sorry. Take a simple example:
wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
comment says it's the maximum walign where there is still a valid width.
What am I missing?
+
+ /* up the smaller alignment until we have enough */
+ do {
+ if (walign = halign walign wmaxa) {
03/14: pxa-camera: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=cb48209c1841
And this one uses the salign functionality of v4l_bound_align_image(),
so...
04/14: sh_mobile_ceu_camera: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=08dc3db16e9a
05/14: zoran: Use v4l bounding/alignment functiob
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=d65d274ca9da
06/14: vivi: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=67a3342606c2
07/14: saa7134: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8e79122888da
08/14: cx88: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=7dc2db9c0b34
09/14: w8968cf: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=1733bbc12c3a
10/14: cx23885: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=605ec680bd75
11/14: mt9: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=d92d47e0d76f
12/14: cx231xx: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3da0c824a487
13/14: em28xx: Use v4l bounding/alignment function
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=42b042c376ec
14/14: cx231xx: TRY_FMT should not actually set anything
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=81ca6b823ec4
Thanks for making this easy
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP patches for linux-media
Em Tue, 16 Jun 2009 10:40:18 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Hi Mauro, [snip] I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. [MK] I along with Chaithrika are working with Hans Verkuil to get the DaVinci video drivers added to open source. I believe VPIF display driver for DM6467 is ready for merge. The VPFE capture driver for DM355 and DM6446 is almost ready. I will be creating the version 3 (hopefully final) version of the patch and review the same in the list. Do you think these patches can be merged to 2.6.31? This will be of great help to us if this can be done since we have other works lined up based on these and our customers are waiting for this for a very long time. Maybe there are still time for 2.6.31. Just please let me know what patches are the final version (or, even better), add it on some -hg tree and ask me to pull from it. If needed, I may create an account for a few TI/Nokia maintainers at linuxtv. I'll then review the patch series and apply if ok (or ask for changes if needed). [snip] One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big [MK] With that in mind, we began our porting work with minimum set of features and stripped off many of the features so that we can add them incrementally. Seems ok to me. I saw also some radio receiver drivers from TI at the ML. I'm not sure what of those are meant for merging. For now, I marked all patches I saw at patchwork that seemed to be related to OMAP/Da Vinci as RFC at patchwork.kernel.org. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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 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 v3]poll method lose race condition
bttv-driver.c,cx23885-video.c,cx88-video.c: poll method lose race condition
for capture video.
In v2, use the clear logic.Thanks to Trent Piepho's help.
In v3, fix a hold mutex locked issue.
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/bt8xx/bttv-driver.c | 11 +++
drivers/media/video/cx23885/cx23885-video.c | 14 ++
drivers/media/video/cx88/cx88-video.c | 14 ++
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 23b7499..3688b6e 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -3152,6 +3152,7 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
struct bttv_fh *fh = file-private_data;
struct bttv_buffer *buf;
enum v4l2_field field;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!check_alloc_btres(fh-btv,fh,RESOURCE_VBI))
@@ -3160,9 +3161,10 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
}
if (check_btres(fh,RESOURCE_VIDEO_STREAM)) {
+ mutex_lock(fh-cap.vb_lock);
/* streaming capture */
if (list_empty(fh-cap.stream))
- return POLLERR;
+ goto err;
buf = list_entry(fh-cap.stream.next,struct
bttv_buffer,vb.stream);
} else {
/* read() capture */
@@ -3191,11 +3193,12 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
+ rc = POLLIN|POLLRDNORM;
+ else
+ rc = 0;
err:
mutex_unlock(fh-cap.vb_lock);
- return POLLERR;
+ return rc;
}
static int bttv_open(struct file *file)
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 68068c6..66bbd2e 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -796,6 +796,7 @@ static unsigned int video_poll(struct file *file,
{
struct cx23885_fh *fh = file-private_data;
struct cx23885_buffer *buf;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!res_get(fh-dev, fh, RESOURCE_VBI))
@@ -803,23 +804,28 @@ static unsigned int video_poll(struct file *file,
return videobuf_poll_stream(file, fh-vbiq, wait);
}
+ mutex_lock(fh-vidq.vb_lock);
if (res_check(fh, RESOURCE_VIDEO)) {
/* streaming capture */
if (list_empty(fh-vidq.stream))
- return POLLERR;
+ goto done;
buf = list_entry(fh-vidq.stream.next,
struct cx23885_buffer, vb.stream);
} else {
/* read() capture */
buf = (struct cx23885_buffer *)fh-vidq.read_buf;
if (NULL == buf)
- return POLLERR;
+ goto done;
}
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
+ rc = POLLIN|POLLRDNORM;
+ else
+ rc = 0;
+done:
+ mutex_unlock(fh-vidq.vb_lock);
+ return rc;
}
static int video_release(struct file *file)
diff --git a/drivers/media/video/cx88/cx88-video.c
b/drivers/media/video/cx88/cx88-video.c
index b993d42..97545a0 100644
--- a/drivers/media/video/cx88/cx88-video.c
+++ b/drivers/media/video/cx88/cx88-video.c
@@ -869,6 +869,7 @@ video_poll(struct file *file, struct poll_table_struct
*wait)
{
struct cx8800_fh *fh = file-private_data;
struct cx88_buffer *buf;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!res_get(fh-dev,fh,RESOURCE_VBI))
@@ -876,22 +877,27 @@ video_poll(struct file *file, struct poll_table_struct
*wait)
return videobuf_poll_stream(file, fh-vbiq, wait);
}
+ mutex_lock(fh-vidq.vb_lock);
if (res_check(fh,RESOURCE_VIDEO)) {
/* streaming capture */
if (list_empty(fh-vidq.stream))
- return POLLERR;
+ goto done;
buf = list_entry(fh-vidq.stream.next,struct
cx88_buffer,vb.stream);
} else {
/* read() capture */
buf = (struct cx88_buffer*)fh-vidq.read_buf;
if (NULL == buf)
- return POLLERR;
+ goto done;
}
Re: [PATCH] videobuf-dma-sg.c : not need memset()
Fingo, Em Wed, 03 Jun 2009 10:13:44 +0800 Figo.zhang figo1...@gmail.com escreveu: mem have malloc zero memory by kzalloc(), so it have not need to memset(). Signed-off-by: Figo.zhang figo1...@gmail.com --- drivers/media/video/videobuf-dma-sg.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c index da1790e..add2f34 100644 --- a/drivers/media/video/videobuf-dma-sg.c +++ b/drivers/media/video/videobuf-dma-sg.c @@ -420,7 +420,7 @@ static void *__videobuf_alloc(size_t size) mem = vb-priv = ((char *)vb)+size; mem-magic=MAGIC_SG_MEM; - videobuf_dma_init(mem-dma); + mem-dma.magic = MAGIC_DMABUF; Technically, this patch is correct. However, I'm afraid that a future change at videobuf_dma_init could cause a breakage. IMO, if we do such change, the better would be to split videobuf_dma_init into two functions or to add a comment at the code warning that this should match the init done at videobuf_dma_init. dprintk(1,%s: allocated at %p(%ld+%ld) %p(%ld)\n, __func__,vb,(long)sizeof(*vb),(long)size-sizeof(*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 -- 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Em Mon, 15 Jun 2009 14:56:39 +0200 (CEST) Patrick Boettcher patrick.boettc...@desy.de escreveu: Hi Mauro, On Mon, 15 Jun 2009, Mauro Carvalho Chehab wrote: Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT) Trent Piepho xy...@speakeasy.org escreveu: On Thu, 11 Jun 2009, Patrick Boettcher wrote: On Wed, 27 May 2009, Trent Piepho wrote: On Tue, 26 May 2009, Patrick Boettcher wrote: Does this patch to fix these problems look ok? In fact, everything looks correct in my eyes. I'll ask Mauro to pull any minute from now. I even have an explaination why the failing attach of the itd1000 was not errored out: when I did the development I was using a userspace proprietary driver to validate, for that I needed the demod to be attached... Thanks for cleaning up this mess. Now that that patch is done, here is the rest of the series with dvb-pll conversions. There is an additional patch to the flexcop card detecting code. The #if defined(CONFIG_...) stuff didn't take into account code being compiled into the kernel. Here's the series: 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90 05/08: b2c2: fix frontends compiled into kernel http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6 08/08: b2c2: Use dvb-pll for Cablestar2 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0 Nice patches. Are those tested with real cards? In particular, I loved this: +/* Can we use the specified front-end? Remember that if we are compiled + * into the kernel we can't call code that's in modules. */ +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) defined(MODULE))) IMO, you should add it on a dvb core header. Then, a cleanup patch would be to simplify all those frontend tests all over all the dvb drivers code. Patrick, I think you have some skystar boards. I'd appreciate if you can review those patches before applying it. The only card I use which is using DVB_PLL (now) is the Airstar DVB-T. So we need to take some risks and apply to force users to test :). I will ask some users I know. However I won't be able to commit nor test anything before 3.5 weeks from now. Hmm... this will be outside the merge window... I think I'll merge it on our tree after sending the first pull request for 2.6.30 (probably later today), in order to cook it for a while at the main tree before merging it. It would be nice if you can ask those users to test it asap, in order to get it tested during this week. Otherwise, we'll need to postpone this to 2.6.31. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ 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] USB interrupt support for radio-si470x FM radio driver
Hello, Edouard
(add Tobias and Douglas on c/c)
On Tue, Jun 16, 2009 at 5:11 PM, Edouard Lafargueedou...@lafargue.name wrote:
Please find below my attempt at removing 'manual' polling from the
radio-si470x USB FM radio driver, by moving to URB interrupt callback
handlers.
This code significantly improves RDS reception - radiotext in
particular - and improves audio quality on my Silabs FM USB dongle, as
lots of pops and clicks have now disappeared. Your mileage may vary.
Issues remain when userspace programs do V4L ioctl calls to the
dongle: this creates clicks in the audio.
I am by no means a professional driver writer and the code below is
most probably in need of a proper review by someone more experienced
than me in writing Linux USB drivers. It does not raise issues on the
machines where I have tested it, but this is hardly proof it's good.
Any help will be much appreciated. It is only tested on the dongle I
own, a Silabs Reference Design FM receiver dongle.
Last: there are a few bits left commented out in my patched version,
those are kept to help code review if someone wants to help, they
should probably be removed from a final release.
Thanks for your feedback!
Signed-off-by: Edouard Lafargue edou...@lafargue.name
diff -Nur ../radio-si470x.c radio-si470x.c
--- ../radio-si470x.c 2008-12-25 00:26:37.0 +0100
+++ radio-si470x.c 2009-06-16 14:20:07.0 +0200
@@ -97,9 +97,14 @@
* - add support for KWorld USB FM Radio FM700
* - blacklisted KWorld radio in hid-core.c and hid-ids.h
*
+ * 2009-06-16 Edouard Lafargue edou...@lafargue.name
+ * Version 1.0.9
+ * - add support for interrupt mode for RDS endpoint, instead of
polling.
+ *
* ToDo:
* - add firmware download/update support
- * - RDS support: interrupt mode, instead of polling
+ * - RDS support: debug interrupt mode and use of URBs further!
+ * - Use URBs for all USB communications
Well, i'm not usb expert, but if such wrappers over URB like
usb_control_msg works fine, why to throw them away? I don't know but
may be there is big reason for that.
* - add LED status output (check if that's not already done in firmware)
*/
@@ -107,10 +112,10 @@
/* driver definitions */
#define DRIVER_AUTHOR Tobias Lorenz tobias.lor...@gmx.net
#define DRIVER_NAME radio-si470x
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 8)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9)
#define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver
#define DRIVER_DESC USB radio driver for Si470x FM Radio Receivers
-#define DRIVER_VERSION 1.0.8
+#define DRIVER_VERSION 1.0.9
/* kernel includes */
@@ -207,13 +212,14 @@
MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*);
/* RDS poll frequency */
-static unsigned int rds_poll_time = 40;
+/* TODO: remove this since not used anymore as we now use the interrupt URB
*/
+/* static unsigned int rds_poll_time = 40; */
/* 40 is used by the original USBRadio.exe */
/* 50 is used by radio-cadet */
/* 75 should be okay */
/* 80 is the usual RDS receive interval */
-module_param(rds_poll_time, uint, 0644);
-MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*);
+/* module_param(rds_poll_time, uint, 0644); */
+/* MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*); */
@@ -440,6 +446,12 @@
struct usb_interface *intf;
struct video_device *videodev;
+ /* Interrupt endpoint handling */
+ char *int_in_buffer;
+ struct usb_endpoint_descriptor *int_in_endpoint;
+ struct urb *int_in_urb;
+ int int_in_running;
+
/* driver management */
unsigned int users;
unsigned char disconnected;
@@ -578,37 +590,6 @@
}
-/*
- * si470x_get_rds_registers - read rds registers
- */
-static int si470x_get_rds_registers(struct si470x_device *radio)
-{
- unsigned char buf[RDS_REPORT_SIZE];
- int retval;
- int size;
- unsigned char regnr;
-
- buf[0] = RDS_REPORT;
-
- retval = usb_interrupt_msg(radio-usbdev,
- usb_rcvintpipe(radio-usbdev, 1),
- (void *) buf, sizeof(buf), size, usb_timeout);
- if (size != sizeof(buf))
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- return size differs: %d != %zu\n, size,
sizeof(buf));
- if (retval 0)
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- usb_interrupt_msg returned %d\n, retval);
-
- if (retval = 0)
- for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++)
- radio-registers[STATUSRSSI + regnr] =
- get_unaligned_be16(
- buf[regnr * RADIO_REGISTER_SIZE + 1]);
-
- return (retval 0) ?
Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
Darius Augulis wrote: On 06/16/2009 05:45 PM, Jonathan Cameron wrote: Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Could you please, describe in more detail how you merged them? Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything. Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision. However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there, That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier). It's very difficult to write 'normal' driver for it. Omnivision does not provide useful documentation, only long constant arrays with few strange comments. Beside documentation is poor, there are lot of errors in register description. Many things are mistery, not documented and seems Omnivision does not have such documentation. I thing this sensor isn't perfect for embedded projects. It's 'designed' for webcams, where reliability and quality are not needed. With ov7720 similar situation... Agreed. Though random discussions with others suggest lots of these chips turn up in things like pedestrian avoidance systems in cars and similar. (not generally running linux and tend to have fairly fixed settings I guess). Jonathan -- 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: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Tue, 16 Jun 2009, Eduardo Valentin wrote: On Sun, Jun 14, 2009 at 06:59:13PM +0200, ext Hans Verkuil wrote: On Sunday 14 June 2009 18:23:41 Trent Piepho wrote: similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in the future, so I think this name should be more specific to the FM_TX API. The cx88 driver could get support for setting the fm preemphasis via a control. I added support via a module option, but a control would be better. You're saying it shouldn't use this fm preemphasis control? Correct. This set the pre-emphasis when transmitting. For receiving you want a separate control. Although the enum should be made generic. So FM_TX can be removed from the enum. Why should we have one rx and one tx control for this? Because you can have both receivers and transmitters in one device and you want independent control of the two. Yes, agreed here. There is the possibility to have receiver and transmitter both in the same device. So, I think it is better to have separated controls. Is both a receiver and transmitter in the same device different than having two receivers or two transmitters? In which case, since controls are not assigned to a specific input, how does one handle that? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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 Jun 16 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11994:770e035ab1bd 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-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-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS 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-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-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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-x86_64: WARNINGS sparse (linux-2.6.30): 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK 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: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 failed to build, but the last compiled spec 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] zl10353 and qt1010: fix stack corruption bug
Em Wed, 10 Jun 2009 08:21:20 +0200
Jan Nikitenko jan.nikite...@gmail.com escreveu:
This patch fixes stack corruption bug present in dump_regs function of
zl10353
and qt1010 drivers:
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack corruption
possibly leading to kernel oops, as discovered originally with af9015 driver.
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
Antti Palosaari wrote:
On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
Solved with [PATCH] af9015: fix stack corruption bug.
This error leads to the zl10353.c and there it was copied to qt1010.c
and af9015.c.
Antti, thanks for pointing out that the same problem was also in zl10353.c
and
qt1010.c. Include your Sign-off-by, please.
Best regards,
Jan
linux/drivers/media/common/tuners/qt1010.c |2 +-
linux/drivers/media/dvb/frontends/zl10353.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -r cff06234b725 linux/drivers/media/common/tuners/qt1010.c
--- a/linux/drivers/media/common/tuners/qt1010.c Sun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/common/tuners/qt1010.c Wed Jun 10 07:37:51
2009 +0200
@@ -65,7 +65,7 @@
/* dump all registers */
static void qt1010_dump_regs(struct qt1010_priv *priv)
{
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
CodingStyle is incorrect. It should be buf[4 + 3 * 16 + 1].
u8 reg, val;
for (reg = 0; ; reg++) {
diff -r cff06234b725 linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c Sun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/dvb/frontends/zl10353.c Wed Jun 10 07:37:51
2009 +0200
@@ -102,7 +102,7 @@
static void zl10353_dump_regs(struct dvb_frontend *fe)
{
struct zl10353_state *state = fe-demodulator_priv;
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
Same CodingStyle issue here.
int ret;
u8 reg;
Without having actually looking at the source code, would it be possible to
change the logic in order to use something else instead of a magic number for
buf size - e. g. using sizeof(something) ?
--
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
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 3/4] lgs8gxx: add lgs8g75 support
Em Thu, 11 Jun 2009 20:39:12 +0800
David Wong davidtlw...@gmail.com escreveu:
@@ -238,21 +384,26 @@
u8 *finished)
{
int ret = 0;
- u8 t;
+ u8 reg, mask, val;
- ret = lgs8gxx_read_reg(priv, 0xA4, t);
- if (ret != 0)
- return ret;
+ if (priv-config-prod == LGS8GXX_PROD_LGS8G75) {
+ reg = 0x1f; mask = 0xC0; val = 0x80;
+ } else {
+ reg = 0xA4; mask = 0x03; val = 0x01;
+ }
Please, one statement per line.
+ if (priv-config-prod == LGS8GXX_PROD_LGS8G75) {
+ reg_total = 0x28; reg_err = 0x2C;
+ } else {
+ reg_total = 0xD0; reg_err = 0xD4;
+ }
Please, one statement per line.
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] cx23885: add card Magic-Pro ProHDTV Extreme 2
Em Thu, 11 Jun 2009 20:39:18 +0800 David Wong davidtlw...@gmail.com escreveu: cx23885: add card Magic-Pro ProHDTV Extreme 2 PCI-E. Signed-off-by: David T.L. Wong davidtlwong at gmail.com Since changes were requested on the previous patch, it makes no sense to apply this one. Please, re-submit this one after fixing the pointed issues on the previous one. 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: USERPTR buffer exchange mechanism
Hi, Any suggestion here? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan Sent: Friday, June 12, 2009 10:57 AM To: linux-media@vger.kernel.org Subject: USERPTR buffer exchange mechanism Hi, I would like to explore what level of support is available in the v4l buffer exchange mechanism for USERPTR buffer exchange. In our internal release, we had a hack to support this feature. We use contiguous buffers in our user ptr hack implementation. The buffers are allocated in a kernel module that export api to pass the physical address of the allocated buffer to the user application. In the v4l2 driver, USERPTR IO mechanism will be requested, and in QBUF, the ptr passed to the driver is the above physical address. One thing we observed was that even in this case, we had to use index in the buffer structure without which it doesn't work. Anyone has any insight into how to port this capability to the open source kernel v4l2 driver? In other words, can I use userptr IO mechanism and pass contigous buffer address like above? If so, Is there a driver example I can refer to port this to my vpfe capture driver? Thanks in advance. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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 -- 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 / resubmit] USB interrupt support for radio-si470x FM radio driver
Hello Alexey,
Many thanks for your comments. I have cleaned up my code/patch along
your guidelines, removed all the remaining code that was not used
anymore, checked that all buffers get deallocated properly - I hope.
Review by Tobias is certainly necessary, he know his own driver best,
I might have broken things without knowing... Anyway it works fine on
the two 32 and 64bit machines where I have tested the dongle, both on
kernel 2.6.28.
The main and very big improvement is the performance of RDS bitstream
reception, now Radiotext appears almost right away even on the most
difficult stations I can receive here in Paris, just like it should.
Performance is similar to 'real' radios, if you see what I mean. Audio
remains perfectly clear.
When it comes to audio, it seems to me the si470x_get_report call
generates some serious clicking in the audio on my Silabs dongle. I
will investigate further, I wonder if other USB FM tokens have the
same issue. I fixed this problem on rdsd by adding a configuration
file option to prevent it constantly polling the dongle for its
current frequency...
Comments are welcome!
Best regards,
Signed-off-by: Edouard Lafargue edou...@lafargue.name
diff -Nur ../radio-si470x.c radio-si470x.c
--- ../radio-si470x.c 2008-12-25 00:26:37.0 +0100
+++ radio-si470x.c 2009-06-16 21:47:58.0 +0200
@@ -97,9 +97,13 @@
* - add support for KWorld USB FM Radio FM700
* - blacklisted KWorld radio in hid-core.c and hid-ids.h
*
+ * 2009-06-16 Edouard Lafargue edou...@lafargue.name
+ * Version 1.0.9
+ * - add support for interrupt mode for RDS endpoint, instead of
polling.
+ *Improves RDS reception significantly
+ *
* ToDo:
* - add firmware download/update support
- * - RDS support: interrupt mode, instead of polling
* - add LED status output (check if that's not already done in firmware)
*/
@@ -107,10 +111,10 @@
/* driver definitions */
#define DRIVER_AUTHOR Tobias Lorenz tobias.lor...@gmx.net
#define DRIVER_NAME radio-si470x
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 8)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9)
#define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver
#define DRIVER_DESC USB radio driver for Si470x FM Radio Receivers
-#define DRIVER_VERSION 1.0.8
+#define DRIVER_VERSION 1.0.9
/* kernel includes */
@@ -206,16 +210,6 @@
module_param(max_rds_errors, ushort, 0644);
MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*);
-/* RDS poll frequency */
-static unsigned int rds_poll_time = 40;
-/* 40 is used by the original USBRadio.exe */
-/* 50 is used by radio-cadet */
-/* 75 should be okay */
-/* 80 is the usual RDS receive interval */
-module_param(rds_poll_time, uint, 0644);
-MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*);
-
-
/**
* Register Definitions
@@ -440,6 +434,12 @@
struct usb_interface *intf;
struct video_device *videodev;
+ /* Interrupt endpoint handling */
+ char *int_in_buffer;
+ struct usb_endpoint_descriptor *int_in_endpoint;
+ struct urb *int_in_urb;
+ int int_in_running;
+
/* driver management */
unsigned int users;
unsigned char disconnected;
@@ -449,7 +449,6 @@
unsigned short registers[RADIO_REGISTER_NUM];
/* RDS receive buffer */
- struct delayed_work work;
wait_queue_head_t read_queue;
struct mutex lock; /* buffer locking */
unsigned char *buffer; /* size is always multiple of three */
@@ -578,37 +577,6 @@
}
-/*
- * si470x_get_rds_registers - read rds registers
- */
-static int si470x_get_rds_registers(struct si470x_device *radio)
-{
- unsigned char buf[RDS_REPORT_SIZE];
- int retval;
- int size;
- unsigned char regnr;
-
- buf[0] = RDS_REPORT;
-
- retval = usb_interrupt_msg(radio-usbdev,
- usb_rcvintpipe(radio-usbdev, 1),
- (void *) buf, sizeof(buf), size, usb_timeout);
- if (size != sizeof(buf))
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- return size differs: %d != %zu\n, size, sizeof(buf));
- if (retval 0)
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- usb_interrupt_msg returned %d\n, retval);
-
- if (retval = 0)
- for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++)
- radio-registers[STATUSRSSI + regnr] =
- get_unaligned_be16(
- buf[regnr * RADIO_REGISTER_SIZE + 1]);
-
- return (retval 0) ? -EINVAL : 0;
-}
-
/*
* si470x_set_chan - set the channel
@@ -882,105 +850,117 @@
**/
/*
- * si470x_rds - rds processing function
+
Re: [PULL] http://kernellabs.com/hg/~mkrufky/k2c2
Michael Krufky wrote:
Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky mkru...@linuxtv.org escreveu:
Mauro,
Please pull from:
http://kernellabs.com/hg/~mkrufky/k2c2
for:
- cx23885: override set_frontend to allow rf input path switching on
the HVR1275
cx23885-dvb.c | 29 +
cx23885.h |2 ++
2 files changed, 31 insertions(+)
Hopefully, you can get this into the next merge window with all the
other pending changesets ;-)
Thanks regards,
Mike
Use separate RF input spigots for Antennae and Cable.
Priority: normal
Reviewed-by: Steven Toth st...@kernellabs.com
Signed-off-by: Michael Krufky mkru...@kernellabs.com
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.cTue May 12
17:53:47 2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.cFri May 08
21:39:24 2009 -0400
@@ -417,6 +417,30 @@
.demod_address = 0x05,
};
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
+struct dvb_frontend_parameters *param)
+{
+struct cx23885_tsport *port = fe-dvb-priv;
+struct cx23885_dev *dev = port-dev;
+
+switch (dev-board) {
+case CX23885_BOARD_HAUPPAUGE_HVR1275:
+switch (param-u.vsb.modulation) {
+case VSB_8:
+cx23885_gpio_clear(dev, GPIO_5);
+break;
+case QAM_64:
+case QAM_256:
+default:
+cx23885_gpio_set(dev, GPIO_5);
+break;
+}
+break;
+}
+return (port-set_frontend_save) ?
+port-set_frontend_save(fe, param) : -ENODEV;
+}
+
static int dvb_register(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port-dev;
@@ -456,6 +480,11 @@
0x60, dev-i2c_bus[1].i2c_adap,
hauppauge_hvr127x_config);
}
+
+/* define bridge override to set_frontend */
+port-set_frontend_save = fe0-dvb.frontend-ops.set_frontend;
+fe0-dvb.frontend-ops.set_frontend =
cx23885_dvb_set_frontend;
+
break;
case CX23885_BOARD_HAUPPAUGE_HVR1255:
i2c_bus = dev-i2c_bus[0];
--- a/linux/drivers/media/video/cx23885/cx23885.hTue May 12
17:53:47 2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885.hFri May 08
21:39:24 2009 -0400
@@ -288,6 +288,8 @@
/* Allow a single tsport to have multiple frontends */
u32num_frontends;
void *port_priv;
+int (*set_frontend_save) (struct dvb_frontend *,
+ struct dvb_frontend_parameters *);
};
struct cx23885_dev {
Argh! this looks like a hack! Don't you have a better approach for it?
I have a better approach that I plan to push for the next kernel.
This is planned for 2.6.31, for 2.6.32 I have a better method that
will be genericly used for all drivers.
I plan to post an RFC about the new method after the merge window closes.
Can you merge this for now, and the new, better method can be saved
for the next devel cycle?
I'd just like to add a point:
The method used in this patch is the same method currently used inside
the dib0700 driver (grep for set_param_save in struct dib0700_adapter_state)
This is the minimal patch for the current merge window -- I'd like to
merge this one for now, and when the merge window closes, I will issue
the RFC for the new, better method, while converting dib0700 and cx23885
both to use this new better method.
Once that is done, this sort of thing will be much clearer and easier to
accomplish across other drivers in the susbsystem tree.
I have added a FIXME comment as per your request...
Please pull from:
http://kernellabs.com/hg/~mkrufky/k2c2
for the following:
- cx23885: override set_frontend to allow rf input path switching on the
HVR1275
- cx23885: add FIXME comment above set_frontend override
cx23885-dvb.c | 30 ++
cx23885.h |4
2 files changed, 34 insertions(+)
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://kernellabs.com/hg/~mkrufky/k2c2
Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky mkru...@linuxtv.org escreveu:
Mauro,
Please pull from:
http://kernellabs.com/hg/~mkrufky/k2c2
for:
- cx23885: override set_frontend to allow rf input path switching on the HVR1275
cx23885-dvb.c | 29 +
cx23885.h |2 ++
2 files changed, 31 insertions(+)
Hopefully, you can get this into the next merge window with all the
other pending changesets ;-)
Thanks regards,
Mike
Use separate RF input spigots for Antennae and Cable.
Priority: normal
Reviewed-by: Steven Toth st...@kernellabs.com
Signed-off-by: Michael Krufky mkru...@kernellabs.com
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c Tue May 12 17:53:47
2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c Fri May 08 21:39:24
2009 -0400
@@ -417,6 +417,30 @@
.demod_address = 0x05,
};
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *param)
+{
+ struct cx23885_tsport *port = fe-dvb-priv;
+ struct cx23885_dev *dev = port-dev;
+
+ switch (dev-board) {
+ case CX23885_BOARD_HAUPPAUGE_HVR1275:
+ switch (param-u.vsb.modulation) {
+ case VSB_8:
+ cx23885_gpio_clear(dev, GPIO_5);
+ break;
+ case QAM_64:
+ case QAM_256:
+ default:
+ cx23885_gpio_set(dev, GPIO_5);
+ break;
+ }
+ break;
+ }
+ return (port-set_frontend_save) ?
+ port-set_frontend_save(fe, param) : -ENODEV;
+}
+
static int dvb_register(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port-dev;
@@ -456,6 +480,11 @@
0x60, dev-i2c_bus[1].i2c_adap,
hauppauge_hvr127x_config);
}
+
+ /* define bridge override to set_frontend */
+ port-set_frontend_save = fe0-dvb.frontend-ops.set_frontend;
+ fe0-dvb.frontend-ops.set_frontend = cx23885_dvb_set_frontend;
+
break;
case CX23885_BOARD_HAUPPAUGE_HVR1255:
i2c_bus = dev-i2c_bus[0];
--- a/linux/drivers/media/video/cx23885/cx23885.h Tue May 12 17:53:47
2009 -0400
+++ b/linux/drivers/media/video/cx23885/cx23885.h Fri May 08 21:39:24
2009 -0400
@@ -288,6 +288,8 @@
/* Allow a single tsport to have multiple frontends */
u32num_frontends;
void *port_priv;
+ int (*set_frontend_save) (struct dvb_frontend *,
+ struct dvb_frontend_parameters *);
};
struct cx23885_dev {
Argh! this looks like a hack! Don't you have a better approach for it?
I have a better approach that I plan to push for the next kernel. This
is planned for 2.6.31, for 2.6.32 I have a better method that will be
genericly used for all drivers.
I plan to post an RFC about the new method after the merge window closes.
Can you merge this for now, and the new, better method can be saved for
the next devel cycle?
Thanks Regards,
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: [PATCH / resubmit] USB interrupt support for radio-si470x FM radio driver
On Wed, Jun 17, 2009 at 12:05 AM, Edouard Lafargueedou...@lafargue.name wrote: Hello Alexey, Hello Edouard Many thanks for your comments. I have cleaned up my code/patch along your guidelines, removed all the remaining code that was not used anymore, checked that all buffers get deallocated properly - I hope. It looks better, thanks. Review by Tobias is certainly necessary, he know his own driver best, I might have broken things without knowing... Anyway it works fine on the two 32 and 64bit machines where I have tested the dongle, both on kernel 2.6.28. Review and testing are definitely necessary, of course. Let's wait his comments. The main and very big improvement is the performance of RDS bitstream reception, now Radiotext appears almost right away even on the most difficult stations I can receive here in Paris, just like it should. Performance is similar to 'real' radios, if you see what I mean. Audio remains perfectly clear. Good to know that. I noticed one more possible thing, please see comment below. When it comes to audio, it seems to me the si470x_get_report call generates some serious clicking in the audio on my Silabs dongle. I will investigate further, I wonder if other USB FM tokens have the same issue. I fixed this problem on rdsd by adding a configuration file option to prevent it constantly polling the dongle for its current frequency... Comments are welcome! Best regards, Signed-off-by: Edouard Lafargue edou...@lafargue.name diff -Nur ../radio-si470x.c radio-si470x.c --- ../radio-si470x.c 2008-12-25 00:26:37.0 +0100 +++ radio-si470x.c 2009-06-16 21:47:58.0 +0200 @@ -97,9 +97,13 @@ * - add support for KWorld USB FM Radio FM700 * - blacklisted KWorld radio in hid-core.c and hid-ids.h * + * 2009-06-16 Edouard Lafargue edou...@lafargue.name + * Version 1.0.9 + * - add support for interrupt mode for RDS endpoint, instead of polling. + * Improves RDS reception significantly Hmmm. Did you make this patch against 2.6.28 kernel sources? Current version of driver is 1.0.9 already :) http://linuxtv.org/hg/v4l-dvb/file/45f342431f6e/linux/drivers/media/radio/ So, your change will make 1.1.0, right? Usually developers applied patches to the latest version of code. If you want to work/make patch with the latest version of v4l-dvb tree you can use v4l-dvb mercurial tree. Link that can help: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Actually, steps in general: 1) install mercurial 2) clone current v4l-dvb tree: hg clone http://linuxtv.org/hg/v4l-dvb 3) Add your changes in radio-si470x driver. 4) Command hg diff will show changes. You can save this changes and sent it to maillist. 5) Don't forget to run make checkpatch and make whitespaces. It will check CodingStyle of your changes. 6) You can use commands like: make menuconfig, make, make install to select, compile and install v4l modules. This way you can update your patch and test it with latest si470x driver. Other way - you can wait Tobias comments and don't play with v4l-dvb tree. + * * ToDo: * - add firmware download/update support - * - RDS support: interrupt mode, instead of polling * - add LED status output (check if that's not already done in firmware) */ @@ -107,10 +111,10 @@ /* driver definitions */ #define DRIVER_AUTHOR Tobias Lorenz tobias.lor...@gmx.net #define DRIVER_NAME radio-si470x -#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 8) +#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9) #define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver #define DRIVER_DESC USB radio driver for Si470x FM Radio Receivers -#define DRIVER_VERSION 1.0.8 +#define DRIVER_VERSION 1.0.9 /* kernel includes */ @@ -206,16 +210,6 @@ module_param(max_rds_errors, ushort, 0644); MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*); -/* RDS poll frequency */ -static unsigned int rds_poll_time = 40; -/* 40 is used by the original USBRadio.exe */ -/* 50 is used by radio-cadet */ -/* 75 should be okay */ -/* 80 is the usual RDS receive interval */ -module_param(rds_poll_time, uint, 0644); -MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*); - - /** * Register Definitions @@ -440,6 +434,12 @@ struct usb_interface *intf; struct video_device *videodev; + /* Interrupt endpoint handling */ + char *int_in_buffer; + struct usb_endpoint_descriptor *int_in_endpoint; + struct urb *int_in_urb; + int int_in_running; + /* driver management */ unsigned int users; unsigned char disconnected; @@ -449,7 +449,6 @@ unsigned short registers[RADIO_REGISTER_NUM]; /* RDS receive buffer */ - struct delayed_work work; wait_queue_head_t read_queue;
Re: [PULL] generic image bounds setting and alignment function
Em Tue, 16 Jun 2009 17:57:20 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
On Sat, 30 May 2009, Trent Piepho wrote:
Mauro,
Please pull from http://linuxtv.org/hg/~tap/v4l-dvb
This series adds a function for bounding and alignment image sizes and
modifies a number of drivers to use it. It came up when the pxa patches to
deal with the alignment issues for that driver were posted. I haven't
tested these patches for pxa.
for the following 14 changesets:
01/14: compat: handle __fls
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273
02/14: v4l2: Create helper function for bounding and aligning images
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d
I am sorry, I will not bother with saving, reformatting, pasting... Just
wanted to ask about this place:
+ if (walign + halign salign) {
+ /* Max walign where there is still a valid width */
+ unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
I cannot follow correctness of the above, sorry. Take a simple example:
wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
comment says it's the maximum walign where there is still a valid width.
What am I missing?
+
+ /* up the smaller alignment until we have enough */
+ do {
+ if (walign = halign walign wmaxa) {
As I'm still cooking the patches, I prefer to postpone the align ones until we
are comfortable with them.
Trent,
Could you please take a look on the above comments
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: [PULL] http://kernellabs.com/hg/~mkrufky/k2c2
On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky mkru...@linuxtv.org escreveu:
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *param)
You could make this an HVR1275 specific function and then do away with the
first case statement. With a name like cx23885_dvb_set_frontend() it
appears that all boards will use it, when it is only ever called with an
HVR1275.
+ switch (param-u.vsb.modulation) {
+ case VSB_8:
+ cx23885_gpio_clear(dev, GPIO_5);
+ break;
+ case QAM_64:
+ case QAM_256:
+ default:
+ cx23885_gpio_set(dev, GPIO_5);
+ break;
Using the modulation to switch inputs is of course a hack, needed because
the dvb api lacks a concept of multiple inputs. I do not know if any still
exist, but there were cable systems which broadcast with both QAM and VS.
Argh! this looks like a hack! Don't you have a better approach for it?
--
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://kernellabs.com/hg/~mkrufky/k2c2
On Tue, Jun 16, 2009 at 7:59 PM, Trent Piephoxy...@speakeasy.org wrote:
On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 11:19:29 -0400
Michael Krufky mkru...@linuxtv.org escreveu:
+static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *param)
You could make this an HVR1275 specific function and then do away with the
first case statement. With a name like cx23885_dvb_set_frontend() it
appears that all boards will use it, when it is only ever called with an
HVR1275.
Actually, it *will* be used by other boards. For now it is
HVR1275-specific. The other changes will come after the close of the
merge window.
+ switch (param-u.vsb.modulation) {
+ case VSB_8:
+ cx23885_gpio_clear(dev, GPIO_5);
+ break;
+ case QAM_64:
+ case QAM_256:
+ default:
+ cx23885_gpio_set(dev, GPIO_5);
+ break;
Using the modulation to switch inputs is of course a hack, needed because
the dvb api lacks a concept of multiple inputs. I do not know if any still
exist, but there were cable systems which broadcast with both QAM and VS.
By design on this board, VSB uses one input, QAM uses the other.
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: Leadtek Winfast DTV-1000S
Hi, Am Dienstag, den 16.06.2009, 11:33 -0400 schrieb Michael Krufky: On Sun, Jun 7, 2009 at 6:39 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Montag, den 08.06.2009, 07:59 +1000 schrieb pau...@planar.id.au: That is fantastic news. Not only will it be coming soon, but I don't have to do it myself!! How will we know when the test repository is created - will it be announced on this list? Thanks, Paul Henry Wu did send modified saa7134 files with support for this card on Tuesday off list. Mike replied, that he will set up a test repository as soon he gets some time for doing so. Paul, give Mike some time for it. There are much more variables in question, that can be different on devices now seen in the wild for the first time and a proper framework must be employed. If you can't wait, ask Mike do send you the files, seems they are recent enough for current v4l-dvb, but better is to wait and start with some unified testing base. Cheers, Hermann Hello all, Apologies for the delay -- I've been extremely busy over the past few weeks, but that's nothing new :-P Anyhow, I pushed up some code almost 2 weeks ago that should cover the DTV1000S in all variations. Thanks to Terry Wu for the baseband video gpio setup. I haven't had time to ask anybody to test this yet, so I'd appreciate it if you can provide some general feedback. This change only adds support for the new card, so I am not interested in anybody's experience with other boards -- this ONLY relates to the DTV1000S. Terry's patches copy the device specific setup from the Hauppauge HVR1110 -- this is actually dangerous, as the HVR1110 GPIO / LNA setup could cause problems when used on other boards. Terry's patches also support a version of the board with a TDA18271c2 -- I don't know if such a board actually exists, but the way that Terry did it doesn't allow for supporting both variations in a single kernel. If the c2 version of the board actually exists, the code that I pushed will work on board boards. I'd like to see dmesg output while using my tree -- please include full device initialization, starting with the line, Linux video capture interface: v2.00 up till the end. I am especially interested to see whether or not the TDA8295 driver attaches successfully -- I have a feeling that there actually is no TDA8295 on that board, but I don't know for sure, offhand. Please test the following tree: http://kernellabs.com/hg/~mkrufky/dtv1000s - saa7134: add initial DVB-T support for the Leadtek DTV1000S - saa7134: add support for baseband video capture on Leadtek DTV1000S Documentation/video4linux/CARDLIST.saa7134 |1 drivers/media/video/saa7134/saa7134-cards.c | 22 + drivers/media/video/saa7134/saa7134-dvb.c | 39 ++ drivers/media/video/saa7134/saa7134.h |1 4 files changed, 63 insertions(+) Cheers, Mike Krufky guess Sander with that Zolid hybrid and such hardware with a saa7131e should give it a try for DVB-T too with card=169 on your testing repo. If he still has it ;) 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] generic image bounds setting and alignment function
On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 17:57:20 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
On Sat, 30 May 2009, Trent Piepho wrote:
+ if (walign + halign salign) {
+ /* Max walign where there is still a valid width */
+ unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
I cannot follow correctness of the above, sorry. Take a simple example:
wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
comment says it's the maximum walign where there is still a valid width.
What am I missing?
+
+ /* up the smaller alignment until we have enough */
+ do {
+ if (walign = halign walign wmaxa) {
As I'm still cooking the patches, I prefer to postpone the align ones until we
are comfortable with them.
Trent,
Could you please take a look on the above comments
There is no bug with the wmaxa code, but there is a different bug
elsewhere.
Please pull from http://linuxtv.org/hg/~tap/fix
for the following changeset:
01/01: v4l2: Fix flaw in alignment code
http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=4ef7fb102b6c
--
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] High resolution timer for cx88 remotes
Em Sat, 23 May 2009 14:06:01 +0200
AH andrzej.ha...@wp.pl escreveu:
Hi
Some remotes requires short polling interval which in modern kernels is
below resolution of standard scheduler (schedule_delayed_work), this
causes problem of missed keystrokes. One of the solutions is to raise
kernel timer frequency, my proposition is to use high resolution timers
which are present in kernel since 2.6.16 (at least API AFAIK).
I have encountered this problem on my Winfast 2000XP Expert, but after
checking cx88-input.c it seems that following cards can be affected also:
WINFAST2000XP_EXPERT
WINFAST_DTV1000
WINFAST_TV2000_XP_GLOBAL
PROLINK_PLAYTVPVR
PIXELVIEW_PLAYTV_ULTRA_PRO
PROLINK_PV_8000GT
PROLINK_PV_GLOBAL_XTREME
KWORLD_LTV883
MSI_TVANYWHERE_MASTER
Patched driver seems to work on my system, with kernel 2.6.28.
I have removed kernel checks for versions below 2.6.20 - they were
because of API changes in scheduler.
I have not tested it on older kernels.
Regards
AH
diff -r 315bc4b65b4f linux/drivers/media/video/cx88/cx88-input.c
--- a/linux/drivers/media/video/cx88/cx88-input.c Sun May 17
12:28:55 2009 +
+++ b/linux/drivers/media/video/cx88/cx88-input.c Sat May 23
14:04:17 2009 +0200
@@ -23,10 +23,10 @@
*/
#include linux/init.h
-#include linux/delay.h
#include linux/input.h
#include linux/pci.h
#include linux/module.h
+#include linux/hrtimer.h
#include compat.h
#include cx88.h
@@ -49,7 +49,7 @@
/* poll external decoder */
int polling;
- struct delayed_work work;
+ struct hrtimer timer;
u32 gpio_addr;
u32 last_gpio;
u32 mask_keycode;
@@ -144,31 +144,25 @@
}
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
-static void cx88_ir_work(void *data)
-#else
-static void cx88_ir_work(struct work_struct *work)
-#endif
+enum hrtimer_restart cx88_ir_work(struct hrtimer *timer)
{
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- struct cx88_IR *ir = data;
-#else
- struct cx88_IR *ir = container_of(work, struct cx88_IR, work.work);
-#endif
+ unsigned long missed;
+ struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);
cx88_ir_handle_key(ir);
- schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
+ missed = hrtimer_forward_now(ir-timer, ktime_set(0,
ir-polling * 100));
Hmm... this patch got line wrapped. please fix it and re-send.
+ if (missed 1)
+ ir_dprintk(Missed ticks %ld\n, missed - 1);
+
+ return HRTIMER_RESTART;
}
void cx88_ir_start(struct cx88_core *core, struct cx88_IR *ir)
{
if (ir-polling) {
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- INIT_DELAYED_WORK(ir-work, cx88_ir_work, ir);
-#else
- INIT_DELAYED_WORK(ir-work, cx88_ir_work);
-#endif
- schedule_delayed_work(ir-work, 0);
+ hrtimer_init(ir-timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ ir-timer.function = cx88_ir_work;
+ hrtimer_start(ir-timer, ktime_set(0, ir-polling *
100), HRTIMER_MODE_REL);
}
if (ir-sampling) {
core-pci_irqmask |= PCI_INT_IR_SMPINT;
@@ -185,7 +179,7 @@
}
if (ir-polling)
- cancel_delayed_work_sync(ir-work);
+ hrtimer_cancel(ir-timer);
}
/*
-- */
--
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
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] High resolution timer for cx88 remotes
On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote: Em Sat, 23 May 2009 14:06:01 +0200 AH andrzej.ha...@wp.pl escreveu: Patched driver seems to work on my system, with kernel 2.6.28. I have removed kernel checks for versions below 2.6.20 - they were because of API changes in scheduler. If you are going to break compatibility below 2.6.20 then you should add the driver to versions.txt -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [Resend] lgs8gxx: add lgs8g75 support
lgs8gxx: add lgs8g75 demodulator support
Signed-off-by: David T.L. Wong davidtlw...@gmail.com
diff -r d4ed75759cae linux/drivers/media/dvb/frontends/lgs8gxx.c
--- a/linux/drivers/media/dvb/frontends/lgs8gxx.c Tue Jun 16 19:02:10 2009 -0300
+++ b/linux/drivers/media/dvb/frontends/lgs8gxx.c Wed Jun 17 10:58:37 2009 +0800
@@ -1,9 +1,9 @@
/*
- *Support for Legend Silicon DMB-TH demodulator
- *LGS8913, LGS8GL5
+ *Support for Legend Silicon GB20600 (a.k.a DMB-TH) demodulator
+ *LGS8913, LGS8GL5, LGS8G75
*experimental support LGS8G42, LGS8G52
*
- *Copyright (C) 2007,2008 David T.L. Wong davidtlw...@gmail.com
+ *Copyright (C) 2007-2009 David T.L. Wong davidtlw...@gmail.com
*Copyright (C) 2008 Sirius International (Hong Kong) Limited
*Timothy Lee timothy@siriushk.com (for initial work on LGS8GL5)
*
@@ -46,6 +46,42 @@
MODULE_PARM_DESC(fake_signal_str, fake signal strength for LGS8913.
Signal strength calculation is slow.(default:on).);
+static const u8 lgs8g75_initdat[] = {
+ 0x01, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xE4, 0xF5, 0xA8, 0xF5, 0xB8, 0xF5, 0x88, 0xF5,
+ 0x89, 0xF5, 0x87, 0x75, 0xD0, 0x00, 0x11, 0x50,
+ 0x11, 0x50, 0xF4, 0xF5, 0x80, 0xF5, 0x90, 0xF5,
+ 0xA0, 0xF5, 0xB0, 0x75, 0x81, 0x30, 0x80, 0x01,
+ 0x32, 0x90, 0x80, 0x12, 0x74, 0xFF, 0xF0, 0x90,
+ 0x80, 0x13, 0x74, 0x1F, 0xF0, 0x90, 0x80, 0x23,
+ 0x74, 0x01, 0xF0, 0x90, 0x80, 0x22, 0xF0, 0x90,
+ 0x00, 0x48, 0x74, 0x00, 0xF0, 0x90, 0x80, 0x4D,
+ 0x74, 0x05, 0xF0, 0x90, 0x80, 0x09, 0xE0, 0x60,
+ 0x21, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x1B, 0x12,
+ 0x00, 0xDD, 0x14, 0x60, 0x15, 0x12, 0x00, 0xDD,
+ 0x14, 0x60, 0x0F, 0x12, 0x00, 0xDD, 0x14, 0x60,
+ 0x09, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x03, 0x12,
+ 0x00, 0xDD, 0x90, 0x80, 0x42, 0xE0, 0x60, 0x0B,
+ 0x14, 0x60, 0x0C, 0x14, 0x60, 0x0D, 0x14, 0x60,
+ 0x0E, 0x01, 0xB3, 0x74, 0x04, 0x01, 0xB9, 0x74,
+ 0x05, 0x01, 0xB9, 0x74, 0x07, 0x01, 0xB9, 0x74,
+ 0x0A, 0xC0, 0xE0, 0x74, 0xC8, 0x12, 0x00, 0xE2,
+ 0xD0, 0xE0, 0x14, 0x70, 0xF4, 0x90, 0x80, 0x09,
+ 0xE0, 0x70, 0xAE, 0x12, 0x00, 0xF6, 0x12, 0x00,
+ 0xFE, 0x90, 0x00, 0x48, 0xE0, 0x04, 0xF0, 0x90,
+ 0x80, 0x4E, 0xF0, 0x01, 0x73, 0x90, 0x80, 0x08,
+ 0xF0, 0x22, 0xF8, 0x7A, 0x0C, 0x79, 0xFD, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD9,
+ 0xF6, 0xDA, 0xF2, 0xD8, 0xEE, 0x22, 0x90, 0x80,
+ 0x65, 0xE0, 0x54, 0xFD, 0xF0, 0x22, 0x90, 0x80,
+ 0x65, 0xE0, 0x44, 0xC2, 0xF0, 0x22
+};
+
/* LGS8GXX internal helper functions */
static int lgs8gxx_write_reg(struct lgs8gxx_state *priv, u8 reg, u8 data)
@@ -55,7 +91,7 @@
struct i2c_msg msg = { .flags = 0, .buf = buf, .len = 2 };
msg.addr = priv-config-demod_address;
- if (reg = 0xC0)
+ if (priv-config-prod != LGS8GXX_PROD_LGS8G75 reg = 0xC0)
msg.addr += 0x02;
if (debug = 2)
@@ -84,7 +120,7 @@
};
dev_addr = priv-config-demod_address;
- if (reg = 0xC0)
+ if (priv-config-prod != LGS8GXX_PROD_LGS8G75 reg = 0xC0)
dev_addr += 0x02;
msg[1].addr = msg[0].addr = dev_addr;
@@ -112,19 +148,36 @@
return 0;
}
+static int wait_reg_mask(struct lgs8gxx_state *priv, u8 reg, u8 mask,
+ u8 val, u8 delay, u8 tries)
+{
+ u8 t;
+ int i;
+
+ for (i = 0; i tries; i++) {
+ lgs8gxx_read_reg(priv, reg, t);
+
+ if ((t mask) == val)
+ return 0;
+ msleep(delay);
+ }
+
+ return 1;
+}
+
static int lgs8gxx_set_ad_mode(struct lgs8gxx_state *priv)
{
const struct lgs8gxx_config *config = priv-config;
u8 if_conf;
- if_conf = 0x10; /* AGC output on; */
+ if_conf = 0x10; /* AGC output on, RF_AGC output off; */
if_conf |=
((config-ext_adc) ? 0x80 : 0x00) |
((config-if_neg_center) ? 0x04 : 0x00) |
((config-if_freq == 0) ? 0x08 : 0x00) | /* Baseband */
- ((config-ext_adc config-adc_signed) ? 0x02 : 0x00) |
- ((config-ext_adc config-if_neg_edge) ? 0x01 : 0x00);
+ ((config-adc_signed) ? 0x02 : 0x00) |
+ ((config-if_neg_edge) ? 0x01 : 0x00);
if (config-ext_adc
(config-prod == LGS8GXX_PROD_LGS8G52)) {
@@ -157,39 +210,82 @@
}
dprintk(AFC_INIT_FREQ = 0x%08X\n, v32);
- lgs8gxx_write_reg(priv, 0x09, 0xFF (v32));
- lgs8gxx_write_reg(priv, 0x0A, 0xFF (v32 8));
- lgs8gxx_write_reg(priv, 0x0B, 0xFF (v32 16));
- lgs8gxx_write_reg(priv, 0x0C, 0xFF (v32 24));
+ if (priv-config-prod == LGS8GXX_PROD_LGS8G75) {
+ lgs8gxx_write_reg(priv, 0x08, 0xFF (v32));
+ lgs8gxx_write_reg(priv, 0x09, 0xFF (v32 8));
+ lgs8gxx_write_reg(priv, 0x0A, 0xFF (v32 16));
+ lgs8gxx_write_reg(priv, 0x0B, 0xFF (v32 24));
+ } else {
+ lgs8gxx_write_reg(priv, 0x09, 0xFF (v32));
+ lgs8gxx_write_reg(priv, 0x0A, 0xFF (v32 8));
+ lgs8gxx_write_reg(priv, 0x0B, 0xFF (v32 16));
+ lgs8gxx_write_reg(priv, 0x0C, 0xFF (v32 24));
+ }
+ return 0;
+}
+
+static int lgs8gxx_get_afc_phase(struct
[PATCH 2/2] [Resend] cx23885: add card Magic-Pro ProHDTV Extreme 2
cx23885: add card Magic-Pro ProHDTV Extreme 2 PCI-E.
Signed-off-by: David T.L. Wong davidtlw...@gmail.com
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c Thu Jun 11 20:04:04 2009 +0800
@@ -202,6 +202,10 @@
.name = Mygica X8506 DMB-TH,
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_MAGICPRO_PROHDTVE2] = {
+ .name = Magic-Pro ProHDTV Extreme 2,
+ .portb = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -325,6 +329,10 @@
.subvendor = 0x14f1,
.subdevice = 0x8651,
.card = CX23885_BOARD_MYGICA_X8506,
+ }, {
+ .subvendor = 0x14f1,
+ .subdevice = 0x8657,
+ .card = CX23885_BOARD_MAGICPRO_PROHDTVE2,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -716,8 +724,9 @@
cx23885_gpio_set(dev, GPIO_9);
break;
case CX23885_BOARD_MYGICA_X8506:
+ case CX23885_BOARD_MAGICPRO_PROHDTVE2:
/* GPIO-1 reset XC5000 */
- /* GPIO-2 reset LGS8GL5 */
+ /* GPIO-2 reset LGS8GL5 / LGS8G75 */
cx_set(GP0_IO, 0x0006);
cx_clear(GP0_IO, 0x0006);
mdelay(100);
@@ -828,6 +837,7 @@
ts2-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
case CX23885_BOARD_MYGICA_X8506:
+ case CX23885_BOARD_MAGICPRO_PROHDTVE2:
ts1-gen_ctrl_val = 0x5; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c Thu Jun 11 20:04:04 2009 +0800
@@ -441,6 +441,26 @@
.if_khz = 5380,
};
+static struct lgs8gxx_config magicpro_prohdtve2_lgs8g75_config = {
+ .prod = LGS8GXX_PROD_LGS8G75,
+ .demod_address = 0x19,
+ .serial_ts = 0,
+ .ts_clk_pol = 1,
+ .ts_clk_gated = 1,
+ .if_clk_freq = 30400, /* 30.4 MHz */
+ .if_freq = 6500, /* 6.50 MHz */
+ .if_neg_center = 1,
+ .ext_adc = 0,
+ .adc_signed = 1,
+ .adc_vpp = 2, /* 1.6 Vpp */
+ .if_neg_edge = 1,
+};
+
+static struct xc5000_config magicpro_prohdtve2_xc5000_config = {
+ .i2c_address = 0x61,
+ .if_khz = 6500,
+};
+
static int dvb_register(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port-dev;
@@ -779,6 +799,19 @@
mygica_x8506_xc5000_config);
}
break;
+ case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+ i2c_bus = dev-i2c_bus[0];
+ i2c_bus2 = dev-i2c_bus[1];
+ fe0-dvb.frontend = dvb_attach(lgs8gxx_attach,
+ magicpro_prohdtve2_lgs8g75_config,
+ i2c_bus-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(xc5000_attach,
+fe0-dvb.frontend,
+i2c_bus2-i2c_adap,
+magicpro_prohdtve2_xc5000_config);
+ }
+ break;
default:
printk(KERN_INFO %s: The frontend of your DVB/ATSC card
isn't supported yet\n,
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885.h Thu Jun 11 20:04:04 2009 +0800
@@ -77,6 +77,7 @@
#define CX23885_BOARD_HAUPPAUGE_HVR125520
#define CX23885_BOARD_HAUPPAUGE_HVR121021
#define CX23885_BOARD_MYGICA_X8506 22
+#define CX23885_BOARD_MAGICPRO_PROHDTVE2 23
#define GPIO_0 0x0001
#define GPIO_1 0x0002
RE: About V4l2 overlay sequence
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo, Nathaniel Kim Sent: Thursday, June 11, 2009 11:15 AM To: xie Cc: v4l2_linux Subject: Re: About V4l2 overlay sequence It seems to be totally described in v4l2 api specification document. The document is saying like this: VIDIOC_QUERYCAP video input and video standard ioctls VIDIOC_G_FBUF and VIDIOC_S_FBUF VIDIOC_G_FMT/S_FMT/TRY_FMT VIDIOC_OVERLAY Take a look at the document for detailed usage. Cheers, Nate On Wed, Jun 10, 2009 at 6:13 PM, xieyili@gmail.com wrote: Dear all ~~ With your help I have implemented the preview with capture interface ~~ Now i want to implement the preview with ovelay , and my camera support s ovelay ~ Who can tell me where I can find the document about ovelay sequcence ~ ? Or does there have a standard example source code ~ ? Thanks a lot ~ Best regards [Shah, Hardik] You can also look at the OMAP display driver which is using this feature. http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=blob;f=drivers/media/video/omap/omap_vout.c;h=fc8ccd9f9e30e070e32fd37b5a4e7fd07e19d2e3;hb=refs/heads/ti_display All the ioctls listed by Nate above are supported by this driver. Regards, Hardik Shah -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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 -- 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
