On 11/02/2015 06:06 PM, Felipe Balbi wrote:
> 
> hi,
> 
> Grygorii Strashko <[email protected]> writes:
>> On 11/02/2015 05:20 PM, Felipe Balbi wrote:
>>> Grygorii Strashko <[email protected]> writes:
>>>
>>>> On 10/29/2015 03:57 PM, Felipe Balbi wrote:
>>>>> there's no need to call pm_runtime_get_sync()
>>>>> followed by pm_runtime_put(). We should, instead,
>>>>> just call pm_runtime_put_sync() and pm_runtime_disable().
>>>>
>>>> Sry, but why do we need to call pm_runtime_put[_sync]() here?
>>>>
>>>> My be just pm_runtime_disable() will be ok?
>>>
>>> and disable with unbalanced pm_runtime_get() ?
>>>
>>
>> Which one is unbalanced pm_runtime_get()?
>> There are no  pm_runtime_get() in probe, so there you are
>> going to introduce unbalanced pm_runtime_put_sync() actually :(
> 
> look at ti_qspi_setup(). I _do_ see, however, that it calls
> pm_runtime_put_autosuspend() in the same function; what happens if
> driver is removed after ti_qspi_setup() runs but before
> put_autosuspend() has time to actually run ?
> 

Seems nothing :) If I understand code in __device_release_driver() right:
the .remove() callback will be called after pm_runtime_put_sync() and
device should be disabled at this moment.

Also, note that ti_qspi_setup() will be called for each SPI device attached
to SPI master and further PM management of SPI master is performed by SPI core
from __spi_pump_messages().

-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to