Peter, Garrett,
See my replied inline. Hopefully I haven't 'lied' without knowing
it or confused you with anything. Sorry for the delay in getting
back to you. I'm also out of the office Aug 23rd & 24th.
Peter Memishian wrote:
[ CC'ing Kevin Crowe, as I think he's familiar with the sordid history of
su_driver.c. This is well outside my area of expertise. ]
> I started looking at su_driver.c. It should be be consolidated as
> well. But one area that gives me cause for concern is comments and code
> referencing the Intel 82510 chip.
>
> Is this chip found on any UltraSPARC hardware (or any hardware that we
> need to support in OpenSolaris?)
Hopefully Kevin can answer this.
I am not aware of any UltraSPARC hardware that uses the 82510 chip? I
believe that the only UltraSPARC chips that the 'su' driver drives
are the Acer-Ali 1535 series of Southbridge chips. These chips claim
to have 165xx compatible UART functionality inside them if I recall?
(I don't have the spec sheets in front of me right now but they are
easily found to confirm this.) I can't remember if Acer-Ali changed
names or sold the 1535 rights to some other company so you may not
find the specs at Acers website?
There might be another brand of Southbridge that was used but I can't
recall what it was? I believe it was also 165xx compatible.
I have no experience with the 82510 chip nor have I ever seen it's
data sheet.
> I can either support the 82510 (I since found a datasheet), or (even
> better) we can declare the chip unsupported.
>
> I would not be surprised to learn that the last 82510 platform was an
> older sun4c or sun4m platform.
I don't remember sun4c but some sun4m's used custom Sun built ASICS and
used the zs serial port driver (Zilog 8530).
Maybe sun4c or the antique i386 based stuff used the 82510? Thats way
before my time though ;)
> I cannot find Intel's original datasheets for this part, and I'm not
> entirely confident in this part. It looks like it probably had a FIFO,
> but that it was accessed using some method quite different from the
> standard 16550 UARTs.
>
> Should I worry about this? I don't feel that I can support the 82510
> without further knowledge of which platform(s) used it (so I can test),
> and without a datasheet.
>
> FWIW, it looks like once upon a time asy.c also had 82510 support that
> was removed in S10. I want to take it a step further and remove 8250
> and 16450, because I consider fifo-less UARTS to largely be useless in
I think it would be safer to leave the code in and just declare the
chip(s) unsupported, clearly you can't introduce any regressions
that way ;)
By the way, su_driver.c was taken as a child of asy.c back around
the Solaris 2.5.1 timeframe to be used as a keyboard/mouse driver.
Around Solaris 8 timeframe the SunBlade 100 came along and used the
Acer-Ali 1535 SuperIO chip and they chose to use the minimally
maintained su driver (virtually no bugs were exposed since it was
only a kbd/mouse driver) rather than port the x86 based asy.c driver
to run on Sparc. asy.c was a bit better maintained since it was
used on x86 (however due to the on-again-off-again x86 Sun support
dance I'd guess it didn't get the best use and support over the years.)
As such, much of su & asy are similar.
su is still used for kbd/mouse on many/most sun4u based platforms
(not the usb based kbd/mouse obviously.) I don't believe se or zs
serial drivers are used at all and asy is only used on x86 so that
leaves us with su as the only currently used generic serial port driver
I'm aware of.
> the modern era.
Clearly, removal of hardware support needs to be carefully researched to
ensure that we are not crippling any supported platforms. Kevin, can you
clue us in on what serial chipsets need to be supported in Nevada?
I believe only the Acer-Ali 1535 SuperIO chip with it's 16550 compabable
serial ports is currently used. I wouldn't say I'm 100% positive but
I don't recall running across anything else in our systems. I'm not
overly familiar with all the Netra series of platforms though. I'm not
aware of new systems in development and I guess it could be possible
they might have plans to use a different chip driven by the su driver.
I can only imagine that you'd have to track down PM's for all the
different development groups to verify this?
Thanks,
Kevin.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
