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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
