Re: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices

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

 



On 04/12/12 01:09, the mail apparently from Alan Stern included:
On Mon, 3 Dec 2012, Andy Green wrote:

Unless someone NAKs it for sure already (if you're already sure you're
going to, please do so to avoid wasting time), I'll issue a try#2 of my
code later which demonstrates what I mean.  At least I guess it's useful
for comparative purposes.

Before you go writing a whole lot more code, we should discuss the
basics a bit more clearly.  There are several unsettled issues here:

      1. Should the LAN95xx stuff be associated with the ehci-omap.0's
	driver or with the hub port?  The port would be more flexible,
	offering the ability to turn the power off and on while the
	system is running without affecting anything else.  But the
	port code is currently in flux, which could cause this new
	addition to be delayed.

I think associating ULPI PHY reset and SMSC power and reset with the hub port power state is good. Then, you could have the driver in a device with multiple onboard USB devices, and individually control whether they're eating power or not. In the asset case, you'd associate mux assets with ehci-omap.0.

Yesterday I studied the hub port code and have a couple of patches, one normalizes the hub port device to have a stub driver.

The other then puts hub port power state signalling into runtime_pm handlers in the hub port device. Until now, actually there's no code in hub.c to switch off a port.

Assuming that's not insane, what should the user interface to disable a port power look like, something in sysfs? Until now it doesn't seem to exist.

	(On the other hand, since the LAN95xx is the only thing
	connected to the root hub, it could be powered off and on by
	unbinding the ehci-omap.0 device from its driver and rebinding
	it.)

We shouldn't get to tied up with Panda case, this will be there for all cases like PCs etc. It should work well if there are multiple ports with onboard assets.

      2. If we do choose the port, do we want to identify it by matching
	against a device name string or by matching a sequence of port
	numbers (in this case, a length-1 sequence)?  The port numbers
	are fixed by the board design, whereas the device name strings
	might  get changed in the future.  On the other hand, the port
	numbers apply only to USB whereas device names can be used by
	any subsystem.

USB device names contain the port information. The matching scheme I have currently just uses the right-hand side of the path information and nothing that is not defined by the USB subsystem. It uses a platform_device ancestor to restrict matches to descendants of the right host controller. So unlike try#1 the names are as stable as the subsystem code alone, however stable that is, it's not exposed to changes from anywhere else. As you mention it's then workable on any dynamically probed bus.

      3. Should the matching mechanism go into the device core or into
	the USB port code?  (This is related to the previous question.)

Currently I am experimenting with having the asset pointer in struct device, but migrating the events into runtime_resume and runtime_suspend. If it works out that has advantages that assets follow not just the logical device existence but the pm state of the device closely.

It also allows leveraging assets directly to the hub port runtime_pm state, so they follow enable state of the port without any additional code.

      4. Should this be implemented simply as a regulator (or a pair of
	regulators)?  Or should it be generalized to some sort of PM
	domain thing?  The generic_pm_domain structure defined in
	include/linux/pm_domain.h seems like overkill, but maybe it's
	the most appropriate thing to use.

They should be regulators for that I think. But it's only part the problem since clocks and mux are also going to be commonly associated with device power state, and indeed are in Panda case.

I realize restricting the scope is desirable to get something done, but I'm not sure supporting regulators only is enough of the job.

Until we decide on the answers to these questions, there's no point
writing detailed patches.

I agree, however I can't get insight into and confidence about what to do without studying and meddling with the code. Some throwaway code is probably a reasonable price.

-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