On 5/20/2020 1:44 PM, bbhatt@xxxxxxxxxxxxxx wrote:
On 2020-05-20 12:06, Jeffrey Hugo wrote:
On 5/20/2020 12:43 PM, bbhatt@xxxxxxxxxxxxxx wrote:
On 2020-05-20 09:54, Jeffrey Hugo wrote:
On 5/18/2020 2:03 PM, Bhaumik Bhatt wrote:
Allow independent votes from clients such that they can choose to vote
for either the device or the bus or both. This helps in cases where
the
device supports autonomous low power mode wherein it can move to M2
state without the need to notify the host. Clients can also vote
only to
keep the underlying bus active without having the device in M0
state to
support offload use cases.
Signed-off-by: Bhaumik Bhatt <bbhatt@xxxxxxxxxxxxxx>
---
I wonder, why doesn't this fit with runtimePM?
Hi Jeff,
Can you elaborate?
In short, with this patch, MHI just wants to give controller the
option to
choose the vote type so we can implement autonomous low power mode
entries
on both host and device.
So, you are attempting to manage the power mode of the device. The
standard mechanism to do so in Linux is runtime pm.
https://elixir.bootlin.com/linux/latest/source/Documentation/driver-api/pm/devices.rst
I'm no runtime pm expert, but it feels like your whole voting
mechanism, etc is just reimplemeting that. Reimplementing the wheel,
when its been a standard thing that the majority of the kernel uses is
not usually acceptable.
IMO, you need some sort of justification why runtime pm is not
applicable for you, because I'm willing to bet Mani/Greg are going to
ask the same.
I think we can look at the patch as simply expanding the scope of what
already exists.
The client here has been calling mhi_device_get/put/sync APIs to gain
device vote and with
new features yet to come in, this introductory change is only
re-purposing what voting
means going forward. i.e. allowing individual bus and device votes.
If you're suggesting using runtimePM APIs to replace the newly
introduced bus vote, it
would be kind of overkill here IMO. Is that what you were getting at?
Because currently,
we just have controllers use runtimePM and provide callbacks to them.
If you have ideas, we can discuss them.
Ultimately, yes I think I am suggesting replacing this API with the
runtime pm API.
As near as I can tell, if I'm a device driver on some other bus, and I
want to keep my device alive because I'm doing a DMA to it or something,
I would call pm_runtime_get(), and when I have confirmation my activity
is done, I would use pm_runtime_put().
As near as I can tell, this is already plumbed into the bus framework,
such that the MHI bus would get a callback when the device driver does
that. In the MHI bus callback, you would be able to route the request
as needed.
So, with this API (that has no consumers currently), I call
pm_runtime_get() and also mhi_device_get()?
--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
