On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
> 1) I would like to make a massive cleanup in the arch/mips/mips-boards
> for the reasons explained here:
You are certainly welcome to do so!
> 2) Removing Atlas would reduce the clean-up effort.
You can make it a bonus project ;-) -- I would certainly do some testing
with real hardware if pieces of software start flying by.
> 3) According to Ralf, the user base for Atlas is zero, the board itself
> is buggy.
The Ethernet controller embedded in the onboard SAA9730 chip is
questionable, though some of the problems are apparently the result of our
buggy driver. For example the settings of the PHY chip are not
synchronised to what is set in the MAC. I cleaned up a lot of cruft at
one point, but more can apparently be done. Switching to PHYLIB could
help and is on my to-do list. The PHY is a QS6612 and is already
supported by PHYLIB.
Otherwise the board is just fine, though perhaps a little bit strange --
no south bridge for example (i.e. no subtractive ISA/LPC decoding, nor
8259A or 8237A cores within), though the SAA9730 does implicit active
decoding (i.e. not through PCI BARs) of some addresses that used to be
assigned to motherboard devices in the PC/AT architecture (most notably
the keyboard controller). Essentially a PCI-based junk I/O controller of
> 4) History knows of an attempt to remove Atlas:
Yes, I know.
> 5) Nobody is losing, man-hours are saved. No explanation of why not to do
> Hence, the patch to the feature-removal-schedule.txt.
Well, I am always uneasy about removing stuff that is sufficiently
different from what keeps being supported as quite frequently apparently
oversimplification decisions are made afterwards which make the addition
of support for less usual designs that appear later on unnecessarily
> It would be nice if you could take a look at that (please see the "P.S."
I have seen this, thanks. I'll have look, time permitting.