Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines
On Friday, April 25, 2014, Thierry Reding thierry.red...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote: Thierry, On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote: [...] Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. I'm not at all comfortable with these. The names are totally confusing. Next somebody will need to do something after the panel has been enabled and we'll have to introduce .post_enable() and .pre_disable() functions. And worse, what if somebody needs something to be done between .pre_enable() and .enable()? .post_pre_enable()? Where does it end? According to the above description the only reason why we need this is to avoid visible glitches when the panel is already on, but the video stream hasn't started yet. If that's the only reason why we need this, then perhaps adding a way for a panel to expose the associated backlight would be better? Actually, we need not expose the entire backlight device. AFAIK, the glitch is caused when you enable BL_EN before there is valid video data. So, one way to mask off the glitch is to follow this sequence: -- power up the panel. -- start video data, (start PWM here or) -- (start PWM here), enable backlight That's very difficult to get right, isn't it? Even if you have fine- grained control over what to enable you still need a way to determine _when_ it's safe to enable the backlight. Typically I guess that would be the duration of one frame (or perhaps 2, depending on when the panel syncs to the video signal). We need not determine, its already present in LVDS datasheet. The LVDS datasheet says at least 200ms delay is needed from Valid data to BL on. Perhaps it could even by sync'ed to the VBLANK? No. vblanks are related to crtc. And the bridge/panel driver should be independent of vblank. The problem is that the above scenario cannot be mapped to panel-simple driver. IMO, panel_simple should provide enable/disable controls both for LCD and backlight. something like panel_simple_lcd_enable/panel_simple_led_enable, and panel_simple_lcd_disable/panel_simple_led_disable. That's not what the simple panel driver can do. If we want this it needs to be solved in a generic way for all panels since they all need to use the drm_panel_*() functions to abstract away the details from drivers that use the panels. Right. So only I have added pre_enable and post_disable callbacks. Using that name won't harm existing panel drivers and still addresses our requirement. Regards, Ajay -- 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 7/9] drm/bridge: ptn3460: add drm_panel controls
On Thu, Apr 24, 2014 at 11:08 PM, Ajay kumar ajayn...@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar ajayn...@gmail.com wrote:
Rob,
On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
Sorry for the previous reply,
Here goes the full explaination:
Rob,
On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
We cannot call them like this from crtc helpers in the order you
mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
-- sometimes panel controls needs to be done before bridge
controls(ptn3460: before RST_N and PD_N)
well, this is why bridge has pre-enable/enable/disable/post-disable
hooks, so you can choose before or after..
These calls are for a bridge to sync with the encoder calls.
We might end up defining pre-enable/enable/disable/post-disable for a
panel to sync
with the bridge calls! I have explained below.
-- sometimes in between the bridge controls (ps8622: one panel control
before SLP_N and one after SLP_N)
-- sometimes panel controls needs to be done after bridge controls.
I am not convinced that a generic panel/bridge adapter is not
possible. Maybe we need more fine grained fxn ptr callbacks, although
seems like pre+post should give you enough. It would certainly be
easier than having to add panel support in each individual bridge
driver (which seems like it will certainly result that only certain
combinations of panel+bridge actually work as intended)
Ok. Consider this case:
Currently, we have the sequence as bridge-pre_enable,
encoder_enable, bridge-enable
And, the bridge should obviously be enabled in bridge-pre_enable.
Now, where do you choose to call panel-pre_enable?
-- as the first step of bridge-pre_enable, before we pull up/down bridge
GPIOs.
-- at the last step of bridge-pre_enable, after we pull up/down the
bridge GPIOs.
Ideally, PTN3460 expects it to be the second case, and PS8625 expects
it to be the first case.
So, we will end up adding pre_pre_enable, post_pre_enable to
accomodate such scenarios.
ok, well I think we can deal with this with a slight modification of
my original proposal. Split drm_panel_bridge into
drm_composite_bridge and drm_panel_bridge:
struct drm_composite_bridge {
struct drm_bridge base;
struct drm_bridge *b1, *b2;
}
static void drm_composite_bridge_enable(struct drm_bridge *bridge)
{
struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
cbridge-b1-funcs-enable(cbridge-b1);
cbridge-b2-funcs-enable(cbridge-b2);
}
.. and so on ..
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
}
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
pbridge-panel-funcs-enable(pbridge-panel);
}
.. and so on..
then in initialization, order can be managed like:
if (panel_first)
bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
else
bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);
possibly parametrize drm_panel_bridge if we need to map
panel-enable() to bridge-pre_enable() vs bridge-enable(), etc..
Well, this really does seems complex to me.
Don't you think just having a drm_panel inside drm_bridge structure is
sufficient?!
And, make a call for pre_panel_enable and post_panel_enable around
bridge-pre_enable..and so on.?
Adding more comments:
The beauty of drm_panel is in the flexibility which it provides.
We can call panel_enable/disable at the right point. Even the
--
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 7/9] drm/bridge: ptn3460: add drm_panel controls
Sorry for the previous reply. Here goes the full explaination.
On Fri, Apr 25, 2014 at 11:40 AM, Ajay kumar ajayn...@gmail.com wrote:
On Thu, Apr 24, 2014 at 11:08 PM, Ajay kumar ajayn...@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar ajayn...@gmail.com wrote:
Rob,
On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar ajayn...@gmail.com wrote:
Sorry for the previous reply,
Here goes the full explaination:
Rob,
On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
We cannot call them like this from crtc helpers in the order you
mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
-- sometimes panel controls needs to be done before bridge
controls(ptn3460: before RST_N and PD_N)
well, this is why bridge has pre-enable/enable/disable/post-disable
hooks, so you can choose before or after..
These calls are for a bridge to sync with the encoder calls.
We might end up defining pre-enable/enable/disable/post-disable for a
panel to sync
with the bridge calls! I have explained below.
-- sometimes in between the bridge controls (ps8622: one panel control
before SLP_N and one after SLP_N)
-- sometimes panel controls needs to be done after bridge controls.
I am not convinced that a generic panel/bridge adapter is not
possible. Maybe we need more fine grained fxn ptr callbacks, although
seems like pre+post should give you enough. It would certainly be
easier than having to add panel support in each individual bridge
driver (which seems like it will certainly result that only certain
combinations of panel+bridge actually work as intended)
Ok. Consider this case:
Currently, we have the sequence as bridge-pre_enable,
encoder_enable, bridge-enable
And, the bridge should obviously be enabled in bridge-pre_enable.
Now, where do you choose to call panel-pre_enable?
-- as the first step of bridge-pre_enable, before we pull up/down bridge
GPIOs.
-- at the last step of bridge-pre_enable, after we pull up/down the
bridge GPIOs.
Ideally, PTN3460 expects it to be the second case, and PS8625 expects
it to be the first case.
So, we will end up adding pre_pre_enable, post_pre_enable to
accomodate such scenarios.
ok, well I think we can deal with this with a slight modification of
my original proposal. Split drm_panel_bridge into
drm_composite_bridge and drm_panel_bridge:
struct drm_composite_bridge {
struct drm_bridge base;
struct drm_bridge *b1, *b2;
}
static void drm_composite_bridge_enable(struct drm_bridge *bridge)
{
struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
cbridge-b1-funcs-enable(cbridge-b1);
cbridge-b2-funcs-enable(cbridge-b2);
}
.. and so on ..
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
}
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
pbridge-panel-funcs-enable(pbridge-panel);
}
.. and so on..
then in initialization, order can be managed like:
if (panel_first)
bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
else
bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);
possibly parametrize drm_panel_bridge if we need to map
panel-enable() to bridge-pre_enable() vs bridge-enable(), etc..
Well, this really does seems complex to me.
Don't you think just having a drm_panel inside drm_bridge structure is
sufficient?!
And, make a call for pre_panel_enable and post_panel_enable around
bridge-pre_enable..and so on.?
Adding more comments:
The beauty of drm_panel is in the flexibility which it provides.
We can call panel_enable/disable at the right point. Even the bridge chips
expect the same. So, I am not ok with combining the bridge and panel and
calling the fxn pointers from crtc_helpers.
So, either we leave it the way it is in this patch (call drm_panel
functions at right points) or
we don't use drm_panel to control the panel sequence and instead use few DT
properties and regulators, inside the bridge chip driver.
--
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
Re: [PATCH v5 1/9] dt: exynos5420: Enable support for USB 3.0 PHY controller
On 04/23/2014 08:00 PM, Vivek Gautam wrote:
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..f69745f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -732,4 +732,24 @@
clock-names = secss;
samsung,power-domain = g2d_pd;
};
+
+ usbdrd_phy0: phy@1210 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USBD300, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
Should the property name be samsung,syscon-phandle as used elsewhere?
samsung,syscon-phandle = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
+
+ usbdrd_phy1: phy@1250 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1250 0x100;
+ clocks = clock CLK_USBD301, clock CLK_SCLK_USBPHY301;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
ditto
+ samsung,pmu-offset = 0x708;
+ #phy-cells = 1;
+ };
};
--
Tushar Behera
--
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 v5 3/9] dt: exynos5250: Enable support for generic USB DRD phy
On 04/23/2014 08:00 PM, Vivek Gautam wrote:
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..d4254c0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -551,6 +551,16 @@
};
};
+ usbdrd_phy: phy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USB3, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
Replace samsung,pmu-syscon by samsung,syscon-phandle ?
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
--
Tushar Behera
--
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] Exynos4: cpuidle: support dual CPUs with AFTR state
On 04/24/2014 07:42 PM, Tomasz Figa wrote:
Hi Daniel,
Please see my comments inline.
Hi Tomasz,
Btw. Please fix your e-mail composer to properly wrap your messages
around 7xth column, as otherwise they're hard to read.
Well it is already set to the 71th column.
On 04.04.2014 11:48, Daniel Lezcano wrote:
The following driver is for exynos4210. I did not yet finished the
other boards, so
I created a specific driver for 4210 which could be merged later.
The driver is based on Colin Cross's driver found at:
https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
This one was based on a 3.4 kernel and an old API.
It has been refreshed, simplified and based on the recent code cleanup
I sent
today.
The AFTR could be entered when all the cpus (except cpu0) are down. In
order to
reach this situation, the couple idle states are used.
There is a sync barrier at the entry and the exit of the low power
function. So
all cpus will enter and exit the function at the same time.
At this point, CPU0 knows the other cpu will power down itself. CPU0
waits for
the CPU1 to be powered down and then initiate the AFTR power down
sequence.
No interrupts are handled by CPU1, this is why we switch to the timer
broadcast
even if the local timer is not impacted by the idle state.
When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then
they both
exit the idle function.
This driver allows the exynos4210 to have the same power consumption
at idle
time than the one when we have to unplug CPU1 in order to let CPU0 to
reach
the AFTR state.
This patch is a RFC because, we have to find a way to remove the macros
definitions and cpu powerdown function without pulling the arch dependent
headers.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-exynos/common.c| 11 +-
drivers/cpuidle/Kconfig.arm |8 ++
drivers/cpuidle/Makefile |1 +
drivers/cpuidle/cpuidle-exynos4210.c | 226
++
4 files changed, 245 insertions(+), 1 deletion(-)
create mode 100644 drivers/cpuidle/cpuidle-exynos4210.c
diff --git a/arch/arm/mach-exynos/common.c
b/arch/arm/mach-exynos/common.c
index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
};
+static struct platform_device exynos4210_cpuidle = {
+.name = exynos4210-cpuidle,
+.dev.platform_data = exynos_sys_powerdown_aftr,
+.id= -1,
+};
+
void __init exynos_cpuidle_init(void)
{
-platform_device_register(exynos_cpuidle);
+if (soc_is_exynos4210())
+platform_device_register(exynos4210_cpuidle);
+else
+platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+bool Cpu Idle Driver for the Exynos 4210 processor
+default y
+depends on ARCH_EXYNOS
+select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+help
+ Select this to enable cpuidle for the Exynos 4210 processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+= cpuidle-zynq.o
obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUIDLE)+= cpuidle-exynos4210.o
###
# POWERPC drivers
diff --git a/drivers/cpuidle/cpuidle-exynos4210.c
b/drivers/cpuidle/cpuidle-exynos4210.c
new file mode 100644
index 000..56f6d51
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-exynos4210.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *http://www.samsung.com
+ *
+ * Copyright (c) 2014 Linaro : Daniel Lezcano
daniel.lezc...@linaro.org
+ *http://www.linaro.org
+ *
+ * Based on the work of Colin Cross ccr...@android.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/cpuidle.h
+#include linux/cpu_pm.h
+#include linux/io.h
+#include linux/platform_device.h
+
+#include asm/proc-fns.h
+#include asm/suspend.h
+#include asm/cpuidle.h
+
+#include plat/pm.h
+#include plat/cpu.h
+#include plat/map-base.h
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On 04/14/2014 08:07 PM, Sylwester Nawrocki wrote:
On 08/04/14 16:36, Vivek Gautam wrote:
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices for
more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+- samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+- samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+- phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+- ref: PHY's reference clock (usually crystal clock), associated by
+ phy name, used to determine bit values for clock settings
+ register.
+Additional clock required for Exynos5420:
+- usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
Why to append -phandle to the property's name ? If this is for PMU
perhaps make it more explicit and name it: samsung,pmu-syscon or
samsung,pmureg ?
There are already a couple of nodes (watchdog and sata) using
samsung,syscon-phandle. IMHO, we should keep only property string for
syscon node. Either we keep syscon-phandle here or change sata/watchdog
driver to use the modified property name.
--
Tushar Behera
--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Fri, Apr 25, 2014 at 1:27 PM, Tushar Behera tushar.beh...@linaro.org wrote:
On 04/14/2014 08:07 PM, Sylwester Nawrocki wrote:
On 08/04/14 16:36, Vivek Gautam wrote:
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices for
more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+- samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+- samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+- phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+- ref: PHY's reference clock (usually crystal clock), associated by
+ phy name, used to determine bit values for clock settings
+ register.
+Additional clock required for Exynos5420:
+- usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
Why to append -phandle to the property's name ? If this is for PMU
perhaps make it more explicit and name it: samsung,pmu-syscon or
samsung,pmureg ?
There are already a couple of nodes (watchdog and sata) using
samsung,syscon-phandle. IMHO, we should keep only property string for
syscon node. Either we keep syscon-phandle here or change sata/watchdog
driver to use the modified property name.
IMHO samsung,pmu-syscon make more sense rather than appending a
'-phandle' to the property name.
This is a 'phandle' and that is in fact understood, isn't it ?
We can change in the watchdog, sata drivers to use use the modified name.
I can send a patch for the same if we are OK with this, so that we
maintain the consistency in the device tree.
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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/4] ARM: dts: exynos4: add PMU syscon node
Hi,
On Thu, Apr 24, 2014 at 9:37 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Chanho,
On 14.04.2014 14:48, Chanho Park wrote:
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};
+ pmu_reg: syscon@1002 {
+ compatible = samsung,exynos4-pmureg, syscon;
Assume a case where exynos PMU is made as platform driver [1] and we
need use the compatible samsung,exynos4-pmureg in the driver.
But since syscon driver uses compatible syscon and once the syscon
driver is probed, the exynos PMU platform driver [1] will NEVER be
probed.
So my question is, can we have 2 compatible strings for a DT node, and
both the compatible strings are used for probing purpose?
Recently I faced this issue on exynos5250, where i was testing PMU
driver [1] and I noticed that PMU driver [1] was NEVER probed, if I
enable syscon driver in menuconfig.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg28038.html
This compatible string doesn't seem to be defined in [1], please add it
there,
[1] Documentation/devicetree/bindings/arm/samsung/pmu.txt
Otherwise looks good, so after fixing that you may add my
Reviewed-by: Tomasz Figa t.f...@samsung.com
Best regards,
Tomasz
--
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
--
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: [PATCHv2 0/4] Enable usbphy and hsotg for exynos4
Hi Chanho, On 25.04.2014 08:59, Chanho Park wrote: This patchset enables a exynos4 usbphy and hsotg DT node for exynos4. The usb phy node uses generic exynos phy driver. The driver uses PMU syscon and SYSREG syscon phandles. Changes from v1: Applied Tomasz Figa's comments - Document PMU syscon compatibles for exynos4210/4x12 - Use clock macro instead of raw clock number - Correct phy name to usb2-phy Chanho Park (4): ARM: dts: exynos4: add PMU syscon node ARM: dts: exynos4: add exynos_usbphy node ARM: dts: exynos4: add hsotg device node ARM: dts: exynos4412-trats2: enable usb nodes .../devicetree/bindings/arm/samsung/pmu.txt| 2 ++ arch/arm/boot/dts/exynos4.dtsi | 26 ++ arch/arm/boot/dts/exynos4412-trats2.dts| 10 + arch/arm/boot/dts/exynos4x12.dtsi | 9 4 files changed, 47 insertions(+) For the whole series: Reviewed-by: Tomasz Figa t.f...@samsung.com -- Best regards, Tomasz -- 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 4/5] devfreq: exynos4: Use devm_devfreq_* function using device resource management
This patch uses devm_devfreq_add_device()/devm_devfreq_register_opp_notifier()
to control automatically the resource of devfreq.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Wei Yongjun yongjun_...@trendmicro.com.cn
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/devfreq/exynos/exynos4_bus.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index d257f1f..bebb0a4 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -979,7 +979,7 @@ static int exynos4_busfreq_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, data);
- data-devfreq = devfreq_add_device(dev, exynos4_devfreq_profile,
+ data-devfreq = devm_devfreq_add_device(dev, exynos4_devfreq_profile,
simple_ondemand, NULL);
if (IS_ERR(data-devfreq))
return PTR_ERR(data-devfreq);
@@ -991,27 +991,20 @@ static int exynos4_busfreq_probe(struct platform_device
*pdev)
busfreq_mon_reset(ppmu_data);
/* Register opp_notifier for Exynos4 busfreq */
- err = devfreq_register_opp_notifier(dev, data-devfreq);
+ err = devm_devfreq_register_opp_notifier(dev, data-devfreq);
if (err 0) {
dev_err(dev, Failed to register opp notifier\n);
- goto err_notifier_opp;
+ return err;
}
/* Register pm_notifier for Exynos4 busfreq */
err = register_pm_notifier(data-pm_notifier);
if (err) {
dev_err(dev, Failed to setup pm notifier\n);
- goto err_notifier_pm;
+ return err;
}
return 0;
-
-err_notifier_pm:
- devfreq_unregister_opp_notifier(dev, data-devfreq);
-err_notifier_opp:
- devfreq_remove_device(data-devfreq);
-
- return err;
}
static int exynos4_busfreq_remove(struct platform_device *pdev)
@@ -1020,10 +1013,6 @@ static int exynos4_busfreq_remove(struct platform_device
*pdev)
/* Unregister all of notifier chain */
unregister_pm_notifier(data-pm_notifier);
- devfreq_unregister_opp_notifier(data-dev, data-devfreq);
-
- /* Remove devfreq instance */
- devfreq_remove_device(data-devfreq);
return 0;
}
--
1.8.0
--
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 5/5] devfreq: exynos5: Use devm_devfreq_* function using device resource management
This patch uses devm_devfreq_add_device()/devm_devfreq_register_opp_notifier()
to control automatically the resource of devfreq.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Manish Badarkhe badarkhe.man...@gmail.com
Cc: Abhilash Kesavan a.kesa...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/devfreq/exynos/exynos5_bus.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index ab54a69..1f622f8 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -165,11 +165,6 @@ static int exynos5_int_get_dev_status(struct device *dev,
}
static void exynos5_int_exit(struct device *dev)
{
- struct platform_device *pdev = container_of(dev, struct platform_device,
- dev);
- struct busfreq_data_int *data = platform_get_drvdata(pdev);
-
- devfreq_unregister_opp_notifier(dev, data-devfreq);
}
static struct devfreq_dev_profile exynos5_devfreq_int_profile = {
@@ -343,30 +338,29 @@ static int exynos5_busfreq_int_probe(struct
platform_device *pdev)
busfreq_mon_reset(ppmu_data);
- data-devfreq = devfreq_add_device(dev, exynos5_devfreq_int_profile,
+ data-devfreq = devm_devfreq_add_device(dev,
exynos5_devfreq_int_profile,
simple_ondemand, NULL);
-
if (IS_ERR(data-devfreq)) {
err = PTR_ERR(data-devfreq);
- goto err_devfreq_add;
+ return err;
}
- devfreq_register_opp_notifier(dev, data-devfreq);
+ err = devm_devfreq_register_opp_notifier(dev, data-devfreq);
+ if (err 0) {
+ dev_err(dev, Failed to register opp notifier\n);
+ return err;
+ }
err = register_pm_notifier(data-pm_notifier);
if (err) {
dev_err(dev, Failed to setup pm notifier\n);
- goto err_devfreq_add;
+ return err;
}
/* TODO: Add a new QOS class for int/mif bus */
pm_qos_add_request(data-int_req, PM_QOS_NETWORK_THROUGHPUT, -1);
return 0;
-
-err_devfreq_add:
- devfreq_remove_device(data-devfreq);
- return err;
}
static int exynos5_busfreq_int_remove(struct platform_device *pdev)
@@ -375,7 +369,6 @@ static int exynos5_busfreq_int_remove(struct
platform_device *pdev)
pm_qos_remove_request(data-int_req);
unregister_pm_notifier(data-pm_notifier);
- devfreq_remove_device(data-devfreq);
return 0;
}
--
1.8.0
--
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/5] ARM: dts: enable display for peach-pit and snow boards
Hi, Tested this whole series on peach-pit board. Tested-by : Arun Kumar K arun...@samsung.com On Sun, Apr 20, 2014 at 5:18 PM, Rahul Sharma rahul.sha...@samsung.com wrote: From: Rahul Sharma rahul.sha...@samsung.com Add nodes for fimd and dp controller for exynos5250 based snow and exynos5420 based peach-pit board. This series is based on Kukjin Kims, for-next branch. It is dependent on 1) Andrew Bresticker's patch for hpd gpio addition, avilable at http://www.spinics.net/lists/linux-samsung-soc/msg28827.html 2) Arun's patch for adding peach-pit board dts file at http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28846.html. Rahul Sharma (5): ARM: dts: move dp hpd line to the board file for exynos5420 ARM: dts: enable fimd for exynos5250 based snow board ARM: dts: enable dp-controller for exynos5250 based snow board ARM: dts: enable fimd for exynos5420 based peach-pit board ARM: dts: enable dp-controller for exynos5420 based peach-pit board arch/arm/boot/dts/exynos5250-snow.dts | 32 +++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 39 arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 - arch/arm/boot/dts/exynos5420-smdk5420.dts |7 + 4 files changed, 78 insertions(+), 7 deletions(-) -- 1.7.9.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 -- 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 1/5] iio: exynos_adc: use indio_dev-dev structure to handle child nodes
From: Naveen Krishna Ch ch.nav...@samsung.com
Using pdev-dev with device_for_each_child() would iterate over all
of the children of the platform device and delete them.
Thus, causing crashes during module unload.
We should be using the indio_dev-dev structure for
registering/unregistering child nodes.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
---
This change was tested on top of
https://lkml.org/lkml/2014/4/21/481 from Doug.
drivers/iio/adc/exynos_adc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..affa93f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -344,7 +344,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
exynos_adc_hw_init(info);
- ret = of_platform_populate(np, exynos_adc_match, NULL, pdev-dev);
+ ret = of_platform_populate(np, exynos_adc_match, NULL, indio_dev-dev);
if (ret 0) {
dev_err(pdev-dev, failed adding child nodes\n);
goto err_of_populate;
@@ -353,7 +353,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
@@ -369,7 +369,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
--
1.7.9.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
[PATCH 5/5] iio: exynos_adc: do a reinit_completion before the conversion
Add reinit_completion() before the wait_for_completion_timeout in
raw_read() call.
Change-Id: I70fa00841bc49eba838a5bd6779015844297dfdb
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/iio/adc/exynos_adc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 805c9f6..32290e6 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -151,6 +151,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
mutex_lock(indio_dev-mlock);
+ reinit_completion(info-completion);
/* Select the channel to be used and Trigger conversion */
if (info-version == ADC_V2) {
--
1.7.9.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
[PATCH 3/5] iio: exynos_adc: reduce timeout and use wait_for_completion_timeout
ADC module on Exynos5 SoCs runs at 600KSPS. At this conversion rate,
waiting for 1000 msecs is wasteful (incase of h/w failure).
Hence, reduce the time out to 100msecs and use
wait_for_completion_timeout() instead of
wait_for_completion_interruptible_timeout()
Also, handle the return values in exynos_raw_read() call.
Change-Id: Icb8cade162094b2777c9f3c77120635deef5947c
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
This change is a part of the patch reviewd at https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index a2b8b1a..4d2467a 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -82,7 +82,7 @@ enum adc_version {
#define ADC_CON_EN_START (1u 0)
#define ADC_DATX_MASK 0xFFF
-#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
+#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
void __iomem*regs;
@@ -121,6 +121,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
u32 con1, con2;
+ int ret;
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
@@ -145,16 +146,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ADC_V1_CON(info-regs));
}
- timeout = wait_for_completion_interruptible_timeout
+ timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
- *val = info-value;
+ if (timeout == 0) {
+ ret = -ETIMEDOUT;
+ } else {
+ *val = info-value;
+ *val2 = 0;
+ ret = IIO_VAL_INT;
+ }
mutex_unlock(indio_dev-mlock);
- if (timeout == 0)
- return -ETIMEDOUT;
-
- return IIO_VAL_INT;
+ return ret;
}
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
--
1.7.9.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
[PATCH 2/5] iio: exynos_adc: rearrange clock and regulator enable/disable calls
From: Naveen Krishna Ch ch.nav...@samsung.com This patch maintains the following order in probe(), remove(), resume() and suspend() calls regulator enable, clk prepare enable ... clk disable unprepare, regulator disable While at it, 1. enable the regulator before the iio_device_register() 2. handle the return values for enable/disable calls Change-Id: I764d9d60f72caa7ea6b0609db49a74115574f081 Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com --- This change fixes the comments given by Jonathan regarding the order of clock and regulator enable/disable calls. https://lkml.org/lkml/2014/4/23/644 drivers/iio/adc/exynos_adc.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index affa93f..a2b8b1a 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -316,6 +316,14 @@ static int exynos_adc_probe(struct platform_device *pdev) goto err_irq; } + ret = regulator_enable(info-vdd); + if (ret) + goto err_irq; + + ret = clk_prepare_enable(info-clk); + if (ret) + goto err_disable_reg; + info-version = exynos_adc_get_version(pdev); platform_set_drvdata(pdev, indio_dev); @@ -334,13 +342,7 @@ static int exynos_adc_probe(struct platform_device *pdev) ret = iio_device_register(indio_dev); if (ret) - goto err_irq; - - ret = regulator_enable(info-vdd); - if (ret) - goto err_iio_dev; - - clk_prepare_enable(info-clk); + goto err_disable_clk; exynos_adc_hw_init(info); @@ -355,10 +357,11 @@ static int exynos_adc_probe(struct platform_device *pdev) err_of_populate: device_for_each_child(indio_dev-dev, NULL, exynos_adc_remove_devices); - regulator_disable(info-vdd); - clk_disable_unprepare(info-clk); -err_iio_dev: iio_device_unregister(indio_dev); +err_disable_clk: + clk_disable_unprepare(info-clk); +err_disable_reg: + regulator_disable(info-vdd); err_irq: free_irq(info-irq, info); return ret; @@ -371,9 +374,10 @@ static int exynos_adc_remove(struct platform_device *pdev) device_for_each_child(indio_dev-dev, NULL, exynos_adc_remove_devices); - regulator_disable(info-vdd); clk_disable_unprepare(info-clk); + regulator_disable(info-vdd); writel(0, info-enable_reg); + iio_device_unregister(indio_dev); free_irq(info-irq, info); @@ -398,8 +402,8 @@ static int exynos_adc_suspend(struct device *dev) } clk_disable_unprepare(info-clk); - writel(0, info-enable_reg); regulator_disable(info-vdd); + writel(0, info-enable_reg); return 0; } @@ -410,12 +414,14 @@ static int exynos_adc_resume(struct device *dev) struct exynos_adc *info = iio_priv(indio_dev); int ret; + writel(1, info-enable_reg); ret = regulator_enable(info-vdd); if (ret) return ret; - writel(1, info-enable_reg); - clk_prepare_enable(info-clk); + ret = clk_prepare_enable(info-clk); + if (ret) + return ret; exynos_adc_hw_init(info); -- 1.7.9.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 0/8] i.MX6 PCIe binding change and MSI support
Am Donnerstag, den 24.04.2014, 11:58 -0600 schrieb Bjorn Helgaas: On Fri, Mar 28, 2014 at 05:52:51PM +0100, Lucas Stach wrote: While working on MSI support for the i.MX6 PCIe host driver it has been discovered that the binding for this host controller is broken in many ways (refer to the patch descriptions for more info) and was introduced without proper discussion about what should/should not be in the binding. This series fixes this and minimizes the difference of the i.MX6 binding to the common designware PCIe binding. I'm aware that this is a quite radical change, but I think it's justified to do this as long as there aren't many user of the old binding (most of the optional properties in the binding aren't even implemented). Looking forward to your feedback. Lucas Stach (8): ARM: imx6q-clk: parent lvds_gate from lvds_sel This one is already applied. PCI: designware: split Exynos and i.MX bindings ARM: dts: imx6: update pcie to bring in line with new binding PCI: imx6: use new clock names PCI: imx6: drop old irq mapping PCI: imx6: rip out optional (and unused) irqs PCI: designware: make MSI isr shared irq aware PCI: imx6: add support for MSI What's the status of all these? I would normally apply patches 4-8 of this series through my tree, given the appropriate acks, but I haven't seen those yet. And I'm not sure what dependencies there are between the non-PCI patches and the PCI ones. It's a complete binding change, so applying one part without the other is going to horribly break things. So I would at least want to see an ack for the binding change on the i.MX side from Shawn and Richard. This will need some follow on patches, as some boards adding PCIe using the old binding have cropped up in linux-next, but I can do the patches on short notice if everyone agrees to merge this patchset. The designware part is pretty simple and doesn't change anything for other users than i.MX. Though I would like to see an ack from Jingoo for those. I have some more stuff in the pipes regarding multiple MSI irqs, that depend on this series and also the Keystone people are waiting for this to be applied in order to consolidate the clock handling of the designware core driver, so it would be nice to get this moving again. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 4/5] iio: exynos_adc: do a soft reset in case of timeout
Do a soft reset software if a timeout happens.
This is applicable only for ADC_V2.
Change-Id: I939eaa06254e0b246dd636df9470f2eb392c2be1
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 4d2467a..805c9f6 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -112,6 +112,30 @@ 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;
+
+ 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_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
@@ -149,6 +173,8 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+ exynos_adc_hw_init(info);
ret = -ETIMEDOUT;
} else {
*val = info-value;
@@ -230,30 +256,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.9.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
[PATCH 0/5] iio: exynos_adc: fix minor nits in the driver
This patchset fixes the 1. bug causing a crash during module removal for exynos_adc.ko. - The bug was seen by Doug, while trying to compile the whole IIO subsystem as module @ https://lkml.org/lkml/2014/4/21/481 from Doug. 2. rearrange the clock and regulator enable/disable calls during probe, remove, suspend and resume calls - Comments give by Jonathan @ https://lkml.org/lkml/2014/4/23/644 3. reduces the timeout and uses wait_for_completion_timeout instead of the interruptible varient. - This change was under review @ https://lkml.org/lkml/2013/11/5/92 Final comments were given by Tomasz, to split and submit. Naveen Krishna Ch (2): iio: exynos_adc: use indio_dev-dev structure to handle child nodes iio: exynos_adc: rearrange clk and regulator enable/disable calls Naveen Krishna Chatradhi (3): iio: exynos_adc: reduce timeout and use wait_for_completion_timeout iio: exynos_adc: do a soft reset in case of timeout iio: exynos_adc: do a reinit_completion before the conversion drivers/iio/adc/exynos_adc.c | 109 +++--- 1 file changed, 61 insertions(+), 48 deletions(-) -- 1.7.9.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
[PATCH v2 1/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Changes from v1:
- Made two separate routines for exynos_ohci_phyg_on() and
exynos_ohci_phyg_off().
- Separated out the phy-get related code from probe() to separate function
exynos_ehci_get_phy().
- Using proper error labels in the code.
.../devicetree/bindings/usb/exynos-usb.txt | 19 +++
drivers/usb/host/ohci-exynos.c | 123 ++--
2 files changed, 132 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..03b7e43 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+ One phy per port. Each port should have its 'reg' entry.
+ - reg: port number on OHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings specifying name of phy
+used by the port.
Example:
usb@1212 {
@@ -47,6 +56,16 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
+
};
DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..eac47cb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -33,12 +34,111 @@ static struct hc_driver __read_mostly
exynos_ohci_hc_driver;
#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)-priv)
+#define PHY_NUMBER 3
struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
+static int exynos_ohci_get_phy(struct platform_device *pdev,
+ struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ohci-phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci-phy)) {
+ ret = PTR_ERR(exynos_ohci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(pdev-dev, Failed to get usb2 phy\n);
+ exynos_ohci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(pdev-dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+ } else {
+ exynos_ohci-otg = exynos_ohci-phy-otg;
+ }
+
+ /* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so that in absence of supporting dts
+* changes the functionality doesn't break.
+* Once we move the ohci dt nodes to use new generic phys,
+* we can remove support for older PHY in this driver.
+*/
+ for_each_available_child_of_node(pdev-dev.of_node, child) {
+ ret = of_property_read_u32(child, reg, phy_number);
+ if (ret) {
+ dev_err(pdev-dev, Failed to parse device tree\n);
+ of_node_put(child);
+ goto fail_phy;
+ }
+ if (phy_number = PHY_NUMBER) {
+ dev_err(pdev-dev, Invalid number of PHYs\n);
+ of_node_put(child);
+ ret = -EINVAL;
+
[PATCH v7 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski k.deb...@samsung.com
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Although the patch-series is named as 'v2' version, but
this patch is named as 'v7' since it is the next version of the patch
sent by Kamil:
[PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy
framework
https://lkml.org/lkml/2014/1/29/298
Changes from v6:
- Added documentation for 'port' property including all its fields -
reg, phys, phy-names.
- Fixed looping in 'exynos_phys_on()' and renamed this function as
exynos_ehci_phyg_on()
- To avoid any regression because of movement from old usb-phy drivers
to new generic phy framework, keeping the changes for old usb-phy driver
intact, and just added support for phy provider from generic phy framework.
- Separated out the phy-get related code from probe() to separate function
exynos_ehci_get_phy().
.../devicetree/bindings/usb/exynos-usb.txt | 18 +++
drivers/usb/host/ehci-exynos.c | 123 ++--
2 files changed, 131 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 03b7e43..4f368b0 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+ One phy per port. Each port should have its 'reg' entry.
+ - reg: port number on EHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings; specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
};
OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..fe0509b 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
@@ -42,14 +43,78 @@
static const char hcd_name[] = ehci-exynos;
static struct hc_driver __read_mostly exynos_ehci_hc_driver;
+#define PHY_NUMBER 3
struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
+static int exynos_ehci_get_phy(struct platform_device *pdev,
+ struct exynos_ehci_hcd *exynos_ehci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ehci-phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ehci-phy)) {
+ ret = PTR_ERR(exynos_ehci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(pdev-dev, Failed to get usb2 phy\n);
+ exynos_ehci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(pdev-dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+ } else {
+ exynos_ehci-otg = exynos_ehci-phy-otg;
[PATCH 0/2] usb: ehci/ohci-exynos: Move to generic phy framework
Added required support for getting phy-provider from generic phy framework Based and tested on 'usb-next' branch of Greg's usb tree, with relevant device tree patches (which i will sending soon). Patch: usb: ehci-exynos: Change to use phy provided by the generic phy framework is the patch from Kamil's usb phy patch-series: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework This is reworked for addressing review comments received in mailing list. Patch: usb: ohci-exynos: Add facility to use phy provided by the generic phy framework is also reworked for addressing review comments. Corresponding changelog for patches mentioned in each patch. Kamil Debski (1): usb: ehci-exynos: Change to use phy provided by the generic phy framework Vivek Gautam (1): usb: ohci-exynos: Add facility to use phy provided by the generic phy framework .../devicetree/bindings/usb/exynos-usb.txt | 37 ++ drivers/usb/host/ehci-exynos.c | 123 ++-- drivers/usb/host/ohci-exynos.c | 123 ++-- 3 files changed, 263 insertions(+), 20 deletions(-) -- 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
[PATCH v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski k.deb...@samsung.com
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v7:
just edited in the commit message: s/ohci/ehci
Although the patch-series is named as 'v2' version, but
this patch is named as 'v7' since it is the next version of the patch
sent by Kamil:
[PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy
framework
https://lkml.org/lkml/2014/1/29/298
Changes from v6:
- Added documentation for 'port' property including all its fields -
reg, phys, phy-names.
- Fixed looping in 'exynos_phys_on()' and renamed this function as
exynos_ehci_phyg_on()
- To avoid any regression because of movement from old usb-phy drivers
to new generic phy framework, keeping the changes for old usb-phy driver
intact, and just added support for phy provider from generic phy framework.
- Separated out the phy-get related code from probe() to separate function
exynos_ehci_get_phy().
.../devicetree/bindings/usb/exynos-usb.txt | 18 +++
drivers/usb/host/ehci-exynos.c | 123 ++--
2 files changed, 131 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 03b7e43..4f368b0 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+ One phy per port. Each port should have its 'reg' entry.
+ - reg: port number on EHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings; specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
};
OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..fe0509b 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
@@ -42,14 +43,78 @@
static const char hcd_name[] = ehci-exynos;
static struct hc_driver __read_mostly exynos_ehci_hc_driver;
+#define PHY_NUMBER 3
struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
+static int exynos_ehci_get_phy(struct platform_device *pdev,
+ struct exynos_ehci_hcd *exynos_ehci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ehci-phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ehci-phy)) {
+ ret = PTR_ERR(exynos_ehci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(pdev-dev, Failed to get usb2 phy\n);
+ exynos_ehci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(pdev-dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+
[PATCH v7 0/2] dts: Add usb2phy to Exynos 5250
Next version of patch for Kamil's patch: [PATCH v6 4/8] dts: Add usb2phy to Exynos 5250 https://lkml.org/lkml/2014/1/29/302 Based on 'for-next' branch of Kgene's linux-samsung tree. Tested with driver side patches: [PATCH 0/2] usb: ehci/ohci-exynos: Move to generic phy framework https://www.mail-archive.com/linux-usb@vger.kernel.org/msg41246.html Changes from v6: - Splitted the patch into two: adding syscon nodes to Exynos5250 and Exynos5420 in first; and phy entry change in the second. - Changed the name of phandle for usb2phy from 'usb2_phy_new' to 'usb2_phy_gen' indicating generic phy. - Using clock macros in dt entries. Kamil Debski (1): ARM: dts: Add usb2phy to Exynos 5250 Vivek Gautam (1): ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420 arch/arm/boot/dts/exynos5250.dtsi | 31 +++ arch/arm/boot/dts/exynos5420.dtsi |5 + 2 files changed, 36 insertions(+) -- 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
[PATCH v7 2/2] ARM: dts: Add usb2phy to Exynos 5250
From: Kamil Debski k.deb...@samsung.com
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 70f0cd5..51e554c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -563,6 +563,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
};
usb@1212 {
@@ -572,6 +580,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
};
usb2_phy: usbphy@1213 {
@@ -589,6 +605,16 @@
};
};
+ usb2_phy_gen: phy@1213 {
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USB2, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
+
pwm: pwm@12dd {
compatible = samsung,exynos4210-pwm;
reg = 0x12dd 0x100;
--
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
[PATCH v7 1/2] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..70f0cd5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -175,6 +175,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5250-sys, syscon;
+ reg = 0x1005 0x5000;
+ };
+
watchdog@101D {
compatible = samsung,exynos5250-wdt;
reg = 0x101D 0x100;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..cfa3755 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -675,6 +675,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5420-sys, syscon;
+ reg = 0x1005 0x5000;
+ };
+
tmu_cpu0: tmu@1006 {
compatible = samsung,exynos5420-tmu;
reg = 0x1006 0x100;
--
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
[PATCH v2 0/5] Add PMU node for Exynos SoCs
This patch series adds new property in samsung PMU binding as samsung,syscon-phandle to get PMU regmap handle in PMU driver implementation and mach-exynos/exynos.c. This patch also updates Exynos4210, Exynos4412 and Exynos4212 dtsi files for adding PMU (Power Management Unit) reg node. Updated binding document for the same. These patches are required for converting PMU implementation free from static mapping of PMU registers as well as it's dependency from machine header files, thus allowing us to converting it into DT based. Changes since v1: - Added new property samsung,syscon-phandle to get access to PMU regmap handle. - Updated Exynos5250, Exynos5420, Exynos4210/4412/4212 dtsi files. - Rebased on Kukjin Kim's for-next branch. Pankaj Dubey (5): ARM: dts: Add syscon handle in pmu node for exynos5250 ARM: dts: Add PMU node to exynos4210 ARM: dts: Add PMU node to exynos4212 and exynos4412 arm: dts: Add syscon handle in pmu node for exynos5420 Documentation: update samsung pmu binding information Documentation/devicetree/bindings/arm/samsung/pmu.txt |7 +++ arch/arm/boot/dts/exynos4210.dtsi |6 ++ arch/arm/boot/dts/exynos4212.dtsi |6 ++ arch/arm/boot/dts/exynos4412.dtsi |6 ++ arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/boot/dts/exynos5420.dtsi |1 + 6 files changed, 27 insertions(+) -- 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
[PATCH v2 3/5] ARM: dts: Add PMU node to exynos4212 and exynos4412
This patch adds pmu regnode to exynos4212 and exynos4412 dtsi to
handle PMU register access via DT.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos4212.dtsi |6 ++
arch/arm/boot/dts/exynos4412.dtsi |6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3c00e6e..b1d4768 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -29,4 +29,10 @@
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
+
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4212-pmu, syscon;
+ reg = 0x1002 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 15d3c0a..6152e70 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -29,4 +29,10 @@
gic: interrupt-controller@1049 {
cpu-offset = 0x4000;
};
+
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4412-pmu, syscon;
+ reg = 0x1002 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
+ };
};
--
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
[PATCH v2 1/5] ARM: dts: Add syscon handle in pmu node for exynos5250
Add samsung,syscon-phandle property pointing to PMU node
to access PMU register via PMU regmap handle.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..52801af 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -173,6 +173,7 @@
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5250-pmu, syscon;
reg = 0x1004 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
};
watchdog@101D {
--
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
[PATCH v2 5/5] Documentation: update samsung pmu binding information
This patch updates samsung pmu (power management unit) binding information.
CC: Leela Krishna Amudala l.kris...@samsung.com
CC: Guenter Roeck li...@roeck-us.net
CC: Rob Landley r...@landley.net
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt |7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f1552..ac9b45c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,14 +2,21 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+ - samsung,exynos4210-pmu - for Exynos4210 SoC,
+ - samsung,exynos4212-pmu - for Exynos4212 SoC,
+ - samsung,exynos4412-pmu - for Exynos4412 SoC,
- samsung,exynos5250-pmu - for Exynos5250 SoC,
- samsung,exynos5420-pmu - for Exynos5420 SoC.
second value must be always syscon.
- reg : offset and length of the register set.
+ - samsung,syscon-phandle : reference to syscon node. This property points to
syscon node
+ holding the PMU base address.
+
Example :
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5250-pmu, syscon;
reg = 0x1004 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
};
--
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
[PATCH v2 2/5] ARM: dts: Add PMU node to exynos4210
This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..042b6d9 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,12 @@
interrupts = 2 2, 3 2;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu, syscon;
+ reg = 0x1002 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
--
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
[PATCH v2 4/5] arm: dts: Add syscon handle in pmu node for exynos5420
Add samsung,syscon-phandle property pointing to PMU node
to access PMU register via PMU regmap handle.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..c6e449d 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -673,6 +673,7 @@
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5420-pmu, syscon;
reg = 0x1004 0x5000;
+ samsung,syscon-phandle = pmu_system_controller;
};
tmu_cpu0: tmu@1006 {
--
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
[PATCH v2 02/10] ARM: EXYNOS: Cleanup mach-exynos/common.h file
Remove unused and unwanted declarations from mach-exynos/common.h Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/common.h |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 9ef3f83..31c5964 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -15,14 +15,8 @@ #include linux/reboot.h #include linux/of.h -void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1); - -struct map_desc; -void exynos_init_io(void); -void exynos_restart(enum reboot_mode mode, const char *cmd); void exynos_cpuidle_init(void); void exynos_cpufreq_init(void); -void exynos_init_late(void); void exynos_firmware_init(void); -- 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
[PATCH v2 09/10] ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c
As we have removed static mappings from regs-pmu.h it does not need map.h anymore. But platsmp.c needed this and till now it got included indirectly. So lets move header inclusion of mach/map.h from regs-pmu.h to platsmp.c. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/platsmp.c |1 + arch/arm/mach-exynos/regs-pmu.h |2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 9ce4c9f9..3831e6c 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -26,6 +26,7 @@ #include asm/firmware.h #include plat/cpu.h +#include mach/map.h #include common.h #include regs-pmu.h diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index 7f3bf65..bb57b62 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -12,8 +12,6 @@ #ifndef __ASM_ARCH_REGS_PMU_H #define __ASM_ARCH_REGS_PMU_H __FILE__ -#include mach/map.h - #define S5P_CENTRAL_SEQ_CONFIGURATION 0x0200 #define S5P_CENTRAL_LOWPWR_CFG (1 16) -- 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
[PATCH v2 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Samsung Power Management Unit (PMU) base address
from device tree. Code will use existing samsung pmu binding information.
This patch also adds two helper functions as get_exynos_pmuregmap and
get_exynos_pmuaddr.
get_exynos_pmuregmap returns a regmap based PMU register handle where as
get_exynos_pmuaddr returns ioremap virtual address.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/Kconfig |2 ++
arch/arm/mach-exynos/common.h |3 ++
arch/arm/mach-exynos/exynos.c | 78 +
3 files changed, 83 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..2f60c90 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -26,6 +26,7 @@ config ARCH_EXYNOS4
select PINCTRL
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
+ select MFD_SYSCON
help
Samsung EXYNOS4 SoCs based systems
@@ -36,6 +37,7 @@ config ARCH_EXYNOS5
select HAVE_ARM_SCU if SMP
select HAVE_SMP
select PINCTRL
+ select MFD_SYSCON
help
Samsung EXYNOS5 (Cortex-A15) SoC based systems
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 31c5964..ecfd0fc 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -57,4 +57,7 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern struct regmap *get_exynos_pmuregmap(void);
+extern void __iomem *get_exynos_pmuaddr(void);
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index d6f405f..68f60e1 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,7 @@
#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_domain.h
+#include linux/mfd/syscon.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -36,6 +37,9 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static struct regmap *exynos_pmu_regmap;
+static void __iomem *exynos_pmu_base;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -269,6 +273,46 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = samsung,exynos4210-pmu },
+ { .compatible = samsung,exynos4212-pmu },
+ { .compatible = samsung,exynos4412-pmu },
+ { .compatible = samsung,exynos5250-pmu },
+ {},
+};
+
+static int __init exynos_fdt_map_pmu(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+ phys_addr_t phys_addr;
+ const struct of_device_id *matches = exynos_dt_pmu_match;
+
+ for (; matches-compatible[0]; matches++) {
+ if (!of_flat_dt_is_compatible(node, matches-compatible))
+ continue;
+ reg = of_get_flat_dt_prop(node, reg, len);
+ if (reg == NULL || len != (sizeof(unsigned long) * 2))
+ return 0;
+
+ phys_addr = be32_to_cpu(reg[0]);
+ iodesc.pfn = __phys_to_pfn(phys_addr);
+ iodesc.length = be32_to_cpu(reg[1]) - 1;
+ iodesc.virtual = (unsigned long)S5P_VA_PMU;
+ iodesc.type = MT_DEVICE;
+ iotable_init(iodesc, 1);
+
+ exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
+ if (WARN_ON(!exynos_pmu_base))
+ return -EFAULT;
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* exynos_map_io
*
@@ -302,6 +346,7 @@ static void __init exynos_init_io(void)
debug_ll_io_init();
of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+ of_scan_flat_dt(exynos_fdt_map_pmu, NULL);
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
@@ -336,6 +381,38 @@ static int __init exynos4_l2x0_cache_init(void)
}
early_initcall(exynos4_l2x0_cache_init);
+
+inline struct regmap *get_exynos_pmuregmap()
+{
+ return exynos_pmu_regmap;
+}
+
+inline void __iomem *get_exynos_pmuaddr()
+{
+ return exynos_pmu_base;
+}
+
+
+void __init exynos_map_pmu(void)
+{
+ struct device_node *np = NULL;
+
+ early_syscon_init();
+
+ np = of_find_matching_node(NULL, exynos_dt_pmu_match);
+
+ if (!np) {
+ pr_err(Failed to find PMU node\n);
+ return;
+ } else {
+ exynos_pmu_regmap = syscon_early_regmap_lookup_by_phandle(np,
+
[PATCH v2 07/10] ARM: EXYNOS: Remove linux/bug.h from pmu.c
From: Young-Gun Jang yg1004.j...@samsung.com This patch removes unnecessary header file inclusion from pmu.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com --- arch/arm/mach-exynos/pmu.c |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c index 05c7ce1..4c3453a 100644 --- a/arch/arm/mach-exynos/pmu.c +++ b/arch/arm/mach-exynos/pmu.c @@ -11,7 +11,6 @@ #include linux/io.h #include linux/kernel.h -#include linux/bug.h #include plat/cpu.h -- 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
[PATCH v2 08/10] ARM: EXYNOS: Refactored code for using PMU address via DT
Under arm/mach-exynos many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc.
Let's convert all these access using either of get_exynos_pmuaddr
or get_exynos_regmap.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to driver
folder which can be reused for ARM64 bsed SoC.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h |4 +-
arch/arm/mach-exynos/cpuidle.c | 37 ++-
arch/arm/mach-exynos/exynos.c | 19 +-
arch/arm/mach-exynos/hotplug.c |4 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/platsmp.c | 13 +-
arch/arm/mach-exynos/pm.c | 60 ++--
arch/arm/mach-exynos/pmu.c | 40 +--
arch/arm/mach-exynos/regs-pmu.h | 506 +++
9 files changed, 348 insertions(+), 338 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ecfd0fc..ad5128e 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -40,7 +40,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END 0x
enum sys_powerdown {
SYS_AFTR,
@@ -51,7 +51,7 @@ enum sys_powerdown {
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c57cae0..5dcdd46 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/time.h
#include linux/platform_device.h
+#include linux/regmap.h
#include asm/proc-fns.h
#include asm/smp_scu.h
@@ -34,10 +35,10 @@
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
- (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+ 0x24 : S5P_INFORM0))
#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
- (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+ 0x20 : S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
@@ -60,6 +61,8 @@
#define PWR_CTRL2_CORE2_UP_RATIO (1 4)
#define PWR_CTRL2_CORE1_UP_RATIO (1 0)
+static struct regmap *pmu_regmap;
+
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
@@ -87,7 +90,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos4_set_wakeupmask(void)
{
- __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+ regmap_write(pmu_regmap, S5P_WAKEUP_MASK, 0xff3e);
}
static unsigned int g_pwr_ctrl, g_diag_reg;
@@ -120,22 +123,28 @@ static int exynos4_enter_core0_aftr(struct cpuidle_device
*dev,
struct cpuidle_driver *drv,
int index)
{
- unsigned long tmp;
+ unsigned int tmp;
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
exynos_sys_powerdown_conf(SYS_AFTR);
-
- __raw_writel(virt_to_phys(exynos_cpu_resume), REG_DIRECTGO_ADDR);
- __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
-
+
+ if (samsung_rev() == EXYNOS4210_REV_1_0) {
+ __raw_writel(virt_to_phys(exynos_cpu_resume),
+ S5P_VA_SYSRAM + REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, S5P_VA_SYSRAM + REG_DIRECTGO_FLAG);
+ } else {
+ regmap_write(pmu_regmap, REG_DIRECTGO_ADDR,
+ virt_to_phys(exynos_cpu_resume));
+ regmap_write(pmu_regmap, REG_DIRECTGO_FLAG, S5P_CHECK_AFTR);
+ }
save_cpu_arch_register();
/* Setting Central Sequence Register for power down mode */
- tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ regmap_read(pmu_regmap, S5P_CENTRAL_SEQ_CONFIGURATION, tmp);
tmp = ~S5P_CENTRAL_LOWPWR_CFG;
- __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+ regmap_write(pmu_regmap, S5P_CENTRAL_SEQ_CONFIGURATION, tmp);
cpu_pm_enter();
cpu_suspend(0, idle_finisher);
@@ -154,14 +163,14 @@ static int exynos4_enter_core0_aftr(struct cpuidle_device
*dev,
* S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
[PATCH v2 05/10] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
From: Young-Gun Jang yg1004.j...@samsung.com Current pm_domain.c file uses S5P_INT_LOCAL_PWR_EN definition from regs-pmu.h and hence needs to include this header file. As there is no other user of S5P_INT_LOCAL_PWR_EN definition other than pm_domain, to remove regs-pmu.h header file dependency from pm_domain.c it's better we define this definition in pm_domain.c file itself and thus it will help in removing header file inclusion from pm_domain.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com --- arch/arm/mach-exynos/pm_domains.c |2 +- arch/arm/mach-exynos/regs-pmu.h |1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index fe6570e..f676b0a 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -22,7 +22,7 @@ #include linux/of_platform.h #include linux/sched.h -#include regs-pmu.h +#define S5P_INT_LOCAL_PWR_EN 0x7 /* * Exynos specific wrapper around the generic power domain diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index 4ee706d..bfebe84 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -116,7 +116,6 @@ #define S5P_PAD_RET_EBIB_OPTIONS5P_PMUREG(0x31A8) #define S5P_CORE_LOCAL_PWR_EN 0x3 -#define S5P_INT_LOCAL_PWR_EN 0x7 #define S5P_CHECK_SLEEP0x0BAD -- 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
[PATCH v2 03/10] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file.
From: Young-Gun Jang yg1004.j...@samsung.com While making PMU implementation to be device tree based, there are few register offsets related with SYSREG present in regs-pmu.h, so let's make a new header file regs-sys.h to keep all such SYSREG related register offsets and remove them from regs-pmu.h Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/exynos.c |1 + arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/regs-pmu.h |3 --- arch/arm/mach-exynos/regs-sys.h | 22 ++ 4 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-exynos/regs-sys.h diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 2388ee4..d6f405f 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -31,6 +31,7 @@ #include common.h #include mfc.h #include regs-pmu.h +#include regs-sys.h #define L2_AUX_VAL 0x7C470001 #define L2_AUX_MASK 0xC200 diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index 15af0ce..723c988 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -35,6 +35,7 @@ #include common.h #include regs-pmu.h +#include regs-sys.h /** * struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index 4f6a256..4ee706d 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -15,7 +15,6 @@ #include mach/map.h #define S5P_PMUREG(x) (S5P_VA_PMU + (x)) -#define S5P_SYSREG(x) (S3C_VA_SYS + (x)) #define S5P_CENTRAL_SEQ_CONFIGURATION S5P_PMUREG(0x0200) @@ -180,8 +179,6 @@ /* For EXYNOS5 */ -#define EXYNOS5_SYS_I2C_CFG S5P_SYSREG(0x0234) - #define EXYNOS5_AUTO_WDTRESET_DISABLE S5P_PMUREG(0x0408) #define EXYNOS5_MASK_WDTRESET_REQUEST S5P_PMUREG(0x040C) diff --git a/arch/arm/mach-exynos/regs-sys.h b/arch/arm/mach-exynos/regs-sys.h new file mode 100644 index 000..84332b0 --- /dev/null +++ b/arch/arm/mach-exynos/regs-sys.h @@ -0,0 +1,22 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * EXYNOS - system register definition + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#ifndef __ASM_ARCH_REGS_SYS_H +#define __ASM_ARCH_REGS_SYS_H __FILE__ + +#include mach/map.h + +#define S5P_SYSREG(x) (S3C_VA_SYS + (x)) + +/* For EXYNOS5 */ +#define EXYNOS5_SYS_I2C_CFGS5P_SYSREG(0x0234) + +#endif /* __ASM_ARCH_REGS_SYS_H */ -- 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
[PATCH v2 10/10] ARM: EXYNOS: Add device tree based initialization support for PMU.
This patch adds device tree based initialization for PMU and modifies
PMU initialization implementation in following way:
1: Let's initialize PMU based on device tree compatibility string.
2: Obtain PMU regmap handle using syscon_early_regmap_lookup_by_phandle
so that we can reduce dependency over machine header files.
3: Separate each SoC's PMU initialization function and bind this initialization
function with PMU compatibility string.
4 : It also removes uses of soc_is_exynos() thus making PMU implementation
independent of plat/cpu.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
---
arch/arm/mach-exynos/pmu.c | 182 +---
1 file changed, 138 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..abcf753 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -9,17 +9,31 @@
* published by the Free Software Foundation.
*/
-#include linux/io.h
#include linux/kernel.h
#include linux/regmap.h
-
-#include plat/cpu.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
+enum exynos_pmu_id {
+ PMU_EXYNOS4210,
+ PMU_EXYNOS4X12,
+ PMU_EXYNOS4412,
+ PMU_EXYNOS5250,
+};
+
+struct exynos_pmu_data {
+ enum exynos_pmu_id pmu_id;
+ struct regmap *pmu_regmap;
+};
+
+struct exynos_pmu_data *pmu_data;
static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+typedef void (*exynos_pmu_init_t)(void);
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .reg = address, .val = { AFTR, LPA, SLEEP } */
@@ -348,28 +362,31 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
- tmp = regmap_read(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
- tmp);
+ tmp = regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
tmp = ~(EXYNOS5_OPTION_USE_STANDBYWFE |
EXYNOS5_OPTION_USE_STANDBYWFI);
- regmap_write(pmu_regmap, exynos5_list_diable_wfi_wfe[i], tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
}
}
@@ -377,52 +394,129 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
+ if (pmu_data-pmu_id == PMU_EXYNOS5250)
exynos5_init_pmu();
for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- regmap_write(pmu_regmap, exynos_pmu_config[i].offset,
+ regmap_write(pmu_data-pmu_regmap, exynos_pmu_config[i].offset,
exynos_pmu_config[i].val[mode]);
- if (soc_is_exynos4412()) {
+ if (pmu_data-pmu_id == PMU_EXYNOS4412) {
for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END;
i++)
- regmap_write(pmu_regmap,
exynos4412_pmu_config[i].offset,
+ regmap_write(pmu_data-pmu_regmap,
+ exynos4412_pmu_config[i].offset,
exynos4412_pmu_config[i].val[mode]);
}
}
-static int __init exynos_pmu_init(void)
+static void exynos4210_pmu_init(void)
{
- unsigned int value;
-
exynos_pmu_config = exynos4210_pmu_config;
- pmu_regmap = get_exynos_pmuregmap();
-
- if (soc_is_exynos4210()) {
- exynos_pmu_config = exynos4210_pmu_config;
- pr_info(EXYNOS4210 PMU Initialize\n);
- }
[PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT
This patch series, does some minor cleanup and modifies Exynos PMU related code for mapping and initialization of Exynos Power Management Unit (PMU) base address from device tree. This is also preparation for moving PMU related code out of machine folder and moving into a drivers/mfd, so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos4210, Exynos4212 and Exynos4412 dtsi files, which has been posted as separate patch series [2] These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch. These patches depends on following two patch series: 1) mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 2) Add PMU node for Exynos SoCs http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html We have tested these patches on SMDK5250 and Arndale (Exynos5250) boards for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey pankaj.du...@samsung.com Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: Make exynos machine_ops as static. For making more cleanup in mach-exynos/common.h as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning mach-exynos/common.h. - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under mach-exynos. Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of exynos_pmu_base, as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that early_syscon_init requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as smp_secondary_init will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove linux/bug.h from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to drivers/mfd folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as samsung, exynosxxx-pmu, syscon, once we enable MFD_SYSCON config option, current syscon driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using syscon_early_regmap_lookup_by_phandle. If there is any better solution please suggest. Pankaj Dubey (6): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Cleanup mach-exynos/common.h file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c ARM: EXYNOS: Add device tree based initialization support for PMU. Young-Gun Jang (4): ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Remove linux/bug.h from pmu.c arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/common.h | 13 +- arch/arm/mach-exynos/cpuidle.c | 37 +- arch/arm/mach-exynos/exynos.c | 104 +- arch/arm/mach-exynos/headsmp.S |2 - arch/arm/mach-exynos/hotplug.c |7 +- arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exynos/include/mach/memory.h |3 +- arch/arm/mach-exynos/platsmp.c | 17 +- arch/arm/mach-exynos/pm.c | 61 ++-- arch/arm/mach-exynos/pm_domains.c |2 +- arch/arm/mach-exynos/pmu.c | 191 --- arch/arm/mach-exynos/regs-pmu.h| 512 ++-- arch/arm/mach-exynos/regs-sys.h| 22 ++
[PATCH v2 01/10] ARM: EXYNOS: Make exynos machine_ops as static
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..2388ee4 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -235,7 +235,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -296,7 +296,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
--
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: [PATCH v4 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
Hi Stratos,
Thanks for the patch.
On Tue, Apr 22, 2014 at 4:30 AM, Stratos Karafotis
strat...@semaphore.gr wrote:
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
This patch produces following build warning,
drivers/cpufreq/freq_table.c: In function 'cpufreq_frequency_table_cpuinfo':
drivers/cpufreq/freq_table.c:36:3: warning: format '%lu' expects
argument of type 'long unsigned int', but argument 2 has type 'int'
[-Wformat=]
pr_debug(table entry %lu: %u kHz\n, pos - table, freq);
Thanks,
--Prabhakar Lad
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
drivers/cpufreq/acpi-cpufreq.c | 9 +++---
drivers/cpufreq/arm_big_little.c | 16 +--
drivers/cpufreq/cpufreq_stats.c | 24 ++--
drivers/cpufreq/dbx500-cpufreq.c | 8 ++
drivers/cpufreq/elanfreq.c | 9 +++---
drivers/cpufreq/exynos-cpufreq.c | 11 ---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +--
drivers/cpufreq/freq_table.c | 56
drivers/cpufreq/longhaul.c | 13 -
drivers/cpufreq/pasemi-cpufreq.c | 10 +++
drivers/cpufreq/powernow-k6.c| 14 -
drivers/cpufreq/ppc_cbe_cpufreq.c| 9 +++---
drivers/cpufreq/s3c2416-cpufreq.c| 40 +++---
drivers/cpufreq/s3c64xx-cpufreq.c| 15 --
14 files changed, 117 insertions(+), 147 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 000e4e0..b0c18ed 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct
acpi_cpufreq_data *data)
static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
{
- int i;
+ struct cpufreq_frequency_table *pos;
struct acpi_processor_performance *perf;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
@@ -223,10 +223,9 @@ static unsigned extract_msr(u32 msr, struct
acpi_cpufreq_data *data)
perf = data-acpi_data;
- for (i = 0; data-freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
- if (msr ==
perf-states[data-freq_table[i].driver_data].status)
- return data-freq_table[i].frequency;
- }
+ cpufreq_for_each_entry(pos, data-freq_table)
+ if (msr == perf-states[pos-driver_data].status)
+ return pos-frequency;
return data-freq_table[0].frequency;
}
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index bad2ed3..1f4d4e3 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -226,22 +226,22 @@ static inline u32 get_table_count(struct
cpufreq_frequency_table *table)
/* get the minimum frequency in the cpufreq_frequency_table */
static inline u32 get_table_min(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t min_freq = ~0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency min_freq)
- min_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency min_freq)
+ min_freq = pos-frequency;
return min_freq;
}
/* get the maximum frequency in the cpufreq_frequency_table */
static inline u32 get_table_max(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t max_freq = 0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency max_freq)
- max_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency max_freq)
+ max_freq = pos-frequency;
return max_freq;
}
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index ecaaebf..0cd9b4d 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
{
- unsigned int i, j, count = 0, ret = 0;
+ unsigned int i, count = 0, ret = 0;
struct cpufreq_stats *stat;
unsigned int alloc_size;
unsigned int cpu = policy-cpu;
- struct cpufreq_frequency_table *table;
+ struct cpufreq_frequency_table *pos, *table;
table = cpufreq_frequency_get_table(cpu);
if (unlikely(!table))
@@ -205,12 +205,8 @@ static int __cpufreq_stats_create_table(struct
cpufreq_policy *policy)
[RFC PATCH v2 2/3] ARM: EXYNOS: Move pmu specific header files under linux/mfd/samsung
Moving Exynos PMU specific header file into include/linux/mfd/samsung
thus updated affected files under mach-exynos to use new location of
these header files.
CC: Sangbeom Kim sbki...@samsung.com
CC: Samuel Ortiz sa...@linux.intel.com
CC: Lee Jones lee.jo...@linaro.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/cpuidle.c |4 +-
arch/arm/mach-exynos/exynos-pmu.h | 31 ---
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/hotplug.c |2 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c |4 +-
arch/arm/mach-exynos/pmu.c |5 +-
arch/arm/mach-exynos/regs-pmu.h | 308 ---
include/linux/mfd/samsung/exynos-pmu.h | 31 +++
include/linux/mfd/samsung/exynos-regs-pmu.h | 308 +++
10 files changed, 348 insertions(+), 349 deletions(-)
delete mode 100644 arch/arm/mach-exynos/exynos-pmu.h
delete mode 100644 arch/arm/mach-exynos/regs-pmu.h
create mode 100644 include/linux/mfd/samsung/exynos-pmu.h
create mode 100644 include/linux/mfd/samsung/exynos-regs-pmu.h
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index ff3be9c..4c18087 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -18,6 +18,8 @@
#include linux/time.h
#include linux/platform_device.h
#include linux/regmap.h
+#include linux/mfd/samsung/exynos-regs-pmu.h
+#include linux/mfd/samsung/exynos-pmu.h
#include asm/proc-fns.h
#include asm/smp_scu.h
@@ -31,8 +33,6 @@
#include mach/map.h
#include common.h
-#include regs-pmu.h
-#include exynos-pmu.h
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
deleted file mode 100644
index 1cc857b..000
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * Header for EXYNOS PMU Driver support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __EXYNOS_PMU_H
-#define __EXYNOS_PMU_H
-
-#define PMU_TABLE_END 0x
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
-
-#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b01987e..24c774a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -21,6 +21,7 @@
#include linux/pm_domain.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/mfd/samsung/exynos-regs-pmu.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -32,7 +33,6 @@
#include common.h
#include mfc.h
-#include regs-pmu.h
#include regs-sys.h
#define L2_AUX_VAL 0x7C470001
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 7831e64..1d3ad84 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -14,6 +14,7 @@
#include linux/smp.h
#include linux/io.h
#include linux/regmap.h
+#include linux/mfd/samsung/exynos-regs-pmu.h
#include asm/cacheflush.h
#include asm/cp15.h
@@ -22,7 +23,6 @@
#include plat/cpu.h
#include common.h
-#include regs-pmu.h
static inline void cpu_enter_lowpower_a9(void)
{
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 3831e6c..54c0df8 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -19,6 +19,7 @@
#include linux/jiffies.h
#include linux/smp.h
#include linux/io.h
+#include linux/mfd/samsung/exynos-regs-pmu.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -29,7 +30,6 @@
#include mach/map.h
#include common.h
-#include regs-pmu.h
extern void exynos4_secondary_startup(void);
static void __iomem *pmu_base;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 103ab92..3e75565 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -21,6 +21,8 @@
#include linux/err.h
#include linux/clk.h
#include linux/regmap.h
+#include linux/mfd/samsung/exynos-regs-pmu.h
+#include linux/mfd/samsung/exynos-pmu.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -35,9 +37,7 @@
#include mach/map.h
#include common.h
-#include regs-pmu.h
#include regs-sys.h
-#include exynos-pmu.h
static struct regmap *pmu_regmap;
diff --git a/arch/arm/mach-exynos/pmu.c
[RFC PATCH v2 1/3] ARM: EXYNOS: Move PMU specific definitions from common.h
From: Younggun Jang yg1004.j...@samsung.com
This patch moves PMU specific definitions into a new file
as exynos-pmu.h. This will help in making PMU implementation
independent of common.h header.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/cpuidle.c|1 +
arch/arm/mach-exynos/exynos-pmu.h | 31 +++
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c|2 +-
5 files changed, 34 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ad5128e..d848ede 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -38,24 +38,7 @@ extern struct smp_operations exynos_smp_ops;
extern void exynos_cpu_die(unsigned int cpu);
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END 0x
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
extern unsigned long l2x0_regs_phys;
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern struct regmap *get_exynos_pmuregmap(void);
extern void __iomem *get_exynos_pmuaddr(void);
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 5dcdd46..ff3be9c 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -32,6 +32,7 @@
#include common.h
#include regs-pmu.h
+#include exynos-pmu.h
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..1cc857b
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+#define PMU_TABLE_END 0x
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e4c10d4..103ab92 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -37,6 +37,7 @@
#include common.h
#include regs-pmu.h
#include regs-sys.h
+#include exynos-pmu.h
static struct regmap *pmu_regmap;
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index abcf753..d020557 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -16,7 +16,7 @@
#include linux/slab.h
#include linux/mfd/syscon.h
-#include common.h
+#include exynos-pmu.h
#include regs-pmu.h
enum exynos_pmu_id {
--
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
[RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from
arm/mach-exynos to drivers/mfd.
This driver is mainly used for setting misc bits of register from PMU IP
of Exynos SoC which will be required to configure before Suspend/Resume.
Currently all these settings are done in arch/arm/mach-exynos/pmu.c but
moving ahead for ARM64 based SoC support, there is a need of DT based
implementation of PMU driver.
This driver uses already existing DT binding information.
CC: Sangbeom Kim sbki...@samsung.com
CC: Samuel Ortiz sa...@linux.intel.com
CC: Lee Jones lee.jo...@linaro.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/Kconfig |2 +
arch/arm/mach-exynos/Makefile |2 -
arch/arm/mach-exynos/pmu.c| 521 -
drivers/mfd/Kconfig |9 +
drivers/mfd/Makefile |1 +
drivers/mfd/exynos-pmu.c | 521 +
6 files changed, 533 insertions(+), 523 deletions(-)
delete mode 100644 arch/arm/mach-exynos/pmu.c
create mode 100644 drivers/mfd/exynos-pmu.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 2f60c90..79559b4 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,7 @@ config ARCH_EXYNOS4
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select MFD_SYSCON
+ select MFD_EXYNOS_PMU
help
Samsung EXYNOS4 SoCs based systems
@@ -38,6 +39,7 @@ config ARCH_EXYNOS5
select HAVE_SMP
select PINCTRL
select MFD_SYSCON
+ select MFD_EXYNOS_PMU
help
Samsung EXYNOS5 (Cortex-A15) SoC based systems
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index a656dbe..19fdf17 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -18,8 +18,6 @@ obj-$(CONFIG_PM_SLEEP)+= pm.o sleep.o
obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
-obj-$(CONFIG_ARCH_EXYNOS) += pmu.o
-
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
deleted file mode 100644
index a26332f..000
--- a/arch/arm/mach-exynos/pmu.c
+++ /dev/null
@@ -1,521 +0,0 @@
-/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- *
- * EXYNOS - CPU PMU(Power Management Unit) support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/regmap.h
-#include linux/of.h
-#include linux/platform_device.h
-#include linux/slab.h
-#include linux/mfd/syscon.h
-#include linux/mfd/samsung/exynos-regs-pmu.h
-#include linux/mfd/samsung/exynos-pmu.h
-
-enum exynos_pmu_id {
- PMU_EXYNOS4210,
- PMU_EXYNOS4X12,
- PMU_EXYNOS4412,
- PMU_EXYNOS5250,
-};
-
-struct exynos_pmu_data {
- enum exynos_pmu_id pmu_id;
- struct regmap *pmu_regmap;
-};
-
-struct exynos_pmu_data *pmu_data;
-static const struct exynos_pmu_conf *exynos_pmu_config;
-typedef void (*exynos_pmu_init_t)(void);
-
-static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
- /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
- { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
- { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
- { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
- { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
- { S5P_DIS_IRQ_CORE1,{ 0x0, 0x0, 0x0 } },
- { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
- { S5P_ARM_COMMON_LOWPWR,{ 0x0, 0x0, 0x2 } },
- { S5P_L2_0_LOWPWR, { 0x2, 0x2, 0x3 } },
- { S5P_L2_1_LOWPWR, { 0x2, 0x2, 0x3 } },
- { S5P_CMU_ACLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
- { S5P_CMU_SCLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
- { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
- { S5P_APLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
- { S5P_MPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
- { S5P_VPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
- { S5P_EPLL_SYSCLK_LOWPWR, { 0x1, 0x1, 0x0 } },
- { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
- { S5P_CMU_RESET_GPSALIVE_LOWPWR,{ 0x1, 0x1, 0x0 } },
- { S5P_CMU_CLKSTOP_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
- { S5P_CMU_CLKSTOP_TV_LOWPWR,{ 0x1, 0x1, 0x0 } },
- { S5P_CMU_CLKSTOP_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
- { S5P_CMU_CLKSTOP_G3D_LOWPWR,
Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking
On 04/23/2014 07:13 PM, Russell King - ARM Linux wrote:
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
So, maybe you would like to finally address *my* point about TDA998x
and your solution in a way that provides a satisfactory answer. *Show*
how it can be done, or *outline* how it can be done.
Let me be absolutely clear *why* I'm very interested in this - and that
is because I'm presently converting TDA998x and Armada DRM to use the
component helpers. If your solution is better, then I'd want to convert
to that instead, and let's retire the component helpers.
At the moment, my belief is that your solution is *very* substandard and
suboptimal precisely for the reasons I've outlined, especially when it
comes to sharing a component between several drivers.
So, if you *really* care, you'll stop fobbing me off on this point and
provide some real technical input how you'd see your solution being used
in exactly the scenario that I've been outlining several times in this
thread.
For example, you could show what kind of modifications you expect would
be required to the _existing_ TDA998x driver to allow it to participate
as a device declared in DT as an entirely separate entity, probed via the
standard I2C probing methods, and then hook itself into the appropriate
DRM driver. Remembering, of course, that the TDA998x device is used by
more than _just_ Armada DRM.
I don't care if you show it via pseudo-code or by real patch. I just
want to know _how_ your solution could be used. And I won't want some
silly remark like trivially or I've already answered that. I want
_you_ to _show_ _how_ it can be done.
Thats good, constructive discussion is better.
I have no experience with tda998x, armada and drm_encoder_slave, so
please be kind if I make some mistakes regarding them.
I will try to show the complete solution starting from the current state
of tda998x and armada in linux-next. I will present solution for DT as
it is more standardized than board files. I hope it should not be a
problem to port it back to board files if necessary.
First I will try to show how to get rid of ifdefs in armada_drv.c, it is
not a part of my proposition but you have emphasized it.
1. tda998x have already minimal DT support, so we can create proper i2c
client device node with nxp,tda998x compatible.
2. There are tda998x_encoder_params defined in armada_drv.c they should
be removed from armada and added to tda998x node, its parsing to tda
driver should be added as well.
3. In armada_drv.c there is armada_drm_slave_config specific for tda. I
am not sure of all its content but it seems it could be mapped to DT
video interface.
So if in armada_drm node there will be port node it means there
is something connected to the output and it uses drm_encoder_slave
interface, if there is no port node there is no encoder.
Sample bindings:
armada_drm {
...
port {
drm_ep: endpoint {
remote-endpoint = tda_ep;
crtcs = 1;
poll_connect;
poll_disconnect;
interlace_allowed;
};
};
};
...
i2c_x {
tda@70 {
reg = 0x70;
compatible = nxp,tda998x;
swap_a = ...;
swap_b = ...;
...
port {
endpoint {
remote-endpoint = drm_ep;
};
};
};
};
4. In armada_drm call of drm_i2c_encoder_init should be replaced
by sth like:
client = of_find_i2c_device_by_node(dev node containing drm_ep phandle);
device_lock(client-dev);
if (!client-dev.driver) {
ret = -EPROBE_DEFER;
goto unlock;
}
module_get(client-dev.driver-owner);
encoder_drv =
to_drm_i2c_encoder_driver(to_i2c_driver(client-dev.driver));
encoder_drv-encoder_init(client, dev, encoder);
unlock:
device_unlock(client-dev);
Similar change should be done to destroy code.
Of course please consider this code as a draft.
All the above is just for removing ifdefs from armada_drv.c, it
is not really connected with my proposition.
It is not really safe, and I am not sure where exactly the locking
should be performed. For sure it can crash when unbind will be called
via sysfs property, but it seems at least as safe as
drm_i2c_encoder_init or it should be possible to make it such.
And it allows to attach to armada theoretically any hardware compatible
encoder having drm_i2c_encoder interface.
What do you think about above steps? Is it OK for you?
And now about my proposition for device probe order issue. My first
answer to your objections about 'glue problem' was to make global list
of 'ready' devices instead of the one glued to the main drm driver.
Over time my idea evolved.
My
Re: [PATCH v2 1/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
On Fri, 25 Apr 2014, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
+static int exynos_ohci_phyg_on(struct phy *phy[])
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; ret == 0 i PHY_NUMBER; i++)
+ if (phy[i])
+ ret = phy_power_on(phy[i]);
+ if (ret)
+ for (i--; i = 0; i--)
+ if (phy[i])
+ phy_power_off(phy[i]);
+
+ return ret;
+}
+
+static int exynos_ohci_phyg_off(struct phy *phy[])
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; ret == 0 i PHY_NUMBER; i++)
+ if (phy[i])
+ ret = phy_power_off(phy[i]);
+
+ return ret;
+}
You probably shouldn't break out of this loop if ret is nonzero; you
should continue to power off the remaining phys.
I'd be inclined to put these two routines directly into
exynos_ohci_phy_enable() and exynos_ohci_phy_disable(), since they
aren't used anywhere else.
@@ -151,6 +253,7 @@ skip_phy:
fail_add_hcd:
exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phyg_off(exynos_ohci-phy_g);
Why did you add this line? It doesn't do anything useful, because
exynos_ohci_phy_disable() already calls exynos_ohci_phyg_off().
Alan Stern
--
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/8] i.MX6 PCIe binding change and MSI support
On Fri, Apr 25, 2014 at 4:21 AM, Lucas Stach l.st...@pengutronix.de wrote: Am Donnerstag, den 24.04.2014, 11:58 -0600 schrieb Bjorn Helgaas: On Fri, Mar 28, 2014 at 05:52:51PM +0100, Lucas Stach wrote: While working on MSI support for the i.MX6 PCIe host driver it has been discovered that the binding for this host controller is broken in many ways (refer to the patch descriptions for more info) and was introduced without proper discussion about what should/should not be in the binding. This series fixes this and minimizes the difference of the i.MX6 binding to the common designware PCIe binding. I'm aware that this is a quite radical change, but I think it's justified to do this as long as there aren't many user of the old binding (most of the optional properties in the binding aren't even implemented). Looking forward to your feedback. Lucas Stach (8): ARM: imx6q-clk: parent lvds_gate from lvds_sel This one is already applied. PCI: designware: split Exynos and i.MX bindings ARM: dts: imx6: update pcie to bring in line with new binding PCI: imx6: use new clock names PCI: imx6: drop old irq mapping PCI: imx6: rip out optional (and unused) irqs PCI: designware: make MSI isr shared irq aware PCI: imx6: add support for MSI What's the status of all these? I would normally apply patches 4-8 of this series through my tree, given the appropriate acks, but I haven't seen those yet. And I'm not sure what dependencies there are between the non-PCI patches and the PCI ones. It's a complete binding change, so applying one part without the other is going to horribly break things. So I would at least want to see an ack for the binding change on the i.MX side from Shawn and Richard. This will need some follow on patches, as some boards adding PCIe using the old binding have cropped up in linux-next, but I can do the patches on short notice if everyone agrees to merge this patchset. The designware part is pretty simple and doesn't change anything for other users than i.MX. Though I would like to see an ack from Jingoo for those. I have some more stuff in the pipes regarding multiple MSI irqs, that depend on this series and also the Keystone people are waiting for this to be applied in order to consolidate the clock handling of the designware core driver, so it would be nice to get this moving again. OK, just poke me again when you're ready for me to do something with these. Bjorn -- 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 v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework
On Fri, 25 Apr 2014, Vivek Gautam wrote:
From: Kamil Debski k.deb...@samsung.com
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
+static int exynos_ehci_phyg_off(struct phy *phy[])
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; ret == 0 i PHY_NUMBER; i++)
+ if (phy[i])
+ ret = phy_power_off(phy[i]);
+
+ return ret;
+}
Same comment as in the OHCI driver about ret.
@@ -175,6 +269,7 @@ skip_phy:
fail_add_hcd:
if (exynos_ehci-phy)
usb_phy_shutdown(exynos_ehci-phy);
+ exynos_ehci_phyg_off(exynos_ehci-phy_g);
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
@@ -195,6 +290,8 @@ static int exynos_ehci_remove(struct platform_device
*pdev)
if (exynos_ehci-phy)
usb_phy_shutdown(exynos_ehci-phy);
+ exynos_ehci_phyg_off(exynos_ehci-phy_g);
+
In both these places, you need to test exynos_ehci-phyg before calling
exynos_ehci_phyg_off().
Maybe it would help to add exynos_ehci_phy_enable/disable routines,
like in the OHCI driver.
Alan Stern
--
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/8] i.MX6 PCIe binding change and MSI support
-Original Message- From: Bjorn Helgaas [mailto:bhelg...@google.com] Sent: Friday, April 25, 2014 10:40 PM To: Lucas Stach Cc: Zhu Richard-R65037; Jingoo Han; Shawn Guo; linux-...@vger.kernel.org; linux-arm; linux-samsung-soc@vger.kernel.org; devicet...@vger.kernel.org; Sean Cross; Marek Vasut; Ian Campbell; Mark Rutland; Pawel Moll; Rob Herring; Arnd Bergmann; Tim Harvey; ker...@pengutronix.de Subject: Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support On Fri, Apr 25, 2014 at 4:21 AM, Lucas Stach l.st...@pengutronix.de wrote: Am Donnerstag, den 24.04.2014, 11:58 -0600 schrieb Bjorn Helgaas: On Fri, Mar 28, 2014 at 05:52:51PM +0100, Lucas Stach wrote: While working on MSI support for the i.MX6 PCIe host driver it has been discovered that the binding for this host controller is broken in many ways (refer to the patch descriptions for more info) and was introduced without proper discussion about what should/should not be in the binding. This series fixes this and minimizes the difference of the i.MX6 binding to the common designware PCIe binding. I'm aware that this is a quite radical change, but I think it's justified to do this as long as there aren't many user of the old binding (most of the optional properties in the binding aren't even implemented). Looking forward to your feedback. Lucas Stach (8): ARM: imx6q-clk: parent lvds_gate from lvds_sel This one is already applied. PCI: designware: split Exynos and i.MX bindings ARM: dts: imx6: update pcie to bring in line with new binding PCI: imx6: use new clock names PCI: imx6: drop old irq mapping PCI: imx6: rip out optional (and unused) irqs PCI: designware: make MSI isr shared irq aware PCI: imx6: add support for MSI What's the status of all these? I would normally apply patches 4-8 of this series through my tree, given the appropriate acks, but I haven't seen those yet. And I'm not sure what dependencies there are between the non-PCI patches and the PCI ones. It's a complete binding change, so applying one part without the other is going to horribly break things. So I would at least want to see an ack for the binding change on the i.MX side from Shawn and Richard. This will need some follow on patches, as some boards adding PCIe using the old binding have cropped up in linux-next, but I can do the patches on short notice if everyone agrees to merge this patchset. The designware part is pretty simple and doesn't change anything for other users than i.MX. Though I would like to see an ack from Jingoo for those. I have some more stuff in the pipes regarding multiple MSI irqs, that depend on this series and also the Keystone people are waiting for this to be applied in order to consolidate the clock handling of the designware core driver, so it would be nice to get this moving again. [Richard] Hi Lucas, thanks. I'm ok for this patch-set. Acked-by: Richard Zhu r65...@freescale.com OK, just poke me again when you're ready for me to do something with these. Bjorn Best Regards Richard Zhu
Re: [PATCH v4 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
Hi Prabhakar, On 25/04/2014 03:31 μμ, Prabhakar Lad wrote: Hi Stratos, Thanks for the patch. On Tue, Apr 22, 2014 at 4:30 AM, Stratos Karafotis strat...@semaphore.gr wrote: The cpufreq core now supports the cpufreq_for_each_entry and cpufreq_for_each_valid_entry macros helpers for iteration over the cpufreq_frequency_table, so use them. It should have no functional changes. This patch produces following build warning, drivers/cpufreq/freq_table.c: In function 'cpufreq_frequency_table_cpuinfo': drivers/cpufreq/freq_table.c:36:3: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=] pr_debug(table entry %lu: %u kHz\n, pos - table, freq); Thanks for this finding. I will fix it and resend the patch. Stratos Karafotis -- 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/5] iio: exynos_adc: use indio_dev-dev structure to handle child nodes
Naveen, Thanks for sending this. Given that Jonathan Cameron was involved in the previous discussion, it probably would have been wise to include him on the CC list. On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com Using pdev-dev with device_for_each_child() would iterate over all of the children of the platform device and delete them. Thus, causing crashes during module unload. We should be using the indio_dev-dev structure for registering/unregistering child nodes. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com --- This change was tested on top of https://lkml.org/lkml/2014/4/21/481 from Doug. drivers/iio/adc/exynos_adc.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Reported-by: Doug Anderson diand...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -- 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 2/5] iio: exynos_adc: rearrange clock and regulator enable/disable calls
Naveen, On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch maintains the following order in probe(), remove(), resume() and suspend() calls regulator enable, clk prepare enable ... clk disable unprepare, regulator disable While at it, 1. enable the regulator before the iio_device_register() 2. handle the return values for enable/disable calls Change-Id: I764d9d60f72caa7ea6b0609db49a74115574f081 Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com --- This change fixes the comments given by Jonathan regarding the order of clock and regulator enable/disable calls. https://lkml.org/lkml/2014/4/23/644 drivers/iio/adc/exynos_adc.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index affa93f..a2b8b1a 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -316,6 +316,14 @@ static int exynos_adc_probe(struct platform_device *pdev) goto err_irq; } + ret = regulator_enable(info-vdd); + if (ret) + goto err_irq; + + ret = clk_prepare_enable(info-clk); + if (ret) + goto err_disable_reg; + info-version = exynos_adc_get_version(pdev); platform_set_drvdata(pdev, indio_dev); @@ -334,13 +342,7 @@ static int exynos_adc_probe(struct platform_device *pdev) ret = iio_device_register(indio_dev); if (ret) - goto err_irq; - - ret = regulator_enable(info-vdd); - if (ret) - goto err_iio_dev; - - clk_prepare_enable(info-clk); + goto err_disable_clk; exynos_adc_hw_init(info); @@ -355,10 +357,11 @@ static int exynos_adc_probe(struct platform_device *pdev) err_of_populate: device_for_each_child(indio_dev-dev, NULL, exynos_adc_remove_devices); - regulator_disable(info-vdd); - clk_disable_unprepare(info-clk); -err_iio_dev: iio_device_unregister(indio_dev); +err_disable_clk: + clk_disable_unprepare(info-clk); +err_disable_reg: + regulator_disable(info-vdd); err_irq: free_irq(info-irq, info); return ret; @@ -371,9 +374,10 @@ static int exynos_adc_remove(struct platform_device *pdev) device_for_each_child(indio_dev-dev, NULL, exynos_adc_remove_devices); - regulator_disable(info-vdd); clk_disable_unprepare(info-clk); + regulator_disable(info-vdd); writel(0, info-enable_reg); + This function still looks wrong. The order of things should generally match the error case of probe, which is the reverse of how things are initted. Specifically you shouldn't be doing iio_device_unregister(indio_dev); last. Technically it's also a very good idea to free the irq much earlier. ...and in probe you should request it later. The request_irq should probably be right before the register function in probe and the free_irq should be right after unregister in remove. iio_device_unregister(indio_dev); free_irq(info-irq, info); @@ -398,8 +402,8 @@ static int exynos_adc_suspend(struct device *dev) } clk_disable_unprepare(info-clk); - writel(0, info-enable_reg); regulator_disable(info-vdd); + writel(0, info-enable_reg); This change looks wrong to me. I'd believe that the rule should always be that the regulator is enabled early and disabled late. return 0; } @@ -410,12 +414,14 @@ static int exynos_adc_resume(struct device *dev) struct exynos_adc *info = iio_priv(indio_dev); int ret; + writel(1, info-enable_reg); ret = regulator_enable(info-vdd); if (ret) return ret; Same here. Should enable the regulator first, I think. -- 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/5] iio: exynos_adc: reduce timeout and use wait_for_completion_timeout
Naveen, On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: ADC module on Exynos5 SoCs runs at 600KSPS. At this conversion rate, waiting for 1000 msecs is wasteful (incase of h/w failure). Hence, reduce the time out to 100msecs and use wait_for_completion_timeout() instead of wait_for_completion_interruptible_timeout() Also, handle the return values in exynos_raw_read() call. You probably didn't need to mention this--it's just a natural part of changing from wait_for_completion_interruptible_timeout() to wait_for_completion_timeout(). Change-Id: Icb8cade162094b2777c9f3c77120635deef5947c Please don't send upstream with Change-Id. Have you considered patman http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;hb=refs/heads/master? Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- This change is a part of the patch reviewd at https://lkml.org/lkml/2013/11/5/92 drivers/iio/adc/exynos_adc.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) Other than problems above, this looks fine to me. If you fix them, feel free to add my Reviewed-by tag. -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 4/5] iio: exynos_adc: do a soft reset in case of timeout
Naveen, On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Do a soft reset software if a timeout happens. This is applicable only for ADC_V2. Change-Id: I939eaa06254e0b246dd636df9470f2eb392c2be1 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- This change is a part of the patch reviewed at https://lkml.org/lkml/2013/11/5/92 drivers/iio/adc/exynos_adc.c | 50 ++ 1 file changed, 26 insertions(+), 24 deletions(-) Reviewed-by: Doug Anderson diand...@chromium.org -- 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 5/5] iio: exynos_adc: do a reinit_completion before the conversion
Naveen On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Add reinit_completion() before the wait_for_completion_timeout in raw_read() call. Change-Id: I70fa00841bc49eba838a5bd6779015844297dfdb Again, remove Change-Id (in the previous patch, too). Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- drivers/iio/adc/exynos_adc.c |1 + 1 file changed, 1 insertion(+) Seems reasonable. Reviewed-by: Doug Anderson diand...@chromium.org -- 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 2/9] drm/panel: add pre_enable and post_disable routines
On Fri, Apr 25, 2014 at 11:34 AM, Ajay kumar ajayn...@gmail.com wrote: On Friday, April 25, 2014, Thierry Reding thierry.red...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote: Thierry, On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote: [...] Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. I'm not at all comfortable with these. The names are totally confusing. Next somebody will need to do something after the panel has been enabled and we'll have to introduce .post_enable() and .pre_disable() functions. And worse, what if somebody needs something to be done between .pre_enable() and .enable()? .post_pre_enable()? Where does it end? According to the above description the only reason why we need this is to avoid visible glitches when the panel is already on, but the video stream hasn't started yet. If that's the only reason why we need this, then perhaps adding a way for a panel to expose the associated backlight would be better? Actually, we need not expose the entire backlight device. AFAIK, the glitch is caused when you enable BL_EN before there is valid video data. So, one way to mask off the glitch is to follow this sequence: -- power up the panel. -- start video data, (start PWM here or) -- (start PWM here), enable backlight That's very difficult to get right, isn't it? Even if you have fine- grained control over what to enable you still need a way to determine _when_ it's safe to enable the backlight. Typically I guess that would be the duration of one frame (or perhaps 2, depending on when the panel syncs to the video signal). We need not determine, its already present in LVDS datasheet. The LVDS datasheet says at least 200ms delay is needed from Valid data to BL on. Perhaps it could even by sync'ed to the VBLANK? No. vblanks are related to crtc. And the bridge/panel driver should be independent of vblank. The problem is that the above scenario cannot be mapped to panel-simple driver. IMO, panel_simple should provide enable/disable controls both for LCD and backlight. something like panel_simple_lcd_enable/panel_simple_led_enable, and panel_simple_lcd_disable/panel_simple_led_disable. That's not what the simple panel driver can do. If we want this it needs to be solved in a generic way for all panels since they all need to use the drm_panel_*() functions to abstract away the details from drivers that use the panels. Right. So only I have added pre_enable and post_disable callbacks. Using that name won't harm existing panel drivers and still addresses our requirement. Regards, Ajay Thierry : Are you really ok with the new callback names? like pre_enable and post_disable? Adding those new callbacks really won't harm the existing panels anyhow. Daniel, Rob : I think I have given sufficient amount of information as to why the concept of drm_panel_bridge fails and why we cannot have callbacks for drm_panel inside crtc helpers or any other generic place. Please let me know your final opinion so that I can start reworking on this series. Thanks and regards, Ajay Kumar -- 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] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board
d726ca2d3316 (ARM: dts: Add vmmc-supply to MMC on arndale-octa board)
added the vmmc-supply to nodes mmc@1220 and mmc@1222 of the
DT. However, this makes the kernel fail to boot on the arndale-octa
spews:
[5.06] dwmmc_exynos 1220.mmc: num-slots property not found,
assuming 1 slot is available
[5.065000] platform 1220.mmc: Driver dwmmc_exynos requests probe
deferral
[5.075000] dwmmc_exynos 1222.mmc: num-slots property not found,
assuming 1 slot is available
[5.085000] platform 1222.mmc: Driver dwmmc_exynos requests probe
deferral
And eventually hangs. Without the vmmc-supply property in the
mmc@1222 node, the kernel boots again.
Signed-off-by: Javi Merino javi.mer...@arm.com
---
Hi,
Note that I don't know *why* removing the property works, all I know
is that 3.15-rc2 fails to boot on my Arndale Octa unless I apply this
patch.
Cheers,
Javi
arch/arm/boot/dts/exynos5420-arndale-octa.dts |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 80a3bf4..722fb6c 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -64,7 +64,6 @@
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
- vmmc-supply = ldo10_reg;
slot@0 {
reg = 0;
--
1.7.9.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] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board
Hi Javi, On 25.04.2014 22:11, Javi Merino wrote: d726ca2d3316 (ARM: dts: Add vmmc-supply to MMC on arndale-octa board) added the vmmc-supply to nodes mmc@1220 and mmc@1222 of the DT. However, this makes the kernel fail to boot on the arndale-octa spews: [5.06] dwmmc_exynos 1220.mmc: num-slots property not found, assuming 1 slot is available [5.065000] platform 1220.mmc: Driver dwmmc_exynos requests probe deferral [5.075000] dwmmc_exynos 1222.mmc: num-slots property not found, assuming 1 slot is available [5.085000] platform 1222.mmc: Driver dwmmc_exynos requests probe deferral And eventually hangs. Without the vmmc-supply property in the mmc@1222 node, the kernel boots again. Signed-off-by: Javi Merino javi.mer...@arm.com --- Hi, Note that I don't know *why* removing the property works, all I know is that 3.15-rc2 fails to boot on my Arndale Octa unless I apply this patch. Are you sure you have the required PMIC driver enabled in your kernel config? Best regards, Tomasz -- 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 v5 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
drivers/cpufreq/acpi-cpufreq.c | 9 +++---
drivers/cpufreq/arm_big_little.c | 16 +--
drivers/cpufreq/cpufreq_stats.c | 24 ++--
drivers/cpufreq/dbx500-cpufreq.c | 8 ++
drivers/cpufreq/elanfreq.c | 9 +++---
drivers/cpufreq/exynos-cpufreq.c | 11 ---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +--
drivers/cpufreq/freq_table.c | 56
drivers/cpufreq/longhaul.c | 11 ---
drivers/cpufreq/pasemi-cpufreq.c | 10 +++
drivers/cpufreq/powernow-k6.c| 14 -
drivers/cpufreq/ppc_cbe_cpufreq.c| 9 +++---
drivers/cpufreq/s3c2416-cpufreq.c| 40 +++---
drivers/cpufreq/s3c64xx-cpufreq.c| 15 --
14 files changed, 116 insertions(+), 146 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 000e4e0..b0c18ed 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct
acpi_cpufreq_data *data)
static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
{
- int i;
+ struct cpufreq_frequency_table *pos;
struct acpi_processor_performance *perf;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
@@ -223,10 +223,9 @@ static unsigned extract_msr(u32 msr, struct
acpi_cpufreq_data *data)
perf = data-acpi_data;
- for (i = 0; data-freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
- if (msr == perf-states[data-freq_table[i].driver_data].status)
- return data-freq_table[i].frequency;
- }
+ cpufreq_for_each_entry(pos, data-freq_table)
+ if (msr == perf-states[pos-driver_data].status)
+ return pos-frequency;
return data-freq_table[0].frequency;
}
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index bad2ed3..1f4d4e3 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -226,22 +226,22 @@ static inline u32 get_table_count(struct
cpufreq_frequency_table *table)
/* get the minimum frequency in the cpufreq_frequency_table */
static inline u32 get_table_min(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t min_freq = ~0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency min_freq)
- min_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency min_freq)
+ min_freq = pos-frequency;
return min_freq;
}
/* get the maximum frequency in the cpufreq_frequency_table */
static inline u32 get_table_max(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t max_freq = 0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency max_freq)
- max_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency max_freq)
+ max_freq = pos-frequency;
return max_freq;
}
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index ecaaebf..0cd9b4d 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
{
- unsigned int i, j, count = 0, ret = 0;
+ unsigned int i, count = 0, ret = 0;
struct cpufreq_stats *stat;
unsigned int alloc_size;
unsigned int cpu = policy-cpu;
- struct cpufreq_frequency_table *table;
+ struct cpufreq_frequency_table *pos, *table;
table = cpufreq_frequency_get_table(cpu);
if (unlikely(!table))
@@ -205,12 +205,8 @@ static int __cpufreq_stats_create_table(struct
cpufreq_policy *policy)
stat-cpu = cpu;
per_cpu(cpufreq_stats_table, cpu) = stat;
- for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table)
count++;
- }
alloc_size = count * sizeof(int) + count * sizeof(u64);
@@ -228,15 +224,11 @@ static int __cpufreq_stats_create_table(struct
cpufreq_policy *policy)
#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
Re: [PATCH] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board
On Fri, Apr 25, 2014 at 09:16:30PM +0100, Tomasz Figa wrote: Hi Javi, On 25.04.2014 22:11, Javi Merino wrote: d726ca2d3316 (ARM: dts: Add vmmc-supply to MMC on arndale-octa board) added the vmmc-supply to nodes mmc@1220 and mmc@1222 of the DT. However, this makes the kernel fail to boot on the arndale-octa spews: [5.06] dwmmc_exynos 1220.mmc: num-slots property not found, assuming 1 slot is available [5.065000] platform 1220.mmc: Driver dwmmc_exynos requests probe deferral [5.075000] dwmmc_exynos 1222.mmc: num-slots property not found, assuming 1 slot is available [5.085000] platform 1222.mmc: Driver dwmmc_exynos requests probe deferral And eventually hangs. Without the vmmc-supply property in the mmc@1222 node, the kernel boots again. Signed-off-by: Javi Merino javi.mer...@arm.com --- Hi, Note that I don't know *why* removing the property works, all I know is that 3.15-rc2 fails to boot on my Arndale Octa unless I apply this patch. Are you sure you have the required PMIC driver enabled in your kernel config? I configured the kernel using exynos_defconfig and that gives me: # CONFIG_PMIC_ADP5520 is not set # CONFIG_PMIC_DA903X is not set Should I be using other defconfig for this board? exynos_defconfig used to work in 3.14. Cheers, Javi -- 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] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board
On 25.04.2014 22:30, Javi Merino wrote: On Fri, Apr 25, 2014 at 09:16:30PM +0100, Tomasz Figa wrote: Hi Javi, On 25.04.2014 22:11, Javi Merino wrote: d726ca2d3316 (ARM: dts: Add vmmc-supply to MMC on arndale-octa board) added the vmmc-supply to nodes mmc@1220 and mmc@1222 of the DT. However, this makes the kernel fail to boot on the arndale-octa spews: [5.06] dwmmc_exynos 1220.mmc: num-slots property not found, assuming 1 slot is available [5.065000] platform 1220.mmc: Driver dwmmc_exynos requests probe deferral [5.075000] dwmmc_exynos 1222.mmc: num-slots property not found, assuming 1 slot is available [5.085000] platform 1222.mmc: Driver dwmmc_exynos requests probe deferral And eventually hangs. Without the vmmc-supply property in the mmc@1222 node, the kernel boots again. Signed-off-by: Javi Merino javi.mer...@arm.com --- Hi, Note that I don't know *why* removing the property works, all I know is that 3.15-rc2 fails to boot on my Arndale Octa unless I apply this patch. Are you sure you have the required PMIC driver enabled in your kernel config? I configured the kernel using exynos_defconfig and that gives me: # CONFIG_PMIC_ADP5520 is not set # CONFIG_PMIC_DA903X is not set Should I be using other defconfig for this board? exynos_defconfig used to work in 3.14. Cheers, Well, unfortunately exynos_defconfig is known to be far from being reasonable. Right now it should be considered just as a base to configure the kernel for Exynos SoCs. Most of board specific options (and many of SoC-wide ones) need to be selected manually. Anyway, with the number of Exynos boards supported in mainline, I don't think we will be ever going to enable all options for all the supported boards by default in defconfig, especially considering the fact that we will be moving to generic multi_v7_defconfig and likely dropping exynos_defconfig completely. As for now, I believe you should just make sure yourself that any options relevant to your board are enabled. Best regards, Tomasz -- 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 01/10] ARM: EXYNOS: Make exynos machine_ops as static
Hi Pankaj,
On 25.04.2014 14:32, Pankaj Dubey wrote:
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..2388ee4 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -235,7 +235,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -296,7 +296,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
This patch seems to be irrelevant to the rest of this series. Anyway,
the changes itself are fine, except that I can see more functions that
could be made static as well:
- exynos_cpuidle_init(),
- exynos_cpufreq_init().
In fact, they both could be probably eliminated, as they are just
oneliners doing things that could be done in exynos_dt_machine_init()
directly.
So, if you are doing this kind of cleanup, you could do this as well and
probably also replace platform_device + platform_device_register() with
platform_device_register_simple() for cpuidle, to reduce line count and
make it consistent with cpufreq.
Best regards,
Tomasz
--
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 03/10] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file.
Hi Pankaj, On 25.04.2014 14:32, Pankaj Dubey wrote: From: Young-Gun Jang yg1004.j...@samsung.com While making PMU implementation to be device tree based, there are few register offsets related with SYSREG present in regs-pmu.h, so let's make a new header file regs-sys.h to keep all such SYSREG related register offsets and remove them from regs-pmu.h Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/exynos.c |1 + arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/regs-pmu.h |3 --- arch/arm/mach-exynos/regs-sys.h | 22 ++ 4 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-exynos/regs-sys.h Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 04/10] ARM: EXYNOS: Remove file path from comment section
Hi Pankaj, On 25.04.2014 14:32, Pankaj Dubey wrote: Many files under arm/mach-exynos are having file path in file comment section which is invalid now. So for better code maintainability let's remove them. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/headsmp.S |2 -- arch/arm/mach-exynos/hotplug.c |3 +-- arch/arm/mach-exynos/include/mach/memory.h |3 +-- arch/arm/mach-exynos/platsmp.c |3 +-- 4 files changed, 3 insertions(+), 8 deletions(-) Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 05/10] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
Hi, On 25.04.2014 14:32, Pankaj Dubey wrote: From: Young-Gun Jang yg1004.j...@samsung.com Current pm_domain.c file uses S5P_INT_LOCAL_PWR_EN definition from regs-pmu.h and hence needs to include this header file. As there is no other user of S5P_INT_LOCAL_PWR_EN definition other than pm_domain, to remove regs-pmu.h header file dependency from pm_domain.c it's better we define this definition in pm_domain.c file itself and thus it will help in removing header file inclusion from pm_domain.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com --- arch/arm/mach-exynos/pm_domains.c |2 +- arch/arm/mach-exynos/regs-pmu.h |1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index fe6570e..f676b0a 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -22,7 +22,7 @@ #include linux/of_platform.h #include linux/sched.h -#include regs-pmu.h +#define S5P_INT_LOCAL_PWR_EN 0x7 nit: You could indent the value a bit more in case of adding any new macros in future. While at it, you could probably also drop the S5P_ prefix. With these fixed, feel free to add my Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Samsung Power Management Unit (PMU) base address
from device tree. Code will use existing samsung pmu binding information.
This patch also adds two helper functions as get_exynos_pmuregmap and
get_exynos_pmuaddr.
get_exynos_pmuregmap returns a regmap based PMU register handle where as
get_exynos_pmuaddr returns ioremap virtual address.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/Kconfig |2 ++
arch/arm/mach-exynos/common.h |3 ++
arch/arm/mach-exynos/exynos.c | 78 +
3 files changed, 83 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..2f60c90 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -26,6 +26,7 @@ config ARCH_EXYNOS4
select PINCTRL
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
+ select MFD_SYSCON
help
Samsung EXYNOS4 SoCs based systems
@@ -36,6 +37,7 @@ config ARCH_EXYNOS5
select HAVE_ARM_SCU if SMP
select HAVE_SMP
select PINCTRL
+ select MFD_SYSCON
help
Samsung EXYNOS5 (Cortex-A15) SoC based systems
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 31c5964..ecfd0fc 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -57,4 +57,7 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern struct regmap *get_exynos_pmuregmap(void);
+extern void __iomem *get_exynos_pmuaddr(void);
Do you really need these functions? Couldn't all the drivers using PMU
simply call syscon_regmap_lookup_by_phandle() or of_iomap() directly?
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index d6f405f..68f60e1 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,7 @@
#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_domain.h
+#include linux/mfd/syscon.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -36,6 +37,9 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static struct regmap *exynos_pmu_regmap;
+static void __iomem *exynos_pmu_base;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -269,6 +273,46 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = samsung,exynos4210-pmu },
+ { .compatible = samsung,exynos4212-pmu },
+ { .compatible = samsung,exynos4412-pmu },
+ { .compatible = samsung,exynos5250-pmu },
+ {},
+};
+
+static int __init exynos_fdt_map_pmu(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+ phys_addr_t phys_addr;
+ const struct of_device_id *matches = exynos_dt_pmu_match;
+
+ for (; matches-compatible[0]; matches++) {
+ if (!of_flat_dt_is_compatible(node, matches-compatible))
+ continue;
+ reg = of_get_flat_dt_prop(node, reg, len);
+ if (reg == NULL || len != (sizeof(unsigned long) * 2))
+ return 0;
+
+ phys_addr = be32_to_cpu(reg[0]);
+ iodesc.pfn = __phys_to_pfn(phys_addr);
+ iodesc.length = be32_to_cpu(reg[1]) - 1;
+ iodesc.virtual = (unsigned long)S5P_VA_PMU;
+ iodesc.type = MT_DEVICE;
+ iotable_init(iodesc, 1);
+
+ exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
+ if (WARN_ON(!exynos_pmu_base))
+ return -EFAULT;
+ return 1;
+ }
+
+ return 0;
+}
Is such early mapping really needed? Couldn't the code using PMU be
deferred to the stage that memory management is available and then
of_iomap() used directly?
+
/*
* exynos_map_io
*
@@ -302,6 +346,7 @@ static void __init exynos_init_io(void)
debug_ll_io_init();
of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+ of_scan_flat_dt(exynos_fdt_map_pmu, NULL);
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
@@ -336,6 +381,38 @@ static int __init exynos4_l2x0_cache_init(void)
}
early_initcall(exynos4_l2x0_cache_init);
+
+inline struct regmap *get_exynos_pmuregmap()
+{
+ return exynos_pmu_regmap;
+}
+
+inline void __iomem *get_exynos_pmuaddr()
+{
+ return exynos_pmu_base;
+}
Hmm, non-static inline inside a C file?
Re: [PATCH v2 07/10] ARM: EXYNOS: Remove linux/bug.h from pmu.c
Hi, On 25.04.2014 14:32, Pankaj Dubey wrote: From: Young-Gun Jang yg1004.j...@samsung.com This patch removes unnecessary header file inclusion from pmu.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com --- arch/arm/mach-exynos/pmu.c |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c index 05c7ce1..4c3453a 100644 --- a/arch/arm/mach-exynos/pmu.c +++ b/arch/arm/mach-exynos/pmu.c @@ -11,7 +11,6 @@ #include linux/io.h #include linux/kernel.h -#include linux/bug.h #include plat/cpu.h Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 08/10] ARM: EXYNOS: Refactored code for using PMU address via DT
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
Under arm/mach-exynos many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc.
Let's convert all these access using either of get_exynos_pmuaddr
or get_exynos_regmap.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to driver
folder which can be reused for ARM64 bsed SoC.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h |4 +-
arch/arm/mach-exynos/cpuidle.c | 37 ++-
arch/arm/mach-exynos/exynos.c | 19 +-
arch/arm/mach-exynos/hotplug.c |4 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/platsmp.c | 13 +-
arch/arm/mach-exynos/pm.c | 60 ++--
arch/arm/mach-exynos/pmu.c | 40 +--
arch/arm/mach-exynos/regs-pmu.h | 506 +++
9 files changed, 348 insertions(+), 338 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ecfd0fc..ad5128e 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -40,7 +40,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END 0x
IMHO (-1U) would be more appropriate.
enum sys_powerdown {
SYS_AFTR,
@@ -51,7 +51,7 @@ enum sys_powerdown {
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c57cae0..5dcdd46 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/time.h
#include linux/platform_device.h
+#include linux/regmap.h
#include asm/proc-fns.h
#include asm/smp_scu.h
@@ -34,10 +35,10 @@
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
- (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+ 0x24 : S5P_INFORM0))
#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
- (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+ 0x20 : S5P_INFORM1))
This patch seems to be based on old code, before Daniel Lezcano's Exynos
cpuidle refactor [1] and it should be rebased on top of that series.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085
#define S5P_CHECK_AFTR0xFCBA0D10
@@ -60,6 +61,8 @@
#define PWR_CTRL2_CORE2_UP_RATIO (1 4)
#define PWR_CTRL2_CORE1_UP_RATIO (1 0)
+static struct regmap *pmu_regmap;
+
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
@@ -87,7 +90,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos4_set_wakeupmask(void)
{
- __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+ regmap_write(pmu_regmap, S5P_WAKEUP_MASK, 0xff3e);
}
static unsigned int g_pwr_ctrl, g_diag_reg;
@@ -120,22 +123,28 @@ static int exynos4_enter_core0_aftr(struct cpuidle_device
*dev,
struct cpuidle_driver *drv,
int index)
{
- unsigned long tmp;
+ unsigned int tmp;
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
exynos_sys_powerdown_conf(SYS_AFTR);
-
- __raw_writel(virt_to_phys(exynos_cpu_resume), REG_DIRECTGO_ADDR);
- __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
-
+
+ if (samsung_rev() == EXYNOS4210_REV_1_0) {
+ __raw_writel(virt_to_phys(exynos_cpu_resume),
+ S5P_VA_SYSRAM + REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, S5P_VA_SYSRAM + REG_DIRECTGO_FLAG);
+ } else {
+ regmap_write(pmu_regmap, REG_DIRECTGO_ADDR,
+ virt_to_phys(exynos_cpu_resume));
+ regmap_write(pmu_regmap, REG_DIRECTGO_FLAG, S5P_CHECK_AFTR);
+ }
This is quite ugly. I'd refactor this into a function pointer set once
at initialization time depending on SoC type and create two functions
for both cases.
In general, please also see my comments about this kind of code checking
SoC type posted as a part of my review of Vikas' Exynos5260 PMU
Re: [PATCH v2 10/10] ARM: EXYNOS: Add device tree based initialization support for PMU.
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
This patch adds device tree based initialization for PMU and modifies
PMU initialization implementation in following way:
1: Let's initialize PMU based on device tree compatibility string.
2: Obtain PMU regmap handle using syscon_early_regmap_lookup_by_phandle
so that we can reduce dependency over machine header files.
3: Separate each SoC's PMU initialization function and bind this initialization
function with PMU compatibility string.
4 : It also removes uses of soc_is_exynos() thus making PMU implementation
independent of plat/cpu.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
---
arch/arm/mach-exynos/pmu.c | 182 +---
1 file changed, 138 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..abcf753 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -9,17 +9,31 @@
* published by the Free Software Foundation.
*/
-#include linux/io.h
#include linux/kernel.h
#include linux/regmap.h
-
-#include plat/cpu.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
+enum exynos_pmu_id {
+ PMU_EXYNOS4210,
+ PMU_EXYNOS4X12,
+ PMU_EXYNOS4412,
+ PMU_EXYNOS5250,
+};
+
+struct exynos_pmu_data {
+ enum exynos_pmu_id pmu_id;
+ struct regmap *pmu_regmap;
Again, since this uses the PMU node directly and doesn't seem to access
any registers shared with other drivers (or at least not at the time
most the functions from this file are called) I don't think there is any
reason why not to use of_iomap() and access the registers directly.
What about adding more fields to this struct? For example .pmu_config,
.pmu_config_extra (for model-specific settings, like for Exynos4412, see
my comment below) and (*pmu_init)? Of course the regmap (or base
address) would have to be moved outside, as it isn't const data.
Then for each PMU variant there would be a static const struct will all
those fields already filled in and entries in OF match table would
already point to appropriate structure.
+};
+
+struct exynos_pmu_data *pmu_data;
static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+typedef void (*exynos_pmu_init_t)(void);
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .reg = address, .val = { AFTR, LPA, SLEEP } */
@@ -348,28 +362,31 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
- tmp = regmap_read(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
- tmp);
+ tmp = regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
tmp = ~(EXYNOS5_OPTION_USE_STANDBYWFE |
EXYNOS5_OPTION_USE_STANDBYWFI);
- regmap_write(pmu_regmap, exynos5_list_diable_wfi_wfe[i], tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
}
}
@@ -377,52 +394,129 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
+ if (pmu_data-pmu_id == PMU_EXYNOS5250)
exynos5_init_pmu();
Next field could be added to exynos_pmu_data struct, called
(*powerdown_conf) and then the code above replaced with:
if (pmu_data-powerdown_conf)
pmu_data-powerdown_conf(mode);
for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- regmap_write(pmu_regmap,
Re: [PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT
Hi Pankaj, Just a small note - please refrain from sending next versions of series in reply to previous version. With threading applied, it gets hard to notice that a new version was posted, because the first message of the thread is always v1. Also it makes threads unnecessarily long. Best regards, Tomasz On 25.04.2014 14:32, Pankaj Dubey wrote: This patch series, does some minor cleanup and modifies Exynos PMU related code for mapping and initialization of Exynos Power Management Unit (PMU) base address from device tree. This is also preparation for moving PMU related code out of machine folder and moving into a drivers/mfd, so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos4210, Exynos4212 and Exynos4412 dtsi files, which has been posted as separate patch series [2] These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch. These patches depends on following two patch series: 1) mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 2) Add PMU node for Exynos SoCs http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html We have tested these patches on SMDK5250 and Arndale (Exynos5250) boards for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey pankaj.du...@samsung.com Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: Make exynos machine_ops as static. For making more cleanup in mach-exynos/common.h as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning mach-exynos/common.h. - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under mach-exynos. Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of exynos_pmu_base, as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that early_syscon_init requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as smp_secondary_init will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove linux/bug.h from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to drivers/mfd folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as samsung, exynosxxx-pmu, syscon, once we enable MFD_SYSCON config option, current syscon driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using syscon_early_regmap_lookup_by_phandle. If there is any better solution please suggest. Pankaj Dubey (6): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Cleanup mach-exynos/common.h file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c ARM: EXYNOS: Add device tree based initialization support for PMU. Young-Gun Jang (4): ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Remove linux/bug.h from pmu.c arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/common.h | 13 +- arch/arm/mach-exynos/cpuidle.c | 37 +- arch/arm/mach-exynos/exynos.c | 104 +- arch/arm/mach-exynos/headsmp.S |2 - arch/arm/mach-exynos/hotplug.c |7 +- arch/arm/mach-exynos/include/mach/map.h|3 -
Re: [PATCH 2/4] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
Hi Chander,
On 20.04.2014 09:23, Chander Kashyap wrote:
Hi Tomasz,
On 18 April 2014 20:12, Tomasz Figa t.f...@samsung.com wrote:
When CPU topology is specified in device tree, cpu_logical_map() does
not return core ID anymore, but rather full MPIDR value. This breaks
existing calculation of PMU register offsets on Exynos SoCs.
This patch fixes the problem by adjusting the code to use only core ID
bits of the value returned by cpu_logical_map() to allow CPU topology to
be specified in device tree on Exynos SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 10 ++
arch/arm/mach-exynos/platsmp.c | 31 ++-
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 7e0f31a..8a5f07d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -92,11 +92,13 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
for (;;) {
- /* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(1));
I think this macro is not yet in ML code.
What do you mean? The S5P_ARM_CORE_CONFIGURATION() macro is being added
by patch 1/4.
Best regards,
Tomasz
--
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 v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Tarek Dakhran t.dakh...@samsung.com writes:
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
[...]
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..83ae5fb 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
for (;;) {
/* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ if (cpu 0)
+ __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
This looks like a fix that's probably not specific to the 5410 and maybe
deserves it's own patch?
[...]
@@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu,
struct task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) S5P_CORE_LOCAL_PWR_EN)) {
+ if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu)) S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
- S5P_ARM_CORE1_CONFIGURATION);
+ S5P_ARM_CORE_CONFIGURATION(cpu));
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+ while ((__raw_readl(S5P_ARM_CORE_STATUS(cpu))
S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
...and this hunk too?
Kevin
--
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 v8 0/3] Exynos 5410 support
Tarek Dakhran t.dakh...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Linux Kernel v3.15-rc1 Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Odroid-XU board (exynos_defconfig) Tested-by: Kevin Hilman khil...@linaro.org I also boot tested (to initramfs) on my odroid-XU and see the 4 big cores booted. Presumably I'm still missing the u-boot/firmware magic for the little cores. Kevin -- 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 v5 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
On 22.04.2014 10:03, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 629
4 files changed, 681 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
I think you should probably keep the entries sorted, so this one should
be somewhere around other EXYNOS PHYs.
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
Ditto.
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..89d7ae8
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,629 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Hi Kevin,
On 26.04.2014 00:52, Kevin Hilman wrote:
Tarek Dakhran t.dakh...@samsung.com writes:
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
[...]
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..83ae5fb 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
for (;;) {
/* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ if (cpu 0)
+ __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
This looks like a fix that's probably not specific to the 5410 and maybe
deserves it's own patch?
[...]
@@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) S5P_CORE_LOCAL_PWR_EN)) {
+ if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu)) S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURATION(cpu));
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+ while ((__raw_readl(S5P_ARM_CORE_STATUS(cpu))
S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
...and this hunk too?
Yes, they do, but we are currently refactoring this code anyway.
Best regards,
Tomasz
--
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 v6 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
I have reviewed v5 without noticing this one, but I think most of the
comments still apply.
Best regards,
Tomasz
On 22.04.2014 13:24, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Mistakenly sent a WIP patchset in v5 version of this patch, that gives
build errors. So fixed those.
Changes from v5:
- Removed any mention about sclk_usbphy30* in the driver.
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 626
4 files changed, 678 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ca1f6ab
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,626 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it
Re: [PATCH] ARM: exynos: register sched_clock callback
Hi Vincent,
On 24.04.2014 11:21, Vincent Guittot wrote:
Use the clocksource mct-frc for sched_clock
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
drivers/clocksource/exynos_mct.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index a6ee6d7..61b0577 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -24,6 +24,7 @@
#include linux/of_irq.h
#include linux/of_address.h
#include linux/clocksource.h
+#include linux/sched_clock.h
#define EXYNOS4_MCTREG(x) (x)
#define EXYNOS4_MCT_G_CNT_L EXYNOS4_MCTREG(0x100)
@@ -192,12 +193,19 @@ struct clocksource mct_frc = {
.resume = exynos4_frc_resume,
};
+static u64 notrace exynos4_read_sched_clock(void)
+{
+ return exynos4_frc_read(mct_frc);
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
+
+ sched_clock_register(exynos4_read_sched_clock, 64, clk_rate);
}
static void exynos4_mct_comp0_stop(void)
Thanks for this patch.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Best regards,
Tomasz
--
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] ARM: dts: Remove mau_pd node for Exynos5420
On 24.04.2014 13:03, Tushar Behera wrote: On 04/24/2014 03:36 PM, Tomasz Figa wrote: On 24.04.2014 11:07, Tushar Behera wrote: On 04/23/2014 03:43 PM, Kukjin Kim wrote: Tushar Behera wrote: On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote: Hi Tushar On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera tushar.beh...@linaro.org wrote: MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. + Jonghwan Choi Well, this is not a perfect solution to support MAU power domain, it's true it is a problem right now though. In other words, this is just temporal fix for the problem. How about accessing clock stuff for audio sub-system with handling MAU power domain via generic IO power domain? + Tomasz Figa Existing power domain driver exynos4_pm_init_power_domain is registered with an arch_initcall whereas the clk-exynos-audss driver is registered with core_initcall. Hence even if add mau_pd node to clk-exynos-audss node, the binding with power-domain doesn't happen. I'd say core_initcall is way too early for clk-exynos-audss driver. It should be at most subsys_initcall. As far as I can see, all users of clocks provided by this driver (i.e. i2s) are probed at device_initcall level anyway. It is also used by ADMA node, which gets probed. If I'm looking correctly, ADMA is handled by pl330 driver which is registered at device_initcall level and so it shouldn't make problems with clk-exynos-audss driver being probed at subsys_initcall level. Alternately, if Tomasz's patches are applied [1], power-domain binding is successful. But because of the init order, clk-exynos-audss defers probe resulting in a kernel crash. Forcing clk-exynos-audss to register through arch_initcall() fixes this issue, but I am not sure if that is okay. If the driver crashes on deferred probe, then it's a bug and it should be fixed. By the time clk-exynos-audss is getting called, mau_pd is already disabled by power-domain driver. That is not getting enabled during clk-exynos-audss probe. Am I missing something? Probably. The driver should enable runtime PM and call pm_runtime_get_sync() to make sure that power is supplied to the device it accesses. By the way, if defining MAU power domain in DT, then also all the devices inside of this domain should be bound to it, including ADMA and I2S, but I don't see neither of them having the samsung,power-domain property. Best regards, Tomasz -- 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 v5] clk: Exynos5250: Add clocks for G3D
Hi Arun,
On 24.04.2014 16:49, Arun Kumar K wrote:
This patch adds the required clocks for ARM Mali IP
in Exynos5250.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch somehow got missed getting merged long time
back after Acks by Mike and Kukjin and review done by
Tomasz and Doug.
Sorry for this, I have obviously missed this patch. Feel free to ping me
if you don't see a reply from me for some time (a week or two). There
are large volumes of e-mails going through my mailbox and such small
single patches can easily get lost. ;)
Anyway, since this patch seems to have changed quite a bit since last
version, please see my comments inline.
http://www.spinics.net/lists/linux-samsung-soc/msg21608.html
Resending it now after rebasing and testing on the latest kernel.
Changes from v4
- Rebased on latest kernel
- Added macros
Changes from v3
- Renamed some clocks as per Tomasz Figa's comments
Changes from v2
- Rebased on clk-next
Changes from v1
- Removed exporting of parent DIV clock for g3d
as per Tomsz Figa's comment.
---
drivers/clk/samsung/clk-exynos5250.c | 14 ++
include/dt-bindings/clock/exynos5250.h |2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee442..14a1d49 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -37,6 +37,7 @@
#define VPLL_CON0 0x10140
#define GPLL_CON0 0x10150
#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
#define SRC_TOP2 0x10218
#define SRC_TOP3 0x1021c
#define SRC_GSCL 0x10220
@@ -71,6 +72,7 @@
#define GATE_IP_GSCL 0x10920
#define GATE_IP_DISP1 0x10928
#define GATE_IP_MFC 0x1092c
+#define GATE_IP_G3D0x10930
#define GATE_IP_GEN 0x10934
#define GATE_IP_FSYS 0x10944
#define GATE_IP_PERIC 0x10950
@@ -100,6 +102,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_CPU0,
SRC_CORE1,
SRC_TOP0,
+ SRC_TOP1,
SRC_TOP2,
SRC_TOP3,
SRC_GSCL,
Shouldn't GATE_IP_G3D be added to the list as well?
@@ -189,10 +192,12 @@ PNAME(mout_vpllsrc_p) = { fin_pll, sclk_hdmi27m };
PNAME(mout_vpll_p)= { mout_vpllsrc, fout_vpll };
PNAME(mout_cpll_p)= { fin_pll, fout_cpll };
PNAME(mout_epll_p)= { fin_pll, fout_epll };
+PNAME(mout_gpll_p) = { fin_pll, fout_gpll };
PNAME(mout_mpll_user_p) = { fin_pll, mout_mpll };
PNAME(mout_bpll_user_p) = { fin_pll, mout_bpll };
PNAME(mout_aclk166_p) = { mout_cpll, mout_mpll_user };
PNAME(mout_aclk200_p) = { mout_mpll_user, mout_bpll_user };
+PNAME(mout_aclk400_p) = { mout_aclk400_g3d_mid, mout_gpll };
PNAME(mout_aclk200_sub_p) = { fin_pll, div_aclk200 };
PNAME(mout_aclk266_sub_p) = { fin_pll, div_aclk266 };
PNAME(mout_aclk333_sub_p) = { fin_pll, div_aclk333 };
@@ -273,12 +278,16 @@ static struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = {
MUX(0, mout_aclk166, mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, mout_aclk200, mout_aclk200_p, SRC_TOP0, 12, 1),
MUX(0, mout_aclk333, mout_aclk166_p, SRC_TOP0, 16, 1),
+ MUX(0, mout_aclk400_g3d_mid, mout_aclk200_p, SRC_TOP0, 20, 1),
+
+ MUX(0, mout_aclk400_g3d, mout_aclk400_p, SRC_TOP1, 28, 1),
MUX(0, mout_cpll, mout_cpll_p, SRC_TOP2, 8, 1),
MUX(0, mout_epll, mout_epll_p, SRC_TOP2, 12, 1),
MUX(0, mout_vpll, mout_vpll_p, SRC_TOP2, 16, 1),
MUX(0, mout_mpll_user, mout_mpll_user_p, SRC_TOP2, 20, 1),
MUX(0, mout_bpll_user, mout_bpll_user_p, SRC_TOP2, 24, 1),
+ MUX(CLK_MOUT_GPLL, mout_gpll, mout_gpll_p, SRC_TOP2, 28, 1),
MUX(0, mout_aclk200_disp1_sub, mout_aclk200_sub_p, SRC_TOP3, 4, 1),
MUX(0, mout_aclk266_gscl_sub, mout_aclk266_sub_p, SRC_TOP3, 8, 1),
@@ -326,6 +335,7 @@ static struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = {
MUX(0, mout_mpll_fout, mout_mpll_fout_p, PLL_DIV2_SEL, 4, 1),
MUX(0, mout_bpll_fout, mout_bpll_fout_p, PLL_DIV2_SEL, 0, 1),
+
nit: Stray blank line.
};
static struct samsung_div_clock exynos5250_div_clks[] __initdata = {
@@ -351,6 +361,8 @@ static struct samsung_div_clock exynos5250_div_clks[]
__initdata = {
DIV(0, div_aclk200, mout_aclk200, DIV_TOP0, 12, 3),
DIV(0, div_aclk266, mout_mpll_user, DIV_TOP0, 16, 3),
DIV(0, div_aclk333, mout_aclk333, DIV_TOP0, 20, 3),
+ DIV(0, div_aclk400_g3d, mout_aclk400_g3d, DIV_TOP0,
+ 24, 3),
DIV(0, div_aclk66_pre, mout_mpll_user, DIV_TOP1, 24, 3),
@@ -615,6 +627,8 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
GATE(CLK_WDT, wdt, div_aclk66, GATE_IP_PERIS, 19, 0, 0),
GATE(CLK_RTC, rtc, div_aclk66, GATE_IP_PERIS, 20, 0, 0),
Re: [PATCH 1/4] ARM: dts: exynos4: add PMU syscon node
Hi Vikas,
On 25.04.2014 10:05, Vikas Sajjan wrote:
Hi,
On Thu, Apr 24, 2014 at 9:37 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Chanho,
On 14.04.2014 14:48, Chanho Park wrote:
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};
+ pmu_reg: syscon@1002 {
+ compatible = samsung,exynos4-pmureg, syscon;
Assume a case where exynos PMU is made as platform driver [1] and we
need use the compatible samsung,exynos4-pmureg in the driver.
But since syscon driver uses compatible syscon and once the syscon
driver is probed, the exynos PMU platform driver [1] will NEVER be
probed.
So my question is, can we have 2 compatible strings for a DT node, and
both the compatible strings are used for probing purpose?
Recently I faced this issue on exynos5250, where i was testing PMU
driver [1] and I noticed that PMU driver [1] was NEVER probed, if I
enable syscon driver in menuconfig.
No, it is not possible to bind two drivers with different compatible
strings to the same node. Basically this is because only one platform
driver can be bound to particular platform device.
The rule is that the most specific compatible string (e.g. the first
from the left) that matches should be used, but I'm not sure if this is
implemented this way in Linux kernel, especially considering that a
platform driver usually probes when it is being registered. So we might
have a race here, which you can work around by making sure that your PMU
driver is always registered first (e.g. by lowering its initcall level).
Best regards,
Tomasz
--
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: [PATCHv2 1/4] ARM: dts: exynos4: add PMU syscon node
Hi Chanho, On 25.04.2014 08:59, Chanho Park wrote: This patch adds a PMU(Power Management Unit) syscon node. This should be required for USB Phy syscon regmap I/F. Cc: Kamil Debski k.deb...@samsung.com Signed-off-by: Chanho Park chanho61.p...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 2 ++ arch/arm/boot/dts/exynos4.dtsi| 5 + arch/arm/boot/dts/exynos4x12.dtsi | 4 3 files changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index f1f1552..e2797d1 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -2,6 +2,8 @@ SAMSUNG Exynos SoC series PMU Registers Properties: - compatible : should contain two values. First value must be one from following list: + - samsung,exynos4210-pmu - for Exynos4210 SoC, + - samsung,exynos4x12-pmu - for Exynos4212/4412 SoC, Actually there are differences between PMUs of 4212 and 4412 (mostly count of CPU-related registers), so they should have separate compatible strings. I have missed this in previous version of this patch, sorry. Best regards, Tomasz -- 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: [PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
Hi Chanwoo,
On 25.04.2014 03:16, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Cc: Arnd Bergmann a...@arndb.de
Cc: Marc Zynigier marc.zyng...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
*/
- asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
- if ((primary_part 0xfff0) == 0xc0f0)
+ primary_part = read_cpuid_part_number();
+
+ switch (primary_part) {
+ case ARM_CPU_PART_CORTEX_A7:
+ case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
- else
+ break;
+ default:
cpu_enter_lowpower_a9();
+ break;
+ }
platform_do_lowpower(cpu, spurious);
I have noticed Leela Krishna Amudala's patch [1] that removes this
distinction completely and simply uses generic code. Could you check if
this works on Exynos3250 as well? If yes, then this patch could be
dropped and Leela's one would be enough.
[1]
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29064.html
Best regards,
Tomasz
--
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: [PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
On Sat, Apr 26, 2014 at 02:25:03AM +0200, Tomasz Figa wrote:
On 25.04.2014 03:16, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own
ID
from Main ID register.
Cc: Arnd Bergmann a...@arndb.de
Cc: Marc Zynigier marc.zyng...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
- * we're ready for shutdown now, so do it.
- * Exynos4 is A9 based while Exynos5 is A15; check the CPU part
- * number by reading the Main ID register and then perform the
- * appropriate sequence for entering low power.
+ * Prepare the CPU for shutting down. The required sequence of
+ * operations depends on core type. CPUID part number can be used to
+ * determine the right way.
*/
-asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
-if ((primary_part 0xfff0) == 0xc0f0)
+primary_part = read_cpuid_part_number();
+
+switch (primary_part) {
+case ARM_CPU_PART_CORTEX_A7:
+case ARM_CPU_PART_CORTEX_A15:
Although I believe we're approaching the point where everyone just uses
ARM Ltd designed CPUs, it should be remembered that the part number
field is designer specific, so if we were being strict, we'd check both
the part number and the designer fields together.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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: [PATCHv4 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7 dual cores and has a target speed of 1.0GHz. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/Kconfig | 22 ++ arch/arm/mach-exynos/exynos.c| 2 ++ arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ 3 files changed, 34 insertions(+) You can add my Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: From: Tomasz Figa t.f...@samsung.com This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR In original driver present in our internal tree I have separated several CMUs to account for certain factors caused by hardware design, which require such separation. Is there any reason why they were merged together into a single CMU again? Cc: Mike Turquette mturque...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Karol Wrona k.wr...@samsung.com Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h +#include linux/of.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/syscore_ops.h + +#include dt-bindings/clock/exynos3250.h + +#include clk.h +#include clk-pll.h + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564
Re: [PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT
Hi Tomasz, On Sat, Apr 26, 2014 at 7:43 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Pankaj, Just a small note - please refrain from sending next versions of series in reply to previous version. With threading applied, it gets hard to notice that a new version was posted, because the first message of the thread is always v1. Also it makes threads unnecessarily long. OK. I will take care in future. Best regards, Tomasz On 25.04.2014 14:32, Pankaj Dubey wrote: This patch series, does some minor cleanup and modifies Exynos PMU related code for mapping and initialization of Exynos Power Management Unit (PMU) base address from device tree. This is also preparation for moving PMU related code out of machine folder and moving into a drivers/mfd, so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos4210, Exynos4212 and Exynos4412 dtsi files, which has been posted as separate patch series [2] These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch. These patches depends on following two patch series: 1) mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 2) Add PMU node for Exynos SoCs http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html We have tested these patches on SMDK5250 and Arndale (Exynos5250) boards for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey pankaj.du...@samsung.com Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: Make exynos machine_ops as static. For making more cleanup in mach-exynos/common.h as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning mach-exynos/common.h. - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under mach-exynos. Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of exynos_pmu_base, as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that early_syscon_init requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as smp_secondary_init will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove linux/bug.h from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to drivers/mfd folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as samsung, exynosxxx-pmu, syscon, once we enable MFD_SYSCON config option, current syscon driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using syscon_early_regmap_lookup_by_phandle. If there is any better solution please suggest. Pankaj Dubey (6): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Cleanup mach-exynos/common.h file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c ARM: EXYNOS: Add device tree based initialization support for PMU. Young-Gun Jang (4): ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Remove linux/bug.h from pmu.c arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/common.h | 13 +- arch/arm/mach-exynos/cpuidle.c | 37 +-
Re: [PATCH 1/4] ARM: dts: exynos4: add PMU syscon node
Hi Tomasz,
On Sat, Apr 26, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
On 25.04.2014 10:05, Vikas Sajjan wrote:
Hi,
On Thu, Apr 24, 2014 at 9:37 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Chanho,
On 14.04.2014 14:48, Chanho Park wrote:
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};
+ pmu_reg: syscon@1002 {
+ compatible = samsung,exynos4-pmureg, syscon;
Assume a case where exynos PMU is made as platform driver [1] and we
need use the compatible samsung,exynos4-pmureg in the driver.
But since syscon driver uses compatible syscon and once the syscon
driver is probed, the exynos PMU platform driver [1] will NEVER be
probed.
So my question is, can we have 2 compatible strings for a DT node, and
both the compatible strings are used for probing purpose?
Recently I faced this issue on exynos5250, where i was testing PMU
driver [1] and I noticed that PMU driver [1] was NEVER probed, if I
enable syscon driver in menuconfig.
No, it is not possible to bind two drivers with different compatible strings
to the same node. Basically this is because only one platform driver can be
bound to particular platform device.
Yes, correct.
The rule is that the most specific compatible string (e.g. the first from
the left) that matches should be used, but I'm not sure if this is
implemented this way in Linux kernel, especially considering that a platform
driver usually probes when it is being registered. So we might have a race
here, which you can work around by making sure that your PMU driver is
always registered first (e.g. by lowering its initcall level).
I don't see it's using first compatible string from the left. I can
see whichever driver registers platform driver first, it's probe is
getting called. As in this particular case, PMU has two compatibility
string as samsung, exynosxxx-pmu, syscon. But since syscon
driver registers it's platform driver in postcore_initcall where as
PMU platform driver [1], was registering as arch_initcall, only
syscon probe got called.
In my V2 patch for converting PMU as driver form, I dropped idea of
converting into platform driver, because we can't remove syscon from
binding as many other driver wants to access PMU register via regmap
handle. By lowering it's initcall level may be I can make PMU probe
gets called but then how other drivers will be able to access PMU
regmap handles?
Best regards,
Tomasz
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 08/10] ARM: EXYNOS: Refactored code for using PMU address via DT
Hi Tomasz,
Thanks for review.
On Sat, Apr 26, 2014 at 7:19 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
Under arm/mach-exynos many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc.
Let's convert all these access using either of get_exynos_pmuaddr
or get_exynos_regmap.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to driver
folder which can be reused for ARM64 bsed SoC.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h |4 +-
arch/arm/mach-exynos/cpuidle.c | 37 ++-
arch/arm/mach-exynos/exynos.c | 19 +-
arch/arm/mach-exynos/hotplug.c |4 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/platsmp.c | 13 +-
arch/arm/mach-exynos/pm.c | 60 ++--
arch/arm/mach-exynos/pmu.c | 40 +--
arch/arm/mach-exynos/regs-pmu.h | 506
+++
9 files changed, 348 insertions(+), 338 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ecfd0fc..ad5128e 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -40,7 +40,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END 0x
IMHO (-1U) would be more appropriate.
OK.
enum sys_powerdown {
SYS_AFTR,
@@ -51,7 +51,7 @@ enum sys_powerdown {
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
diff --git a/arch/arm/mach-exynos/cpuidle.c
b/arch/arm/mach-exynos/cpuidle.c
index c57cae0..5dcdd46 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/time.h
#include linux/platform_device.h
+#include linux/regmap.h
#include asm/proc-fns.h
#include asm/smp_scu.h
@@ -34,10 +35,10 @@
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0
? \
- (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+ 0x24 : S5P_INFORM0))
#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0
? \
- (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+ 0x20 : S5P_INFORM1))
This patch seems to be based on old code, before Daniel Lezcano's Exynos
cpuidle refactor [1] and it should be rebased on top of that series.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085
OK, I will rebase on top of it along with addressing all other review comments.
#define S5P_CHECK_AFTR0xFCBA0D10
@@ -60,6 +61,8 @@
#define PWR_CTRL2_CORE2_UP_RATIO (1 4)
#define PWR_CTRL2_CORE1_UP_RATIO (1 0)
+static struct regmap *pmu_regmap;
+
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
@@ -87,7 +90,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos4_set_wakeupmask(void)
{
- __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+ regmap_write(pmu_regmap, S5P_WAKEUP_MASK, 0xff3e);
}
static unsigned int g_pwr_ctrl, g_diag_reg;
@@ -120,22 +123,28 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- unsigned long tmp;
+ unsigned int tmp;
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
exynos_sys_powerdown_conf(SYS_AFTR);
-
- __raw_writel(virt_to_phys(exynos_cpu_resume), REG_DIRECTGO_ADDR);
- __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
-
+
+ if (samsung_rev() == EXYNOS4210_REV_1_0) {
+ __raw_writel(virt_to_phys(exynos_cpu_resume),
+ S5P_VA_SYSRAM + REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, S5P_VA_SYSRAM +
REG_DIRECTGO_FLAG);
+ } else {
+ regmap_write(pmu_regmap, REG_DIRECTGO_ADDR,
+ virt_to_phys(exynos_cpu_resume));
+ regmap_write(pmu_regmap, REG_DIRECTGO_FLAG,
S5P_CHECK_AFTR);
+ }
Re: [PATCH v2 05/10] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
HI Tomasz, On Sat, Apr 26, 2014 at 6:19 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi, On 25.04.2014 14:32, Pankaj Dubey wrote: From: Young-Gun Jang yg1004.j...@samsung.com Current pm_domain.c file uses S5P_INT_LOCAL_PWR_EN definition from regs-pmu.h and hence needs to include this header file. As there is no other user of S5P_INT_LOCAL_PWR_EN definition other than pm_domain, to remove regs-pmu.h header file dependency from pm_domain.c it's better we define this definition in pm_domain.c file itself and thus it will help in removing header file inclusion from pm_domain.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com --- arch/arm/mach-exynos/pm_domains.c |2 +- arch/arm/mach-exynos/regs-pmu.h |1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index fe6570e..f676b0a 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -22,7 +22,7 @@ #include linux/of_platform.h #include linux/sched.h -#include regs-pmu.h +#define S5P_INT_LOCAL_PWR_EN 0x7 nit: You could indent the value a bit more in case of adding any new macros in future. While at it, you could probably also drop the S5P_ prefix. Thanks for review. Will take care of both suggestions. Thanks, Pankaj Dubey With these fixed, feel free to add my Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 -- 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 10/10] ARM: EXYNOS: Add device tree based initialization support for PMU.
HI Tomasz,
Thanks for review.
On Sat, Apr 26, 2014 at 7:40 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
This patch adds device tree based initialization for PMU and modifies
PMU initialization implementation in following way:
1: Let's initialize PMU based on device tree compatibility string.
2: Obtain PMU regmap handle using syscon_early_regmap_lookup_by_phandle
so that we can reduce dependency over machine header files.
3: Separate each SoC's PMU initialization function and bind this
initialization
function with PMU compatibility string.
4 : It also removes uses of soc_is_exynos() thus making PMU
implementation
independent of plat/cpu.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
---
arch/arm/mach-exynos/pmu.c | 182
+---
1 file changed, 138 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..abcf753 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -9,17 +9,31 @@
* published by the Free Software Foundation.
*/
-#include linux/io.h
#include linux/kernel.h
#include linux/regmap.h
-
-#include plat/cpu.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
+enum exynos_pmu_id {
+ PMU_EXYNOS4210,
+ PMU_EXYNOS4X12,
+ PMU_EXYNOS4412,
+ PMU_EXYNOS5250,
+};
+
+struct exynos_pmu_data {
+ enum exynos_pmu_id pmu_id;
+ struct regmap *pmu_regmap;
Again, since this uses the PMU node directly and doesn't seem to access any
registers shared with other drivers (or at least not at the time most the
functions from this file are called) I don't think there is any reason why
not to use of_iomap() and access the registers directly.
Regarding using PMU base address as regmap handle or base address I
have replied to your comments in this thread [1], so let's decide
which way is the best. So I will update accordingly.
[1]: https://lkml.org/lkml/2014/4/25/751
What about adding more fields to this struct? For example .pmu_config,
.pmu_config_extra (for model-specific settings, like for Exynos4412, see my
comment below) and (*pmu_init)? Of course the regmap (or base address) would
have to be moved outside, as it isn't const data.
Then for each PMU variant there would be a static const struct will all
those fields already filled in and entries in OF match table would already
point to appropriate structure.
Thanks for suggestion. I will take care in next version.
+};
+
+struct exynos_pmu_data *pmu_data;
static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+typedef void (*exynos_pmu_init_t)(void);
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .reg = address, .val = { AFTR, LPA, SLEEP } */
@@ -348,28 +362,31 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i],
tmp);
+ regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i],
tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION,
tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_data-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION,
tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
- tmp = regmap_read(pmu_regmap,
exynos5_list_diable_wfi_wfe[i],
- tmp);
+ tmp = regmap_read(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
tmp = ~(EXYNOS5_OPTION_USE_STANDBYWFE |
EXYNOS5_OPTION_USE_STANDBYWFI);
- regmap_write(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
tmp);
+ regmap_write(pmu_data-pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
}
}
@@ -377,52 +394,129 @@ void exynos_sys_powerdown_conf(enum
Re: [PATCH v2 01/10] ARM: EXYNOS: Make exynos machine_ops as static
HI Tomasz,
Thanks for review and suggestions.
On Sat, Apr 26, 2014 at 6:05 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Pankaj,
On 25.04.2014 14:32, Pankaj Dubey wrote:
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..2388ee4 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -235,7 +235,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -296,7 +296,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc,
ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
This patch seems to be irrelevant to the rest of this series. Anyway, the
changes itself are fine, except that I can see more functions that could be
made static as well:
- exynos_cpuidle_init(),
- exynos_cpufreq_init().
In fact, they both could be probably eliminated, as they are just oneliners
doing things that could be done in exynos_dt_machine_init() directly.
So, if you are doing this kind of cleanup, you could do this as well and
probably also replace platform_device + platform_device_register() with
platform_device_register_simple() for cpuidle, to reduce line count and make
it consistent with cpufreq.
OK, I will take care of this.
Also will separate these patches from PMU series.
Thanks,
Pankaj Dubey
Best regards,
Tomasz
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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
