Re: HVR-900H dvb-t regression(s)

["Fabio M. Di Nitto" <fdinitto@redhat.com>]

On 11/29/2011 12:35 PM, Mauro Carvalho Chehab wrote:
> On 29-11-2011 02:53, Fabio M. Di Nitto wrote:

>>> [ 7867.776612] tm6000: Found Generic tm6010 board
>>> [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
>>> 00 00 00 00 00 00  ................
>> [SNIP]
>>> [ 7869.707769] Device has eeprom but is currently unknown
>>>
>>> and the device will be miss-detected.
>>
>> I don't think this was ever the case, but I can easily check the dmesg
>> output that I collected.
> 
> This may affect your bisect tests.

The eeprom was never 00 all the way.

> 
>>> You can fix it by forcing the driver to use "card=9" via modprobe
>>> option.
>>>
>>> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
>>> audio issue with HVR-900H on analog mode.
>>
>> Ok, I'll try to grab them. It appears that mail relay from linux-media
>> to my inbox is not reliable.
> 
> I've applied them yesterday.

tested them already, I sent the results in another email.

> 
>> As for the analog, I should be able to test it today.
> 
> On the tests I've made yesterday after applying Stefan and my patches,
> analog is working fine. Audio got corrected by the patches for MSC
> (the audio standard used on NTSC and PAL-M). I tested here with both NTSC
> and PAL-M standards, and it worked as expected.
> 
> There are some fixes applied yesterday that are related to DTV. One of them
> fixes the alloc function call used for the DVB streaming buffer inside the
> USB stack:
> 
> - ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
> + ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC);
> 
> The usage of GFP_KERNEL there may fail, causing failures at the DVB stream.
> 
> I'm now seeing if I can make the IR work on HVR-900H.

No luck with analog here, but I need to do more investigation as the
source might be broken all together.

Fabio