External email: Use caution opening links or attachments
24.01.2020 12:51, Jon Hunter ÐÐÑÐÑ:
On 24/01/2020 09:07, Jon Hunter wrote:1. Device shall be in RPM-suspended state at the time of driver's
On 23/01/2020 15:16, Dmitry Osipenko wrote:Sorry I meant the RPM case. In other words, I don't see a problem for
23.01.2020 12:22, Sameer Pujar ÐÐÑÐÑ:I don't see any problem with this for the !RPM case.
Maybe this is fine for !RPM, but not really fine in a case of enabled
On 1/22/2020 9:57 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachmentsI think it looks to be similar to what is there already.
22.01.2020 14:52, Jon Hunter ÐÐÑÐÑ:
On 22/01/2020 07:16, Sameer Pujar wrote:Yes, it was kinda actual for the case of unavailable RPM.
...
I recall that this was the preferred way of doing this from the RPMIf RPM is broken, it probably would have been caught during deviceI took a closer look and looks like the counter actually should beOnce the driver is re-loaded and RPM is enabled, I don't think itIt should matter (if I'm not missing something) because RPM shouldI guess this was added for safety and explicit suspend keeps clock+static int tegra210_i2s_remove(struct platform_device *pdev)This breaks device's RPM refcounting if it was disabled in the
+{
+ pm_runtime_disable(&pdev->dev);
+ if (!pm_runtime_status_suspended(&pdev->dev))
+ tegra210_i2s_runtime_suspend(&pdev->dev);
active
state. This code should be removed. At most you could warn
about the
unxpected RPM state here, but it shouldn't be necessary.
disabled.
Not sure if ref-counting of the device matters when runtime PM is
disabled and device is removed.
I see few drivers using this way.
be in
a wrecked state once you'll try to re-load the driver's module.
Likely
that those few other drivers are wrong.
[snip]
would use
the same 'dev' and the corresponding ref count. Doesn't it use the
new
counters?
If RPM is not working for some reason, most likely it would be the
case
for other
devices. What best driver can do is probably do a force suspend
during
removal if
already not done. I would prefer to keep, since multiple drivers
still
have it,
unless there is a real harm in doing so.
reset. Still I don't think that it's a good practice to make changes
underneath of RPM, it may strike back.
usage.
I will remove explicit suspend here if no any concerns from other
folks.
Thanks.
folks. Tegra30 I2S driver does the same and Stephen had pointed me to
this as a reference.
I believe that this is meant to ensure that the
device is always powered-off regardless of it RPM is enabled or not and
what the current state is.
Anyways, /I think/ variant like this should have been more preferred:
if (!pm_runtime_enabled(&pdev->dev))
tegra210_i2s_runtime_suspend(&pdev->dev);
else
pm_runtime_disable(&pdev->dev);
pm_runtime_disable(&pdev->dev); // it would turn out to be a dummy call
if !RPM
if (!pm_runtime_status_suspended(&pdev->dev)) // it is true always if !RPM
tegra210_i2s_runtime_suspend(&pdev->dev);
RPM. Device could be in resumed state after pm_runtime_disable() if it
wasn't suspended before the disabling.
neither the RPM case of the !RPM case.
removal, unless there is a bug in the sound driver. Hence why do you
need the dead code which doesn't bring any practical value?
2. Making changes underneath of RPM is simply error-prone. It may hit
badly in the future once something will change in the RPM core.