Timer allocates too many ports

Hi!

The timer in linux allocates the io ports 0x40 to 0x5F. This is causing some problems for me since the hardware I'm writing a driver for has its ports at 0x4E and 0x4F. In Windows the ports 0x40 to 0x43 are used for the timer. Why does linux allocate so many more ports?

Rgds
Pierre Ossman

On Fri, 20 Aug 2004 22:33:19 +0200 Pierre Ossman wrote:

| Hi!

Ho-

| The timer in linux allocates the io ports 0x40 to 0x5F. This is causing 
| some problems for me since the hardware I'm writing a driver for has its 
| ports at 0x4E and 0x4F. In Windows the ports 0x40 to 0x43 are used for 
| the timer. Why does linux allocate so many more ports?

Seems reasonable to me for Linux timer driver (resource) to allocate 0x40 - 0x43 and 0x50 - 0x53 (on intel x86; only 0x40 - 0x43 for AMD x86-64). At least that's what is in some Intel specs. That would be accurate AFAIK and still leave 0x4e - 0x4f available.

What kind of device uses IO addresses 0x4e - 0x4f?
Is it a motherboard device? Intel ICH specs think that 0x4e - 0x4f are for LPC SIO and are forwarded to the LPC device.

--
~Randy

Unfortunately the driver allocates 0x40-0x5f as can be seen in /proc/ioports:
0040-005f : timer
I do not know which file contains this allocation so I haven't been able to change it. Any ideas?

The device is a SD/MMC card reader which is indeed an LPC device. The ports in question are needed to identify the chip and determine which resources it has. Actual usage is done on higher ports.

Rgds
Pierre

On Fri, 20 Aug 2004 23:25:49 +0200 Pierre Ossman wrote:

| Randy.Dunlap wrote:
| 
| >On Fri, 20 Aug 2004 22:33:19 +0200 Pierre Ossman wrote:
| >
| >| The timer in linux allocates the io ports 0x40 to 0x5F. This is causing 
| >| some problems for me since the hardware I'm writing a driver for has its 
| >| ports at 0x4E and 0x4F. In Windows the ports 0x40 to 0x43 are used for 
| >| the timer. Why does linux allocate so many more ports?
| >
| >Seems reasonable to me for Linux timer driver (resource) to allocate
| >0x40 - 0x43 and 0x50 - 0x53 (on intel x86; only 0x40 - 0x43 for AMD x86-64).
| >At least that's what is in some Intel specs.  That would be accurate
| >AFAIK and still leave 0x4e - 0x4f available.
| >  
| >
| Unfortunately the driver allocates 0x40-0x5f as can be seen in 
| /proc/ioports:
| 0040-005f : timer

Yes, I know, I wasn't questioning that.

| I do not know which file contains this allocation so I haven't been able | to change it. Any ideas?

Sure, arch/i386/kernel/setup.c, near line 221 (in 2.6.8.1):

	.name	= "timer",
	.start	= 0x0040,
	.end	= 0x005f,
	.flags	= IORESOURCE_BUSY | IORESOURCE_IO

Just split that into 2 entries in the standard_io_resources[] array and it's done.

| >What kind of device uses IO addresses 0x4e - 0x4f?
| >Is it a motherboard device?  Intel ICH specs think that 0x4e - 0x4f
| >are for LPC SIO and are forwarded to the LPC device.
| >
| >
| The device is a SD/MMC card reader which is indeed an LPC device. The 
| ports in question are needed to identify the chip and determine which 
| resources it has. Actual usage is done on higher ports.

--
~Randy

Thanks. That worked perfectly. Who is the responsible maintainer for this part of the kernel? When my driver is ready to be added to the Linus' kernel I need to have this changed.

Rgds
Pierre

On Sat, 21 Aug 2004 10:58:28 +0200 Pierre Ossman wrote:

| Randy.Dunlap wrote:
| 
| >On Fri, 20 Aug 2004 23:25:49 +0200 Pierre Ossman wrote:
| >
| >
| >| I do not know which file contains this allocation so I haven't been able 
| >| to change it. Any ideas?
| >
| >Sure, arch/i386/kernel/setup.c, near line 221 (in 2.6.8.1):
| >
| >	.name	= "timer",
| >	.start	= 0x0040,
| >	.end	= 0x005f,
| >	.flags	= IORESOURCE_BUSY | IORESOURCE_IO
| >
| >Just split that into 2 entries in the standard_io_resources[] array
| >and it's done.
| >
| >  
| >
| Thanks. That worked perfectly. Who is the responsible maintainer for 
| this part of the kernel? When my driver is ready to be added to the 
| Linus' kernel I need to have this changed.

Post the patch here for other comments/review & copy it to [email protected] (Andrew Morton).

He will likely merge it into the -mm patchset for a while to see if it makes anything else unhappy. If not, and if noone has problems with it (e.g., on other kinds of x86 motherboards), then it should be merged, but that's up to Andrew and/or Linus.

--
~Randy