ext Paul Walmsley [EMAIL PROTECTED] writes:
Hello Jouni,
On Wed, 18 Jun 2008, Högander Jouni wrote:
ext Paul Walmsley [EMAIL PROTECTED] writes:
Major changes since the first version:
1. Jouni Hogander suggested that the set_max_cpu_lat() function be
merged into set_max_dev_wakeup_lat(), when set_max_dev_wakeup_lat()
is called with the CPU0 sys_device (via get_cpu_sysdev(0)). He feels
that this will be easier for device driver developers to use. This
change has been made.
I just noticed that this won't work. We have this declaration:
(*pdata-set_max_dev_wakeup_lat)(struct device *dev, unsigned long t)
In case of cpu it is not possible to underlying code to identify the
caller.
Eh, nice catch. Let's add set_max_intr_lat() back in - perhaps call it
set_max_mpu_wakeup_lat() instead for symmetry?
Yes, I agree. Originally my idea to change this was related to that pm
qos extending and actually I didn't expect you to do this change.
This derives a question should we have parameter for caller
identification in set_max_dev_wakeup_lat()?
I mean currently we are assuming that there is only one caller for each
device. Is this correct assumination? If we think e.g. busses. There
might be drivers for devices on some specific bus. Each of them might
want to set latency constraint for the bus.
In the case of bus wakeup latency, all of the on-chip interconnects share
the same wakeup latency - the CORE powerdomain wakeup latency. So
set_max_dma_lat() covers all of the interconnect latencies.
Well I didn't mean interconnect busses here. I was thinking busses
like spi, which can have multiple devices on it. Drivers for theses
devices might want to set latency constraints for spi bus. In current
plan we are assuming that spi driver is the only one who sets the
latency constraint for spi bus. How could spi driver know what is the
spi latency requirement for the device that is connected to it?
We could call it set_max_bus_wakeup_lat(), with a prototype similar to
set_max_dev_wakeup_lat(), for consistency. (The bus agent argument would
effectively be ignored in OMAP2/3.)
Lets not change that, originally it was planned to control sdma
latency constraint, without caring that it actually affects also to
interconnect bus latencies. Is this plan changed? At some point it was
thought to be changed to set_max_sdma_lat(), right?
If we are some day at point where interconnect busses are modelled as a
bus, then adding set_max_bus_wakeup_lat() could be good idea. Further
if also sdma will be modelled as a platform device, then
set_max_dma_lat() could be removed and set_max_dev_wakeup_lat() used
instead for sdma.
Currently set_max_intr_lat() could be already removed with adding one
more parameter to set_max_dev_wakeup_lat():
set_max_dev_wakeup_lat(struct device *dev, struct device *req, unsigned
long t);
This is just an idea, please do not change:) Instead I think your idea
to change it back to what it was is better at this point.
--
Jouni Högander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
