Regression in 4.20 - still present in 5.0-rc6

2019-02-12 Thread Mark Zimmerman 
Greetings:

This is to call your attention to a regression that showed up in kernel 4.20; 
the behavior is still present in 5.0-rc6.

Please look at https://bugzilla.kernel.org/show_bug.cgi?id=202565 for details.

Also, the forum post https://bbs.archlinux.org/viewtopic.php?id=244097 has 
further discussion and references a RedHat bug that may be relevant.

Thank you for your time,
-- Mark Zimmerman

Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-13 Thread Mark Zimmerman 
On Sun, Feb 13, 2011 at 04:26:50PM -0500, Andy Walls wrote:
> On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote:
> > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote:
> > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman  wrote:
> > > > Clearly my previous bisection went astray; I think I have a more
> > > > sensible result this time.
> > > >
> > > > qpc$ git bisect good
> > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
> > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be
> > > > Author: Jean Delvare 
> > > > Date: ? Sun Jul 18 16:52:05 2010 -0300
> > > >
> > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions
> > > >
> > > > ? ?Don't just check for nacks on zero-length transactions. Check on
> > > > ? ?other transactions too.
> > > 
> > > This could be a combination of the xc5000 doing clock stretching and
> > > the cx23885 i2c master not properly implementing clock stretch.  In
> > > the past I've seen i2c masters broken in their handling of clock
> > > stretching where they treat it as a NAK.
> > > 
> > > The xc5000 being one of the few devices that actually does i2c clock
> > > stretching often exposes cases where it is improperly implemented in
> > > the i2c master driver (I've had to fix this with several bridges).
> > > 
> > 
> > Thanks for your insight. I am looking at cx23885-i2c.c and there is no
> > clock stretching logic in i2c_slave_did_ack().  Would this be the
> > right place for it to be?  Can you point me to an example of another
> > driver that does it correctly?  I really don't know what I am doing...
> 
> 
> Mark,
> 
> You don't have much hope of getting that right without the CX23885
> datasheet.
> 
> Let's just get the bad commit reverted and into 2.6.38, and fix what
> used to work for you.  Doing a git bisect is enough work for anyone.
> 
> I'll do a patch to revert the commit and ask it to be pulled for
> 2.6.38-rc-whatever.  I'll be sure to add a
> 
>   Bisected-by: Mark Zimmerman 
> 
> tag to the patch.  (The Linux Kernel devs understand the work involved
> to do a bisection.)
> 
> 
> Later, if I can work up a patch to deal with clock stretching properly,
> I may ask you to test.
> 
Thanks, that would be great. Meanwhile, I have built a 2.6.37 with the
offending commit removed:

git bisect reset
git checkout v2.6.37
git revert 44835f197bf1e3f57464f23dfb239fef06cf89be

and it seems to be working fine using both tuners:

xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
xc5000: firmware read 12401 bytes.
xc5000: firmware uploading...
xc5000: firmware upload complete...
xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
xc5000: firmware read 12401 bytes.
xc5000: firmware uploading...
xc5000: firmware upload complete...

Thanks again
-- Mark

--
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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-13 Thread Mark Zimmerman 
On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote:
> On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman  wrote:
> > Clearly my previous bisection went astray; I think I have a more
> > sensible result this time.
> >
> > qpc$ git bisect good
> > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
> > commit 44835f197bf1e3f57464f23dfb239fef06cf89be
> > Author: Jean Delvare 
> > Date: ? Sun Jul 18 16:52:05 2010 -0300
> >
> > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions
> >
> > ? ?Don't just check for nacks on zero-length transactions. Check on
> > ? ?other transactions too.
> 
> This could be a combination of the xc5000 doing clock stretching and
> the cx23885 i2c master not properly implementing clock stretch.  In
> the past I've seen i2c masters broken in their handling of clock
> stretching where they treat it as a NAK.
> 
> The xc5000 being one of the few devices that actually does i2c clock
> stretching often exposes cases where it is improperly implemented in
> the i2c master driver (I've had to fix this with several bridges).
> 

Thanks for your insight. I am looking at cx23885-i2c.c and there is no
clock stretching logic in i2c_slave_did_ack().  Would this be the
right place for it to be?  Can you point me to an example of another
driver that does it correctly?  I really don't know what I am doing...

-- Mark
--
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

[corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-13 Thread Mark Zimmerman 
On Sat, Feb 12, 2011 at 08:29:54AM -0700, Mark Zimmerman wrote:
> On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> > Greetings:
> > 
> > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
> > which fails to initialize with the latest 2.6.36 kernel. The firmware
> > fails to load due to an i2c failure. A search of the archives indicates
> > that this is not the first time this issue has occurred.
> > 
> > What can I do to help get this problem fixed?
> > 
> > Here is the dmesg from 2.6.35, for the two tuners: 
> > 
> > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > xc5000: firmware read 12401 bytes. 
> > xc5000: firmware uploading... 
> > xc5000: firmware upload complete... 
> > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > xc5000: firmware read 12401 bytes. 
> > xc5000: firmware uploading... 
> > xc5000: firmware upload complete..
> > 
> > and here is what happens with 2.6.36: 
> > 
> > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > xc5000: firmware read 12401 bytes. 
> > xc5000: firmware uploading... 
> > xc5000: I2C write failed (len=3) 
> > xc5000: firmware upload complete... 
> > xc5000: Unable to initialise tuner 
> > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > xc5000: firmware read 12401 bytes. 
> > xc5000: firmware uploading... 
> > xc5000: I2C write failed (len=3) 
> > xc5000: firmware upload complete...
> > 
> 
> I did a git bisect on this and finally reached the end of the line.
> Blah blah blah...
> 
Clearly my previous bisection went astray; I think I have a more
sensible result this time.

qpc$ git bisect good
44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
commit 44835f197bf1e3f57464f23dfb239fef06cf89be
Author: Jean Delvare 
Date:   Sun Jul 18 16:52:05 2010 -0300

V4L/DVB: cx23885: Check for slave nack on all transactions

Don't just check for nacks on zero-length transactions. Check on
other transactions too.

Signed-off-by: Jean Delvare 
Signed-off-by: Andy Walls 
Signed-off-by: Mauro Carvalho Chehab 

:04 04 e48c9f6efc6186800e8d711c05987c0ad9445c09 
1ba37458c6a5fc22d19271f09cde2f336887c616 M  drivers



git bisect start
# good: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35
git bisect good 9fe6206f400646a2322096b56c59891d530e8d51
# bad: [18a87becf85d50e7f3d547f1b7a75108b151374d] V4L/DVB: cx23885: 
i2c_wait_done returns 0 or 1, don't check for < 0 return value
git bisect bad 18a87becf85d50e7f3d547f1b7a75108b151374d
# good: [03da30986793385af57eeca3296253c887b742e6] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect good 03da30986793385af57eeca3296253c887b742e6
# good: [ab69bcd66fb4be64edfc767365cb9eb084961246] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6
git bisect good ab69bcd66fb4be64edfc767365cb9eb084961246
# good: [a57f9a3e811cf1246b394f0cc667c6bc5a52e099] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2
git bisect good a57f9a3e811cf1246b394f0cc667c6bc5a52e099
# good: [9e50ab91d025afc17ca14a1764be2e1d0c24245d] Merge branch 'acpica' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git bisect good 9e50ab91d025afc17ca14a1764be2e1d0c24245d
# good: [d71048e22f47725a5808ea2e4e1e72fa36c1a788] Merge branch 
'omap-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
git bisect good d71048e22f47725a5808ea2e4e1e72fa36c1a788
# good: [4fd6c6bf83cb16321e9902b00e2af79054f4e0d6] Merge branch 'for-linus' of 
git://android.kernel.org/kernel/tegra
git bisect good 4fd6c6bf83cb16321e9902b00e2af79054f4e0d6
# good: [c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33] CRIS: Return something from 
profile write
git bisect good c1c8f558749cbf2a7ed16b6ae6e19a4238b6fa33
# good: [ab11b487402f97975f3ac1eeea09c82f4431481e] Merge branch 'master' into 
for-linus
git bisect good ab11b487402f97975f3ac1eeea09c82f4431481e
# good: [30d4554a02d3ad6f9928767c9f98214775f4dcb2] V4L/DVB: gspca - main: 
Version change
git bisect good 30d4554a02d3ad6f9928767c9f98214775f4dcb2
# good: [6e80cc51b4419ca0f8162024ee2497d7ec8ba31c] V4L/DVB: gspca - sq930x: 
Cleanup source, add comments
git bisect good 6e80cc51b4419ca0f8162024ee2497d7ec8ba31c
# good: [3d217c8656842c77d6f33329a034102157363c8d] V4L/DVB: gspca - vc032x: 
Force main register write at probe time (po)
git bisect good 3d217c8656842c77d6f33329a034102157363c8d
# bad: [44835f197bf1e3f57464f23dfb239fef06cf89be] V4L/DVB: cx23885: Check for 
slave nack on all transactions
git bisect bad 44835f197bf1e3f57464f23dfb239fef06cf89be
# good: [f4acb3c4ccca74f54483

Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-12 Thread Mark Zimmerman 
On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote:
> On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote:
> > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote:
> > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote:
> > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> > > > > Greetings:
> > > > > 
> > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 
> > > > > but
> > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware
> > > > > fails to load due to an i2c failure. A search of the archives 
> > > > > indicates
> > > > > that this is not the first time this issue has occurred.
> > > > > 
> > > > > What can I do to help get this problem fixed?
> > > > > 
> > > > > Here is the dmesg from 2.6.35, for the two tuners: 
> > > > > 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: firmware upload complete... 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: firmware upload complete..
> > > > > 
> > > > > and here is what happens with 2.6.36: 
> > > > > 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: I2C write failed (len=3) 
> > > > > xc5000: firmware upload complete... 
> > > > > xc5000: Unable to initialise tuner 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: I2C write failed (len=3) 
> > > > > xc5000: firmware upload complete...
> > > > > 
> > > > 
> > > > I did a git bisect on this and finally reached the end of the line.
> > > > Here is what it said:
> > > > 
> > > > qpc$ git bisect bad
> > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit
> > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98
> > > > Author: Jarod Wilson 
> > > > Date:   Thu Jul 29 18:20:44 2010 -0300
> > > > 
> > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage
> > > > 
> > > > Fix when CONFIG_MODULES is not enabled:
> > > > 
> > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit 
> > > > declaration of function 'module_refcount'
> > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration 
> > > > of function 'module_refcount'
> > > > drivers/built-in.o: In function `it87_probe':
> > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev'
> > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev'
> > > > drivers/built-in.o: In function `lirc_it87_exit':
> > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to 
> > > > `drop_chrdev'
> > > > 
> > > > Its a quick hack and untested beyond building, since I don't have 
> > > > the
> > > > hardware, but it should do the trick.
> > > > 
> > > > Acked-by: Randy Dunlap 
> > > > Signed-off-by: Jarod Wilson 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > 
> > > > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 
> > > > 49e50945ccf8e1c8567c049908890d2752443b72 M  drivers
> > > 
> > > Hmm.  git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the
> > > commit is completely unrealted.
> > > 
> > > Please try and see if things are good or bad at commit
> > > 18a87becf85d50e7f3d547f1b7a75108b151374d:
> > > 
> > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d
> > > Author: Jean Delvare 
> > > Date:   Sun Jul 18 17:05:17 2010 -0300
> > >

Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-12 Thread Mark Zimmerman 
On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote:
> On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote:
> > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote:
> > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote:
> > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> > > > > Greetings:
> > > > > 
> > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 
> > > > > but
> > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware
> > > > > fails to load due to an i2c failure. A search of the archives 
> > > > > indicates
> > > > > that this is not the first time this issue has occurred.
> > > > > 
> > > > > What can I do to help get this problem fixed?
> > > > > 
> > > > > Here is the dmesg from 2.6.35, for the two tuners: 
> > > > > 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: firmware upload complete... 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: firmware upload complete..
> > > > > 
> > > > > and here is what happens with 2.6.36: 
> > > > > 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: I2C write failed (len=3) 
> > > > > xc5000: firmware upload complete... 
> > > > > xc5000: Unable to initialise tuner 
> > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > > > xc5000: firmware read 12401 bytes. 
> > > > > xc5000: firmware uploading... 
> > > > > xc5000: I2C write failed (len=3) 
> > > > > xc5000: firmware upload complete...
> > > > > 
> > > > 
> > > > I did a git bisect on this and finally reached the end of the line.
> > > > Here is what it said:
> > > > 
> > > > qpc$ git bisect bad
> > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit
> > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98
> > > > Author: Jarod Wilson 
> > > > Date:   Thu Jul 29 18:20:44 2010 -0300
> > > > 
> > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage
> > > > 
> > > > Fix when CONFIG_MODULES is not enabled:
> > > > 
> > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit 
> > > > declaration of function 'module_refcount'
> > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration 
> > > > of function 'module_refcount'
> > > > drivers/built-in.o: In function `it87_probe':
> > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev'
> > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev'
> > > > drivers/built-in.o: In function `lirc_it87_exit':
> > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to 
> > > > `drop_chrdev'
> > > > 
> > > > Its a quick hack and untested beyond building, since I don't have 
> > > > the
> > > > hardware, but it should do the trick.
> > > > 
> > > > Acked-by: Randy Dunlap 
> > > > Signed-off-by: Jarod Wilson 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > 
> > > > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 
> > > > 49e50945ccf8e1c8567c049908890d2752443b72 M  drivers
> > > 
> > > Hmm.  git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the
> > > commit is completely unrealted.
> > > 
> > > Please try and see if things are good or bad at commit
> > > 18a87becf85d50e7f3d547f1b7a75108b151374d:
> > > 
> > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d
> > > Author: Jean Delvare 
> > > Date:   Sun Jul 18 17:05:17 2010 -0300
> > >

Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-12 Thread Mark Zimmerman 
On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote:
> On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote:
> > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> > > Greetings:
> > > 
> > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
> > > which fails to initialize with the latest 2.6.36 kernel. The firmware
> > > fails to load due to an i2c failure. A search of the archives indicates
> > > that this is not the first time this issue has occurred.
> > > 
> > > What can I do to help get this problem fixed?
> > > 
> > > Here is the dmesg from 2.6.35, for the two tuners: 
> > > 
> > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > xc5000: firmware read 12401 bytes. 
> > > xc5000: firmware uploading... 
> > > xc5000: firmware upload complete... 
> > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > xc5000: firmware read 12401 bytes. 
> > > xc5000: firmware uploading... 
> > > xc5000: firmware upload complete..
> > > 
> > > and here is what happens with 2.6.36: 
> > > 
> > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > xc5000: firmware read 12401 bytes. 
> > > xc5000: firmware uploading... 
> > > xc5000: I2C write failed (len=3) 
> > > xc5000: firmware upload complete... 
> > > xc5000: Unable to initialise tuner 
> > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> > > xc5000: firmware read 12401 bytes. 
> > > xc5000: firmware uploading... 
> > > xc5000: I2C write failed (len=3) 
> > > xc5000: firmware upload complete...
> > > 
> > 
> > I did a git bisect on this and finally reached the end of the line.
> > Here is what it said:
> > 
> > qpc$ git bisect bad
> > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit
> > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98
> > Author: Jarod Wilson 
> > Date:   Thu Jul 29 18:20:44 2010 -0300
> > 
> > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage
> > 
> > Fix when CONFIG_MODULES is not enabled:
> > 
> > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration 
> > of function 'module_refcount'
> > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of 
> > function 'module_refcount'
> > drivers/built-in.o: In function `it87_probe':
> > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev'
> > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev'
> > drivers/built-in.o: In function `lirc_it87_exit':
> > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev'
> > 
> > Its a quick hack and untested beyond building, since I don't have the
> > hardware, but it should do the trick.
> > 
> > Acked-by: Randy Dunlap 
> > Signed-off-by: Jarod Wilson 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 
> > 49e50945ccf8e1c8567c049908890d2752443b72 M  drivers
> 
> Hmm.  git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the
> commit is completely unrealted.
> 
> Please try and see if things are good or bad at commit
> 18a87becf85d50e7f3d547f1b7a75108b151374d:
> 
> commit 18a87becf85d50e7f3d547f1b7a75108b151374d
> Author: Jean Delvare 
> Date:   Sun Jul 18 17:05:17 2010 -0300
> 
> V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 
> 0 return v
> 
> Function i2c_wait_done() never returns negative values, so there 
> is no
> point in checking for them.
> 
> Signed-off-by: Jean Delvare 
> Signed-off-by: Andy Walls 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> Which is the first commit, prior to the one you found, that seems to me
> to have any direct bearing to I2C transactions.
> 
> If that commit is good, then these commits in between would be my next
> likely suspects:
> e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29
> dbe83a3b921328e12b2abe894fc692afba293d7f
> 
> Regards,
> Andy
> 

Sorry to require so much hand holding, but I am new to all of this git
gymnastics. Would you mind sending me the correct git command to get
to a specific commit? Also, do I need to do a bisect reset?

Thanks,
-- Mark
--
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

[get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed

2011-02-12 Thread Mark Zimmerman 
On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> Greetings:
> 
> I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
> which fails to initialize with the latest 2.6.36 kernel. The firmware
> fails to load due to an i2c failure. A search of the archives indicates
> that this is not the first time this issue has occurred.
> 
> What can I do to help get this problem fixed?
> 
> Here is the dmesg from 2.6.35, for the two tuners: 
> 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: firmware upload complete... 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: firmware upload complete..
> 
> and here is what happens with 2.6.36: 
> 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: I2C write failed (len=3) 
> xc5000: firmware upload complete... 
> xc5000: Unable to initialise tuner 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: I2C write failed (len=3) 
> xc5000: firmware upload complete...
> 

I did a git bisect on this and finally reached the end of the line.
Here is what it said:

qpc$ git bisect bad
82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit
commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98
Author: Jarod Wilson 
Date:   Thu Jul 29 18:20:44 2010 -0300

V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage

Fix when CONFIG_MODULES is not enabled:

drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of 
function 'module_refcount'
drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of 
function 'module_refcount'
drivers/built-in.o: In function `it87_probe':
lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev'
lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev'
drivers/built-in.o: In function `lirc_it87_exit':
lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev'

Its a quick hack and untested beyond building, since I don't have the
hardware, but it should do the trick.

Acked-by: Randy Dunlap 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 

:04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 
49e50945ccf8e1c8567c049908890d2752443b72 M  drivers

--
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: Tuning channels with DViCO FusionHDTV7 Dual Express

2011-02-10 Thread Mark Zimmerman 
On Wed, Feb 09, 2011 at 08:25:32PM -0500, Andy Walls wrote:
> On Tue, 2011-02-08 at 22:41 -0700, Dave Johansen wrote:
> > On Tue, Feb 8, 2011 at 9:51 AM, Dave Johansen  
> > wrote:
> > > On Tue, Feb 8, 2011 at 8:25 AM, Mark Zimmerman  wrote:
> > >> On Mon, Feb 07, 2011 at 06:54:30PM -0500, Andy Walls wrote:
> > >>>
> > >>> You perhaps could
> > >>>
> > >>> A. provide the smallest window of known good vs known bad kernel
> > >>> versions.  Maybe someone with time and hardware can 'git bisect' the
> > >>> issue down to the problem commit.  (I'm guessing this problem might be
> > >>> specific to a particular 64 bit platform IOMMU type, given the bad
> > >>> dma_ops pointer.)
> > >>>
> > >>
> > >> FYI: I am on the process of doing a git bisect (10 kernels to go) to
> > >> track down this problem:
> > >>
> > >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg25342.html
> > >>
> > >> Which may or may not be related to the problem in this thread.
> > >>
> > >
> > > I'm using Mythbuntu 10.10 x64, which I believe uses 2.6.35 but I will
> > > check tonight, so if the issue you're tracking down really is related
> > > to 2.6.36, then I imagine that my problem wouldn't be caused by what
> > > you're looking into. Plus, every time I've looked at dmesg the
> > > firmware has loaded properly, so I'm guessing I'm on 2.6.35 and being
> > > affected by a different issue.
> > >
> > > Thanks for the heads up,
> > > Dave
> > >
> > 
> > So I don't know how useful this is, but I tried Mythbuntu 10.10 x86
> > and it works like a charm. So the issue appears to be isolated to the
> > x64 build. 
> 
> You validated my guess. :)
> 
> 
> > If there's anything I can do to help figure out what the
> > cause of this issue is in the x64 build, then please let me know and
> > I'll do my best to help out.
> 
> So this increases the likelyhood that this is a kernel problem
> introduced outside of the drivers/media directory.
> 
> To find it, someone needs to clone out the kernel with git; start a git
> bisect using the lastest known good and earliest known bad kernel
> versions; and build, install, and test kernels until the problem is
> found, as outlined here:
> 
> http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
> http://manpages.ubuntu.com/manpages/maverick/man1/git-bisect.1.html
> 
> 
> 
> The "build, install and test kernels" step is the pain.  Let's say it
> takes a 2 core AMD64 machine about 17 minutes to build a minimal kernel.
> The number of kernels that need to be tested will be roughly log2(Number
> of commits between known good and bad kernels).  So 30,000 commits will
> require roughly 15 kernel builds to narrow the problem.  If it takes 20
> minutes per iteration, that's 5 hours to find the problem.
> 
> That someone also needs 64 bit hardware and a board supported by the
> cx23885 driver that also exhibits the problem.  I have an HVR-1850 and a
> 64-bit machine, but I haven't tested it yet.  I do not have 5 hours
> free.  Sorry.
> 

The slowest part of the process for me was deciding to start. After
that, the 'install, test, and reboot back into a good kernel' cycle
takes about 10 minutes, then I start the next build and walk away. By
squeezing in one cycle in the morning before leaving for work, and one
or two in the evening, I have gotten this far:

Bisecting: 37 revisions left to test after this (roughly 5 steps)


--
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: Tuning channels with DViCO FusionHDTV7 Dual Express

2011-02-08 Thread Mark Zimmerman 
On Mon, Feb 07, 2011 at 06:54:30PM -0500, Andy Walls wrote:
> 
> You perhaps could 
> 
> A. provide the smallest window of known good vs known bad kernel
> versions.  Maybe someone with time and hardware can 'git bisect' the
> issue down to the problem commit.  (I'm guessing this problem might be
> specific to a particular 64 bit platform IOMMU type, given the bad
> dma_ops pointer.)
> 

FYI: I am on the process of doing a git bisect (10 kernels to go) to
track down this problem:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg25342.html

Which may or may not be related to the problem in this thread. 
--
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: Tuning channels with DViCO FusionHDTV7 Dual Express

2011-02-06 Thread Mark Zimmerman 
On Sun, Feb 06, 2011 at 03:46:59PM -0700, Dave Johansen wrote:
> I am trying to resurrect my MythBuntu system with a DViCO FusionHDTV7
> Dual Express. I had previously had some issues with trying to get
> channels working in MythTV (
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg03846.html
> ), but now it locks up with MythBuntu 10.10 when I scan for channels
> in MythTV and also with the scan command line utility.
> 
> Here's the output from scan:
> 
> scan /usr/share/dvb/atsc/us-ATSC-
> center-frequencies-8VSB
> scanning us-ATSC-center-frequencies-8VSB
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> >>> tune to: 189028615:8VSB
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x1ffb
> 
> Any ideas/suggestions on how I can get this to work?

Check your dmesg to see if yout firmware loads.


--
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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-25 Thread Mark Zimmerman 
On Mon, Jan 24, 2011 at 10:57:02AM -0500, Devin Heitmueller wrote:
> On Mon, Jan 24, 2011 at 10:49 AM, Mark Zimmerman  wrote:
> > From looking at the code and a dump of the firmware file, the first
> > i2c write would have a length of 3; so this error:
> >
> > xc5000: I2C write failed (len=3)
> >
> > tells me that there were probably no successful i2c transactions on
> > this device. The i2c write call looks the same as that in other
> > drivers, so I wonder if there is an initialization step that is now
> > necessary but which is missing.
> >
> > Still hoping for suggestions...
> 
> My guess would be that somebody screwed up either the GPIO config int
> the cx88 board profile, or the i2c gate, which is resulting in not
> being able to reach the tuner at all.
> 
> Do you have an oscilloscope?  If so, I bet you will find that the
> xc5000 pin is being held in reset.

If I had an oscilloscope I probably wouldn't know where to stick the
probe.

> 
> I would probably take a hard look at the board profile in cx88-cards.c
> as well as whether there have been any changes to the GPIO setup and
> power management code.

cx23885-cards.c, actually. I'll see what I can find in there.

Thanks,
-- Mark
--
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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-24 Thread Mark Zimmerman 
On Wed, Jan 19, 2011 at 10:39:46AM -0700, Mark Zimmerman wrote:
> On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote:
> > On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
> >  wrote:
> > >> Can someone please look into this and possibly provide a fix for the
> > >> bug? ??I'm surprised it hasn't happened yet after all this time but
> > >> maybe it's been forgotten the bug existed.
> > >
> > > You shouldn't be too surprised. ??In many cases device support for more
> > > obscure products comes not from the maintainer of the actual driver
> > > but rather from some random user who hacked in an additional board
> > > profile (in many cases, not doing it correctly but good enough so it
> > > "works for them"). ??In cases like that, the changes get committed, the
> > > original submitter disappears, and then when things break there is
> > > nobody with the appropriate knowledge and the hardware to debug the
> > > problem.
> > 
> > Good point.  My understanding is that this is a fairly common card so
> > I wouldn't think that would be the case.  At any rate, hopefully we'll
> > be able to narrow down the cause of the problem and get it fixed.
> > 
> 
> Were there changes to i2c between 2.6.35 and 2.6.36 that are missing
> from the xc5000 driver?  If so, is there another driver that has the
> required updates so I can look at what changed?  I would like to get
> some traction on this but I really don't know where to start.
> 

>From looking at the code and a dump of the firmware file, the first
i2c write would have a length of 3; so this error:

xc5000: I2C write failed (len=3)

tells me that there were probably no successful i2c transactions on
this device. The i2c write call looks the same as that in other
drivers, so I wonder if there is an initialization step that is now
necessary but which is missing.

Still hoping for suggestions...
-- Mark
--
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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-19 Thread Mark Zimmerman 
On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote:
> On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
>  wrote:
> >> Can someone please look into this and possibly provide a fix for the
> >> bug? ??I'm surprised it hasn't happened yet after all this time but
> >> maybe it's been forgotten the bug existed.
> >
> > You shouldn't be too surprised. ??In many cases device support for more
> > obscure products comes not from the maintainer of the actual driver
> > but rather from some random user who hacked in an additional board
> > profile (in many cases, not doing it correctly but good enough so it
> > "works for them"). ??In cases like that, the changes get committed, the
> > original submitter disappears, and then when things break there is
> > nobody with the appropriate knowledge and the hardware to debug the
> > problem.
> 
> Good point.  My understanding is that this is a fairly common card so
> I wouldn't think that would be the case.  At any rate, hopefully we'll
> be able to narrow down the cause of the problem and get it fixed.
> 

Were there changes to i2c between 2.6.35 and 2.6.36 that are missing
from the xc5000 driver?  If so, is there another driver that has the
required updates so I can look at what changed?  I would like to get
some traction on this but I really don't know where to start.

Thanks,
-- Mark
--
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: DViCO FusionHDTV7 Dual Express I2C write failed

2011-01-09 Thread Mark Zimmerman 
On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote:
> Greetings:
> 
> I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
> which fails to initialize with the latest 2.6.36 kernel. The firmware
> fails to load due to an i2c failure. A search of the archives indicates
> that this is not the first time this issue has occurred.
> 
> What can I do to help get this problem fixed?
> 
> Here is the dmesg from 2.6.35, for the two tuners: 
> 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: firmware upload complete... 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: firmware upload complete..
> 
> and here is what happens with 2.6.36: 
> 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: I2C write failed (len=3) 
> xc5000: firmware upload complete... 
> xc5000: Unable to initialise tuner 
> xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
> xc5000: firmware read 12401 bytes. 
> xc5000: firmware uploading... 
> xc5000: I2C write failed (len=3) 
> xc5000: firmware upload complete...
> 

More information about this: I tried 2.6.37 (vanilla source from
kernel.org) and the problem persisted. So, I enabled these options:
CONFIG_I2C_DEBUG_CORE=y 
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
hoping to get more information but this time the firmware loaded
successfully and the tuner works properly.

This leads me to suspect a race condition somewhere, or maybe a
tunable parameter that can be adjusted. The fact that the 'write
failed' message occurs before the 'upload complete' message would tend
to support this. Can anyone suggest something I might try?

-- Mark
--
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

S2API documentation

2011-01-01 Thread Mark Zimmerman 
Greetings:

Is there any sort of documentation yet for S2API? The wiki still
references DVB API 3.2.

-- Mark
--
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: Lost remote after kernel/v4l update cx23885 chipset

2010-12-18 Thread Mark Zimmerman 
For the archives: Working again in 2.6.35


On Sun, Feb 14, 2010 at 02:50:41PM -0700, Mark Zimmerman wrote:
> Greetings:
> 
> I found this <http://www.spinics.net/lists/linux-media/msg15421.html>
> in the archives and I am having the exact same problem. Everything
> worked in 2.6.31. Let me know if there is any testing I could do to
> help solve this.
> 
> -- Mark
> 
> --
> 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

DViCO FusionHDTV7 Dual Express I2C write failed

2010-12-07 Thread Mark Zimmerman 
Greetings:

I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
which fails to initialize with the latest 2.6.36 kernel. The firmware
fails to load due to an i2c failure. A search of the archives indicates
that this is not the first time this issue has occurred.

What can I do to help get this problem fixed?

Here is the dmesg from 2.6.35, for the two tuners: 

xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
xc5000: firmware read 12401 bytes. 
xc5000: firmware uploading... 
xc5000: firmware upload complete... 
xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
xc5000: firmware read 12401 bytes. 
xc5000: firmware uploading... 
xc5000: firmware upload complete..

and here is what happens with 2.6.36: 

xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
xc5000: firmware read 12401 bytes. 
xc5000: firmware uploading... 
xc5000: I2C write failed (len=3) 
xc5000: firmware upload complete... 
xc5000: Unable to initialise tuner 
xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 
xc5000: firmware read 12401 bytes. 
xc5000: firmware uploading... 
xc5000: I2C write failed (len=3) 
xc5000: firmware upload complete...

-- Mark
--
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

Any remotes that work with the pcHDTV HD5500?

2010-02-15 Thread Mark Zimmerman 
Greetings:

The pcHDTV HD5500 ships with an IR receiver but no remote. Support
seems to be there:

input: cx88 IR (pcHDTV HD5500 HDTV) as 
/devices/pci:00/:00:06.0/:01:07.1/input/input6

Does anyone know of a remote that actually works with it? I have read
that it is supposed to be a "Phillips/Magnavox" type, so I tried
setting several programmable remotes to the codes for Phillips and
Magnavox TVs, but nothing has worked so far.

Thanks,
-- Mark
--
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: Lost remote after kernel/v4l update cx23885 chipset

2010-02-14 Thread Mark Zimmerman 
Greetings:

I found this 
in the archives and I am having the exact same problem. Everything
worked in 2.6.31. Let me know if there is any testing I could do to
help solve this.

-- Mark

--
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: TBS 8920 still fails to initialize - cx24116_readreg error

2009-07-29 Thread Mark Zimmerman 
On Thu, Jul 30, 2009 at 01:22:21AM +0300, Igor M. Liplianin wrote:
> On 28  2009 04:21:54 Mark Zimmerman wrote:
> > On Mon, Jul 27, 2009 at 08:50:20PM +0300, Igor M. Liplianin wrote:
> > > On 27 ???? 2009 04:43:16 Mark Zimmerman wrote:
> > > > On Sun, Jul 26, 2009 at 03:29:13PM +0300, Igor M. Liplianin wrote:
> > > > > On 25  2009 05:22:06 Mark Zimmerman wrote:
> > > > > > On Fri, Jul 24, 2009 at 07:06:11PM +0300, Igor M. Liplianin wrote:
> > > > > > > On 24  2009 05:33:15 Mark Zimmerman wrote:
> > > > > > > > Greetings:
> > > > > > > >
> > > > > > > > Using current current v4l-dvb drivers, I get the following in
> > > > > > > > the dmesg:
> > > > > > > >
> > > > > > > > cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2
> > > > > > > > [card=72] cx88[1]/2: cx2388x based DVB/ATSC card
> > > > > > > > cx8802_alloc_frontends() allocating 1 frontend(s)
> > > > > > > > cx24116_readreg: reg=0xff (error=-6)
> > > > > > > > cx24116_readreg: reg=0xfe (error=-6)
> > > > > > > > Invalid probe, probably not a CX24116 device
> > > > > > > > cx88[1]/2: frontend initialization failed
> > > > > > > > cx88[1]/2: dvb_register failed (err = -22)
> > > > > > > > cx88[1]/2: cx8802 probe failed, err = -22
> > > > > > > >
> > > > > > > > Does this mean that one of the chips on this card is different
> > > > > > > > than expected? How can I gather useful information about this?
> > > > > > >
> Please try attached patch against recent v4l-dvb.
> It does matter to set explicitly gpio0 value in cx88_board structure for TBS 
> 8920 card.
> 
> Igor
> 
> 

> # HG changeset patch
> # User Igor M. Liplianin 
> # Date 1248905908 -10800
> # Node ID d2dee95e2da26a145cca2d081be86793cc9b07ea
> # Parent  ee6cf88cb5d3faf861289fce0ef0385846adcc7c
> fix TBS 8920 card support
> 

Looks good now. dmesg follows:

Linux video capture interface: v2.00
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
cx88[0]: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72,autodetected], 
frontend(s): 1
cx88[0]: TV tuner type 4, Radio tuner type -1
input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input5
cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
cx88[0]/2: cx2388x 8802 Driver Manager
  alloc irq_desc for 17 on cpu 0 node 0
  alloc kstat_irqs on cpu 0 node 0
cx88-mpeg driver manager :00:08.2: PCI INT A -> GSI 17 (level, low) -> IRQ 
17
cx88[0]/2: found at :00:08.2, rev: 5, irq: 17, latency: 32, mmio: 0xf900
IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx8800 :00:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx88[0]/0: found at :00:08.0, rev: 5, irq: 17, latency: 32, mmio: 0xfa00
IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88/2: cx2388x dvb driver version 0.0.7 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
cx88[0]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
DVB: registering new adapter (cx88[0])
DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)...

...

cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)...
cx88-mpeg driver manager :00:08.2: firmware: requesting dvb-fe-cx24116.fw
cx24116_firmware_ondemand: Waiting for firmware upload(2)...
cx24116_load_firmware: FW version 1.23.86.1
cx24116_firmware_ondemand: Firmware upload complete

vtest$ ls -laR /dev/dvb
/dev/dvb:
total 0
drwxr-xr-x  3 root root   60 2009-07-29 21:13 .
drwxr-xr-x 18 root root 3480 2009-07-29 21:14 ..
drwxr-xr-x  2 root root  120 2009-07-29 21:13 adapter0

/dev/dvb/adapter0:
total 0
drwxr-xr-x 2 root root 120 2009-07-29 21:13 .
drwxr-xr-x 3 root root  60 2009-07-29 21:13 ..
crw-rw 1 root video 212, 1 2009-07-29 21:13 demux0
crw-rw 1 root video 212, 2 2009-07-29 21:13 dvr0
crw-rw 1 root video 212, 0 2009-07-29 21:13 frontend0
crw-rw 1 root video 212, 3 2009-07-29 21:13 net0

Thank you for working through this.
-- Mark

--
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: TBS 8920 still fails to initialize - cx24116_readreg error

2009-07-27 Thread Mark Zimmerman 
On Mon, Jul 27, 2009 at 08:50:20PM +0300, Igor M. Liplianin wrote:
> On 27  2009 04:43:16 Mark Zimmerman wrote:
> > On Sun, Jul 26, 2009 at 03:29:13PM +0300, Igor M. Liplianin wrote:
> > > On 25 ???? 2009 05:22:06 Mark Zimmerman wrote:
> > > > On Fri, Jul 24, 2009 at 07:06:11PM +0300, Igor M. Liplianin wrote:
> > > > > On 24  2009 05:33:15 Mark Zimmerman wrote:
> > > > > > Greetings:
> > > > > >
> > > > > > Using current current v4l-dvb drivers, I get the following in the
> > > > > > dmesg:
> > > > > >
> > > > > > cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
> > > > > > cx88[1]/2: cx2388x based DVB/ATSC card
> > > > > > cx8802_alloc_frontends() allocating 1 frontend(s)
> > > > > > cx24116_readreg: reg=0xff (error=-6)
> > > > > > cx24116_readreg: reg=0xfe (error=-6)
> > > > > > Invalid probe, probably not a CX24116 device
> > > > > > cx88[1]/2: frontend initialization failed
> > > > > > cx88[1]/2: dvb_register failed (err = -22)
> > > > > > cx88[1]/2: cx8802 probe failed, err = -22
> > > > > >
> > > > > > Does this mean that one of the chips on this card is different than
> > > > > > expected? How can I gather useful information about this?
> > > > >
> > > > > Hi
> > > > > You can try:
> > > > > http://www.tbsdtv.com/download/tbs6920_8920_v23_linux_x86_x64.rar
> > > >
> > > > This code did not compile as-is, but after I commented out some things
> > > > in drivers I do not need, I managed to build something. The TBS card
> > > > now seems to be initialized, but it also broke support for my DViCO
> > > > FusionHDTV7 Dual Express card, which also uses a cx23885.
> > > >
> > > > I am going to move this card to another machine that does not have any
> > > > other capture cards and repeat the process. This should make it easier
> > > > to know what the TBS card/driver is doing.
> > > >
> > > > I am assuming that you are interested in using me to gather
> > > > information to update the v4l-dvb drivers so that this card can be
> > > > supported properly. Is this correct?  Please let me know what I can do
> > > > to assist.
> > >
> > > I've changed tbs 8920 initialization in
> > > http://mercurial.intuxication.org/hg/s2-liplianin. I ask you to try it.
> > > If it works, then I will commit it to linuxv.
> > > Also pay attention to remote.
> >
> > Unfortunately, there appears to be no change:
> >
> > Just for reference, here is how it looks when using the drivers
> > compiled from the source in tbs6920_8920_v23_linux_x86_x64.rar:
> >
> > Also, here are the diffs of cx88-dvb.c between your version and the one
> > from the manufacturer.  I wonder if the magic number writes at line 1142
> > could be what makes it work. I can try adding them to your source if you
> > think it is advisable.
> It is advisable to try.
> I forgot about voltage control. It must preserve that "magic" number.
> 
> http://mercurial.intuxication.org/hg/s2-liplianin/rev/b1ca288a0600 
> 

This was successful.  So that there is no miscommunication, let me
specify exactly what I tested:

I started with

hg clone http://mercurial.intuxication.org/hg/s2-liplianin/rev/b1ca288a0600

and then changed cx88-dvb.c as follows:

diff -r ecdc9c389f8a linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c Mon Jul 27 18:02:25 2009 +0300
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c Mon Jul 27 19:14:53 2009 -0600
@@ -429,15 +429,17 @@
switch (voltage) {
case SEC_VOLTAGE_13:
printk("LNB Voltage SEC_VOLTAGE_13\n");
+   cx_set(MO_GP0_IO, 0x6040);
cx_clear(MO_GP0_IO, 0x0020);
break;
case SEC_VOLTAGE_18:
printk("LNB Voltage SEC_VOLTAGE_18\n");
+   cx_set(MO_GP0_IO, 0x6020);
cx_set(MO_GP0_IO, 0x0020);
break;
case SEC_VOLTAGE_OFF:
+   printk("LNB Voltage SEC_VOLTAGE_off\n");
cx_clear(MO_GP0_IO, 0x0020);
-   printk("LNB Voltage SEC_VOLTAGE_off\n");
break;
}
 
@@ -1144,6 +1146,15 @@
case CX88_BOARD_TBS

Re: TBS 8920 still fails to initialize - cx24116_readreg error

2009-07-26 Thread Mark Zimmerman 
On Sun, Jul 26, 2009 at 03:29:13PM +0300, Igor M. Liplianin wrote:
> On 25  2009 05:22:06 Mark Zimmerman wrote:
> > On Fri, Jul 24, 2009 at 07:06:11PM +0300, Igor M. Liplianin wrote:
> > > On 24 ???? 2009 05:33:15 Mark Zimmerman wrote:
> > > > Greetings:
> > > >
> > > > Using current current v4l-dvb drivers, I get the following in the
> > > > dmesg:
> > > >
> > > > cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
> > > > cx88[1]/2: cx2388x based DVB/ATSC card
> > > > cx8802_alloc_frontends() allocating 1 frontend(s)
> > > > cx24116_readreg: reg=0xff (error=-6)
> > > > cx24116_readreg: reg=0xfe (error=-6)
> > > > Invalid probe, probably not a CX24116 device
> > > > cx88[1]/2: frontend initialization failed
> > > > cx88[1]/2: dvb_register failed (err = -22)
> > > > cx88[1]/2: cx8802 probe failed, err = -22
> > > >
> > > > Does this mean that one of the chips on this card is different than
> > > > expected? How can I gather useful information about this?
> > >
> > > Hi
> > > You can try:
> > > http://www.tbsdtv.com/download/tbs6920_8920_v23_linux_x86_x64.rar
> >
> > This code did not compile as-is, but after I commented out some things
> > in drivers I do not need, I managed to build something. The TBS card
> > now seems to be initialized, but it also broke support for my DViCO
> > FusionHDTV7 Dual Express card, which also uses a cx23885.
> >
> > I am going to move this card to another machine that does not have any
> > other capture cards and repeat the process. This should make it easier
> > to know what the TBS card/driver is doing.
> >
> > I am assuming that you are interested in using me to gather
> > information to update the v4l-dvb drivers so that this card can be
> > supported properly. Is this correct?  Please let me know what I can do
> > to assist.
> I've changed tbs 8920 initialization in 
> http://mercurial.intuxication.org/hg/s2-liplianin.
> I ask you to try it.
> If it works, then I will commit it to linuxv.
> Also pay attention to remote.
> 

Unfortunately, there appears to be no change:

cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
cx88[0]: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72,autodetected], 
frontend(s): 1
cx88[0]: TV tuner type 4, Radio tuner type -1
input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input5
cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
input: cx88 IR (TBS 8920 DVB-S/S2) as 
/devices/pci:00/:00:08.2/input/input6
cx88[0]/2: cx2388x 8802 Driver Manager
  alloc irq_desc for 17 on cpu 0 node 0
  alloc kstat_irqs on cpu 0 node 0
cx88-mpeg driver manager :00:08.2: PCI INT A -> GSI 17 (level, low) -> IRQ 
17
cx88[0]/2: found at :00:08.2, rev: 5, irq: 17, latency: 32, mmio: 0xf900
IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx8800 :00:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx88[0]/0: found at :00:08.0, rev: 5, irq: 17, latency: 32, mmio: 0xfa00
IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88/2: cx2388x dvb driver version 0.0.7 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
cx88[0]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
  alloc irq_desc for 22 on cpu 0 node 0
  alloc kstat_irqs on cpu 0 node 0
VIA 82xx Audio :00:11.5: PCI INT C -> Link[ALKC] -> GSI 22 (level, low) -> 
IRQ 22
VIA 82xx Audio :00:11.5: setting latency timer to 64
cx24116_readreg: reg=0xff (error=-6)
cx24116_readreg: reg=0xfe (error=-6)
Invalid probe, probably not a CX24116 device
cx88[0]/2: frontend initialization failed
cx88[0]/2: dvb_register failed (err = -22)
cx88[0]/2: cx8802 probe failed, err = -22

Just for reference, here is how it looks when using the drivers
compiled from the source in tbs6920_8920_v23_linux_x86_x64.rar:

cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
cx88[0]: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72,autodetected], 
frontend(s): 1
cx88[0]: TV tuner type 4, Radio tuner type -1
input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input5
cx88[0]/2: cx2388x 8802 Driver Manager
  alloc irq_desc for 17 on cpu 0 node 0
  alloc kstat_irqs on cpu 0 node 0
cx88-mpeg driver manager :00:08.2: PCI INT A -> GSI 17 (level, low) -> IRQ 
17
cx88[0]/2: found at :00:08.2, rev: 5, irq: 17, latency: 32,

Re: TBS 8920 still fails to initialize - cx24116_readreg error

2009-07-24 Thread Mark Zimmerman 
On Fri, Jul 24, 2009 at 07:06:11PM +0300, Igor M. Liplianin wrote:
> On 24  2009 05:33:15 Mark Zimmerman wrote:
> > Greetings:
> >
> > Using current current v4l-dvb drivers, I get the following in the
> > dmesg:
> >
> > cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
> > cx88[1]/2: cx2388x based DVB/ATSC card
> > cx8802_alloc_frontends() allocating 1 frontend(s)
> > cx24116_readreg: reg=0xff (error=-6)
> > cx24116_readreg: reg=0xfe (error=-6)
> > Invalid probe, probably not a CX24116 device
> > cx88[1]/2: frontend initialization failed
> > cx88[1]/2: dvb_register failed (err = -22)
> > cx88[1]/2: cx8802 probe failed, err = -22
> >
> > Does this mean that one of the chips on this card is different than
> > expected? How can I gather useful information about this?
> Hi
> You can try:
> http://www.tbsdtv.com/download/tbs6920_8920_v23_linux_x86_x64.rar

This code did not compile as-is, but after I commented out some things
in drivers I do not need, I managed to build something. The TBS card
now seems to be initialized, but it also broke support for my DViCO
FusionHDTV7 Dual Express card, which also uses a cx23885.

I am going to move this card to another machine that does not have any
other capture cards and repeat the process. This should make it easier
to know what the TBS card/driver is doing.

I am assuming that you are interested in using me to gather
information to update the v4l-dvb drivers so that this card can be
supported properly. Is this correct?  Please let me know what I can do
to assist.

-- Mark
--
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

TBS 8920 still fails to initialize - cx24116_readreg error

2009-07-23 Thread Mark Zimmerman 
Greetings:

Using current current v4l-dvb drivers, I get the following in the
dmesg:

cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
cx88[1]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
cx24116_readreg: reg=0xff (error=-6)
cx24116_readreg: reg=0xfe (error=-6)
Invalid probe, probably not a CX24116 device
cx88[1]/2: frontend initialization failed
cx88[1]/2: dvb_register failed (err = -22)
cx88[1]/2: cx8802 probe failed, err = -22

Does this mean that one of the chips on this card is different than
expected? How can I gather useful information about this?

-- Mark

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

TBS 8920 fails to initialize

2009-07-22 Thread Mark Zimmerman 
Greetings:

I am trying out a new TBS 8920 using the 2.6.30 built-in driver and it
fails to initialize. Here are the dmesg lines:

qpc$ dmesg | grep cx88\\[1\\]
cx88[1]: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72,autodetected], 
frontend(s): 1
cx88[1]: TV tuner type 4, Radio tuner type -1
cx88[1]/2: cx2388x 8802 Driver Manager
cx88[1]/2: found at :01:08.2, rev: 5, irq: 16, latency: 32, mmio: 0xf100
IRQ 16/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
cx88[1]/0: found at :01:08.0, rev: 5, irq: 16, latency: 32, mmio: 0xf000
IRQ 16/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
cx88[1]/0: registered device video1 [v4l2]
cx88[1]/0: registered device vbi1
cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
cx88[1]/2: cx2388x based DVB/ATSC card
cx88[1]/2: frontend initialization failed
cx88[1]/2: dvb_register failed (err = -22)
cx88[1]/2: cx8802 probe failed, err = -22

and the lspci -vv:

01:08.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI 
Video and Audio Decoder (rev 05)
Subsystem: Device 8920:
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- http://vger.kernel.org/majordomo-info.html

TBS 8920 DVB-S2 Satellite card

2009-07-12 Thread Mark Zimmerman 
Greetings:

Is the TBS 8920 card supported?  It is not present in the supported
cards list in the wiki, but I saw it mentioned in an article about
S2API.  I just wanted to check before I bought one.

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

Re: [linux-dvb] Fusion HDTV 7 Dual Express

2009-01-22 Thread Mark Zimmerman 
On Thu, Jan 22, 2009 at 02:13:02PM -0800, Tu-Tu Yu wrote:
> Then that means you're getting good signal== 012c (Hex) equal to
> 300(Dec) then that means your snr value is 300/10 = 30 dB
> 

I just got one of these cards and I was noticing the snr values
(generally 300 or 295) as compared to those from my HD5500 (which
reports large numbers that have to be shifted and scaled). The card
works great but I was wondering: Does every driver report SNR in its
own unique way? Is there a standard way to interpret the numbers other
than reading the driver code? Just curious, not flaming...

Also, perhaps OT, the remote is detected:

input: i2c IR (FusionHDTV) as /devices/virtual/input/input6
ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-3/3-006b/ir0 [cx23885[0]]

I noticed the other thread about keytables and was wondering if there
is any testing I could do that might be useful.

-- Mark

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