Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: [...] >> Please create two different functions, >> omap_device_set_max_dev_wakeup_lat() and >> omap_device_set_min_bus_tput(). ÂDocumentation/CodingStyle chapter 6. >> > It has been agreed (in weekly calls) to have two functions at the OMAP > PM level but only one function with a class parameter at the > omap_device level. This allows easier maintenance and clean-up later. > Kevin, is that corrcet? Yes, that is my preference (but Paul is the maintainer of these layers, so he has the final say.) What I would like to see is a more generic API at the omap_device level which can easily be extended to handle new constraints (by adding a new 'class'), without having to grow the API each time. That being said, you can still create the two functions that Paul mentioned above and just have the generic function call those based on class. The only question then is which interface the drivers will eventually use. I much prefer keeping the driver interface to a simple set of add & remove constraint functions where the type is determined by class: Today we have: - max wakeup latency - min bus througput but eventually we may also want - min frequency - max frequency (thermal) - etc. Kevin -- 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
