> -----Original Message----- > From: David Brownell [mailto:david-b@xxxxxxxxxxx] > Sent: Thursday, October 16, 2008 11:58 PM > To: Rajendra Nayak > Cc: linux-omap@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
