Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Mar 2009 17:34:09 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        freebsd-hackers@FreeBSD.org
Subject:   fdc io ports
Message-ID:  <49C7ABF1.3060808@icyb.net.ua>

next in thread | raw e-mail | index | archive | help

There is the following verbose and helpful comment in fdc_isa.c:
> On standard ISA, we don't just use an 8 port range
> (e.g. 0x3f0-0x3f7) since that covers an IDE control register at
> 0x3f6.  So, on older hardware, we use 0x3f0-0x3f5 and 0x3f7.
> However, some BIOSs omit the control port, while others start at
> 0x3f2.  Of the latter, sometimes we have two resources, other times
> we have one.  We have to deal with the following cases:
> 
> 1:   0x3f0-0x3f5                     # very rare
> 2:   0x3f0                           # hints -> 0x3f0-0x3f5,0x3f7
> 3:   0x3f0-0x3f5,0x3f7               # Most common
> 4:   0x3f2-0x3f5,0x3f7               # Second most common
> 5:   0x3f2-0x3f5                     # implies 0x3f7 too.
> 6:   0x3f2-0x3f3,0x3f4-0x3f5,0x3f7   # becoming common
> 7:   0x3f2-0x3f3,0x3f4-0x3f5         # rare
> 8:   0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7
> 9:   0x3f0-0x3f3,0x3f4-0x3f5,0x3f7

Looking in fdc.c it seems that it never uses ports at offsets 0, 1 and 3:
> #define FDOUT   2       /* Digital Output Register (W) */
...
> #define FDSTS   4       /* NEC 765 Main Status Register (R) */
> #define FDDSR   4       /* Data Rate Select Register (W) */
> #define FDDATA  5       /* NEC 765 Data Register (R/W) */
> #define FDCTL   7       /* Control Register (W) */

On my system ACPIreserves 0x3f2-0x3f5,0x3f7 ("second most common" above).

In i386/amd64 world, it seems that the only reason to specify
hint.fdc.0.port="0x3F0" in GENERIC.hints is to say "we actually do not use 0x3f0
and 0x3f1 ports, but we guess that they might affect fdc, so we'll reserve them
just in case". Do we really need to do this over-safety?

The only reason for me asking is that I am hacking on a driver for a Super I/O
chip that actually uses 0x3f0 and 0x3f1 ports and there is a resource conflict
with fdc when ACPI is disabled. It's not an issue, but I thought that we could
free up those ports.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C7ABF1.3060808>