Greg On Mon, May 2, 2022 at 12:13 PM Tanjore Suresh <tansuresh@xxxxxxxxxx> wrote: > > On Sat, Apr 30, 2022 at 12:52 AM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > A: http://en.wikipedia.org/wiki/Top_post > > Q: Were do I find info about this thing called top-posting? > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > A: Top-posting. > > Q: What is the most annoying thing in e-mail? > > > > A: No. > > Q: Should I include quotations after my reply? > > > > http://daringfireball.net/2007/07/on_top > > > > On Fri, Apr 29, 2022 at 11:03:07AM -0700, Tanjore Suresh wrote: > > > Rafael, > > > > > > That is a good observation, however, many of the use cases in data > > > centers (deployment of devices in data centers) do not exploit device > > > power management. Therefore, I'm not sure that is the right way to > > > design this. > > > > Yes it is, enable device power management and use that interface please. > > Devices in data centers should of course be doing the same thing as > > everyone else, as it actually saves real money in power costs. To not > > do so is very odd. > > > > I guess we are intermixing the terminology of device power management > with shutdown. > My second, third reasoning in my previous e-mail, thought it brings > out that difference. Maybe not. > I will try one more time, my thought process on this one. > > This patch is only for shutdown. The shutdown can be done in a system > in various flavors, > (this may include a power being pulled from the system components when > all the devices > are quiescent and it can also be soft shutdown, where power is not > removed from the system, but system > could be attempting a reboot) > > The device power management allows the device to bring down any > devices that may be idle to various power states that > device may support in a selective manner & based on the transition > allowed by the device. Such a transition initiated by > the system can be achieved using the 'dpm' interface for runtime power > management (more for extending laptop battery life). > It can also be exploited for system sleep models (suspend and resume - > where state is preserved and restarted from where it left off > --> More applicable for laptops/desktops). That does not mean data > center devices cannot exploit, but they worry about slight latency > variation in any > I/O initiated to any device. Such power management could introduce > more latency when it transitions from one state to another. > Therefore, the use case is more apt for Laptops, in certain cases > desktops in my opinion or understanding. > > The shutdown entry point has been traditionally different and the > semantics is that the whole system is going down to a > quiescent state and power may be pulled or may not be, IMO, i am > seeing both are independent requirements, in my view. > Let me know if I am mistaken. I am not sure why we should break the > shutdown semantics as understood by driver developers and > overload it with dpm requirements? > I have not seen additional comments, I request your help in moving this further, please. If i have missed something, Please let me know. Thanks sureshtk > Thanks > sureshtk > > > > thanks, > > > > greg k-h
