"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
