How to interpret SNR, BER, Signal Strength from TT C-1501

2009-06-16 Thread Martin Schmid
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

2009-06-16 Thread David Coles
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

2009-06-16 Thread Thomas Kernen

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

2009-06-16 Thread Eduardo Valentin
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

2009-06-16 Thread Eduardo Valentin
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

2009-06-16 Thread Hans Verkuil
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

2009-06-16 Thread Eduardo Valentin
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

2009-06-16 Thread Hans Verkuil
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

2009-06-16 Thread Hans Verkuil
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

2009-06-16 Thread Eero Nurkkala
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Eduardo Valentin
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

2009-06-16 Thread Eduardo Valentin
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

2009-06-16 Thread Eero Nurkkala
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

2009-06-16 Thread Udi Atar
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

2009-06-16 Thread Edouard Lafargue
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Guennadi Liakhovetski
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

2009-06-16 Thread Aguirre Rodriguez, Sergio Alberto
 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

2009-06-16 Thread Karicheri, Muralidharan
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

2009-06-16 Thread Jonathan Cameron
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

2009-06-16 Thread 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
--
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

2009-06-16 Thread Karicheri, Muralidharan
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Guennadi Liakhovetski
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

2009-06-16 Thread Mauro Carvalho Chehab
Em Tue, 16 Jun 2009 09:24:14 -0500
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com escreveu:

 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.

Ok.
 
 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.

That's good news! I think there are still some OMAP 2 RFC patches that weren't
applied. Are you also handling those?

 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.

Ok, thanks.

 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: OMAP patches for linux-media

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Figo.zhang
 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()

2009-06-16 Thread Mauro Carvalho Chehab
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/

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Alexey Klimov
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

2009-06-16 Thread Jonathan Cameron
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

2009-06-16 Thread Trent Piepho
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

2009-06-16 Thread Hans Verkuil
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Karicheri, Muralidharan
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

2009-06-16 Thread Edouard Lafargue
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

2009-06-16 Thread Michael Krufky

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

2009-06-16 Thread Michael Krufky

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

2009-06-16 Thread Alexey Klimov
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Trent Piepho
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

2009-06-16 Thread Michael Krufky
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

2009-06-16 Thread hermann pitton
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

2009-06-16 Thread Trent Piepho
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

2009-06-16 Thread Mauro Carvalho Chehab
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

2009-06-16 Thread Trent Piepho
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

2009-06-16 Thread David Wong
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

2009-06-16 Thread David Wong
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

2009-06-16 Thread Shah, Hardik


 -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