Hauppauge WinTV-HVR2205 driver feedback

Hauppauge WinTV-HVR2205 driver feedback

[Stephen Allan]

I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205.  I thought I would post some feedback.  I have recently compiled the driver as at 2015-05-31 using "media build tree".  I am unable to tune a channel.  When running the following w_scan command:

w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf

I get the following error after scanning the frequency range for Australia.

ERROR: Sorry - i couldn't get any working frequency/transponder
 Nothing to scan!!

At the same time I get the following messages being logged to the Linux console.

dmesg
[165512.436662] si2168 22-0066: unknown chip version Si2168-
[165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
[165512.480559] si2157 21-0060: firmware version: 3.0.5
[165517.981155] si2168 22-0064: unknown chip version Si2168-
[165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
[165518.024867] si2157 20-0060: firmware version: 3.0.5
[165682.334171] si2168 22-0064: unknown chip version Si2168-
[165730.579085] si2168 22-0064: unknown chip version Si2168-
[165838.420693] si2168 22-0064: unknown chip version Si2168-
[166337.342437] si2168 22-0064: unknown chip version Si2168-
[167305.393572] si2168 22-0064: unknown chip version Si2168-


Many thanks to the developers for all of your hard work.

Re: Hauppauge WinTV-HVR2205 driver feedback

[Antti Palosaari]

On 06/03/2015 06:55 AM, Stephen Allan wrote:
> I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205.  I thought I would post some feedback.  I have recently compiled the driver as at 2015-05-31 using "media build tree".  I am unable to tune a channel.  When running the following w_scan command:
>
> w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf
>
> I get the following error after scanning the frequency range for Australia.
>
> ERROR: Sorry - i couldn't get any working frequency/transponder
>   Nothing to scan!!
>
> At the same time I get the following messages being logged to the Linux console.
>
> dmesg
> [165512.436662] si2168 22-0066: unknown chip version Si2168-
> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
> [165512.480559] si2157 21-0060: firmware version: 3.0.5
> [165517.981155] si2168 22-0064: unknown chip version Si2168-
> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
> [165518.024867] si2157 20-0060: firmware version: 3.0.5
> [165682.334171] si2168 22-0064: unknown chip version Si2168-
> [165730.579085] si2168 22-0064: unknown chip version Si2168-
> [165838.420693] si2168 22-0064: unknown chip version Si2168-
> [166337.342437] si2168 22-0064: unknown chip version Si2168-
> [167305.393572] si2168 22-0064: unknown chip version Si2168-
>
>
> Many thanks to the developers for all of your hard work.

Let me guess they have changed Si2168 chip to latest "C" version. Driver 
supports only A and B (A20, A30 and B40). I have never seen C version.

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Antti Palosaari]

On 06/03/2015 10:55 AM, Antti Palosaari wrote:
> On 06/03/2015 06:55 AM, Stephen Allan wrote:
>> I am aware that there is some development going on for the saa7164
>> driver to support the Hauppauge WinTV-HVR2205.  I thought I would post
>> some feedback.  I have recently compiled the driver as at 2015-05-31
>> using "media build tree".  I am unable to tune a channel.  When
>> running the following w_scan command:
>>
>> w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf
>>
>> I get the following error after scanning the frequency range for
>> Australia.
>>
>> ERROR: Sorry - i couldn't get any working frequency/transponder
>>   Nothing to scan!!
>>
>> At the same time I get the following messages being logged to the
>> Linux console.
>>
>> dmesg
>> [165512.436662] si2168 22-0066: unknown chip version Si2168-
>> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
>> [165512.480559] si2157 21-0060: firmware version: 3.0.5
>> [165517.981155] si2168 22-0064: unknown chip version Si2168-
>> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
>> [165518.024867] si2157 20-0060: firmware version: 3.0.5
>> [165682.334171] si2168 22-0064: unknown chip version Si2168-
>> [165730.579085] si2168 22-0064: unknown chip version Si2168-
>> [165838.420693] si2168 22-0064: unknown chip version Si2168-
>> [166337.342437] si2168 22-0064: unknown chip version Si2168-
>> [167305.393572] si2168 22-0064: unknown chip version Si2168-
>>
>>
>> Many thanks to the developers for all of your hard work.
>
> Let me guess they have changed Si2168 chip to latest "C" version. Driver
> supports only A and B (A20, A30 and B40). I have never seen C version.

gah, looking the driver I think that is not issue - it will likely print 
"unknown chip version Si2168-C.." on that case already. However, I 
remember I have seen that kind of issue earlier too, but don't remember 
what was actual reason. Probably something to do with firmware, wrong 
firmware and loading has failed? Could you make cold boot, remove socket 
from the wallet and wait minute it really powers down, then boot and 
look what happens.

regards
Antti



-- 
http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Olli Salonen]

I'm seeing the same issue as well. I thought that maybe some recent
Si2168 changes did impact this, but it does not seem to be the case.

I made a quick test myself. I reverted the latest si2168 patches one
by one, but that did not remedy the situation. Anyway, the kernel log
does not seem to indicate that the si2168_cmd_execute itself would
fail (which is what happens after the I2C error handling patch in case
the demod sets the error bit).

olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log
--oneline si2168.c

d4b3830 Revert "[media] si2168: add support for gapped clock"
eb62eb1 Revert "[media] si2168: add I2C error handling"
7adf99d [media] si2168: add I2C error handling
8117a31 [media] si2168: add support for gapped clock
17d4d6a [media] si2168: add support for 1.7MHz bandwidth
683e98b [media] si2168: return error if set_frontend is called with invalid para
c32b281 [media] si2168: change firmware variable name and type
9b7839c [media] si2168: print chip version

dmesg lines when it fails (this is with a card that has worked before):

[66661.336898] saa7164[0]: registered device video0 [mpeg]
[66661.567295] saa7164[0]: registered device video1 [mpeg]
[66661.778660] saa7164[0]: registered device vbi0 [vbi]
[66661.778817] saa7164[0]: registered device vbi1 [vbi]
[66675.175508] si2168:si2168_init: si2168 2-0064:
[66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms
[66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
took 2 ms [OLLI: The result of this I2C cmd must be bogus]
[66675.194110] si2168 2-0064: unknown chip version Si2168-
[66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22
[66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
[66675.242856] si2157 0-0060: firmware version: 3.0.5

Cheers,
-olli

On 3 June 2015 at 10:02, Antti Palosaari <crope@iki.fi> wrote:
> On 06/03/2015 10:55 AM, Antti Palosaari wrote:
>>
>> On 06/03/2015 06:55 AM, Stephen Allan wrote:
>>>
>>> I am aware that there is some development going on for the saa7164
>>> driver to support the Hauppauge WinTV-HVR2205.  I thought I would post
>>> some feedback.  I have recently compiled the driver as at 2015-05-31
>>> using "media build tree".  I am unable to tune a channel.  When
>>> running the following w_scan command:
>>>
>>> w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf
>>>
>>> I get the following error after scanning the frequency range for
>>> Australia.
>>>
>>> ERROR: Sorry - i couldn't get any working frequency/transponder
>>>   Nothing to scan!!
>>>
>>> At the same time I get the following messages being logged to the
>>> Linux console.
>>>
>>> dmesg
>>> [165512.436662] si2168 22-0066: unknown chip version Si2168-
>>> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
>>> [165512.480559] si2157 21-0060: firmware version: 3.0.5
>>> [165517.981155] si2168 22-0064: unknown chip version Si2168-
>>> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
>>> [165518.024867] si2157 20-0060: firmware version: 3.0.5
>>> [165682.334171] si2168 22-0064: unknown chip version Si2168-
>>> [165730.579085] si2168 22-0064: unknown chip version Si2168-
>>> [165838.420693] si2168 22-0064: unknown chip version Si2168-
>>> [166337.342437] si2168 22-0064: unknown chip version Si2168-
>>> [167305.393572] si2168 22-0064: unknown chip version Si2168-
>>>
>>>
>>> Many thanks to the developers for all of your hard work.
>>
>>
>> Let me guess they have changed Si2168 chip to latest "C" version. Driver
>> supports only A and B (A20, A30 and B40). I have never seen C version.
>
>
> gah, looking the driver I think that is not issue - it will likely print
> "unknown chip version Si2168-C.." on that case already. However, I remember
> I have seen that kind of issue earlier too, but don't remember what was
> actual reason. Probably something to do with firmware, wrong firmware and
> loading has failed? Could you make cold boot, remove socket from the wallet
> and wait minute it really powers down, then boot and look what happens.
>
> regards
> Antti
>
>
>
> --
> http://palosaari.fi/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

On Wed, Jun 3, 2015 at 5:29 AM, Olli Salonen <olli.salonen@iki.fi> wrote:
> I'm seeing the same issue as well. I thought that maybe some recent
> Si2168 changes did impact this, but it does not seem to be the case.

We've had a couple of people raise this so its highly likely we have an issue.

I had some patches to the 2168 driver to add support for a new
firmware revision. The last time I tested the HVR2205 I convinced
myself those were not required, thus I discarded those and re-tested.
Probably a warm boot.

If the GPIOs aren't truly resetting the SI2168 and thus a warm boot
didn't flush the firmware, I suspect dropping the patches would have
no immediate effect until a full power-down took place. I'm wondering
whether the testing was invalid and indeed we have a problem in the
field, as well as a GPIO issue. Two potential issues.

I'll schedule sometime later this week to fire up my HVR22xx dev
platform and re-validate the 2205.

Thanks for raising this.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

>> Many thanks to the developers for all of your hard work.
>
>
> Let me guess they have changed Si2168 chip to latest "C" version. Driver
> supports only A and B (A20, A30 and B40). I have never seen C version.

I'll look in detail and report back shortly.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Antti Palosaari]

On 06/03/2015 12:29 PM, Olli Salonen wrote:
> I'm seeing the same issue as well. I thought that maybe some recent
> Si2168 changes did impact this, but it does not seem to be the case.
>
> I made a quick test myself. I reverted the latest si2168 patches one
> by one, but that did not remedy the situation. Anyway, the kernel log
> does not seem to indicate that the si2168_cmd_execute itself would
> fail (which is what happens after the I2C error handling patch in case
> the demod sets the error bit).
>
> olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log
> --oneline si2168.c
>
> d4b3830 Revert "[media] si2168: add support for gapped clock"
> eb62eb1 Revert "[media] si2168: add I2C error handling"
> 7adf99d [media] si2168: add I2C error handling
> 8117a31 [media] si2168: add support for gapped clock
> 17d4d6a [media] si2168: add support for 1.7MHz bandwidth
> 683e98b [media] si2168: return error if set_frontend is called with invalid para
> c32b281 [media] si2168: change firmware variable name and type
> 9b7839c [media] si2168: print chip version
>
> dmesg lines when it fails (this is with a card that has worked before):
>
> [66661.336898] saa7164[0]: registered device video0 [mpeg]
> [66661.567295] saa7164[0]: registered device video1 [mpeg]
> [66661.778660] saa7164[0]: registered device vbi0 [vbi]
> [66661.778817] saa7164[0]: registered device vbi1 [vbi]
> [66675.175508] si2168:si2168_init: si2168 2-0064:
> [66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms
> [66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
> took 2 ms [OLLI: The result of this I2C cmd must be bogus]
> [66675.194110] si2168 2-0064: unknown chip version Si2168-
> [66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22
> [66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
> [66675.242856] si2157 0-0060: firmware version: 3.0.5

Okei, so it has been working earlier... Could you enable I2C debugs to 
see what kind of data that command returns?

What I suspect in first hand is that Windows driver has downloaded 
firmware to chip and linux driver does it again, but with incompatible 
firmware, which leads to situation it starts failing. But if that is 
issue you likely already noted it.

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Olli Salonen]

I cold booted my number cruncher after a hiatus of a couple of weeks,
applied a couple of extra dev_dbg printouts in the si2168_cmd_execute
and installed the newly built module. The results:

[  663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached
[  663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[  663.152436] DVB: registering new adapter (saa7164)
[  663.152441] saa7164 0000:07:00.0: DVB: registering adapter 1
frontend 0 (Silicon Labs Si2168)...
[  678.690104] si2168:si2168_init: si2168 2-0064:
[  678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0
[  678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
12 00 0c 00 0d 16 00 00 00 00 00 00
[  678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1
[  678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
06 01 0f 00 20 20 01
[  678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
[  678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms
[  678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13
[  678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02
[  678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
00 44 34 30 02 00 00 00 00 00 00 00
[  678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms
[  678.708639] si2168 2-0064: unknown chip version Si2168-
[  678.714777] si2168:si2168_init: si2168 2-0064: failed=-22
[  678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
[  678.783587] si2157 0-0060: firmware version: 3.0.5

The answer to the 02 command seems really odd. You can see it is a
Si2168, version 40, but I'd expect the second octet to say 42 instead
of 00.

Cheers,
-olli

On 3 June 2015 at 17:34, Antti Palosaari <crope@iki.fi> wrote:
> On 06/03/2015 12:29 PM, Olli Salonen wrote:
>>
>> I'm seeing the same issue as well. I thought that maybe some recent
>> Si2168 changes did impact this, but it does not seem to be the case.
>>
>> I made a quick test myself. I reverted the latest si2168 patches one
>> by one, but that did not remedy the situation. Anyway, the kernel log
>> does not seem to indicate that the si2168_cmd_execute itself would
>> fail (which is what happens after the I2C error handling patch in case
>> the demod sets the error bit).
>>
>> olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log
>> --oneline si2168.c
>>
>> d4b3830 Revert "[media] si2168: add support for gapped clock"
>> eb62eb1 Revert "[media] si2168: add I2C error handling"
>> 7adf99d [media] si2168: add I2C error handling
>> 8117a31 [media] si2168: add support for gapped clock
>> 17d4d6a [media] si2168: add support for 1.7MHz bandwidth
>> 683e98b [media] si2168: return error if set_frontend is called with
>> invalid para
>> c32b281 [media] si2168: change firmware variable name and type
>> 9b7839c [media] si2168: print chip version
>>
>> dmesg lines when it fails (this is with a card that has worked before):
>>
>> [66661.336898] saa7164[0]: registered device video0 [mpeg]
>> [66661.567295] saa7164[0]: registered device video1 [mpeg]
>> [66661.778660] saa7164[0]: registered device vbi0 [vbi]
>> [66661.778817] saa7164[0]: registered device vbi1 [vbi]
>> [66675.175508] si2168:si2168_init: si2168 2-0064:
>> [66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
>> took 6 ms
>> [66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
>> took 2 ms [OLLI: The result of this I2C cmd must be bogus]
>> [66675.194110] si2168 2-0064: unknown chip version Si2168-
>> [66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22
>> [66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
>> [66675.242856] si2157 0-0060: firmware version: 3.0.5
>
>
> Okei, so it has been working earlier... Could you enable I2C debugs to see
> what kind of data that command returns?
>
> What I suspect in first hand is that Windows driver has downloaded firmware
> to chip and linux driver does it again, but with incompatible firmware,
> which leads to situation it starts failing. But if that is issue you likely
> already noted it.
>
> regards
> Antti
>
> --
> http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Antti Palosaari]

On 06/03/2015 10:08 PM, Olli Salonen wrote:
> I cold booted my number cruncher after a hiatus of a couple of weeks,
> applied a couple of extra dev_dbg printouts in the si2168_cmd_execute
> and installed the newly built module. The results:
>
> [  663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached
> [  663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158
> successfully attached
> [  663.152436] DVB: registering new adapter (saa7164)
> [  663.152441] saa7164 0000:07:00.0: DVB: registering adapter 1
> frontend 0 (Silicon Labs Si2168)...
> [  678.690104] si2168:si2168_init: si2168 2-0064:
> [  678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0
> [  678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
> 12 00 0c 00 0d 16 00 00 00 00 00 00
> [  678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1
> [  678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
> 06 01 0f 00 20 20 01
> [  678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
> [  678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms
> [  678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13
> [  678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02
> [  678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
> 00 44 34 30 02 00 00 00 00 00 00 00
> [  678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms
> [  678.708639] si2168 2-0064: unknown chip version Si2168-
> [  678.714777] si2168:si2168_init: si2168 2-0064: failed=-22
> [  678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
> [  678.783587] si2157 0-0060: firmware version: 3.0.5
>
> The answer to the 02 command seems really odd. You can see it is a
> Si2168, version 40, but I'd expect the second octet to say 42 instead
> of 00.

Yeah, very odd. That byte should be letter A (0x41) or B (0x42) or 
likely C (0x43) in future when current C revision chips are seen.

Are you really sure it has returned (and worked) 0x42 earlier? Have you 
used Windows driver - I speculate if it could make permanent upgrade to 
chip to change it.

Timing issues are also possible. Maybe you could test with some extra 
sleeps, like adding 100ms delay between command request and reply.

Unfortunately value of those 3 bytes are really important as driver 
selects firmware to download according them.

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Peter Faulkner-Ball]

Steven Toth <stoth <at> kernellabs.com> writes:

> 
> >> Many thanks to the developers for all of your hard work.
> >
> >
> > Let me guess they have changed Si2168 chip to latest "C" version. Driver
> > supports only A and B (A20, A30 and B40). I have never seen C version.
> 
> I'll look in detail and report back shortly.
> 

Hi,
I have a working solution (workaround) for the HVR2205/HVR2215 firmware
loading issue.


In the file:

dvb-frontends/si2168.c


change:

#define SI2168_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)


to:

#define SI2168_B40 (68 << 16 | '4' << 8 | '0' << 0)


I do not know why this works, but this is the place where the new chip
is not being detected correctly.

In my case the chip is labelled as: SI2168 40
When the firmware failed to load the error log reported as: si2168-x0040

I hope this is helpful.


I have 2x HVR2215 cards both working for DVB-T on OpenSuse13.2

To get them working, I installed the latest HEAD kernel, downloaded the
media_build tree from LinuxTV, made the change as above, make, make
install, reboot

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

> I have a working solution (workaround) for the HVR2205/HVR2215 firmware
> loading issue.
>
>
> In the file:
>
> dvb-frontends/si2168.c
>
>
> change:
>
> #define SI2168_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
>
>
> to:
>
> #define SI2168_B40 (68 << 16 | '4' << 8 | '0' << 0)
>
>
> I do not know why this works, but this is the place where the new chip
> is not being detected correctly.
>
> In my case the chip is labelled as: SI2168 40
> When the firmware failed to load the error log reported as: si2168-x0040
>
> I hope this is helpful.
>
>
> I have 2x HVR2215 cards both working for DVB-T on OpenSuse13.2

So the hardware is reporting as a 'D' revision, and a prior firmware
is being loaded and its working nicely. Looks like an easy fix to the
2168 driver.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

RE: Hauppauge WinTV-HVR2205 driver feedback

[Stephen Allan]

Hi,

Just thought I'd clarify that in my case I haven't ever used this board with Windows.  See a more detailed dmesg output below for "saa7168" and "si21xx" messages.  From what I am seeing the firmware is loading correctly.  However I may be wrong.

dmesg | grep 'saa7164\|si21'
[   18.112439] saa7164 driver loaded
[   18.113429] CORE saa7164[0]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected]
[   18.113435] saa7164[0]/0: found at 0000:03:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xf7800000
[   18.113470] saa7164 0000:03:00.0: irq 46 for MSI/MSI-X
[   18.270310] saa7164_downloadfirmware() no first image
[   18.270322] saa7164_downloadfirmware() Waiting for firmware upload (NXP7164-2010-03-10.1.fw)
[   20.240635] saa7164_downloadfirmware() firmware read 4019072 bytes.
[   20.240637] saa7164_downloadfirmware() firmware loaded.
[   20.240642] saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072
[   20.240648] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
[   20.240649] saa7164_downloadfirmware() BSLSize = 0x0
[   20.240650] saa7164_downloadfirmware() Reserved = 0x0
[   20.240650] saa7164_downloadfirmware() Version = 0x1661c00
[   27.096269] saa7164_downloadimage() Image downloaded, booting...
[   27.200300] saa7164_downloadimage() Image booted successfully.
[   29.936962] saa7164_downloadimage() Image downloaded, booting...
[   31.705407] saa7164_downloadimage() Image booted successfully.
[   31.750358] saa7164[0]: Hauppauge eeprom: model=151609
[   31.776446] si2168 22-0064: Silicon Labs Si2168 successfully attached
[   31.781307] si2157 20-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
[   31.781695] DVB: registering new adapter (saa7164)
[   31.781698] saa7164 0000:03:00.0: DVB: registering adapter 4 frontend 0 (Silicon Labs Si2168)...
[   31.782652] si2168 22-0066: Silicon Labs Si2168 successfully attached
[   31.785961] si2157 21-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
[   31.786340] DVB: registering new adapter (saa7164)
[   31.786342] saa7164 0000:03:00.0: DVB: registering adapter 5 frontend 0 (Silicon Labs Si2168)...
[   31.786562] saa7164[0]: registered device video1 [mpeg]
[   32.021659] saa7164[0]: registered device video2 [mpeg]
[   32.238336] saa7164[0]: registered device vbi0 [vbi]
[   32.238389] saa7164[0]: registered device vbi1 [vbi]
[165512.436662] si2168 22-0066: unknown chip version Si2168-
[165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
[165512.480559] si2157 21-0060: firmware version: 3.0.5
[165517.981155] si2168 22-0064: unknown chip version Si2168-
[165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
[165518.024867] si2157 20-0060: firmware version: 3.0.5
[165682.334171] si2168 22-0064: unknown chip version Si2168-
[165730.579085] si2168 22-0064: unknown chip version Si2168-
[165838.420693] si2168 22-0064: unknown chip version Si2168-
[166337.342437] si2168 22-0064: unknown chip version Si2168-
[167305.393572] si2168 22-0064: unknown chip version Si2168-
[170762.907071] si2168 22-0064: unknown chip version Si2168-

-----Original Message-----
From: Antti Palosaari [mailto:crope@iki.fi] 
Sent: Wednesday, June 3, 2015 6:03 PM
To: Stephen Allan; linux-media@vger.kernel.org
Subject: Re: Hauppauge WinTV-HVR2205 driver feedback

On 06/03/2015 10:55 AM, Antti Palosaari wrote:
> On 06/03/2015 06:55 AM, Stephen Allan wrote:
>> I am aware that there is some development going on for the saa7164 
>> driver to support the Hauppauge WinTV-HVR2205.  I thought I would 
>> post some feedback.  I have recently compiled the driver as at 
>> 2015-05-31 using "media build tree".  I am unable to tune a channel.  
>> When running the following w_scan command:
>>
>> w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf
>>
>> I get the following error after scanning the frequency range for 
>> Australia.
>>
>> ERROR: Sorry - i couldn't get any working frequency/transponder
>>   Nothing to scan!!
>>
>> At the same time I get the following messages being logged to the 
>> Linux console.
>>
>> dmesg
>> [165512.436662] si2168 22-0066: unknown chip version Si2168- 
>> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
>> [165512.480559] si2157 21-0060: firmware version: 3.0.5 
>> [165517.981155] si2168 22-0064: unknown chip version Si2168- 
>> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
>> [165518.024867] si2157 20-0060: firmware version: 3.0.5 
>> [165682.334171] si2168 22-0064: unknown chip version Si2168- 
>> [165730.579085] si2168 22-0064: unknown chip version Si2168- 
>> [165838.420693] si2168 22-0064: unknown chip version Si2168- 
>> [166337.342437] si2168 22-0064: unknown chip version Si2168- 
>> [167305.393572] si2168 22-0064: unknown chip version Si2168-
>>
>>
>> Many thanks to the developers for all of your hard work.
>
> Let me guess they have changed Si2168 chip to latest "C" version. 
> Driver supports only A and B (A20, A30 and B40). I have never seen C version.

gah, looking the driver I think that is not issue - it will likely print "unknown chip version Si2168-C.." on that case already. However, I remember I have seen that kind of issue earlier too, but don't remember what was actual reason. Probably something to do with firmware, wrong firmware and loading has failed? Could you make cold boot, remove socket from the wallet and wait minute it really powers down, then boot and look what happens.

regards
Antti



--
http://palosaari.fi/

RE: Hauppauge WinTV-HVR2205 driver feedback

[faulkner-ball]

The board has multiple "chips", each of which are detected and 
configured as part of the driver loading.

saa7164
This chip requires firmware which appears to load correctly at 20.240637


si2168
This chip requires firmware
The chip is detected and "loaded" but the chip version is not 
identified, so the firmware load does not occur.
As this is a dual tuner card, there are 2 of these chips.


si2157
this is the actual tuner chip, again there are 2 chips on the card, and 
it does not need to load any firmware.
The firmware version already in the chip is reported at 165512.480559 
and 165518.024867

both of the si21xx chips don't get the firmware loaded until the tuner 
is accessed by an application, so the card appears to be loading 
correctly, but will not tune.


See my other post for a workaround.
I'm sure one of the developers will provide a more elegant/correct 
solution soon.


Regards
Peter


On 04/06/2015 12:38 pm, Stephen Allan wrote:
> Hi,
> 
> Just thought I'd clarify that in my case I haven't ever used this
> board with Windows.  See a more detailed dmesg output below for
> "saa7168" and "si21xx" messages.  From what I am seeing the firmware
> is loading correctly.  However I may be wrong.
> 
> dmesg | grep 'saa7164\|si21'
> [   18.112439] saa7164 driver loaded
> [   18.113429] CORE saa7164[0]: subsystem: 0070:f120, board: Hauppauge
> WinTV-HVR2205 [card=13,autodetected]
> [   18.113435] saa7164[0]/0: found at 0000:03:00.0, rev: 129, irq: 16,
> latency: 0, mmio: 0xf7800000
> [   18.113470] saa7164 0000:03:00.0: irq 46 for MSI/MSI-X
> [   18.270310] saa7164_downloadfirmware() no first image
> [   18.270322] saa7164_downloadfirmware() Waiting for firmware upload
> (NXP7164-2010-03-10.1.fw)
> [   20.240635] saa7164_downloadfirmware() firmware read 4019072 bytes.
> [   20.240637] saa7164_downloadfirmware() firmware loaded.
> [   20.240642] saa7164_downloadfirmware() SecBootLoader.FileSize = 
> 4019072
> [   20.240648] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
> [   20.240649] saa7164_downloadfirmware() BSLSize = 0x0
> [   20.240650] saa7164_downloadfirmware() Reserved = 0x0
> [   20.240650] saa7164_downloadfirmware() Version = 0x1661c00
> [   27.096269] saa7164_downloadimage() Image downloaded, booting...
> [   27.200300] saa7164_downloadimage() Image booted successfully.
> [   29.936962] saa7164_downloadimage() Image downloaded, booting...
> [   31.705407] saa7164_downloadimage() Image booted successfully.
> [   31.750358] saa7164[0]: Hauppauge eeprom: model=151609
> [   31.776446] si2168 22-0064: Silicon Labs Si2168 successfully 
> attached
> [   31.781307] si2157 20-0060: Silicon Labs Si2147/2148/2157/2158
> successfully attached
> [   31.781695] DVB: registering new adapter (saa7164)
> [   31.781698] saa7164 0000:03:00.0: DVB: registering adapter 4
> frontend 0 (Silicon Labs Si2168)...
> [   31.782652] si2168 22-0066: Silicon Labs Si2168 successfully 
> attached
> [   31.785961] si2157 21-0060: Silicon Labs Si2147/2148/2157/2158
> successfully attached
> [   31.786340] DVB: registering new adapter (saa7164)
> [   31.786342] saa7164 0000:03:00.0: DVB: registering adapter 5
> frontend 0 (Silicon Labs Si2168)...
> [   31.786562] saa7164[0]: registered device video1 [mpeg]
> [   32.021659] saa7164[0]: registered device video2 [mpeg]
> [   32.238336] saa7164[0]: registered device vbi0 [vbi]
> [   32.238389] saa7164[0]: registered device vbi1 [vbi]
> [165512.436662] si2168 22-0066: unknown chip version Si2168-
> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
> [165512.480559] si2157 21-0060: firmware version: 3.0.5
> [165517.981155] si2168 22-0064: unknown chip version Si2168-
> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
> [165518.024867] si2157 20-0060: firmware version: 3.0.5
> [165682.334171] si2168 22-0064: unknown chip version Si2168-
> [165730.579085] si2168 22-0064: unknown chip version Si2168-
> [165838.420693] si2168 22-0064: unknown chip version Si2168-
> [166337.342437] si2168 22-0064: unknown chip version Si2168-
> [167305.393572] si2168 22-0064: unknown chip version Si2168-
> [170762.907071] si2168 22-0064: unknown chip version Si2168-
> 
> -----Original Message-----
> From: Antti Palosaari [mailto:crope@iki.fi]
> Sent: Wednesday, June 3, 2015 6:03 PM
> To: Stephen Allan; linux-media@vger.kernel.org
> Subject: Re: Hauppauge WinTV-HVR2205 driver feedback
> 
> On 06/03/2015 10:55 AM, Antti Palosaari wrote:
>> On 06/03/2015 06:55 AM, Stephen Allan wrote:
>>> I am aware that there is some development going on for the saa7164
>>> driver to support the Hauppauge WinTV-HVR2205.  I thought I would
>>> post some feedback.  I have recently compiled the driver as at
>>> 2015-05-31 using "media build tree".  I am unable to tune a channel.
>>> When running the following w_scan command:
>>> 
>>> w_scan -a4 -ft -cAU -t 3 -X > /tmp/tzap/channels.conf
>>> 
>>> I get the following error after scanning the frequency range for
>>> Australia.
>>> 
>>> ERROR: Sorry - i couldn't get any working frequency/transponder
>>>   Nothing to scan!!
>>> 
>>> At the same time I get the following messages being logged to the
>>> Linux console.
>>> 
>>> dmesg
>>> [165512.436662] si2168 22-0066: unknown chip version Si2168-
>>> [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30'
>>> [165512.480559] si2157 21-0060: firmware version: 3.0.5
>>> [165517.981155] si2168 22-0064: unknown chip version Si2168-
>>> [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30'
>>> [165518.024867] si2157 20-0060: firmware version: 3.0.5
>>> [165682.334171] si2168 22-0064: unknown chip version Si2168-
>>> [165730.579085] si2168 22-0064: unknown chip version Si2168-
>>> [165838.420693] si2168 22-0064: unknown chip version Si2168-
>>> [166337.342437] si2168 22-0064: unknown chip version Si2168-
>>> [167305.393572] si2168 22-0064: unknown chip version Si2168-
>>> 
>>> 
>>> Many thanks to the developers for all of your hard work.
>> 
>> Let me guess they have changed Si2168 chip to latest "C" version.
>> Driver supports only A and B (A20, A30 and B40). I have never seen C 
>> version.
> 
> gah, looking the driver I think that is not issue - it will likely
> print "unknown chip version Si2168-C.." on that case already. However,
> I remember I have seen that kind of issue earlier too, but don't
> remember what was actual reason. Probably something to do with
> firmware, wrong firmware and loading has failed? Could you make cold
> boot, remove socket from the wallet and wait minute it really powers
> down, then boot and look what happens.
> 
> regards
> Antti
> 
> 
> 
> --
> http://palosaari.fi/
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{���b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w����+zf���h���~����i���z�\x1e�w���?����&�)ߢ

Re: Hauppauge WinTV-HVR2205 driver feedback

[Olli Salonen]

My card has been always installed in a machine that does not have
Windows, so any interference with the Windows driver should not be an
issue. I found some old console logs from February 21 when I was
trying to put together a driver for the board. It shows that the
Si2168 chip on my board was at that time correctly detected as
Si2168-B40 by the si2168 driver and the 4.0.11 firmware was loaded ok.

[   28.646668] DVB: registering new adapter (saa7164)
[   28.646671] saa7164 0000:07:00.0: DVB: registering adapter 1
frontend 0 (Silicon Labs Si2168)...
[   28.648633] i2c i2c-4: Added multiplexed i2c bus 6
[   28.648638] si2168 4-0066: Silicon Labs Si2168 successfully attached
[   28.658000] si2157 6-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[   28.658439] DVB: registering new adapter (saa7164)
[   28.658442] saa7164 0000:07:00.0: DVB: registering adapter 2
frontend 0 (Silicon Labs Si2168)...
[   28.732812] init: plymouth-splash main process (1305) terminated
with status 1
[   35.214858] random: nonblocking pool is initialized
[  582.391928] si2168 3-0064: found a 'Silicon Labs Si2168-B40'
[  582.392289] si2168 3-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
[  584.946560] si2168 3-0064: firmware version: 4.0.11
[  584.984386] si2157 5-0060: found a 'Silicon Labs Si2157-A30'
[  585.058396] si2157 5-0060: firmware version: 3.0.5

I have some w_scan logs from that day that show that the card was
indeed working.

Cheers,
-olli


On 3 June 2015 at 21:46, Antti Palosaari <crope@iki.fi> wrote:
> On 06/03/2015 10:08 PM, Olli Salonen wrote:
>>
>> I cold booted my number cruncher after a hiatus of a couple of weeks,
>> applied a couple of extra dev_dbg printouts in the si2168_cmd_execute
>> and installed the newly built module. The results:
>>
>> [  663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached
>> [  663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158
>> successfully attached
>> [  663.152436] DVB: registering new adapter (saa7164)
>> [  663.152441] saa7164 0000:07:00.0: DVB: registering adapter 1
>> frontend 0 (Silicon Labs Si2168)...
>> [  678.690104] si2168:si2168_init: si2168 2-0064:
>> [  678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0
>> [  678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
>> 12 00 0c 00 0d 16 00 00 00 00 00 00
>> [  678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1
>> [  678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
>> 06 01 0f 00 20 20 01
>> [  678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
>> [  678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
>> took 6 ms
>> [  678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13
>> [  678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02
>> [  678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
>> 00 44 34 30 02 00 00 00 00 00 00 00
>> [  678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution
>> took 2 ms
>> [  678.708639] si2168 2-0064: unknown chip version Si2168-
>> [  678.714777] si2168:si2168_init: si2168 2-0064: failed=-22
>> [  678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
>> [  678.783587] si2157 0-0060: firmware version: 3.0.5
>>
>> The answer to the 02 command seems really odd. You can see it is a
>> Si2168, version 40, but I'd expect the second octet to say 42 instead
>> of 00.
>
>
> Yeah, very odd. That byte should be letter A (0x41) or B (0x42) or likely C
> (0x43) in future when current C revision chips are seen.
>
> Are you really sure it has returned (and worked) 0x42 earlier? Have you used
> Windows driver - I speculate if it could make permanent upgrade to chip to
> change it.
>
> Timing issues are also possible. Maybe you could test with some extra
> sleeps, like adding 100ms delay between command request and reply.
>
> Unfortunately value of those 3 bytes are really important as driver selects
> firmware to download according them.
>
> regards
> Antti
>
> --
> http://palosaari.fi/

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

> If the GPIOs aren't truly resetting the SI2168 and thus a warm boot
> didn't flush the firmware, I suspect dropping the patches would have
> no immediate effect until a full power-down took place. I'm wondering
> whether the testing was invalid and indeed we have a problem in the
> field, as well as a GPIO issue. Two potential issues.
>
> I'll schedule sometime later this week to fire up my HVR22xx dev
> platform and re-validate the 2205.

For the record, here's what happened.

1. The GPIO is working correctly, I've validated this with a meter.
This wasn't a warm vs cold boot issue, or in any way Windows related.
2. I have multiple HVR22x5 cards. a HVR2205 and a HVR2215. The HVR2215
I obtained much later after prompting my Olli, it has a newer build
date stamped on the demodulators and reports a newer chip version.
These newer demods are not recognized by the current tip, the prior
ones are.

The solution was to patch the SI2168 to recognize the newer demodulator version.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Tycho Lürsen]

Op 11-10-15 om 08:18 schreef Richard Tresidder:
> Hi Again
>   Yep that fixed pulling in the saa7164: si2168 frontends:
>
> [ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16
> [ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached
> [ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158
> successfully attached
> [ 6778.597229] DVB: registering new adapter (saa7164)
> YAY!!
Bottoms up!
>
> What a painful process... first time I built the kernel from the rpm
> source I must have stuffed something up and the resultant installed
> rpm didn't have the module turned on.. aaarrrrggghhhhh...
> Trying to rebuild the srpm again after tweaking the .config file and
> copying it around to the various locations again just didn't work..
> Eventually gave up and had to rip it all out and start afresh..
It's not that hard once you get the hang of it. I had to recompile 
anyway, as I need saa716x, dvbloopback and backported drivers for DVBSky 
T982, plus I need more then 8 dvb adapters. Semi-automated this of course:
https://github.com/bas-t/centos7-kernel
>
> Well spotted on that one.. What a pain that the call to the i2c mux
> create didn't result in a error :/
>
> Now I just need to shutoff kernel updates..
> Really need to push this up into the centos config.. I've noted that
> it has been turned back on in other releases..
> Will submit a bug.
Excellent idea. But as stated, I'll have to recompile anyway...
>
> Regards
>    Richard Tresidder
>
> On 05/10/15 20:45, Tycho Lürsen wrote:
>> Hi, not sure if this is related.
>> I had to recompile the centos7 stock kernel with:
>> CONFIG_I2C_MUX=m
>>
>> It was not enabled in the kernel config.
>>
>> Op 04-10-15 om 06:55 schreef Richard Tresidder:
>>> Sorry If I've posted this to the wrong section my first attempt..
>>>
>>> Hi
>>>    I'm attempting to get an HVR2205 up and going.
>>> CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge
>>> WinTV-HVR2205 [card=13,autodetected]
>>> Distribution is CentOS7 so I've pulled the v4l from media_build.git
>>> Had to change a couple of things..  and another macro issue
>>> regarding clamp() ..
>>> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was
>>> failing..
>>> kept getting:  kernel: modprobe: page allocation failure: order:10,
>>> mode:0x10c0d0
>>> Have plenty of RAM free so surprised about that one.. tried some of
>>> the tricks re increasing the vm.min_free_kbytes etc..
>>>
>>> Any way I modified the routine to only allocate a single chunk
>>> buffer based on dstsize and tweaked the chunk handling code..
>>> seemed to fix that one.. fw downloaded and seemed to boot ok..
>>>
>>> Next I'm running into a problem with the saa7164_dvb_register()
>>> stage...
>>>
>>> saa7164[1]: Hauppauge eeprom: model=151609
>>> saa7164_dvb_register() Frontend/I2C initialization failed
>>> saa7164_initdev() Failed to register dvb adapters on porta
>>>
>>> I added some extra debug and identified that
>>> client_demod->dev.driver is null..
>>>
>>> However I'm now stuck as to what to tackle next..
>>>
>>> I can provide more info, just didn't want to spam the list for my
>>> first email..
>>>
>>> Regards
>>>    Richard Tresidder
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Hi Again
   Yep that fixed pulling in the saa7164: si2168 frontends:

[ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16
[ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached
[ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158 
successfully attached
[ 6778.597229] DVB: registering new adapter (saa7164)
YAY!!

What a painful process... first time I built the kernel from the rpm 
source I must have stuffed something up and the resultant installed rpm 
didn't have the module turned on.. aaarrrrggghhhhh...
Trying to rebuild the srpm again after tweaking the .config file and 
copying it around to the various locations again just didn't work.. 
Eventually gave up and had to rip it all out and start afresh..

Well spotted on that one.. What a pain that the call to the i2c mux 
create didn't result in a error :/

Now I just need to shutoff kernel updates..
Really need to push this up into the centos config.. I've noted that it 
has been turned back on in other releases..
Will submit a bug.

Regards
    Richard Tresidder

On 05/10/15 20:45, Tycho Lürsen wrote:
> Hi, not sure if this is related.
> I had to recompile the centos7 stock kernel with:
> CONFIG_I2C_MUX=m
>
> It was not enabled in the kernel config.
>
> Op 04-10-15 om 06:55 schreef Richard Tresidder:
>> Sorry If I've posted this to the wrong section my first attempt..
>>
>> Hi
>>    I'm attempting to get an HVR2205 up and going.
>> CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
>> [card=13,autodetected]
>> Distribution is CentOS7 so I've pulled the v4l from media_build.git
>> Had to change a couple of things..  and another macro issue regarding 
>> clamp() ..
>> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was 
>> failing..
>> kept getting:  kernel: modprobe: page allocation failure: order:10, 
>> mode:0x10c0d0
>> Have plenty of RAM free so surprised about that one.. tried some of 
>> the tricks re increasing the vm.min_free_kbytes etc..
>>
>> Any way I modified the routine to only allocate a single chunk buffer 
>> based on dstsize and tweaked the chunk handling code..
>> seemed to fix that one.. fw downloaded and seemed to boot ok..
>>
>> Next I'm running into a problem with the saa7164_dvb_register() stage...
>>
>> saa7164[1]: Hauppauge eeprom: model=151609
>> saa7164_dvb_register() Frontend/I2C initialization failed
>> saa7164_initdev() Failed to register dvb adapters on porta
>>
>> I added some extra debug and identified that client_demod->dev.driver 
>> is null..
>>
>> However I'm now stuck as to what to tackle next..
>>
>> I can provide more info, just didn't want to spam the list for my 
>> first email..
>>
>> Regards
>>    Richard Tresidder
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Sigh again

Did a module only build for the i2c-mux and got it into the currently 
running kernel with a force to bypass the no symbol version for 
module_layout error.. figured it was safe enough given it was the 
identical kernel config etc from the centos vault...

Anyway still failed.. though the module seemed to install and is showing 
with lsmod no dmesg barfs..
I'll try a full kernel build tomorrow..

Regards
   Richard Tresidder



On 05/10/15 20:45, Tycho Lürsen wrote:
> Hi, not sure if this is related.
> I had to recompile the centos7 stock kernel with:
> CONFIG_I2C_MUX=m
>
> It was not enabled in the kernel config.
>
> Op 04-10-15 om 06:55 schreef Richard Tresidder:
>> Sorry If I've posted this to the wrong section my first attempt..
>>
>> Hi
>>    I'm attempting to get an HVR2205 up and going.
>> CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
>> [card=13,autodetected]
>> Distribution is CentOS7 so I've pulled the v4l from media_build.git
>> Had to change a couple of things..  and another macro issue regarding 
>> clamp() ..
>> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was 
>> failing..
>> kept getting:  kernel: modprobe: page allocation failure: order:10, 
>> mode:0x10c0d0
>> Have plenty of RAM free so surprised about that one.. tried some of 
>> the tricks re increasing the vm.min_free_kbytes etc..
>>
>> Any way I modified the routine to only allocate a single chunk buffer 
>> based on dstsize and tweaked the chunk handling code..
>> seemed to fix that one.. fw downloaded and seemed to boot ok..
>>
>> Next I'm running into a problem with the saa7164_dvb_register() stage...
>>
>> saa7164[1]: Hauppauge eeprom: model=151609
>> saa7164_dvb_register() Frontend/I2C initialization failed
>> saa7164_initdev() Failed to register dvb adapters on porta
>>
>> I added some extra debug and identified that client_demod->dev.driver 
>> is null..
>>
>> However I'm now stuck as to what to tackle next..
>>
>> I can provide more info, just didn't want to spam the list for my 
>> first email..
>>
>> Regards
>>    Richard Tresidder
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

On Mon, Oct 5, 2015 at 11:26 AM, Richard Tresidder
<rtresidd@tresar-electronics.com.au> wrote:
> stage 1..
> Yep it works with accessing src directly.. had to reboot to verify that one.
> Well at least the download says it worked and the image booted successfully.
>
> excuse my manual diff method..
> git and I don't agree... not sure how to get it to diff the media_build repo
> I pulled the code from..
> my brain is stuck in subversion mode..
>
> Still rebuilding the kernel to check the i2c Mux issue..

Good, that's the patch I had in mind. Thanks.

Yes, you'd need to issue a complete PCIe reset (warm or cold boot) for
the risc processor to reset, and for it to require a firmware to be
loaded again. So, your comments make sense.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

stage 1..
Yep it works with accessing src directly.. had to reboot to verify that one.
Well at least the download says it worked and the image booted successfully.

excuse my manual diff method..
git and I don't agree... not sure how to get it to diff the media_build 
repo I pulled the code from..
my brain is stuck in subversion mode..

Still rebuilding the kernel to check the i2c Mux issue..

Regards
    Richard

saa7164-fw.c.patch
******************************************************************
--- saa7164-fw.c    2015-10-05 23:05:31.279329924 +0800
+++ saa7164-fw.c    2015-10-05 23:21:54.236082009 +0800
@@ -75,7 +75,6 @@ static int saa7164_downloadimage(struct
                   u32 dlflags, u8 __iomem *dst, u32 dstsize)
  {
      u32 reg, timeout, offset;
-    u8 *srcbuf = NULL;
      int ret;

      u32 dlflag = dlflags;
@@ -93,17 +92,10 @@ static int saa7164_downloadimage(struct
          goto out;
      }

-    srcbuf = kzalloc(4 * 1048576, GFP_KERNEL);
-    if (NULL == srcbuf) {
-        ret = -ENOMEM;
-        goto out;
-    }
-
      if (srcsize > (4*1048576)) {
          ret = -ENOMEM;
          goto out;
      }
-    memcpy(srcbuf, src, srcsize);

      dprintk(DBGLVL_FW, "%s() dlflag = 0x%x\n", __func__, dlflag);
      dprintk(DBGLVL_FW, "%s() dlflag_ack = 0x%x\n", __func__, dlflag_ack);
@@ -134,8 +126,9 @@ static int saa7164_downloadimage(struct
      for (offset = 0; srcsize > dstsize;
          srcsize -= dstsize, offset += dstsize) {

+
          dprintk(DBGLVL_FW, "%s() memcpy %d\n", __func__, dstsize);
-        memcpy_toio(dst, srcbuf + offset, dstsize);
+        memcpy_toio(dst, src+offset, dstsize);

          /* Flag the data as ready */
          saa7164_writel(drflag, 1);
@@ -153,7 +146,7 @@ static int saa7164_downloadimage(struct

      dprintk(DBGLVL_FW, "%s() memcpy(l) %d\n", __func__, dstsize);
      /* Write last block to the device */
-    memcpy_toio(dst, srcbuf+offset, srcsize);
+    memcpy_toio(dst, src+offset, srcsize);

      /* Flag the data as ready */
      saa7164_writel(drflag, 1);
@@ -192,7 +185,6 @@ static int saa7164_downloadimage(struct
      ret = 0;

  out:
-    kfree(srcbuf);
      return ret;
  }
  *********************************************************************


On 05/10/15 22:43, Steven Toth wrote:
>>> Do you have a large number of other devices / drivers loaded? I
>>> suspect another driver is burning through kernel memory before the
>>> saa7164 has a chance to be initialized.
>> Nope nothing I can see Its actually the only addon card I have in this
>> system..
>> I'd be buggered If 4GB of RAM is fragmented enough early on in the boot
>> stage...?
> I agree.
>
>> I've hunted but can't find a nice way to determine what contiguous blocks
>> are available..
>> Noted there was a simple module that could be compiled in to test such
>> things, I'll play with that and see what it turns up..
> Let us know how that goes.
>
>>> I took a quick look at saa7164-fw.c this morning, I see no reason why
>>> the allocation is required at all. With a small patch the function
>>> could be made to memcpy from 'src' directly, dropping the need to
>>> allocate srcbuf what-so-ever. This would remove the need for the 4MB
>>> temporary allocation, and might get you past this issue, likely on to
>>> the next (user buffer allocations are also large - as I recall). Note
>>> that the 4MB allocation is temporary, so its not a long term saving,
>>> but it might get you past the hump.
>> That was my thoughts exactly.. but I took a minimal fiddling approach to
>> begin with..
>> I wasn't sure if there was some requirement for the memcpy_toio requiring a
>> specially allocated source..? can't see why..
>> Was going to dig into that next as a side job..
> At this stage the code is 7-8 years old, so I don't recall the
> rationale for why I did that back in 2008(?) - but looking at it
> today, I think its needless.... and its a fairly trivial thing to
> remove and test.
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

>> Do you have a large number of other devices / drivers loaded? I
>> suspect another driver is burning through kernel memory before the
>> saa7164 has a chance to be initialized.
>
> Nope nothing I can see Its actually the only addon card I have in this
> system..
> I'd be buggered If 4GB of RAM is fragmented enough early on in the boot
> stage...?

I agree.

> I've hunted but can't find a nice way to determine what contiguous blocks
> are available..
> Noted there was a simple module that could be compiled in to test such
> things, I'll play with that and see what it turns up..

Let us know how that goes.

>
>> I took a quick look at saa7164-fw.c this morning, I see no reason why
>> the allocation is required at all. With a small patch the function
>> could be made to memcpy from 'src' directly, dropping the need to
>> allocate srcbuf what-so-ever. This would remove the need for the 4MB
>> temporary allocation, and might get you past this issue, likely on to
>> the next (user buffer allocations are also large - as I recall). Note
>> that the 4MB allocation is temporary, so its not a long term saving,
>> but it might get you past the hump.
>
> That was my thoughts exactly.. but I took a minimal fiddling approach to
> begin with..
> I wasn't sure if there was some requirement for the memcpy_toio requiring a
> specially allocated source..? can't see why..
> Was going to dig into that next as a side job..

At this stage the code is 7-8 years old, so I don't recall the
rationale for why I did that back in 2008(?) - but looking at it
today, I think its needless.... and its a fairly trivial thing to
remove and test.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Hi
   Just for clarification
I forgot to add that I had already got past that little bump by chunking 
the allocation to src_buf in the same loop as the memcpy_toio
But I'll rebuild the module with the memcpy_toio directly accessing src 
and see how it goes.

Regards
    Richard Tresidder

On 05/10/15 22:35, Richard Tresidder wrote:
>
>
> On 05/10/15 22:22, Steven Toth wrote:
>> On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder
>> <rtresidd@tresar-electronics.com.au> wrote:
>>> Hi Steven
>>>     Nope standard x86_64
>>> kernel 3.10.0-229.14.1.el7.x86_64
>> Hmm.
>>
>>> Was rather surprised as all my quick reading indicates that the kernel
>>> should quite happily do this...
>>> Though looks like its the largest chunk you can request? I'm not 
>>> well enough
>>> up to speed with the nitty gritty..
>> Yeah, 4MB is the upper limit IIRC.
>>
>>> There is mention of something similar against this card on www 
>>> linuxtv org
>>> wiki index.php  Hauppauge_WinTV-HVR-2200
>>>
>>> ********
>>> Note: Some kernels will not have enough free memory available for the
>>> driver. The dmesg error will start with a message like this:
>>> ] modprobe: page allocation failure: order:10, mode:0x2000d0
>>> followed by a stack trace and other debugging information. While the 
>>> driver
>>> will load, no devices will be registered.
>>> The simple workaround is to allocate more memory for the kernel:
>>> sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes
>>> sudo rmmod saa7164
>>> sudo modprobe saa7164
>>> ********
>> Hmm. I wasn't aware people in the past has seen the issue either. I
>> assume you've tried the above and its not helping, or in fact growing
>> that number for experimentation purposes.
>>
>> Do you have a large number of other devices / drivers loaded? I
>> suspect another driver is burning through kernel memory before the
>> saa7164 has a chance to be initialized.
> Nope nothing I can see Its actually the only addon card I have in this 
> system..
> I'd be buggered If 4GB of RAM is fragmented enough early on in the 
> boot stage...?
> I've hunted but can't find a nice way to determine what contiguous 
> blocks are available..
> Noted there was a simple module that could be compiled in to test such 
> things, I'll play with that and see what it turns up..
>
>> I took a quick look at saa7164-fw.c this morning, I see no reason why
>> the allocation is required at all. With a small patch the function
>> could be made to memcpy from 'src' directly, dropping the need to
>> allocate srcbuf what-so-ever. This would remove the need for the 4MB
>> temporary allocation, and might get you past this issue, likely on to
>> the next (user buffer allocations are also large - as I recall). Note
>> that the 4MB allocation is temporary, so its not a long term saving,
>> but it might get you past the hump.
> That was my thoughts exactly.. but I took a minimal fiddling approach 
> to begin with..
> I wasn't sure if there was some requirement for the memcpy_toio 
> requiring a specially allocated source..? can't see why..
> Was going to dig into that next as a side job..
>
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

On 05/10/15 22:22, Steven Toth wrote:
> On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder
> <rtresidd@tresar-electronics.com.au> wrote:
>> Hi Steven
>>     Nope standard x86_64
>> kernel 3.10.0-229.14.1.el7.x86_64
> Hmm.
>
>> Was rather surprised as all my quick reading indicates that the kernel
>> should quite happily do this...
>> Though looks like its the largest chunk you can request? I'm not well enough
>> up to speed with the nitty gritty..
> Yeah, 4MB is the upper limit IIRC.
>
>> There is mention of something similar against this card on www linuxtv org
>> wiki index.php  Hauppauge_WinTV-HVR-2200
>>
>> ********
>> Note: Some kernels will not have enough free memory available for the
>> driver. The dmesg error will start with a message like this:
>> ] modprobe: page allocation failure: order:10, mode:0x2000d0
>> followed by a stack trace and other debugging information. While the driver
>> will load, no devices will be registered.
>> The simple workaround is to allocate more memory for the kernel:
>> sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes
>> sudo rmmod saa7164
>> sudo modprobe saa7164
>> ********
> Hmm. I wasn't aware people in the past has seen the issue either. I
> assume you've tried the above and its not helping, or in fact growing
> that number for experimentation purposes.
>
> Do you have a large number of other devices / drivers loaded? I
> suspect another driver is burning through kernel memory before the
> saa7164 has a chance to be initialized.
Nope nothing I can see Its actually the only addon card I have in this 
system..
I'd be buggered If 4GB of RAM is fragmented enough early on in the boot 
stage...?
I've hunted but can't find a nice way to determine what contiguous 
blocks are available..
Noted there was a simple module that could be compiled in to test such 
things, I'll play with that and see what it turns up..

> I took a quick look at saa7164-fw.c this morning, I see no reason why
> the allocation is required at all. With a small patch the function
> could be made to memcpy from 'src' directly, dropping the need to
> allocate srcbuf what-so-ever. This would remove the need for the 4MB
> temporary allocation, and might get you past this issue, likely on to
> the next (user buffer allocations are also large - as I recall). Note
> that the 4MB allocation is temporary, so its not a long term saving,
> but it might get you past the hump.
That was my thoughts exactly.. but I took a minimal fiddling approach to 
begin with..
I wasn't sure if there was some requirement for the memcpy_toio 
requiring a specially allocated source..? can't see why..
Was going to dig into that next as a side job..

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Hmm indeed...
I see that the 2168 wants a mux i2c adapter..
and yep my /boot/config-3.10.0-229.14.1.el7.x86_64/ is indeed showing 
that CONFIG_I2C_MUX is commented out..
sigh.. Rebuilding the kernel with that setting on...
Why this is disabled rather than just a module is beyond me..
Curious that an error doesn't pop up about that..
Is there a debug level that can be turned on that would show that up?

Well spotted Tycho
Will let you know how things go

Regards
    Richard Tresidder

On 05/10/15 20:45, Tycho Lürsen wrote:
> Hi, not sure if this is related.
> I had to recompile the centos7 stock kernel with:
> CONFIG_I2C_MUX=m
>
> It was not enabled in the kernel config.
>
> Op 04-10-15 om 06:55 schreef Richard Tresidder:
>> Sorry If I've posted this to the wrong section my first attempt..
>>
>> Hi
>>    I'm attempting to get an HVR2205 up and going.
>> CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
>> [card=13,autodetected]
>> Distribution is CentOS7 so I've pulled the v4l from media_build.git
>> Had to change a couple of things..  and another macro issue regarding 
>> clamp() ..
>> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was 
>> failing..
>> kept getting:  kernel: modprobe: page allocation failure: order:10, 
>> mode:0x10c0d0
>> Have plenty of RAM free so surprised about that one.. tried some of 
>> the tricks re increasing the vm.min_free_kbytes etc..
>>
>> Any way I modified the routine to only allocate a single chunk buffer 
>> based on dstsize and tweaked the chunk handling code..
>> seemed to fix that one.. fw downloaded and seemed to boot ok..
>>
>> Next I'm running into a problem with the saa7164_dvb_register() stage...
>>
>> saa7164[1]: Hauppauge eeprom: model=151609
>> saa7164_dvb_register() Frontend/I2C initialization failed
>> saa7164_initdev() Failed to register dvb adapters on porta
>>
>> I added some extra debug and identified that client_demod->dev.driver 
>> is null..
>>
>> However I'm now stuck as to what to tackle next..
>>
>> I can provide more info, just didn't want to spam the list for my 
>> first email..
>>
>> Regards
>>    Richard Tresidder
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder
<rtresidd@tresar-electronics.com.au> wrote:
> Hi Steven
>    Nope standard x86_64
> kernel 3.10.0-229.14.1.el7.x86_64

Hmm.

>
> Was rather surprised as all my quick reading indicates that the kernel
> should quite happily do this...
> Though looks like its the largest chunk you can request? I'm not well enough
> up to speed with the nitty gritty..

Yeah, 4MB is the upper limit IIRC.

>
> There is mention of something similar against this card on www linuxtv org
> wiki index.php  Hauppauge_WinTV-HVR-2200
>
> ********
> Note: Some kernels will not have enough free memory available for the
> driver. The dmesg error will start with a message like this:
> ] modprobe: page allocation failure: order:10, mode:0x2000d0
> followed by a stack trace and other debugging information. While the driver
> will load, no devices will be registered.
> The simple workaround is to allocate more memory for the kernel:
> sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes
> sudo rmmod saa7164
> sudo modprobe saa7164
> ********

Hmm. I wasn't aware people in the past has seen the issue either. I
assume you've tried the above and its not helping, or in fact growing
that number for experimentation purposes.

Do you have a large number of other devices / drivers loaded? I
suspect another driver is burning through kernel memory before the
saa7164 has a chance to be initialized.

I took a quick look at saa7164-fw.c this morning, I see no reason why
the allocation is required at all. With a small patch the function
could be made to memcpy from 'src' directly, dropping the need to
allocate srcbuf what-so-ever. This would remove the need for the 4MB
temporary allocation, and might get you past this issue, likely on to
the next (user buffer allocations are also large - as I recall). Note
that the 4MB allocation is temporary, so its not a long term saving,
but it might get you past the hump.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Tycho Lürsen]

Hi, not sure if this is related.
I had to recompile the centos7 stock kernel with:
CONFIG_I2C_MUX=m

It was not enabled in the kernel config.

Op 04-10-15 om 06:55 schreef Richard Tresidder:
> Sorry If I've posted this to the wrong section my first attempt..
>
> Hi
>    I'm attempting to get an HVR2205 up and going.
> CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
> [card=13,autodetected]
> Distribution is CentOS7 so I've pulled the v4l from media_build.git
> Had to change a couple of things..  and another macro issue regarding 
> clamp() ..
> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was failing..
> kept getting:  kernel: modprobe: page allocation failure: order:10, 
> mode:0x10c0d0
> Have plenty of RAM free so surprised about that one.. tried some of 
> the tricks re increasing the vm.min_free_kbytes etc..
>
> Any way I modified the routine to only allocate a single chunk buffer 
> based on dstsize and tweaked the chunk handling code..
> seemed to fix that one.. fw downloaded and seemed to boot ok..
>
> Next I'm running into a problem with the saa7164_dvb_register() stage...
>
> saa7164[1]: Hauppauge eeprom: model=151609
> saa7164_dvb_register() Frontend/I2C initialization failed
> saa7164_initdev() Failed to register dvb adapters on porta
>
> I added some extra debug and identified that client_demod->dev.driver 
> is null..
>
> However I'm now stuck as to what to tackle next..
>
> I can provide more info, just didn't want to spam the list for my 
> first email..
>
> Regards
>    Richard Tresidder
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Hi Steven
    Nope standard x86_64
kernel 3.10.0-229.14.1.el7.x86_64

Was rather surprised as all my quick reading indicates that the kernel 
should quite happily do this...
Though looks like its the largest chunk you can request? I'm not well 
enough up to speed with the nitty gritty..

There is mention of something similar against this card on www linuxtv 
org wiki index.php  Hauppauge_WinTV-HVR-2200

********
Note: Some kernels will not have enough free memory available for the 
driver. The dmesg error will start with a message like this:
] modprobe: page allocation failure: order:10, mode:0x2000d0
followed by a stack trace and other debugging information. While the 
driver will load, no devices will be registered.
The simple workaround is to allocate more memory for the kernel:
sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes
sudo rmmod saa7164
sudo modprobe saa7164
********

log snippet and trace from my system before the path I made...
***********
Oct  3 18:43:09 richos kernel: CORE saa7164[0]: subsystem: 0070:f120, 
board: Hauppauge WinTV-HVR2205 [card=13,autodetected]
Oct  3 18:43:09 richos kernel: saa7164[0]/0: found at 0000:04:00.0, rev: 
129, irq: 18, latency: 0, mmio: 0xf7800000
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() no first image
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() Waiting for 
firmware upload (NXP7164-2010-03-10.1.fw)
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() firmware read 
4019072 bytes.
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() firmware loaded.
Oct  3 18:43:09 richos kernel: Firmware file header part 1:
Oct  3 18:43:09 richos kernel: .FirmwareSize = 0x0
Oct  3 18:43:09 richos kernel: .BSLSize = 0x0
Oct  3 18:43:09 richos kernel: .Reserved = 0x3d538
Oct  3 18:43:09 richos kernel: .Version = 0x3
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() 
SecBootLoader.FileSize = 4019072
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() FirmwareSize = 
0x1fd6
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() BSLSize = 0x0
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() Reserved = 0x0
Oct  3 18:43:09 richos kernel: saa7164_downloadfirmware() Version = 
0x1661c00
Oct  3 18:43:09 richos kernel: modprobe: page allocation failure: 
order:10, mode:0x10c0d0
Oct  3 18:43:09 richos kernel: CPU: 1 PID: 23702 Comm: modprobe Tainted: 
GF          O--------------   3.10.0-229.14.1.el7.x86_64 #1
Oct  3 18:43:09 richos kernel: Hardware name: System manufacturer System 
Product Name/P7H55-M/USB3, BIOS 0312    05/26/2010
Oct  3 18:43:09 richos kernel: 000000000010c0d0 00000000a89d2ba5 
ffff8801011d7810 ffffffff81604516
Oct  3 18:43:09 richos kernel: ffff8801011d78a0 ffffffff8115c5c0 
0000000000000000 00000000ffffffff
Oct  3 18:43:09 richos kernel: ffff880117fd6000 ffffffff8115efa6 
ffff8801011d7870 00000000a89d2ba5
Oct  3 18:43:09 richos kernel: Call Trace:
Oct  3 18:43:09 richos kernel: [<ffffffff81604516>] dump_stack+0x19/0x1b
Oct  3 18:43:09 richos kernel: [<ffffffff8115c5c0>] 
warn_alloc_failed+0x110/0x180
Oct  3 18:43:09 richos kernel: [<ffffffff8115efa6>] ? 
drain_local_pages+0x16/0x20
Oct  3 18:43:09 richos kernel: [<ffffffff81160d48>] 
__alloc_pages_nodemask+0x9a8/0xb90
Oct  3 18:43:09 richos kernel: [<ffffffff8119f3a9>] 
alloc_pages_current+0xa9/0x170
Oct  3 18:43:09 richos kernel: [<ffffffff8115b53e>] 
__get_free_pages+0xe/0x50
Oct  3 18:43:09 richos kernel: [<ffffffff811aa13e>] 
kmalloc_order_trace+0x2e/0xa0
Oct  3 18:43:09 richos kernel: [<ffffffffa082b3b1>] 
saa7164_downloadimage+0x9f/0x486 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffffa0820212>] 
saa7164_downloadfirmware+0x882/0xbe0 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffff8110d78c>] ? 
request_threaded_irq+0xcc/0x170
Oct  3 18:43:09 richos kernel: [<ffffffffa081d843>] 
saa7164_initdev+0x583/0xfd0 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffff813087a5>] 
local_pci_probe+0x45/0xa0
*******************

On 4/10/2015 10:03 PM, Steven Toth wrote:
>> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was failing..
>> kept getting:  kernel: modprobe: page allocation failure: order:10,
>> mode:0x10c0d0
> I don't think I've ever seen or heard of that in the entire history of
> the driver.
>
> Are you running on traditional x86/x86 hardware, or something embedded/custom?
>

Re: Hauppauge WinTV-HVR2205 driver feedback

[Steven Toth]

> Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was failing..
> kept getting:  kernel: modprobe: page allocation failure: order:10,
> mode:0x10c0d0

I don't think I've ever seen or heard of that in the entire history of
the driver.

Are you running on traditional x86/x86 hardware, or something embedded/custom?

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge WinTV-HVR2205 driver feedback

[Richard Tresidder]

Sorry If I've posted this to the wrong section my first attempt..

Hi
    I'm attempting to get an HVR2205 up and going.
CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
[card=13,autodetected]
Distribution is CentOS7 so I've pulled the v4l from media_build.git
Had to change a couple of things..  and another macro issue regarding 
clamp() ..
Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was failing..
kept getting:  kernel: modprobe: page allocation failure: order:10, 
mode:0x10c0d0
Have plenty of RAM free so surprised about that one.. tried some of the 
tricks re increasing the vm.min_free_kbytes etc..

Any way I modified the routine to only allocate a single chunk buffer 
based on dstsize and tweaked the chunk handling code..
seemed to fix that one.. fw downloaded and seemed to boot ok..

Next I'm running into a problem with the saa7164_dvb_register() stage...

saa7164[1]: Hauppauge eeprom: model=151609
saa7164_dvb_register() Frontend/I2C initialization failed
saa7164_initdev() Failed to register dvb adapters on porta

I added some extra debug and identified that client_demod->dev.driver is 
null..

However I'm now stuck as to what to tackle next..

I can provide more info, just didn't want to spam the list for my first 
email..

Regards
    Richard Tresidder