On 7 August 2013 17:34, Mark Brown wrote:
> On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote:
>> On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown wrote:
>> > From: Andy Green
>> >
>> > You might have CONFIG_PM, but you might not have CONFIG_SUSPEND,
On 06/12/12 00:42, the mail apparently from Alan Stern included:
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is cr
On 05/12/12 02:14, the mail apparently from Sarah Sharp included:
On Tue, Dec 04, 2012 at 11:40:05AM +0800, Andy Green wrote:
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
On 05/12/12 01:10, the mail apparently from Alan Stern included:
[CC: list trimmed; the people who were on it should be subscribed to at
least one of the lists anyway.]
On Tue, 4 Dec 2012, Andy Green wrote:
I think associating ULPI PHY reset and SMSC power and reset with the hub
port power
On 04/12/12 10:39, the mail apparently from Ming Lei included:
On Mon, Dec 3, 2012 at 12:52 PM, Andy Green wrote:
+static void ehci_hub_power_off(struct power_controller *pc, struct
device
*dev)
+{
+ gpio_set_value(GPIO_HUB_NRESET, 0);
+ gpio_set_value(GPIO_HUB_POWER, 0
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 w
On 03/12/12 12:11, the mail apparently from Ming Lei included:
On Mon, Dec 3, 2012 at 12:37 AM, Andy Green wrote:
On 02/12/12 23:01, the mail apparently from Ming Lei included:
Hi -
This patch defines power controller for powering on/off LAN95xx
USB hub and USB ethernet devices, and
.
Cc: Andy Green
Cc: Roger Quadros
Cc: Alan Stern
Cc: Felipe Balbi
Signed-off-by: Ming Lei
---
arch/arm/mach-omap2/board-omap4panda.c | 99 +++-
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-
notifier.
Cc: Andy Green
Cc: Roger Quadros
Cc: Alan Stern
Cc: Felipe Balbi
Signed-off-by: Ming Lei
---
drivers/base/core.c| 21 +
include/linux/device.h | 13 +
2 files changed, 34 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
devices don't need to provide power.
What stops us using struct regulator here? If you have child regulators
supplied by a parent supply, isn't that the right semantic already
without introducing a whole new thing? Apologies if I missed the point.
-Andy
Cc: "Rafael J. Wysocki&q
ecially 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
On 11/30/2012 04:58 AM, the mail apparently from Andy Green included:
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would be possible to bind an asset
array to them and make the pre- and
On 11/28/2012 11:06 PM, the mail apparently from Roger Quadros included:
Hi Roger -
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI lo
omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.
Signed-off-by: Andy Green
---
arch/arm/configs/omap2plus_defconfig | 42 ++
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git
measurements there.
Signed-off-by: Andy Green
---
arch/arm/mach-omap2/board-omap4panda.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 52add03..97489c7 100644
--- a
e time, which is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green
---
arch/arm/mach-omap2/
This series migrates it to be assets of the logical ehci-omap.0
device object.
Signed-off-by: Andy Green
---
arch/arm/mach-omap2/usb-host.c|1 -
arch/arm/plat-omap/include/plat/usb.h |7 --
drivers/usb/host/ehci-omap.c | 37 -
3
duplication at the usages
is nipped in the bud.
Signed-off-by: Andy Green
---
drivers/clk/clkdev.c | 39 +++
include/linux/clk.h | 33 -
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clkdev.c b
duplication at the usages
is nipped in the bud.
Signed-off-by: Andy Green
---
drivers/regulator/core.c | 34 ++
include/linux/regulator/machine.h | 30 ++
2 files changed, 64 insertions(+)
diff --git a/drivers/regulator/core.c b
pically disable them.
Signed-off-by: Andy Green
---
drivers/base/dd.c | 36
include/linux/device.h | 25 +
2 files changed, 61 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..d37210a 100644
--- a/dri
le hidden in the plumbing.
The end result is power and clock to the HUB+PHY (smsc95xx chip)
remains off until ehci-hcd module is inserted, and both are
disabled again when the module is removed.
---
Andy Green (7):
drivers: base: introduce device assets
regulator: core: add default
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 be
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 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 ad
;s regulator is still platform dependent(even for same LAN95xx
USB devices on different platforms(omap, tegra, ..)) , so I am wondering
why we don't enable it directly in probe() of ehci-omap.0 platform device?
I didn't get this point, ehci-omap doesn't help if it's non-omap pl
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 a
On 11/27/2012 12:20 AM, the mail apparently from Roger Quadros included:
Hi Andy,
On 11/26/2012 02:45 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
Without power control, the ULPI PHY + SMSC9614 on the Panda
an do nothing except
complain at hardware designers for some reason I failed to quite
identify, I fear we are moving deckchairs on the titanic.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/15597458
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
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
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 l
omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.
Signed-off-by: Andy Green
---
arch/arm/configs/omap2plus_defconfig | 42 ++
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git
start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green
---
arch/arm/mach-omap2/Kconfig|1
arch/arm/mach-omap2/board-omap4panda.c | 90 +--
This adds the config option to associate a regulator with each hub,
when the hub on a specific, interesting device path appears, then
the regular is powered while the logical hub exists.
Signed-off-by: Andy Green
---
drivers/usb/core/Kconfig | 10 ++
drivers/usb/core/hub.c | 26
This series migrates it to the hub driver as suggested by
Felipe Balbi.
Signed-off-by: Andy Green
---
drivers/usb/host/ehci-omap.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 44e7d0f
s_omap/ehci-omap.0/usb*
providing the same literal string for ehci-omap.0 hub no matter how many\
usb buses have been registered before.
This wildcard string can then be matched to regulators or other string-
searchable assets intended for the device on that hardware path.
Signed-off-by: Andy G
ault at boot, and
is powered cleanly for the lifecycle of the ehci-hcd root hub object.
Comments welcome, this is my first attempt at turning the discussion of the
last few days into an implementation, it is working here well on Panda ES.
-Andy
---
Andy Green (5):
drivers : introduce devic
On 11/24/12 23:38, the mail apparently from Alan Stern included:
On Sat, 24 Nov 2012, Andy Green wrote:
If we're just looking at fixing the current "magic regulator name"
scheme of "hsusb0" so that it can work with abstract devices like any
hub / port, we could invert
egulator name
to be "ehci1/usbhub1-1/1-1.1" or whatever) and you're just trying to
sell device_path_generate() to someone else, which should be pretty small.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook
ernel objects to
asynchronously probed devices: there's one way to do it for hardwired
platform devices.
-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/#!/linaroo
Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
From: Andy Green
This patch changes the management of the two GPIO for
"hub reset" (actually controls enable of ULPI PHY and hub reset) and
"hub power" (controls power to hub + eth).
looks like th
On 11/22/12 20:21, the mail apparently from Felipe Balbi included:
Hi,
On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
Hi,
On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
On 11/21/2012 05:32 PM
43 matches
Mail list logo
