Arabella Resource Manager

Jonathan Masel jmasel at arabellasw.com
Fri May 20 02:37:28 EST 2005


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 at timesys.com>
> TimeSys Corporation






More information about the Linuxppc-embedded mailing list