Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80I/O delay override.

[Christer Weinigel]

On Tue, 08 Jan 2008 15:28:03 -0500
"David P. Reed" <dpreed@xxxxxxxx> wrote:

> Register compatible.  Not  the same chips or even the same  masks or 
> timing requirements.

No, but somehow people keep making similar mistakes.  The DEC HiNote
needed outb_p to function correctly?  That was definitely a much more
modern design than the original PC and most probably did not use any
discrete Intel chips, but the same timing problems were there.  I belive
that problem had to do with the keyboard controller though.

> > The discrete Intel
> > chips or clones got aggregated into Super I/O chips, and the Super
> > I/O chips were put on a LPC bus (an ISA bus with another name) or
> > integrated into the southbrige.
> Don't try to teach your grandmother to suck eggs: I've been
> programming PC compatibles since probably before you were able to do
> long division - including writing code on the first prototype IBM
> PCs, the first pre-manufacturing PC-ATs, and zillions of clones.
> (and I was also involved in designing hardware including the
> so-called "Lotus Intel" expanded memory cards and the original PC
> cards)  

Argument by personal authority.  Thats good.  I guess that's why you
don't seem to understand the difference between reading the serial port
status register and not being allowed to access a register at all
due to such this as the 4 cycle delay you quoted yourself from the 8390
data sheet, and similar issues with the I8253 that I quoted from its
data sheet a few posts ago.

> The 8259 PIC is an *interrupt controller*. It was NEVER
> present in a Super I/O chip, or an LPC chip.  Its functionality was
> absorbed into the chipsets that control interrupt mapping, like the
> PIIX and the nForce. 

Yup, sorry about that, it got integrated into some other chip instead.
I was thinking of another timer, the RTC which is usually a part of the
Super I/O. And which is yet another troublesome area since apparently a
lot of chipsets have problems with it.  But the sequence is the same,
discrete chips get aggregated into larger chips. Sometimes the
sometimes old macrocells are reused, sometimes they are redesigned from
scratch (and new bugs are introduced).

> > And the "if it ain't broken, don't fix
> > it" mantra probably means that some modern chipsets are still using
> > exactly the same internal design as the 25 year old chips and will
> > still be subject to some of those ancient limitations.
> >   
> Oh, come on.  Give the VLSI designers some credit for brains.   The
> CAD tools used to design the 8259 and 8253 were so primitive you
> couldn't even get a chip manufactured with designs from that era
> today.  When people design chips today they do it with simulators
> that can't even work, and testers that run from test suites that were
> not available at the time.

And they still keep making the same mistakes...  Registers that require
wait states before being read again, register that assume that there
are going to be some spare cycles between each access so that some
internal logic has time to update, registers that would have needed a
one byte FIFO to avoid DMA overruns (I'd almost forgotten about that
specific bug on SPI controller of the Samsung 2410, but it bit me last
week and I only managed to chase it down properly yesterday), and so on.

I'm quite impressed with what some VLSI designers manage to do.  I just
saw a company roll out a completely new ARM9 design with lots of fun
stuff and as far as I know they only made one single mistake on that
chip.  On the other hand, on other designs you can see how the same old
macrocell has been reused long past the "best before" date, because
some bugs crop up over and over again.  

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