Re: [PATCH] OMAP PM interface, version 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"ext Paul Walmsley" <paul@xxxxxxxxx> writes:

> Hello Jouni, 
>
> On Wed, 18 Jun 2008, Högander Jouni wrote:
>
>> "ext Paul Walmsley" <paul@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux