RFC: [PATCH] platform device driver model support

[Kumar Gala]

Andrew,

What I have already done should be able to handle your situation, 
assuming you can identify the two processor variants with a 32-bit 
integer or a string.  In your board code you determine which variant 
you are and then the device list will get registered based on that.

- kumar

On Jan 14, 2005, at 1:13 PM, Andrew May wrote:

> On Wed, 2005-01-12 at 14:14 -0700, Matt Porter wrote:
>  > On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
>  > > On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
>  > >
> > > In fact, I don't see any gain (at least for 4xx) in all these 
> changes.
> > > It makes 4xx much more tangled IMHO, because we'll still need all
> > > those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
>  >
> > Summarizing some stuff from IRC (now that I'm caught up after time
>  > off :P), I think we can live with this on 4xx. What seems to be
>  > acceptable is that we can have an soc_specs[] and 
> soc_platform_devices[]
> > in each 4xx SoC platform file. So, core_ocp[] can be merged and split
>  > into soc_specs[]/soc_platform_devices[]. The active one will be 
> selected
> > at build time just like we do now. This is due to the static nature
>  > of the 4xx memory map (per SoC) and well as the variation in 
> location
>  > of iomem and irq resources as well as platform_data. Our soc_specs[]
>  > will only have one SoC in it, since there is one per file. Doing
>  > something like 85xx will scatter info about as you point out
>  > above...and that doesn't make sense for 4xx.
>
> I would like to bring the Virtex-II Pro, into the thinking as well. It
>  is an FPGA around the 405 so it can be much more flexible on what 
> makes
>  up the SoC.
>
> I am stuck working on 2.4 for a non-released product (so no code to
>  submit) and we have 2 of these chips on 1 board.
>
> One has only 1 UART and the other has 2. The rest of the standard
>  devices are the same, but they all have different IRQ mappings.
>
> I really don't want to build 2 different kernels just to handle this. 
> So
> far I have just overwritten the OCP struct at boot time to deal with 
> it,
>  based on a HW reg that tells me which chip I am running on. I also did
>  a kernel cmd line option saved in u-boot before I got the HW reg.
>
> If FPGAs start to make up more of the SoC market it don't think a 
> simple
>  array of the devices is a good model to have. The FPGA could be loaded
>  differently for special modes with a very different setup.
>
> I am not sure what the trade off should be for the simple build time
>  array compared to the run time list that is built up.
>
> Would something like this be OK?
>
> struct chip_basic_features[] = { {}, {},....... };
>
> struct chip_ext1_features[] = { {}, {},....... };
>  struct chip_ext2_features[] = { {}, {},....... };
>
> LIST_HEAD(system_features);
>
>
>
> board_init()
>  {
>          list_add_tail( &system_features, &chip_basic_features );
>
>         if( board1 ){
>                  list_add_tail( &system_features, &chip_ext1_features 
> );
>          }else{
>                  list_add_tail( &system_features, &chip_ext2_features 
> );
>          }
>  }