RFC: [PATCH] platform device driver model support

Kumar Gala kumar.gala at freescale.com
Thu Jan 13 01:41:27 EST 2005


On Jan 12, 2005, at 2:36 AM, Eugene Surovegin wrote:

> On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
>  >
> > Please take a look at the following patch.  It adds driver model 
> support
> > via platform devices to 85xx.  This is originally based on patches 
> from
> > Jason M.
> >
> > The idea behind the code is that for a give family: 4xx, 8xx, 82xx, 
> 83xx,
> > 85xx, 86xx we will have structure defns for the following:
>  >
> > enum ppc_soc_devices
>  > in asm-ppc/<family.h>:
> >   list of all unique devices in the family
>  >
> > struct platform_device soc_platform_devices[]
> > in arch/ppc/platforms/<family>/<family>_devices.c:
> >   describes all platform devices that exist in the family
>  >
> > struct soc_spec soc_specs[]
>  > in arch/ppc/platforms/<family>/<family>_soc.c:
> >   describes each unique chip in the family and what devices it has
>
> Well, there is a problem right here at least for 4xx.
> Current OCP implementation is much more flexible IMHO.
>
> For 4xx is not uncommon when you have the same "logical" device at the
> different places with different "properties" (e.h. different channel,
> etc).
>
> Your case (85xx) looks simpler - all you need is a list of devices
> which particular SoC supports, without significant differences in
> "properties". This will not work that easy for 4xx.
>
> 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.
>
> Please note, using platform_device is orthogonal to the way we
> describe each SoC (this is what I don't quite like in your patch), and
> I don't have any strong objections to using platform_device instead of
> OCP or feature_call or whatever for communication with device drivers.

I need to understand a bit more about how 4xx does things.  When I 
started the SOC stuff, it was freescale specific.  I agree that its 
orthogonal to the use of platform device.  Does this some like a bad 
idea for the fsl case?

> > Plus the following functions:
>  >
> > identify_soc_by_id() -- determine soc by an int id
> > identify_soc_by_name() -- determin soc by name (useful in some 82xx 
> cases)
>  > ppc_soc_get_pdata() -- get platform_data pointer so board code can 
> modify
>  > ppc_soc_update_paddr() -- update iomem resources with a given paddr
>
> IMHO, ppc_soc_update_paddr - is a very confusing name, in fact, from
> first read I though it _changes_ paddr to the new value, not _adds_ it
> :)
>
> Probably this function should be made 85xx specific as I cannot come
> up with any use for it in 4xx (we don't have anything similar to
> CCSRBAR ;).

Not an issue, any suggestions on renaming to make it clear what it 
does?  Also, I can make this fsl_increment_paddr() since its useful to 
more than on family of fsl processors.

> [snip]
>
> > +
>  > +struct platform_device soc_platform_devices[] = {
>  > +     [MPC85xx_TSEC1] = {
>  > +             .name = "fsl-gianfar",
>  > +             .id     = 1,
>  > +             .dev.platform_data = &mpc85xx_tsec1_pdata,
> > +             .num_resources   = 4,
>  > +             .resource = (struct resource[]) {
>  > +                     {
>  > +                             .start  = MPC85xx_ENET1_OFFSET,
> > +                             .end    = MPC85xx_ENET1_OFFSET +
>  > +                                             MPC85xx_ENET1_SIZE - 
> 1,
>  > +                             .flags  = IORESOURCE_MEM,
> > +                     },
>  > +                     {
>  > +                             .name   = "tx",
>  > +                             .start  = MPC85xx_IRQ_TSEC1_TX,
> > +                             .end    = MPC85xx_IRQ_TSEC1_TX,
> > +                             .flags  = IORESOURCE_IRQ,
> > +                     },
>  > +                     {
>  > +                             .name   = "rx",
>  > +                             .start  = MPC85xx_IRQ_TSEC1_RX,
> > +                             .end    = MPC85xx_IRQ_TSEC1_RX,
> > +                             .flags  = IORESOURCE_IRQ,
> > +                     },
>  > +                     {
>  > +                             .name   = "error",
>  > +                             .start  = MPC85xx_IRQ_TSEC1_ERROR,
> > +                             .end    = MPC85xx_IRQ_TSEC1_ERROR,
> > +                             .flags  = IORESOURCE_IRQ,
> > +                     },
>  [snip]
>
>
>
> I already wrote about this but repeat again :(.
>
>  Why put all these defines (e.g. for memory regions) into header when
> the only user is this particular file. It doesn't help readability and
>  only obfuscates sources (and 4xx is a very good example of such mess
> :)

Understood, I forgot about this.  I've got now issue with changing it, 
just trying to minimize changes.

thanks

- kumar




More information about the Linuxppc-embedded mailing list