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

["H. Peter Anvin" <hpa@zytor.com>]

Rene Herman wrote:
> On 17-12-07 03:05, H. Peter Anvin wrote:
>
> > Incidentally, I had the thought earlier today that port 0xf0 might be 
> > a suitable delay port.  It is used only by the 387-emulating-a-287 
> > hack for IRQ 13, which Linux doesn't use on 486+.
>
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> rene@7ixe4:~/src/port80$ su -c ./portf0
> cycles: out 2400, in 2400
>
> (Duron 1300)
>
> I suppose you mean using it instead of port 0x80 always and not just as 
> an alternate port? For the latter 0xed is alright I guess...

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).

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.

	-hpa


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

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