RE: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w

["Rajendra Nayak" <rnayak@ti.com>]

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net] 
> Sent: Thursday, October 16, 2008 11:58 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
> 
> On Thursday 16 October 2008, Rajendra Nayak wrote:
> > +       /* Function to change the level of the resource */
> > +       int (*change_level)(struct shared_resource *res, 
> u32 target_level);
> > +       /* Function to validate the requested level of the 
> resource */
> > +       int (*validate_level)(struct shared_resource *res, 
> u32 target_level);
> 
> What is a "target_level" supposed to represent?  Are they
> even comparable, in the senses that
> 
>   (a) "42" for one resource is the same as "42" for another?
>   (b) "42" includes "41", "40", etc?
> 
> There's no documentation at all on what seems to be a
> fairly fundamental concept.  Or on the rest of it either;
> the call syntax information is no real help.  What kind
> of "resource" is involved, that might need a "level"?

I'll try and put in some more details on the design. Whats essentially 
planned is a framework to model "shared multi level" resources.
target_level and supported levels for each resource type might vary 
and are platform specific and defined in the platform specific header file.
(In this case resource34xx.h file in mach-omap2)

Shared Multi level Resources currently planned to be modeled are Power-domain-latencies 
(would have different latencies based on what state (RET/OFF) it enters 
and hence multi level) and OPP/Frequency resources (Will have mutlitple levels 
each representing a defined OPP).

So for instance, for a VDD1-OPP resource a DSP load pridictor would request for OPP2
based on its predictions and CPUFreq might request OPP3 based on the ARM load. 
The F/w then *sums* up all the requests and decides on whats the best *target_level*
for the resource which keeps everyone happy.  
  
> 
> Also, I suspect a flat namespace for all resources will
> be a net lose.  Why isn't it scoped by devices, so that
> device-relative "logical names" can be used instead of
> requiring what have tended to be platform-specific and
> very mutable "physical names"?  I notice that the call
> to request a resource is already device-scoped ...
> 
> - Dave
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html