Arabella Resource Manager

Arabella Resource Manager

[Jonathan Masel]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

Hi all,
Several people have expressed an interest in seeing some more of our
Resource Manager - a kernel library for allocating/releasing on-chip
resources of all PQ processors. We currently have PQ1, PQ2 and PQ3 for 2.4
and 2.6 kernels.

Attached are some of our Resource Manager files. It's not complete - just
some "documentation" and examples. If you'd like to see more, please just
let me know.

resmgr.c - is the generic part of the Resource Manager pq2rm.c - is the part
of RM that is specific to all PQ2 family members pqfcc_enet.c - is an
FCC/Eth driver using the Resource Manager mpc8260ads.c - a board-specific
file for the 8260ADS

To get the gist of it (and without getting too long-winded here) - take
parallel pin assignment in the FCC/Eth driver as an example.
In pqfcc_enet.c we find the board-specific configuration choices by using
pqboard_get_port_config (which is in the board-specific file). Specific pins
are then set/cleared by calling pq_pin_set (or clear, program, ...). This is
located in pq2rm.c.

pq_pin-set uses the generic RM code to allocate a resource of this type (a
parallel I/O bit), check that it is not already in use, attach it to its
consumer and so on.

We don't have ANY board-level dependencies anywhere in our drivers outside
mpc8260ads.c. More than that - the FCC driver is completely independent of
the chip itself (across any of the PQ2's or even PQ3's) since this level of
dependency is handled inside the Resource Manager. If it's the same FCC in
the chip, the driver is supposed completely unchanged.

You can see in the source files that the RM handles allocation of clocks,
GPIO, internal DPRAM and communication channels in the same way.

We are in the process of updating this for platforms too. 

Best regards,

Jonathan

[-- Attachment #2: resmgr.tar.bz2 --]
[-- Type: application/octet-stream, Size: 41026 bytes --]

Re: Arabella Resource Manager

[Pantelis Antoniou]

Jonathan Masel wrote:
> Hi all,
> Several people have expressed an interest in seeing some more of our
> Resource Manager - a kernel library for allocating/releasing on-chip
> resources of all PQ processors. We currently have PQ1, PQ2 and PQ3 for 2.4
> and 2.6 kernels.
> 
[snip]
> 
> 

Jonathan, I see that you use a proc interface for status.
You could use the seq_file abstraction and clean up the code there.

Also could you just list the categories of the thing you manage
on the list so that we can comment per category?

Regards

Pantelis

Re: Arabella Resource Manager

[McMullan, Jason]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Interesting code, but not generic enough.
What would be nicer would be an API like the following, that can be
easily extended, and work for more than just PQ (and ppc, for that
matter)

enum bres_type {
	BRES_TYPE_CLOCK = 0,
	BRES_TYPE_PIN,
	BRES_TYPE_CPM_SRAM,
	...
	BRES_TYPE_MAX,
}

struct bres_pool {
	struct resource *pool;
	int (*set)(int id, ...);
	int (*clear)(int id);
};

/* Board setup will set up the available regions
 * into this array, similar as to how the PCI 
 * system sets up the iomem areas.
 */
struct bres_pool *board_resource[BRES_TYPE_MAX];

/* Request a resource out of the available pools
 */
int bres_request(enum bres_type type, const struct resource *req);

/* Free a requested resource 
 * This also calls the 'clear' function of the pool.
 */
int bres_release(enum bres_type type, const struct resource *res);


/* After request completes, you can 'instance'
 * the resource.
 */

/* Wire a pin
 * pin is the same as you requested in the resource
 * pin type is defined in either the board or SoC CPU headers
 *  (ie CPM_PB17_SDL)
 */
static inline int bres_pin_wire_as(int pin, int pin_type)
{  return board_resource[BRES_TYPE_PIN].instance(pin, pin_type); }

/* Wire a clock
 */
static inline int bres_clock_wire_as(int clock, int clock_target,
			int multiplier, int divider)
{  return board_resource[BRES_TYPE_CLOCK].instance(pin, pin_type); }

...etc....



-- 
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Arabella Resource Manager

[Jonathan Masel]

Hi Jason,
The code is actually much more flexible than that. I only sent a sample
yesterday (you got down to the nitty-gritty a little quicker than I had
thought!). I've uploaded all RM source code to our FTP server
(ftp.arabellasw.com - user ft.rm, passwd arabella). There's no real
documentation (outside source/comments) on the internals - sorry.

Chip-specific code registers the resource types, etc something like you
suggest. API's can be at the very generic RM level (see resmgr.h) but a chip
driver would usually operate at the more convenient chip-level interface.
So, the chip-specific RM code decides which types of resources can be
alloc/freed by the RM (for PQ's that's usually xcc, clocks, pins and dpram)
and the parameters necessary in each case.

We've never used it (yet) outside PQ family, though I don't see any reason
why it can't be.

The files in the tar file (misnamed resmsg.gz.tar!) are
pq1brddef.h - PQ1-specific board definitions
pq1defs.h - PQ1-specific chip definitions
pqrm.c - PQ1-specific RM code (should be called pq1rm.c!)
pq1rm.h - PQ1-specific RM definitions

pq2brddef.h - PQ2-specific board definitions
pq2defs.h - PQ2-specific chip definitions
pq2rm.c - PQ2-specific RM code
pq2rm.h - PQ2-specific RM definitions

pq3brddef.h - PQ3-specific board definitions
pq3defs.h - PQ3-specific chip definitions
pq3rm.c - PQ3-specific RM code
pq3rm.h - PQ3-specific RM definitions

pqbrddef.h - PQ family board-specific information
pqdefs.h - PQ family chip definitions
pqrm.h - PQ family RM code

resmgr.c - generic RM code
resmgr.h - generic RM definitions

Jonathan


Jason wrote:
> 
> Interesting code, but not generic enough.
> What would be nicer would be an API like the following, that can be
> easily extended, and work for more than just PQ (and ppc, for that
> matter)
> 
> enum bres_type {
> 	BRES_TYPE_CLOCK = 0,
> 	BRES_TYPE_PIN,
> 	BRES_TYPE_CPM_SRAM,
> 	...
> 	BRES_TYPE_MAX,
> }
> 
> struct bres_pool {
> 	struct resource *pool;
> 	int (*set)(int id, ...);
> 	int (*clear)(int id);
> };
> 
> /* Board setup will set up the available regions
>  * into this array, similar as to how the PCI
>  * system sets up the iomem areas.
>  */
> struct bres_pool *board_resource[BRES_TYPE_MAX];
> 
> /* Request a resource out of the available pools
>  */
> int bres_request(enum bres_type type, const struct resource *req);
> 
> /* Free a requested resource
>  * This also calls the 'clear' function of the pool.
>  */
> int bres_release(enum bres_type type, const struct resource *res);
> 
> 
> /* After request completes, you can 'instance'
>  * the resource.
>  */
> 
> /* Wire a pin
>  * pin is the same as you requested in the resource
>  * pin type is defined in either the board or SoC CPU headers
>  *  (ie CPM_PB17_SDL)
>  */
> static inline int bres_pin_wire_as(int pin, int pin_type)
> {  return board_resource[BRES_TYPE_PIN].instance(pin, pin_type); }
> 
> /* Wire a clock
>  */
> static inline int bres_clock_wire_as(int clock, int clock_target,
> 			int multiplier, int divider)
> {  return board_resource[BRES_TYPE_CLOCK].instance(pin, pin_type); }
> 
> ...etc....
> 
> 
> 
> --
> Jason McMullan <jason.mcmullan@timesys.com>
> TimeSys Corporation