Re: Adding PM QoS parameters

[Matteo Carnevali <rekstorm@gmail.com>]

Premi, Sanjeev <premi <at> ti.com> writes:

> 
> Sorry, picking-up thread late...
> 

Hi, I'm Matteo Carnevali and I'm working in ST with Patrick on the topic of CPM.

> 
> Would like to see more of this before real comment; because I
> am trying to see what could happen if 2 drivers sharing a
> common parent clock try to change the freq in 2 different
> directions.
> 

Of Course, the QoS should always be granted, at least as long as system 
resources are available by the hardware.

In a real context is not so common that drivers (different from the cpu drivers 
like cpufreq or cpuidle) explicitly ask to lower cpu frequency, the cpufreq 
driver can do that but it relies on the governor which monitors the cpu load 
and consequently tunes the frequency.

Moreover the cpu frequency cannot be considered as an abstract parameter, but
something very related to the physical architecture. A device driver, in our 
ideas, cannot state "I now need more than 200Mhz to the cpu"...

However, two conflicting requests on an abstract parameter will be actually 
treated as a conflict and the framework core (the controller) or a governor 
associated to the framework will avoid to work on such proposal.
Anyway, the framework core should not be considered as a central entity that 
manages the control telling the driver how to act under certain circumstances, 
this is a feature of "Centralized power management" and it is not our idea.

Moreover, it is also not very possible that two requests to change the value of 
an abstract parameter (i.e. set a constraint on a parameter) happen exactly at 
the same time.

> 
> Once a requested level is achieved the requester should be
> notified for possible reconfiguration. It could be via an
> optional registration.
>

Yes, this is can be done with the notification chain.
Writing about the Best Effort approach of pmqos, we wanted to be sure we 
correctly pointed out a possible limitation of pmqos it self and we would like 
to know if you agree on this. 

> 
> So, again we are again looking at means to add more constraints
> and also the "kind" of constraint.
> 

> 
> We could start with a smaller set, e.g.:
> - Interrupt latency (in lieu of DMA latency)  
> - Sleep lateny (to control sleep in absence of cpuidle)
> - Cpu frequency
> - Cpu voltage
> 
> Of course, when we extend this to SoCs with multiple
> CPUs then we do have (possible) need of multiplicity
> if one of these has to act as "master".
> 
> e.g. OMAP3 allows ARM and IVA voltages and frequency
> to be changed independently.
> 

Specific hardware and platform feature should be kept confined in the driver 
code and not brought directly at framework level, i.e translated in parameters; 
on the other hand, the mapping among device operating modes (aka local driver 
configuration) and abstract parameters should be performed inside the device 
driver to support the framework.

> 
> On the first read, I believe abstract parameter+level combination
> can help us achieve the appliation portability across architectures
> and allow specific map most suitable for each arch.
> 

> 
> I am not sure if I understood this completely, but I believe
> that abstract -> specific mapping should be done at system level.
> Letting drivers define them, may not be portable; and might lead
> to more confusion.
> 

We can consider to have two mappings:
1) mapping between the driver local configuration and the abstract parameters.
Hence, if abstract parameter are well defined and a device driver is well 
written to support them and correctly maps its operating modes to the 
parameters, there should not be confusion.
Let's consider a NIC driver with 3 operating modes and just one abstract 
parameter, the bandwidth:

op mode   ---mapping---    bandwidth 

idle <----------------->   0
low power <------------>   0-20 Mbit/s
max power <------------>   0-54 Mbit/s

this is just a dummy example...

Drivers using this framework should of course correctly implement the framework 
API.

2) mapping between the platform code and the abstract parameters, which allows 
the hierarchical binding of platform specific resources and the abstract 
parameters

If we consider the example of the NIC driver, let say that it uses an SPI bus to 
transfer data to the SoC: the NIC declares it wants at least x bandwidth on the 
bus by setting a constraint on that abstract parameter. At this point the 
platform code has the job to assign the correct SPI channel for that request and 
can do that thanks to its mapping with the abstract parameter.
The NIC driver itself does not know at which SPI channel is attached. It just 
sets a constraint on a abstract parameter.

> 
> Agree.
> 

> 
> ...if we get rope closer to ground, gravity doesn't harm much!
> 

> 
> Generic params that impact the apps could/should be an array;
> while arch/plat specific ones could be a linked list.
> 
> Best regards,
> Sanjeev
> 


best regards,
Matteo


<-------------------------------------------------------------------->
  Matteo Carnevali < rekstorm at gmail dot com>
  Master student at Politecnico di Milano

<-------------------------------------------------------------------->

> > 
>