Dan Malek wrote: > > On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote: > >> In my experience it's much easier to configure these things once. >> Hunting down where the driver modifies pins & clocks is a nightmare, if >> you ever use a non standard configuration. > > > That doesn't quite work, as we have discussed before. The problem with > setting them in the board set up is you can have loadable modules and > select among several different IO pin configurations depending upon > what you load. So, the plan is to have the drivers make a generic > call out request using feature_call() to the supporting functions in the > board specific directory. This is for more than just IO pin > configurations, > since boards may have power management or other external logic that > has to be routed to the physical interface. For example, the SCC Ethernet > driver will perform a feature_call() during set up requesting any necessary > configuration for SCC2. The board specific function can chose to ignore > this and get the "default" configuration, or to do whatever is necessary > unique to the board to enable the external data path. All that drivers > know > is there are a couple of specific places where they need configuration > assistance, they don't care what the specific board has to do. >
Sounds nice. I'm a much simpler guy it seems :) > It's in the works and nearly done for a few example 85xx and 82xx > boards and CPM2 drivers. I'll be checking it in shortly. I just haven't > decided if I want a varargs list or a data structure for passing the > information and results. > Mind sharing? > Thanks. > > -- Dan > > > Regards Pantelis
