Re: Changes to power management in ehci-tegra

[Stephen Warren <swarren@xxxxxxxxxxxxx>]

On 04/19/2012 07:52 AM, Alan Stern wrote:
> On Wed, 18 Apr 2012, Stephen Warren wrote:
> 
>> On 04/18/2012 02:47 PM, Alan Stern wrote:
>> ...
>>> Are you sure the controllers aren't getting suspending under the 
>>> current driver?  It seems like they ought to be -- otherwise there 
>>> would be no point in defining power_down_on_bus_suspend.
>>
>> Ah. The ports are getting suspended (when nothing is plugged in), and
>> tegra_ehci_bus_suspend() is returning 0. However, as soon as any port is
>> suspended, it resumes immediately. I guess that's why plugging something
>> in works even after the controller is suspended; it keeps waking up and
>> is essentially polling for any plugged-in device.
> 
> All right.  In that case there's no point in powering down the 
> controller at all.
> 
> Here's what you can do.  In the patch, change the lines
> 
> +	if (!pdata->power_down_on_bus_suspend)
> +		pm_runtime_forbid(&pdev->dev);
> 
> so that pm_runtime_forbid() gets called unconditionally.  For example:
> 
> +//	if (!pdata->power_down_on_bus_suspend)
> +		pm_runtime_forbid(&pdev->dev);
> 
> If you make that change, does the driver continue to work as well as it 
> did before?

Yes, I believe so.

Note: I found that the immediate resume is because hcd_bus_suspend()
aborts part-way through due to "suspend raced with wakeup event", which
is due to ehci_hub_status_data() finding that port_status has all of
PORT_CSC | PORT_PEC | PORT_OCC set. Is it worth tracking that down
further? I have no idea if it's an ehci-tegra.c issue or quirk in our
EHCI HW.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html