Date: Tue, 13 May 2014 23:04:01 +0100 From: Maxim Ignatenko <gelraen.ua@gmail.com> To: Ruslan Bukin <br@bsdpad.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Keyboard drivers, polling vs. non-polling mode Message-ID: <CABWTX-bY%2BBe_mJRf%2B5eAYhRF=Q=qkiHGJV-LjX7M185j7%2BQQ3g@mail.gmail.com> In-Reply-To: <CABWTX-a79Y=zg8VcTcYsOJjB7JmuO=GSHYcyDTDSG8NO7UUCQw@mail.gmail.com> References: <CABWTX-YViLKRS62cuWcJh=Ma_n3TjU2EEaAcijBzSFXGqiuMDQ@mail.gmail.com> <20140513084008.GA71115@machdep.com> <CABWTX-Z7Kh1QHCgBeVs6NGzDkfYRCtfctJ5oij-Og5POqB5jEA@mail.gmail.com> <CABWTX-a79Y=zg8VcTcYsOJjB7JmuO=GSHYcyDTDSG8NO7UUCQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 May 2014 22:26, Maxim Ignatenko <gelraen.ua@gmail.com> wrote: > On 13 May 2014 11:17, Maxim Ignatenko <gelraen.ua@gmail.com> wrote: >> On 13 May 2014 09:40, Ruslan Bukin <br@bsdpad.com> wrote: >>> On Sun, May 11, 2014 at 11:33:42PM +0100, Maxim Ignatenko wrote: >>>> Hello, >>>> >>>> I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). >>>> br@ said that it doesn't work there because polling mode is not implemented yet. >>>> Where can I read about the difference between polling and non-polling >>>> modes (and about keyboard drivers in general)? >>>> sys/dev/kbd/kbdreg.h describes some structures and method signatures, >>>> but I have no clue what is the expected behaviour of those methods. >>>> >>>> My current guess is that in polling mode keyboard driver just queues >>>> up all the input coming from keyboard and then gives it to consumer >>>> upon request, while in non-polling mode it invokes some callback >>>> instead of queueing. But I cannot find any documentation to confirm or >>>> disprove that. >>>> >>> >>> Chrome Embedded Controller (EC) provides interrupt (KB_GPIO_INT pin, active low) >>> reporting that there are pending data and you need to read the data using >>> ec_command(..). After all data was read, pin comes to 1 (not active). >>> >>> We have no interrupts in KDB, so you have to check pin status manually and >>> if status == 0 (active) then read new data. >>> >>> Probably you can start with patch attached (I did't tested). >> >> Thanks, I've tried something like that, except with invoking >> ec_command immediately and comparing returned state to previous one >> rather than reading status bit from GPIO pin. >> I keep getting "fdb0: i2c transfer returned 6" and none of the printfs >> I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. > > Here's what I have now. After booting kernel from flash drive I get > kdb prompt (because of panic() call in exynos5_ehci.c) and when I > press any key - screen gets spammed with "fdb0: i2c transfer returned > 6". printfs added to dev/iicbus/*.c are not triggered. Any ideas? Sorry, it's "fbd0", not "fdb0". -- Best regards, Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABWTX-bY%2BBe_mJRf%2B5eAYhRF=Q=qkiHGJV-LjX7M185j7%2BQQ3g>