I couldn't find a maintainer of the code, so I'm writing here.
In kernel 2.4.1 in arch/i386/kernel/setup.c there is:
--- arch/i386/kernel/setup.c
struct resource standard_io_resources[] = {
{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
{ "timer", 0x40, 0x5f, IORESOURCE_BUSY },
{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
};
---
which fix-allocate some io-resources.
What is the reason for that?
Isn't that a job of the device drivers?
In KGI we have our own keyboard driver which tries to allocate the
kayboard I/O range for itself, and when it does io_check_region() it
fails. What should I do?
--
http://www.jaszczur.org/~smoku/
"Tomasz Sterna wrote:"
> I couldn't find a maintainer of the code, so I'm writing here.
>
> In kernel 2.4.1 in arch/i386/kernel/setup.c there is:
>
> --- arch/i386/kernel/setup.c
> struct resource standard_io_resources[] = {
> { "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
> { "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
> { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
> { "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
> { "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
> { "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
> { "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
> { "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
> };
> ---
>
> which fix-allocate some io-resources.
> What is the reason for that?
> Isn't that a job of the device drivers?
>
> In KGI we have our own keyboard driver which tries to allocate the
> kayboard I/O range for itself, and when it does io_check_region() it
> fails. What should I do?
There are more problems. Eg. ali14xx (old IDE interface, mostly used on
i486-bazed systems) sometimes uses 0x074, 0x0f4 or 0x034 ports for IDE
configuration. It cannot be evidenced as all the ports mentioned here are
claimed to be used by other subsystem.
But there's another problem here: probing port 0x34 on Intel VX/HX/TX/LX/BX
chipset based systems causes system hang (interrupts are masked) as these
chipsets do not completely decode 0x34 I/O address (ie. 0x34 == 0x20 for
them)
So, the ports are used in some hardware configurations, are not used (some
of them) in others. But there is no simple way to distinguish these cases.
:(
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
>Isn't that a job of the device drivers?
Well most of those resources are present on every PC motherboard.
>In KGI we have our own keyboard driver which tries to allocate the
>kayboard I/O range for itself, and when it does io_check_region() it
>fails. What should I do?
This will also be the case for 2.5.X. We already have the PS/2 keyboard
ported over to the input api. Since we can in theory have a USB system and
then later attach a PS/2 keyboard we have it so the resources are
allocated for PS/2 keyboards.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
On Wed, Mar 21, 2001 at 09:13:05AM -0800, James Simmons wrote:
> >Isn't that a job of the device drivers?
> Well most of those resources are present on every PC motherboard.
I still can't see a reason for allocating it before the device drivers
could do that.
Any suggestions? Anyone?
> This will also be the case for 2.5.X. We already have the PS/2 keyboard
> ported over to the input api.
What is the "input api"? Could You give me any URL to read?
--
__ ___ __
__`-,_( | )_(__)_|-<_(__)___ _
http://www.jaszczur.org/~smoku/
Tomasz Sterna wrote:
>
> On Wed, Mar 21, 2001 at 09:13:05AM -0800, James Simmons wrote:
> > >Isn't that a job of the device drivers?
> > Well most of those resources are present on every PC motherboard.
>
> I still can't see a reason for allocating it before the device drivers
> could do that.
>
> Any suggestions? Anyone?
If you write into those resources and they are absent, bad things
sometimes happen. So, they are always added to the reserved-resource
list. I already had this argument with Linus :)
Jeff
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
>If you write into those resources and they are absent, bad things
>sometimes happen. So, they are always added to the reserved-resource
>list. I already had this argument with Linus :)
Oops. Got that wrong. Time to fix CVS.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
>I still can't see a reason for allocating it before the device drivers
>could do that.
See Jeff's response. We got it wrong as well :-( Time to fix that.
>What is the "input api"? Could You give me any URL to read?
http://www.suse.cz/development/inputhttp://www.suse.cz/development/
And http://linuxconsole.sourceforge.net which is a project that takes
advantage of using the input layer for the console system and a massive
cleanup of the fbdev layer.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net