On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>> Hi,
>>
>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi@xxxxxx> [130710 09:18]:
>>>>
>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>> during probe.
>>>>>
>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>
>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>> Author: Felipe Balbi <balbi@xxxxxx>
>>>>> Date: Wed Jul 10 18:50:16 2013 +0300
>>>>>
>>>>> arm: omap2plus: unidle devices which are about to probe
>>>>>
>>>>> in order to make HWMOD and pm_runtime agree on the
>>>>> initial state of the device, we will unidle the device
>>>>> and call pm_runtime_set_active() to tell pm_runtime
>>>>> that the device is really active.
>> Don't think that it's good idea (
>> I've checked some driver's and think this patch will enable some devices
>> unpredictably:
>> - hwspinlock
>> - mailbox
>> - iommu
>> - ipu
>> All above devices need to be enabled on demand only (no
>> pm_runtime_get*() calls in probe). More over, some of them have very
>> specific enabling sequence - like ipu).
>>
>> May be Summan can say more on that.
>
> Indeed, this is a problem for any of the slave processor devices.
> mailbox and iommu would be slaves to the remoteproc and the drivers have
> a specific sequence of bringing up a processor. The current
> hwmod/omap_device code is such that these devices will be left in reset
> and the driver code use the omap_device_(de)assert_hardreset API
> together with omap_device_enable code to bring up the devices. The
> remoteproc driver also needs to assert the resets (there are other
> problems associated with using omap_device_idle for remoteproc and
> iommu) for bringing up the devices after a suspend sequence. hwspinlock
> and mailbox may get away since they are in CORE domain, but definitely
> an issue for iommu and remoteproc. I would think that this would also
> affect other compute devices like IVAHD, ISS, SGX.
Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
/*
* If an IP block contains HW reset lines and all of them are
* asserted, we let integration code associated with that
* block handle the enable. We've received very little
* information on what those driver authors need, and until
* detailed information is provided and the driver code is
* posted to the public lists, this is probably the best we
* can do.
*/
if (_are_all_hardreset_lines_asserted(oh))
return 0;
What if this information is send back to omap_device() through a return value
so omap_device() knows about this too, so it avoids marking the omap device as
enabled? Wouldn't that fix the issue?
>
> regards
> Suman
>
>>
>>>>>
>>>>> By the time driver's probe() is reached, a call to
>>>>> pm_runtime_get_sync() will not cause driver's
>>>>> ->runtime_resume() method to be called at first, only
>>>>> after a successful ->runtime_suspend().
>>>>>
>>>>> Signed-off-by: Felipe Balbi <balbi@xxxxxx>
>>>>
>>>> btw, this is RFC, haven't tested at all.
>>>
>>> Yes it does not compile, then removing the extra ; at the end
>>> of the functions, it oopses with a NULL pointer exception.
>>>
>>> Regards,
>>>
>>> Tony
>>> --
>>> 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
>>>
>>
>
--
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
