[PATCH 1/4 v2] devicetree: bindings: Document murata vendor prefix
Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Acked-by: Mark Rutland mark.rutl...@arm.com Cc: Guenter Roeck li...@roeck-us.net --- Changes since v1: 1. Rearranged vendor-prefix alphabetically 2. Added Acked-by from Mark Rutland .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4d7f375..46a311e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -83,6 +83,7 @@ mosaixtechMosaix Technologies, Inc. moxa Moxa mplMPL AG mundoreaderMundo Reader S.L. +murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. national National Semiconductor neonodeNeonode Inc. -- 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 4/4 v2] ARM: DTS: Add NTC thermistor nodes to Exynos5420 based Peach_PIT
Exynos5420 based Peach PIT board has 4 NTC thermistors to measure
temperatures at various points on the board.
IIO based ADC becomes the parent and NTC thermistors are the childs,
via the HWMON interface.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Doug Anderson diand...@chromium.org
---
Changes since v1:
1. Arranged the ADC node alphabetical
2. Added status = okay to the ADC node
This patch needs
1. MAX77802 PMIC device tree nodes (for ldo9)
https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
This patch set is tested
1. On Peach PIT board via sysfs entry exposed by hwmon
localhost ~ # cat /sys/class/hwmon/hwmon*/device/temp1_input
37436
36449
38560
38059
2. Backward compatibility is tested by replacing murata with ntc
in the dts nodes and running the above test.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index b96a66a..19d733d 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -101,6 +101,40 @@
};
};
+adc {
+ status = okay;
+ vdd-supply = ldo9_reg;
+
+ ncp15wb473@3 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 3;
+ };
+ ncp15wb473@4 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 4;
+ };
+ ncp15wb473@5 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 5;
+ };
+ ncp15wb473@6 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 6;
+ };
+};
+
dp {
status = okay;
pinctrl-names = default;
--
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/4 v2] ARM: DTS: use new compatible string for thermistors in trats2
As Murata Manufactures the NTC based thermistors. The vendor
name in the compatibility is preposed to change to murata
This patch uses the new compatibility string in exynos4412 based
Trats2 board.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
---
Changes since v1:
None
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
thermistor-ap@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
@@ -779,7 +779,7 @@
};
thermistor-battery@1 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
--
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/4 v2] hwmon: ntc_thermistor: Use the manufacturer name properly
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Note: Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
Changes since v1:
1. Kept the old compatible string marked as DEPRECATED in code and
in the Documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 20 ++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 14 +-
5 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..b117b2e 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
+
+/* Usage of vendor name ntc is deprecated */
+DEPRECATED ntc,ncp15wb473
+DEPRECATED ntc,ncp18wb473
+DEPRECATED ntc,ncp21wb473
+DEPRECATED ntc,ncp03wb473
+DEPRECATED ntc,ncp15wl333
+
- pullup-uv Pull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +29,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config SENSORS_NTC_THERMISTOR
- tristate NTC thermistor support
+ tristate NTC thermistor support from Murata
depends on !OF || IIO=n || IIO
help
This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
send notifications about the temperature.
Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333.
+ NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333
+ from Murata.
This driver can also be built as a module. If so, the module
will be called ntc-thermistor.
diff --git a/drivers/hwmon/ntc_thermistor.c
Re: [PATCH 3/4 v2] ARM: DTS: use new compatible string for thermistors in trats2
On 06/25/2014 03:29 PM, Naveen Krishna Chatradhi wrote:
As Murata Manufactures the NTC based thermistors. The vendor
name in the compatibility is preposed to change to murata
This patch uses the new compatibility string in exynos4412 based
Trats2 board.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
---
Changes since v1:
None
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
thermistor-ap@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
@@ -779,7 +779,7 @@
};
thermistor-battery@1 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
Looks good to me.
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
--
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/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
Hello Naveen, On Wed, Jun 25, 2014 at 7:04 AM, Naveen Krishna Ch naveenkrishna...@gmail.com wrote: Doug, On 25 June 2014 03:24, Doug Anderson diand...@chromium.org wrote: Naveen, On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Exynos5420 based Peach PIT and Exynos5800 based PI boards have 4 NTC thermistors to measure temperatures at various points on the board. IIO based ADC becomes the parent and NTC thermistors are the childs, via the HWMON interface. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Doug Anderson diand...@chromium.org --- This patch needs 1. MAX77802 PMIC device tree nodes (for ldo9) https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix arch/arm/boot/dts/exynos5420-peach-pit.dts | 32 1 file changed, 32 insertions(+) * You forgot: status=okay for the ADC. One might question how this patch was tested. Will correct it. * Please also include this change for pi. MAX77802 device node was not added for Peach_PI (exynos5800-peach-pi.dts). I guess, Javier have a plan to send. That's correct. I didn't include the changes to Peach Pi since I only have a Pit to test but I'll add it on the next version so you can have that patch as a dependency and use the MAX77802 LD9 regulator. I will edit the commit message to remove Peach_PI for now. Also, we have few similar nodes on Peach PI and Peach PIT. Any plans or discussion on merging the common nodes ? * We just got through the painful process of sorting this .dts file. Please sort adc alphabetically. Kukjin: please confirm that you will keep an eye on patches and make sure that they are sorted OK. Other than those problems this seems to work fine to me. -Doug Thanks for the Review. -- Shine bright, (: Nav :) Best regards, Javier -- 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 sob, 2014-06-14 at 00:43 +0200, Daniel Lezcano wrote: On 06/11/2014 10:50 AM, Krzysztof Kozlowski wrote: (...) Hi, Shouldn't the exynos_idle_barrier be initialized here? As it is a static data it will be initialized to zero. I know you sent the patch almost 2 months ago but I stomped on this while testing it on Exynos3250. No problem. And what results on exynos3250 ? I had to change some of the ways for synchronization two cores (boot vector behaves differently) so actually the driver is different except the general idea. As for the results (on dual-core Exynos3250) - the mode (AFTR+CPU1 off) consumes about 5% less energy than idle-WFI state. I expect there will be much more savings in deeper mode (called here W-AFTR). Best regards, Krzysztof -- 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] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Tue, Jun 24, 2014 at 4:35 PM, Kamil Debski k.deb...@samsung.com wrote: By reboot I guess that you mean typing reboot or by using SysRq magic and not power cycling? If so, I had experienced the same symptoms. I guess that the Ethernet chip is not reset properly and fails to enumerate without power cycling (it's nRESET pin is connected to P3V3). I found that removing regulator-always-on from buck8_reg: BUCK8 in the dts file fixes this problem. Yes, that fixes the problem. Thanks! Tested-by: Daniel Drake dr...@endlessm.com -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add support for Exynos clock output configuration
Hi, On Tue, Jun 24, 2014 at 5:08 PM, Tomasz Figa t.f...@samsung.com wrote: Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. for all the patches: Tested-by: Daniel Drake dr...@endlessm.com Tested on ODROID-U2 alongside phy: phy-samsung-usb2: Change phy power on/power off sequence now USB is working fine. Thanks! Daniel -- 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] devicetree: Add generic IOMMU device tree bindings
On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote: On Tuesday 24 June 2014 19:11:50 Will Deacon wrote: On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote: We do describe the masked StreamID (SID) but we need to specify the mask that the SMMU should apply to the incoming SIDs, right? We have a bus master that emits 43 unique SIDs. However, we have only 40 SMMU_SMRn registers in the SMMU. So we need to mask out some of the incoming SID bits so that the 43 SIDs can match one of 40 entries in the SMR. Hmm, so you're talking about stream matching, right? That doesn't belong in the device-tree. I appreciate that the current driver does a terrible job at allocating the SMRs (it's bloody difficult!), but we should try to improve the dynamic behaviour instead of moving configuration of the SMMU out into device-tree, where it's inflexible at best. There have been patches previously posted by Andreas Herrmann helping here. I'd be glad to see them revived. Note that there are areas where we have in the past decided that dynamic configuration is just too hard for the kernel to do and that we're better off putting the configuration into DT. Pinctrl and clocks are at least partially in that category. It's always best if you can get the kernel to do things in the ideal way where that is possible, but getting there may be just not worth it. I have no idea where it should be for SMMU, but it's something to consider: if you can take reasonable shortcuts by reading parts of the configuration from DT, you may just as well do that. I treat this in the same manner as the topology bindings we discussed previously; we should do a best-effort to configure things dynamically and solve corner-cases and quirks as special cases. Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Tue, Jun 24, 2014 at 10:35:54PM +0100, Olav Haugan wrote:
On 6/24/2014 11:11 AM, Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:
iommu {
#address-cells = 2;
#size-cells = 0;
};
master@a {
...
iommus = iommu StreamID0 MASK0,
iommu StreamID1 MASK1,
iommu StreamID2 MASK2;
};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?
We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.
I am talking about SMMU_SMRn[MASK] register bits. This is not something
that can be dynamically detected at run-time. It is configuration at the
same level as the actual StreamIDs.
Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
hardware (from the SMMU architecture perspective), the SMRs are completely
programmable. Why doesn't something like Andreas's proposal work for you?
The idea there was to find the constant bits among the StreamIDs for a
master and create the mask accordingly.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wednesday 25 June 2014 10:17:02 Will Deacon wrote: On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote: On Tuesday 24 June 2014 19:11:50 Will Deacon wrote: On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote: We do describe the masked StreamID (SID) but we need to specify the mask that the SMMU should apply to the incoming SIDs, right? We have a bus master that emits 43 unique SIDs. However, we have only 40 SMMU_SMRn registers in the SMMU. So we need to mask out some of the incoming SID bits so that the 43 SIDs can match one of 40 entries in the SMR. Hmm, so you're talking about stream matching, right? That doesn't belong in the device-tree. I appreciate that the current driver does a terrible job at allocating the SMRs (it's bloody difficult!), but we should try to improve the dynamic behaviour instead of moving configuration of the SMMU out into device-tree, where it's inflexible at best. There have been patches previously posted by Andreas Herrmann helping here. I'd be glad to see them revived. Note that there are areas where we have in the past decided that dynamic configuration is just too hard for the kernel to do and that we're better off putting the configuration into DT. Pinctrl and clocks are at least partially in that category. It's always best if you can get the kernel to do things in the ideal way where that is possible, but getting there may be just not worth it. I have no idea where it should be for SMMU, but it's something to consider: if you can take reasonable shortcuts by reading parts of the configuration from DT, you may just as well do that. I treat this in the same manner as the topology bindings we discussed previously; we should do a best-effort to configure things dynamically and solve corner-cases and quirks as special cases. I think the situation is a bit different here: It's less about the corner cases for the SMMU, but about the question whether it makes more sense to have the kernel figure out the settings, or have them come from DT all the time. As I said, I can't tell which approach is best here, but it sounds to me we should either do dynamic configuration and get it right, or hardcode the configuration it all the time if we can't. Arnd -- 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] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote: On Wednesday 25 June 2014 10:17:02 Will Deacon wrote: On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote: On Tuesday 24 June 2014 19:11:50 Will Deacon wrote: On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote: We do describe the masked StreamID (SID) but we need to specify the mask that the SMMU should apply to the incoming SIDs, right? We have a bus master that emits 43 unique SIDs. However, we have only 40 SMMU_SMRn registers in the SMMU. So we need to mask out some of the incoming SID bits so that the 43 SIDs can match one of 40 entries in the SMR. Hmm, so you're talking about stream matching, right? That doesn't belong in the device-tree. I appreciate that the current driver does a terrible job at allocating the SMRs (it's bloody difficult!), but we should try to improve the dynamic behaviour instead of moving configuration of the SMMU out into device-tree, where it's inflexible at best. There have been patches previously posted by Andreas Herrmann helping here. I'd be glad to see them revived. Note that there are areas where we have in the past decided that dynamic configuration is just too hard for the kernel to do and that we're better off putting the configuration into DT. Pinctrl and clocks are at least partially in that category. It's always best if you can get the kernel to do things in the ideal way where that is possible, but getting there may be just not worth it. I have no idea where it should be for SMMU, but it's something to consider: if you can take reasonable shortcuts by reading parts of the configuration from DT, you may just as well do that. I treat this in the same manner as the topology bindings we discussed previously; we should do a best-effort to configure things dynamically and solve corner-cases and quirks as special cases. I think the situation is a bit different here: It's less about the corner cases for the SMMU, but about the question whether it makes more sense to have the kernel figure out the settings, or have them come from DT all the time. But, as far as I can tell, this setting is basically `which bits are constant among this set of IDs'. As I said, I can't tell which approach is best here, but it sounds to me we should either do dynamic configuration and get it right, or hardcode the configuration it all the time if we can't. I disagree. If you have `sensible' StreamID allocations, doing this dynamically should be straight-forward and gives the driver more flexibility (e.g. we then have the option of combining SMR entries for different masters if they are in the same domain). The dynamic approach also lends itself to sanity-checking (it is IMPLEMENTATION DEFINED whether the SMMU detects SMR aliases) and helps with virtualisation (forcing QEMU to generate these masks in a device-tree for a guest using a virtual SMMU interface is very painful). Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wednesday 25 June 2014 10:38:25 Will Deacon wrote: On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote: On Wednesday 25 June 2014 10:17:02 Will Deacon wrote: On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote: On Tuesday 24 June 2014 19:11:50 Will Deacon wrote: On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote: We do describe the masked StreamID (SID) but we need to specify the mask that the SMMU should apply to the incoming SIDs, right? We have a bus master that emits 43 unique SIDs. However, we have only 40 SMMU_SMRn registers in the SMMU. So we need to mask out some of the incoming SID bits so that the 43 SIDs can match one of 40 entries in the SMR. Hmm, so you're talking about stream matching, right? That doesn't belong in the device-tree. I appreciate that the current driver does a terrible job at allocating the SMRs (it's bloody difficult!), but we should try to improve the dynamic behaviour instead of moving configuration of the SMMU out into device-tree, where it's inflexible at best. There have been patches previously posted by Andreas Herrmann helping here. I'd be glad to see them revived. Note that there are areas where we have in the past decided that dynamic configuration is just too hard for the kernel to do and that we're better off putting the configuration into DT. Pinctrl and clocks are at least partially in that category. It's always best if you can get the kernel to do things in the ideal way where that is possible, but getting there may be just not worth it. I have no idea where it should be for SMMU, but it's something to consider: if you can take reasonable shortcuts by reading parts of the configuration from DT, you may just as well do that. I treat this in the same manner as the topology bindings we discussed previously; we should do a best-effort to configure things dynamically and solve corner-cases and quirks as special cases. I think the situation is a bit different here: It's less about the corner cases for the SMMU, but about the question whether it makes more sense to have the kernel figure out the settings, or have them come from DT all the time. But, as far as I can tell, this setting is basically `which bits are constant among this set of IDs'. As I said, I can't tell which approach is best here, but it sounds to me we should either do dynamic configuration and get it right, or hardcode the configuration it all the time if we can't. I disagree. If you have `sensible' StreamID allocations, doing this dynamically should be straight-forward and gives the driver more flexibility (e.g. we then have the option of combining SMR entries for different masters if they are in the same domain). The dynamic approach also lends itself to sanity-checking (it is IMPLEMENTATION DEFINED whether the SMMU detects SMR aliases) and helps with virtualisation (forcing QEMU to generate these masks in a device-tree for a guest using a virtual SMMU interface is very painful). In which case do you think hardcoding is needed then? I'm still confused why you think we need both, as your arguments seem to all be in favor of dynamic configuration. Arnd -- 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: update mmc node with hs-200 mode
This patch updates hs-200 device tree property from caps2-mmc-hs200-1.8v to mmc-hs200-1.8v for peach-pit and peach-pi boards. Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 1cf9df0..056a6fa 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -186,7 +186,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index 2c2c137..bb3ee76 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -171,7 +171,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; -- 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 v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 25, 2014 at 10:48:31AM +0100, Arnd Bergmann wrote: On Wednesday 25 June 2014 10:38:25 Will Deacon wrote: On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote: I think the situation is a bit different here: It's less about the corner cases for the SMMU, but about the question whether it makes more sense to have the kernel figure out the settings, or have them come from DT all the time. But, as far as I can tell, this setting is basically `which bits are constant among this set of IDs'. As I said, I can't tell which approach is best here, but it sounds to me we should either do dynamic configuration and get it right, or hardcode the configuration it all the time if we can't. I disagree. If you have `sensible' StreamID allocations, doing this dynamically should be straight-forward and gives the driver more flexibility (e.g. we then have the option of combining SMR entries for different masters if they are in the same domain). The dynamic approach also lends itself to sanity-checking (it is IMPLEMENTATION DEFINED whether the SMMU detects SMR aliases) and helps with virtualisation (forcing QEMU to generate these masks in a device-tree for a guest using a virtual SMMU interface is very painful). In which case do you think hardcoding is needed then? I'm still confused why you think we need both, as your arguments seem to all be in favor of dynamic configuration. So far, I've been avoiding the hardcoding. However, you could potentially build a system with a small number of SMRs (compared to the number of StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic configuration would be NP complete if we require an optimal SMR allocation. However: (1) I don't know of a system where this is the case (2) Not much work has been done on improving the dynamic allocator yet which is why I'm still favouring dynamic configuration in the driver. The other thing I forgot to mention earlier is that we need to support device hotplug in the future, so some level of dynamic configuration will always be required. Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] clk: samsung: exynos4: Remove SRC_MASK_ISP gates
Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote: ISP special clocks have dedicated gating registers and so MUX SRC_MASK register should not be used. This patch fixes the problem of Exynos4x12-based boards freezing on system suspend, because those mux outputs need not to be masked while suspending. Not sure if you will be interested in this, as your plate must be pretty full already, and I am probably the first person to try suspend/resume on ODROID, but: ODROID-U2 fails to suspend/resume. I am testing with rtcwake, trying to raise a wakeup alarm on the internal Exynos4412 RTC. For this, CONFIG_COMMON_CLK_MAX77686 must be disabled (otherwise it disables the upstream 32KHz clock source for the RTC), I also have CONFIG_RTC_DRV_MAX77686 disabled so that there is only one RTC to worry about. Then: rtcwake --utc -m mem -s 10 -v Before this patch, it would totally hang after calling cpu_suspend() (checked with S3C_PMDBG) - not sure if it hangs before sleeping, or if it sleeps but simply fails to wake up. With this patch, now it seems like the RTC alarm does wake up the system after the desired time, however it immediately goes back into uboot rather than resuming into Linux. So this patch does make some progress at least. The power light is on at all times during these tests (not sure if that means anything, but I was wondering if it should go out when the system suspends). Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system
On czw, 2014-06-19 at 20:20 +0200, Javier Martinez Canillas wrote:
From: Doug Anderson diand...@chromium.org
The max77686 includes an RTC that keeps power during suspend. It's
convenient to be able to use it as a wakeup source.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/rtc/rtc-max77686.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index d20a7f0..c1c6055 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -583,6 +583,33 @@ static void max77686_rtc_shutdown(struct platform_device
*pdev)
#endif /* MAX77686_RTC_WTSR_SMPL */
}
+#ifdef CONFIG_PM_SLEEP
+static int max77686_rtc_suspend(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return enable_irq_wake(info-virq);
+ }
+
+ return 0;
+}
+
+static int max77686_rtc_resume(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return disable_irq_wake(info-virq);
+ }
+
+ return 0;
+}
+#endif
Haven't you noticed un-acked interrupts after first resume? Does the
alarm IRQ works after first suspend-resume?
This happens quite often (at least on boards with max14577, max77836 and
s2m/s5m). The drivers implementing own irq_chip often just call irq
worker thread (see max77693_irq_resume [1]). With regmap_irq_chip you
can disable/enable the IRQ [2][3].
P.S. Sorry for late reply. I was on holidays.
[1] http://lxr.free-electrons.com/source/drivers/mfd/max77693-irq.c#L233
[2] http://lxr.free-electrons.com/source/drivers/mfd/max14577.c#L181
[2] http://lxr.free-electrons.com/source/drivers/mfd/sec-core.c#L444
Best regards,
Krzysztof
--
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/1] i2c: Kconfig: Enable HSI2C for Exynos5 platform
All Exynos5 platforms have HSI2C controllers and are needed by various IPs connected to the boards based on these SoCs. Thus select this by default for Exynos5 platforms. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Doug Anderson diand...@chromium.org --- drivers/i2c/busses/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9f7d5859cf65..c7918cffe790 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -465,9 +465,9 @@ config I2C_EG20T config I2C_EXYNOS5 tristate Exynos5 high-speed I2C driver depends on ARCH_EXYNOS5 OF + default y help - Say Y here to include support for high-speed I2C controller in the - Exynos5 based Samsung SoCs. + High-speed I2C controller on Exynos5 based Samsung SoCs. config I2C_GPIO tristate GPIO-based bitbanging I2C -- 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 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Testing against 3.16-rc2, this doesn't quite work for me. SAMSUNG_PM_DEBUG still doesn't appear in menuconfig. HAVE_SAMSUNG_PM_DEBUG is 'n'. Looks like the select from DEBUG_S3C_UART is not working, but I'm not sure why. Daniel -- 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] devicetree: Add generic IOMMU device tree bindings
On Wednesday 25 June 2014 10:57:36 Will Deacon wrote: So far, I've been avoiding the hardcoding. However, you could potentially build a system with a small number of SMRs (compared to the number of StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic configuration would be NP complete if we require an optimal SMR allocation. However: (1) I don't know of a system where this is the case (2) Not much work has been done on improving the dynamic allocator yet which is why I'm still favouring dynamic configuration in the driver. The other thing I forgot to mention earlier is that we need to support device hotplug in the future, so some level of dynamic configuration will always be required. Ok, got it. So we just hope that we can make dynamic configuration work all the time, but if it all fails, then we come up with a hardcoded configuration method. I guess this could be done similarly to how we handle clocks on a lot of systems: generally these are dynamic, but you have the option to provide hints in the clock controller node about how you expect things to be configured. For the SMMU that could mean that (if we get into the situation you describe), we add optional properties to the SMMU node itself describing how we expect the SMRs to be used. Arnd -- 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] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 25, 2014 at 11:12:13AM +0100, Arnd Bergmann wrote: On Wednesday 25 June 2014 10:57:36 Will Deacon wrote: So far, I've been avoiding the hardcoding. However, you could potentially build a system with a small number of SMRs (compared to the number of StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic configuration would be NP complete if we require an optimal SMR allocation. However: (1) I don't know of a system where this is the case (2) Not much work has been done on improving the dynamic allocator yet which is why I'm still favouring dynamic configuration in the driver. The other thing I forgot to mention earlier is that we need to support device hotplug in the future, so some level of dynamic configuration will always be required. Ok, got it. So we just hope that we can make dynamic configuration work all the time, but if it all fails, then we come up with a hardcoded configuration method. I guess this could be done similarly to how we handle clocks on a lot of systems: generally these are dynamic, but you have the option to provide hints in the clock controller node about how you expect things to be configured. For the SMMU that could mean that (if we get into the situation you describe), we add optional properties to the SMMU node itself describing how we expect the SMRs to be used. That sounds good to me! Thanks for the discussion. Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] arm: exynos: Support cluster power off on exynos5420/5800
Kevin Hilman wrote: Abhilash Kesavan a.kesa...@samsung.com writes: Hi, Turning off a cluster when all 4 cores of the cluster are powered off saves power significantly. Powering off the A15 L2 alone gives around 100mW in savings. Add support for powering off the A15/A7 clusters on exynos5420/5800. The patch enables specific register bits which ensure that: - cluster L2 will be turned on before the first man is powered up. - last man will be turned off before the cluster L2 is turned off. - core is powered down before powering it up. Remove the exynos_cluster_power_control function completely as we can rely on the above mentioned bits rather than polling the cluster power status register. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Acked-by: Nicolas Pitre n...@linaro.org --- Change in v2: Added a macro for the COMMON_OPTION register and used it in the MCPM back-end. The patch is based on Linux-next 20140619. It has been tested on an exynos5420-based chromebook using the /dev/bL_switcher interface as well as the script provided by Nicolas Pitre and Dave Martin [1]. Patch depends on: [v2] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start [1] http://www.spinics.net/lists/linux-samsung-soc/msg31257.html Tested on exynos5800/Chromebook2 along with the dependency patch and using the script from Dave and Nico. Tested-by: Kevin Hilman khil...@linaro.org Kevin, thanks for your test on the board ;-) Applied into samsung tree. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
On czw, 2014-06-19 at 20:20 +0200, Javier Martinez Canillas wrote:
This patch adds a dt-binding include for Maxim 77686
PMIC clock IDs that can be to be shared between the
clk-max77686 clock driver and DeviceTree source files.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/clk/clk-max77686.c | 7 +--
include/dt-bindings/clock/maxim,max77686.h | 23 +++
2 files changed, 24 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/clock/maxim,max77686.h
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index 3d7e8dd..185b611 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -30,12 +30,7 @@
#include linux/mutex.h
#include linux/clkdev.h
-enum {
- MAX77686_CLK_AP = 0,
- MAX77686_CLK_CP,
- MAX77686_CLK_PMIC,
- MAX77686_CLKS_NUM,
-};
+#include dt-bindings/clock/maxim,max77686.h
struct max77686_clk {
struct max77686_dev *iodev;
diff --git a/include/dt-bindings/clock/maxim,max77686.h
b/include/dt-bindings/clock/maxim,max77686.h
new file mode 100644
index 000..7b28b09
--- /dev/null
+++ b/include/dt-bindings/clock/maxim,max77686.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2014 Google, Inc
+ *
+ * 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.
+ *
+ * Device Tree binding constants clocks for the Maxim 77686 PMIC.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
+#define _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
+
+/* Fixed rate clocks. */
+
+#define MAX77686_CLK_AP 0
+#define MAX77686_CLK_CP 1
+#define MAX77686_CLK_PMIC2
+
+/* Total number of clocks. */
+#define MAX77686_CLKS_NUM(MAX77686_CLK_PMIC + 1)
+
+#endif /* _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/14] clk: max77686: Improve Maxim 77686 PMIC clocks binding
On czw, 2014-06-19 at 20:20 +0200, Javier Martinez Canillas wrote:
Like most clock drivers, the Maxim 77686 PMIC clock binding
follows the convention that the #clock-cells property is
used to specify the number of cells in a clock provider.
But the binding document is not clear enough that it shall
be set to 1 since the PMIC support multiple clocks outputs.
Also, explain that the clocks identifiers are defined in a
header file that can be included by Device Tree source with
client nodes to avoid using magic numbers.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/clock/maxim,max77686.txt | 15
++-
1 file changed, 10 insertions(+), 5 deletions(-)
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
index 96ce71b..8dea305 100644
--- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
+++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
@@ -9,13 +9,18 @@ The MAX77686 contains three 32.768khz clock outputs that
can be controlled
Following properties should be presend in main device node of the MFD chip.
Required properties:
-- #clock-cells: simple one-cell clock specifier format is used, where the
- only cell is used as an index of the clock inside the provider. Following
- indices are allowed:
+
+- #clock-cells: from common clock binding; shall be set to 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock,
- 2: 32khz_pmic clock.
+Clocks are defined as preprocessor macros in
dt-bindings/clock/maxim,max77686.h
+header and can be used in device tree sources.
+
Example: Node of the MFD chip
max77686: max77686@09 {
@@ -33,6 +38,6 @@ Example: Clock consumer node
foo@0 {
compatible = bar,foo;
/* ... */
- clock-names = my-clock;
- clocks = max77686 2;
+ clock-names = 32khz_pmic;
+ clocks = max77686 MAX77686_CLK_PMIC;
};
--
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/1] i2c: Kconfig: Enable HSI2C for Exynos5 platform
Sachin Kamat wrote: All Exynos5 platforms have HSI2C controllers and are needed by various IPs connected to the boards based on these SoCs. Thus select this by default for Exynos5 platforms. Yeah right, even upcoming exynos5 SoCs have only HS-I2C not I2C ;-) Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Doug Anderson diand...@chromium.org Acked-by: Kukjin Kim kgene@samsung.com Thanks, Kukjin --- drivers/i2c/busses/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9f7d5859cf65..c7918cffe790 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -465,9 +465,9 @@ config I2C_EG20T config I2C_EXYNOS5 tristate Exynos5 high-speed I2C driver depends on ARCH_EXYNOS5 OF + default y help - Say Y here to include support for high-speed I2C controller in the - Exynos5 based Samsung SoCs. + High-speed I2C controller on Exynos5 based Samsung SoCs. config I2C_GPIO tristate GPIO-based bitbanging I2C -- 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: update mmc node with hs-200 mode
Yuvaraj Kumar C D wrote: + Doug Hi, This patch updates hs-200 device tree property from caps2-mmc-hs200-1.8v to mmc-hs200-1.8v for peach-pit and peach-pi boards. Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com Already I've queued same patch into my local but waiting for dependencies for push to my tree in git.kernel.org: http://www.spinics.net/lists/arm-kernel/msg341198.html Thanks, Kukjin --- arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420- peach-pit.dts index 1cf9df0..056a6fa 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -186,7 +186,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800- peach-pi.dts index 2c2c137..bb3ee76 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -171,7 +171,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; -- 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 v3 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system
Hello Krzysztof,
On 06/25/2014 12:05 PM, Krzysztof Kozlowski wrote:
On czw, 2014-06-19 at 20:20 +0200, Javier Martinez Canillas wrote:
From: Doug Anderson diand...@chromium.org
The max77686 includes an RTC that keeps power during suspend. It's
convenient to be able to use it as a wakeup source.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/rtc/rtc-max77686.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index d20a7f0..c1c6055 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -583,6 +583,33 @@ static void max77686_rtc_shutdown(struct
platform_device *pdev)
#endif /* MAX77686_RTC_WTSR_SMPL */
}
+#ifdef CONFIG_PM_SLEEP
+static int max77686_rtc_suspend(struct device *dev)
+{
+if (device_may_wakeup(dev)) {
+struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+return enable_irq_wake(info-virq);
+}
+
+return 0;
+}
+
+static int max77686_rtc_resume(struct device *dev)
+{
+if (device_may_wakeup(dev)) {
+struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+return disable_irq_wake(info-virq);
+}
+
+return 0;
+}
+#endif
Haven't you noticed un-acked interrupts after first resume? Does the
alarm IRQ works after first suspend-resume?
This happens quite often (at least on boards with max14577, max77836 and
s2m/s5m). The drivers implementing own irq_chip often just call irq
worker thread (see max77693_irq_resume [1]). With regmap_irq_chip you
can disable/enable the IRQ [2][3].
Yes, the original Chrome OS 3.8 max77xxx also called the irq worker thread to
ack the interrupt.
So the real problem is that an interrupt occurs before the I2C bus controller is
resumed and so the interrupt handler is not able to access the registers over
I2C.
Doug posted the following patches [0,1] that AFAIU solves the issue by making
I2C controllers to be resumed in the noirq time to ensure that drivers will be
able to use the I2C bus to handler their wakeup.
In fact, Doug's original patch had this as a part of the commit message:
NOTE: due to wakeup ordering problems this patch alone doesn't work so
well on exynos5250-snow. You also need something that brings the i2c
bus up before the max77686 wakeup runs.
I removed that note since I (probably wrong) thought that he didn't mean it to
be part of the commit message but just was side information.
P.S. Sorry for late reply. I was on holidays.
No worries, thanks a lot for your feedback.
[1] http://lxr.free-electrons.com/source/drivers/mfd/max77693-irq.c#L233
[2] http://lxr.free-electrons.com/source/drivers/mfd/max14577.c#L181
[2] http://lxr.free-electrons.com/source/drivers/mfd/sec-core.c#L444
Best regards,
Krzysztof
Best regards,
Javier
[0]: https://patchwork.kernel.org/patch/4414851/
[1]: https://patchwork.kernel.org/patch/4414871/
--
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/4 v2] hwmon: ntc_thermistor: Use the manufacturer name properly
Hello Naveen,
On Wed, Jun 25, 2014 at 8:29 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Note: Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
Changes since v1:
1. Kept the old compatible string marked as DEPRECATED in code and
in the Documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 20
++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 14 +-
5 files changed, 35 insertions(+), 14 deletions(-)
Looks good to me.
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..b117b2e 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
+
+/* Usage of vendor name ntc is deprecated */
+DEPRECATED ntc,ncp15wb473
+DEPRECATED ntc,ncp18wb473
+DEPRECATED ntc,ncp21wb473
+DEPRECATED ntc,ncp03wb473
+DEPRECATED ntc,ncp15wl333
+
- pullup-uv Pull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +29,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config SENSORS_NTC_THERMISTOR
- tristate NTC thermistor support
+ tristate NTC thermistor support from Murata
depends on !OF || IIO=n || IIO
help
This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
send notifications about the temperature.
Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473,
RE: [PATCH v2 0/4] Add support for Exynos clock output configuration
Tomasz Figa wrote: Hi Tomasz, On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of internal SoC clocks to be output from the SoC. The hardware structure Yeah, because the CLKOUT pin is used for measure of the clock for debug on all of exynos SoCs commonly. of CLKOUT related clocks looks as follows: CMU |--- clock0 - | PMU | | | | several |--- clock1 - | mux | muxes | | + |--- CLKOUT dividers | ... | gate| and gates | | | |--- clockN - | | Since the block responsible for handling the pin is PMU, not CMU, a separate driver, that binds to PMU node is required and acquires all input clocks by standard DT clock look-up. This way we don't need any cross-IP block drivers and cross-driver register sharing or nodes for fake devices. BTW, upcoming exynos5 SoCs have two muxs for CLKOUT and each mux is controlled by CMU and PMU, so The mux1 for CLKOUT in CMU is used to decide which clock in each sub-domain will be out and the mux2 in PMU is used to decide which sub-domain will be out via CLKOUT. So I want you to consider of all of exynos SoCs including upcoming SoCs. Thanks, Kukjin To represent the PMU mux/gate clock, generic composite clock is registered. Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg333276.html) - rebased onto next-20140624, - fixed #clock-cells values in exynos5250.dtsi and exynos5420.dtsi, - temporarily removed ISP CLKOUT clocks on Exynos4x12, until ISP clock domain handling gets fixed in Exynos4 clock driver. Changes since RFC v1: (https://lkml.org/lkml/2014/5/15/506) - rebased onto v5 of Enable usbphy and hsotg for exynos4 series and current HEAD of samsung-clk tree, - added handling of suspend/resume in the driver, - added missing CPU clocks on Exynos4, - added CLK_SET_RATE_PARENT to CMU CLKOUT gates on Exynos4, - fixed bit field width on Exynos4, - added CLKOUT CMU registers of Exynos4 to save/restore list, - added CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT to clkout clock, - changed the binding to use 1-cell clock specifier to allow extension with further PMU clocks in future, if needed. Tomasz Figa (4): clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy clk: samsung: exynos4: Add CLKOUT clock hierarchy clk: samsung: Add driver to control CLKOUT line on Exynos SoCs ARM: dts: exynos: Update PMU node with CLKOUT related data .../devicetree/bindings/arm/samsung/pmu.txt| 30 arch/arm/boot/dts/exynos4210.dtsi | 10 ++ arch/arm/boot/dts/exynos4x12.dtsi | 7 + arch/arm/boot/dts/exynos5250.dtsi | 3 + arch/arm/boot/dts/exynos5420.dtsi | 3 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos-clkout.c| 153 +++ drivers/clk/samsung/clk-exynos4.c | 166 - include/dt-bindings/clock/exynos4.h| 5 + 9 files changed, 374 insertions(+), 4 deletions(-) create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c -- 1.9.3 -- 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/4 v2] ARM: DTS: Add NTC thermistor nodes to Exynos5420 based Peach_PIT
Hello Naveen,
On Wed, Jun 25, 2014 at 8:29 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
Exynos5420 based Peach PIT board has 4 NTC thermistors to measure
temperatures at various points on the board.
IIO based ADC becomes the parent and NTC thermistors are the childs,
via the HWMON interface.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Doug Anderson diand...@chromium.org
---
Changes since v1:
1. Arranged the ADC node alphabetical
2. Added status = okay to the ADC node
This patch needs
1. MAX77802 PMIC device tree nodes (for ldo9)
https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
This patch set is tested
1. On Peach PIT board via sysfs entry exposed by hwmon
localhost ~ # cat /sys/class/hwmon/hwmon*/device/temp1_input
37436
36449
38560
38059
2. Backward compatibility is tested by replacing murata with ntc
in the dts nodes and running the above test.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index b96a66a..19d733d 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -101,6 +101,40 @@
};
};
+adc {
+ status = okay;
+ vdd-supply = ldo9_reg;
+
+ ncp15wb473@3 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 3;
+ };
+ ncp15wb473@4 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 4;
+ };
+ ncp15wb473@5 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 5;
+ };
+ ncp15wb473@6 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 6;
+ };
+};
+
dp {
status = okay;
pinctrl-names = default;
--
1.7.9.5
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
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/arm64: DT: Fix GICv2 CPU interface size
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5410.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi| 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi| 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi| 2 +-
arch/arm/boot/dts/tegra114.dtsi | 2 +-
arch/arm/boot/dts/tegra124.dtsi | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm64/boot/dts/apm-storm.dtsi | 2 +-
arch/arm64/boot/dts/foundation-v8.dts | 2 +-
arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index ea288f0..40aacc9 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -62,7 +62,7 @@
#address-cells = 0;
interrupt-controller;
reg = 0x20 0x01001000 0 0x1000,
- 0x20 0x01002000 0 0x1000,
+ 0x20 0x01002000 0 0x2000,
0x20 0x01004000 0 0x2000,
0x20 0x01006000 0 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..65329ff 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -46,7 +46,7 @@
interrupt-controller;
#interrupt-cells = 3;
reg = 0x48211000 0x1000,
- 0x48212000 0x1000,
+ 0x48212000 0x2000,
0x48214000 0x2000,
0x48216000 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
index 2ccbb57f..c15e7e0 100644
--- a/arch/arm/boot/dts/ecx-2000.dts
+++ b/arch/arm/boot/dts/ecx-2000.dts
@@ -99,7 +99,7 @@
interrupt-controller;
interrupts = 1 9 0xf04;
reg = 0xfff11000 0x1000,
- 0xfff12000 0x1000,
+ 0xfff12000 0x2000,
0xfff14000 0x2000,
0xfff16000 0x2000;
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..bbd177a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -173,7 +173,7 @@
#interrupt-cells = 3;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000 0x2000;
interrupts = 1 9 0xf04;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..15fdc3b 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -44,7 +44,7 @@
#interrupt-cells = 3;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000 0x2000;
interrupts = 1 9 0xf04;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 5398a60..c0e2341 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -161,7 +161,7 @@
#size-cells = 0;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000
[PATCH 1/2] i2c: exynos5: remove an unnecessary read of FIFO_STATUS register
This patch removes an extra read of FIFO_STATUS register in the interrrupt
service routine. Which is read again before the actual use.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-exynos5.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..0d1a7bc 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -405,7 +405,6 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
int_status = readl(i2c-regs + HSI2C_INT_STATUS);
writel(int_status, i2c-regs + HSI2C_INT_STATUS);
- fifo_status = readl(i2c-regs + HSI2C_FIFO_STATUS);
/* handle interrupt related to the transfer status */
if (int_status HSI2C_INT_I2C) {
--
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/2] i2c: exynos5: fix minor styling nits
This patch removes an extra line and fixes a styling nit
in exynos5_i2c_message_start()
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-exynos5.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 0d1a7bc..4c2e6f3 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
if (i2c-msg-flags I2C_M_RD) {
i2c_ctl |= HSI2C_RXCHON;
- i2c_auto_conf = HSI2C_READ_WRITE;
+ i2c_auto_conf |= HSI2C_READ_WRITE;
trig_lvl = (i2c-msg-len i2c-variant-fifo_depth) ?
(i2c-variant-fifo_depth * 3 / 4) : i2c-msg-len;
@@ -548,7 +548,6 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
writel(fifo_ctl, i2c-regs + HSI2C_FIFO_CTL);
writel(i2c_ctl, i2c-regs + HSI2C_CTL);
-
/*
* Enable interrupts before starting the transfer so that we don't
* miss any INT_I2C interrupts.
--
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 2/4 v2] hwmon: ntc_thermistor: Use the manufacturer name properly
Hello Javier,
On 25 June 2014 16:06, Javier Martinez Canillas jav...@dowhile0.org wrote:
Hello Naveen,
On Wed, Jun 25, 2014 at 8:29 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Note: Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
Changes since v1:
1. Kept the old compatible string marked as DEPRECATED in code and
in the Documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 20
++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 14 +-
5 files changed, 35 insertions(+), 14 deletions(-)
Looks good to me.
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Thanks for the review.
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..b117b2e 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
+
+/* Usage of vendor name ntc is deprecated */
+DEPRECATED ntc,ncp15wb473
+DEPRECATED ntc,ncp18wb473
+DEPRECATED ntc,ncp21wb473
+DEPRECATED ntc,ncp03wb473
+DEPRECATED ntc,ncp15wl333
+
- pullup-uv Pull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +29,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config SENSORS_NTC_THERMISTOR
- tristate NTC thermistor support
+ tristate NTC thermistor support from Murata
depends on !OF || IIO=n || IIO
help
This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
send notifications about
Re: [PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer
Thanks Inki,
One more thing. mixer_layer_update is only called on for mixer version;
MXR_VER_16_0_33_0, MXR_VER_128_0_0_184. This condition
should have taken care of Exynos4 scenarios. What you say?
Regards,
Rahul Sharma.
On 24 June 2014 20:20, Inki Dae inki@samsung.com wrote:
2014-06-24 20:38 GMT+09:00 Andreas Färber afaer...@suse.de:
Am 24.06.2014 07:21, schrieb Inki Dae:
On 2014년 06월 23일 14:32, Rahul Sharma wrote:
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context
*ctx, int win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = ctx-mixer_res;
-u32 val;
-
-val = mixer_reg_read(res, MXR_CFG);
-/* allow one update per vsync only */
-if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
-mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
Rahul, it looks good to me and ok as is. But above codes don't consider
Exynos4 series. In case of Exynos4xxx SoC,
MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
register are reserved fields. So can you work that patch to be
considered for Exynos4xxx SoC? That patch would be additional one.
Anyway, will apply it as is, and I will wait for the additional patch.
If it's not too late, could you fix up multiple in the subject? :)
Corrected. :)
Thanks,
Inki Dae
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 3/4] Documentation: devicetree: Fix tps65090 typos
On Mon, Jun 23, 2014 at 06:27:04PM +0100, Doug Anderson wrote:
Andreas,
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.
Signed-off-by: Andreas Färber afaer...@suse.de
---
Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 34098023..ca69f5e 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = some_reg;
infet6-supply = some_reg;
infet7-supply = some_reg;
- vsys_l1-supply = some_reg;
- vsys_l2-supply = some_reg;
+ vsys-l1-supply = some_reg;
+ vsys-l2-supply = some_reg;
Your change matches the code and all existing device trees in the
Linux kernel.
Could this fact please be mentioned in the commit message?
Given that:
Acked-by: Mark Rutland mark.rutl...@arm.com
I also see plenty of other bindings with dashes, so this seems
reasonable.
Dashes rather than underscores are preferred/correct for property names
and compatible strings. Given no-one can possibly be using the
bad/incorrect form with underscores, fixing the documentation to use
dashes makes sense.
Thanks,
Mark.
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
On 05/31/2014 12:17 AM, Tomasz Figa wrote: On 30.05.2014 20:42, Kukjin Kim wrote: On 05/31/14 03:19, Andreas Färber wrote: Am 28.05.2014 06:13, schrieb Sachin Kamat: Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamatsachin.ka...@linaro.org Signed-off-by: Tushar Beheratushar.beh...@linaro.org --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to applying the 5410 patches... Tested-by: Andreas Färberafaer...@suse.de Andreas, thanks for your test :-) Sachin, How about exynos4210, 5250, 5260 and 5440?... I need to check again, honestly I don't remember all of Exynos SoCs' different things ;-) Then will apply into fixes for 3.16. Exynos4210 doesn't use secure firmware, at least on any board supported in mainline. Not sure about those Exynos5 models, but the only boards supported in mainline with firmware node in DT are based on Exynos4412 or Exynos5410. Best regards, Tomasz Kukjin, Would you please pick this patch as a fix for 3.16? -- 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 2/2] i2c: exynos5: fix minor styling nits
Hi Naveen,
On Wed, Jun 25, 2014 at 4:08 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch removes an extra line and fixes a styling nit
in exynos5_i2c_message_start()
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-exynos5.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c
b/drivers/i2c/busses/i2c-exynos5.c
index 0d1a7bc..4c2e6f3 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
if (i2c-msg-flags I2C_M_RD) {
i2c_ctl |= HSI2C_RXCHON;
- i2c_auto_conf = HSI2C_READ_WRITE;
+ i2c_auto_conf |= HSI2C_READ_WRITE;
This change looks more than just a styling nit. Please update the commit message
accordingly.
--
Regards,
Sachin.
--
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 0/4] Add support for Exynos clock output configuration
Hi Kukjin, On 25.06.2014 12:36, Kukjin Kim wrote: Tomasz Figa wrote: Hi Tomasz, On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of internal SoC clocks to be output from the SoC. The hardware structure Yeah, because the CLKOUT pin is used for measure of the clock for debug on all of exynos SoCs commonly. of CLKOUT related clocks looks as follows: CMU |--- clock0 - | PMU | | | | several |--- clock1 - | mux | muxes| | + |--- CLKOUT dividers | ... | gate| and gates| | | |--- clockN - | | Since the block responsible for handling the pin is PMU, not CMU, a separate driver, that binds to PMU node is required and acquires all input clocks by standard DT clock look-up. This way we don't need any cross-IP block drivers and cross-driver register sharing or nodes for fake devices. BTW, upcoming exynos5 SoCs have two muxs for CLKOUT and each mux is controlled by CMU and PMU, so The mux1 for CLKOUT in CMU is used to decide which clock in each sub-domain will be out and the mux2 in PMU is used to decide which sub-domain will be out via CLKOUT. So I want you to consider of all of exynos SoCs including upcoming SoCs. Is it something similar to what I implemented for Exynos4 in patch 2/4? The same has to be done for other Exynos SoCs as well, but i don't have any board on which I could test this, so I just added a subset of available inputs of PMU mux in current implementation. Anyway, anything in CMU can be handled in normal SoC clock driver, so I don't think this poses any problem for this series. 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 0/4 v2] hwmon: ntc_thermistor: prepose vendor prefix change
Naveen Krishna Chatradhi wrote: + Jean Delvare, Guenter Roeck I'm adding maintainers for drivers/hwmon/ntc* but I'm not sure. Hi, This series looks good to me. I will take 3/4 and 4/4 for exynos DT changes once hwmon/ntc maintainer pick the others. Thanks, Kukjin As Murata is the manufacturer of the NTC (Negative Temperature coefficient) based Thermistors. ntc_thermistor driver extensively used the prefix ntc. But, vendor-prefix should be murata instead of ntc. This patchset 1. Updates the vendor-prefix, DT bindings and Documentation, where ever necessary. 2. Adds thermistor nodes to Exynos5420 based Peach PIT board. Patches: 1/4. devicetree: bindings: Document murata vendor prefix Adds the vendor prefix murata to vendor-prefixes.txt. 2/4. hwmon: ntc_thermistor: Use the manufacturer name properly Updates the driver, Kconfig, device tree bindings and Documentation with the Manufacturer/vendor information. Keeps the old bindings marked as DEPRECATED in code and Documentation 3/4. ARM: DTS: use new compatible string as per the documentation Updates the device node in Exynos4412 based Trats2 board with the new device tree bindings. 4/4. ARM: DTS: Add NTC thermistor nodes as child nodes to ADC Adds Thermistor nodes to Exynos5420 based Peach PIT board. This patchset Naveen Krishna Chatradhi (4): devicetree: bindings: Document murata vendor prefix hwmon: ntc_thermistor: Use the manufacturer name properly ARM: DTS: use new compatible string as per the documentation ARM: DTS: Add NTC thermistor nodes to Exynos5420 based Peach_PIT .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +- .../devicetree/bindings/hwmon/ntc_thermistor.txt | 20 .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/hwmon/ntc_thermistor |8 ++--- arch/arm/boot/dts/exynos4412-trats2.dts|4 +-- arch/arm/boot/dts/exynos5420-peach-pit.dts | 34 drivers/hwmon/Kconfig |5 +-- drivers/hwmon/ntc_thermistor.c | 14 +++- 8 files changed, 72 insertions(+), 16 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
RE: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
Abhilash Kesavan wrote:
Hi Russell and Tomasz,
+Arnd
On Tue, Jun 24, 2014 at 9:41 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
Hi Kukjin,
On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com
wrote:
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Do you have any comments on this patch ?
I do.
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index d10c351..6dd4a11 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
...
@@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_restore_register();
It is invalid to check just the part number. The part number on its
own is meaningless without taking account of the implementor. Both
the implementor and the part number should be checked at each of these
sites.
Thanks for pointing this out. I was not aware of the implementor id
check requirement.
Another point: exynos have taken it upon themselves to add code which
saves various ARM core registers. This is a bad idea, it brings us
back to the days where every platform did their own suspend implementations.
CPU level registers should be handled by CPU level code, not by platform
code. Is there a reason why this can't be added to the Cortex-A9
support code in proc-v7.S ?
Got it. Thanks for pointing out.
@@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
s3c_pm_do_restore_core(exynos_core_save,
ARRAY_SIZE(exynos_core_save));
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
early_wakeup:
@@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct
notifier_block *self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
- exynos_cpu_save_register();
+ if (read_cpuid_part_number() ==
ARM_CPU_PART_CORTEX_A9)
+ exynos_cpu_save_register();
}
break;
case CPU_PM_EXIT:
if (cpu == 0) {
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() ==
+ ARM_CPU_PART_CORTEX_A9) {
scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
+ exynos_cpu_restore_register();
+ }
exynos_pm_central_resume();
}
break;
And presumably with the CPU level code dealing with those registers,
you don't need the calls to save and restore these registers in this
notifier.
Regarding save/restore of these registers, I could send out a patch
cleaning these out once Shawn's patch gets merged. I'd need some help
testing it out on Exynos4 boards though. For now, is it OK if I just
update to the new function ?
Which, by the way, is probably illegal to run as it runs in a read-
lock code path and with the SCU disabled. As you're calling
scu_enable() that means you're non-coherent with the other CPUs,
and therefore locks don't work.
I think this code is very broken and wrongly architected, and shows
that we're continuing to make the same mistakes that we made all
through the 2000s with platforms doing their own crap rather than
properly thinking about this stuff.
I see that you have sent a patch out that ensures both part and
implementor number are checked. Currently, my patch has been applied
to the fixes branch of the arm-soc tree and I wanted to know how to
proceed (without it there is a crash on the 5420):
Should I request Arnd to drop it (if possible) and send out a new
patch using your updated function ?
Oops, Abhilash please send new fix on top of the current patch.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] i2c: exynos5: Properly use the noirq variants of suspend/resume
Doug Anderson wrote:
The original code for the exynos i2c controller registered for the
noirq variants. However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually noirq (despite functions named
exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq).
i2c controllers that might have wakeup sources on them seem to need to
resume at noirq time so that the individual drivers can actually read
the i2c bus to handle their wakeup.
NOTE: I took the original review feedback from Wolfram and added
poweroff, thaw, freeze, restore.
Yeah I'm not sure except .suspend_noirq and .resume_noirq but I'm fine if
Wolfram suggested ;-)
This patch has only been compile-tested since I don't have all the
patches needed to make my machine using this i2c driver actually
suspend/resume.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Added missing CONFIG_PM_SLEEP
drivers/i2c/busses/i2c-exynos5.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-
exynos5.c
index 63d2292..348b1cd 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -789,8 +789,16 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
}
#endif
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
- exynos5_i2c_resume_noirq);
+const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
Maybe static const struct...?
+#ifdef CONFIG_PM_SLEEP
+ .suspend_noirq = exynos5_i2c_suspend_noirq,
+ .resume_noirq = exynos5_i2c_resume_noirq,
+ .freeze_noirq = exynos5_i2c_suspend_noirq,
+ .thaw_noirq = exynos5_i2c_resume_noirq,
+ .poweroff_noirq = exynos5_i2c_suspend_noirq,
+ .restore_noirq = exynos5_i2c_resume_noirq,
+#endif
+};
static struct platform_driver exynos5_i2c_driver = {
.probe = exynos5_i2c_probe,
--
2.0.0.526.g5318336
Others look good to me,
Acked-by: Kukjin Kim kgene@samsung.com
Thanks,
Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 11:37:54AM +0100, Marc Zyngier wrote:
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5410.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi| 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi| 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi| 2 +-
arch/arm/boot/dts/tegra114.dtsi | 2 +-
arch/arm/boot/dts/tegra124.dtsi | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm64/boot/dts/apm-storm.dtsi | 2 +-
arch/arm64/boot/dts/foundation-v8.dts | 2 +-
arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
For the Tegra114 and Tegra124 patches:
Tested-by: Thierry Reding tred...@nvidia.com
Acked-by: Thierry Reding tred...@nvidia.com
pgpOr175p_rJn.pgp
Description: PGP signature
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On Wed, Jun 25, 2014 at 10:30:46AM +0530, Abhilash Kesavan wrote: I see that you have sent a patch out that ensures both part and implementor number are checked. Currently, my patch has been applied to the fixes branch of the arm-soc tree and I wanted to know how to proceed (without it there is a crash on the 5420): Should I request Arnd to drop it (if possible) and send out a new patch using your updated function ? I'll hold my patch off - as yours is in the fixes branch, it should end up in a -rc release. Mine isn't -rc material. -- 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: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Hi Yuvaraj.
This patch looks like similar Jaehoon's.
Is it resending?
Anyway, I added some comments below.
On Wed, June 25, 2014, Jaehoon Chung wrote:
On 06/25/2014 03:00 AM, Doug Anderson wrote:
Yuvaraj,
On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com
wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 71
++---
drivers/mmc/host/dw_mmc.h |2 ++
2 files changed, 36 insertions(+), 37 deletions(-)
Perhaps you could CC me on the whole series for the next version since
I was involved in privately reviewing previous versions?
Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..f5cabce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if ((!IS_ERR(mmc-supply.vmmc))
+ !test_bit(DW_MMC_CARD_POWERED,
slot-flags)) {
+ ret = regulator_enable(mmc-supply.vmmc);
+ if (!ret)
+ set_bit(DW_MMC_CARD_POWERED, slot-flags);
MMC_CARD_POWERED? I didn't know why it needs.
Also, ios-vdd is missed. Use mmc_regulator_set_ocr() instead of
regulator_enable() for vmmc.
And with mmc_regulator_set_ocr(), we don't need to check additional flag for
enable/disable.
It does that already.
+ }
As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
different times.
In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and
vmmc at different times.
Also: if you fail to turn on either of the regulators it feels like
you should print a pretty nasty error message since your device will
almost certainly not work.
set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
regs = mci_readl(slot-host, PWREN);
regs |= (1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ test_bit(DW_MMC_IO_POWERED, slot-flags))
{
+ ret = regulator_disable(mmc-supply.vqmmc);
+ if (!ret)
+ clear_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
+ if (!IS_ERR(mmc-supply.vmmc)
+ test_bit(DW_MMC_CARD_POWERED,
slot-flags)) {
+ ret = regulator_disable(mmc-supply.vmmc);
+ if (!ret)
+ clear_bit(DW_MMC_CARD_POWERED,
slot-flags);
+ }
regs = mci_readl(slot-host, PWREN);
regs = ~(1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
+ case MMC_POWER_ON:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ !test_bit(DW_MMC_IO_POWERED,
slot-flags)) {
You can use regulator_is_enabled() instead of flag bit, DW_MMC_IO_POWERED.
Important thing is that if powering vmmc failed at MMC_POWER_UP, vqmmc should
not be powered.
Please consider Doug's mentions below.
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (!ret)
+ set_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
default:
break;
}
@@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-f_max = freq[1];
}
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ /*if there are external regulators, get them*/
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret == -EPROBE_DEFER)
+ goto err_setup_bus;
+
+ if (!mmc-ocr_avail)
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
if (host-pdata-caps)
mmc-caps = host-pdata-caps;
@@ -2133,7 +2165,7 @@ static int
Re: [PATCH] clk/exynos5250: fix bit number for tv sysmmu clock
Hi Kukjin,
Please take this fix in your tree.
Regards,
Rahul Sharma
On 19 June 2014 11:35, Sachin Kamat sachin.ka...@samsung.com wrote:
On Thu, Jun 19, 2014 at 11:17 AM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Change bit from 2 to 9 for tv (mixer) sysmmu clock.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on Kukjin's for-next branch.
drivers/clk/samsung/clk-exynos5250.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 1fad4c5..184f642 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -661,7 +661,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
GATE(CLK_RTC, rtc, div_aclk66, GATE_IP_PERIS, 20, 0, 0),
GATE(CLK_TMU, tmu, div_aclk66, GATE_IP_PERIS, 21, 0, 0),
GATE(CLK_SMMU_TV, smmu_tv, mout_aclk200_disp1_sub,
- GATE_IP_DISP1, 2, 0, 0),
+ GATE_IP_DISP1, 9, 0, 0),
SysMMU TV corresponds to bit 9 as per user manual of 5250.
Reviewed-by: Sachin Kamat sachin.ka...@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk/exynos5250: fix bit number for tv sysmmu clock
Hi Rahul, On 25.06.2014 13:22, Rahul Sharma wrote: Hi Kukjin, Please take this fix in your tree. This is a patch for Samsung clock drivers, so I'll apply it when about to send fixes pull request to Mike. 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 1/2] clk: samsung: fix several typos to fix boot on s3c2410
Hi Vasily, On 23.06.2014 22:29, Vasily Khoruzhick wrote: There's a several typos in a driver: 2410 instead of S3C2410 and wrong argument to ARRAY_SIZE(). They prevent s3c2410 from properly booting. Thanks for fixing this. I will apply and send to Mike with other fixes. Same for patch 2/2. 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] clk/exynos5250: fix bit number for tv sysmmu clock
Tomasz Figa wrote: Hi Rahul, On 25.06.2014 13:22, Rahul Sharma wrote: Hi Kukjin, Please take this fix in your tree. This is a patch for Samsung clock drivers, so I'll apply it when about to send fixes pull request to Mike. Yes, I also checked the datasheet and this change is correct. If you want, please add my ack on the patch. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3 v5] spi: s3c64xx: fix broken cs_gpios usage in the driver
Doug Anderson wrote:
Mark or Kukjin,
Hi,
On Thu, Jun 12, 2014 at 8:59 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
Since, (3146bee spi: s3c64xx: Added provision for dedicated cs pin)
spi-s3c64xx.c driver expects
1. chip select gpios from cs-gpio(singular) under the
controller-data node of the client/slave device of the SPI.
2. cs-gpio(singular) entry to be present in the SPI device node.
Eg of current broken usage:
spi_1 {
cs-gpio ; /* this entry is checked during probe */
...
slave_node {
controller-data {
cs-gpio gpioa2 5 0;
/* This field is parsed during .setup() */
}
};
};
The following dts files which were using this driver. But,
din't have the cs-gpio entry under SPI node.
-- arch/arm/boot/dts/exynos4210-smdkv310.dts
-- arch/arm/boot/dts/exynos4412-trats2.dts
-- arch/arm/boot/dts/exynos5250-smdk5250.dts
Also, the SPI core and many drivers moved on to using cs-gpios
from SPI node and removed the gpio handling code from drivers
(including spi-s3c64xx.c).
Hence, spi-s3c64xx.c is broken since Jun 21 11:26:12 2013 and
considering the time with no compliants about the breakage.
We are assuming it is safe to remove the cs-gpio(singular) usage
from device tree binding of spi-samsung.txt and makes appropriate
changes in the driver to use cs-gpios(plural) from
SPI device node.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Rob Herring r...@kernel.org
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Doug Anderson diand...@chromium.org
Cc: Tomasz Figa t.f...@samsung.com
---
Changes since v4:
1. Added reviewed by from Javier and Tested by from Doug
Changes since v3:
1. Remove the sdd-cs_gpio and use gpio_is_valid(spi-cs_gpio) instead
2. Keep cs-line only for Non-DT platforms and use spi-cs_gpio
for DT platforms
.../devicetree/bindings/spi/spi-samsung.txt|8 ++--
drivers/spi/spi-s3c64xx.c | 41
2 files changed, 20 insertions(+), 29 deletions(-)
Is one of you two planning to apply (parts 1 and 2)? I know that
Kukjin needs to handle the part 3 (the .dts files)...
Once Mark takes spi driver related patches, I will pick DT related patches into
samsung tree.
Ideally it seems like it could go to 3.16 since it is a bugfix...
I think so but it depends on Mark's comments ;-)
Thanks,
Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: s3c64xx: Hookup SPI clocks correctly
Hi Charles, On 18.06.2014 11:52, Charles Keepax wrote: In the move to this clock driver the hookups for the SPI clocks were dropped, which causes my system Cragganmore (s3c6410 based) to be unable to locate any spibus clocks. This patch adds them back in. When taking the clock from the epll clock (SCLK) the rates on the SPI bus are incorrect, this needs further debugging but the hookup here should be correct and the problem should be else where. The USBCLK case has been dropped because this requires the USB PHY to be enabled. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/clk/samsung/clk-s3c64xx.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Thanks for fixing this. Will apply to my fixes branch. 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 2/3] clk: exynos5420: Add IDs for clocks used in PD mfc
On 10.06.2014 17:39, Tomasz Figa wrote: Hi, On 26.05.2014 13:56, Shaik Ameer Basha wrote: From: Arun Kumar K arun...@samsung.com Adds IDs for MUX clocks to be used by power domain for MFC for doing re-parenting while pd on/off. Signed-off-by: Arun Kumar K arun...@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- drivers/clk/samsung/clk-exynos5420.c |6 -- include/dt-bindings/clock/exynos5420.h |2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Tomasz Figa t.f...@samsung.com Actually, since this patch shouldn't generate any serious conflicts, feel free to add my Acked-by: Tomasz Figa t.f...@samsung.com to let the whole series go through Samsung tree. 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 1/1] ARM: Kconfig.debug: Update Samsung UART config options
Sachin Kamat wrote: + Russell In a multiplatform config, the low level debug option shows several UART port entries. Improve the user visible string so that it becomes clear to the user about Samsung UART ports. While at it also remove some lines from the help text that are no longer applicable across all Samsung platforms. Looks good to me and will apply into cleanup. Thanks, Kukjin Signed-off-by: Sachin Kamat sachin.ka...@samsung.com --- arch/arm/Kconfig.debug | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 3548612b0bfe..b92993e59a12 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -617,53 +617,41 @@ choice depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool Use S3C UART 0 for low-level debug + bool Use Samsung S3C UART 0 for low-level debug help Say Y here if you want the debug print routines to direct their output to UART 0. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART1 depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool Use S3C UART 1 for low-level debug + bool Use Samsung S3C UART 1 for low-level debug help Say Y here if you want the debug print routines to direct their output to UART 1. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART2 depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool Use S3C UART 2 for low-level debug + bool Use Samsung S3C UART 2 for low-level debug help Say Y here if you want the debug print routines to direct their output to UART 2. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART3 depends on PLAT_SAMSUNG ARCH_EXYNOS select DEBUG_EXYNOS_UART - bool Use S3C UART 3 for low-level debug + bool Use Samsung S3C UART 3 for low-level debug help Say Y here if you want the debug print routines to direct their output to UART 3. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C2410_UART0 depends on ARCH_S3C24XX select DEBUG_S3C2410_UART -- 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 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
On 25.06.2014 12:09, Daniel Drake wrote: Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Testing against 3.16-rc2, this doesn't quite work for me. SAMSUNG_PM_DEBUG still doesn't appear in menuconfig. HAVE_SAMSUNG_PM_DEBUG is 'n'. Looks like the select from DEBUG_S3C_UART is not working, but I'm not sure why. I hastily changed this to something simpler in last minute before sending without proper testing. Let me send something that works. 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 3/4] Documentation: devicetree: Fix tps65090 typos
Am 25.06.2014 12:47, schrieb Mark Rutland:
On Mon, Jun 23, 2014 at 06:27:04PM +0100, Doug Anderson wrote:
Andreas,
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.
Signed-off-by: Andreas Färber afaer...@suse.de
---
Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 34098023..ca69f5e 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = some_reg;
infet6-supply = some_reg;
infet7-supply = some_reg;
- vsys_l1-supply = some_reg;
- vsys_l2-supply = some_reg;
+ vsys-l1-supply = some_reg;
+ vsys-l2-supply = some_reg;
Your change matches the code and all existing device trees in the
Linux kernel.
Could this fact please be mentioned in the commit message?
Yes, I admit the commit message could've been clearer in stating that
only the example is modified, not the actual specification. What about:
Specification and existing device trees use vsys-l{1,2}-supply, not
vsys_l{1,2}-supply. Fix the example to match the specification.
Maybe also ... typos in example in the subject.
Let me know whether I should send a v2 or let maintainers fix it up.
Regards,
Andreas
Given that:
Acked-by: Mark Rutland mark.rutl...@arm.com
I also see plenty of other bindings with dashes, so this seems
reasonable.
Dashes rather than underscores are preferred/correct for property names
and compatible strings. Given no-one can possibly be using the
bad/incorrect form with underscores, fixing the documentation to use
dashes makes sense.
Thanks,
Mark.
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
Sachin Kamat wrote: On Fri, May 30, 2014 at 11:49 PM, Andreas Färber afaer...@suse.de wrote: Am 28.05.2014 06:13, schrieb Sachin Kamat: Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to applying the 5410 patches... Tested-by: Andreas Färber afaer...@suse.de Kukjin, this patch is required to bring up 4 A15 cores on some 5410 and 5420 based boards. Can you please queue this up for the upcoming rc as fixes? Sure, I will take this into fixes. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Signed-off-by: Tomasz Figa t.f...@samsung.com --- arch/arm/plat-samsung/Kconfig| 5 +++-- arch/arm/plat-samsung/pm-debug.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 301b892..ad9515f 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -413,8 +413,9 @@ config S5P_DEV_MFC comment Power management config SAMSUNG_PM_DEBUG - bool S3C2410 PM Suspend debug - depends on PM DEBUG_KERNEL DEBUG_S3C_UART + bool Samsung PM Suspend debug + depends on PM DEBUG_KERNEL + depends on DEBUG_EXYNOS_UART || DEBUG_S3C24XX_UART || DEBUG_S3C2410_UART help Say Y here if you want verbose debugging from the PM Suspend and Resume code. See file:Documentation/arm/Samsung-S3C24XX/Suspend.txt diff --git a/arch/arm/plat-samsung/pm-debug.c b/arch/arm/plat-samsung/pm-debug.c index 8f19f66..3960960 100644 --- a/arch/arm/plat-samsung/pm-debug.c +++ b/arch/arm/plat-samsung/pm-debug.c @@ -14,6 +14,7 @@ */ #include linux/serial_core.h +#include linux/serial_s3c.h #include linux/io.h #include asm/mach/map.h -- 1.9.3 -- 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/6] ARM: EXYNOS: Fix suspend/resume sequences
Due to recent consolidation of Exynos suspend and cpuidle code, some
parts of suspend and resume sequences are executed two times, once from
exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
breaks suspend, at least on Exynos4-based boards.
This patch fixes the issue by removing exynos_pm_syscore_ops completely
and making the code rely only on CPU PM notifier.
Tested on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/pm.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
Changes since v1:
- rebased onto Kukjin's fixes branch.
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 202ca73..f23cc77 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -364,11 +364,6 @@ early_wakeup:
return;
}
-static struct syscore_ops exynos_pm_syscore_ops = {
- .suspend= exynos_pm_suspend,
- .resume = exynos_pm_resume,
-};
-
/*
* Suspend Ops
*/
@@ -438,22 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block
*self,
switch (cmd) {
case CPU_PM_ENTER:
- if (cpu == 0) {
- exynos_pm_central_suspend();
- if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
- exynos_cpu_save_register();
- }
+ if (cpu == 0)
+ exynos_pm_suspend();
break;
case CPU_PM_EXIT:
- if (cpu == 0) {
- if (read_cpuid_part_number() ==
- ARM_CPU_PART_CORTEX_A9) {
- scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
- }
- exynos_pm_central_resume();
- }
+ if (cpu == 0)
+ exynos_pm_resume();
break;
}
@@ -478,6 +464,5 @@ void __init exynos_pm_init(void)
tmp |= ((0xFF 8) | (0x1F 1));
__raw_writel(tmp, S5P_WAKEUP_MASK);
- register_syscore_ops(exynos_pm_syscore_ops);
suspend_set_ops(exynos_suspend_ops);
}
--
1.9.3
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
Am 25.06.2014 13:43, schrieb Kukjin Kim: Sachin Kamat wrote: On Fri, May 30, 2014 at 11:49 PM, Andreas Färber afaer...@suse.de wrote: Am 28.05.2014 06:13, schrieb Sachin Kamat: Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to applying the 5410 patches... Tested-by: Andreas Färber afaer...@suse.de FWIW meanwhile I also successfully tested it on 5420 based Arndale Octa. I can also check on 5250 based Spring, now that it's working, if that helps build confidence in the patch. Cheers, Andreas Kukjin, this patch is required to bring up 4 A15 cores on some 5410 and 5420 based boards. Can you please queue this up for the upcoming rc as fixes? Sure, I will take this into fixes. Thanks, Kukjin -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 v2] drm/exynos: allow mulitple layer updates per vsync for mixer
On 2014년 06월 25일 19:42, Rahul Sharma wrote:
Thanks Inki,
One more thing. mixer_layer_update is only called on for mixer version;
MXR_VER_16_0_33_0, MXR_VER_128_0_0_184. This condition
should have taken care of Exynos4 scenarios. What you say?
There was my missing point. :) Already considered. ignore my comment.
Thanks,
Inki Dae
Regards,
Rahul Sharma.
On 24 June 2014 20:20, Inki Dae inki@samsung.com wrote:
2014-06-24 20:38 GMT+09:00 Andreas Färber afaer...@suse.de:
Am 24.06.2014 07:21, schrieb Inki Dae:
On 2014년 06월 23일 14:32, Rahul Sharma wrote:
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context
*ctx, int win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = ctx-mixer_res;
-u32 val;
-
-val = mixer_reg_read(res, MXR_CFG);
-/* allow one update per vsync only */
-if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
-mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
Rahul, it looks good to me and ok as is. But above codes don't consider
Exynos4 series. In case of Exynos4xxx SoC,
MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
register are reserved fields. So can you work that patch to be
considered for Exynos4xxx SoC? That patch would be additional one.
Anyway, will apply it as is, and I will wait for the additional patch.
If it's not too late, could you fix up multiple in the subject? :)
Corrected. :)
Thanks,
Inki Dae
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
On 06/25/2014 03:59 AM, Laura Abbott wrote:
On 6/24/2014 10:47 AM, Laura Abbott wrote:
On 6/23/2014 11:32 AM, Kevin Hilman wrote:
On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera trbli...@gmail.com wrote:
Adding linux-samsung-soc and linux-arm-kernel ML for wider audience.
On 06/19/2014 04:12 PM, Tushar Behera wrote:
On 06/19/2014 03:02 PM, Tushar Behera wrote:
On 06/18/2014 09:22 AM, Kevin Hilman wrote:
On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera trbli...@gmail.com
wrote:
On 06/17/2014 10:23 PM, Kevin Hilman wrote:
Sachin,
On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot
khil...@linaro.org wrote:
Tree/Branch: mainline
Git describe: v3.16-rc1-2-gebe0618
Failed boot tests (console logs at the end)
===
exynos5420-arndale-octa: FAIL:arm-exynos_defconfig
ste-snowball: FAIL:arm-u8500_defconfig
FYI... these failures are getting more consistent on my octa board,
but still not failing every time.
Kevin
Hi Kevin,
Same here.
Observation: If you soft-reset the board (through the jumpers) after
getting this problem, the problem keeps repeating. But if you
hard-reset
the board (by removing the power cord), the problem doesn't occur
during
next iteration.
I don't ever use the soft-reset, I only toggle the wall power. I
don't ever actually remove the power cord though, I'm using a
USB-controlled relay to toggle the wall power.
Kevin
Laura,
We are getting following kernel panic [1] (not always, but quite
regularly) while booting Arndale-Octa (based on Samsung's Exynos5420)
board with upstream kernel. I haven't observed this issue with other
boards yet.
This issue is observed when I am booting with uImage + dtb (within
roughly ~10 iterations).
Some more information:
The boot logs are provided in pastebin, okay[2] and failed[3].
In case of boot failures, I am getting a higher value for vm_total_pages
(684424 in [3]). In case of successful boot on my board, it is always
521232 [2] on my board.
I can confirm that reverting the Get rid of meminfo patch gets the
Octa board booting reliably again for me also.
In case it helps, some boot logs for failures from the last copule
linux-next build/boot cycles can be seen here:
http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
Sorry, I missed this yesterday. I'm going to take a look.
Were all of
http://pastebin.com/1iLaizuL
http://pastebin.com/5tdDt4GL
http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log
collected on the same type of board with the same amount of DRAM? I'm seeing a
different amount of total pages across all those logs. All the logs have the
same lowmem limit so it seems like the upper bound was being calculated
incorrectly for passing to free_area_init_node. Nothing is immediately jumping
out at me so can you boot up with a small debug patch?
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..88eac1f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -187,6 +187,8 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max_low,
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
struct memblock_region *reg;
+ pr_err(XXX min %lx max_low %lx max_high %lx\n, min, max_low,
max_high);
+ __memblock_dump_all();
/*
* initialise the zones.
*/
It would be helpful to do this across a few bootups to see if the values are
actually consistent. I'll keep looking in the meantime.
Thanks,
Laura
Thanks Laura for the pointer. In case of error, I am getting some random
memblock_add() calls from drivers/of/fdt.c:early_init_dt_scan_memory.
The issue seems to be from u-boot, where it is not updating the memory
subnode properly. I have got a fix for the u-boot, which I am testing
right now. I will update tomorrow after I do some more test.
Additional changes in kernel.
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..bca82b3 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -817,7 +817,7 @@ int __init early_init_dt_scan_memory(unsigned long
node, const char *uname,
endp = reg + (l / sizeof(__be32));
- pr_debug(memory scan node %s, reg size %d, data: %x %x %x %x,\n,
+ pr_err(memory scan node %s, reg size %d, data: %x %x %x %x,\n,
uname, l, reg[0], reg[1], reg[2], reg[3]);
while ((endp - reg) = (dt_root_addr_cells + dt_root_size_cells)) {
@@ -891,6 +891,7 @@ void __init __weak early_init_dt_add_memory_arch(u64
base, u64 size)
size -= phys_offset - base;
base = phys_offset;
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
Acked-by: Rob Herring r...@kernel.org
Rob
--
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/4] Documentation: devicetree: Fix tps65090 typos
On Wed, Jun 25, 2014 at 6:43 AM, Andreas Färber afaer...@suse.de wrote:
Am 25.06.2014 12:47, schrieb Mark Rutland:
On Mon, Jun 23, 2014 at 06:27:04PM +0100, Doug Anderson wrote:
Andreas,
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.
Signed-off-by: Andreas Färber afaer...@suse.de
---
Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 34098023..ca69f5e 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = some_reg;
infet6-supply = some_reg;
infet7-supply = some_reg;
- vsys_l1-supply = some_reg;
- vsys_l2-supply = some_reg;
+ vsys-l1-supply = some_reg;
+ vsys-l2-supply = some_reg;
Your change matches the code and all existing device trees in the
Linux kernel.
Could this fact please be mentioned in the commit message?
Yes, I admit the commit message could've been clearer in stating that
only the example is modified, not the actual specification. What about:
Specification and existing device trees use vsys-l{1,2}-supply, not
vsys_l{1,2}-supply. Fix the example to match the specification.
Maybe also ... typos in example in the subject.
Let me know whether I should send a v2 or let maintainers fix it up.
Please send v2.
Rob
--
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/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25 2014 at 01:21:17 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.
See at the end of https://lkml.org/lkml/2014/6/25/243
Basically, we stay with a GICv1 behaviour if we detect the mess.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
Acked-by: Rob Herring r...@kernel.org
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
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 v3 1/2] usb: ehci-exynos: Make provision for vdd regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the exynos systems turn on only minimal number of regulators.
Until now, the VDD regulator supplies were either turned on
by the bootloader, or the regulators were enabled by default
in the kernel, so that the controller drivers did not need to
care about turning on these regulators on their own.
This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary
VDD regulators (if available, unless there are direct VDD rails),
and enable them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Changes from v2:
- replaced devm_regulator_get() with devm_regulator_get_optional().
- Added Documentation for the vdd supplies for the controller.
- Re-did the commit message.
.../devicetree/bindings/usb/exynos-usb.txt |2 +
drivers/usb/host/ehci-exynos.c | 55 +++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index a3b5990..b04b015 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,6 +23,8 @@ Required properties:
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
Example:
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1c7621..b920642 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,6 +21,7 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -50,6 +51,8 @@ struct exynos_ehci_hcd {
struct usb_phy *phy;
struct usb_otg *otg;
struct phy *phy_g[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -193,7 +196,27 @@ static int exynos_ehci_probe(struct platform_device *pdev)
err = exynos_ehci_get_phy(pdev-dev, exynos_ehci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci-vdd33 = devm_regulator_get_optional(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get_optional(pdev-dev, vdd10);
+ if (!IS_ERR(exynos_ehci-vdd10)) {
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 1.0V Vdd supply\n);
+ goto fail_regulator2;
+ }
+ }
skip_phy:
@@ -262,6 +285,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -280,6 +307,11 @@ static int exynos_ehci_remove(struct platform_device *pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ if (!IS_ERR(exynos_ehci-vdd33))
+ regulator_disable(exynos_ehci-vdd33);
+ if (!IS_ERR(exynos_ehci-vdd10))
+ regulator_disable(exynos_ehci-vdd10);
+
usb_put_hcd(hcd);
return 0;
@@ -305,6 +337,11 @@ static int exynos_ehci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ehci-clk);
+ if (!IS_ERR(exynos_ehci-vdd33))
+ regulator_disable(exynos_ehci-vdd33);
+ if (!IS_ERR(exynos_ehci-vdd10))
+ regulator_disable(exynos_ehci-vdd10);
+
return rc;
}
@@ -314,6 +351,22 @@ static int exynos_ehci_resume(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int ret;
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ ret = regulator_enable(exynos_ehci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable 3.3V Vdd supply\n);
+ return ret;
+
[PATCH v3 2/2] usb: ohci-exynos: Make provision for vdd regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the exynos systems turn on only minimal number of regulators.
Until now, the VDD regulator supplies were either turned on
by the bootloader, or the regulators were enabled by default
in the kernel, so that the controller drivers did not need to
care about turning on these regulators on their own.
This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary
VDD regulators (if available, unless there are direct VDD rails),
and enable them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Changes from v2:
- replaced devm_regulator_get() with devm_regulator_get_optional().
- Added Documentation for the vdd supplies for the controller.
- Re-did the commit message.
.../devicetree/bindings/usb/exynos-usb.txt |4 ++
drivers/usb/host/ohci-exynos.c | 55 +++-
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index b04b015..3991c50 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -63,6 +63,10 @@ Required properties:
port 2 is HSIC phy1
- phys: from the *Generic PHY* bindings, specifying phy used by port.
+Optional properties:
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
+
Example:
usb@1212 {
compatible = samsung,exynos4210-ohci;
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 060a6a4..57c807c 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,6 +19,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/phy/phy.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -41,6 +42,8 @@ struct exynos_ohci_hcd {
struct usb_phy *phy;
struct usb_otg *otg;
struct phy *phy_g[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static int exynos_ohci_get_phy(struct device *dev,
@@ -172,7 +175,27 @@ static int exynos_ohci_probe(struct platform_device *pdev)
err = exynos_ohci_get_phy(pdev-dev, exynos_ohci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ohci-vdd33 = devm_regulator_get_optional(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ohci-vdd33)) {
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get_optional(pdev-dev, vdd10);
+ if (!IS_ERR(exynos_ohci-vdd10)) {
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 1.0V Vdd supply\n);
+ goto fail_regulator2;
+ }
+ }
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -233,6 +256,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -251,6 +278,11 @@ static int exynos_ohci_remove(struct platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ if (!IS_ERR(exynos_ohci-vdd33))
+ regulator_disable(exynos_ohci-vdd33);
+ if (!IS_ERR(exynos_ohci-vdd10))
+ regulator_disable(exynos_ohci-vdd10);
+
usb_put_hcd(hcd);
return 0;
@@ -282,6 +314,11 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ if (!IS_ERR(exynos_ohci-vdd33))
+ regulator_disable(exynos_ohci-vdd33);
+ if (!IS_ERR(exynos_ohci-vdd10))
+ regulator_disable(exynos_ohci-vdd10);
+
return 0;
}
@@ -291,6 +328,22 @@ static int exynos_ohci_resume(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int ret;
+ if (!IS_ERR(exynos_ohci-vdd33)) {
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+
[PATCH v5 0/6] Cleanup patches for mach-exynos
This series is doing code cleanup under arch/arm/mach-exynos. These patches have been separated from main exynos pmu v4 patch posted here [1]. [1]: https://lkml.org/lkml/2014/5/10/29 Changes Since v4: - Rebased on latest for-next of Kukjin Kim's tree. - Removing file path comment from mach-exynos/headsmp.S also. - Removed signed-off-by of Young-Gun Jang yg1004.j...@samsung.com, as this id is no more valid. Taking ownership of all his patches. - Separated these patches from main exynos pmu v4 patch series as suggested by Tomasz Figa. Changes Since v3: - Addressed build fail issue in exynos.c as reported by Sachin Kamat. - Rebased on top of Sysram patches by Sachin Kamat. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed exynos_cpuidle_init and exynos_cpufreq_init code as suggested by Tomasz Figa. 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. - Added patch: Remove linux/bug.h from pmu.c. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c Pankaj Dubey (6): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine ARM: EXYNOS: Move SYSREG definition into sys-reg specific file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Remove linux/bug.h from pmu.c arch/arm/mach-exynos/common.h |8 arch/arm/mach-exynos/exynos.c | 26 -- arch/arm/mach-exynos/headsmp.S |1 - arch/arm/mach-exynos/hotplug.c |3 +-- arch/arm/mach-exynos/include/mach/map.h|3 +-- arch/arm/mach-exynos/include/mach/memory.h |3 +-- arch/arm/mach-exynos/platsmp.c |3 +-- arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/pm_domains.c |8 arch/arm/mach-exynos/pmu.c |1 - arch/arm/mach-exynos/regs-pmu.h|4 arch/arm/mach-exynos/regs-sys.h| 22 ++ 12 files changed, 39 insertions(+), 44 deletions(-) create mode 100644 arch/arm/mach-exynos/regs-sys.h -- 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 v5 2/6] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine
As exynos_cpuidle_init and exynos_cpufreq_init function have just one lines
of code for registering platform devices. We can move these lines to
exynos_dt_machine_init and delete exynos_cpuidle_init and exynos_cpufreq_init
function. This will help in reducing lines of code in exynos.c, making it
more cleaner.
Suggested-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6affcd9..e54d885 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -171,19 +171,6 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
};
-void __init exynos_cpuidle_init(void)
-{
- if (soc_is_exynos5440())
- return;
-
- platform_device_register(exynos_cpuidle);
-}
-
-void __init exynos_cpufreq_init(void)
-{
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
-}
-
static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
@@ -271,8 +258,10 @@ static void __init exynos_dt_machine_init(void)
}
}
- exynos_cpuidle_init();
- exynos_cpufreq_init();
+ if (!soc_is_exynos5440())
+ platform_device_register(exynos_cpuidle);
+
+ platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
of_platform_populate(NULL, of_default_bus_match_table, NULL, 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 v5 1/6] ARM: EXYNOS: Make exynos machine_ops as static
As machine function ops are used only in this file let's make
them static. Also remove unused and unwanted declarations from
common.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/common.h |8
arch/arm/mach-exynos/exynos.c |6 +++---
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 16617bd..3f25f89 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -111,16 +111,8 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID,
EXYNOS5_SOC_MASK)
#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \
soc_is_exynos5420() || soc_is_exynos5800())
-void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
-
-struct map_desc;
extern void __iomem *sysram_ns_base_addr;
extern void __iomem *sysram_base_addr;
-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);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 90aab4d..6affcd9 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -143,7 +143,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;
@@ -184,7 +184,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 */
@@ -231,7 +231,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
--
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 v5 3/6] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file
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: Pankaj Dubey pankaj.du...@samsung.com
Reviewed-by: Tomasz Figa t.f...@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 e54d885..4a69b3f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -29,6 +29,7 @@
#include common.h
#include mfc.h
#include regs-pmu.h
+#include regs-sys.h
static struct map_desc exynos4_iodesc[] __initdata = {
{
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 202ca73..f127c0c 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 1d13b08..790af14 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)
@@ -188,8 +187,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.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 v5 5/6] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
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.
Also removing S5P_ prefix from macro.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c |8
arch/arm/mach-exynos/regs-pmu.h |1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index fe6570e..bcd8dcf 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 INT_LOCAL_PWR_EN 0x7
/*
* Exynos specific wrapper around the generic power domain
@@ -44,13 +44,13 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd-base;
- pwr = power_on ? S5P_INT_LOCAL_PWR_EN : 0;
+ pwr = power_on ? INT_LOCAL_PWR_EN : 0;
__raw_writel(pwr, base);
/* Wait max 1ms */
timeout = 10;
- while ((__raw_readl(base + 0x4) S5P_INT_LOCAL_PWR_EN) != pwr) {
+ while ((__raw_readl(base + 0x4) INT_LOCAL_PWR_EN) != pwr) {
if (!timeout) {
op = (power_on) ? enable : disable;
pr_err(Power domain %s %s failed\n, domain-name, op);
@@ -172,7 +172,7 @@ static __init int exynos4_pm_init_power_domain(void)
platform_set_drvdata(pdev, pd);
- on = __raw_readl(pd-base + 0x4) S5P_INT_LOCAL_PWR_EN;
+ on = __raw_readl(pd-base + 0x4) INT_LOCAL_PWR_EN;
pm_genpd_init(pd-pd, NULL, !on);
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 790af14..1993e6b 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -126,7 +126,6 @@
#define S5P_PAD_RET_EBIB_OPTIONS5P_PMUREG(0x31A8)
#define S5P_CORE_LOCAL_PWR_EN 0x3
-#define S5P_INT_LOCAL_PWR_EN 0x7
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
--
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 v5 4/6] ARM: EXYNOS: Remove file path from comment section
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 Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/headsmp.S |1 - arch/arm/mach-exynos/hotplug.c |3 +-- arch/arm/mach-exynos/include/mach/map.h|3 +-- arch/arm/mach-exynos/include/mach/memory.h |3 +-- arch/arm/mach-exynos/platsmp.c |3 +-- 5 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S index cdd9d91..b54f970 100644 --- a/arch/arm/mach-exynos/headsmp.S +++ b/arch/arm/mach-exynos/headsmp.S @@ -1,5 +1,4 @@ /* - * linux/arch/arm/mach-exynos4/headsmp.S * * Cloned from linux/arch/arm/mach-realview/headsmp.S * diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 8a134d0..572f6b1 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -1,5 +1,4 @@ -/* linux arch/arm/mach-exynos4/hotplug.c - * +/* * Cloned from linux/arch/arm/mach-realview/hotplug.c * * Copyright (C) 2002 ARM Ltd. diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h index 548269a..963002f 100644 --- a/arch/arm/mach-exynos/include/mach/map.h +++ b/arch/arm/mach-exynos/include/mach/map.h @@ -1,5 +1,4 @@ -/* linux/arch/arm/mach-exynos/include/mach/map.h - * +/* * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. * http://www.samsung.com/ * diff --git a/arch/arm/mach-exynos/include/mach/memory.h b/arch/arm/mach-exynos/include/mach/memory.h index 2a4cdb7..e19df1f 100644 --- a/arch/arm/mach-exynos/include/mach/memory.h +++ b/arch/arm/mach-exynos/include/mach/memory.h @@ -1,5 +1,4 @@ -/* linux/arch/arm/mach-exynos4/include/mach/memory.h - * +/* * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. * http://www.samsung.com * diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index ec02422..f82fd8d 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -1,5 +1,4 @@ -/* linux/arch/arm/mach-exynos4/platsmp.c - * + /* * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. * http://www.samsung.com * -- 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 v5 6/6] ARM: EXYNOS: Remove linux/bug.h from pmu.c
This patch removes unnecessary header file inclusion from pmu.c. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Reviewed-by: Tomasz Figa t.f...@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 fb0deda..dcfcb44 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 common.h #include regs-pmu.h -- 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 1/1] ARM: Kconfig.debug: Update Samsung UART config options
On Wed, Jun 25, 2014 at 08:41:13PM +0900, Kukjin Kim wrote: Sachin Kamat wrote: + Russell In a multiplatform config, the low level debug option shows several UART port entries. Improve the user visible string so that it becomes clear to the user about Samsung UART ports. While at it also remove some lines from the help text that are no longer applicable across all Samsung platforms. Looks good to me and will apply into cleanup. That's fine. I don't have anything which clashes with this. Thanks for asking. -- 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: [PATCH] clk/exynos5250: fix bit number for tv sysmmu clock
Sure Tomasz, Kukjin. Thanks for the update. Regards. On 25 June 2014 16:56, Kukjin Kim kgene@samsung.com wrote: Tomasz Figa wrote: Hi Rahul, On 25.06.2014 13:22, Rahul Sharma wrote: Hi Kukjin, Please take this fix in your tree. This is a patch for Samsung clock drivers, so I'll apply it when about to send fixes pull request to Mike. Yes, I also checked the datasheet and this change is correct. If you want, please add my ack on the patch. Thanks, Kukjin ___ 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 3/3] mmc: dw_mmc: Support voltage changes
On Mon, June 23, 2014, Yuvaraj Kumar C D wrote:
Subject: [PATCH 3/3] mmc: dw_mmc: Support voltage changes
From: Doug Anderson diand...@chromium.org
For UHS cards we need the ability to switch voltages from 3.3V to
1.8V. Add support to the dw_mmc driver to handle this. Note that
dw_mmc needs a little bit of extra code since the interface needs a
special bit programmed to the CMD register while CMD11 is progressing.
This means adding a few extra states to the state machine to track.
Overall new additional states makes it complicated.
Can we do that in other way?
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 145
+---
drivers/mmc/host/dw_mmc.h |5 +-
include/linux/mmc/dw_mmc.h |2 +
3 files changed, 142 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index e034bce..38eb548 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -29,6 +29,7 @@
#include linux/irq.h
#include linux/mmc/host.h
#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
#include linux/mmc/sdio.h
#include linux/mmc/dw_mmc.h
#include linux/bitops.h
@@ -235,10 +236,13 @@ err:
}
#endif /* defined(CONFIG_DEBUG_FS) */
+static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
+
static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command
*cmd)
{
struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci *host = slot-host;
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 cmdr;
cmd-error = -EINPROGRESS;
@@ -254,6 +258,32 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
else if (cmd-opcode != MMC_SEND_STATUS cmd-data)
cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
+ if (cmd-opcode == SD_SWITCH_VOLTAGE) {
+ u32 clk_en_a;
+
+ /* Special bit makes CMD11 not die */
+ cmdr |= SDMMC_CMD_VOLT_SWITCH;
+
+ /* Change state to continue to handle CMD11 weirdness */
+ WARN_ON(slot-host-state != STATE_SENDING_CMD);
+ slot-host-state = STATE_SENDING_CMD11;
+
+ /*
+ * We need to disable clock stop while doing voltage switch
+ * according to 7.4.1.2 Voltage Switch Normal Scenario.
+ *
+ * It's assumed that by the next time the CLKENA is updated
+ * (when we set the clock next) that the voltage change will
+ * be over, so we don't bother setting any bits to synchronize
+ * with dw_mci_setup_bus().
+ */
+ clk_en_a = mci_readl(host, CLKENA);
+ clk_en_a = ~(SDMMC_CLKEN_LOW_PWR slot-id);
+ mci_writel(host, CLKENA, clk_en_a);
+ mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
+ SDMMC_CMD_PRV_DAT_WAIT, 0);
dw_mci_disable_low_power() can be used here.
+ }
+
if (cmd-flags MMC_RSP_PRESENT) {
/* We expect a response, so set this bit */
cmdr |= SDMMC_CMD_RESP_EXP;
@@ -776,11 +806,15 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
unsigned int clock = slot-clock;
u32 div;
u32 clk_en_a;
+ u32 sdmmc_cmd_bits = SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT;
+
+ /* We must continue to set bit 28 in CMD until the change is complete */
+ if (host-state == STATE_WAITING_CMD11_DONE)
+ sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
I didn't get the reason SDMMC_CMD_VOLT_SWITCH is needed during clock
update(enable/disable)
Can you explain it in details?
if (!clock) {
mci_writel(host, CLKENA, 0);
- mci_send_cmd(slot,
- SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+ mci_send_cmd(slot, sdmmc_cmd_bits, 0);
} else if (clock != host-current_speed || force_clkinit) {
div = host-bus_hz / clock;
if (host-bus_hz % clock host-bus_hz clock)
@@ -804,15 +838,13 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
mci_writel(host, CLKSRC, 0);
/* inform CIU */
- mci_send_cmd(slot,
- SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+ mci_send_cmd(slot, sdmmc_cmd_bits, 0);
/* set clock to desired speed */
mci_writel(host, CLKDIV, div);
/* inform CIU */
- mci_send_cmd(slot,
- SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
+ mci_send_cmd(slot, sdmmc_cmd_bits, 0);
/* enable clock; only low power if no SDIO */
clk_en_a = SDMMC_CLKEN_ENABLE
[PATCH v2 1/5] ARM: dts: exynos4: add port sub-nodes to exynos usb host modules
This patch adds port sub-nodes to exynos4 ehci and ohci modules, which
are required by recently merged new exynos4 usb2 phy support.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8ece4be41ca..c91284441694 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -322,6 +322,23 @@
clocks = clock CLK_USB_HOST;
clock-names = usbhost;
status = disabled;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = exynos_usbphy 1;
+ status = disabled;
+ };
+ port@1 {
+ reg = 1;
+ phys = exynos_usbphy 2;
+ status = disabled;
+ };
+ port@2 {
+ reg = 2;
+ phys = exynos_usbphy 3;
+ status = disabled;
+ };
};
ohci@1259 {
@@ -331,6 +348,13 @@
clocks = clock CLK_USB_HOST;
clock-names = usbhost;
status = disabled;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = exynos_usbphy 1;
+ status = disabled;
+ };
};
i2s1: i2s@1396 {
--
1.9.2
--
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: refactor Odroid DTS file and add support for Odroid X2 and U2/U3
This patch moves some parts of exynos4412-odroidx.dts to common
exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and
U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz
instead of 1.4GHz), while U2/U3 differs from X2 by different way of
routing signals to host USB hub. It also lacks some hw modules not yet
supported by those dts files (i.e. LCD touch panel).
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 319 +++
arch/arm/boot/dts/exynos4412-odroidu3.dts | 49
arch/arm/boot/dts/exynos4412-odroidx.dts| 326 +---
arch/arm/boot/dts/exynos4412-odroidx2.dts | 23 ++
5 files changed, 404 insertions(+), 315 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-odroid-common.dtsi
create mode 100644 arch/arm/boot/dts/exynos4412-odroidu3.dts
create mode 100644 arch/arm/boot/dts/exynos4412-odroidx2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff63b901..28b354936685 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,7 +66,9 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos4210-universal_c210.dtb \
+ exynos4412-odroidu3.dtb \
exynos4412-odroidx.dtb \
+ exynos4412-odroidx2.dtb \
exynos4412-origen.dtb \
exynos4412-smdk4412.dtb \
exynos4412-tiny4412.dtb \
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
new file mode 100644
index ..f793f3b8f0b9
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -0,0 +1,319 @@
+/*
+ * Common definition for Hardkernel's Exynos4412 based ODROID-X/X2/U2/U3 boards
+ * device tree source
+ *
+ * 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 exynos4412.dtsi
+
+/ {
+ firmware@0204F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0204F000 0x1000;
+ };
+
+ mmc@1255 {
+ pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
+ pinctrl-names = default;
+ vmmc-supply = ldo20_reg buck8_reg;
+ status = okay;
+
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ };
+ };
+
+ watchdog@1006 {
+ status = okay;
+ };
+
+ rtc@1007 {
+ status = okay;
+ };
+
+ g2d@1080 {
+ status = okay;
+ };
+
+ camera {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = ;
+
+ fimc_0: fimc@1180 {
+ status = okay;
+ };
+
+ fimc_1: fimc@1181 {
+ status = okay;
+ };
+
+ fimc_2: fimc@1182 {
+ status = okay;
+ };
+
+ fimc_3: fimc@1183 {
+ status = okay;
+ };
+ };
+
+ sdhci@1253 {
+ bus-width = 4;
+ pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
+ pinctrl-names = default;
+ vmmc-supply = ldo4_reg ldo21_reg;
+ status = okay;
+ };
+
+ serial@1380 {
+ status = okay;
+ };
+
+ serial@1381 {
+ status = okay;
+ };
+
+ fixed-rate-clocks {
+ xxti {
+ compatible = samsung,clock-xxti;
+ clock-frequency = 0;
+ };
+
+ xusbxti {
+ compatible = samsung,clock-xusbxti;
+ clock-frequency = 2400;
+ };
+ };
+
+ i2c@1386 {
+ pinctrl-0 = i2c0_bus;
+ pinctrl-names = default;
+ status = okay;
+
+ usb3503: usb3503@08 {
+ compatible = smsc,usb3503;
+ reg = 0x08;
+
+ intn-gpios = gpx3 0 0;
+ connect-gpios = gpx3 4 0;
+ reset-gpios = gpx3 5 0;
+ initial-mode = 1;
+ };
+
+ max77686: pmic@09 {
+ compatible = maxim,max77686;
+
[PATCH v2 0/4] Add Exynos4412 based Odroid X2 and U2/U3/U3+ support
Hello, This is the second version of the initial patch series adding support for Exynos 4412 based Odroid X2 and U2/U3/U3+ boards and improving support for Odroid X. Complete USB support for Odroid U2/U3/U3+ still requires some fixes in Exynos4 USB2 Phy driver and clock driver for CLKOUT: http://thread.gmane.org/gmane.linux.kernel/1731843/ http://www.spinics.net/lists/linux-usb/msg109587.html The above changes however don't affect Odroid DTS files, but without them, usb3503 hub is not yet functional. Support for audio codec will be posted separately by Sylwester Nawrocki soon. Support for HDMI video output will be also posted separately together with the required ExynosDRM-HDMI fixes. If one is interested in more complete and open-source Odroid board support, there are also patches for u-boot project: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188295/focus=188610 Best regards Marek Szyprowski Samsung RD Institute Poland Changelog: v2: - added fix for broken LAN after reboot (removed BUCK8 always on property) - restored all 4 uarts for Odroid X/X2 until correct patch for UART driver is developed - rmoved incorrect port@2 node in ehci node for odroidx dts - updated links for latest version of CLKOUT and PHY patches v1: - initial version Kamil Debski (2): ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device) ARM: dts: exynos4412-odroid-common: disable 'always on' for BUCK8 regulator Marek Szyprowski (3): ARM: dts: exynos4: add port sub-nodes to exynos usb host modules ARM: dts: exynos4412-odroidx: enable common hardware blocks ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3 arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/exynos4.dtsi | 24 ++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 318 arch/arm/boot/dts/exynos4412-odroidu3.dts | 49 arch/arm/boot/dts/exynos4412-odroidx.dts| 264 +--- arch/arm/boot/dts/exynos4412-odroidx2.dts | 23 ++ 6 files changed, 427 insertions(+), 253 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4412-odroid-common.dtsi create mode 100644 arch/arm/boot/dts/exynos4412-odroidu3.dts create mode 100644 arch/arm/boot/dts/exynos4412-odroidx2.dts -- 1.9.2 -- 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: exynos4412-odroidx: add support for USB (phy, host, device)
From: Kamil Debski k.deb...@samsung.com
This patch adds basic support for USB modules (host and device) on
OdroidX board.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[removed incorrect port@2 node]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index fda9ac23dd55..4c853fbf7202 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -148,6 +148,16 @@
pinctrl-names = default;
status = okay;
+ usb3503@08 {
+ compatible = smsc,usb3503;
+ reg = 0x08;
+
+ intn-gpios = gpx3 0 0;
+ connect-gpios = gpx3 4 0;
+ reset-gpios = gpx3 5 0;
+ initial-mode = 1;
+ };
+
max77686: pmic@09 {
compatible = maxim,max77686;
reg = 0x09;
@@ -338,4 +348,21 @@
};
};
};
+
+ exynos-usbphy@125B {
+ status = okay;
+ };
+
+ hsotg@1248 {
+ status = okay;
+ vusb_d-supply = ldo15_reg;
+ vusb_a-supply = ldo12_reg;
+ };
+
+ ehci@1258 {
+ status = okay;
+ port@1 {
+ status = okay;
+ };
+ };
};
--
1.9.2
--
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] ARM: dts: exynos4412-odroid-common: disable 'always on' for BUCK8 regulator
From: Kamil Debski k.deb...@samsung.com On Odroid U2/U3 BUCK8 is used for providing power to also to P3V3 source, which is also connected to LAN9730 chip's nRESET signal. To reset lan chip on system reboot, the BUCK8 output should not be used in 'always on' mode. This change has no impact on X/X2 boards. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index f793f3b8f0b9..ad2cb32a3439 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -297,7 +297,6 @@ regulator-name = BUCK8_2.8V; regulator-min-microvolt = 280; regulator-max-microvolt = 280; - regulator-always-on; }; }; }; -- 1.9.2 -- 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: exynos4412-odroidx: enable common hardware blocks
This patch adds support for common hardware modules available on all
Exynos4412-based Odroid boards, which already have complete support in
mainline kernel. This includes secure firmware calls, watchdog, g2d and
fimc (mem2mem) multimedia accelerators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 35
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a4bb33..fda9ac23dd55 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -22,6 +22,11 @@
reg = 0x4000 0x4000;
};
+ firmware@0204F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0204F000 0x1000;
+ };
+
leds {
compatible = gpio-leds;
led1 {
@@ -68,10 +73,40 @@
regulator-boot-on;
};
+ watchdog@1006 {
+ status = okay;
+ };
+
rtc@1007 {
status = okay;
};
+ g2d@1080 {
+ status = okay;
+ };
+
+ camera {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = ;
+
+ fimc_0: fimc@1180 {
+ status = okay;
+ };
+
+ fimc_1: fimc@1181 {
+ status = okay;
+ };
+
+ fimc_2: fimc@1182 {
+ status = okay;
+ };
+
+ fimc_3: fimc@1183 {
+ status = okay;
+ };
+ };
+
sdhci@1253 {
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
--
1.9.2
--
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/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25, 2014 at 11:37:54AM +0100, Marc Zyngier wrote:
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Just tested this on an Allwinner A31.
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
Tested-by: Maxime Ripard maxime.rip...@free-electrons.com
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v2 4/6] ARM: mm: l2x0: Add support for overriding prefetch settings
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
arch/arm/mm/cache-l2x0.c | 46 ++
2 files changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index b513cb8..8096fcd 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -44,6 +44,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 6600fd9..fd23cce 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1018,9 +1018,12 @@ static const struct l2c_init_data of_l2c220_data
__initconst = {
static void __init l2c310_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask)
{
+ bool set_prefetch = false;
u32 data[3] = { 0, 0, 0 };
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
+ u32 prefetch;
+ u32 val;
of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
if (tag[0] tag[1] tag[2])
@@ -1047,6 +1050,49 @@ static void __init l2c310_of_parse(const struct
device_node *np,
writel_relaxed((filter[0] ~(SZ_1M - 1)) | L310_ADDR_FILTER_EN,
l2x0_base + L310_ADDR_FILTER_START);
}
+
+ prefetch = readl_relaxed(l2x0_base + L310_PREFETCH_CTRL);
+
+ if (!of_property_read_u32(np, arm,double-linefill, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, arm,double-linefill-incr, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, arm,double-linefill-wrap, val)) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, arm,prefetch-drop, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ set_prefetch = true;
+ }
+
+ if (!of_property_read_u32(np, arm,prefetch-offset, val)) {
+ prefetch = ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val L310_PREFETCH_CTRL_OFFSET_MASK;
+ set_prefetch = true;
+ }
+
+ if (set_prefetch)
+ l2c_write_sec(prefetch, l2x0_base, L310_PREFETCH_CTRL);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.3
--
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/6] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec callback is provided by this patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 63 +
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index eb91d23..def7bb4 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -14,7 +14,9 @@
#include linux/of.h
#include linux/of_address.h
+#include asm/cputype.h
#include asm/firmware.h
+#include asm/hardware/cache-l2x0.h
#include mach/map.h
@@ -70,6 +72,57 @@ static const struct firmware_ops exynos_firmware_ops = {
.cpu_boot = exynos_cpu_boot,
};
+static void exynos_l2_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
+{
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val L2X0_CTRL_EN)
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_AUX_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP2,
+ readl_relaxed(base + L310_POWER_CTRL),
+ val, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ case L310_TAG_LATENCY_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ val,
+ readl_relaxed(base + L310_DATA_LATENCY_CTRL),
+ readl_relaxed(base + L310_PREFETCH_CTRL));
+ break;
+
+ case L310_DATA_LATENCY_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ readl_relaxed(base + L310_TAG_LATENCY_CTRL),
+ val,
+ readl_relaxed(base + L310_PREFETCH_CTRL));
+ break;
+
+ case L310_PREFETCH_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP1,
+ readl_relaxed(base + L310_TAG_LATENCY_CTRL),
+ readl_relaxed(base + L310_DATA_LATENCY_CTRL),
+ val);
+ break;
+
+ case L310_POWER_CTRL:
+ exynos_smc(SMC_CMD_L2X0SETUP2, val,
+ readl_relaxed(base + L2X0_AUX_CTRL), 0);
+ break;
+
+ default:
+ WARN_ONCE(1, %s: ignoring write to reg 0x%x\n, __func__, reg);
+ }
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -89,4 +142,14 @@ void __init exynos_firmware_init(void)
pr_info(Running under secure firmware.\n);
register_firmware_ops(exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
+ outer_cache.write_sec = exynos_l2_write_sec;
}
--
1.9.3
--
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/6] ARM: Get outer cache .write_sec callback from mach_desc only if not NULL
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 2c42576..e7383b9 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -125,7 +125,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_CACHE_L2X0)
(machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
- outer_cache.write_sec = machine_desc-l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc-l2c_write_sec;
ret = l2x0_of_init(machine_desc-l2c_aux_val,
machine_desc-l2c_aux_mask);
if (ret)
--
1.9.3
--
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/6] ARM: mm: cache-l2x0: Use l2c_write_sec() for LATENCY_CTRL registers
According to the documentation, TAG_LATENCY_CTRL and DATA_LATENCY_CTRL registers of L2C-310 can be written only in secure mode, so l2c_write_sec() should be used to change them, instead of plain writel_relaxed(). Signed-off-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mm/cache-l2x0.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 478566b..6600fd9 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -622,10 +622,10 @@ static void l2c310_resume(void) unsigned revision; /* restore pl310 setup */ - writel_relaxed(l2x0_saved_regs.tag_latency, - base + L310_TAG_LATENCY_CTRL); - writel_relaxed(l2x0_saved_regs.data_latency, - base + L310_DATA_LATENCY_CTRL); + l2c_write_sec(l2x0_saved_regs.tag_latency, + base, L310_TAG_LATENCY_CTRL); + l2c_write_sec(l2x0_saved_regs.data_latency, + base, L310_DATA_LATENCY_CTRL); writel_relaxed(l2x0_saved_regs.filter_end, base + L310_ADDR_FILTER_END); writel_relaxed(l2x0_saved_regs.filter_start, @@ -1024,20 +1024,20 @@ static void __init l2c310_of_parse(const struct device_node *np, of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag)); if (tag[0] tag[1] tag[2]) - writel_relaxed( + l2c_write_sec( L310_LATENCY_CTRL_RD(tag[0] - 1) | L310_LATENCY_CTRL_WR(tag[1] - 1) | L310_LATENCY_CTRL_SETUP(tag[2] - 1), - l2x0_base + L310_TAG_LATENCY_CTRL); + l2x0_base, L310_TAG_LATENCY_CTRL); of_property_read_u32_array(np, arm,data-latency, data, ARRAY_SIZE(data)); if (data[0] data[1] data[2]) - writel_relaxed( + l2c_write_sec( L310_LATENCY_CTRL_RD(data[0] - 1) | L310_LATENCY_CTRL_WR(data[1] - 1) | L310_LATENCY_CTRL_SETUP(data[2] - 1), - l2x0_base + L310_DATA_LATENCY_CTRL); + l2x0_base, L310_DATA_LATENCY_CTRL); of_property_read_u32_array(np, arm,filter-ranges, filter, ARRAY_SIZE(filter)); -- 1.9.3 -- 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 6/6] ARM: dts: exynos4: Add nodes for L2 cache controller
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..99970ab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -54,6 +54,15 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 2 2 1;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943d..ddffefe 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -60,6 +60,20 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 3 2 1;
+ arm,double-linefill = 1;
+ arm,double-linefill-incr = 0;
+ arm,double-linefill-wrap = 1;
+ arm,prefetch-drop = 1;
+ arm,prefetch-offset = 7;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.9.3
--
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/6] Enable L2 cache support on Exynos4210/4x12 SoCs
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
Patches 1-3 might affect other platforms using .write_sec callback, so
I'd like to kindly ask any interested people for testing.
Further two patches add impelmentation of .write_sec for Exynos secure
firmware and necessary DT nodes to enable L2 cache.
Tested on Exynos4210-based Universal C210 and Trats (both without secure
firmware) and Exynos4412-based TRATS2 and ODROID-U3 boards (both with secure
firmware).
Changes since v1:
(https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106323.html)
- rebased onto for-next branch of linux-samsung tree,
- changed argument order of outer_cache.write_sec() callback to match
l2c_write_sec() function in cache-l2x0.c,
- added support of overriding of prefetch settings to work around incorrect
default settings on certain Exynos4x12-based boards,
- added call to firmware to invalidate whole L2 cache before setting enable
bit in L2C control register (required by Exynos secure firmware).
Tomasz Figa (6):
ARM: mm: cache-l2x0: Add base address argument to write_sec callback
ARM: Get outer cache .write_sec callback from mach_desc only if not
NULL
ARM: mm: cache-l2x0: Use l2c_write_sec() for LATENCY_CTRL registers
ARM: mm: l2x0: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10
arch/arm/boot/dts/exynos4210.dtsi | 9
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/mach/arch.h | 3 +-
arch/arm/include/asm/outercache.h | 2 +-
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/firmware.c| 63 +
arch/arm/mach-highbank/highbank.c | 3 +-
arch/arm/mach-omap2/omap4-common.c | 3 +-
arch/arm/mach-ux500/cache-l2x0.c | 3 +-
arch/arm/mm/cache-l2x0.c | 64 ++
11 files changed, 162 insertions(+), 15 deletions(-)
--
1.9.3
--
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/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback
For certain platforms (e.g. Exynos) it is necessary to read back some
values from registers before they can be written (i.e. SMC calls that
set multiple registers per call), so base address of L2C controller is
needed for .write_sec operation. This patch adds base argument to
.write_sec callback so that its implementation can also access registers
directly.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/include/asm/mach/arch.h | 3 ++-
arch/arm/include/asm/outercache.h | 2 +-
arch/arm/mach-highbank/highbank.c | 3 ++-
arch/arm/mach-omap2/omap4-common.c | 3 ++-
arch/arm/mach-ux500/cache-l2x0.c | 3 ++-
arch/arm/mm/cache-l2x0.c | 2 +-
6 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 060a75e..fefff4d 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -46,7 +46,8 @@ struct machine_desc {
enum reboot_modereboot_mode;/* default restart mode */
unsignedl2c_aux_val;/* L2 cache aux value */
unsignedl2c_aux_mask; /* L2 cache aux mask*/
- void(*l2c_write_sec)(unsigned long, unsigned);
+ void(*l2c_write_sec)(unsigned long,
+void __iomem *, unsigned);
struct smp_operations *smp; /* SMP operations */
bool(*smp_init)(void);
void(*fixup)(struct tag *, char **);
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b..25b70b5 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -35,7 +35,7 @@ struct outer_cache_fns {
void (*resume)(void);
/* This is an ARM L2C thing */
- void (*write_sec)(unsigned long, unsigned);
+ void (*write_sec)(unsigned long, void __iomem *, unsigned);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 8c35ae4..20cf160 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -51,7 +51,8 @@ static void __init highbank_scu_map_io(void)
}
-static void highbank_l2c310_write_sec(unsigned long val, unsigned reg)
+static void highbank_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
if (reg == L2X0_CTRL)
highbank_smc1(0x102, val);
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 326cd98..ce04afa 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -167,7 +167,8 @@ void __iomem *omap4_get_l2cache_base(void)
return l2cache_base;
}
-static void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
+static void omap4_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
unsigned smc_op;
diff --git a/arch/arm/mach-ux500/cache-l2x0.c b/arch/arm/mach-ux500/cache-l2x0.c
index 842ebed..bd87108 100644
--- a/arch/arm/mach-ux500/cache-l2x0.c
+++ b/arch/arm/mach-ux500/cache-l2x0.c
@@ -35,7 +35,8 @@ static int __init ux500_l2x0_unlock(void)
return 0;
}
-static void ux500_l2c310_write_sec(unsigned long val, unsigned reg)
+static void ux500_l2c310_write_sec(unsigned long val, void __iomem *base,
+ unsigned reg)
{
/*
* We can't write to secure registers as we are in non-secure
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index efc5cab..478566b 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -72,7 +72,7 @@ static void l2c_write_sec(unsigned long val, void __iomem
*base, unsigned reg)
if (val == readl_relaxed(base + reg))
return;
if (outer_cache.write_sec)
- outer_cache.write_sec(val, reg);
+ outer_cache.write_sec(val, base, reg);
else
writel_relaxed(val, base + reg);
}
--
1.9.3
--
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 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs
On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: This series intends to add support for L2 cache on Exynos4 SoCs on boards running under secure firmware, which requires certain initialization steps to be done with help of firmware, as selected registers are writable only from secure mode. What I said in my message on June 12th applies to this series. I'm not having the virtual address exposed via the write_sec call. Yes, you need to read other registers in order to use your secure firmware implementation. Let's fix that by providing a better write_sec interface so you don't have to read back these registers, rather than working around this short-coming. That's exactly what I meant when I talked on June 12th about turning cache-l2x0.c back into a pile of crap. You're working around problems rather than fixing the underlying issue, as seems to be standard platform maintainer behaviour when things like core ARM code is concerned. This is why things devolve over time into piles of crap, because platforms just hack around problems rather than fixing the root cause of the problem. So... I'm NAKing the entire series. -- 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: [PATCH v2 3/5] ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device)
On Wed, Jun 25, 2014 at 6:56 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
From: Kamil Debski k.deb...@samsung.com
This patch adds basic support for USB modules (host and device) on
OdroidX board.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[removed incorrect port@2 node]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index fda9ac23dd55..4c853fbf7202 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -148,6 +148,16 @@
pinctrl-names = default;
status = okay;
+ usb3503@08 {
+ compatible = smsc,usb3503;
+ reg = 0x08;
+
+ intn-gpios = gpx3 0 0;
+ connect-gpios = gpx3 4 0;
+ reset-gpios = gpx3 5 0;
+ initial-mode = 1;
+ };
+
max77686: pmic@09 {
compatible = maxim,max77686;
reg = 0x09;
@@ -338,4 +348,21 @@
};
};
};
+
+ exynos-usbphy@125B {
+ status = okay;
+ };
+
+ hsotg@1248 {
+ status = okay;
+ vusb_d-supply = ldo15_reg;
+ vusb_a-supply = ldo12_reg;
Can you please point me to the documentation for these two properties
in the DT bindings ?
Which tree i should grep to find that ?
We have similar supplies for ehci/ohci and other host controllers too,
so just wondering
if we can use similar nomenclature for hsotg as well as host.
I have posted driver side patches for host (with DT documentation) a
while back :
https://lkml.org/lkml/2014/6/25/363
[snip]
--
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
[PATCH v5 0/5] ARM: Exynos: PMU cleanup and refactoring for using DT
This patch series, modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either drivers/mfd, or drivers/power or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches are created on top of Kukjin Kim's for-next. I have tested this patches on Exynos5250 Snow board for system boot and S2R. This patch series depends on following two patch series: [1]: mfd: syscon: Decouple syscon interface from syscon devices. https://lkml.org/lkml/2014/6/24/188 [2]: Cleanup patches for mach-exynos. http://www.spinics.net/lists/arm-kernel/msg341474.html Patch v4 and discussion can be found here: https://lkml.org/lkml/2014/5/10/29 Changes Since v4: - Splitted patch series in two parts. Part 1 has code cleanup under mach-exynos and posted as separate patch [2]. Current patchset is part 2 which modified exynos pmu implementation for making it platform driver. - Removed dependency over early_syscon API. - Removed usage of regmap read/write APIs. - Modified probe function to register exynos pmu as syscon provider using Tomasz Figa's syscon patch [1]. - Address various other review comments from Tomasz Figa. - Removed signed-off-by of Young-Gun Jang yg1004.j...@samsung.com, as this id is no more valid. Taking ownership of all his patches. Changes Since v3: - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init as suggested by Vikas Sajjan. - Modified syscon_early_regmap_lookup_by_phandle and syscon_regmap_lookup_by_phandle function call to pass property as NULL. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed early mapping of PMU base address from exynos.c and removed get_exynos_pmuaddr function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - 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. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - 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 (5): ARM: EXYNOS: Add support for mapping PMU base address via DT 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 platform driver support for Exynos PMU ARM: EXYNOS: Move PMU specific definitions from common.h arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/common.h| 18 +- arch/arm/mach-exynos/exynos-pmu.h| 31 ++ arch/arm/mach-exynos/exynos.c| 63 +++- arch/arm/mach-exynos/include/mach/map.h |3 - arch/arm/mach-exynos/mcpm-exynos.c |5 +- arch/arm/mach-exynos/platsmp.c |4 +- arch/arm/mach-exynos/pm.c| 80 ++-- arch/arm/mach-exynos/pmu.c | 223 --- arch/arm/mach-exynos/regs-pmu.h | 510 +- arch/arm/plat-samsung/include/plat/map-s5p.h |1 - 11 files changed, 556 insertions(+), 383 deletions(-) create mode 100644 arch/arm/mach-exynos/exynos-pmu.h -- 1.7.9.5 --
[PATCH v5 1/5] ARM: EXYNOS: Add support for mapping PMU base address via DT
Add support for mapping Samsung Power Management Unit (PMU)
base address from device tree.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h |1 +
arch/arm/mach-exynos/exynos.c | 45 +
2 files changed, 46 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 3f25f89..f3114be 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -113,6 +113,7 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID,
EXYNOS5_SOC_MASK)
extern void __iomem *sysram_ns_base_addr;
extern void __iomem *sysram_base_addr;
+extern void __iomem *pmu_base_addr;
void exynos_firmware_init(void);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4a69b3f..82dabc8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,8 @@
#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_domain.h
+#include linux/clocksource.h
+#include linux/clk-provider.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -31,6 +33,8 @@
#include regs-pmu.h
#include regs-sys.h
+void __iomem *pmu_base_addr;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -231,6 +235,46 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = samsung,exynos3250-pmu },
+ { .compatible = samsung,exynos4210-pmu },
+ { .compatible = samsung,exynos4212-pmu },
+ { .compatible = samsung,exynos4412-pmu },
+ { .compatible = samsung,exynos5250-pmu },
+ { .compatible = samsung,exynos5420-pmu },
+ {},
+};
+
+static void exynos_map_pmu(void)
+{
+ struct device_node *np = NULL;
+
+ np = of_find_matching_node(NULL, exynos_dt_pmu_match);
+
+ if (!np) {
+ pr_err(Failed to find PMU node\n);
+ return;
+ }
+
+ pmu_base_addr = of_iomap(np, 0);
+
+ if (!pmu_base_addr)
+ panic(failed to find exynos pmu register\n);
+}
+
+static void __init exynos_init_time(void)
+{
+ /* Nothing to do timer specific.
+* Since platsmp.c needs pmu base address by the time
+* DT is not unflatten so we can't use DT APIs before
+* init_time
+*/
+ exynos_map_pmu();
+
+ of_clk_init(NULL);
+ clocksource_of_init();
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -306,6 +350,7 @@ DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened
Device Tree))
.smp= smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
+ .init_time = exynos_init_time,
.init_machine = exynos_dt_machine_init,
.init_late = exynos_init_late,
.dt_compat = exynos_dt_compat,
--
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 v5 4/5] ARM: EXYNOS: Add platform driver support for Exynos PMU
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform driver support and probe function where Exynos PMU
driver will register itself as syscon provider with syscon framework.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynosXYZ().
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/pmu.c | 201 +-
2 files changed, 161 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index d58995c9..c4320e6 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -25,6 +25,7 @@ config ARCH_EXYNOS
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select SRAM
+ select MFD_SYSCON
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index a6f034c..c80a648 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -9,13 +9,32 @@
* published by the Free Software Foundation.
*/
+#include linux/module.h
#include linux/io.h
-#include linux/kernel.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
-static const struct exynos_pmu_conf *exynos_pmu_config;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ struct exynos_pmu_data *pmu_data;
+};
+
+static void __iomem *pmu_base_addr;
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
@@ -93,7 +112,7 @@ static const struct exynos_pmu_conf exynos4210_pmu_config[]
= {
{ PMU_TABLE_END,},
};
-static const struct exynos_pmu_conf exynos4x12_pmu_config[] = {
+static const struct exynos_pmu_conf exynos4212_pmu_config[] = {
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
{ S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
{ S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
@@ -335,7 +354,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+static void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -372,51 +391,151 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
- exynos5_init_pmu();
+ struct exynos_pmu_data *pmu_data = pmu_context-pmu_data;
+
+ if (!pmu_data)
+ return;
- for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- __raw_writel(exynos_pmu_config[i].val[mode],
- pmu_base_addr + exynos_pmu_config[i].offset);
+ if (pmu_data-powerdown_conf)
+ pmu_data-powerdown_conf(mode);
- if (soc_is_exynos4412()) {
- for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END ;
i++)
- __raw_writel(exynos4412_pmu_config[i].val[mode],
- pmu_base_addr +
exynos4412_pmu_config[i].offset);
+ if (pmu_data-pmu_config) {
+ for (i = 0; (pmu_data-pmu_config[i].offset != PMU_TABLE_END) ;
i++)
+ __raw_writel(pmu_data-pmu_config[i].val[mode],
+ pmu_base_addr +
pmu_data-pmu_config[i].offset);
+ }
+
+ if (pmu_data-pmu_config_extra) {
+ for (i = 0; pmu_data-pmu_config_extra[i].offset !=
PMU_TABLE_END; i++)
+ __raw_writel(pmu_data-pmu_config_extra[i].val[mode],
+ pmu_base_addr +
pmu_data-pmu_config_extra[i].offset);
}
}
-static int __init exynos_pmu_init(void)
+static void exynos5250_pmu_init(void)
{
unsigned int value;
+ /*
+* When SYS_WDTRESET is set, watchdog timer reset request
+* is ignored by power management unit.
+*/
+
[PATCH v5 2/5] 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 iomapped address.
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/exynos.c| 18 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/mcpm-exynos.c |5 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c| 79 ++--
arch/arm/mach-exynos/pmu.c | 36 +-
arch/arm/mach-exynos/regs-pmu.h | 508 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |1 -
9 files changed, 324 insertions(+), 332 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f3114be..296c6e1 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -137,7 +137,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END (-1U)
enum sys_powerdown {
SYS_AFTR,
@@ -147,7 +147,7 @@ enum sys_powerdown {
};
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 82dabc8..01d746a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -62,11 +62,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -140,11 +135,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -152,7 +142,7 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
{
struct device_node *np;
u32 val = 0x1;
- void __iomem *addr = EXYNOS_SWRESET;
+ void __iomem *addr = NULL;
if (of_machine_is_compatible(samsung,exynos5440)) {
u32 status;
@@ -165,9 +155,9 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
val = __raw_readl(addr);
val = (val 0x) | (status 0x);
- }
-
- __raw_writel(val, addr);
+ __raw_writel(val, addr);
+ } else
+ __raw_writel(val, pmu_base_addr + EXYNOS_SWRESET);
}
static struct platform_device exynos_cpuidle = {
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 963002f..f0b7e92 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -27,9 +27,6 @@
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
-#define EXYNOS4_PA_PMU 0x1002
-#define EXYNOS5_PA_PMU 0x1004
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index ace0ed6..60ac5d66 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -51,7 +51,7 @@
dsb\n\t \
ldmfd sp!, {fp, ip} \
: \
- : Ir (S5P_INFORM0) \
+ : Ir (pmu_base_addr + S5P_INFORM0) \
: r0, r1, r2, r3, r4, r5, r6, r7, \
r9, r10, lr, memory)
@@ -325,7 +325,8 @@ static int __init exynos_mcpm_init(void)
* To increase the stability of KFC reset we need to program
* the PMU SPARE3 register
*/
- __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL,
+ pmu_base_addr + S5P_PMU_SPARE3);
[PATCH v5 3/5] 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 Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/platsmp.c |2 ++ arch/arm/mach-exynos/regs-pmu.h |2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 4b934e3..71add5b 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -26,6 +26,8 @@ #include asm/smp_scu.h #include asm/firmware.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 77afda4..efad6cb 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.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 1/4 v2] devicetree: bindings: Document murata vendor prefix
On 06/24/2014 11:29 PM, Naveen Krishna Chatradhi wrote: Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Acked-by: Mark Rutland mark.rutl...@arm.com Cc: Guenter Roeck li...@roeck-us.net Applied. Thanks, Guenter -- 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/4 v2] hwmon: ntc_thermistor: Use the manufacturer name properly
On 06/24/2014 11:29 PM, Naveen Krishna Chatradhi wrote: Murata Manufacturing Co., Ltd is the vendor for NTC (Negative Temperature coefficient) based Thermistors. But, the driver extensively uses NTC as the vendor name. This patch corrects the vendor name also updates the compatibility strings according to the vendor-prefix.txt Note: Drivers continue to support the previous compatible strings but further addition of these compatible strings in device tree is deprecated. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Guenter Roeck li...@roeck-us.net Applied. Guenter -- 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
