Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice

Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice

[Jonathan Masel]

Are you interested in looking at our Resource Manager? It works in 2.4 and
2.6 kernels for a wide range of PQ's (virtually all of them).

It seems to take some of these ideas, but further. The basic idea is to
handle at all on-chip resources in an orderly and robust way (not just
modularly, but that too). We allocate parallel port pins, clocks (BRG or
CLK), internal DPRAM and communication channels to "consumers". Board
specific (if/where needed) are all located in a single per-board file.
Allocation is all dynamic and we can check that we're not conflicting with
prior requests. There are quite a few other goodies too (display all
consumers to which certain resources are allocated, etc).

This lets us easily handle dynamic configurations. E.g. configure pins for
I2C during reset or start-up, modify them later on when you need ATM (they
are multiplexed on the same pins on several devices). Or, as you mentioned,
dynamic modules - but even when they have potentially conflicting requests.

And it is one, simple to use mechanism that we use across all devices
(adapted for PQ1, PQ2 and PQ3).

If you're interested, please let me know. We'd be happy to contribute it if
it will help.

Jonathan

Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice

[Pantelis Antoniou]

Jonathan Masel wrote:
> Are you interested in looking at our Resource Manager? It works in 2.4 and
> 2.6 kernels for a wide range of PQ's (virtually all of them).
> 
> It seems to take some of these ideas, but further. The basic idea is to
> handle at all on-chip resources in an orderly and robust way (not just
> modularly, but that too). We allocate parallel port pins, clocks (BRG or
> CLK), internal DPRAM and communication channels to "consumers". Board
> specific (if/where needed) are all located in a single per-board file.
> Allocation is all dynamic and we can check that we're not conflicting with
> prior requests. There are quite a few other goodies too (display all
> consumers to which certain resources are allocated, etc).
> 
> This lets us easily handle dynamic configurations. E.g. configure pins for
> I2C during reset or start-up, modify them later on when you need ATM (they
> are multiplexed on the same pins on several devices). Or, as you mentioned,
> dynamic modules - but even when they have potentially conflicting requests.
> 
> And it is one, simple to use mechanism that we use across all devices
> (adapted for PQ1, PQ2 and PQ3).
> 
> If you're interested, please let me know. We'd be happy to contribute it if
> it will help.
> 
> Jonathan
> 
> 

Hi Jonathan.

This is a good time for everyone working in freescale platforms to
just put on the table what it uses and see if a common ground can
be found.

So please post the files, and some comments on how they work.

Regards

Pantelis