On 12/01/2012 03:49 PM, the mail apparently from Jassi Brar included:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
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.
How does this sound?
That sounds much better, and it might come in handy for other types of
devices than platform devices, so feel free to put this on the core
'struct device' instead if needed.
Isn't enabling/disabling of clocks and regulators what
dev.probe()/remove() of any driver already does?
The particular issue this tries to address is stuff that is not part of
the generic driver function, but which is tied to the device instance by
hardware connection choices on the physical platform. External clocks,
regulators and mux settings needed to make the device instance work on
the board may all be out of scope for the generic driver, even when the
generic driver has a SoC-specific part as in this case.
So no, enabling regulators, clock and mux it has no idea about because
the dependency only exists as a board feature is not the job of probe /
remove in drivers already.
If we mean only board specific setup/teardown, still it would mean
having the device core to do an extra 'probe' call when the current
probe() is already meant to do whatever it takes to bring the device
up. To my untrained eyes, it seem like messing with the
probe()/remove()'s semantics.
It's in the way of automating and simplifying code that would be
repeated in each driver probe routine according to what you're
suggesting. In fact the pre-probe activity happens at the start of the
actual probe code, and post remove at the end of the actual remove,
there is no duplicated activity. It's just a helper.
IMHO, if we really must implement something like that, may be we
should employ some 'broadcast mechanism' so that anything anywhere in
kernel knows which new device has been probed()/removed()
successfully. I haven't thought exactly how because I am not sure even
that would be the right way to approach PandaBoard's problem.
I think this stuff is a bit more multifacted than you're giving it
credit for, and indeed this thread has gone right into this aspect. Say
we hooked to a device creation notifier, we still must identify the
correct device, in the case the device is on a dynamic bus. Hence the
discussion about device paths. Just throwing a notifier at it itself
doesn't scratch the problem. The stuff I completed yesterday does solve
this dynamic matching issue inexpensively.
Looking at "Figure 15 – Panda USBB1 Interface Block Diagram" of
http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf
gives me visions ...
1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is
USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So
we should have a platform device for USB3320C, the probe() of which
should simply
a) Enable REFCLK (FREF_CLK3_OUT)
b) Reset itself by cycling RESETB (GPIO_62)
c) Create one "ehci-omap" platform device
(or in appropriate order if the above isn't)
That way insmod/rmmod'ing the USB3320C driver would power-up/down the
whole subsystem.
First there's the issue that Panda has the same signal to reset the ULPI
PHY and the SMSC device, and that we must operate that reset after
powering the SMSC device. The only nice way to do that is to arrange
for the reset to happen once for both, at a time after the SMSC chip is
powered, so we have no need to interrupt ULPI operation or touch the
reset subsequently, until next powerup of the ULPI PHY + SMSC.
That is why tying "foreign-to-the-generic-driver" assets to a device
instantiation can get us out of the hole, even when we want a hub port
device that is impossible to have as a platform_device to control the
power and clock for the SMSC device.
With Panda just trying to cleanly deal with ULPI reset in ULPI driver
and SMSC reset in SMSC driver (how're you going to let that dynamically
created smsc device know the gpio again?) are complicated by both
getting reset by the same signal.
Second, the choices of Panda about providing a refclock and reset to the
ULPI PHY are not SoC level choices but board level ones.
2) Just like the user has to manually power-on/off any externally
powered hub connected to a PC, maybe we should implement a user
controlled 'soft' switch (reacting to UDEV events from ehci-omap?) to
emulate LAN9514 power-on/off. I do realize it would be cool to have it
automatically toggle in kernel when we (de)power the hub but isn't
that outside of scope of Linux USB implementation?
The above solution isn't most optimal for Panda but it seems a design
more consistent with what we already have. Or so do I think.
Not sure why you think that's out of scope for USB when USB allows hubs
to control port power.
Hub port power state seems like the right thing to control the
"enablement" of the stuff wired to the hub port afaics, it's a great
indication if we transition a hub port from depowered to powered, even
if that only has a logical effect rather than actually switching 5V, we
can understand from that we should power + clock (+ anything else
needed) the thing connected to the port then so it can be probed... it's
definitely what is wanted.
The device_asset stuff is able to do that and control similarly the
lifecycle of arbitrary mux, clocks and regulators to go along with it,
without contaminiating the hub driver (except with 2 calls to work
around the fact that hub port devices have no driver).
The power domain stuff will also work, but only as far as hooking up the
regulator and not the clock and mux stuff. If there's a plan to allow
to bind clocks and mux to a regulator, well, OK you can do it all that
way, gluing it together by magic names for the power domain assets.
Anyway there's a lot of angles to it, the device_asset technique is
powerful and will definitely solve "out of band" prerequisites setup
nicely without involving the driver.
But I can't say I can see deep enough into the other considerations
(especially other subsystems understanding all this thinking) that just
trying to solve the regulator angle with a power domain is "wrong".
However it won't properly solve even the Panda case by itself as well as
device_asset - external clock will stay permanently up and the forest of
mux code - it's code, not tables - in mach-omap2 will stay as a _init
one-off.
-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
