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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux