Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green <andy.green@linaro.org>]

On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
> On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Tue, 27 Nov 2012, Ming Lei wrote:
>>
>>> IMO, all matches mean the devices are inside the ehci-omap bus, so
>>> the direct/simple way is to enable/disable the regulators in the probe() and
>>> remove() of ehci-omap controller driver.
>>
>> When this discussion started, Felipe argued against such an approach.
>> He pointed out that the same chip could be used in other platforms, and
>> then the code added to ehci-omap.c would have to be duplicated in
>> several other places.
>
>  From Andy's implementation, the 'general' code is to enable/disable
> the regulators(patch 3/5), I am wondering if it is general enough, so the
> 'duplicated' code are just several lines of regulator_enable/regulator_disable,
> which should be implemented in many platform drivers.

Fair enough; my main interest was in the device path side when writing 
the patches.  I stuck enough in one place to confirm the series works on 
Panda case for power control.  So long as it doesn't get obsessed with 
just regulators some common implementation that seems to be discussed 
will be better.

(BTW let me take this opportunity to thank you for your great 
urbs-in-flight limiting patch on smsc95xx a while back)

> Also from my intuition, power domain should be involved in the problem,
> because these hard-wired and self-powered USB devices should have
> its own power domains, and the ehci-omap driver may enable/disable
> these power domains before adding the bus.

I don't know enough to have an opinion, but the arrangement on Panda is 
literally a linear regulator is being controlled by a gpio, which fits 
into struct regulator model.  What else would a power domain for that 
buy us?

>> We should have a more generic solution in a more central location, like
>> the device core.
>>
>> For example, each struct platform_device could have a list of resources
>> to be enabled when the device is bound to a driver and disabled when
>> the device is unbound.  Such a list could include regulators, clocks,
>> and whatever else people can invent.
>>
>> In this case, when it is created the ehci-omap.0 platform device could
>> get an entry pointing to the LAN95xx's regulator.  Then the regulator
>> would automatically be turned on when the platform device is bound to
>> the ehci-omap driver.
>
> The LAN95xx's regulator is still platform dependent(even for same LAN95xx
> USB devices on different platforms(omap, tegra, ..)) , so I am wondering
> why we don't enable it directly in probe() of ehci-omap.0 platform device?

I didn't get this point, ehci-omap doesn't help if it's non-omap platform.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html