The code in these files was moved to cm*.[ch] and prm*.[ch] in the same
directory by commits 4981539 (ARM: OMAP2+: powerdomain/PRM: move the
low-level powerdomain functions into PRM) and 4bd5259 (ARM: OMAP2/3:
clockdomain/PRM/CM: move the low-level clockdomain functions into
PRM/CM).
I am not sure
Hi,
On Sun, Mar 03, 2013 at 01:21:32AM +0200, Felipe Balbi wrote:
> > I don't know much about clock handling. In general, the
> > pm_runtime_set_active() and pm_runtime_enable() parts should be done by
> > the subsystem, not the driver, whenever possible.
>
> good to know :-) Though I disagree w
Hi,
On Sat, Mar 02, 2013 at 05:02:13PM -0500, Alan Stern wrote:
> On Sat, 2 Mar 2013, Felipe Balbi wrote:
>
> > > > @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device
> > > > *dev)
> > > > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > > > struct xhci_
On Sat, 2 Mar 2013, Felipe Balbi wrote:
> > > @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device
> > > *dev)
> > > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > >
> > > + if (!pm_runtime_suspended(&dev->dev))
> > >
Hi,
On Sat, Mar 02, 2013 at 10:53:16AM -0500, Alan Stern wrote:
> On Sat, 2 Mar 2013, Vivek Gautam wrote:
>
> > By enabling runtime pm in this driver allows users of
> > xhci-plat to enter into runtime pm. This is not full
> > runtime pm support (AKA xhci-plat doesn't actually power
> > anything
On 02.03.2013 17:05, Koen Kooi wrote:
> On Fri, 2013-03-01 at 22:57 +0100, Daniel Mack wrote:
>> Hi Afzal, everyone,
>>
>> On 03.11.2012 08:33, Mohammed, Afzal wrote:
>>> * Daniel Mack, November 03, 2012 1:06 AM:
>>>
I'm testing these patches with an AM33xx board that has the first musb
p
On Fri, 2013-03-01 at 22:57 +0100, Daniel Mack wrote:
> Hi Afzal, everyone,
>
> On 03.11.2012 08:33, Mohammed, Afzal wrote:
> > * Daniel Mack, November 03, 2012 1:06 AM:
> >
> >> I'm testing these patches with an AM33xx board that has the first musb
> >> port wired to an USB type A plug, but it d
On Sat, 2 Mar 2013, Vivek Gautam wrote:
> By enabling runtime pm in this driver allows users of
> xhci-plat to enter into runtime pm. This is not full
> runtime pm support (AKA xhci-plat doesn't actually power
> anything off when in runtime suspend mode) but,
> just basic enablement.
>
> Signed-o
On 03/02/2013 08:49 AM, Mark Brown wrote:
> This will probably never fail but it's better style.
>
> Signed-off-by: Mark Brown
> ---
> sound/soc/omap/omap3pandora.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/om
The current code in the dwc3 probe effectively disables runtime pm
from ever working because it calls a get() that was never put() until
device removal. Change the runtime pm code to match the standard
formula and allow runtime pm to function.
Signed-off-by: Vivek Gautam
CC: Doug Anderson
---
Now that machines may select the mode of working of DWC3 (HOST only,
GADGET only or DUAL_ROLE), lets set DWC3 mode based on that
rather than fixing it to whatever DWC3 hardware says.
This way we can skip initializing Gadget/Host in case
we are using Host-only/Gadget-only mode respectively.
Signed-
Right now it doesn't handle full runtime suspend/resume
functionality. However it allows to handle PHYs' sleep
and wakeup across runtime suspend/resume.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/core.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam
---
include/linux/usb/phy.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --g
The PHY controller can choose between ref_pad_clk (XusbXTI-external PLL),
or EXTREFCLK (XXTI-internal clock crystal) to generate the required clock.
Adding the provision for ref_pad_clk here.
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usb3phy.c | 46 +++
Enable autosuspending of Samsung usb3.0 PHY
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usb3phy.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/phy/samsung-usb3phy.c
b/drivers/usb/phy/samsung-usb3phy.c
index 70e2c7b..7594cc7 100644
--- a/
By enabling runtime pm in this driver allows users of
xhci-plat to enter into runtime pm. This is not full
runtime pm support (AKA xhci-plat doesn't actually power
anything off when in runtime suspend mode) but,
just basic enablement.
Signed-off-by: Vivek Gautam
CC: Doug Anderson
---
drivers/us
Enabling runtime power management on dwc3-exynos
letting dwc3 controller to be autosuspended on exynos
platform when not in use.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/d
Allow dwc3 to enable auto power management only after its PHYs
are initialized so that any further PHY handling by dwc3's
runtime power management callbacks is fine.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/core.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --
Exynos5250 has external PLL (XusbXTI) for USB 3.0 PHY's
ref_pad_clk. So use this clock based on availability of
gpio to power control this PLL, otherwise use internal
clock only from XXTI.
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usb3phy.c | 14 ++
drivers/usb/phy/sa
This patch-series enables runtime power management on xhci-plat,
dwc3-core, dwc3-exynos as well as on samsung-usb3 type PHY.
This allows usb 3.0 host ports to be power managed at runtime.
We also turn off the PHY ref_clk PLL, which supplies reference clock
to USB3 type phy, when ports are not in us
On Fri, Mar 01, 2013 at 11:22:48AM -0600, Jon Hunter wrote:
> For OMAP devices, if a gpio is being used as an interrupt source but has
> not been requested by calling gpio_request(), a call to request_irq()
> may cause the kernel hang because the gpio bank may be disabled and
> hence the register a
On Fri, Mar 01, 2013 at 11:22:47AM -0600, Jon Hunter wrote:
> Currently the OMAP GPIO driver uses a legacy mapping for the GPIO IRQ
> domain. This is not necessary because we do not need to assign a
> specific interrupt number to the GPIO IRQ domain. Therefore, convert
> the OMAP GPIO driver to use
22 matches
Mail list logo