linux-kernel - Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <829197380907191932p56391dedj660d2bfc941a53a8@mail.gmail.com>
Date:	Sun, 19 Jul 2009 22:32:10 -0400
From:	Devin Heitmueller <dheitmueller@...nellabs.com>
To:	Mark Lord <lkml@....ca>
Cc:	Steven Toth <stoth@...uxtv.org>, linux-media@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes 
	branch

On Sun, Jul 19, 2009 at 10:18 PM, Mark Lord<lkml@....ca> wrote:
> Devin Heitmueller wrote:
>>
>> Yeah, the situation with the seven second firmware load time is well
>> known.  It's actually a result of the i2c's implementation in the
>> au0828 hardware not properly supporting i2c clock stretching.  Because
>> of some bugs in the hardware, I have it clocked down to something like
>> 30KHz as a workaround.  I spent about a week investigating the i2c bus
>> issue with my logic analyzer, and had to move on to other things.  I
>> documented the gory details here back in March if you really care:
>
> ..
>
> From your livejournal comments, it sounded like the slow clock might
> not be necessary until *after* the firmware transfer.
>
> Mmm.. I wonder if perhaps a higher clock speed could be used
> during the firmware download, and then switch to the slower 30KHz
> speed afterward ?
>
> This could reduce the firmware transfer to a couple of seconds,
> much better than the current 6-7 second pause.

I did experiment with introducing a tuner callback to inform the
bridge to enter a high speed mode, which in theory would have allowed
the firmware load at 250Khz (and then revert to the slower speed after
the load finished).  However, for some unknown reason the tuner would
not work after the load.  I would see i2c errors on the bus when doing
the tune, and I was not able to identify the cause.

I spent a couple of nights playing with the idea, but didn't have more
time to spend on it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/