[PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
jwboyer at linux.vnet.ibm.com
Thu Jul 17 12:15:53 EST 2008
On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> > > Shouldn't it be enough to have a common compatible value in each
> > > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > > specific type unless you need to do something special?
> > This is bad for the same reason that "amcc,44x-<blah>" compatible values
> > are bad in device nodes. The definition of '*-44x-*' changes over time as
> > new parts are added. Compatible values should always reflect an exact
> > part number.
> I agree in general, but I also think that all 44x boards should be
> regarded as the same machine time, in the same way that all powermacs
> are detected as compatible with "Power Macintosh" or "MacRISC", or
> how all sorts of serial ports claim compatibility with i8250.
> For classic SOCs like 4xx or 52xx, the SOC familiy more or less defines
> the platform, and all the details about peripherals can be expressed
> in the device tree elsewhere.
This is what Grant has done for 52xx and what I was talking about with
"4xx_board.c", though 4xx_soc.c is probably a better name.
My hesitation is that while it's true today that 440<chip name> defines
the SoC, it might not always be. And the Virtex boards are craziness
with the core and FPGA setup. So we need to be careful a bit when
chosing what do "bind" to for generics.
> If one board is so different that you need a separate board setup
> in the kernel, it should simply not claim compatibility with the
> SOC platform.
Right. Today we only have a few "overrides" in 4xx. Namely
Canyonlands/Glacier, and Bamboo/Yosemite (Sequoia/Rainier should also
really be that way, but they aren't). So if we decide to go to a
different scheme, it shouldn't be a big deal to switch.
More information about the Linuxppc-embedded