[parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[Mattias Wadenstein]

I'm working on migrating the TODO list to the BTS, and I didn't found any
info on if this was active or old in the mailinglist archive or on IRC.

The entry is:

* HIL keyboard driver needs updating (Brian and Alex has access to
  HIL documentation)

If anyone knows what is means, please file it with the bug tracking system
unless it is solved already.

/Mattias Wadenstein

[parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[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.

--
Brian S. Julin

On Fri, 15 Dec 2000, Helge Deller wrote:

> 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
>
> On Wednesday 01 November 2000 08:48, you wrote:
> > 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
>

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[Grant Grundler]

"Brian S. Julin" wrote:
> 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

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[Alex deVries]

"Brian S. Julin" wrote:
> 
> 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

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Putting open source to work.

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[Brian S. Julin]

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 updating"

[Mike Hibler]

> Date: Mon, 5 Mar 2001 12:26:46 -0500 (EST)
> From: "Brian S. Julin" <bri@mojo.calyx.net>
> To: Alex deVries <alex@linuxcare.com>
> Subject: Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"
> 
> 
> 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).
> 

The doc clearly states that auto-polling must be disabled or you must be
certain that the timing of your data transfer does not interfere with the
polling.  The recommended way was to disable auto polling.

As for disabling interrupts, its been a long time and I'm not sure what the
hell we meant by "Hence we mask interrupts to prevent potential access
from most interrupt routines".  You may want to disable interrupts to get
on and off the loop as quick as possible to avoid dropping input chars.

> 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.
> 

Just following directions! :-)  Don't think we ever tried it without
disabling auto polling, so I don't know what the consequences of
interfering with a poll would be, probably not good.

> 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.
> 

Understandable.  Yes, we went for simple and straight-forward when writing
the drivers and didn't always exploit "special features" of the hardware.
My experience with such special HW features is that they make drivers more
complicated with little added benefit.

Anyway, I have been using the BSD HIL driver daily for 14 years or so now,
and haven't had any significant problems.

Mike

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs u pdating"

[5116]

On  5 Mar, Alex deVries wrote:

> 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
-- 

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[Alex deVries]

5116@telia.com wrote:
> Does this include the WAX EISA bridge?

Yeah, it's the WAX ERS.  It has a Qtip on the front page.

> 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.

> 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?

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.

> 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?

I'll dig this up, I do have that info.

I tried to trigger interrupts, but never actually got this going.

> 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.

The remapping functions are pretty wild, and I'd thought I'd already
committed those.  It's a horrible bit twisting and shifting thing.

> 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?

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).

> It seems from the existing source that there should be a version
> register at 0x7000 but it seems to read 0xffff on 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

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Putting open source to work.

Re: [parisc-linux] TODO-list entry of "HIL keyboard driver needs updating"

[5116]

On  7 Mar, Alex deVries wrote:
 
> 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)?
 
> Hang on a few days, I'll dig this up for you.
Will do.


/Daniel

--