LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Jonathan Masel" <jmasel@arabellasw.com>
To: "'McMullan, Jason'" <jason.mcmullan@timesys.com>
Cc: 'PPC_LINUX' <linuxppc-embedded@ozlabs.org>
Subject: RE: Arabella Resource Manager
Date: Thu, 19 May 2005 18:37:28 +0200	[thread overview]
Message-ID: <E1DYn5o-0000PK-00@gold.webfusion.co.uk> (raw)
In-Reply-To: <1116509554.9050.127.camel@jmcmullan.timesys>

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

      reply	other threads:[~2005-05-19 15:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-18 15:26 Arabella Resource Manager Jonathan Masel
2005-05-19 13:23 ` Pantelis Antoniou
2005-05-19 13:32 ` McMullan, Jason
2005-05-19 16:37   ` Jonathan Masel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1DYn5o-0000PK-00@gold.webfusion.co.uk \
    --to=jmasel@arabellasw.com \
    --cc=jason.mcmullan@timesys.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox