Menu
▾
▴
linuxconsole-dev
|
From: Franz S. <Fra...@la...> - 2002-07-02 11:03:18
|
At 12:43 02.07.2002, Svetoslav Slavtchev wrote: >Hi , >is it supposed drivers/input/keybdev.c to declare the functions and variables, >that are allready defined in drivers/char/keyboard.c , more precisely >x86keycodes >and the problematic emulate_raw, > >and ... >how can one compile kebdev >it seems to me that drivers/input/keybdev.c comes from standart 2.5 or may >be -dj >but not from ruby, what i mean is in emulate_raw it uses handle_scancode, >which doesn't exist in ruby but exist in 2.5 and -dj >and as far i understand the code is replaced by put_queue >so .. ? should handle_scancode in keybdev.c be replaced by put_queue > >and the other unresolved symbol in keybdev.c -- kbd_ledfunc >it appears to me that in keyboard.c kbd_ledfunc is replyced by ledstate >is this correct ? > >so >how should one compile keybdev.c ? With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS for maintenance reasons. keybdev.c provides bridge code between input layer and old-style keyboard.c. In ruby this is no longer necessary as the new-style keyboard.c registers itself directly to the input layer. Maybe you should just wait some more days, Vojtech should be merging this to Linus any day now. Franz. |
|
From: Vojtech P. <vo...@su...> - 2002-07-02 12:56:09
|
On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote: > At 12:43 02.07.2002, Svetoslav Slavtchev wrote: > >Hi , > >is it supposed drivers/input/keybdev.c to declare the functions and variables, > >that are allready defined in drivers/char/keyboard.c , more precisely > >x86keycodes > >and the problematic emulate_raw, > > > >and ... > >how can one compile kebdev > >it seems to me that drivers/input/keybdev.c comes from standart 2.5 or may > >be -dj > >but not from ruby, what i mean is in emulate_raw it uses handle_scancode, > >which doesn't exist in ruby but exist in 2.5 and -dj > >and as far i understand the code is replaced by put_queue > >so .. ? should handle_scancode in keybdev.c be replaced by put_queue > > > >and the other unresolved symbol in keybdev.c -- kbd_ledfunc > >it appears to me that in keyboard.c kbd_ledfunc is replyced by ledstate > >is this correct ? > > > >so > >how should one compile keybdev.c ? > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS for > maintenance reasons. keybdev.c provides bridge code between input layer and > old-style keyboard.c. In ruby this is no longer necessary as the new-style > keyboard.c registers itself directly to the input layer. > > Maybe you should just wait some more days, Vojtech should be merging this > to Linus any day now. That's right, I'm working on the merge right now. -- Vojtech Pavlik SuSE Labs |
|
From: Franz S. <Fra...@la...> - 2002-07-06 14:46:50
|
On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote: > On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote: > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS > > for maintenance reasons. keybdev.c provides bridge code between input > > layer and old-style keyboard.c. In ruby this is no longer necessary as > > the new-style keyboard.c registers itself directly to the input layer. > > > > Maybe you should just wait some more days, Vojtech should be merging this > > to Linus any day now. > > That's right, I'm working on the merge right now. And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech! While preparing the PPC part I noticed one thing though, how do you intend to handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far (using ioremap/readb/writeb and sometimes special access sequences)? Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like i8042-ppc.[ch]? One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this really make sense? Franz. |
|
From: James S. <jsi...@tr...> - 2002-07-06 21:59:31
|
> > > for maintenance reasons. keybdev.c provides bridge code between input > > > layer and old-style keyboard.c. In ruby this is no longer necessary as > > > the new-style keyboard.c registers itself directly to the input layer. > > > You still need keybdev.c with 2.5.25. It will be a few weeks before we will migrate the console system to the input api. > > That's right, I'm working on the merge right now. > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech! Just a few more steps to go. I submited the console patches to Linus. Now to wait for them to go in. > While preparing the PPC part I noticed one thing though, how do you intend to > handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far > (using ioremap/readb/writeb and sometimes special access sequences)? Why we break them. One thing I learned the hard way with the fbdev layer is if you want to change the api you need to change the upper layer first and break every driver. Its the only way it will work. > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like > i8042-ppc.[ch]? :-( > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this > really make sense? ?? |
|
From: Franz S. <Fra...@la...> - 2002-07-07 13:30:30
|
On Samstag, 6. Juli 2002 23:59, James Simmons wrote:
> > > > for maintenance reasons. keybdev.c provides bridge code between input
> > > > layer and old-style keyboard.c. In ruby this is no longer necessary
> > > > as the new-style keyboard.c registers itself directly to the input
> > > > layer.
>
> You still need keybdev.c with 2.5.25. It will be a few weeks before we
> will migrate the console system to the input api.
No problem. The main problem isn't keybdev.c but pc_keyb.c. On PPC I just
disabled most of pc_keyb.c by adding this to asm/keyboard.h:
static inline void kbd_init_hw(void)
{
}
and removing the corresponding #define. Then atkbd.c and i8042.c can be used
without problems.
> > > That's right, I'm working on the merge right now.
> >
> > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!
>
> Just a few more steps to go. I submited the console patches to Linus. Now
> to wait for them to go in.
Well, what are a few weeks more, I'm waiting for 2 years now for this code to
go in.
> > While preparing the PPC part I noticed one thing though, how do you
> > intend to handle the platforms (2 PPC embedded boards and MIPS AFAICS)
> > that redefined
> > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far
> > (using ioremap/readb/writeb and sometimes special access sequences)?
>
> Why we break them. One thing I learned the hard way with the fbdev layer
> is if you want to change the api you need to change the upper layer first
> and break every driver. Its the only way it will work.
No complaint here, just searching for a solution :-).
> > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers
> > like i8042-ppc.[ch]?
> >
> :-(
Exactly. i8042.c has quite a few assumptions in it. It uses inb/out instead of
ioremap/readb/writeb, it assumes control and data register are 4 addresses
apart and it assumes no special sequences are necessary to access these
registers.
> > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does
> > this really make sense?
>
> ??
On PPC quite a lot of embedded boards exist that have PS2 HW which is remapped
to the standard IO addresses and thus i8042.c is useable out of the box.
Nevertheless none of these boards have ISA slots (shudder!) and thus
CONFIG_ISA isn't defined, preventing enabling of CONFIG_SERIO_I8042.
Franz.
|
|
From: Vojtech P. <vo...@su...> - 2002-07-07 19:21:10
|
On Sun, Jul 07, 2002 at 03:29:53PM +0200, Franz Sirl wrote:
> On Samstag, 6. Juli 2002 23:59, James Simmons wrote:
> > > > > for maintenance reasons. keybdev.c provides bridge code between input
> > > > > layer and old-style keyboard.c. In ruby this is no longer necessary
> > > > > as the new-style keyboard.c registers itself directly to the input
> > > > > layer.
> >
> > You still need keybdev.c with 2.5.25. It will be a few weeks before we
> > will migrate the console system to the input api.
>
> No problem. The main problem isn't keybdev.c but pc_keyb.c. On PPC I just
> disabled most of pc_keyb.c by adding this to asm/keyboard.h:
>
> static inline void kbd_init_hw(void)
> {
> }
>
> and removing the corresponding #define. Then atkbd.c and i8042.c can be used
> without problems.
>
> > > > That's right, I'm working on the merge right now.
> > >
> > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!
> >
> > Just a few more steps to go. I submited the console patches to Linus. Now
> > to wait for them to go in.
>
> Well, what are a few weeks more, I'm waiting for 2 years now for this code to
> go in.
I'll be pushing a lot this week, and possibly manage to switch away from
keybdev.c this week also. There might not be a complete switch to
James's console code , just a hacked keyboard.c, but that'll work for
the time being.
--
Vojtech Pavlik
SuSE Labs
|
|
From: James S. <jsi...@tr...> - 2002-07-08 17:01:34
|
> > Just a few more steps to go. I submited the console patches to Linus. Now > > to wait for them to go in. > > Well, what are a few weeks more, I'm waiting for 2 years now for this code to > go in. Well it is a matter of convincing Linus to take the code. I sent him the BK link for the console code some time ago. He hasn't applied it. > > layer is if you want to change the api you need to change the upper > > layer first and break every driver. Its the only way it will work. > > No complaint here, just searching for a solution :-). Its the only way. BT Wprepare for major breakage for teh fbdev layer. Only a few drivers will work very soon. > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out instead of > ioremap/readb/writeb, it assumes control and data register are 4 addresses > apart and it assumes no special sequences are necessary to access these > registers. Some time ago I thought about this when I looked at the sparc i8042 driver. I tried a few things but I didn't come up with a solution. |
|
From: Franz S. <Fra...@la...> - 2002-07-13 14:20:09
Attachments:
bk-input-11.diff
|
On Montag, 8. Juli 2002 19:01, James Simmons wrote: > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out > > instead of ioremap/readb/writeb, it assumes control and data register are > > 4 addresses apart and it assumes no special sequences are necessary to > > access these registers. > > Some time ago I thought about this when I looked at the sparc i8042 > driver. I tried a few things but I didn't come up with a solution. What do you all think about the appended patch? With the strategy in the patch it should be possible to initialize and use i8042 chips on pretty much every platform without code duplication. The patch compiles on PPC (and thus should on x86 too), but I can't test it cause I don't have access to the affected embedded boards. If you like the approach, please apply it to the linux-input repo after testing on x86. Franz. |
|
From: Vojtech P. <vo...@su...> - 2002-07-13 14:41:32
|
On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote: > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out > > > instead of ioremap/readb/writeb, it assumes control and data register are > > > 4 addresses apart and it assumes no special sequences are necessary to > > > access these registers. > > > > Some time ago I thought about this when I looked at the sparc i8042 > > driver. I tried a few things but I didn't come up with a solution. > > What do you all think about the appended patch? With the strategy in the patch > it should be possible to initialize and use i8042 chips on pretty much every > platform without code duplication. > > The patch compiles on PPC (and thus should on x86 too), but I can't test it > cause I don't have access to the affected embedded boards. > > If you like the approach, please apply it to the linux-input repo after > testing on x86. A couple thoughs: 1) We could as well go back to using the asm/ include way, that way we'd have less ifdefs, etc. 2) Do we really want to do all the nasty probing needed on x86 to detect the presence of the AUX port, on every arch out there? Well, maybe it doesn't hurt ... -- Vojtech Pavlik SuSE Labs |
|
From: Franz S. <Fra...@la...> - 2002-07-13 17:13:32
|
On Samstag, 13. Juli 2002 16:40, Vojtech Pavlik wrote: > On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote: > > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out > > > > instead of ioremap/readb/writeb, it assumes control and data register > > > > are 4 addresses apart and it assumes no special sequences are > > > > necessary to access these registers. > > > > > > Some time ago I thought about this when I looked at the sparc i8042 > > > driver. I tried a few things but I didn't come up with a solution. > > > > What do you all think about the appended patch? With the strategy in the > > patch it should be possible to initialize and use i8042 chips on pretty > > much every platform without code duplication. > > > > The patch compiles on PPC (and thus should on x86 too), but I can't test > > it cause I don't have access to the affected embedded boards. > > > > If you like the approach, please apply it to the linux-input repo after > > testing on x86. > > A couple thoughs: > > 1) We could as well go back to using the asm/ include way, that way > we'd have less ifdefs, etc. I don't think we would have many #ifdefs, hmm. With asm/ we would have duplication of the header all over the place with nearly no difference. I think in this case the maintainence burden is lower with the #ifdefs. We could do it like that in i8042.c though: #include "i8042.h" #ifdef CONFIG_PPC #include "i8042-ppc.h" #endif #ifndef I8042_HAVE_PLATFORM_INLINES static inline .... #endif That would avoid the generic i8042-io.h header. Or what about a local i8042.h and a i8042-arch.h in asm/? Anyway, just massage the patch as you would like it (or tell me exactly what solution you want) and push it, I'll send you any missing PPC parts then. > 2) Do we really want to do all the nasty probing needed on x86 to detect > the presence of the AUX port, on every arch out there? Well, maybe it > doesn't hurt ... It didn't hurt so far with the pc_keyb.c driver, so I guess it's OK. But on the other hand it would be no problem to put the AUX probing into another inline routine that platforms can override. Franz. |
|
From: Tom R. <tr...@ke...> - 2002-07-15 14:34:22
|
On Sat, Jul 13, 2002 at 07:12:59PM +0200, Franz Sirl wrote: > On Samstag, 13. Juli 2002 16:40, Vojtech Pavlik wrote: > > On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote: > > > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out > > > > > instead of ioremap/readb/writeb, it assumes control and data register > > > > > are 4 addresses apart and it assumes no special sequences are > > > > > necessary to access these registers. > > > > > > > > Some time ago I thought about this when I looked at the sparc i8042 > > > > driver. I tried a few things but I didn't come up with a solution. > > > > > > What do you all think about the appended patch? With the strategy in the > > > patch it should be possible to initialize and use i8042 chips on pretty > > > much every platform without code duplication. > > > > > > The patch compiles on PPC (and thus should on x86 too), but I can't test > > > it cause I don't have access to the affected embedded boards. > > > > > > If you like the approach, please apply it to the linux-input repo after > > > testing on x86. > > > > A couple thoughs: > > > > 1) We could as well go back to using the asm/ include way, that way > > we'd have less ifdefs, etc. > > I don't think we would have many #ifdefs, hmm. With asm/ we would have > duplication of the header all over the place with nearly no difference. I > think in this case the maintainence burden is lower with the #ifdefs. Isn't that what include/asm-generic/foo.h is for? Or does that just get abused into doing things like: include/asm-$(ARCH)/foo.h /* * We don't need anything special. */ #include <asm-generic/foo.h> -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
|
From: Vojtech P. <vo...@su...> - 2002-07-13 18:32:06
|
On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote: > On Montag, 8. Juli 2002 19:01, James Simmons wrote: > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out > > > instead of ioremap/readb/writeb, it assumes control and data register are > > > 4 addresses apart and it assumes no special sequences are necessary to > > > access these registers. > > > > Some time ago I thought about this when I looked at the sparc i8042 > > driver. I tried a few things but I didn't come up with a solution. > > What do you all think about the appended patch? With the strategy in the patch > it should be possible to initialize and use i8042 chips on pretty much every > platform without code duplication. > > The patch compiles on PPC (and thus should on x86 too), but I can't test it > cause I don't have access to the affected embedded boards. > > If you like the approach, please apply it to the linux-input repo after > testing on x86. Ok, pushed, should be there. -- Vojtech Pavlik SuSE Labs |
|
From: Christoph H. <hc...@ls...> - 2002-07-17 21:18:49
|
On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote: > What do you all think about the appended patch? With the strategy in the patch > it should be possible to initialize and use i8042 chips on pretty much every > platform without code duplication. What about adding asm/i8042.h instead of the ugly ifdef kludges? |
|
From: Vojtech P. <vo...@su...> - 2002-07-07 19:39:41
|
On Sat, Jul 06, 2002 at 04:46:12PM +0200, Franz Sirl wrote: > On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote: > > On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote: > > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS > > > for maintenance reasons. keybdev.c provides bridge code between input > > > layer and old-style keyboard.c. In ruby this is no longer necessary as > > > the new-style keyboard.c registers itself directly to the input layer. > > > > > > Maybe you should just wait some more days, Vojtech should be merging this > > > to Linus any day now. > > > > That's right, I'm working on the merge right now. > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech! > > While preparing the PPC part I noticed one thing though, how do you intend to > handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far > (using ioremap/readb/writeb and sometimes special access sequences)? > > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like > i8042-ppc.[ch]? Depends on how much the keyboard controller is similar on those archs. I'd prefer separate files if the driver on those arch (for example Sun) where the separate driver wouldn't need to handle all the quirky PC historic cruft, and thus be just a very simple driver. Also, if probing is different (if for example firmware can tell you the thing is there), it's worth a separate driver. The code duplication won't be that bad. But for Alpha for example, #defines for just the i/o and irqs will be enough. > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this > really make sense? Depends what CONFIG_ISA means. i8042 certainly resides on ISA (or what remained of it) in PCs. It's not in an ISA slot, though. But it may not be on ISA on other archs, so we might as well remove the #define. -- Vojtech Pavlik SuSE Labs |
|
From: Tom R. <tr...@ke...> - 2002-07-08 15:46:31
|
On Sun, Jul 07, 2002 at 08:52:43PM +0200, Vojtech Pavlik wrote: > On Sat, Jul 06, 2002 at 04:46:12PM +0200, Franz Sirl wrote: > > On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote: > > > On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote: > > > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS > > > > for maintenance reasons. keybdev.c provides bridge code between input > > > > layer and old-style keyboard.c. In ruby this is no longer necessary as > > > > the new-style keyboard.c registers itself directly to the input layer. > > > > > > > > Maybe you should just wait some more days, Vojtech should be merging this > > > > to Linus any day now. > > > > > > That's right, I'm working on the merge right now. > > > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech! > > > > While preparing the PPC part I noticed one thing though, how do you intend to > > handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined > > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far > > (using ioremap/readb/writeb and sometimes special access sequences)? > > > > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like > > i8042-ppc.[ch]? > > Depends on how much the keyboard controller is similar on those archs. Well, in the case of the IBM Spruce (one of the two PPC embedded boards that changes things) has an Intel 82C42PC (S82C42C) to control the keyboard/mouse. I'm not quite sure how that relates to i8042 however.. > > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this > > really make sense? > > Depends what CONFIG_ISA means. i8042 certainly resides on ISA (or what > remained of it) in PCs. It's not in an ISA slot, though. But it may not > be on ISA on other archs, so we might as well remove the #define. That's the important part. On a somewhat related note (I hope) how is the _kd_mksound stuff being handled with the new code? The 'current' _kd_mksound (with PC timers 'n whatnot) works on some PPC32 machines (which have a SuperIO) but not on others, and I'd like to avoid turning on (or asking about) CONFIG_ISA on machines which have a SuperIO but no ISA slots. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
|
From: Vojtech P. <vo...@su...> - 2002-07-08 15:59:44
|
On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote: > On Sun, Jul 07, 2002 at 08:52:43PM +0200, Vojtech Pavlik wrote: > > On Sat, Jul 06, 2002 at 04:46:12PM +0200, Franz Sirl wrote: > > > On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote: > > > > On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote: > > > > > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS > > > > > for maintenance reasons. keybdev.c provides bridge code between input > > > > > layer and old-style keyboard.c. In ruby this is no longer necessary as > > > > > the new-style keyboard.c registers itself directly to the input layer. > > > > > > > > > > Maybe you should just wait some more days, Vojtech should be merging this > > > > > to Linus any day now. > > > > > > > > That's right, I'm working on the merge right now. > > > > > > And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech! > > > > > > While preparing the PPC part I noticed one thing though, how do you intend to > > > handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined > > > kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far > > > (using ioremap/readb/writeb and sometimes special access sequences)? > > > > > > Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like > > > i8042-ppc.[ch]? > > > > Depends on how much the keyboard controller is similar on those archs. > > Well, in the case of the IBM Spruce (one of the two PPC embedded boards > that changes things) has an Intel 82C42PC (S82C42C) to control the > keyboard/mouse. I'm not quite sure how that relates to i8042 however.. It's the chip, yes. i82c42pc is just a later version of the i8042 ... > > > One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this > > > really make sense? > > > > Depends what CONFIG_ISA means. i8042 certainly resides on ISA (or what > > remained of it) in PCs. It's not in an ISA slot, though. But it may not > > be on ISA on other archs, so we might as well remove the #define. > > That's the important part. On a somewhat related note (I hope) how is > the _kd_mksound stuff being handled with the new code? The 'current' > _kd_mksound (with PC timers 'n whatnot) works on some PPC32 machines With the new code the keyboard just sends a "EV_SND, SND_BELL" event to beep. If the keyboard can do it, it will. Otherwise a separate "beep device" has to be registered that'll do the beep. This "beep device" will have a very simple driver that'll program the i8253 PIT on the PC, but can do other stuff elsewhere. > (which have a SuperIO) but not on others, and I'd like to avoid turning > on (or asking about) CONFIG_ISA on machines which have a SuperIO but no > ISA slots. Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we won't require it for hardware only found on mainboards (superio, etc). -- Vojtech Pavlik SuSE Labs |
|
From: Benjamin H. <be...@ke...> - 2002-07-08 16:18:40
|
>With the new code the keyboard just sends a "EV_SND, SND_BELL" event to
>beep. If the keyboard can do it, it will. Otherwise a separate "beep
>device" has to be registered that'll do the beep.
>
>This "beep device" will have a very simple driver that'll program the
>i8253 PIT on the PC, but can do other stuff elsewhere.
Sounds good...
>> (which have a SuperIO) but not on others, and I'd like to avoid turning
>> on (or asking about) CONFIG_ISA on machines which have a SuperIO but no
>> ISA slots.
>
>Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we
>won't require it for hardware only found on mainboards (superio, etc).
The whole point of detecting ISA-like (superio or whatever else) devices
has been discussed a bit at OLS & kernel summit. One idea that popped up
would be to have:
- Arch fills the device tree whith informations about known
ISA-like devices in the system
- Drivers for those rely on the device-tree and stop mucking
around possibly non-existent HW
- In order to deal with the problem of legacy stuff for which
we don't know really if the device is here before "probing" for
it at various known ports & IRQs, the solution is to have the arch
put that info in the device-tree as well (some kind of "need probe"
flag instead of a resource).
That way, existing legacy x86 would just populate the device-tree with
default entries for legacy serial, kbd, ... stuffs with a "need probe"
flag. Newer x86 could use whatever (ACPI ?) tables are passed by the
BIOS to populate the device-tree.
Non-x86 can do the right thing ;)
Ben.
|
|
From: Tom R. <tr...@ke...> - 2002-07-08 16:22:19
|
On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > Well, in the case of the IBM Spruce (one of the two PPC embedded boards
> > that changes things) has an Intel 82C42PC (S82C42C) to control the
> > keyboard/mouse. I'm not quite sure how that relates to i8042 however..
>
> It's the chip, yes. i82c42pc is just a later version of the i8042 ...
Okay, that's good. Will the current code remove the need for what
spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
allow for overides like it is now?
> > (which have a SuperIO) but not on others, and I'd like to avoid turning
> > on (or asking about) CONFIG_ISA on machines which have a SuperIO but no
> > ISA slots.
>
> Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we
> won't require it for hardware only found on mainboards (superio, etc).
Sounds good to me..
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
|
|
From: Vojtech P. <vo...@su...> - 2002-07-08 16:33:48
|
On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > Well, in the case of the IBM Spruce (one of the two PPC embedded boards
> > > that changes things) has an Intel 82C42PC (S82C42C) to control the
> > > keyboard/mouse. I'm not quite sure how that relates to i8042 however..
> >
> > It's the chip, yes. i82c42pc is just a later version of the i8042 ...
>
> Okay, that's good. Will the current code remove the need for what
> spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> allow for overides like it is now?
Wow, the chip must be connected in some pretty non-simple way then.
You'll most likely need a separate driver for spruce there.
By the way, is there a way to *write* to the keyboard controller on that
machine?
> > > (which have a SuperIO) but not on others, and I'd like to avoid turning
> > > on (or asking about) CONFIG_ISA on machines which have a SuperIO but no
> > > ISA slots.
> >
> > Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we
> > won't require it for hardware only found on mainboards (superio, etc).
>
> Sounds good to me..
--
Vojtech Pavlik
SuSE Labs
|
|
From: Tom R. <tr...@ke...> - 2002-07-08 17:29:26
|
On Mon, Jul 08, 2002 at 06:33:37PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> > On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > > Well, in the case of the IBM Spruce (one of the two PPC embedded boards
> > > > that changes things) has an Intel 82C42PC (S82C42C) to control the
> > > > keyboard/mouse. I'm not quite sure how that relates to i8042 however..
> > >
> > > It's the chip, yes. i82c42pc is just a later version of the i8042 ...
> >
> > Okay, that's good. Will the current code remove the need for what
> > spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> > allow for overides like it is now?
>
> Wow, the chip must be connected in some pretty non-simple way then.
> You'll most likely need a separate driver for spruce there.
>
> By the way, is there a way to *write* to the keyboard controller on that
> machine?
Well, from what I can tell of the documents
(http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/39BD3DAA6349C75F87256A0E0046344A)
about it all, I think it might be possible to get at the keyboard in a
different way, but the way we're doing it now is the suggested way to do
it by IBM on that particular memory map. But I'm not entirely sure.
And it might be possible to write to the controller in a similar fashion
to how we read from it. I need to go track down my coworker who did all
of this and ask him more..
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
|
|
From: Tom R. <tr...@ke...> - 2002-07-08 17:40:10
|
On Mon, Jul 08, 2002 at 06:33:37PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 08, 2002 at 09:21:49AM -0700, Tom Rini wrote:
> > On Mon, Jul 08, 2002 at 05:59:24PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Jul 08, 2002 at 08:45:57AM -0700, Tom Rini wrote:
> > > > Well, in the case of the IBM Spruce (one of the two PPC embedded boards
> > > > that changes things) has an Intel 82C42PC (S82C42C) to control the
> > > > keyboard/mouse. I'm not quite sure how that relates to i8042 however..
> > >
> > > It's the chip, yes. i82c42pc is just a later version of the i8042 ...
> >
> > Okay, that's good. Will the current code remove the need for what
> > spruce_read_keyb_{data,status} (arch/ppc/platforms/spruce_setup.c) or
> > allow for overides like it is now?
>
> Wow, the chip must be connected in some pretty non-simple way then.
> You'll most likely need a separate driver for spruce there.
>
> By the way, is there a way to *write* to the keyboard controller on that
> machine?
Oh, and as Franz just pointed out to me on IRC, writing it much simpiler
(in arch/ppc/platforms/spruce.h) :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X