Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17-12-07 04:35, H. Peter Anvin wrote:

Well, we probably should leave the possibility in to use 0x80 -- for one thing, we need to use 0x80 on 386, and there is always the possibility that the switch will have different timing properties on some or all machines.

Note that this doesn't require that a machine actually implements port 0xf0 for FERR/IGNNE, it just requires that they don't use it for something else.

I would be rather inclined to try using port 0xf0 by default as long as family > 3[*] (with fallback to port 0x80) at least experimentally (-mm).

Possible timing differences would be what worry me. 0x80 is well-known for its delay purposes, and frankly, I dont believe that one type of machine having a problem, which may very well have to be categorized a possibly BIOS fixable bug, is enough ground for switching everyone over to a different port

It's enough ground to look at not doing outputs at all AFAIC but that's more due to the outb being somewhat cheesy to start with which using a different port wouldn't change. But, on the other hand:

We *might* even be able to use port 0xf0 unconditionally in the setup code, since we're not using the FPU there (the only FPU instructions in the setup code are there to detect the FPU.)

One thing: although I believe most actual implementations of port 0xf0 implement it as a strobe alone (data is ignored), all documentation I've found, including "The Undocumented PC" specifically says "write 0x00 to this port." This *could* mean there are platforms which use other values than 0x00 for other hacks.

The Intel PIIX/PIIX3 datasheet confirms that the data is of no consequence, but yes, most documentation talks about 0.

The PIIX/PIIX3 datasheet also says that both reads and writes flow through to the ISA bus, while for port 0x80 only writes do, and reads do not.

I do not know how universal that is, but _reading_ port 0xf0 might in fact be sensible then? And should even work on a 386/387 pair? (I have a 386/387 in fact, although I'd need to dig it up).

Versus the out it has the al clobber disadvantage, but givne that we're by now seem to be talking about out of line switch() native_io_delays anyways, that's not much of a problem anymore...

[*] The following statements are equivalent:
    - family > 3.
    - CR0.NE is settable.
    - EFLAGS.AC is settable.

For the boot code, I gather (which could I suppose then also plug in the delay port in the zero page or somewhere for use by the kernel proper? I don't know how/if these bits communicate).

But, well, _reading_ port 0xf0 sounds promising across the board and low risk replacement _if_ teh PIIX/PIIX3 behaviour is as guaranteed as the port 0x80 behaviour...

Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux