Second Attempt: Driver model usage on embedded processors

Second Attempt: Driver model usage on embedded processors

[Kumar Gala]

I'm looking at moving support for PowerPC System on a Chip devices to 
using the 2.6 driver model.  I think may issues may apply to any system 
on a chip device. I have a few issues, however one is holding up 
progress.  I think the best way to ask my question is with an example:

On a given chip we have an ethernet controller that is directly 
available to the CPU.  The ideas is that this device would be a 
platform device.  The issue is that this controller may have several 
minor variations on the same chip or between chip models.  We have 
written a single driver to handle these variants.  Variants may 
include, support for Gigabit, support for RMON, support for interrupt 
coalescing.  Additionally, the driver needs to be based some 
information that is board specific.  Such as which PHY, at what PHY id, 
does the PHY have an interrupt, etc.

The intent was that I would use the platform_data pointer to pass board 
specific information to the driver.  We would have board specific code 
which would fill in the information.  The question I have is how to 
handle the device variant information which is really static?

Possible solutions I've come up with:
1. use a struct resource for the flags that describe ethernet variants
- Add a new resource type
- steal a bus specific resource type
2. create a super structure that platform_data points to which contains 
the flags and a board_data pointer

The issue I've got with #2 is that some of these devices (and therefor 
drivers) will end up existing on various parts from Freescale that 
might have an ARM core or PPC core.  I'd prefer a solution that did not 
impose restrictions on how an arch does things.

I a few other questions about headers and were to put things, but 
that's secondary.

- kumar

Re: Second Attempt: Driver model usage on embedded processors

[McMullan, Jason]

On Mon, 2004-12-06 at 23:03 -0600, Kumar Gala wrote:
> The intent was that I would use the platform_data pointer to pass =
board=20
> specific information to the driver.  We would have board specific code =

> which would fill in the information.  The question I have is how to=20
> handle the device variant information which is really static?

I use a 'struct device_ethernet_data' in my MPC85xx platform-device
patches at http://www.evillabs.net/~gus/patches

That seems to work well, and we could move it from
include/asm-ppc/device-ethernet.h to include/linux/device-ethernet.h to
make it more arch-independant. That covers MAC addrs and phy locations.

As for PHY IRQ, that's a thornier issue. For now, I put that in the
ethernet device's resource list.

--=20
Jason McMullan <jason.mcmullan@timesys.com>

Re: Second Attempt: Driver model usage on embedded processors

[Dan Malek]

On Dec 7, 2004, at 12:03 AM, Kumar Gala wrote:

> The intent was that I would use the platform_data pointer to pass 
> board specific information to the driver.  We would have board 
> specific code which would fill in the information.  The question I 
> have is how to handle the device variant information which is really 
> static?

Why don't you just use the feature_call() model like we currently
use for PowerPC on the PMac?  Isolate those places in the driver
that need that information and call the function with a 
selector/information
request (and varargs) to get it.  This seems much more flexible
because we don't have to ensure the data structure contains all possible
information for all platforms, we don't have to invent a list of
functions to call that just return that information, and worse, have
to go back and update everyone when we realize we forgot a
piece of necessary information for one particular implementation.

There can be a standard list of information requests, it can easily
be extended for boards that may need to do some special processing
either to enable or retrieve such information, and the driver can
determine an appropriate course of action if the function returns a
status that it can't handle the request.

> The issue I've got with #2 is that some of these devices (and therefor 
> drivers) will end up existing on various parts from Freescale that 
> might have an ARM core or PPC core.

If the configuration options are truly static, we can do just like we 
do today
with processor cores that share similar peripherals.  Just #define 
those things
that are constants and compile them into the driver.  These could be 
address
offsets, functional support (like RMON), and so on.  There are examples
of these drivers that work fine today and could work even better with 
minor
touch ups of the configuration options.  You have already #define'd this
stuff in the board/processor configuration files.  Why put them into a 
static
data structure and then find some complex method to access it?  These
are embedded systems, after all, that want to minimize overhead.

For those things that are dynamic or based upon a particular set of
drivers selected (either as loadable modules or static linked), you can
use the feature_call() (or whatever we want to name it).  For example,
a driver could:

feature_call(SOC_FTR, Fast_Ethernet1, INIT_IO_PINS);

to configure the IO pins associated with the device, then it could:

feature_call(SOC_FTR, Fast_Ethernet1, GET_CLKS, &txclk, &rxclk);

to get the routing for the transmit and receive clocks, and finally:

feature_call(SOC_FTR, Fast_Ethernet1, GET_PHY_IRQ, &phy_irq);

to get the external interrupt number associated with the PHY.

If the feature_call() returns a status that the request couldn't be 
processed,
the driver can choose a default course of action.  This could be to
simply bail out with an error, or it could choose some common and
reasonable default configuration.  In the case of a PHY interrupt,
it could simply enter a polled mode if an interrupt is not provided.

Using the call out function doesn't place any restrictions on the driver
data structure formats.  The board can choose how it wishes to represent
the data, which it could fetch from flash, from a command line argument,
from some start up configuration, whatever it wishes.  It can also 
perform
any board specific operation necessary to enable/activate the 
peripheral.
For example, as part of INIT_IO_PINS, it could also configure some board
control register if there is external routing of signals through a 
logic device
or to enable power to the PHY.  It also allows "extending" the driver if
some board/processor needs an additional set up or control that others
don't.  The board/processors that don't need that function can simply
return from the call doing nothing, so no harm done (and requiring no
software updates to existing board ports), while this new 
board/processor
gets the needed function call.

Thanks.


	-- Dan

Re: Second Attempt: Driver model usage on embedded processors

[Sylvain Munaut]

Dan Malek wrote:

> Why don't you just use the feature_call() model like we currently
> use for PowerPC on the PMac?  Isolate those places in the driver
> that need that information and call the function with a 
> selector/information
> request (and varargs) to get it. 


> For example,
> a driver could:
>
> feature_call(SOC_FTR, Fast_Ethernet1, INIT_IO_PINS);
>
> to configure the IO pins associated with the device, then it could:
>
> feature_call(SOC_FTR, Fast_Ethernet1, GET_CLKS, &txclk, &rxclk);
>
> to get the routing for the transmit and receive clocks, and finally:
>
> feature_call(SOC_FTR, Fast_Ethernet1, GET_PHY_IRQ, &phy_irq);
>
> to get the external interrupt number associated with the PHY.
>

FWIW, I really like this model.

Just as another example, for the I2C driver i2c-mpc, almost the only
variation between model is the clock selection and that forced to put
some processor specific stuff into the driver. With that model, you could
easly avoid theses platform/cpu specific stuff and isolate them.

USB with some really alike bus glues comes to mind too ...

Being able to do "action" in plus of just passing parameters is really nice
IMHO.


    Sylvain

Re: Second Attempt: Driver model usage on embedded processors

[Andy Fleming]

On Dec 7, 2004, at 08:53, Dan Malek wrote:
>> The issue I've got with #2 is that some of these devices (and 
>> therefor drivers) will end up existing on various parts from 
>> Freescale that might have an ARM core or PPC core.
>
> If the configuration options are truly static, we can do just like we 
> do today
> with processor cores that share similar peripherals.  Just #define 
> those things
> that are constants and compile them into the driver.  These could be 
> address
> offsets, functional support (like RMON), and so on.  There are examples
> of these drivers that work fine today and could work even better with 
> minor
> touch ups of the configuration options.  You have already #define'd 
> this
> stuff in the board/processor configuration files.  Why put them into a 
> static
> data structure and then find some complex method to access it?  These
> are embedded systems, after all, that want to minimize overhead.

The issue here is that the driver supports devices which can vary in 
features on the same processor.  An example is the gianfar driver for 
the 8540.  The driver supports the two TSEC devices, as well as the 
FEC.  In order to make the driver applicable to different processors 
with different device configurations, the driver needs to be agnostic 
about how many devices there are, and what features they have.  As 
such, defining constants does not solve the problem.

These things could be assigned statically at compile time, in the 
driver, but this means that every new processor will require adding 
#ifdefs to the driver, which will become progressively more difficult 
to maintain.

Anyway, I like the idea of using feature_call.  Are we sure, though, 
that it's not using a hammer for a screw?  I'm not very familiar with 
the function's intent.


Andy Fleming
Open Source Team
Freescale Semiconductor, Inc

Re: Second Attempt: Driver model usage on embedded processors

[Dan Malek]

On Dec 8, 2004, at 11:10 AM, Andy Fleming wrote:

> .....  An example is the gianfar driver for the 8540.  The driver 
> supports the two TSEC devices, as well as the FEC.

No, it doesn't.  The TSEC and CPM FCC are very different devices that 
are
supported by different drivers.  The FEC is used/shared on 8xx and 5xxx.
Some of us have chosen to design 85xx boards that use the TSEC0 for MDIO
control of all of the PHYs, even those on the FCC, but we aren't doing
to discuss that here :-)

>  In order to make the driver applicable to different processors with 
> different device configurations, the driver needs to be agnostic about 
> how many devices there are, and what features they have.

How can you be agnostic about features and still support them? :-)
A driver has to know exactly what features it can support, and can then
be configurable to support some subset in various combinations.


> Anyway, I like the idea of using feature_call.  Are we sure, though, 
> that it's not using a hammer for a screw?  I'm not very familiar with 
> the function's intent.

It's been proven to work very nicely on the PMac to solve the same kind
of configuration challenges.  Drivers have call outs to feature calls 
that
can manage the same logical feature although the boards have very
different underlying implementations.  With something like the 8xx(x),
externally the system can have very different IO pin usage for the
routing of signals for data/clocks, plus they often have external logic
with another level of switching and control.  Depending upon which
drivers you load, you can route the signals dynamically to use many
different functions.  Functionally, the driver still does the same 
thing,
it just needs places within the code to call these board specific
functions to do the management of IO pins.  Some boards may do
nothing, others may have to execute non-trivial code to get the bits
flowing.  The driver doesn't care, it just asks for it to be done 
through
the feature call.  The feature_call is implemented on PowerPC as
inline/macro with indirect function pointer.  Different architectures
could choose to define this differently in their machdep.h, making
it a no operation or extending it as necessary.

Trying to find some "driver model" data structure to make this happen
isn't likely.  This challenge has existed for years, we started to
address it with the old SCC Ethernet driver.  It never went anywhere
because people just kept hacking the driver to suit their needs.
There are reasons to use the OCP-like driver model for some
functional configuration, but you can't create data structures with
information and "agnostic" drivers that can do the special processing
needed across all of the embedded boards.  It failed when the
drivers were very platform specific, and now if you want to
expand the use of common drivers across more platforms,
it only makes it harder.

We are talking about solving two different problems.  One is
a generic " ... which peripherals do I want to configure and
where are they in the resource space ... "  and the other
is " .. how do I route the external signals, control
board specific external logic to make bits flow, and
retrieve external information ... "   The OCP does
the former, the feature call does the latter.

Thanks.


	-- Dan