Re: [PATCH v3 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
Hi Felipe, On Tue, Apr 2, 2013 at 1:59 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Apr 01, 2013 at 07:24:01PM +0530, Vivek Gautam wrote: 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 gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, wrong comment style. Yea :-( will fix this. + * to make sure we know device state prior to + * pm_runtime_enable + */ + pm_runtime_set_suspended(dev); didn't Alan mention this should be done at the Bus level ? In that case, shouldn't you have call pm_runtime_set_active/suspended() based on DT's status=okay or status=disabled ? Or something similar ? True, we should be doing this at bus level. But he did also mention to let pm core know of the state of the device before enabling the runtime pm. Right ? Moreover immediately after pm_runtime_enable(), we do pm_runtime_get_sync() so that device comes to active state. I am possibly missing things out here, not able to grab this whole picture completely :-( Wouldn't DT's status=disabled actually be disabling the device as a whole ? So, how much will runtime power management on the device be affecting ? -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi Kishon,
On Wed, Apr 3, 2013 at 10:38 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Monday 01 April 2013 07:24 PM, Vivek Gautam wrote:
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 gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 11:48:39AM +0530, Vivek Gautam wrote:
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 gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
Hi, On Wed, Apr 03, 2013 at 11:35:43AM +0530, Vivek Gautam wrote: 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 gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, wrong comment style. Yea :-( will fix this. + * to make sure we know device state prior to + * pm_runtime_enable + */ + pm_runtime_set_suspended(dev); didn't Alan mention this should be done at the Bus level ? In that case, shouldn't you have call pm_runtime_set_active/suspended() based on DT's status=okay or status=disabled ? Or something similar ? True, we should be doing this at bus level. But he did also mention to let pm core know of the state of the device before enabling the runtime pm. Right ? Moreover immediately after pm_runtime_enable(), we do pm_runtime_get_sync() so that device comes to active state. I am possibly missing things out here, not able to grab this whole picture completely :-( Wouldn't DT's status=disabled actually be disabling the device as a whole ? So, how much will runtime power management on the device be affecting ? indeed, maybe we can keep it like this, but it would be nice to have OF core handle this for us based on whatever data. -- balbi signature.asc Description: Digital signature
Re: [PATCH 8/9] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 31 March 2013 09:23, Viresh Kumar viresh.ku...@linaro.org wrote:
On 25 March 2013 15:41, Viresh Kumar viresh.ku...@linaro.org wrote:
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
arch/arm/Kconfig | 46 ---
arch/arm/mach-s3c24xx/Kconfig | 66
+-
arch/arm/mach-s3c24xx/Makefile | 6 --
arch/arm/mach-s3c24xx/{ = include/mach}/s3c2412.h | 0
arch/arm/mach-s3c24xx/iotiming-s3c2412.c | 2 +-
arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
arch/arm/plat-samsung/include/plat/cpu-freq.h | 6 +-
drivers/cpufreq/Kconfig.arm| 58 +++
drivers/cpufreq/Makefile | 5 ++
.../cpufreq/s3c2410-cpufreq.c | 0
.../cpufreq/s3c2412-cpufreq.c | 3 +-
.../cpufreq/s3c2440-cpufreq.c | 0
.../cpufreq/s3c24xx-cpufreq-debugfs.c | 0
.../cpufreq.c = drivers/cpufreq/s3c24xx-cpufreq.c | 0
14 files changed, 100 insertions(+), 102 deletions(-)
rename arch/arm/mach-s3c24xx/{ = include/mach}/s3c2412.h (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =
drivers/cpufreq/s3c2410-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =
drivers/cpufreq/s3c2412-cpufreq.c (99%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =
drivers/cpufreq/s3c2440-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =
drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq.c = drivers/cpufreq/s3c24xx-cpufreq.c
(100%)
Ben/Kukjin,
Can i have your View or Ack for this patch?
Ping!!
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using randconfig
On Wed, Apr 03, 2013 at 10:46:53AM +0100, Chen Gang wrote: Hello Maintainers: when you have time, could you help to check this suggestion ? [...] make: make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig set arm-linux-gnu- for Cross-compiler tool prefix set Samsung S5PV210/S5PC210 for ARM system type make V=1 EXTRA_CFLAGS=-W ARCH=arm I think the main problem is that you've reported an issue created from a randconfig, but you haven't made the config in question available. Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using randconfig
On 2013年04月03日 18:10, Will Deacon wrote: I think the main problem is that you've reported an issue created from a randconfig, but you haven't made the config in question available. excuse me, my English is not quite well. I guess your meaning is : I need also provide the related .config file in this mail. so we can be more easier to find the root cause. is it correct ? BTW: unlucky, the original .config has been deleted. I can try to reproduce it, so let us to fix it with more efficiency. thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/12] mipi-csis: Enable all interrupts for fimc-is usage
Hi Arun, On 03/13/2013 05:09 AM, Arun Kumar K wrote: Hi Sylwester, /* Interrupt mask */ #define S5PCSIS_INTMSK 0x10 -#define S5PCSIS_INTMSK_EN_ALL0xf000103f +#define S5PCSIS_INTMSK_EN_ALL0xfc00103f Do you know what interrupts are assigned to the CSIS_INTMSK bits 26, 27 ? In the documentation I have they are marked as reserved. I have tested this patch on Exynos4x12, it seems OK but you might want to merge it to the patch adding compatible property for exynos5. The bits 26 and 27 are for Frame start and Frame end interrupts. Yes this change can be merged with the MIPI-CSIS support for Exynos5. Shaik will pick it up and merge it along with his patch series in v2. OK, thanks a lot for the clarification. I tested this patch on Exynos4x12 and I could see twice as many interrupts from MIPI-CSIS as there was captured frames from the sensor. Certainly we don't want to see these interrupts when they are not needed. I have been thinking of some interface that the MIPI-CSIS subdev would provide to the media driver, so it can enable the interrupts when needed. I suppose a private subdev ioctl might be good for that. But first I think there is e.g. a subdev flag needed so a subdev driver can decide that it doesn't want to have its non-standard ioctls called from user space. I'll see if I can address those issues. It would be good to know what these bits are for. And how enabling the interrupts actually help without modifying the interrupt handler ? Is it enough to just acknowledge those interrupts ? Or how it works ? These interrupts are used by the FIMC-IS firmware possibly to check if the sensor is working. Without enabling these, I get the error from firmware on Sensor Open command. Hm, interesting... Looks like the MIPI-CSIS interrupts get routed to the FIMC-IS GIC. I was also wondering how the FIMC-IS receives Embedded Data from the MIPI CSIS IP, which is sent by an image sensor. Presumably FIMC-IS can memory map the Embedded Data buffer at the MIPI CSIS internal memory, and then it reads from there. It's just a guess though. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi Felipe,
On Wed, Apr 3, 2013 at 1:45 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 11:48:39AM +0530, Vivek Gautam wrote:
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 gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
--
balbi
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
HI,
On Wed, Apr 03, 2013 at 06:42:48PM +0530, Vivek Gautam wrote:
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 gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do
you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made
by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 3, 2013 at 7:26 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe
and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what do
you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made
by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe
and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what
do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are
made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm
on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the
PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active
state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides
this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if
any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
On Wed, Apr 3, 2013 at 7:48 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in
probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what
do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are
made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm
on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the
PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active
state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in
that case,
only one of the consumer can enable runtime_pm on PHY. So who decides
this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if
any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)
Yes ofcourse.
So PHYs (in their runtime_suspend) should not be pulled into a state
wherein even the controllers become in-operational.
Thereby no attach-detection, and controller doesn't wake up to be able
to usb_phy_autopm_get_sync()
Sorry for so much noise, i am acting like slow study ;-)
--
balbi
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ASoC: Samsung: return error if drvdata is not set
On Tue, Apr 02, 2013 at 04:53:01PM +0530, Padmavathi Venna wrote: From: Prathyush K prathyus...@samsung.com This patch fixes a possible crash in case drvdata for the secondary device is not set. Applied both, thanks. signature.asc Description: Digital signature
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Lars, On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen l...@metafoo.de wrote: I think you still need the mutex for serialization, otherwise the requests would just cancel each other out. Btw. what happens if you start a conversion while another is still in progress? Is it possible to abort a conversion? I was thinking that the spinlock would just replace the mutex for the purposes of serialization. I stepped back a bit, though, and I'm wondering if we're over-thinking things. The timeout case should certainly be handled properly (thanks for pointing it out), but getting a timeout is really not expected and adding a lot of extra overhead to handle it elegantly seems a bit much? Specifically, the mutex means that we have one user of the ADC at a time, and ADC conversion has nothing variable about it. The user manual that I have access to talks about 12-bit conversion happening in 1 microsecond with a 5MHz input clock or 5 microseconds with a 1MHz input clock. Even if someone has clocks configured very differently, it would be hard to imagine a conversion actually taking a full second. ...so that means that if the timeout actually fires then something else fairly drastic has gone wrong. It's _very_ unlikely that the IRQ will still go off for this conversion sometime in the future. To me, total modifications to what's landed already ought to be: * Change timeout to long (from unsigned long) * Make sure we return errors (negative results) from wait_for_completion_interruptible_timeout() properly. * If we get back a value of 0 from wait_for_completion_interruptible_timeout() then we should print a warning and attempt machinations to reset the ADC. Without ever seeing real-world situtations that would cause a real timeout these machinations would be a bit of a guess (is resetting the adc useful when it's more likely that someone accidentally messed with the clock tree or power gated the ADC?)... ...or perhaps a warning and a TODO in the code would be enough? Thoughts? -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were part of the work
Kukjin, On Tue, Apr 2, 2013 at 7:16 PM, Kukjin Kim kgene@samsung.com wrote: Applied with 1st one, BTW, do you want to send this for stable tree? I don't have any need for it to be in stable tree. The ARM Chromebook hasn't reached critical functionality on any released/upstram Linux versions so it doesn't make much sense to backport fixes. If someone else wants it in stable (and can confirm that it helps them) then I certainly wouldn't object! One more note, just now I discussed Jaecheol Lee about the bit, ENABLE_WAKEUP_SW, as the patch fixed, it should be cleared but used to be set s3c_irqwake_intmask. Let me check again, then if any updates I'll let you know. OK, thanks. If there is a reason that ENABLE_WAKEUP_SW needs to be set then it would be good to understand that case. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] usb: dwc3/xhci/phy: Enable runtime power management
Question: Do you still need this patch for 3.10? http://marc.info/?l=linux-usbm=136057666911621w=2 Does this patchset build on top of that? I'm really behind on my patches for 3.10, sorry. Sarah Sharp On Mon, Apr 01, 2013 at 07:23:59PM +0530, Vivek Gautam wrote: This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on Samsung's USB 2.0 type and USB 3.0 type PHYs. Based on 'next' branch of Felipe Balbi's USB tree. Changes from v2: - Using separate functions for USB PHY runtime power management, instead of using macros. - Adding 'pm_runtime_set_suspended()' api call in dwc3 core layer before enabling runtime pm. (Ideally, we should be explicitly make device 'suspended' or 'active' before enabling runtime pm on it). - Checking return code for 'put_sync' and 'get_sync' of USB-PHYs when waking up or suspending them from dwc3 core's runtime_pm callbacks. - Removed buggy pm_runtime_put() calls from driver's (xhci, dwc3 and PHY) remove functions. - Adding a patch to enable runtime power management of Samsung's USB 2.0 PHY (usb: phy: samsung: Enable runtime power management on usb2phy) Changes from v1: - Adding required PHY APIs to handle runtime power management instead of directly twiddling with phy-dev. - Handling runtime power management of usb PHYs in dwc3 core driver instead of in any glue layer. - Splitting the patch: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb into required number to bifurcate functionality. Vivek Gautam (11): usb: phy: Add APIs for runtime power management USB: dwc3: Adjust runtime pm to allow autosuspend usb: dwc3: Enable runtime pm only after PHYs are initialized usb: dwc3: Add runtime power management callbacks usb: dwc3: exynos: Enable runtime power management usb: xhci: Enable runtime pm in xhci-plat usb: phy: samsung: Enable runtime power management on usb2phy usb: phy: samsung: Enable runtime power management on usb3phy usb: phy: samsung: Add support for external reference clock usb: phy: samsung: Add support for PHY ref_clk gpio usb: phy: samsung: Add support for PHY refclk switching drivers/usb/dwc3/core.c| 59 ++-- drivers/usb/dwc3/dwc3-exynos.c | 12 +++ drivers/usb/host/xhci-plat.c |6 ++ drivers/usb/phy/phy-samsung-usb.c | 26 +++ drivers/usb/phy/phy-samsung-usb.h |1 + drivers/usb/phy/phy-samsung-usb2.c |5 ++ drivers/usb/phy/phy-samsung-usb3.c | 119 +-- include/linux/usb/phy.h| 141 8 files changed, 358 insertions(+), 11 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] pinctrl: samsung: Split pin bank description into two structures
On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This patch splits pin bank description into two structures, one describing bank type (currently only bitfield widths), which can be shared across multiple banks and second containing bank-specific parameters including a pointer to a bank type struct. It is a prerequisite for further patch removing the statically hardcoded register offsets, making it impossible to support SoCs with different set and order of pin control registers. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com I'd like an ACK from Thomas Abraham on this patch. Thanks, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: GENERIC_GPIO considered deprecated
Alexandre Courbot wrote: Hi Romain, On Sat, Mar 30, 2013 at 3:07 PM, Romain Naour romain.na...@openwide.fr wrote: Hi Alex, When I read your mail, I was surprised that you were speaking about GPIOs, my pathes for samsung CPUs are intended for timer sub-system. As you can see in this thread, when I send my patches ARM: S3C24XX: Add samsung-time support for s3c24xx and Add samsung-time support for s5pc100. They didn't add select GENERIC_GPIO. http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13432/focus=14980 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13432/focus=14982 There is something wrong with the commit, I see that select GENERIC_GPIO was added in my patches by mistake. Oops, sorry about that. I recommend you to speak directly with samsung's kernel maintainer that I CC in this mail. Thanks... Indeed, it seems like these select GENERIC_GPIO have been added during the merge of your patches, since I can see the line is here in your patch (but not added by it). Kim, on the current next there are two of these select GENERIC_GPIO that are added from your branch, OK, I see. could you amend the patches that adds them such as they get changed into select ARCH_REQUIRE_GPIOLIB instead? You can grep for select I can do it for my tree but the branch already included in arm-soc tree so I think, it should be fixed with another patch. And GENERIC_GPIO in arch/arm to find the offending lines. We are removing GENERIC_GPIO and this work cannot be merged until you do this since it would break ARM builds. Thanks! So how about following? If you are OK, let me take into samsung tree. 88 From: Kukjin Kim kgene@samsung.com Subject: [PATCH] ARM: SAMSUNG: change GENERIC_GPIO to ARCH_REQUIRE_GPIOLIB When I applied regarding samsung-time patches, the select GENERIC_GPIO has been added wrong, so this patch fixes that. And since the GENERIC_GPIO in arch/arm/ will be gone away, this adds ARCH_REQUIRE_GPIOLIB for S3C24XX and S5PC100 instead. Reported-by: Alexandre Courbot gnu...@gmail.com Cc: Romain Naour romain.na...@openwide.fr Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 46fcfa8..a239c7e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -770,10 +770,10 @@ config ARCH_SA1100 config ARCH_S3C24XX bool Samsung S3C24XX SoCs select ARCH_HAS_CPUFREQ + select ARCH_REQUIRE_GPIOLIB select CLKDEV_LOOKUP select CLKSRC_MMIO select GENERIC_CLOCKEVENTS - select GENERIC_GPIO select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG @@ -828,11 +828,11 @@ config ARCH_S5P64X0 config ARCH_S5PC100 bool Samsung S5PC100 + select ARCH_REQUIRE_GPIOLIB select CLKDEV_LOOKUP select CLKSRC_MMIO select CPU_V7 select GENERIC_CLOCKEVENTS - select GENERIC_GPIO select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE: [PATCH 00/21] Various fixes and extensions to Exynos4 clock driver
Mike Turquette wrote: Quoting Kukjin Kim (2013-04-02 01:30:39) Tomasz Figa wrote: On Saturday 30 of March 2013 15:33:00 Thomas Abraham wrote: Hi Tomasz, On 27 March 2013 16:32, Tomasz Figa t.f...@samsung.com wrote: This series is a collection of various fixes and extensions to Exynos4 clock driver, which improve coverage of clocks present on Exynos4 SoCs and fix problems discovered during our internal work and testing. Nice series. Thanks for the improvements and fixes. Looking at the second patch in this series, I crossed checked again with the Exynos4412 user manual that I have. Your modifications are different from what the manual has listed. I suspect, you have a newer copy of the manual. Right. I have checked revisions 0.0, 0.1 and 1.1 of the manual and indeed there are differences in clock layout between 0.1 and 1.1. My patches are based on revision 1.1. Correct...hmm... For this series: Reviewed-by: Thomas Abraham thomas.abra...@linaro.org Yes, looks good to me but would be better if I could get Mike's ack on this series. Acked-by: Mike Turquette mturque...@linaro.org Thanks, applied. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges property
On Wednesday, March 27, 2013 10:04 PM, Thierry Reding wrote:
On Tue, Mar 26, 2013 at 04:20:23PM +, Andrew Murray wrote:
This patch factors out common implementation patterns to reduce overall
kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges
them
into a single range (as was the case with powerpc and microblaze).
The modifications to microblaze, mips and powerpc have not been tested.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Thierry Reding thierry.red...@avionic-design.de
It works properly with Exynos5440.
Tested-by: Jingoo Han jg1@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iio: adc: exynos_adc: Handle timeout issues
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch does the following
1. Handle the return values of wait_for_completion_interruptible_timeout
2. Reset software if a timeout happes.
Note: submitted for review at https://patchwork.kernel.org/patch/2279591/
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Lars-Peter Clausen l...@metafoo.de
---
As per the comments from Doug at
http://marc.info/?l=linux-kernelm=136500878406955w=3
Changes since v1:
1. Remove the spin lock implememtation and the INIT_COMPLETION
2. Rearrange the code and reset the ADC in cases of timeout.
drivers/iio/adc/exynos_adc.c | 73 ++--
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 5ab0dfd..a6c4df5 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -111,6 +111,35 @@ static inline unsigned int exynos_adc_get_version(struct
platform_device *pdev)
return (unsigned int)match-data;
}
+static void exynos_adc_hw_init(struct exynos_adc *info)
+{
+ u32 con1, con2;
+ int delay;
+
+ if (info-version == ADC_V2) {
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info-regs));
+
+ /* ADC H/W requires 25PCLKs before other register access */
+ delay = DIV_ROUND_UP(25 * 100, clk_get_rate(info-clk));
+ udelay(delay);
+
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info-regs));
+
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info-regs));
+ } else {
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info-regs));
+ }
+}
+
static int exynos_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
@@ -118,8 +147,9 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
long mask)
{
struct exynos_adc *info = iio_priv(indio_dev);
- unsigned long timeout;
+ long timeout;
u32 con1, con2;
+ int ret;
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
@@ -146,14 +176,21 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
timeout = wait_for_completion_interruptible_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
- *val = info-value;
- mutex_unlock(indio_dev-mlock);
+ if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out reseting\n);
+ exynos_adc_hw_init(info);
+ ret = -ETIMEDOUT;
+ } else if (timeout 0) {
+ ret = timeout;
+ } else {
+ *val = info-value;
+ ret = IIO_VAL_INT;
+ }
- if (timeout == 0)
- return -ETIMEDOUT;
+ mutex_unlock(indio_dev-mlock);
- return IIO_VAL_INT;
+ return ret;
}
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
@@ -225,30 +262,6 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
-{
- u32 con1, con2;
-
- if (info-version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info-regs));
-
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info-regs));
-
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info-regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
-
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info-regs));
- }
-}
-
static int exynos_adc_probe(struct platform_device *pdev)
{
struct exynos_adc *info = NULL;
--
1.7.12.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE: [PATCH v2 0/4] clk: samsung: pm fixes and multiple aliases
Mike Turquette wrote: Quoting Kukjin Kim (2013-03-25 02:26:34) Heiko Stübner wrote: Second version of the fixes to address comments gathered from the first version, like not entering the dt code on non-dt platforms even if dt-support is present in the kernel. Patch 1 and 3 got Reviewed-by tags but I only included the one for patch 1, because patch 3 changed due to the changes in patch 2. Heiko Stuebner (4): clk: samsung: register clk_div_tables for divider clocks clk: samsung: fix pm init on non-dt platforms clk: samsung: always allocate the clk_table clk: samsung: add infrastructure to add separate aliases drivers/clk/samsung/clk.c | 72 +++-- --- drivers/clk/samsung/clk.h | 34 ++-- 2 files changed, 87 insertions(+), 19 deletions(-) -- 1.7.2.3 Looks good to me and applied into samsung tree based on samsung common clock by Thomas P Abraham for testing. But would be helpful to me if I could get Mike's ack on this series. Acked-by: Mike Turquette mturque...@linaro.org Applied, thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] usb: dwc3/xhci/phy: Enable runtime power management
Hi Sarah, On Wed, Apr 3, 2013 at 10:57 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Question: Do you still need this patch for 3.10? Felipe's 'next' is closed for 3.10, so this series won't be making it to 3.10 now, as a whole. :-( http://marc.info/?l=linux-usbm=136057666911621w=2 Does this patchset build on top of that? Yea, it builds fine on top of the above mentioned patch. I would suggest that we pull the xhci-plat patch in this series when the complete patch-set getting in. btw, its your decision ;-) I'm really behind on my patches for 3.10, sorry. Sarah Sharp On Mon, Apr 01, 2013 at 07:23:59PM +0530, Vivek Gautam wrote: This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on Samsung's USB 2.0 type and USB 3.0 type PHYs. Based on 'next' branch of Felipe Balbi's USB tree. Changes from v2: - Using separate functions for USB PHY runtime power management, instead of using macros. - Adding 'pm_runtime_set_suspended()' api call in dwc3 core layer before enabling runtime pm. (Ideally, we should be explicitly make device 'suspended' or 'active' before enabling runtime pm on it). - Checking return code for 'put_sync' and 'get_sync' of USB-PHYs when waking up or suspending them from dwc3 core's runtime_pm callbacks. - Removed buggy pm_runtime_put() calls from driver's (xhci, dwc3 and PHY) remove functions. - Adding a patch to enable runtime power management of Samsung's USB 2.0 PHY (usb: phy: samsung: Enable runtime power management on usb2phy) Changes from v1: - Adding required PHY APIs to handle runtime power management instead of directly twiddling with phy-dev. - Handling runtime power management of usb PHYs in dwc3 core driver instead of in any glue layer. - Splitting the patch: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb into required number to bifurcate functionality. Vivek Gautam (11): usb: phy: Add APIs for runtime power management USB: dwc3: Adjust runtime pm to allow autosuspend usb: dwc3: Enable runtime pm only after PHYs are initialized usb: dwc3: Add runtime power management callbacks usb: dwc3: exynos: Enable runtime power management usb: xhci: Enable runtime pm in xhci-plat usb: phy: samsung: Enable runtime power management on usb2phy usb: phy: samsung: Enable runtime power management on usb3phy usb: phy: samsung: Add support for external reference clock usb: phy: samsung: Add support for PHY ref_clk gpio usb: phy: samsung: Add support for PHY refclk switching drivers/usb/dwc3/core.c| 59 ++-- drivers/usb/dwc3/dwc3-exynos.c | 12 +++ drivers/usb/host/xhci-plat.c |6 ++ drivers/usb/phy/phy-samsung-usb.c | 26 +++ drivers/usb/phy/phy-samsung-usb.h |1 + drivers/usb/phy/phy-samsung-usb2.c |5 ++ drivers/usb/phy/phy-samsung-usb3.c | 119 +-- include/linux/usb/phy.h| 141 8 files changed, 358 insertions(+), 11 deletions(-) -- 1.7.6.5 -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 0/7] Update Arndale board support
Tushar Behera wrote: Arndale board support has been updated using pin-control and common clock framework. The patchset is based on Kukjin's for-next. commit d58f6a153f40 (Merge branch 'next/clk-exynos-2' into for-next) It depends on following patchset. [PATCH 0/2] ARM: dts: Add default pin states for client nodes on Exynos4/5 platforms http://comments.gmane.org/gmane.linux.kernel.samsung-soc/16559 Following 2 patches have been newly added in this patchset because of changes during 3.9 merge window. 1/7: ARM: dts: Add pin-control related changes for Arndale board 2/7: ARM: dts: Add disable-wp for card slot on exynos5250-arndale Amit Daniel Kachhap (1): ARM: dts: Add PMIC node entry for Arndale board Sachin Kamat (4): ARM: dts: Add disable-wp for card slot on exynos5250-arndale ARM: dts: Add vmmc regulator support for Arndale board ARM: dts: Add MFC codec support for Arndale board ARM: dts: Add HDMI HPD and regulator node for Arndale board Tushar Behera (2): ARM: dts: Add pin-control related changes for Arndale board ARM: dts: Add gpio-button entries for Arndale board arch/arm/boot/dts/exynos5250-arndale.dts | 343 +- 1 file changed, 333 insertions(+), 10 deletions(-) -- 1.7.9.5 Applied this whole series, thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mmc: dwmmc: let device core setup the default pin configuration
On Wednesday, April 03, 2013, Doug Anderson wrote: Thomas, On Mon, Apr 1, 2013 at 11:09 PM, Thomas Abraham thomas.abra...@linaro.org wrote: With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org You missed Seungwon's other feedback. Please change the title from mmc: dwmmc: let device core setup the default pin configuration to mmc: dw_mmc: let device core setup the default pin configuration. He requested that the tag have the underscore in it for consistency. If you're resending, it also seems like it might be nice to rebase this atop: 0f6e73d mmc: dw_mmc: Add MSHC compatible for Exynos4412 ...just to avoid the simple merge conflict when applying? Otherwise everything here looks great... -Doug Thomas, It's a conflict to merge. Please do rebase the patch. Thanks, Seungwon Jeon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Would it be possible for you to either delay the removal of shmobile_timer_init. In general I am in favour of the following approach to wide changes such as this one: 1. Add new feature 2. Convert users to new feature 3. Remove old feature. If it is not possible to delay the removal of shmobile_timer_init could you update your base such that you also remove its usage from the following files: arch/arm/mach-shmobile/board-kzm9g-reference.c arch/arm/mach-shmobile/setup-r8a73a4.c arch/arm/mach-shmobile/setup-r8a7779.c arch/arm/mach-shmobile/board-lager.c arch/arm/mach-shmobile/board-ape6evm.c arch/arm/mach-shmobile/setup-r8a7778.c arch/arm/mach-shmobile/board-marzen-reference.c arch/arm/mach-shmobile/setup-r8a7790.c arch/arm/mach-shmobile/board-bockw.c The above files are all present in the arm-soc/next/boards2 branch of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git. I am happy for you use the later as a base if you wish. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Russell King li...@arm.linux.org.uk Cc: Kukjin Kim kgene@samsung.com Cc: Tony Lindgren t...@atomide.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: linux-samsung-soc@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux...@vger.kernel.org --- arch/arm/include/asm/arch_timer.h| 13 + arch/arm/kernel/arch_timer.c | 17 +++-- arch/arm/mach-exynos/mach-exynos5-dt.c |1 - arch/arm/mach-exynos/mct.c |6 -- arch/arm/mach-highbank/highbank.c|5 + arch/arm/mach-omap2/timer.c |5 + arch/arm/mach-shmobile/board-kzm9d.c |1 - I have boot tested the board-kzm9d change on the kzm9d board, it seems fine. arch/arm/mach-shmobile/include/mach/common.h |1 - arch/arm/mach-shmobile/setup-emev2.c |1 - I am not able to test the setup-emev2 portion properly at this time, booting the kzm9d board without the board-kzm9d file seems broken without your patch. However, your change seems reasonable to me. arch/arm/mach-shmobile/setup-r8a7740.c |1 - I am not able to test the setup-r8a7740 portion properly at this time, booting the armadillo800eva board without the board-armadillo800eva file seems broken without your patch. However, your change seems reasonable to me. arch/arm/mach-shmobile/setup-sh7372.c|1 - I am not able to test the setup-sh7372 portion properly at this time, booting the mackerel board without the board-mackerel file seems broken without your patch. However, your change seems reasonable to me. arch/arm/mach-shmobile/setup-sh73a0.c|1 - I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine. The tests above were made by merging git://sources.calxeda.com/kernel/linux.git arm-timers head commit: df3f518db302caf9fc0511917c5e9021037f6fcd (devtree: add binding documentation for sp804) and the renesas-next-20130403 tag of the renesas tree (URL above). arch/arm/mach-shmobile/timer.c |6 -- arch/arm/mach-vexpress/v2m.c |7 ++- arch/arm/mach-virt/virt.c|9 - arch/arm64/include/asm/arch_timer.h |5 + arch/arm64/kernel/time.c |6 -- drivers/clocksource/Kconfig |1 + drivers/clocksource/arm_arch_timer.c | 23 +-- include/clocksource/arm_arch_timer.h |6 -- 20 files changed, 27 insertions(+), 89 deletions(-) diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h index 7ade91d..7c1bfc0 100644 --- a/arch/arm/include/asm/arch_timer.h +++ b/arch/arm/include/asm/arch_timer.h @@ -10,8 +10,7 @@ #include clocksource/arm_arch_timer.h #ifdef CONFIG_ARM_ARCH_TIMER -int arch_timer_of_register(void); -int arch_timer_sched_clock_init(void); +int arch_timer_arch_init(void); /* * These register accessors are marked inline so the compiler can @@ -110,16 +109,6 @@ static inline void __cpuinit arch_counter_set_user_access(void) asm volatile(mcr p15, 0, %0, c14, c1, 0 : : r (cntkctl)); } -#else -static inline int arch_timer_of_register
