> i dont get your last point. Firstly, we do an "outb $0x80" not an inb.
outb not inb sorry yes > Secondly, outb $0x80 has no PCI posting side-effects AFAICS. Thirdly, It does. The last mmio write cycle to the bridge gets pushed out before the 0x80 cycle goes to the PCI bridge, times out and goes to the LPC bus. I still don't believe any of our _p users in PCI space are actually real - but someone needs to look at the scsi ones. > even assuming that it has PCI posting side-effects, how can any locking > error be covered up by an outb 0x80 sticking together with the inb it > does before it? The sequence we emit is: > > inbb $some_port > outb $0x80 > > and i see that the likelyhood of getting such sequences from two CPUs > 'mixed up' are low, but how can this have any smp locking side-effects? > How can this provide any workaround/coverup? We issue inb port We issue outb 0x80 The CPU core stalls and the LPC bus stalls On the other CPU we issue another access to the LPC bus because our locking is wrong. With the 0x80 outb use this stalls so the delay is applied unless the two inb's occur perfectly in time. With a udelay() the udelay can be split and we get a second access which breaks the needed device delay. We end up relying on the bus locking non splitting properties of the 0x80 port access to paper over bugs - see the watchdog fix example I sent you about a week ago. That btw is another argument for removing 0x80 usage as much as possible - its bad for real time. > do you have any memories about the outb_p() use of misc_32.c: > > pos = (x + cols * y) * 2; /* Update cursor position */ > outb_p(14, vidport); > outb_p(0xff & (pos >> 9), vidport+1); > outb_p(15, vidport); > outb_p(0xff & (pos >> 1), vidport+1); > > was this ever needed? This is so early in the bootup that can we cannot None - but we don't care. The problems with 0x80 and the wacko HP systems occur once ACPI is enabled so we are fine using 0x80. I don't myself know why the _p versions ended up being used. A rummage through archives found me nothing useful on this but notes that outb not outw is required for some devices. For that matter does anyone actually have video cards old enough for us to care actually still in use with Linux today ? Alan -- 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/
