Porting to new board [was: Re: Au1100 FB driver uplift for 2.6]

[Ulrich Eckhardt <eckhardt@satorlaser.com>]

Dan Malek wrote:
> On Apr 4, 2005, at 11:17 AM, Ulrich Eckhardt wrote:
> > [2] Based on DB1100. Are there any pointers on how to port to a new
> > board, btw?
>
> One of the discussion items is always how to keep a "generic"
> driver and still provide unique setup/control for different types of
> boards.  I guess if we can discuss other board ports, it will be
> more clear how to do this.

OK, I'll be more concrete:
The board I'm talking about has different peripherals than the DB1100. In 
particular, it doesn't have any BCSRs, it only has a single flash-chip with 2 
MB RAM on board, a CAN bus interface and a rather peculiar way to generate 
the clocks for attached displays. 
 Most of this is easily remedied by only compiling a selected driver in and 
I'm doing rather fine loading a DB1100 config and modifying it a bit to get 
the board running. There are a few things though where I could really use a 
preprocessor check for that board:
- the layout table for the on-board flash RAM. The current driver only checks 
for a handful of layouts supported by the DB1x/PB1x boards, but those don't 
fit. This needs more research though.
- a default configuration file would be nice, but optional.
- the mentioned BCSRs are used to control some peripherals. Code that uses 
them needs to be changed.

All in all, I'd just write a different board_setup() routine than the one for 
DB1100 and have a few #ifdef HAVE_DB1x00_BCSR and be done. I'd even make this 
a subtype of the 'standard' DB1100 configuration, because of its strong 
similarities, but there are a few cases where I simply need to determine the 
type in the code.

I'd send a patch for discussion, but I'm far from finished yet. If there are 
any pitfalls I should watch out for or you have any suggestion how to tackle 
this problem, I'm all open ears.

thanks

Uli