Re: [PATCH] hdpvr: enable IR part

2011-01-15 Thread Andy Walls 
With my newly hacked lirc_zilog, try using the 'tx_only' parameter please.  
It's not quite ready yet, but I'd like to know if it can bind.

If you already loaded a lirc_zilog without my latest patches, the i2c subsystem 
might have bogus crud still registered.  A reboot might be needed for a valid 
test.

R,
Andy 

Jarod Wilson ja...@wilsonet.com wrote:

On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote:
...
 BTW, a checkpatch and compiler tested lirc_zilog.c is here:
 
 http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8
 
 It should fix all the binding and allocation problems related to
 ir_probe()/ir_remove().  Except I suspect it may leak the Rx poll
 kthread.  That's possibly another bug to add to the list.
 
 Anyway, $DIETY knows if the lirc_zilog module actually still works after
 all my hacks.  Give it a test if you are adventurous.  I won't be able
 to test until tomorrow evening.
 
 I'll try to grab those and give them a test tomorrow, and hey, I've even got
 a baseline to test against now.

Forgot to mention: I think it was suggested that one could use ir-kbd-i2c
for receive and lirc_zilog for transmit, at the same time. With ir-kbd-i2c
already loaded, lirc_zilog currently won't bind to anything.

-- 
Jarod Wilson
ja...@wilsonet.com



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

Technotrend C-2300, LOCK but no data on encrypted channels

2011-01-15 Thread Magion 
Hi!

I have a Technotrend C-2300 which have been working great with MythTV
on Mythbuntu 8.10 for both FTA and encrypted channels.
About two weeks ago I decided to reinstall my HTPC and install Gentoo
instead, as that is the distro I usually prefer...
but whatever I tried, I just couldn't get the C-2300 to work with
encrypted channels.
I tried kernel 2.6.32, 2.6.34 and 2.6.36, and I always get a lock on
the encrypted channels, but there seems like I get no data.
So I then tried installing Mythbuntu again, but now I can't get it to
work with that either, it's the same error.
I have every Mythbuntu version from 8.04 to 10.10, and whatever I do I
just get the same result.
So then I tried to put in my old Technotrend C-1500 instead, and with
that I get LOCK and picture/audio, but, for some reason
that card only get about 55% signal, whereas the C-2300 always get
atleast 80%... so some channels are unwatchable with the C-1500.

Can someone please give me some more advice on what I can try to get
the C-2300 to get data on encrypted channels again?
(btw, I've tried every firmware I could find for it, all with the same results)
I'm starting to think that the card somehow is broken... which would
be odd, as all I did was reinstall, and it works perfectly for FTA
channels.
Mplayer says it gets a TS stream, but on encrypted channels it just
hangs there, whereas on FTA channels it finds video and audio and then
plays the stream.
Oh, I've also tried with both CI and softcam, and it says it gets the
correct key and LOCK, but still no data.
I'm out of ideas!

If you need some logs or some other info or anything, I'll be happy to post it.

/Mattias
--
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

Patches an media build tree

2011-01-15 Thread Helmut Auer 

Hello List

How long does it usually take til patches are integrated into the media build tree ( after 
posting these here ) ?

I'm just wondering because I miss some patches posted here.

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

Re: [PATCH] dib7000m/p: struct alignment fix

2011-01-15 Thread Robin Humble 
Hi Patrick,

On Fri, Jan 14, 2011 at 06:11:24PM +0100, Patrick Boettcher wrote:
On Wed, 12 Jan 2011, Mauro Carvalho Chehab wrote:
Em 12-01-2011 11:17, Robin Humble escreveu:
this is basically a re-post of
  http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html
which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge
Nova-T, Winfast DTV. it seems to be quite commonly reported on this list.

 [  809.128579] BUG: unable to handle kernel NULL pointer dereference at 
 0012
 [  809.128586] IP: [a0013702] i2c_transfer+0x16/0x124 [i2c_core]
 [  809.128598] PGD 669a7067 PUD 79e5f067 PMD 0
 [  809.128604] Oops:  [#1] SMP
...
Could you try this patch:
http://git.linuxtv.org/pb/media_tree.git?a=commit;h=80a5f1fdc6beb496347cbb297f9c1458c8cb9f50
and report whether it solves the problem or not?

yes, that patch works for me on linux-media's media-master branch, and
also on fedora 2.6.35.10-72.fc14.x86_64.
thanks for workng on this!
it makes a lot of sense that the pid filtering fns are the root cause.

please feel free to add this to your patch:
  Tested-by: Robin Humble robin.humble+...@anu.edu.au
and to scrap my patch.

cheers,
robin
--
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] hdpvr: enable IR part

2011-01-15 Thread Andy Walls 
On Sat, 2011-01-15 at 00:37 -0500, Jarod Wilson wrote:
 On Jan 14, 2011, at 11:35 PM, Andy Walls wrote:
 

 
 A single button press w/ir-kbd-i2c debugging and your patch:
 
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 ir-kbd-i2c: ir_poll_key
 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00
 T.
 ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21
 


FWIW, here's what an HVR-1600 and ir-kbd-i2c dumped out for me:

ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 24 00   $.
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=9
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 24 00   $.
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=9
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
[...]
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 08 00   ..
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=2
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..
ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00   ..

I did a momentary press of button '9' and got a single '9'.

I did a press and hold of button '2' during which I accidentally pointed
the remote away from the sensor and then back.  IIRC I got one '2' and
then many '2''s after an initial lag.  (What I might expect from holding
down a keybard key.)

I did a following momentary press of button '2'. I can't recall if I got
one or many '2''s for that.

Regards,
Andy

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

Re: no sound with WinTV HVR-980 - Help

2011-01-15 Thread Mauro Carvalho Chehab 
Em 15-01-2011 03:03, Pasquale escreveu:
 Hello I am running the following OS Ubuntu 10.04.1 LTS 
 with Mythtv I have a WinTv HVR-980 and hvae no sound with 
 video see errors below any assistance would be appreciated.
 
 I should have a /dev/dsp1 but I can not find it?
 
 
 [   28.349674] em28xx #0: Config register raw data: 0xd0
 [   28.350444] em28xx #0: AC97 vendor ID = 0x
 [   28.350819] em28xx #0: AC97 features = 0x6a90
 [   28.350822] em28xx #0: Empia 202 AC97 audio processor detected
 [   28.588908] em28xx #0: v4l2 driver version 0.1.2
 [   28.676311] em28xx #0: V4L2 video device registered as /dev/video0
 [   28.676315] em28xx #0: V4L2 VBI device registered as /dev/vbi0
 [   28.692112] usbcore: registered new interface driver em28xx
 [   28.692117] em28xx driver loaded
 [   28.706196] em28xx_alsa: disagrees about version of symbol snd_pcm_new
 [   28.706201] em28xx_alsa: Unknown symbol snd_pcm_new
 [   28.706319] em28xx_alsa: disagrees about version of symbol 
 snd_card_register
 [   28.706322] em28xx_alsa: Unknown symbol snd_card_register
 [   28.706438] em28xx_alsa: disagrees about version of symbol snd_card_free
 [   28.706440] em28xx_alsa: Unknown symbol snd_card_free
 [   28.706673] em28xx_alsa: disagrees about version of symbol 
 snd_pcm_lib_ioctl
 [   28.706675] em28xx_alsa: Unknown symbol snd_pcm_lib_ioctl
 [   28.706988] em28xx_alsa: disagrees about version of symbol snd_pcm_set_ops
 [   28.706990] em28xx_alsa: Unknown symbol snd_pcm_set_ops
 [   28.707209] em28xx_alsa: disagrees about version of symbol
 snd_pcm_hw_constraint_integer
 [   28.707212] em28xx_alsa: Unknown symbol snd_pcm_hw_constraint_integer
 [   28.707657] em28xx_alsa: disagrees about version of symbol snd_card_create
 [   28.707660] em28xx_alsa: Unknown symbol snd_card_create
 [   28.707766] em28xx_alsa: disagrees about version of symbol
 snd_pcm_period_elapsed
 [   28.707768] em28xx_alsa: Unknown symbol snd_pcm_period_elapsed
 [   28.910841] em28xx #0/2: xc3028 attached
 [   28.910844] DVB: registering new adapter (em28xx #0)
 [   28.911226] Successfully loaded em28xx-dvb

Or you have two em28xx drivers or you compiled em28xx_alsa against a different
header than the ones used to compile the alsa modules on your distro.

It is reported that (some versions) Ubuntu ships the wrong alsa headers
with their kernel header package.

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: no sound with WinTV HVR-980 - Help

2011-01-15 Thread Mauro Carvalho Chehab 
Em 15-01-2011 13:15, Pasquale Riccio escreveu:
 How do I verify if I have the latest headers? do I use the Ubuntu 
 repositories to update (apt-get)  or should I download a version from 
 somewhere?

Sorry, I've no idea. I'm not an Ubuntu user, but it seems that they compile 
alsa on a separate
package, and they don't include the alsa headers at the kernel tree. The 
out-of-tree compilation
of media_build (and the deprecated mercurial tree) only looks for the alsa 
headers on the
kernel tree (where they should be). 

So, if Ubuntu shipping the alsa headers on a different directory or aren't 
providing the
alsa headers at all, the driver will compile, but, as the headers will be 
obsolete,
any alsa driver compiled from V4L/DVB won't work, as symbol definitions won't 
match.

One way to fix it is to get the latest kernel (2.6.37) from kernel.org and 
compile from it.
I think that there were no recent changes on em28xx that could affect HVR-980. 
So, using
the vanilla 2.6.37 should provide you audio, video and remote controller on 
this device.

Cheers,
Mauro

 Thank you for the reply,
 Pasquale
 
 
 
 On Sat, Jan 15, 2011 at 9:58 AM, Mauro Carvalho Chehab mche...@redhat.com 
 mailto:mche...@redhat.com wrote:
 
 Em 15-01-2011 03:03, Pasquale escreveu:
  Hello I am running the following OS Ubuntu 10.04.1 LTS
  with Mythtv I have a WinTv HVR-980 and hvae no sound with
  video see errors below any assistance would be appreciated.
 
  I should have a /dev/dsp1 but I can not find it?
 
 
  [   28.349674] em28xx #0: Config register raw data: 0xd0
  [   28.350444] em28xx #0: AC97 vendor ID = 0x
  [   28.350819] em28xx #0: AC97 features = 0x6a90
  [   28.350822] em28xx #0: Empia 202 AC97 audio processor detected
  [   28.588908] em28xx #0: v4l2 driver version 0.1.2
  [   28.676311] em28xx #0: V4L2 video device registered as /dev/video0
  [   28.676315] em28xx #0: V4L2 VBI device registered as /dev/vbi0
  [   28.692112] usbcore: registered new interface driver em28xx
  [   28.692117] em28xx driver loaded
  [   28.706196] em28xx_alsa: disagrees about version of symbol 
 snd_pcm_new
  [   28.706201] em28xx_alsa: Unknown symbol snd_pcm_new
  [   28.706319] em28xx_alsa: disagrees about version of symbol 
 snd_card_register
  [   28.706322] em28xx_alsa: Unknown symbol snd_card_register
  [   28.706438] em28xx_alsa: disagrees about version of symbol 
 snd_card_free
  [   28.706440] em28xx_alsa: Unknown symbol snd_card_free
  [   28.706673] em28xx_alsa: disagrees about version of symbol 
 snd_pcm_lib_ioctl
  [   28.706675] em28xx_alsa: Unknown symbol snd_pcm_lib_ioctl
  [   28.706988] em28xx_alsa: disagrees about version of symbol 
 snd_pcm_set_ops
  [   28.706990] em28xx_alsa: Unknown symbol snd_pcm_set_ops
  [   28.707209] em28xx_alsa: disagrees about version of symbol
  snd_pcm_hw_constraint_integer
  [   28.707212] em28xx_alsa: Unknown symbol snd_pcm_hw_constraint_integer
  [   28.707657] em28xx_alsa: disagrees about version of symbol 
 snd_card_create
  [   28.707660] em28xx_alsa: Unknown symbol snd_card_create
  [   28.707766] em28xx_alsa: disagrees about version of symbol
  snd_pcm_period_elapsed
  [   28.707768] em28xx_alsa: Unknown symbol snd_pcm_period_elapsed
  [   28.910841] em28xx #0/2: xc3028 attached
  [   28.910844] DVB: registering new adapter (em28xx #0)
  [   28.911226] Successfully loaded em28xx-dvb
 
 Or you have two em28xx drivers or you compiled em28xx_alsa against a 
 different
 header than the ones used to compile the alsa modules on your distro.
 
 It is reported that (some versions) Ubuntu ships the wrong alsa headers
 with their kernel header package.
 
 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] hdpvr: enable IR part

2011-01-15 Thread Andy Walls 
On Sat, 2011-01-15 at 07:50 -0500, Andy Walls wrote:
 Jarod Wilson ja...@wilsonet.com wrote:

 Forgot to mention: I think it was suggested that one could use ir-kbd-i2c
 for receive and lirc_zilog for transmit, at the same time. With ir-kbd-i2c
 already loaded, lirc_zilog currently won't bind to anything.


 With my newly hacked lirc_zilog, try using the 'tx_only' parameter
 please.  It's not quite ready yet, but I'd like to know if it can
 bind.

I have now tested this.

Using the 'tx_only' module parameter to lirc_zilog appears to allow
ir-kbd-i2c and lirc_zilog to coexist, for I2C subsystem binding at
least.

It does not appear to matter what order the two modules are loaded. I
tried it both ways.


However, lirc_zilog sharing of Z8 is not fully functional yet.  I need
to change things to have the bridge drivers provide a IR transceiver
mutex to both lirc_zilog and ir-kbd-i2c.  lirc_zilog and ir-kbd-i2c
would use that mutex for exclusive access to the Z8 when needed, if it
was provided by the bridge driver.

I view proper sharing of the Z8 as an important requirement, because of
two use cases:

1. User only wants to use the Z8 for IR Rx.  User doesn't want to fetch
the lirc_zilog required firmware or perform any LIRC setup.

2. User only wants to use the Z8 for IR Tx.  User uses some other
ir-kbd-i2c supported receiver and remote IR Rx.

Maybe use case #2 is too rare to worry about?
However, if one accepts both use cases as valid, then ir-kbd-i2c must
support the Z8, and lirc_zilog must be able to coexist with ir-kbd-i2c.

Proper sharing of the Z8 is, however, lower on my to-do list than fixing
some internal lirc_zilog problems.

Regards,
Andy

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

Re: [PATCH v14 1/2] davinci vpbe: platform specific additions

2011-01-15 Thread Sergei Shtylyov 

Hello.

On 14-01-2011 16:31, Manjunath Hadli wrote:


This patch implements the overall device creation for the Video
display driver.


   It does not only that...


Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
Acked-by: Muralidharan Karicherim-kariche...@ti.com
Acked-by: Hans Verkuilhverk...@xs4all.nl

[...]


diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..f435c7d 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
  #define DM365_MMCSD0_BASE  0x01D11000
  #define DM365_MMCSD1_BASE  0x01D0

+void __iomem  *davinci_sysmodbase;
+


   I think this should be added in a sperate patch.


@@ -242,10 +242,7 @@ void __init davinci_setup_mmc(int module, struct 
davinci_mmc_config *config)
SZ_4K - 1;
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
-   /* REVISIT: should this be in board-init code? */


   Why you removed that line?


-   void __iomem *base =
-   IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+   void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2652af1..106bc1b 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -878,6 +878,9 @@ void __init dm355_init_asp1(u32 evt_enable, struct 
snd_platform_data *pdata)

  void __init dm355_init(void)
  {
+   davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+   if (!davinci_sysmodbase)
+   return;


   Why not do it in davinci_common_init() instead of repeating for every SoC?


davinci_common_init(davinci_soc_info_dm355);
  }

[...]

diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h 
b/arch/arm/mach-davinci/include/mach/dm644x.h
index 5a1b26d..790925f 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -40,8 +44,14 @@
  #define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x0600
  #define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x0800

+/* VPBE register base addresses */
+#define DM644X_VPSS_REG_BASE   0x01c73400
+#define DM644X_VENC_REG_BASE   0x01C72400
+#define DM644X_OSD_REG_BASE0x01C72600


   Note that for other devices we don't have '_REG' in such macros. Would 
make sense to delete it here for consistency.


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

[PATCH 1/8] [media] tda8290: Make all read operations atomic

2011-01-15 Thread Mauro Carvalho Chehab 
Read operations should be preceeded by a write operation. However,
nothing prevents that an I2C operation could happen between the two
transactions.

To avoid that problem, use an unique I2C transfer for both parts of
the I2C transaction.

Cc: Michael Krufky mkru...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/common/tuners/tda8290.c 
b/drivers/media/common/tuners/tda8290.c
index c9062ce..5f889c1 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -95,8 +95,7 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int 
close)
msleep(20);
} else {
msg = disable;
-   tuner_i2c_xfer_send(priv-i2c_props, msg, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, msg[1], 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props, msg, 1, msg[1], 1);
 
buf[2] = msg[1];
buf[2] = ~0x04;
@@ -239,13 +238,15 @@ static void tda8290_set_params(struct dvb_frontend *fe,
fe-ops.tuner_ops.set_analog_params(fe, params);
 
for (i = 0; i  3; i++) {
-   tuner_i2c_xfer_send(priv-i2c_props, addr_pll_stat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, pll_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_pll_stat, 1, pll_stat, 1);
if (pll_stat  0x80) {
-   tuner_i2c_xfer_send(priv-i2c_props, addr_adc_sat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, adc_sat, 1);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_agc_stat, 
1);
-   tuner_i2c_xfer_recv(priv-i2c_props, agc_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_adc_sat, 1,
+adc_sat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_agc_stat, 1,
+agc_stat, 1);
tuner_dbg(tda8290 is locked, AGC: %d\n, agc_stat);
break;
} else {
@@ -259,20 +260,22 @@ static void tda8290_set_params(struct dvb_frontend *fe,
   agc_stat, adc_sat, pll_stat  0x80);
tuner_i2c_xfer_send(priv-i2c_props, gainset_2, 2);
msleep(100);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_agc_stat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, agc_stat, 1);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_pll_stat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, pll_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_agc_stat, 1, agc_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_pll_stat, 1, pll_stat, 1);
if ((agc_stat  115) || !(pll_stat  0x80)) {
tuner_dbg(adjust gain, step 2. Agc: %d, lock: %d\n,
   agc_stat, pll_stat  0x80);
if (priv-cfg.agcf)
priv-cfg.agcf(fe);
msleep(100);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_agc_stat, 
1);
-   tuner_i2c_xfer_recv(priv-i2c_props, agc_stat, 1);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_pll_stat, 
1);
-   tuner_i2c_xfer_recv(priv-i2c_props, pll_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_agc_stat, 1,
+agc_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_pll_stat, 1,
+pll_stat, 1);
if((agc_stat  115) || !(pll_stat  0x80)) {
tuner_dbg(adjust gain, step 3. Agc: %d\n, 
agc_stat);
tuner_i2c_xfer_send(priv-i2c_props, 
adc_head_12, 2);
@@ -284,10 +287,12 @@ static void tda8290_set_params(struct dvb_frontend *fe,
 
/* l/ l' deadlock? */
if(priv-tda8290_easy_mode  0x60) {
-   tuner_i2c_xfer_send(priv-i2c_props, addr_adc_sat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, adc_sat, 1);
-   tuner_i2c_xfer_send(priv-i2c_props, addr_pll_stat, 1);
-   tuner_i2c_xfer_recv(priv-i2c_props, pll_stat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+addr_adc_sat, 1,
+adc_sat, 1);
+   tuner_i2c_xfer_send_recv(priv-i2c_props,
+

[PATCH 2/8] [media] tda8290: Fix a bug if no tuner is detected

2011-01-15 Thread Mauro Carvalho Chehab 
If tda8290 is detected, but no tuner is found, the driver will do bad
things:

tuner 2-0060: chip found @ 0xc0 (saa7133[0])
tda829x 2-0060: could not clearly identify tuner address, defaulting to 60
tda829x 2-0060: tuner access failed!
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [a048c267] set_audio+0x47/0x170 [tda8290]
PGD 1187b0067 PUD 11771e067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/module/i2c_core/initstate
CPU 0
Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) 
ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) 
saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) 
v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) 
tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq 
freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter 
ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput 
floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq 
snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac 
edac_core nouveau
Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) 
ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) 
saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) 
v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) 
tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq 
freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter 
ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput 
floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq 
snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac 
edac_core nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core 
ext3 jbd mbcache firewire_ohci firewire_core crc!
 _itu_t sr_mod cdrom sd_mod crc_t10dif ahci dm_mod [last unloaded: microcode]
Pid: 9497, comm: modprobe Not tainted 2.6.32-72.el6.x86_64 #1 HP Z400 
Workstation
RIP: 0010:[a048c267]  [a048c267] set_audio+0x47/0x170 
[tda8290]
RSP: 0018:88010ba01b28  EFLAGS: 00010206
RAX: 00ff RBX: 880119522800 RCX: 0002
RDX: 3be0 RSI: 88010ba01bb8 RDI: 
RBP: 88010ba01b28 R08: 0002 R09: 
R10:  R11:  R12: 
R13: 88010ba01bb8 R14: 1900 R15: 1900
FS:  7f4b96b3d700() GS:88002820() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0020 CR3: 00011866c000 CR4: 26f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process modprobe (pid: 9497, threadinfo 88010ba0, task 880100708a70)
Stack:
 88010ba01b98 a048c95b 88010ba01b78 0060
0  000e 001d a03ec838
0 88010abac240 880119522800 880119522800 880119522bc0
Call Trace:
 [a048c95b] tda8295_set_params+0x3b/0x210 [tda8290]
 [a03ec838] ? v4l2_i2c_new_subdev_cfg+0x88/0xc0 [v4l2_common]
 [a0484418] set_freq+0x128/0x2f0 [tuner]
 [a0486464] tuner_s_std+0xc4/0x740 [tuner]
 [a04b9ae6] saa7134_set_tvnorm_hw+0x2d6/0x3d0 [saa7134]
 [a04ba455] set_tvnorm+0xd5/0x100 [saa7134]
 [a04bc9fd] saa7134_video_init2+0x1d/0x50 [saa7134]
 [a04bf57e] saa7134_initdev+0x6e1/0xb1d [saa7134]
 [8125afea] ? kobject_get+0x1a/0x30
 [812765f7] local_pci_probe+0x17/0x20
 [812777e1] pci_device_probe+0x101/0x120
 [8132ec72] ? driver_sysfs_add+0x62/0x90
 [8132ee10] driver_probe_device+0xa0/0x2a0
 [8132f0bb] __driver_attach+0xab/0xb0
 [8132f010] ? __driver_attach+0x0/0xb0
 [8132e074] bus_for_each_dev+0x64/0x90
 [8132ebae] driver_attach+0x1e/0x20
 [8132e4b0] bus_add_driver+0x200/0x300
 [8132f3e6] driver_register+0x76/0x140
 [814c7c43] ? printk+0x41/0x46
 [81277a46] __pci_register_driver+0x56/0xd0
 [a04de000] ? saa7134_init+0x0/0x4f [saa7134]
 [a04de04d] saa7134_init+0x4d/0x4f [saa7134]
 [8100a04c] do_one_initcall+0x3c/0x1d0
 [810af5ef] sys_init_module+0xdf/0x250
 [81013172] system_call_fastpath+0x16/0x1b
Code: 20 01 49 c7 c0 c9 ec 48 a0 83 7e 04 01 74 2d

[PATCH 3/8] [media] tda8290: Turn tda829x on before touching at the I2C gate

2011-01-15 Thread Mauro Carvalho Chehab 
On Kworld SBTVD, tda8295-c1 starts in power off mode. It needs
to be powered, otherwise, the I2C gate control command won't work.

Cc: Michael Krufky mkru...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/common/tuners/tda8290.c 
b/drivers/media/common/tuners/tda8290.c
index 11ea4e0..419d064 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -754,11 +754,10 @@ struct dvb_frontend *tda829x_attach(struct dvb_frontend 
*fe,
   sizeof(struct analog_demod_ops));
}
 
-   if ((!(cfg) || (TDA829X_PROBE_TUNER == cfg-probe_tuner)) 
-   (tda829x_find_tuner(fe)  0)) {
-   memset(fe-ops.analog_ops, 0, sizeof(struct analog_demod_ops));
-
-   goto fail;
+   if (!(cfg) || (TDA829X_PROBE_TUNER == cfg-probe_tuner)) {
+   tda8295_power(fe, 1);
+   if (tda829x_find_tuner(fe)  0)
+   goto fail;
}
 
switch (priv-ver) {
@@ -803,6 +802,8 @@ struct dvb_frontend *tda829x_attach(struct dvb_frontend *fe,
return fe;
 
 fail:
+   memset(fe-ops.analog_ops, 0, sizeof(struct analog_demod_ops));
+
tda829x_release(fe);
return NULL;
 }
-- 
1.7.1


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

[PATCH 6/8] [media] saa7134: Fix analog mode for Kworld SBTVD

2011-01-15 Thread Mauro Carvalho Chehab 
There were some issues at tda8290 that were preventing this device
to work. Now that those fixes were fixed, we can enable analog
mode.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/saa7134/saa7134-cards.c 
b/drivers/media/video/saa7134/saa7134-cards.c
index e7aa588..b242600 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5179,18 +5179,8 @@ struct saa7134_board saa7134_boards[] = {
[SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG] = {
.name   = Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid,
.audio_clock= 0x00187de7,
-#if 0
-   /*
-* FIXME: Analog mode doesn't work, if digital is enabled. The proper
-* fix is to use tda8290 driver, but Kworld seems to use an
-* unsupported version of tda8295.
-*/
-   .tuner_type = TUNER_NXP_TDA18271,   /* 
TUNER_PHILIPS_TDA8290 */
-   .tuner_addr = 0x60,
-#else
-   .tuner_type = UNSET,
+   .tuner_type = TUNER_PHILIPS_TDA8290,
.tuner_addr = ADDR_UNSET,
-#endif
.radio_type = UNSET,
.radio_addr = ADDR_UNSET,
.gpiomask   = 0x8e054000,
@@ -5201,6 +5191,7 @@ struct saa7134_board saa7134_boards[] = {
.vmux   = 1,
.amux   = TV,
.tv = 1,
+   .gpio   = 0x4000,
 #if 0  /* FIXME */
}, {
.name   = name_comp1,
@@ -7659,36 +7650,11 @@ int saa7134_board_init2(struct saa7134_dev *dev)
break;
}
case SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG:
-   {
-   struct i2c_msg msg = { .addr = 0x4b, .flags = 0 };
-   int i;
-   static u8 buffer[][2] = {
-   {0x30, 0x31},
-   {0xff, 0x00},
-   {0x41, 0x03},
-   {0x41, 0x1a},
-   {0xff, 0x02},
-   {0x34, 0x00},
-   {0x45, 0x97},
-   {0x45, 0xc1},
-   };
saa_writel(SAA7134_GPIO_GPMODE0  2, 0x4000);
saa_writel(SAA7134_GPIO_GPSTATUS0  2, 0x4000);
 
-   /*
-* FIXME: identify what device is at addr 0x4b and what means
-* this initialization
-*/
-   for (i = 0; i  ARRAY_SIZE(buffer); i++) {
-   msg.buf = buffer[i][0];
-   msg.len = ARRAY_SIZE(buffer[0]);
-   if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
-   printk(KERN_WARNING
-  %s: Unable to enable tuner(%i).\n,
-  dev-name, i);
-   }
+   saa7134_set_gpio(dev, 27, 0);
break;
-   }
} /* switch() */
 
/* initialize tuner */
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c 
b/drivers/media/video/saa7134/saa7134-dvb.c
index 3315a48..064bf2c 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -236,7 +236,7 @@ static struct tda18271_std_map mb86a20s_tda18271_std_map = {
 
 static struct tda18271_config kworld_tda18271_config = {
.std_map = mb86a20s_tda18271_std_map,
-   .gate= TDA18271_GATE_DIGITAL,
+   .gate= TDA18271_GATE_ANALOG,
 };
 
 static const struct mb86a20s_config kworld_mb86a20s_config = {
@@ -623,37 +623,6 @@ static struct tda827x_config tda827x_cfg_2_sw42 = {
 
 /* -- */
 
-static int __kworld_sbtvd_i2c_gate_ctrl(struct saa7134_dev *dev, int enable)
-{
-   unsigned char initmsg[] = {0x45, 0x97};
-   unsigned char msg_enable[] = {0x45, 0xc1};
-   unsigned char msg_disable[] = {0x45, 0x81};
-   struct i2c_msg msg = {.addr = 0x4b, .flags = 0, .buf = initmsg, .len = 
2};
-
-   if (i2c_transfer(dev-i2c_adap, msg, 1) != 1) {
-   wprintk(could not access the I2C gate\n);
-   return -EIO;
-   }
-   if (enable)
-   msg.buf = msg_enable;
-   else
-   msg.buf = msg_disable;
-   if (i2c_transfer(dev-i2c_adap, msg, 1) != 1) {
-   wprintk(could not access the I2C gate\n);
-   return -EIO;
-   }
-   msleep(20);
-   return 0;
-}
-static int kworld_sbtvd_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
-{
-   struct saa7134_dev *dev = fe-dvb-priv;
-
-   return __kworld_sbtvd_i2c_gate_ctrl(dev, enable);
-}
-
-/* -- */
-
 static struct tda1004x_config tda827x_lifeview_config = {
.demod_address = 0x08,
.invert= 1,
@@ -1660,7 +1629,6 @@ static int

[PATCH 4/8] [media] mb86a20s: Fix i2c read/write error messages

2011-01-15 Thread Mauro Carvalho Chehab 
A script replaced err var to rc. Howerver, this script gambled
error string, changing it to rcor. Revert that bad change.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/dvb/frontends/mb86a20s.c 
b/drivers/media/dvb/frontends/mb86a20s.c
index d3ad3e7..e06507d 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -318,7 +318,7 @@ static int mb86a20s_i2c_writereg(struct mb86a20s_state 
*state,
 
rc = i2c_transfer(state-i2c, msg, 1);
if (rc != 1) {
-   printk(%s: writereg rcor(rc == %i, reg == 0x%02x,
+   printk(%s: writereg error (rc == %i, reg == 0x%02x,
  data == 0x%02x)\n, __func__, rc, reg, data);
return rc;
}
@@ -353,7 +353,7 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state 
*state,
rc = i2c_transfer(state-i2c, msg, 2);
 
if (rc != 2) {
-   rc(%s: reg=0x%x (rcor=%d)\n, __func__, reg, rc);
+   rc(%s: reg=0x%x (error=%d)\n, __func__, reg, rc);
return rc;
}
 
-- 
1.7.1


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

[PATCH 7/8] [media] saa7134: Fix digital mode on Kworld SBTVD

2011-01-15 Thread Mauro Carvalho Chehab 
This patch fixes digital mode on Kworld SBTVD. Unfortunately, it disables
analog mode.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/saa7134/saa7134-cards.c 
b/drivers/media/video/saa7134/saa7134-cards.c
index b242600..dea90a1 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5179,7 +5179,11 @@ struct saa7134_board saa7134_boards[] = {
[SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG] = {
.name   = Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid,
.audio_clock= 0x00187de7,
+#if 0
.tuner_type = TUNER_PHILIPS_TDA8290,
+#else
+   .tuner_type = UNSET,
+#endif
.tuner_addr = ADDR_UNSET,
.radio_type = UNSET,
.radio_addr = ADDR_UNSET,
@@ -5191,7 +5195,6 @@ struct saa7134_board saa7134_boards[] = {
.vmux   = 1,
.amux   = TV,
.tv = 1,
-   .gpio   = 0x4000,
 #if 0  /* FIXME */
}, {
.name   = name_comp1,
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c 
b/drivers/media/video/saa7134/saa7134-dvb.c
index 064bf2c..d2a12df 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -236,13 +236,38 @@ static struct tda18271_std_map mb86a20s_tda18271_std_map 
= {
 
 static struct tda18271_config kworld_tda18271_config = {
.std_map = mb86a20s_tda18271_std_map,
-   .gate= TDA18271_GATE_ANALOG,
+   .gate= TDA18271_GATE_DIGITAL,
 };
 
 static const struct mb86a20s_config kworld_mb86a20s_config = {
.demod_address = 0x10,
 };
 
+static int kworld_sbtvd_gate_ctrl(struct dvb_frontend* fe, int enable)
+{
+   struct saa7134_dev *dev = fe-dvb-priv;
+
+   unsigned char initmsg[] = {0x45, 0x97};
+   unsigned char msg_enable[] = {0x45, 0xc1};
+   unsigned char msg_disable[] = {0x45, 0x81};
+   struct i2c_msg msg = {.addr = 0x4b, .flags = 0, .buf = initmsg, .len = 
2};
+
+   if (i2c_transfer(dev-i2c_adap, msg, 1) != 1) {
+   wprintk(could not access the I2C gate\n);
+   return -EIO;
+   }
+   if (enable)
+   msg.buf = msg_enable;
+   else
+   msg.buf = msg_disable;
+   if (i2c_transfer(dev-i2c_adap, msg, 1) != 1) {
+   wprintk(could not access the I2C gate\n);
+   return -EIO;
+   }
+   msleep(20);
+   return 0;
+}
+
 /* ==
  * tda1004x based DVB-T cards, helper functions
  */
@@ -1639,10 +1664,21 @@ static int dvb_init(struct saa7134_dev *dev)
   kworld_mb86a20s_config,
   dev-i2c_adap);
if (fe0-dvb.frontend != NULL) {
+#if 0
+   dvb_attach(tda829x_attach, fe0-dvb.frontend,
+  dev-i2c_adap, 0x4b,
+  tda829x_no_probe);
+#else
+   dvb_attach(tda829x_attach, fe0-dvb.frontend,
+  dev-i2c_adap, 0x4b, NULL);
+#endif
dvb_attach(tda18271_attach, fe0-dvb.frontend,
   0x60, dev-i2c_adap,
   kworld_tda18271_config);
+   fe0-dvb.frontend-ops.i2c_gate_ctrl = 
kworld_sbtvd_gate_ctrl;
}
+
+   /* mb86a20s need to use the I2C gateway */
break;
default:
wprintk(Huh? unknown DVB card?\n);
-- 
1.7.1


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

[PATCH 5/8] [media] mb86a20s: Be sure that device is initialized before starting DVB

2011-01-15 Thread Mauro Carvalho Chehab 
Due to a hard to track bug between tda829x/tda18271/saa7134, tda829x
wants to go to analog mode during DVB initialization, causing some
I2C errors.

The analog failure doesn't cause any harm, as the device were already
properly initialized in analog mode. However, the failure at the digital
mode causes the frontend mb86a20s to not initialize. Fortunately, at
least on my tests, it was possible to detect that the device is a
mb86a20s before the failure.

What happens is that tda8290 is a very bad boy: during DVB setup, it
keeps insisting to call tda18271 analog_set_params, that calls
tune_agc code. The tune_agc code calls saa7134 driver, changing the
value of GPIO 27, switching from digital to analog mode and disabling
the access to mb86a20s, as, on Kworld SBTVD, the same GPIO used
to switch the hardware AGC mode seems to be used to enable the I2C
switch that allows access to the frontend (mb86a20s).

So, a call to analog_set_params ultimately disables the access to
the frontend, and causes a failure at the init frontend logic.

This patch is a workaround for this issue: it simply checks if the
frontend init had any failure. If so, it will init the frontend when
some DTV application will try to set DVB mode.

Even being a hack for Kworld SBTVD to work, and assumning that we could
teach tda8290 to be a good boy, this is actually an improvement at the
frontend driver, as it will be more reliable to initialization failures.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/dvb/frontends/mb86a20s.c 
b/drivers/media/dvb/frontends/mb86a20s.c
index e06507d..cc4acd2 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -43,6 +43,8 @@ struct mb86a20s_state {
const struct mb86a20s_config *config;
 
struct dvb_frontend frontend;
+
+   bool need_init;
 };
 
 struct regdata {
@@ -382,23 +384,31 @@ static int mb86a20s_initfe(struct dvb_frontend *fe)
/* Initialize the frontend */
rc = mb86a20s_writeregdata(state, mb86a20s_init);
if (rc  0)
-   return rc;
+   goto err;
 
if (!state-config-is_serial) {
regD5 = ~1;
 
rc = mb86a20s_writereg(state, 0x50, 0xd5);
if (rc  0)
-   return rc;
+   goto err;
rc = mb86a20s_writereg(state, 0x51, regD5);
if (rc  0)
-   return rc;
+   goto err;
}
 
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
 
-   return 0;
+err:
+   if (rc  0) {
+   state-need_init = true;
+   printk(KERN_INFO mb86a20s: Init failed. Will try again 
later\n);
+   } else {
+   state-need_init = false;
+   dprintk(Initialization succeded.\n);
+   }
+   return rc;
 }
 
 static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16 
*strength)
@@ -485,8 +495,22 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe,
 
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
+   dprintk(Calling tuner set parameters\n);
fe-ops.tuner_ops.set_params(fe, p);
 
+   /*
+* Make it more reliable: if, for some reason, the initial
+* device initialization doesn't happen, initialize it when
+* a SBTVD parameters are adjusted.
+*
+* Unfortunately, due to a hard to track bug at tda829x/tda18271,
+* the agc callback logic is not called during DVB attach time,
+* causing mb86a20s to not be initialized with Kworld SBTVD.
+* So, this hack is needed, in order to make Kworld SBTVD to work.
+*/
+   if (state-need_init)
+   mb86a20s_initfe(fe);
+
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
rc = mb86a20s_writeregdata(state, mb86a20s_reset_reception);
-- 
1.7.1


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

[PATCH 8/8] [media] saa7134: Kworld SBTVD: make both analog and digital to work

2011-01-15 Thread Mauro Carvalho Chehab 
There are some weird bugs at tda8290/tda18271 initialization, as it
insits do do analog initialization during DVB frontend attach:

DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Fujitsu mb86A20s)...
mb86a20s: mb86a20s_initfe
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer 
returned: -5
tda18271_init: [2-0060|M] error -5 on line 830
tda18271_tune: [2-0060|M] error -5 on line 908
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer 
returned: -5
tda18271c2_rf_tracking_filters_correction: [2-0060|M] error -5 on line 265
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x25, len = 1, i2c_transfer 
returned: -5
tda18271_channel_configuration: [2-0060|M] error -5 on line 119
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
mb86a20s_i2c_writereg: writereg error (rc == -5, reg == 0x29, data == 0x33)
mb86a20s: Init failed. Will try again later

The problem is that mb86a20s is only visible if the analog part is disabled.

However, due to a trick at mb86a20s, it will later initialize properly:

mb86a20s: mb86a20s_initfe: Initialization succeded.

This is hacky and ugly. However, I coldn't find any easy way to fix it.
A proper fix would be to have a resource locking schema, used by both
V4L and DVB parts that would block access to analog registers while
digital registers are in use, but this will probably put tda829x into
a dead lock.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/common/tuners/tda8290.c 
b/drivers/media/common/tuners/tda8290.c
index 419d064..bc6a677 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -232,6 +232,7 @@ static void tda8290_set_params(struct dvb_frontend *fe,
tuner_i2c_xfer_send(priv-i2c_props, pll_bw_nom, 2);
}
 
+
tda8290_i2c_bridge(fe, 1);
 
if (fe-ops.tuner_ops.set_analog_params)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c 
b/drivers/media/video/saa7134/saa7134-cards.c
index dea90a1..deb8fcf 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5179,11 +5179,7 @@ struct saa7134_board saa7134_boards[] = {
[SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG] = {
.name   = Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid,
.audio_clock= 0x00187de7,
-#if 0
.tuner_type = TUNER_PHILIPS_TDA8290,
-#else
-   .tuner_type = UNSET,
-#endif
.tuner_addr = ADDR_UNSET,
.radio_type = UNSET,
.radio_addr = ADDR_UNSET,
@@ -6926,10 +6922,17 @@ static inline int 
saa7134_kworld_sbtvd_toggle_agc(struct saa7134_dev *dev,
/* toggle AGC switch through GPIO 27 */
switch (mode) {
case TDA18271_ANALOG:
-   saa7134_set_gpio(dev, 27, 0);
+   saa_writel(SAA7134_GPIO_GPMODE0  2, 0x4000);
+   saa_writel(SAA7134_GPIO_GPSTATUS0  2, 0x4000);
+   msleep(20);
break;
case TDA18271_DIGITAL:
-   saa7134_set_gpio(dev, 27, 1);
+   saa_writel(SAA7134_GPIO_GPMODE0  2, 0x14000);
+   saa_writel(SAA7134_GPIO_GPSTATUS0  2, 0x14000);
+   msleep(20);
+   saa_writel(SAA7134_GPIO_GPMODE0  2, 0x54000);
+   saa_writel(SAA7134_GPIO_GPSTATUS0  2, 0x54000);
+   msleep(30);
break;
default:
return -EINVAL;
@@ -6987,6 +6990,7 @@ static int saa7134_tda8290_callback(struct saa7134_dev 
*dev,
 int saa7134_tuner_callback(void *priv, int component, int command, int arg)
 {
struct saa7134_dev *dev = priv;
+
if (dev != NULL) {
switch (dev-tuner_type) {
case TUNER_PHILIPS_TDA8290:
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c 
b/drivers/media/video/saa7134/saa7134-dvb.c
index d2a12df..f65cad2 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -237,6 +237,8 @@ static struct tda18271_std_map mb86a20s_tda18271_std_map = {
 static struct tda18271_config kworld_tda18271_config = {
.std_map = mb86a20s_tda18271_std_map,
.gate= TDA18271_GATE_DIGITAL,
+   .config  = 3,   /* Use tuner callback for AGC */
+
 };
 
 static const struct mb86a20s_config kworld_mb86a20s_config = {
@@ -1654,24 +1656,16 @@ static int dvb_init(struct saa7134_dev *dev)
}
break;
case SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG:
-   saa_writel(SAA7134_GPIO_GPMODE0  2, 0x14000);
-

[PATCH 0/8] Make both analog and digital modes work with Kworld SBTVD

2011-01-15 Thread Mauro Carvalho Chehab 
This patch fixes saa7134 driver to allow both analog and digital modes
to work. While here, I fixed some issues I saw at tda8290 driver and
on mb82a20s.

The biggest issue I found is a a hard to track bug between 
tda829x/tda18271/saa7134. This series adds a workaround for it, but
we'll need to do some fix at the code, for it to work better.

The issue is that tda829x wants to go to analog mode during DVB 
initialization, causing some I2C errors.

The analog failure doesn't cause any harm, as the device were already
properly initialized in analog mode. However, the failure at the digital
mode causes the frontend mb86a20s to not initialize. Fortunately, at
least on my tests, it was possible to detect that the device is a
mb86a20s before the failure.

What happens is that tda8290 is a very bad boy: during DVB setup, it
keeps insisting to call tda18271 analog_set_params, that calls
tune_agc code. The tune_agc code calls saa7134 driver, changing the
value of GPIO 27, switching from digital to analog mode and disabling
the access to mb86a20s, as, on Kworld SBTVD, the same GPIO used
to switch the hardware AGC mode seems to be used to enable the I2C
switch that allows access to the frontend (mb86a20s).

So, a call to analog_set_params ultimately disables the access to
the frontend, and causes a failure at the init frontend logic.

This patch is a workaround for this issue: it simply checks if the
frontend init had any failure. If so, it will init the frontend when
some DTV application will try to set DVB mode.

Patches that teach good behaviors to tda8290 are welcome, as this guy
should not interrrupt somebody's else talk.

Mauro Carvalho Chehab (8):
  [media] tda8290: Make all read operations atomic
  [media] tda8290: Fix a bug if no tuner is detected
  [media] tda8290: Turn tda829x on before touching at the I2C gate
  [media] mb86a20s: Fix i2c read/write error messages
  [media] mb86a20s: Be sure that device is initialized before starting
DVB
  [media] saa7134: Fix analog mode for Kworld SBTVD
  [media] saa7134: Fix digital mode on Kworld SBTVD
  [media] saa7134: Kworld SBTVD: make both analog and digital to work

 drivers/media/common/tuners/tda8290.c   |  130 +++
 drivers/media/dvb/frontends/mb86a20s.c  |   36 ++--
 drivers/media/video/saa7134/saa7134-cards.c |   51 +++
 drivers/media/video/saa7134/saa7134-dvb.c   |   80 -
 4 files changed, 152 insertions(+), 145 deletions(-)

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

Re: Hauppauge WinTV-HVR-1120 on Unbuntu 10.04

2011-01-15 Thread Albin Kauffmann 
On Tuesday 11 January 2011 14:57:43 mmanzato wrote:
 Same behaviour here. I'm with Mythbuntu 10.10.
 
 TDA10048 firwmare is found in the linux-firmware-nonfree Ubuntu package.
 From what I can see in dmesg it is loaded correctly.
 
 http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1120 says that
 support for this card seems to be broken in recent Linux kernels (does
 that mean in recent V4L drivers?)

Yes. As far as I understand, Linux releases include a stable snapshot of V4L 
and both seem broken :(

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

[cron job] v4l-dvb daily build: WARNINGS

2011-01-15 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:Sat Jan 15 19:00:28 CET 2011
git master:   59365d136d205cc20fe666ca7f89b1c5001b0d5a
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

A linux-media.tar.bz2 archive with the latest media git sources that can be
used with the media_build tree is available here:

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

Rename to linux-media.tar.bz2, put it in the media_build/linux directory,
go to the directory and type 'make untar'.

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

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

Re: [PATCH 2/2] Fix capture issues for non 8-bit per pixel formats

2011-01-15 Thread Guennadi Liakhovetski 
On Wed, 12 Jan 2011, Alberto Panizzo wrote:

 If the camera was set to output formats like RGB565 YUYV or SBGGR10,
 the resulting image was scrambled due to erroneous interpretations of
 horizontal parameter's units.
 
 This patch in fourcc_to_ipu_pix, eliminate also the pixel formats mappings
 that, first are not used within mainline code and second, standing at
 the datasheets, they will not work properly:
 
  The IPU internal bus support only the following data formatting
  (44.1.1.3 Data Flows and Formats):
   1 YUV 4:4:4 or RGB-8 bits per color component
   2 YUV 4:4:4 or RGB-10 bits per color component
   3 Generic data (from sensor to the system memory only)
 
  And format conversions are done:
   - from memory: de-packing from other formats to IPU supported ones

did you mean unpacking (also below)?

   - to memory: packing in the inverse order.
 
  So, assigning a packing/depacking strategy to the IPU for that formats
  will produce a packing to memory and not the inverse.
 
 In the end in mx3_camera_get_formats, is fixed an erroneous debug message
 that try to shows info from an invalid xlate pointer.
 
 Signed-off-by: Alberto Panizzo maramaopercheseimo...@gmail.com
 ---
  drivers/media/video/mx3_camera.c |   66 +
  1 files changed, 51 insertions(+), 15 deletions(-)
 
 diff --git a/drivers/media/video/mx3_camera.c 
 b/drivers/media/video/mx3_camera.c
 index b9cb4a4..6b9d019 100644
 --- a/drivers/media/video/mx3_camera.c
 +++ b/drivers/media/video/mx3_camera.c
 @@ -324,14 +324,10 @@ static enum pixel_fmt fourcc_to_ipu_pix(__u32 fourcc)
  {
   /* Add more formats as need arises and test possibilities appear... */
   switch (fourcc) {
 - case V4L2_PIX_FMT_RGB565:
 - return IPU_PIX_FMT_RGB565;
   case V4L2_PIX_FMT_RGB24:
   return IPU_PIX_FMT_RGB24;
 - case V4L2_PIX_FMT_RGB332:
 - return IPU_PIX_FMT_RGB332;
 - case V4L2_PIX_FMT_YUV422P:
 - return IPU_PIX_FMT_YVU422P;
 + case V4L2_PIX_FMT_UYVY:
 + case V4L2_PIX_FMT_RGB565:
   default:
   return IPU_PIX_FMT_GENERIC;
   }
 @@ -359,9 +355,31 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
  
   /* This is the configuration of one sg-element */
   video-out_pixel_fmt= fourcc_to_ipu_pix(fourcc);
 - video-out_width= icd-user_width;
 - video-out_height   = icd-user_height;
 - video-out_stride   = icd-user_width;
 +
 + if (video-out_pixel_fmt == IPU_PIX_FMT_GENERIC) {
 + /*
 +  * If the IPU DMA channel is configured to transport
 +  * generic 8-bit data, we have to set up correctly the
 +  * geometry parameters upon the current pixel format.
 +  * So, since the DMA horizontal parameters are expressed
 +  * in bytes not pixels, convert these in the right unit.
 +  */
 + int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
 + icd-current_fmt-host_fmt);
 + BUG_ON(bytes_per_line = 0);
 +
 + video-out_width= bytes_per_line;
 + video-out_height   = icd-user_height;
 + video-out_stride   = bytes_per_line;
 + } else {
 + /*
 +  * For IPU known formats the pixel unit will be managed
 +  * successfully by the IPU code
 +  */
 + video-out_width= icd-user_width;
 + video-out_height   = icd-user_height;
 + video-out_stride   = icd-user_width;
 + }
  
  #ifdef DEBUG
   /* helps to see what DMA actually has written */
 @@ -734,18 +752,36 @@ static int mx3_camera_get_formats(struct 
 soc_camera_device *icd, unsigned int id
   if (xlate) {
   xlate-host_fmt = fmt;
   xlate-code = code;
 + dev_dbg(dev, Providing format %c%c%c%c in pass-through mode\n,
 + (fmt-fourcc  (0*8))  0xFF,
 + (fmt-fourcc  (1*8))  0xFF,
 + (fmt-fourcc  (2*8))  0xFF,
 + (fmt-fourcc  (3*8))  0xFF);
   xlate++;
 - dev_dbg(dev, Providing format %x in pass-through mode\n,
 - xlate-host_fmt-fourcc);
   }
  
   return formats;
  }
  
  static void configure_geometry(struct mx3_camera_dev *mx3_cam,
 -unsigned int width, unsigned int height)
 +unsigned int width, unsigned int height,
 +enum v4l2_mbus_pixelcode code)
  {
   u32 ctrl, width_field, height_field;
 + const struct soc_mbus_pixelfmt *fmt;
 +
 + fmt = soc_mbus_get_fmtdesc(code);
 + BUG_ON(!fmt);
 +
 + if (fourcc_to_ipu_pix(fmt-fourcc) == IPU_PIX_FMT_GENERIC) {
 + /*
 +  * As the CSI will be configured to output BAYER, here
 +  * the

Re: [PATCH] hdpvr: enable IR part

2011-01-15 Thread Andy Walls 
On Sat, 2011-01-15 at 00:37 -0500, Jarod Wilson wrote:
 On Jan 14, 2011, at 11:35 PM, Andy Walls wrote:

 Receive with lirc_zilog does actually work slightly better, though its still
 not perfect. Each key press (using irw to watch) always results in at least
 two lines of output, both with sequence number 00 (i.e., two distinct events),
 and holding a button down results in a stream of 00 events. So repeat is
 obviously busted. But I don't see the wackiness that is happening 
 w/ir-kbd-i2c.
 
 Oh, and transmit works too. So this patch and the buffer alloc patch have now
 been formally tested. Unless we go the custom get_key() route inside the hdpvr
 driver, I think the rest of the legwork to make the hdpvr's IR part behave is
 within lirc_zilog and ir-kbd-i2c (both of which I need to spend some more
 time reading over).
 
 
  BTW, a checkpatch and compiler tested lirc_zilog.c is here:
  
  http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8
  
  It should fix all the binding and allocation problems related to
  ir_probe()/ir_remove().  Except I suspect it may leak the Rx poll
  kthread.  That's possibly another bug to add to the list.
  
  Anyway, $DIETY knows if the lirc_zilog module actually still works after
  all my hacks.  Give it a test if you are adventurous.  I won't be able
  to test until tomorrow evening.
 
 I'll try to grab those and give them a test tomorrow, and hey, I've even got
 a baseline to test against now.

I have now confirmed that with all the above patches to lirc_zilog, both
Tx and Rx using an HVR-1600 work.

Time to start cleaning up the less important things I noticed...

Regards,
Andy


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

Hauppauge WinTV-NOVA-HD-S2 with differenct PCI ID

2011-01-15 Thread benefici 
Hi,

I've bought a Hauppauge WinTV-NOVA-HD-S2 card, which theoretically
should be supported in the stock Linux kernel since version 2.6.28. However, 
my card is not detected, there are apparently no kernel modules loaded for 
the card and no message appears in dmesg during booting. I tried the card 
under both openSUSE 11.2 and 11.3, with identical results. The card is listed 
by lspci as:

# lspci -vnn -s 01:07
01:07.0 Multimedia video controller [0400]: Conexant Systems, Inc. Device 
[14f1:0800] (rev 05)
        Subsystem: Hauppauge computer works Inc. Device [0070:6906]
        Flags: bus master, medium devsel, latency 32, IRQ 12
        Memory at 2100 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [44] Vital Product Data
        Capabilities: [4c] Power Management version 2

01:07.1 Multimedia controller [0480]: Conexant Systems, Inc. Device 
[14f1:0801] (rev 05)
        Subsystem: Hauppauge computer works Inc. Device [0070:6906]
        Flags: bus master, medium devsel, latency 32, IRQ 12
        Memory at 2200 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] Power Management version 2

01:07.2 Multimedia controller [0480]: Conexant Systems, Inc. Device 
[14f1:0802] (rev 05)
        Subsystem: Hauppauge computer works Inc. Device [0070:6906]
        Flags: bus master, medium devsel, latency 32, IRQ 12
        Memory at 2300 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] Power Management version 2

01:07.4 Multimedia controller [0480]: Conexant Systems, Inc. Device 
[14f1:0804] (rev 05)
        Subsystem: Hauppauge computer works Inc. Device [0070:6906]
        Flags: bus master, medium devsel, latency 32, IRQ 12
        Memory at 2400 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] Power Management version 2

One thing I found suspicious is the PCI ID of the card: 14f1:0800.
Based on http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000
I think this is expected to be 14f1:8800.
As a quick hack, I changed the device id from 0x8800 to 0x0800 in 
cx88/cx88-video.c and in cx88/cx88-reg.h

After this, the card is detected, but the module tveeprom fails:
[4.916902] cx8800 :01:07.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[4.917629] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000
(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
[4.917751] cx88[0]: TV tuner type -1, Radio tuner type -1
[5.083308] tveeprom 1-0050: Huh, no eeprom present (err=-6)?
[5.083390] tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or 
not a Hauppauge eeprom.
[5.083501] cx88[0]: warning: unknown hauppauge model #0
[5.083574] cx88[0]: hauppauge eeprom: model=0
[5.083757] input: cx88 IR (Hauppauge WinTV-HVR400 
as /devices/pci:00/:00:1e.0/:01:07.0/input/input3
[5.083955] cx88[0]/0: found at :01:07.0, rev: 5, irq: 19, latency: 32, 
mmio: 0x2100
[5.084097] IRQ 19/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[5.084233] cx88[0]/0: registered device video0 [v4l2]
[5.084343] cx88[0]/0: registered device vbi0

I found one guy with the same problem on a Mandriva forum (back in April 2009) 
but no solution. Any ideas?

Best regards,
Tom
--
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] hdpvr: enable IR part

2011-01-15 Thread Andy Walls 
On Sat, 2011-01-15 at 01:56 -0500, Jarod Wilson wrote:
 On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote:

  Registered IR keymap rc-hauppauge-new
  input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
  rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
  ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD 
  PVR I2C]

 Okay, last spam before I head off to bed... :)
 
 I can get ir-kbd-i2c behavior to pretty much match lirc_zilog wrt key repeat,
 by simply setting init_data-polling_interval = 260; in hdpvr-i2c.c, which
 matches up with the delay in lirc_zilog. With the 260 interval:

RC-5 has a repetition interval of about 4096/36kHz = 113.8 ms, IIRC.  

Using 260 ms, you are throwing away one repeat from the remote for sure,
maybe two.  Maybe that will help you understand what may be going on.
(I've lost the bubble on hdpvr with ir-kbd-i2c.)

Regards,
Andy

 Event: time 1295072449.490542, -- Report Sync 
 Event: time 1295072453.321206, type 4 (Misc), code 4 (ScanCode), value 15
 Event: time 1295072453.321245, type 1 (Key), code 108 (Down), value 1
 Event: time 1295072453.321252, -- Report Sync 
 Event: time 1295072453.570512, type 1 (Key), code 108 (Down), value 0
 Event: time 1295072453.570544, -- Report Sync 
 Event: time 1295072453.575718, type 4 (Misc), code 4 (ScanCode), value 15
 Event: time 1295072453.575744, type 1 (Key), code 108 (Down), value 1
 Event: time 1295072453.575752, -- Report Sync 
 Event: time 1295072453.816215, type 4 (Misc), code 4 (ScanCode), value 15
 Event: time 1295072454.065515, type 1 (Key), code 108 (Down), value 0
 Event: time 1295072454.065544, -- Report Sync 
 
 Lowering this a bit, I can get split personality, one press will look like
 what I was originally seeing, another will look like the 260 output.
 
 Adding filtering (return 0 if buf[0] != 0x80) doesn't help any.
 
 The final thing I've noticed tonight is that ir-kbd-i2c calls rc_keydown
 using a value of 0 for its 3rd parameter. From rc-main.c:
 
  * @toggle: the toggle value (protocol dependent, if the protocol doesn't
  *  support toggle values, this should be set to zero)
 
 Well, in this case, the protocol *does* use a toggle, so that's probably
 something that could use fixing. Not sure it actually has anything to do with
 the odd repeats I'm seeing. Okay, wasn't too much work to pass along toggle
 values too, but it didn't help any.
 
 I'll sleep on 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: [PATCH] hdpvr: enable IR part

2011-01-15 Thread Jarod Wilson 
On Jan 15, 2011, at 4:56 PM, Andy Walls wrote:

 On Sat, 2011-01-15 at 01:56 -0500, Jarod Wilson wrote:
 On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote:
 
 Registered IR keymap rc-hauppauge-new
 input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
 rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
 ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD 
 PVR I2C]
 
 Okay, last spam before I head off to bed... :)
 
 I can get ir-kbd-i2c behavior to pretty much match lirc_zilog wrt key repeat,
 by simply setting init_data-polling_interval = 260; in hdpvr-i2c.c, which
 matches up with the delay in lirc_zilog. With the 260 interval:
 
 RC-5 has a repetition interval of about 4096/36kHz = 113.8 ms, IIRC.  
 
 Using 260 ms, you are throwing away one repeat from the remote for sure,
 maybe two.

Yep. From lirc_zilog:

/*
 * This is ~113*2 + 24 + jitter (2*repeat gap +
 * code length).  We use this interval as the chip
 * resets every time you poll it (bad!).  This is
 * therefore just sufficient to catch all of the
 * button presses.  It makes the remote much more
 * responsive.  You can see the difference by
 * running irw and holding down a button.  With
 * 100ms, the old polling interval, you'll notice
 * breaks in the repeat sequence corresponding to
 * lost keypresses.
 */

But as noted previously, even that doesn't result in correct behavior from
lircd/irw's standpoint.


 Maybe that will help you understand what may be going on.
 (I've lost the bubble on hdpvr with ir-kbd-i2c.)

Not yet. After reading that comment in the code, I'd actually though that
something in the 113 to 130 range might actually be the ticket. I still
think that's probably correct, but it didn't make the wacky repeats stop,
so I think I need to instrument lirc_zilog and/or ir-kbd-i2c a bit more to
get a better idea what's going on.

Oh, and while drifting off to sleep last night, I think I came upon an
explanation for why things behave as they do with that 260ms interval. The
rc_keydown() call has an automatic key release after 250ms.


-- 
Jarod Wilson
ja...@wilsonet.com



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

[PATCH][BUG FIX for 2.6.38] DM04/QQBOX memcpy to const char fix.

2011-01-15 Thread Malcolm Priestley 
Driver Version v1.75
Kernel oops appears in 2.6.37-rc8 in lme_firmware_switch because of a memcpy to 
a const char.

Signed-off-by: Malcolm Priestley tvbox...@gmail.com





diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c 
b/drivers/media/dvb/dvb-usb/lmedm04.c
index 9eea418..46ccd01 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -659,7 +659,7 @@ static int lme2510_download_firmware(struct usb_device *dev,
 }
 
 /* Default firmware for LME2510C */
-const char lme_firmware[50] = dvb-usb-lme2510c-s7395.fw;
+char lme_firmware[50] = dvb-usb-lme2510c-s7395.fw;
 
 static void lme_coldreset(struct usb_device *dev)
 {
@@ -1006,7 +1006,7 @@ static struct dvb_usb_device_properties 
lme2510c_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
.download_firmware = lme2510_download_firmware,
-   .firmware = lme_firmware,
+   .firmware = (const char *)lme_firmware,
.size_of_priv = sizeof(struct lme2510_state),
.num_adapters = 1,
.adapter = {
@@ -1109,5 +1109,5 @@ module_exit(lme2510_module_exit);
 
 MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
 MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0);
-MODULE_VERSION(1.74);
+MODULE_VERSION(1.75);
 MODULE_LICENSE(GPL);

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

[RFC PATCH] ir-kbd-i2c, lirc_zilog: Allow bridge drivers to pass an IR trasnceiver mutex to I2C IR modules

2011-01-15 Thread Andy Walls 
The following patch allows bridge drivers, with an I2C IR Tx/Rx
transceiver, to pass a mutex for serializing access to a single I2C IR
chip between separate IR Tx and Rx modules.

The change modifies struct IR_i2c_init_data and struct IR_i2c to add

struct mutex *transceiver_lock

that ir-kbd-i2c and lirc_zilog will use, if provided by the bridge
driver.  The changes to ir-kbd-i2c.[ch] and lirc_zilog.c provide the
functional change in the patch.

This patch also modifies cx18, ivtv, and hdpvr (sans Jarrod's recent
patches) to provide a transceiver_lock mutex to ir-kbd-i2c and
lirc_zilog.

I skimmed all the other modules that use IR_i2c_init_data. They all
appear to zero-fill the init_data properly before handing the data over
to ir-kbd-i2c.c.  

I did find that pvrusb2 IR Rx for address 0x71 was broken, due to my
recommendation to remove automatic config for address 0x71 from
ir-kbd-i2c.c.  I'll fix that in another patch, if someone with a pvrusb2
device doesn't beat me to it.

So without further ado...


diff --git a/drivers/media/video/cx18/cx18-driver.c 
b/drivers/media/video/cx18/cx18-driver.c
index 676e5be..da1ef93 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -701,6 +701,7 @@ static int __devinit cx18_init_struct1(struct cx18 *cx)
 
mutex_init(cx-serialize_lock);
mutex_init(cx-gpio_lock);
+   mutex_init(cx-ir_transceiver_lock);
mutex_init(cx-epu2apu_mb_lock);
mutex_init(cx-epu2cpu_mb_lock);
 
diff --git a/drivers/media/video/cx18/cx18-driver.h 
b/drivers/media/video/cx18/cx18-driver.h
index f6f3e50..82dc747 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -626,6 +626,7 @@ struct cx18 {
struct cx18_i2c_algo_callback_data i2c_algo_cb_data[2];
 
struct IR_i2c_init_data ir_i2c_init_data;
+   struct mutex ir_transceiver_lock;
 
/* gpio */
u32 gpio_dir;
diff --git a/drivers/media/video/cx18/cx18-i2c.c 
b/drivers/media/video/cx18/cx18-i2c.c
index c330fb9..7782de1 100644
--- a/drivers/media/video/cx18/cx18-i2c.c
+++ b/drivers/media/video/cx18/cx18-i2c.c
@@ -96,10 +96,12 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct 
i2c_adapter *adap, u32 hw,
/* Our default information for ir-kbd-i2c.c to use */
switch (hw) {
case CX18_HW_Z8F0811_IR_RX_HAUP:
+   case CX18_HW_Z8F0811_IR_TX_HAUP:
init_data-ir_codes = RC_MAP_HAUPPAUGE_NEW;
init_data-internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
init_data-type = RC_TYPE_RC5;
init_data-name = cx-card_name;
+   init_data-transceiver_lock = cx-ir_transceiver_lock;
info.platform_data = init_data;
break;
}
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c 
b/drivers/media/video/hdpvr/hdpvr-core.c
index f7d1ee5..df4a02a 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -304,6 +304,7 @@ static int hdpvr_probe(struct usb_interface *interface,
 
mutex_init(dev-io_mutex);
mutex_init(dev-i2c_mutex);
+   mutex_init(dev-ir_transceiver_mutex);
mutex_init(dev-usbc_mutex);
dev-usbc_buf = kmalloc(64, GFP_KERNEL);
if (!dev-usbc_buf) {
diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c 
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..b1e68b8 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -48,13 +48,15 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, 
struct i2c_adapter *adap,
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, type, I2C_NAME_SIZE);
 
-   /* Our default information for ir-kbd-i2c.c to use */
+   /* Our default information for ir-kbd-i2c.c and lirc_zilog.c to use */
switch (addr) {
case Z8F0811_IR_RX_I2C_ADDR:
+   case Z8F0811_IR_TX_I2C_ADDR:
init_data-ir_codes = RC_MAP_HAUPPAUGE_NEW;
init_data-internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
init_data-type = RC_TYPE_RC5;
init_data-name = HD PVR;
+   init_data-transceiver_lock = dev-ir_transceiver_mutex;
info.platform_data = init_data;
break;
}
diff --git a/drivers/media/video/hdpvr/hdpvr.h 
b/drivers/media/video/hdpvr/hdpvr.h
index 37f1e4c..00c8563 100644
--- a/drivers/media/video/hdpvr/hdpvr.h
+++ b/drivers/media/video/hdpvr/hdpvr.h
@@ -112,6 +112,7 @@ struct hdpvr_device {
 
/* For passing data to ir-kbd-i2c */
struct IR_i2c_init_data ir_i2c_init_data;
+   struct mutex ir_transceiver_mutex;
 
/* usb control transfer buffer and lock */
struct mutexusbc_mutex;
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index c87b6bc..6714e1e 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++