TODO-list entry of "HIL keyboard driver needs updating"
A message that is not in the archive (sent off-list or not yet received): 00121503462102.00304@P100
Hmmm... Brian might refer to me, but I do not know who Alex is. The only other person who showed interest in the driver was Helge Deller. We do NOT have access to the HIL specs, and the driver I would like to write will need more detail than that gleaned from the BSD/linux/mklinux source code. But, if the below refers to another two people who DO have access to the docs, then it would be nice if they would tell me what needs to be done to get me access to them.
--
Brian S. Julin
Quoted 26 lines · Helge Deller
Hi Brian,
I plan to remove the current HIL-keyboard-support from the kernel and would like to use your new linux-input-style driver instead.
I've just checked and linux-input is now in our tree, so this would be a good time to add your code.The remaining question is currently, how much time you have had so far for this driver and if/when this code could be added to CVS ? If you need a helping hand please don't hesitate to ask me,
Greetings,
Helge Deller
Quoted 9 lines · you
Probably best not to worry about cleaning keyboard drivers up too much. The current USB code will be followed by linux-input style drivers at some point. In fact I started a HIL linux-input style driver, which would abstract the PS2 port/HIL ports and allow a standard keyboard module to be hooked into the abstracted serio port. I will work on it more when time permits.
--
Brian S. Julin
Quoted 3 lines · Brian S. Julin
We do NOT have access to the HIL specs, and the driver I would like to write will need more detail than that gleaned from the BSD/linux/mklinux source code.
If you have specific questions, I (or other HP employees) can try to find you the answer(s). Since we had a working HIL driver, releasing the HP docs for it was pretty low on the list.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
Quoted 9 lines · Brian S. Julin
Hmmm... Brian might refer to me, but I do not know who Alex is. The only other person who showed interest in the driver was Helge Deller. We do NOT have access to the HIL specs, and the driver I would like to write will need more detail than that gleaned from the BSD/linux/mklinux source code. But, if the below refers to another two people who DO have access to the docs, then it would be nice if they would tell me what needs to be done to get me access to them.
I'm Alex.
The reason that I think I have HIL specs is because it's mentioned in the WAX documentation I have under NDA. I can't send out copies of it, but I can give information necessary for writing code.
- Alex
Signature · 4 lines
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel [email protected], http://www.linuxcare.com/ Linuxcare, Putting open source to work.
The main sticking point I have with the HIL hardware which has an effect on the way I write the linux-input driver, concerns whether or not there is a safe way for me to leave the auto-polling enabled always, or whether it will have to be turned off when a hil packet starts, and the driver must go register a timer task to go poll the chip until the packet is over. It centers around a comment in the BSD driver:
/*
* Send a command to a device on the loop.
* Since only one command can be active on the loop at any time,
* we must ensure that we are not interrupted during this process.
* Hence we mask interrupts to prevent potential access from most
* interrupt routines and turn off auto-polling to disable the
* internally generated poll commands.
*/
Amazingly, all the drivers I find seem to be happy to tie up the CPU and busy wait on the HIL bus in some places, which is "just not good"(tm).
Basically I need to know if there really is the chance that during a packet send operation I will be interrupted by an internally generated poll command, or if they were just being paranoid.
BTW, writing drivers with nothing but other people's source code to look at really is not my favorite activity. I am always left with the impression that there could be a hardware feature that the other authors ignored that would make the code better or simpler. I am guessing that HP has managed to put mountains of paperwork in the way of getting hardware docs, and that my saying this won't help, but I am willing to sign an NDA for the HIL docs.
Thanks,
P.S. I haven't been keeping tabs on things lately -- do we now have loadable kernel modules and modutils working well? Is the kernel timer support up to par? How in sync are the .debs with the bi-monthly trashing of libc compatibility?
--
Brian S. Julin
Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs u pdating"
In reply to Alex deVriesQuoted 5 lines · Alex deVries
I'm Alex.
The reason that I think I have HIL specs is because it's mentioned in the WAX documentation I have under NDA. I can't send out copies of it, but I can give information necessary for writing code.
Does this include the WAX EISA bridge?
In that case I have a few questions to you... I hope you don't mind.
First about different WAXes...
There seems to be two major versions here
- one with sversion 0x76 which is found on ASP based machines (715/old,
730, 735, 750, 755)
- one set of two with sversions 0x8e and 0x90 which are found on LASI based machines where the one with sversion 0x90 is the EISA BA.
These seem to be found on the 715/new, 725, some B, C, D, J and R-class machines)
How are these tow WAX EISA BA's different? Do you know?
1) About interrupts.
How are they implemented?
- If I assume that the interrupt controller is like a ASP or LASI with the following registers, am I right, then?
#define OFFSET_IRR 0x0000 /* Interrupt request register */ #define OFFSET_IMR 0x0004 /* Interrupt mask register */ #define OFFSET_IPR 0x0008 /* Interrupt pending register */ #define OFFSET_ICR 0x000C /* Interrupt control register */ #define OFFSET_IAR 0x0010 /* Interrupt address register */
If so how are the interrupts numbered is bit 0 irq 0 or 15 or?
How is the interrupt connected upwards? IRQ line 23 on the ASP is labeled EISA is this where WAX EISA interrupts go?
2) On I/O regions
I thinks that there are two I/O regions in the WAX EISA: one for port I/O which seem to start at the hpa+0 and then a second one (for MMIO i suppose) which starts at 0x100000 if this is a EISA bus address or host linear address I don't know.
Question is: what do the docs say?
I guess I need to do something with MMIO so that ioremap() and virt_to_bus() work as expected.
I guess I can not count of this thing being DMA coherent on a 715/old?
It seems from the existing source that there should be a version register at 0x7000 but it seems to read 0xffff on my machine...
Best Regards,
Daniel
Quoted 1 line · [email protected] wrote:
Does this include the WAX EISA bridge?
Yeah, it's the WAX ERS. It has a Qtip on the front page.
Quoted 1 line
In that case I have a few questions to you... I hope you don't mind.
Not at all, I'm happy someone with coding time is asking them. I'm in a hotel room in a different country than my docs, but I'll be reunited with them in a crushing airport scene on Friday, hopefully.
Quoted 10 lines
First about different WAXes...
There seems to be two major versions here
- one with sversion0x76which is found on ASP based machines (715/old,730, 735, 750, 755)- one set of two with sversions
0x8eand0x90which are found on LASI based machines where the one with sversion0x90is the EISA BA.
These seem to be found on the 715/new, 725, some B, C, D, J and R-class machines)
How are these tow WAX EISA BA's different? Do you know?
My understanding is that one of them is the bridge portion of WAX, the other is all the other WAX devices like HIL and RS232. It actually doesn't much matter so long as we load the right driver based on the right signatures. I had thought I'd done that in the driver already.
And yes, the WAX does have RS232 ports, and it looks like the 715/new machines have one serial port on Lasi, the other on WAX.
Quoted 12 lines
1) About interrupts.
How are they implemented?
- If I assume that the interrupt controller is like a ASP or LASI with the following registers, am I right, then?#define OFFSET_IRR 0x0000 /* Interrupt request register */ #define OFFSET_IMR 0x0004 /* Interrupt mask register */ #define OFFSET_IPR 0x0008 /* Interrupt pending register */ #define OFFSET_ICR 0x000C /* Interrupt control register */ #define OFFSET_IAR 0x0010 /* Interrupt address register */
Quoted 4 lines
If so how are the interrupts numbered is bit 0 irq 0 or 15 or?
How is the interrupt connected upwards? IRQ line 23 on the ASP is labeled EISA is this where WAX EISA interrupts go?
I'll dig this up, I do have that info.
I tried to trigger interrupts, but never actually got this going.
Quoted 6 lines
2) On I/O regions
I thinks that there are two I/O regions in the WAX EISA: one for port I/O which seem to start at the hpa+0 and then a second one (for MMIO i suppose) which starts at
0x100000if this is a EISA bus address or host linear address I don't know.
The remapping functions are pretty wild, and I'd thought I'd already committed those. It's a horrible bit twisting and shifting thing.
Quoted 5 lines
Question is: what do the docs say?
I guess I need to do something with MMIO so thatioremap()andvirt_to_bus()work as expected.I guess I can not count of this thing being DMA coherent on a 715/old?
There's some gross coherency problems that are going to be difficult to outline without actually showing you the doc (which I'm okay with, but you need to talk to HP to get that sorted out).
Quoted 2 lines
It seems from the existing source that there should be a version register at
0x7000but it seems to read0xffffon my machine...
Let me find out about that as well, I did get this part to work at some point.
Hang on a few days, I'll dig this up for you.
- Alex
Signature · 4 lines
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare 613.562.2759 tel [email protected], http://www.linuxcare.com/ Linuxcare, Putting open source to work.
Quoted 2 lines · Alex deVries
The remapping functions are pretty wild, and I'd thought I'd already committed those. It's a horrible bit twisting and shifting thing.
Yes, I saw those, but I did not really get them to work until I removed the remapping thing. May be the early EISA BA is very different from the later (and more common one)?
Quoted 1 line
Hang on a few days, I'll dig this up for you.
Will do.
/Daniel