map2430 (since it is now safe to do so);
Runtime-enable the musb and declare it irq_safe (this will
automatically runtime-resume the omap2430);
Register the musb.
If things are done this way, no special action needs to be taken.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rate using a
> shared interrupt where needed.
>
> For the regression for the -rc series? Do you see any better
> alternatives to what I posted?
No.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 9 Sep 2015, Roger Quadros wrote:
> (adding back folks in cc)
>
> On 08/09/15 20:35, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Roger Quadros wrote:
> >
> >>>> What if there is another architecture like so?
> >>
> |
> |--|--|
> [OTG core] [gadget][host]
>
> We need a more flexible mechanism to link the gadget and
> host device to the otg core for non DT case.
>
> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>
> e.g.
> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>
> If otg is NULL it will try DT otg-controller property or parent to
> get the otg controller.
This seems a lot like something Peter and I discussed recently. See
http://marc.info/?l=linux-usb=143977568021328=2
and the following messages in that thread.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, you can never send
an entire packet's worth of data. If the bounce buffer is 1024 bytes
then you can send the entire first packet. When that's done, you can
send the second packet. And so on. It wouldn't be quite as fast, but
for ep0 that shouldn't matter.
Alan Stern
--
To unsubscribe from
as the maxpacket
size? In other words, 1024 bytes instead of 512, for ep0 on a USB-3
device.
Alan stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
controller to send only
part of the data.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
called before the add can complete?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uses _usb_add/remove_hcd()
How about a more explicit naming scheme?
HC drivers use usb_add/remove_hcd()
OTG core uses usb_otg_add/remove_hcd()
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
to simplify things.
Good luck.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
?
This patch deals with the host side, not the device side. The fact
that the device is suspended is not relevant to the issues above.
Besides, the problems I outlined are more connected with the way
Linux's host-side USB stack is organized, and not so much with the
details of the OTG spec.
Alan
be the only practical way forward.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
with interrupts disabled (and in this case pm_runtime_resume
may be called in interrupt context -- normally it can be called only in
process context).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
that, I can't think of any reason not to
update last_busy in rpm_resume.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
() on the wakeirq in without
waiting for the device driver runtime_suspend to disable the wakeirq.
That would minimize the interface to just dev_pm_request_wakeirq()
and dev_pm_free_wakeirq().
Will that be acceptable in systems with shared IRQ lines?
Alan Stern
--
To unsubscribe from this list: send
() for the
IRQ in question and it will cover the devices that don't need separate
wakeup interrupts too.
Does that make sense to you?
Can we back up a little? What is the basic problem the two of you are
trying to solve?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe
completed resume?
That doesn't make sense. You're asking for a routine that is allowed
to sleep but can safely be called in interrupt context.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
at all.
That wouldn't help URBs that were already enqueued when the disconnect
occurred.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
with the 2.6.37 and
3.2 kernels.
Maybe you should try bisection. It's slow but it gives you an answer.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
it about the new
SETUP.
As for gadgets not using the composite framework, I don't think there
are very many of them left. gadgetfs certainly, but hardly any others.
Felipe should know for sure.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
thread.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
as soon as it retrieves the information for the current SETUP
packet from the buffer.
Otherwise, as you described it, if the gadget driver never sends its
delayed status response then the UDC will never respond to any more
control transfers.
Alan Stern
--
To unsubscribe from this list: send
'depends on'.
Since the same dependency exists for the client driver, do the
same change there.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
Cc: Alan Stern st...@rowland.harvard.edu
For the host side changes:
Acked-by: Alan Stern st...@rowland.harvard.edu
:
composite.c for those gadgets using it, otherwise in the higher level
driver (if there are any remaining gadgets that don't use the composite
framework).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
a delayed status response, the response would be sent only if the
counter had not changed from when the original setup request was
received.
As far as I can see, composite.c doesn't do anything like that.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap
know that the status response is stale. It will think the
response was meant for the new transfer, not the old one.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
log saying that
the gadget driver needs to be fixed.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
of this? That is, can you explain the
difference between USB PHY support and general PHY support, and why we
need both?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
platform
drivers.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/resume. But if this is unavoidable, the USB Persist mechanism
should be able to cope by issuing a reset-resume. (Unless userspace
has turned Persist off, of course -- I believe some distributions do
this. Chrome?)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap
and the main I/O thread are mutually exclusive (they both grab
the private mutex), so a suspend can't occur while a SCSI command is
underway.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
a reset_resume method) are able to
handle this -- they put the device back into the right state and then
act as if nothing had happened. Others aren't; they get unbound and
rebound just as though the device really had been disconnected and
reconnected.
Alan Stern
--
To unsubscribe from this list: send
.
As the OMAP IO pad wakeup management code [1] is still in transition, I'll
wait till
that gets settled and then resend this series.
Okay.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
would use phy1 or phy2, and the PHY
consumers would use host1 or host2.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, this was simply meant to be a suggestion to show that it
is relatively easy to do what you need without using name or ID
strings.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
?
phy_create is the API by which the PHY's driver (the supplier) hook into the
PHY framework. It's like the controller driver will always interact with the
PHY driver through the PHY framework.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ }
+
+ return ret;
+}
All good.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
does phy_create() fit into this picture?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Alan Stern
--
To unsubscribe from this list: send
is now active.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, you
can add my Acked-by.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
All of these issues are discussed (among lots of other material) in
Documentation/power/runtime_pm.txt.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
should never be set on systems with shared IRQs. Having both would ...
well, it would indicate a really bad system design.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Wed, 3 Jul 2013, Felipe Balbi wrote:
On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
On 07/03/2013 03:57 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
A PCI-based EHCI controller has two power sources: the core well
On Tue, 2 Jul 2013, Roger Quadros wrote:
On 07/02/2013 12:01 AM, Alan Stern wrote:
On Mon, 1 Jul 2013, Felipe Balbi wrote:
I don't know what Pad wakeup is. The wakeup signal has to originate
from the EHCI controller, doesn't it? If not, how does the Pad know
when a wakeup
On Mon, 1 Jul 2013, Roger Quadros wrote:
On 06/28/2013 10:06 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Roger Quadros wrote:
That's not what I meant. Never mind the pinctrl; I was asking about
the EHCI controller itself. Under what circumstances does the
controller assert its wakeup
. But if EHCI is
powered off, those bits can't be used.
Also, once the wakeup signal has been turned on, how does it get turned
off again?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
()
there would end up calling ehci_suspend() after usb_remove_hcd().
bound or started would be better names.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
to have to do the same thing, which
argues for putting the enable call in the core. Perhaps at the start
of hcd_resume_work() instead of the end.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
be true, because wakeup is always enabled during runtime suspend.
Also, why do you need omap-initialized? Do you think you might get a
wakeup interrupt before the controller has been fully set up? I don't
see how you could, given the pm_runtime_get_sync() call in the probe
routine.
Alan Stern
On Tue, 25 Jun 2013, Roger Quadros wrote:
On 06/24/2013 10:34 PM, Alan Stern wrote:
On Mon, 24 Jun 2013, Roger Quadros wrote:
OK I've tried to handle all this in an alternate way. Now the controller
suspend/resume
and runtime suspend/resume is independent of bus suspend
);
usb_hcd_resume_root_hub(hcd);
return IRQ_HANDLED;
}
I think this will work. How does it look to you?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
to do in
ehci-omap.c is call synchronize_irq() after ehci_suspend() returns and
before turning off the clocks.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
. Or if it is, we could
adopt a simpler alternative: the controller's resume routine could
always call usb_hcd_resume_root_hub(). After all, about the only
reason for doing a runtime resume of the controller is because the root
hub needs to do something.
Alan Stern
--
To unsubscribe from
, and bus_resume handlers. This
provision is done in patch 3.
Do you still need to override these things if you do the controller
suspend at the right time?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
it in the DT core.
This particular approach doesn't seem very robust. What if
pdev-dev.dma_mask is already set to a different value for some good
reason?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
in the remove
routine if it points to the static mask value.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
. Was this an oversight?
In a little while I will submit a patch which removes USB_SUSPEND from
that file. You or someone else may want to write a separate patch to
enable PM_RUNTIME.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
? That routine would do the opposite of usb_phy_init(),
putting the PHY back into its initialized state.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Hi,
On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Alright, so here's my understanding:
I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said
On Wed, 17 Apr 2013, Roger Quadros wrote:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2 insertions
USB_EHCI_HCD_OMAP
is enabled.
warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct
dependencies (USB_SUPPORT USB_PHY)
warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct
dependencies (USB_SUPPORT USB_PHY)
CC: Alan Stern st
On Mon, 15 Apr 2013, Roger Quadros wrote:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
If we fail to get the PHY device it could be due
to missing USB PHY drivers. Give this hint to the user
in the error message.
CC: Alan Stern st
the DWC3 driver call to register itself
as a consumer of the PHY?
Likewise, what routine does it call to unregister itself?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
and unregistering themselves, which is about the
same thing.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
[ 13.529998] IP-Config: Failed to open eth0
I have bisected this to:
commit 18aafe64d75d0e27dae206cacf4171e4e485d285
Author: Alan Stern st...@rowland.harvard.edu
Date: Wed Jul 11 11:23:04 2012 -0400
USB: EHCI
an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
You're more familiar with that code. Reported-by is good enough for
me. :-)
Alan Stern
--
To unsubscribe from
...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 13 Mar 2013, Roger Quadros wrote:
As it does almost nothing, get rid of omap_ehci_init()
and move the ehci-caps initialization part into probe().
Also remove the outdated TODO list from header.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
On Tue, 12 Mar 2013, Roger Quadros wrote:
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st
: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c | 38 +++---
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1ba1df8..dc2de47 100644
--- a/drivers/usb
to mainline.
Acked-by: Alan Stern st...@rowland.harvard.edu
for the EHCI changes.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
was suspended even though it was really at full power.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that these two calls don't invoke the
driver's runtime-PM callbacks!)
Probably nobody has thought these problems through very carefully for
the platform subsystem. Nevertheless, that's where the decisions need
to be made.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux
);
This is very strange. Why have a pm_runtime_put with no balancing
pm_runtime_get?
And why use an async routine when you're about to unbind the driver?
Don't you want the callback to occur before the unbinding?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap
remain unsuspended even after the
driver does a pm_runtime_put(). For example, this will happen if the
user wrote on to /sys/.../power/control.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Wed, 6 Feb 2013, Alan Stern wrote:
Is this issue fixed ?
Actually we too are getting very similar issue with samsung exynos5250
hardware.
With latest 'usb-next' kernel and supporting arch patches, when i use
following test scenerio:
Connect a USB 2.0 external hub to USB 2.0
On Thu, 7 Feb 2013, Roger Quadros wrote:
The module alias should be ehci-omap and not
omap-ehci to match the platform device name.
The omap-ehci module should now autoload correctly.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers
timer bug affecting
port resume
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
at the time...)
...
After waiting for several minutes, it stops, and dmesg shows:
# dmesg | grep -i omap
This grep will drop the important information.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ohci-omap3 part:
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ehci-omap part:
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux
, assets look like a good way to improve this. In fact, to some
extent assets appear to be a generalization or extension of platform
data.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
device).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is fairly complicated, there's a lot of code in
drivers/base/power/domain.c (it's the biggest source file in its
directory), and I'm not aware of any documentation.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
? 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.
Until we decide on the answers to these questions, there's no point
writing detailed patches.
Alan Stern
--
To unsubscribe from this list: send the line
, not
just USB ports, may be over-reaching.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
at all.
Maybe we just need a platform-specific way to associate a regulator or
clock with a USB port, something that the port driver would know about
explicitly.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
below ehci-omap.0.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
?
Lei Ming provided a partial answer, but his suggestion is tied to USB.
It would be better to have a more general approach. So far nobody has
come up with a suggestion that everybody approves of.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
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?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
is bound or unbound. The most straightforward way to
arrange _that_ is to allow each platform_device to have a list of
callbacks.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
,
at first he confused the root hub with the LAN95xx's hub.) There's no
reason to restrict this sort of thing to USB hubs (or to regulators,
for that matter). The driver core is the right place for it.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
to that
later.
Agreed.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is unregistered.
There doesn't have to be anything in this scheme that's specific to
hubs or even to USB. In particular, no changes to the hub driver would
be needed.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
1 - 100 of 299 matches
Mail list logo
