On Tue, 2009-08-18 at 03:04 +0200, Giuseppe Bilotta wrote:
> On Tue, Aug 18, 2009 at 1:53 AM, Maxim Levitsky<maximlevitsky@...> wrote:
> > On Mon, 2009-08-17 at 16:01 +0200, Giuseppe Bilotta wrote:
> >> On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe
> >> Bilotta<giuseppe.bilotta@...> wrote:
> >> >
> >> > Some more information. The kernel is actually 2.6.30-6 in Debian
> >> > unstable. The rc works (in Vista everything is fine). If I reboot the
> >> > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then
> >> > pressing a key (e.g. the DVD key) I get
> >> >
> >> > oblomov@...:~$ cat /dev/lirc0 | xxd
> >> > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^.............
> >> >
> >> > After that, nothing else comes out. I can reboot, and get the stuff
> >> > again, and then again nothing.
> >> Doh, sorry for replying to myself so often and for spamming like this,
> >> but one more information: after the first key press on the remote, I
> >> get nothing else. A reboot is _necessary_. Just unloading and then
> >> reloading the lirc_ene0100 (and related) modules is not enough.
> > I knew that there were hardware differences :-(
> > Try to load the driver (after a reboot)
> > (You probably need first to unload it)
> > modprobe -r lirc_ene0100
> > c sample_period=200
> > and then, please run
> > mode2 -m -d /dev/lirc0
> > and send me the output
> I will look into this, but I suspect the problem does not lie there. I
> think the buffer pointer is stored elsewhere in my chip, see below.
> > also, when there is no output, take a look at /proc/interrupts
> > does entry enecir increase ?
> No, only 1 interrupt gets called.
This is the most interesting part....
Which means that interrupt ACK that works here, doesn't work on your
Still, try to use enable_idle=0
> > What exactly notebook you have?
> I have an HP Pavilion dv5. However, more important than the notebook I
> think is the actual chip ID.
> You can get the chip ID value by peeking at FF1E (hi) and FF1F (lo),
> which in my case return 3926 (since you mention a KB3924, I assume
> FF1F will hold 0x24 in your case)
Mine actually returns 3909. The fact I have 3924 I concluded from bios
dumps and changelog of it.
> . For my chip, F8F9 does not hold the
> buffer pointer but another configuration word, which I think refers to
> the IR _transmitter_ provided by this chip (a feature which is
> probably disabled here anyway). I'll try providing more information as
> soon as I discover it.
F8F9 can contain anything. its only the lowest bit that I check.
could you see if contents of F8F0-F8F7 stop changing after initial
And, are these contents always the same? Or in other words is the
firmware buffer there.
Just a wild guess, maybe they have switched to store each sample in a
word?, then firmware pointer might be further away.
Anyway, hardware really seems to be different.
F400h~FBFF are the device ram, thus onlu range that depends on firmware
used, but you probably have a slightly different hardware too.
These clowns, change hardware, and keep the same PNP ID....
And also, it would be great to see interrupt status, FD80, before and
after first and only interrupt, to see if another bit is used there.
> By the way, did you manage to contact the ENE rep for the embedded
> controllers? I wrote him an email some time ago but they never replied
> ... maybe if enough people ask they will provide datasheets ...
I didn't try, but, since OLPC devs have worked quite hard to get KB3700
datasheets, I guess these folks won't give me anything unless I sign an
NDA or so, and I won't do that for any price.