[Top] [All Lists]

Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.

To: Dmitri Vorobiev <>
Subject: Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: "Maciej W. Rozycki" <>
Date: Tue, 15 Jan 2008 13:57:08 +0000 (GMT)
Cc: Geert Uytterhoeven <>, Ralf Baechle <>,, Linux-kernel <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <Pine.LNX.4.64.0801142302001.2335@anakin> <> <> <>
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 
some sort.

> 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 
> that.
>    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." 
> part):

 I have seen this, thanks.  I'll have look, time permitting.


<Prev in Thread] Current Thread [Next in Thread>