On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros rog...@ti.com wrote:
On 12/06/2012 04:34 PM, Jassi Brar wrote:
Yes, this is where we can think of a generic PHY driver to make sure thy
PHY has necessary resources enabled. In the Panda case it would be the
PHY clock and RESET gpio.
I wonder if
On 12/11/2012 11:12 AM, Jassi Brar wrote:
On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros rog...@ti.com wrote:
On 12/06/2012 04:34 PM, Jassi Brar wrote:
Yes, this is where we can think of a generic PHY driver to make sure thy
PHY has necessary resources enabled. In the Panda case it would be
On Tue, Dec 11, 2012 at 12:01:57PM +0200, Roger Quadros wrote:
On 12/11/2012 11:12 AM, Jassi Brar wrote:
On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros rog...@ti.com wrote:
On 12/06/2012 04:34 PM, Jassi Brar wrote:
Yes, this is where we can think of a generic PHY driver to make sure thy
On 12/06/2012 04:34 PM, Jassi Brar wrote:
On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros rog...@ti.com wrote:
Hi Jassi,
On 12/01/2012 09:49 AM, Jassi Brar wrote:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern
Hi,
On Mon, Dec 10, 2012 at 11:48:51AM +0200, Roger Quadros wrote:
(or in appropriate order if the above isn't)
That way insmod/rmmod'ing the USB3320C driver would power-up/down the
whole subsystem.
Yes, this is where we can think of a generic PHY driver to make sure thy
PHY has
On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros rog...@ti.com wrote:
Hi Jassi,
On 12/01/2012 09:49 AM, Jassi Brar wrote:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
We should have a more generic
Hi Jassi,
On 12/01/2012 09:49 AM, Jassi Brar wrote:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org 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,
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 gre...@linuxfoundation.org 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
On Sat, Dec 1, 2012 at 2:07 PM, Andy Green andy.gr...@linaro.org wrote:
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 gre...@linuxfoundation.org
wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
We should
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org 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
On Thu, 29 Nov 2012, Ming Lei wrote:
If we want to set up the association between usb port and power domain,
usb knowledge is required, at least bus info and port topology are needed.
One difficulty is the fact that the device(such as usb port) is independent
with the 'power domain', for
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because
On 11/28/2012 01:47 PM, Andy Green wrote:
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply
On Wed, 28 Nov 2012, Roger Quadros wrote:
board file:
static struct regulator myreg = {
.name = mydevice-regulator,
};
static struct device_asset mydevice_assets[] = {
{
.name = mydevice-regulator,
.handler =
On Thu, Nov 29, 2012 at 12:43 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 28 Nov 2012, Roger Quadros wrote:
board file:
static struct regulator myreg = {
.name = mydevice-regulator,
};
static struct device_asset mydevice_assets[] = {
{
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.
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do things there.
But the cost of that is like the tuple suggestion,
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern 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
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@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
On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do
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 st...@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
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice, but there is zero code provided in my patches that
relies on pathnames in
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice, but there
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
struct device_asset {
char *name; /* name of regulator, clock,
On Wed, Nov 28, 2012 at 1:55 AM, Andy Green andy.gr...@linaro.org wrote:
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 st...@rowland.harvard.edu
wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices
On Wed, Nov 28, 2012 at 7:06 AM, Ming Lei tom.leim...@gmail.com wrote:
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
On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
On Mon, 26 Nov 2012, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can generate a string like
/platform/usbhs_omap/ehci-omap.0/usb1/1-1
which enapsulates
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
+struct device_path list;
+DEFINE_MUTEX(lock);
Those are some very descriptive global variables you just created :(
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can generate a string like
/platform/usbhs_omap/ehci-omap.0/usb1/1-1
On Mon, Nov 26, 2012 at 11:22:06AM -0800, Greg KH wrote:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
This adds a small optional API into drivers/base which deals with
generating,
matching and registration of wildcard device paths.
From a struct device * you can
On Mon, 26 Nov 2012, Greg KH wrote:
Ah, here's the root of your problem, right? You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device? Using the device path and hard-coding it into the
kernel is not the proper way to solve this, sorry.
On Mon, Nov 26, 2012 at 04:07:38PM -0500, Alan Stern wrote:
On Mon, 26 Nov 2012, Greg KH wrote:
Ah, here's the root of your problem, right? You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device? Using the device path and hard-coding
On 11/27/2012 03:12 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can generate a string like
On 11/27/2012 03:16 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
+struct device_path list;
+DEFINE_MUTEX(lock);
Those are some very descriptive global variables you just created :(
I guess I can add the static if that will heal
On 11/27/2012 03:22 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can
On 11/27/2012 05:07 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, Greg KH wrote:
Ah, here's the root of your problem, right? You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device? Using the device path and
On Tue, Nov 27, 2012 at 5:07 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 26 Nov 2012, Greg KH wrote:
Ah, here's the root of your problem, right? You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device? Using the device path and
39 matches
Mail list logo
