[PATCH 1/2] ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats

[Krzysztof Kozlowski]

Enable the kernel NEON mode and asm/NEON accelerated crypto algorithms
which should bring performance benefits on Exynos SoCs. Enable these as
modules because they are optional, not essential anyhow for platform
booting nor related directly to Exynos Soc. All accelerated algorithms
pass booting self-tests on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412).

Additionally enable cpufreq statistics as they are useful for debugging.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
 arch/arm/configs/exynos_defconfig | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 24dcd2bb1215..0aee1e035be9 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -26,12 +26,14 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC1,115200 init=/linuxrc mem=256M"
 CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_CPU_IDLE=y
 CONFIG_ARM_EXYNOS_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
+CONFIG_KERNEL_MODE_NEON=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -238,7 +240,11 @@ CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_DEBUG_USER=y
-CONFIG_CRYPTO_SHA256=y
+CONFIG_ARM_CRYPTO=y
+CONFIG_CRYPTO_SHA1_ARM_NEON=m
+CONFIG_CRYPTO_SHA256_ARM=m
+CONFIG_CRYPTO_SHA512_ARM=m
+CONFIG_CRYPTO_AES_ARM_BS=m
 CONFIG_CRC_CCITT=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
-- 
1.9.1

--
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] ARM: exynos_defconfig: Enable s5p-secss driver

[Krzysztof Kozlowski]

The Exynos SoC provides a Security SubSystem block for accelerating some
cryptographic operations. Enable the driver for it - s5p-secss to
utilize the hardware acceleration.

Currently the s5p-secss driver supports AES in CBC and ECB modes.
However on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412) boards this
change introduces one booting error:

alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: ret=22

The cbc-aes-s5p properly registers itself and passes self-tests.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 0aee1e035be9..c47c7e069873 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -240,6 +240,7 @@ CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_S5P=y
 CONFIG_ARM_CRYPTO=y
 CONFIG_CRYPTO_SHA1_ARM_NEON=m
 CONFIG_CRYPTO_SHA256_ARM=m
-- 
1.9.1

--
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 1/3] rtc: s5m: Cleanup by removing useless 'rtc' prefix from fields

[Krzysztof Kozlowski]

On 05.01.2016 02:08, Alexandre Belloni wrote:
> Hi,
> 
> On 30/12/2015 at 13:47:25 +0900, Krzysztof Kozlowski wrote :
>> Remove the 'rtc' prefix from some of the fields in struct
>> s5m_rtc_reg_config because it is obvious - this is a RTC driver. No
>> functional changes.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>
> 
> I was going to apply those patches but they don't apply cleanly on
> rtc-next. Did I miss something?
> 

Probably that's my fault because I rebased it on linux-next. I will
rebase the patches on rtc-next and resend.

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 v2 1/3] rtc: s5m: Cleanup by removing useless 'rtc' prefix from fields

[Krzysztof Kozlowski]

On 05.01.2016 08:53, Krzysztof Kozlowski wrote:
> On 05.01.2016 02:08, Alexandre Belloni wrote:
>> Hi,
>>
>> On 30/12/2015 at 13:47:25 +0900, Krzysztof Kozlowski wrote :
>>> Remove the 'rtc' prefix from some of the fields in struct
>>> s5m_rtc_reg_config because it is obvious - this is a RTC driver. No
>>> functional changes.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>
>>
>> I was going to apply those patches but they don't apply cleanly on
>> rtc-next. Did I miss something?
>>
> 
> Probably that's my fault because I rebased it on linux-next. I will
> rebase the patches on rtc-next and resend.

Ah, no need for rebasing. I forgot about dependency - the support for
S2MPS15 was added recently through Lee Jones' tree. Fortunately Lee put
S2MPS15 patches in a separate branch and tag: "ib-mfd-regulator-rtc-4.5"

This means that to apply the patches this is needed first:
https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/log/?h=ib-mfd-regulator-rtc-4.5

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: [rtc-linux] Re: [PATCH v2 3/3] rtc: s5m: Make register configuration per S2MPS device to remove exceptions

[Krzysztof Kozlowski]

2015-12-30 19:14 GMT+09:00 Alim Akhtar <alim.akh...@samsung.com>:
>
> Hi Krzysztof,
>
> On 12/30/2015 10:17 AM, Krzysztof Kozlowski wrote:
>>
>> Before updating time and alarm the driver must set appropriate mask in
>> UDR register. For that purpose the driver uses common register
>> configuration and a lot of exceptions per device in the code. The
>> exceptions are not obvious, for example except the change in the logic
>> sometimes the fields are swapped (WUDR and AUDR between S2MPS14 and
>> S2MPS15). This leads to quite complicated code.
>>
>> Try to make it more obvious by:
>> 1. Documenting the UDR masks for devices and operations.
>> 2. Adding fields in register configuration structure for each operation
>> (read time, write time and alarm).
>> 3. Splitting the configuration per S2MPS13, S2MPS14 and S2MPS15 thus
>> removing exceptions for them.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>
> Tested for s2mps15 pmic on exynos7-espresso board. rtc and timer works as 
> expected.
> Fill free to add
> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
> Tested-by: Alim Akhtar <alim.akh...@samsung.com>
>

Thank you, I really appreciate this!

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 2/3] rtc: s5m: Add separate field for storing auto-cleared mask in register config

[Krzysztof Kozlowski]

Some devices from S2M/S5M family use different register update masks for
different operations (alarm and register update). Now the driver uses
common register configuration and a lot of exceptions per device in code.

Before eliminating the exceptions and using specific register
configuration for given device, make the auto-cleared mask a separate
field. This is merely a refactoring.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
 drivers/rtc/rtc-s5m.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 85649861a6b0..559db8f72117 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -56,6 +56,8 @@ struct s5m_rtc_reg_config {
 * auto-cleared after successful update.
 */
unsigned int udr_update;
+   /* Auto-cleared mask in UDR field for writing time and alarm */
+   unsigned int autoclear_udr_mask;
/* Mask for UDR field in 'udr_update' register */
unsigned int udr_mask;
 };
@@ -68,6 +70,7 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.alarm0 = S5M_ALARM0_SEC,
.alarm1 = S5M_ALARM1_SEC,
.udr_update = S5M_RTC_UDR_CON,
+   .autoclear_udr_mask = S5M_RTC_UDR_MASK,
.udr_mask   = S5M_RTC_UDR_MASK,
 };
 
@@ -82,6 +85,7 @@ static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
.alarm0 = S2MPS_ALARM0_SEC,
.alarm1 = S2MPS_ALARM1_SEC,
.udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
.udr_mask   = S2MPS_RTC_WUDR_MASK,
 };
 
@@ -167,7 +171,7 @@ static inline int s5m8767_wait_for_udr_update(struct 
s5m_rtc_info *info)
 
do {
ret = regmap_read(info->regmap, info->regs->udr_update, );
-   } while (--retry && (data & info->regs->udr_mask) && !ret);
+   } while (--retry && (data & info->regs->autoclear_udr_mask) && !ret);
 
if (!retry)
dev_err(info->dev, "waiting for UDR update, reached max number 
of retries\n");
-- 
1.9.1

--
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/3] rtc: s5m: Make register configuration per S2MPS device to remove exceptions

[Krzysztof Kozlowski]

Before updating time and alarm the driver must set appropriate mask in
UDR register. For that purpose the driver uses common register
configuration and a lot of exceptions per device in the code. The
exceptions are not obvious, for example except the change in the logic
sometimes the fields are swapped (WUDR and AUDR between S2MPS14 and
S2MPS15). This leads to quite complicated code.

Try to make it more obvious by:
1. Documenting the UDR masks for devices and operations.
2. Adding fields in register configuration structure for each operation
   (read time, write time and alarm).
3. Splitting the configuration per S2MPS13, S2MPS14 and S2MPS15 thus
   removing exceptions for them.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

---

Tested only on S2MPS11 (Odroid XU4).
---
 drivers/rtc/rtc-s5m.c   | 110 +++-
 include/linux/mfd/samsung/rtc.h |   2 +
 2 files changed, 77 insertions(+), 35 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 559db8f72117..7407d7394bb4 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -38,7 +38,22 @@
  */
 #define UDR_READ_RETRY_CNT 5
 
-/* Registers used by the driver which are different between chipsets. */
+/*
+ * Registers used by the driver which are different between chipsets.
+ *
+ * Operations like read time and write alarm/time require updating
+ * specific fields in UDR register. These fields usually are auto-cleared
+ * (with some exceptions).
+ *
+ * Table of operations per device:
+ *
+ * Device | Write time | Read time | Write alarm
+ * =
+ * S5M8767| UDR + TIME |   | UDR
+ * S2MPS11/14 | WUDR   | RUDR  | WUDR + RUDR
+ * S2MPS13| WUDR   | RUDR  | WUDR + AUDR
+ * S2MPS15| WUDR   | RUDR  | AUDR
+ */
 struct s5m_rtc_reg_config {
/* Number of registers used for setting time/alarm0/alarm1 */
unsigned int regs_count;
@@ -58,8 +73,13 @@ struct s5m_rtc_reg_config {
unsigned int udr_update;
/* Auto-cleared mask in UDR field for writing time and alarm */
unsigned int autoclear_udr_mask;
-   /* Mask for UDR field in 'udr_update' register */
-   unsigned int udr_mask;
+   /*
+* Masks in UDR field for time and alarm operations.
+* The read time mask can be 0. Rest should not.
+*/
+   unsigned int read_time_udr_mask;
+   unsigned int write_time_udr_mask;
+   unsigned int write_alarm_udr_mask;
 };
 
 /* Register map for S5M8763 and S5M8767 */
@@ -71,14 +91,44 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.alarm1 = S5M_ALARM1_SEC,
.udr_update = S5M_RTC_UDR_CON,
.autoclear_udr_mask = S5M_RTC_UDR_MASK,
-   .udr_mask   = S5M_RTC_UDR_MASK,
+   .read_time_udr_mask = 0, /* Not needed */
+   .write_time_udr_mask= S5M_RTC_UDR_MASK | S5M_RTC_TIME_EN_MASK,
+   .write_alarm_udr_mask   = S5M_RTC_UDR_MASK,
+};
+
+/* Register map for S2MPS13 */
+static const struct s5m_rtc_reg_config s2mps13_rtc_regs = {
+   .regs_count = 7,
+   .time   = S2MPS_RTC_SEC,
+   .ctrl   = S2MPS_RTC_CTRL,
+   .alarm0 = S2MPS_ALARM0_SEC,
+   .alarm1 = S2MPS_ALARM1_SEC,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
+   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
+   .write_time_udr_mask= S2MPS_RTC_WUDR_MASK,
+   .write_alarm_udr_mask   = S2MPS_RTC_WUDR_MASK | S2MPS13_RTC_AUDR_MASK,
+};
+
+/* Register map for S2MPS11/14 */
+static const struct s5m_rtc_reg_config s2mps14_rtc_regs = {
+   .regs_count = 7,
+   .time   = S2MPS_RTC_SEC,
+   .ctrl   = S2MPS_RTC_CTRL,
+   .alarm0 = S2MPS_ALARM0_SEC,
+   .alarm1 = S2MPS_ALARM1_SEC,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
+   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
+   .write_time_udr_mask= S2MPS_RTC_WUDR_MASK,
+   .write_alarm_udr_mask   = S2MPS_RTC_WUDR_MASK | S2MPS_RTC_RUDR_MASK,
 };
 
 /*
- * Register map for S2MPS14.
- * It may be also suitable for S2MPS11 but this was not tested.
+ * Register map for S2MPS15 - in comparison to S2MPS14 the WUDR and AUDR bits
+ * are swapped.
  */
-static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
+static const struct s5m_rtc_reg_config s2mps15_rtc_regs = {
.regs_count = 7,
.time   = S2MPS_RTC_SEC,
.ctrl   = S2MPS_RTC_CTRL,
@@ -86,7 +136,9 @@ static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
.alarm1 = S2MPS_ALARM1_SEC,
.udr_update = S2MPS_RTC_U

[PATCH 1/3] rtc: s5m: Cleanup by removing useless 'rtc' prefix from fields

[Krzysztof Kozlowski]

Remove the 'rtc' prefix from some of the fields in struct
s5m_rtc_reg_config because it is obvious - this is a RTC driver. No
functional changes.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
 drivers/rtc/rtc-s5m.c | 40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 0d68a85dd429..85649861a6b0 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -55,9 +55,9 @@ struct s5m_rtc_reg_config {
 * will enable update of time or alarm register. Then it will be
 * auto-cleared after successful update.
 */
-   unsigned int rtc_udr_update;
-   /* Mask for UDR field in 'rtc_udr_update' register */
-   unsigned int rtc_udr_mask;
+   unsigned int udr_update;
+   /* Mask for UDR field in 'udr_update' register */
+   unsigned int udr_mask;
 };
 
 /* Register map for S5M8763 and S5M8767 */
@@ -67,8 +67,8 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.ctrl   = S5M_ALARM1_CONF,
.alarm0 = S5M_ALARM0_SEC,
.alarm1 = S5M_ALARM1_SEC,
-   .rtc_udr_update = S5M_RTC_UDR_CON,
-   .rtc_udr_mask   = S5M_RTC_UDR_MASK,
+   .udr_update = S5M_RTC_UDR_CON,
+   .udr_mask   = S5M_RTC_UDR_MASK,
 };
 
 /*
@@ -81,8 +81,8 @@ static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
.ctrl   = S2MPS_RTC_CTRL,
.alarm0 = S2MPS_ALARM0_SEC,
.alarm1 = S2MPS_ALARM1_SEC,
-   .rtc_udr_update = S2MPS_RTC_UDR_CON,
-   .rtc_udr_mask   = S2MPS_RTC_WUDR_MASK,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .udr_mask   = S2MPS_RTC_WUDR_MASK,
 };
 
 struct s5m_rtc_info {
@@ -166,9 +166,8 @@ static inline int s5m8767_wait_for_udr_update(struct 
s5m_rtc_info *info)
unsigned int data;
 
do {
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update,
-   );
-   } while (--retry && (data & info->regs->rtc_udr_mask) && !ret);
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
+   } while (--retry && (data & info->regs->udr_mask) && !ret);
 
if (!retry)
dev_err(info->dev, "waiting for UDR update, reached max number 
of retries\n");
@@ -214,7 +213,7 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
int ret;
unsigned int data;
 
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update, );
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
if (ret < 0) {
dev_err(info->dev, "failed to read update reg(%d)\n", ret);
return ret;
@@ -223,21 +222,20 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
switch (info->device_type) {
case S5M8763X:
case S5M8767X:
-   data |= info->regs->rtc_udr_mask | S5M_RTC_TIME_EN_MASK;
+   data |= info->regs->udr_mask | S5M_RTC_TIME_EN_MASK;
case S2MPS15X:
/* As per UM, for write time register, set WUDR bit to high */
data |= S2MPS15_RTC_WUDR_MASK;
break;
case S2MPS14X:
case S2MPS13X:
-   data |= info->regs->rtc_udr_mask;
+   data |= info->regs->udr_mask;
break;
default:
return -EINVAL;
}
 
-
-   ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
+   ret = regmap_write(info->regmap, info->regs->udr_update, data);
if (ret < 0) {
dev_err(info->dev, "failed to write update reg(%d)\n", ret);
return ret;
@@ -253,14 +251,14 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
int ret;
unsigned int data;
 
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update, );
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
if (ret < 0) {
dev_err(info->dev, "%s: fail to read update reg(%d)\n",
__func__, ret);
return ret;
}
 
-   data |= info->regs->rtc_udr_mask;
+   data |= info->regs->udr_mask;
switch (info->device_type) {
case S5M8763X:
case S5M8767X:
@@ -268,7 +266,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
break;
case S2MPS15X:
/* As per UM, for write alarm, set A_UDR(bit[4]) to high
-* rtc_udr_mask above sets bit[4]
+

Re: [PATCH 3/3] rtc: s5m: Make register configuration per S2MPS device to remove exceptions

[Krzysztof Kozlowski]

On 30.12.2015 11:53, Yadwinder Singh Brar wrote:
> Hi Krysztof,
> 
> On Tue, Dec 29, 2015 at 5:53 PM, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> Before updating time and alarm the driver must set appropriate mask in
>> UDR register. For that purpose the driver uses common register
>> configuration and a lot of exceptions per device in the code. The
>> exceptions are not obvious, for example except the change in the logic
>> sometimes the fields are swapped (WUDR and AUDR between S2MPS14 and
>> S2MPS15). This leads to quite complicated code.
>>
>> Try to make it more obvious by:
>> 1. Documenting the UDR masks for devices and operations.
>> 2. Adding fields in register configuration structure for each operation
>>(read time, write time and alarm).
>> 3. Splitting the configuration per S2MPS13, S2MPS14 and S2MPS15 thus
>>removing exceptions for them.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>
>> ---
>>
>> Tested only on S2MPS11 (Odroid XU4).
>> ---
>>  drivers/rtc/rtc-s5m.c   | 110 
>> +++-
>>  include/linux/mfd/samsung/rtc.h |   2 +
>>  2 files changed, 77 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>> index 559db8f72117..7407d7394bb4 100644
>> --- a/drivers/rtc/rtc-s5m.c
>> +++ b/drivers/rtc/rtc-s5m.c
>> @@ -38,7 +38,22 @@
>>   */
>>  #define UDR_READ_RETRY_CNT 5
>>
>> -/* Registers used by the driver which are different between chipsets. */
>> +/*
>> + * Registers used by the driver which are different between chipsets.
>> + *
>> + * Operations like read time and write alarm/time require updating
>> + * specific fields in UDR register. These fields usually are auto-cleared
>> + * (with some exceptions).
>> + *
>> + * Table of operations per device:
>> + *
>> + * Device | Write time | Read time | Write alarm
>> + * =
>> + * S5M8767| UDR + TIME |   | UDR
>> + * S2MPS11/14 | WUDR   | RUDR  | WUDR + RUDR
>> + * S2MPS13| WUDR   | RUDR  | WUDR + AUDR
>> + * S2MPS15| WUDR   | RUDR  | AUDR
>> + */
>>  struct s5m_rtc_reg_config {
>> /* Number of registers used for setting time/alarm0/alarm1 */
>> unsigned int regs_count;
>> @@ -58,8 +73,13 @@ struct s5m_rtc_reg_config {
>> unsigned int udr_update;
>> /* Auto-cleared mask in UDR field for writing time and alarm */
>> unsigned int autoclear_udr_mask;
>> -   /* Mask for UDR field in 'udr_update' register */
>> -   unsigned int udr_mask;
>> +   /*
>> +* Masks in UDR field for time and alarm operations.
>> +* The read time mask can be 0. Rest should not.
>> +*/
>> +   unsigned int read_time_udr_mask;
>> +   unsigned int write_time_udr_mask;
>> +   unsigned int write_alarm_udr_mask;
>>  };
>>
>>  /* Register map for S5M8763 and S5M8767 */
>> @@ -71,14 +91,44 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
>> .alarm1 = S5M_ALARM1_SEC,
>> .udr_update = S5M_RTC_UDR_CON,
>> .autoclear_udr_mask = S5M_RTC_UDR_MASK,
>> -   .udr_mask   = S5M_RTC_UDR_MASK,
>> +   .read_time_udr_mask = 0, /* Not needed */
>> +   .write_time_udr_mask= S5M_RTC_UDR_MASK | S5M_RTC_TIME_EN_MASK,
>> +   .write_alarm_udr_mask   = S5M_RTC_UDR_MASK,
>> +};
>> +
>> +/* Register map for S2MPS13 */
>> +static const struct s5m_rtc_reg_config s2mps13_rtc_regs = {
>> +   .regs_count = 7,
>> +   .time   = S2MPS_RTC_SEC,
>> +   .ctrl   = S2MPS_RTC_CTRL,
>> +   .alarm0 = S2MPS_ALARM0_SEC,
>> +   .alarm1 = S2MPS_ALARM1_SEC,
>> +   .udr_update = S2MPS_RTC_UDR_CON,
>> +   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
>> +   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
>> +   .write_time_udr_mask= S2MPS_RTC_WUDR_MASK,
>> +   .write_alarm_udr_mask   = S2MPS_RTC_WUDR_MASK | 
>> S2MPS13_RTC_AUDR_MASK,
>> +};
>> +
>> +/* Register map for S2MPS11/14 */
>> +static const struct s5m_rtc_reg_config s2mps14_rtc_regs = {
>> +   .regs_count = 7,
>> +   .time   = S2MPS_RTC_SEC,
>> +   .ctrl   = S2MPS_RTC_CT

[PATCH v2 2/3] rtc: s5m: Add separate field for storing auto-cleared mask in register config

[Krzysztof Kozlowski]

Some devices from S2M/S5M family use different register update masks for
different operations (alarm and register update). Now the driver uses
common register configuration and a lot of exceptions per device in code.

Before eliminating the exceptions and using specific register
configuration for given device, make the auto-cleared mask a separate
field. This is merely a refactoring.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

---

Changes since v1:
1. None.
---
 drivers/rtc/rtc-s5m.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 85649861a6b0..559db8f72117 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -56,6 +56,8 @@ struct s5m_rtc_reg_config {
 * auto-cleared after successful update.
 */
unsigned int udr_update;
+   /* Auto-cleared mask in UDR field for writing time and alarm */
+   unsigned int autoclear_udr_mask;
/* Mask for UDR field in 'udr_update' register */
unsigned int udr_mask;
 };
@@ -68,6 +70,7 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.alarm0 = S5M_ALARM0_SEC,
.alarm1 = S5M_ALARM1_SEC,
.udr_update = S5M_RTC_UDR_CON,
+   .autoclear_udr_mask = S5M_RTC_UDR_MASK,
.udr_mask   = S5M_RTC_UDR_MASK,
 };
 
@@ -82,6 +85,7 @@ static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
.alarm0 = S2MPS_ALARM0_SEC,
.alarm1 = S2MPS_ALARM1_SEC,
.udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
.udr_mask   = S2MPS_RTC_WUDR_MASK,
 };
 
@@ -167,7 +171,7 @@ static inline int s5m8767_wait_for_udr_update(struct 
s5m_rtc_info *info)
 
do {
ret = regmap_read(info->regmap, info->regs->udr_update, );
-   } while (--retry && (data & info->regs->udr_mask) && !ret);
+   } while (--retry && (data & info->regs->autoclear_udr_mask) && !ret);
 
if (!retry)
dev_err(info->dev, "waiting for UDR update, reached max number 
of retries\n");
-- 
1.9.1

--
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/3] rtc: s5m: Cleanup by removing useless 'rtc' prefix from fields

[Krzysztof Kozlowski]

Remove the 'rtc' prefix from some of the fields in struct
s5m_rtc_reg_config because it is obvious - this is a RTC driver. No
functional changes.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

---

Changes since v1:
1. None.
---
 drivers/rtc/rtc-s5m.c | 40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 0d68a85dd429..85649861a6b0 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -55,9 +55,9 @@ struct s5m_rtc_reg_config {
 * will enable update of time or alarm register. Then it will be
 * auto-cleared after successful update.
 */
-   unsigned int rtc_udr_update;
-   /* Mask for UDR field in 'rtc_udr_update' register */
-   unsigned int rtc_udr_mask;
+   unsigned int udr_update;
+   /* Mask for UDR field in 'udr_update' register */
+   unsigned int udr_mask;
 };
 
 /* Register map for S5M8763 and S5M8767 */
@@ -67,8 +67,8 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.ctrl   = S5M_ALARM1_CONF,
.alarm0 = S5M_ALARM0_SEC,
.alarm1 = S5M_ALARM1_SEC,
-   .rtc_udr_update = S5M_RTC_UDR_CON,
-   .rtc_udr_mask   = S5M_RTC_UDR_MASK,
+   .udr_update = S5M_RTC_UDR_CON,
+   .udr_mask   = S5M_RTC_UDR_MASK,
 };
 
 /*
@@ -81,8 +81,8 @@ static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
.ctrl   = S2MPS_RTC_CTRL,
.alarm0 = S2MPS_ALARM0_SEC,
.alarm1 = S2MPS_ALARM1_SEC,
-   .rtc_udr_update = S2MPS_RTC_UDR_CON,
-   .rtc_udr_mask   = S2MPS_RTC_WUDR_MASK,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .udr_mask   = S2MPS_RTC_WUDR_MASK,
 };
 
 struct s5m_rtc_info {
@@ -166,9 +166,8 @@ static inline int s5m8767_wait_for_udr_update(struct 
s5m_rtc_info *info)
unsigned int data;
 
do {
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update,
-   );
-   } while (--retry && (data & info->regs->rtc_udr_mask) && !ret);
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
+   } while (--retry && (data & info->regs->udr_mask) && !ret);
 
if (!retry)
dev_err(info->dev, "waiting for UDR update, reached max number 
of retries\n");
@@ -214,7 +213,7 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
int ret;
unsigned int data;
 
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update, );
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
if (ret < 0) {
dev_err(info->dev, "failed to read update reg(%d)\n", ret);
return ret;
@@ -223,21 +222,20 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
switch (info->device_type) {
case S5M8763X:
case S5M8767X:
-   data |= info->regs->rtc_udr_mask | S5M_RTC_TIME_EN_MASK;
+   data |= info->regs->udr_mask | S5M_RTC_TIME_EN_MASK;
case S2MPS15X:
/* As per UM, for write time register, set WUDR bit to high */
data |= S2MPS15_RTC_WUDR_MASK;
break;
case S2MPS14X:
case S2MPS13X:
-   data |= info->regs->rtc_udr_mask;
+   data |= info->regs->udr_mask;
break;
default:
return -EINVAL;
}
 
-
-   ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
+   ret = regmap_write(info->regmap, info->regs->udr_update, data);
if (ret < 0) {
dev_err(info->dev, "failed to write update reg(%d)\n", ret);
return ret;
@@ -253,14 +251,14 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
int ret;
unsigned int data;
 
-   ret = regmap_read(info->regmap, info->regs->rtc_udr_update, );
+   ret = regmap_read(info->regmap, info->regs->udr_update, );
if (ret < 0) {
dev_err(info->dev, "%s: fail to read update reg(%d)\n",
__func__, ret);
return ret;
}
 
-   data |= info->regs->rtc_udr_mask;
+   data |= info->regs->udr_mask;
switch (info->device_type) {
case S5M8763X:
case S5M8767X:
@@ -268,7 +266,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
break;
case S2MPS15X:
/* As per UM, for write alarm, set A_UDR(bit[4]) to high
-* 

Re: [PATCH 3/3] rtc: s5m: Make register configuration per S2MPS device to remove exceptions

[Krzysztof Kozlowski]

On 30.12.2015 12:38, Krzysztof Kozlowski wrote:
> On 30.12.2015 11:53, Yadwinder Singh Brar wrote:
>> Hi Krysztof,
>>
>> On Tue, Dec 29, 2015 at 5:53 PM, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> Before updating time and alarm the driver must set appropriate mask in
>>> UDR register. For that purpose the driver uses common register
>>> configuration and a lot of exceptions per device in the code. The
>>> exceptions are not obvious, for example except the change in the logic
>>> sometimes the fields are swapped (WUDR and AUDR between S2MPS14 and
>>> S2MPS15). This leads to quite complicated code.
>>>
>>> Try to make it more obvious by:
>>> 1. Documenting the UDR masks for devices and operations.
>>> 2. Adding fields in register configuration structure for each operation
>>>(read time, write time and alarm).
>>> 3. Splitting the configuration per S2MPS13, S2MPS14 and S2MPS15 thus
>>>removing exceptions for them.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>
>>> ---
>>>
>>> Tested only on S2MPS11 (Odroid XU4).
>>> ---
>>>  drivers/rtc/rtc-s5m.c   | 110 
>>> +++-
>>>  include/linux/mfd/samsung/rtc.h |   2 +
>>>  2 files changed, 77 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>>> index 559db8f72117..7407d7394bb4 100644
>>> --- a/drivers/rtc/rtc-s5m.c
>>> +++ b/drivers/rtc/rtc-s5m.c
>>> @@ -38,7 +38,22 @@
>>>   */
>>>  #define UDR_READ_RETRY_CNT 5
>>>
>>> -/* Registers used by the driver which are different between chipsets. */
>>> +/*
>>> + * Registers used by the driver which are different between chipsets.
>>> + *
>>> + * Operations like read time and write alarm/time require updating
>>> + * specific fields in UDR register. These fields usually are auto-cleared
>>> + * (with some exceptions).
>>> + *
>>> + * Table of operations per device:
>>> + *
>>> + * Device | Write time | Read time | Write alarm
>>> + * =
>>> + * S5M8767| UDR + TIME |   | UDR
>>> + * S2MPS11/14 | WUDR   | RUDR  | WUDR + RUDR
>>> + * S2MPS13| WUDR   | RUDR  | WUDR + AUDR
>>> + * S2MPS15| WUDR   | RUDR  | AUDR
>>> + */
>>>  struct s5m_rtc_reg_config {
>>> /* Number of registers used for setting time/alarm0/alarm1 */
>>> unsigned int regs_count;
>>> @@ -58,8 +73,13 @@ struct s5m_rtc_reg_config {
>>> unsigned int udr_update;
>>> /* Auto-cleared mask in UDR field for writing time and alarm */
>>> unsigned int autoclear_udr_mask;
>>> -   /* Mask for UDR field in 'udr_update' register */
>>> -   unsigned int udr_mask;
>>> +   /*
>>> +* Masks in UDR field for time and alarm operations.
>>> +* The read time mask can be 0. Rest should not.
>>> +*/
>>> +   unsigned int read_time_udr_mask;
>>> +   unsigned int write_time_udr_mask;
>>> +   unsigned int write_alarm_udr_mask;
>>>  };
>>>
>>>  /* Register map for S5M8763 and S5M8767 */
>>> @@ -71,14 +91,44 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
>>> .alarm1 = S5M_ALARM1_SEC,
>>> .udr_update = S5M_RTC_UDR_CON,
>>> .autoclear_udr_mask = S5M_RTC_UDR_MASK,
>>> -   .udr_mask   = S5M_RTC_UDR_MASK,
>>> +   .read_time_udr_mask = 0, /* Not needed */
>>> +   .write_time_udr_mask= S5M_RTC_UDR_MASK | S5M_RTC_TIME_EN_MASK,
>>> +   .write_alarm_udr_mask   = S5M_RTC_UDR_MASK,
>>> +};
>>> +
>>> +/* Register map for S2MPS13 */
>>> +static const struct s5m_rtc_reg_config s2mps13_rtc_regs = {
>>> +   .regs_count = 7,
>>> +   .time   = S2MPS_RTC_SEC,
>>> +   .ctrl   = S2MPS_RTC_CTRL,
>>> +   .alarm0 = S2MPS_ALARM0_SEC,
>>> +   .alarm1 = S2MPS_ALARM1_SEC,
>>> +   .udr_update = S2MPS_RTC_UDR_CON,
>>> +   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
>>> +   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
>>> +   .write_time_udr

[PATCH v2 3/3] rtc: s5m: Make register configuration per S2MPS device to remove exceptions

[Krzysztof Kozlowski]

Before updating time and alarm the driver must set appropriate mask in
UDR register. For that purpose the driver uses common register
configuration and a lot of exceptions per device in the code. The
exceptions are not obvious, for example except the change in the logic
sometimes the fields are swapped (WUDR and AUDR between S2MPS14 and
S2MPS15). This leads to quite complicated code.

Try to make it more obvious by:
1. Documenting the UDR masks for devices and operations.
2. Adding fields in register configuration structure for each operation
   (read time, write time and alarm).
3. Splitting the configuration per S2MPS13, S2MPS14 and S2MPS15 thus
   removing exceptions for them.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

---

Tested on S2MPS11 (Odroid XU4) and S2MPS13. Testing on S2MPS15 would be
appreciated!

Changes since v1:
1. Fix value used in S2MPS15_RTC_AUDR_MASK, pointed by Yadwinder Singh
   Brar.
---
 drivers/rtc/rtc-s5m.c   | 110 +++-
 include/linux/mfd/samsung/rtc.h |   2 +
 2 files changed, 77 insertions(+), 35 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 559db8f72117..7407d7394bb4 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -38,7 +38,22 @@
  */
 #define UDR_READ_RETRY_CNT 5
 
-/* Registers used by the driver which are different between chipsets. */
+/*
+ * Registers used by the driver which are different between chipsets.
+ *
+ * Operations like read time and write alarm/time require updating
+ * specific fields in UDR register. These fields usually are auto-cleared
+ * (with some exceptions).
+ *
+ * Table of operations per device:
+ *
+ * Device | Write time | Read time | Write alarm
+ * =
+ * S5M8767| UDR + TIME |   | UDR
+ * S2MPS11/14 | WUDR   | RUDR  | WUDR + RUDR
+ * S2MPS13| WUDR   | RUDR  | WUDR + AUDR
+ * S2MPS15| WUDR   | RUDR  | AUDR
+ */
 struct s5m_rtc_reg_config {
/* Number of registers used for setting time/alarm0/alarm1 */
unsigned int regs_count;
@@ -58,8 +73,13 @@ struct s5m_rtc_reg_config {
unsigned int udr_update;
/* Auto-cleared mask in UDR field for writing time and alarm */
unsigned int autoclear_udr_mask;
-   /* Mask for UDR field in 'udr_update' register */
-   unsigned int udr_mask;
+   /*
+* Masks in UDR field for time and alarm operations.
+* The read time mask can be 0. Rest should not.
+*/
+   unsigned int read_time_udr_mask;
+   unsigned int write_time_udr_mask;
+   unsigned int write_alarm_udr_mask;
 };
 
 /* Register map for S5M8763 and S5M8767 */
@@ -71,14 +91,44 @@ static const struct s5m_rtc_reg_config s5m_rtc_regs = {
.alarm1 = S5M_ALARM1_SEC,
.udr_update = S5M_RTC_UDR_CON,
.autoclear_udr_mask = S5M_RTC_UDR_MASK,
-   .udr_mask   = S5M_RTC_UDR_MASK,
+   .read_time_udr_mask = 0, /* Not needed */
+   .write_time_udr_mask= S5M_RTC_UDR_MASK | S5M_RTC_TIME_EN_MASK,
+   .write_alarm_udr_mask   = S5M_RTC_UDR_MASK,
+};
+
+/* Register map for S2MPS13 */
+static const struct s5m_rtc_reg_config s2mps13_rtc_regs = {
+   .regs_count = 7,
+   .time   = S2MPS_RTC_SEC,
+   .ctrl   = S2MPS_RTC_CTRL,
+   .alarm0 = S2MPS_ALARM0_SEC,
+   .alarm1 = S2MPS_ALARM1_SEC,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
+   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
+   .write_time_udr_mask= S2MPS_RTC_WUDR_MASK,
+   .write_alarm_udr_mask   = S2MPS_RTC_WUDR_MASK | S2MPS13_RTC_AUDR_MASK,
+};
+
+/* Register map for S2MPS11/14 */
+static const struct s5m_rtc_reg_config s2mps14_rtc_regs = {
+   .regs_count = 7,
+   .time   = S2MPS_RTC_SEC,
+   .ctrl   = S2MPS_RTC_CTRL,
+   .alarm0 = S2MPS_ALARM0_SEC,
+   .alarm1 = S2MPS_ALARM1_SEC,
+   .udr_update = S2MPS_RTC_UDR_CON,
+   .autoclear_udr_mask = S2MPS_RTC_WUDR_MASK,
+   .read_time_udr_mask = S2MPS_RTC_RUDR_MASK,
+   .write_time_udr_mask= S2MPS_RTC_WUDR_MASK,
+   .write_alarm_udr_mask   = S2MPS_RTC_WUDR_MASK | S2MPS_RTC_RUDR_MASK,
 };
 
 /*
- * Register map for S2MPS14.
- * It may be also suitable for S2MPS11 but this was not tested.
+ * Register map for S2MPS15 - in comparison to S2MPS14 the WUDR and AUDR bits
+ * are swapped.
  */
-static const struct s5m_rtc_reg_config s2mps_rtc_regs = {
+static const struct s5m_rtc_reg_config s2mps15_rtc_regs = {
.regs_count = 7,
.time   = S2MPS_RTC_SEC,
.ctrl   = S2MPS_RTC_CTRL,
@@ -86,7 +136,9 @@ static const 

[GIT PULL] ARM: EXYNOS: dts: DeviceTree for v4.5, 2nd try

[Krzysztof Kozlowski]

Hi,


This is an updated pull request, without the Exynos5410 DTS pinctrl
changes.

I am still not sure why they have to be acked separately but I do not
want to hold on the changes because of this. However if the pinctrl
commit is okay, then please pull tag 'tags/samsung-dt-4.5' instead.


This contains the dependency: SSS clock for Exynos4, acked by Stephen
Boyd (tag: 'samsung-clk-exynos4-4.5').


Best regards,
Krzysztof

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-4.5-2

for you to fetch changes up to bf0dda345b0ee1af287f043857fc34ecfa206293:

  ARM: dts: Unify G2D device node with other devices on exynos4 (2015-12-29 
09:07:44 +0900)


Samsung DeviceTree updates and improvements for 4.5
1. eMMC/SDIO minor fixes usage of bindings on Snow and Peach
   Chromebooks.
2. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used
   yet and on XU3-Lite and XU4 it is not supported.
3. Remove deprecated since June 2013 samsung,exynos5-hdmi.
4. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now).
   This depends on new SSS clock.
5. Add rotator nodes for Exynos4 and Exynos5.
6. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because
   now it cannot be used as OTG.
7. Cleanup the G2D usage on Exynos4 and add it to a proper domain
   in case of Exynos4210.
8. Put MDMA1 in proper domain on Exynos4210 as well.
9. Minor cleanups.


Andrzej Hajda (1):
  dt-bindings: remove deprecated compatible string from exynos-hdmi

Javier Martinez Canillas (7):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
  ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
  ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
  ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
  ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3

Krzysztof Kozlowski (4):
  clk: samsung: exynos4: Add SSS gate clock
  Merge tag 'samsung-clk-exynos4-4.5' into next/dt
  ARM: dts: Add PRNG module for exynos4
  ARM: dts: Enable PRNG module on exynos4412-trats2

Marek Szyprowski (10):
  ARM: dts: Remove fimd node from exynos5422-odroidxu3-common
  ARM: dts: Add rotator nodes on exynos4
  ARM: dts: Fix power domain for sysmmu-rotator device on exynos4
  ARM: dts: Add rotator node on exynos5250
  ARM: dts: Add rotator node on exynos5420
  ARM: dts: Use peripheral mode for dwc3_1 on exynos5422-odroidxu3
  ARM: dts: exynos4210-universal_c210: Disable DMA for UARTs
  ARM: dts: MDMA1 device belongs to LCD0 power domain on exynos4210
  ARM: dts: Add power domain to G2D device on exynos4210
  ARM: dts: Unify G2D device node with other devices on exynos4

 .../bindings/display/exynos/exynos_hdmi.txt   |  7 +++
 arch/arm/boot/dts/exynos4.dtsi| 18 +-
 arch/arm/boot/dts/exynos4210-origen.dts   |  4 
 arch/arm/boot/dts/exynos4210-smdkv310.dts |  4 
 arch/arm/boot/dts/exynos4210-universal_c210.dts   |  8 
 arch/arm/boot/dts/exynos4210.dtsi | 14 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi   |  4 
 arch/arm/boot/dts/exynos4412-odroidu3.dts |  1 -
 arch/arm/boot/dts/exynos4412-origen.dts   |  4 
 arch/arm/boot/dts/exynos4412-smdk4412.dts |  4 
 arch/arm/boot/dts/exynos4412-trats2.dts   |  4 
 arch/arm/boot/dts/exynos4x12.dtsi |  5 -
 arch/arm/boot/dts/exynos5250-snow-common.dtsi |  6 ++
 arch/arm/boot/dts/exynos5250.dtsi |  9 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts|  5 +
 arch/arm/boot/dts/exynos5420.dtsi | 19 +++
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi|  5 -
 arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts   |  2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3.dts|  2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts |  5 +
 drivers/clk/samsung/clk-exynos4.c |  1 +
 include/dt-bindings/clock/exynos4.h   |  1 +
 22 files changed, 85 insertions(+), 47 deletions(-)
--
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] mfd: use to_i2c_client

[Krzysztof Kozlowski]

On 29.12.2015 00:00, Geliang Tang wrote:
> Use to_i2c_client() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang <geliangt...@163.com>
> ---
>  drivers/mfd/88pm80x.c   | 4 ++--
>  drivers/mfd/88pm860x-core.c | 4 ++--
>  drivers/mfd/max14577.c  | 4 ++--
>  drivers/mfd/max77686.c  | 4 ++--
>  drivers/mfd/max77693.c  | 4 ++--
>  drivers/mfd/max77843.c  | 4 ++--
>  drivers/mfd/max8925-i2c.c   | 4 ++--
>  drivers/mfd/max8997.c   | 8 
>  drivers/mfd/max8998.c   | 8 
>  drivers/mfd/sec-core.c  | 4 ++--
>  10 files changed, 24 insertions(+), 24 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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] ARM: s3c64xx: fix pm-debug compilation

[Krzysztof Kozlowski]

On 18.12.2015 23:46, Arnd Bergmann wrote:
> I got one randconfig build that failed to compile plat-samsung/pm-debug.c
> on s3c64xx:
> 
> In file included from arch/arm/plat-samsung/pm-debug.c:27:0:
> arch/arm/mach-s3c64xx/include/mach/pm-core.h: In function 
> 's3c_pm_debug_init_uart':
> arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: error: 'S3C_VA_SYS' 
> undeclared (first use in this function)
>   u32 tmp = __raw_readl(S3C_PCLK_GATE);
> arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: note: each undeclared 
> identifier is reported only once for each function it appears in
> arch/arm/mach-s3c64xx/include/mach/pm-core.h:39:2: error: implicit 
> declaration of function 'udelay' [-Werror=implicit-function-declaration]
>   udelay(10);
> 
> I have not investigated why this does not show up much more often, I
> guess the headers are usually included from elsewhere, but adding
> explicit #include statements is an obvious fix.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> I suspect this has been broken for a long time, so no rush, but please
> apply this to a cleanup branch.
> 

The dependencies for plat-samsung/SAMSUNG_PM_* symbols are little bit
mixed up:
1. pm-common.o depends on PM_SLEEP,
2. pm.o and pm-debug.o depend on PM and sometimes they use stuff from
pm-common.

It is possible to create a config with PM_SLEEP=n and PM=y so this is
confusing (pm-common won't be linked).

I think this still compiles fine because of various #ifdefs but it would
be nice to clean it up.

Anyway your patch looks correct:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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] ARM: s3c: simplify s3c_irqwake_{e,}intallow definition

[Krzysztof Kozlowski]

On 18.12.2015 23:45, Arnd Bergmann wrote:
> For a long time, gcc has warned about odd configurations on s3c64xx:
> 
> In file included from arch/arm/plat-samsung/pm.c:34:0:
> arch/arm/mach-s3c64xx/include/mach/pm-core.h:61:0: warning: 
> "s3c_irqwake_eintallow" redefined
>  #define s3c_irqwake_eintallow ((1 << 28) - 1)
> In file included from arch/arm/plat-samsung/pm.c:33:0:
> arch/arm/plat-samsung/include/plat/pm.h:49:0: note: this is the location of 
> the previous definition
>  #define s3c_irqwake_eintallow 0
> 
> The definitions of s3c_irqwake_intallow and s3c_irqwake_eintallow are a bit 
> consistent
> between the various platforms. Things have become easier now that it's only 
> s3c24xx
> and s3c64xx that use them at all, so I've tried to rearrange the definitions 
> to
> make it more obvious what is going on.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> This fixes a very old and harmless warning, please apply to a cleanup branch
> if you agree.
> 

Looks correct and makes sense. Hoping you compiled it on all machs:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 10/10] ARM: plat-samsung: use to_platform_device()

[Krzysztof Kozlowski]

On 27.12.2015 22:17, Geliang Tang wrote:
> Use to_platform_device() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang <geliangt...@163.com>
> ---
>  arch/arm/plat-samsung/adc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Thanks!

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings

[Krzysztof Kozlowski]

The regulator/s5m8767-regulator.txt duplicates some of the information
about bindings with old mfd/s2mps11.txt. Now common part exists entirely
in mfd/samsung,sec-core.txt so:
 - add company prefix to file name (regulator/samsung,s5m8767.txt),
 - remove duplicated information,
 - reorganize the contents to match style of
   regulator/samsung,s2mps11.txt.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Acked-by: Mark Brown <broo...@kernel.org>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>

---

Changes since v1:
1. Added accumulated acks.
2. Use -M20% so renames will be more visible (formatting is changed so
   default -M50% does not consider it as renames).
---
 .../devicetree/bindings/mfd/samsung,sec-core.txt   |   4 +-
 .../{s5m8767-regulator.txt => samsung,s5m8767.txt} | 152 +
 MAINTAINERS|   2 +-
 3 files changed, 71 insertions(+), 87 deletions(-)
 rename Documentation/devicetree/bindings/regulator/{s5m8767-regulator.txt => 
samsung,s5m8767.txt} (34%)

diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
index ef0166d0f643..4aeb95c82304 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
+++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
@@ -14,6 +14,7 @@ addressed by the host system using different I2C slave 
addresses.
 This document describes bindings for main device node. Optional sub-blocks
 must be a sub-nodes to it. Bindings for them can be found in:
  - bindings/regulator/samsung,s2mps11.txt
+ - bindings/regulator/samsung,s5m8767.txt
  - bindings/clock/samsung,s2mps11.txt
 
 
@@ -23,7 +24,8 @@ Required properties:
- "samsung,s2mps13-pmic",
- "samsung,s2mps14-pmic",
- "samsung,s2mps15-pmic",
-   - "samsung,s2mpu02-pmic".
+   - "samsung,s2mpu02-pmic",
+   - "samsung,s5m8767-pmic".
  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
similarity index 34%
rename from Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
rename to Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
index 20191315e444..093edda0c8df 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
@@ -1,98 +1,80 @@
-* Samsung S5M8767 Voltage and Current Regulator
-
-The Samsung S5M8767 is a multi-function device which includes voltage and
-current regulators, rtc, charger controller and other sub-blocks. It is
-interfaced to the host controller using a i2c interface. Each sub-block is
-addressed by the host system using different i2c slave address. This document
-describes the bindings for 'pmic' sub-block of s5m8767.
-
-Required properties:
-- compatible: Should be "samsung,s5m8767-pmic".
-- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
-
-- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
-  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
-  for additional information.
-
-- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
-  units for buck3 when changing voltage using gpio dvs. Refer to [1] below
-  for additional information.
-
-- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
-  units for buck4 when changing voltage using gpio dvs. Refer to [1] below
-  for additional information.
-
-- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
-  for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
-
-[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
-property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
-property should specify atleast one voltage level (which would be a
-safe operating voltage).
-
-If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
-property is specified, then all the eight voltage values for the
-'s5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
-
-Optional properties:
-- interrupt-parent: Specifies the phandle of the interrupt controller to which
-  the interrupts from s5m8767 are delivered to.
-- interrupts: Interrupt specifiers for two interrupt sources.
-  - First interrupt specifier is for 'irq1' interrupt.
-  - Second interrupt specifier is for 'alert' interrupt.
-- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
-- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
-- s5m8767,pmic-buck

[PATCH v2 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

[Krzysztof Kozlowski]

The mfd/s2mpa01.txt duplicates some of the information about bindings
with old mfd/s2mps11.txt. Now common part exists entirely in
mfd/samsung,sec-core.txt so:
 - add company prefix to file name (regulator/samsung,s2mpa01.txt),
 - remove duplicated information,
 - reorganize the contents to match style of
   regulator/samsung,s2mps11.txt.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Acked-by: Mark Brown <broo...@kernel.org>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>

---

Changes since v1:
1. Added accumulated acks.
2. Use -M20% so renames will be more visible (formatting is changed so
   default -M50% does not consider it as renames).
---
 .../devicetree/bindings/mfd/samsung,sec-core.txt   |  4 +-
 .../s2mpa01.txt => regulator/samsung,s2mpa01.txt}  | 69 +-
 2 files changed, 32 insertions(+), 41 deletions(-)
 rename Documentation/devicetree/bindings/{mfd/s2mpa01.txt => 
regulator/samsung,s2mpa01.txt} (37%)

diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
index 4aeb95c82304..cdd079bfc287 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
+++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
@@ -4,7 +4,7 @@ Binding for Samsung S2M and S5M family multi-function device
 This is a part of device tree bindings for S2M and S5M family multi-function
 devices.
 
-The Samsung S2MPS11/13/14/15, S2MPU02 and S5M8767 is a family
+The Samsung S2MPA01, S2MPS11/13/14/15, S2MPU02 and S5M8767 is a family
 of multi-function devices which include voltage and current regulators, RTC,
 charger controller, clock outputs and other sub-blocks. It is interfaced
 to the host controller using an I2C interface. Each sub-block is usually
@@ -13,6 +13,7 @@ addressed by the host system using different I2C slave 
addresses.
 
 This document describes bindings for main device node. Optional sub-blocks
 must be a sub-nodes to it. Bindings for them can be found in:
+ - bindings/regulator/samsung,s2mpa01.txt
  - bindings/regulator/samsung,s2mps11.txt
  - bindings/regulator/samsung,s5m8767.txt
  - bindings/clock/samsung,s2mps11.txt
@@ -20,6 +21,7 @@ must be a sub-nodes to it. Bindings for them can be found in:
 
 Required properties:
  - compatible: Should be one of the following
+   - "samsung,s2mpa01-pmic",
- "samsung,s2mps11-pmic",
- "samsung,s2mps13-pmic",
- "samsung,s2mps14-pmic",
diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt 
b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
similarity index 37%
rename from Documentation/devicetree/bindings/mfd/s2mpa01.txt
rename to Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
index c13d3d8c3947..bae3c7f838cf 100644
--- a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
+++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
@@ -1,54 +1,43 @@
+Binding for Samsung S2MPA01 regulator block
+===
 
-* Samsung S2MPA01 Voltage and Current Regulator
+This is a part of device tree bindings for S2M family multi-function devices.
+More information can be found in bindings/mfd/sec-core.txt file.
 
-The Samsung S2MPA01 is a multi-function device which includes high
-efficiency buck converters including Dual-Phase buck converter, various LDOs,
-and an RTC. It is interfaced to the host controller using an I2C interface.
-Each sub-block is addressed by the host system using different I2C slave
-addresses.
+The S2MPA01 device provide buck and LDO regulators.
 
-Required properties:
-- compatible: Should be "samsung,s2mpa01-pmic".
-- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
+To register these with regulator framework instantiate under main device node
+a sub-node named "regulators" with more sub-nodes for each regulator using the
+common regulator binding documented in:
+ - Documentation/devicetree/bindings/regulator/regulator.txt
 
-Optional properties:
-- interrupt-parent: Specifies the phandle of the interrupt controller to which
-  the interrupts from s2mpa01 are delivered to.
-- interrupts: An interrupt specifier for the sole interrupt generated by the
-  device.
-
-Optional nodes:
-- regulators: The regulators of s2mpa01 that have to be instantiated should be
-  included in a sub-node named 'regulators'. Regulator nodes and constraints
-  included in this sub-node use the standard regulator bindings which are
-  documented elsewhere.
-
-Properties for BUCK regulator nodes:
-- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
-  (default), 25000, or 5. May be 0 for disabling the ramp delay on
-  BUCK{1,2,3,4}.
-
- In the absence of the regulator-ramp-delay property, the default ramp
- delay will be used.
-
-  NOTE: Some BUCKs share the ramp rate se

[PATCH v2 0/3] dt-bindings: regulator/clock/mfd: Reorganize S2M/S5M bindings

[Krzysztof Kozlowski]

Hi,


I got all acks for the patches. Please kindly pick up. Maybe Rob or Lee?


The patchset tries to bring some order to the chaotic bindings for family
of Samsung PMIC devices: S2MPS/S2MPA/S5M.

Beside of renaming and removal of common parts I also tried to make
a consistent style used in the files. The bindings itself were not
modified.

Rebased on next-20151223.


Changes since v1:
1. Added accumulated acks.
2. Use -M20% so renames will be more visible (formatting is changed so
   default -M50% does not consider it as renames).


Best regards,
Krzysztof

Krzysztof Kozlowski (3):
  dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings
  dt-bindings: regulator/mfd: Reorganize S5M8767 bindings
  dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

 .../devicetree/bindings/clock/samsung,s2mps11.txt  |  49 +++
 .../devicetree/bindings/mfd/samsung,sec-core.txt   |  88 
 .../s2mpa01.txt => regulator/samsung,s2mpa01.txt}  |  69 --
 .../s2mps11.txt => regulator/samsung,s2mps11.txt}  | 135 ++
 .../{s5m8767-regulator.txt => samsung,s5m8767.txt} | 152 +
 MAINTAINERS|   6 +-
 6 files changed, 279 insertions(+), 220 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
 rename Documentation/devicetree/bindings/{mfd/s2mpa01.txt => 
regulator/samsung,s2mpa01.txt} (37%)
 rename Documentation/devicetree/bindings/{mfd/s2mps11.txt => 
regulator/samsung,s2mps11.txt} (25%)
 rename Documentation/devicetree/bindings/regulator/{s5m8767-regulator.txt => 
samsung,s5m8767.txt} (34%)

-- 
1.9.1

--
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/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

[Krzysztof Kozlowski]

Bindings for Samsung S2M and S5M family PMICs are in mess. They are
spread over different files and subdirectories in a non-consistent way.
The devices and respective drivers for them share a lot in common so
everything could be organized in a more readable way.

Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
drivers for this family of devices:
 - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
   driver (common for entire family),
 - split clock block to clock/samsung,s2mps11.txt,
 - split regulator block to regulator/samsung,s2mps11.txt.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Acked-by: Mark Brown <broo...@kernel.org>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Acked-by: Michael Turquette <mturque...@baylibre.com>

---

Changes since v1:
1. Added accumulated acks.
2. Use -M20% so renames will be more visible (formatting is changed so
   default -M50% does not consider it as renames).
---
 .../devicetree/bindings/clock/samsung,s2mps11.txt  |  49 
 .../devicetree/bindings/mfd/samsung,sec-core.txt   |  84 +
 .../s2mps11.txt => regulator/samsung,s2mps11.txt}  | 135 +++--
 MAINTAINERS|   4 +-
 4 files changed, 178 insertions(+), 94 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
 rename Documentation/devicetree/bindings/{mfd/s2mps11.txt => 
regulator/samsung,s2mps11.txt} (25%)

diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt 
b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
new file mode 100644
index ..2726c1d58a79
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
@@ -0,0 +1,49 @@
+Binding for Samsung S2M and S5M family clock generator block
+
+
+This is a part of device tree bindings for S2M and S5M family multi-function
+devices.
+More information can be found in bindings/mfd/sec-core.txt file.
+
+The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
+outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
+
+To register these as clocks with common clock framework instantiate under
+main device node a sub-node named "clocks".
+
+It uses the common clock binding documented in:
+ - Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Required properties of the "clocks" sub-node:
+ - #clock-cells: should be 1.
+ - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
+   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
+   The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
+   clocks.
+
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+Clock   ID   Devices
+--
+32KhzAP0S2MPS11/13/14/15, S5M8767
+32KhzCP1S2MPS11/13/15, S5M8767
+32KhzBT2S2MPS11/13/14/15, S5M8767
+
+Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
+in device tree sources.
+
+
+Example:
+
+   s2mps11_pmic@66 {
+   compatible = "samsung,s2mps11-pmic";
+   reg = <0x66>;
+
+   s2m_osc: clocks {
+   compatible = "samsung,s2mps11-clk";
+   #clock-cells = <1>;
+   clock-output-names = "xx", "yy", "zz";
+   };
+   };
diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
new file mode 100644
index ..ef0166d0f643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
@@ -0,0 +1,84 @@
+Binding for Samsung S2M and S5M family multi-function device
+
+
+This is a part of device tree bindings for S2M and S5M family multi-function
+devices.
+
+The Samsung S2MPS11/13/14/15, S2MPU02 and S5M8767 is a family
+of multi-function devices which include voltage and current regulators, RTC,
+charger controller, clock outputs and other sub-blocks. It is interfaced
+to the host controller using an I2C interface. Each sub-block is usually
+addressed by the host system using different I2C slave addresses.
+
+
+This document describes bindings for main device node. Optional sub-blocks
+must be a sub-nodes to it. Bindings for them can be found in:
+ - bindings/regulator/samsung,s2mps11.txt
+ - bindings/clock/samsung,s2mps11.txt
+
+
+Required 

Re: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Krzysztof Kozlowski]

W dniu 18.12.2015 o 18:16, Pavel Fedin pisze:
>  Hello!
> 
>> 4. This branch is not pushed to linux-next. I will sort it out if my
>> previous pull requests get in. I will be out of office for Christmas so
>> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
>> not go into v4.5 (yay...).
>>
>> 5. If it does not get into v4.5, I will rebase it and proceed further
>> for v4.6.
>>
>> If you have any questions, please let me know.
> 
>  Thank you very much. No, i don't have any questions, i'm glad that my work 
> is picked up and not lost, i'm just keeping an eye on it
> until it goes to stable.
> 
>  P.S. Not related to these sets directly, just to note... When i was writing 
> the doc for SROMc bindings, i noticed that we have two
> directories for Exynos in Documentation/devicetree/bindings/arm:
> 1. Documentation/devicetree/bindings/arm/exynos
> 2. Documentation/devicetree/bindings/arm/Samsung
> 
>  In (1) we have only a single old file, shouldn't this be cleaned up and 
> shouldn't this file be moved to (2)?

Thanks for hind but I already cleaned it up:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=068812ed108acbfe070b893faba9845fe2ea3fd9

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] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Krzysztof Kozlowski]

From: Krzysztof Kozlowski <k.kozlow...@samsung.com>

For Odroid XU3-family enable the:
 - PWM fan (to control the CPU fan using thermal subsystem),
 - TI INA231 sensors (provide power measurements of big.LITTLE cores,
   DRAM and GPU),
 - Samsung sound (for Odroid XU3 and Snow as well).

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

---

Resending with Javier's tag.
---
 arch/arm/configs/multi_v7_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index f6a2557b55df..419f9413402c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -390,7 +390,8 @@ CONFIG_POWER_RESET_RMOBILE=y
 CONFIG_SENSORS_LM90=y
 CONFIG_SENSORS_LM95245=y
 CONFIG_SENSORS_NTC_THERMISTOR=m
-CONFIG_THERMAL=y
+CONFIG_SENSORS_PWM_FAN=m
+CONFIG_SENSORS_INA2XX=m
 CONFIG_CPU_THERMAL=y
 CONFIG_ROCKCHIP_THERMAL=y
 CONFIG_RCAR_THERMAL=y
@@ -521,10 +522,13 @@ CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m
 CONFIG_SND_HDA_CODEC_HDMI=m
-CONFIG_SND_USB_AUDIO=y
+CONFIG_SND_USB_AUDIO=m
 CONFIG_SND_SOC=m
 CONFIG_SND_ATMEL_SOC=m
 CONFIG_SND_ATMEL_SOC_WM8904=m
+CONFIG_SND_SOC_SAMSUNG=m
+CONFIG_SND_SOC_SNOW=m
+CONFIG_SND_SOC_ODROIDX2=m
 CONFIG_SND_SOC_SH4_FSI=m
 CONFIG_SND_SOC_RCAR=m
 CONFIG_SND_SOC_RSRC_CARD=m
-- 
2.1.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: [GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5

[Krzysztof Kozlowski]

W dniu 22.12.2015 o 13:46, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> Dependency for soc64 changes.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-clk-arm64-symbols-4.5
>>
>> for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc:
>>
>>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 
>> 19:25:29 +0900)
> 
> Hi,
> 
> Looks like this lacks ack from any of the clock maintainers.

It got the ack from Sylwester and Tomasz - Samsung clock maintainers. If
it is not sufficient... then let's wait with it for v4.6. I am on
holidays now so I cannot really do anything meaningful with it.


> 
> Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause
> a breakage in bisectability on some of these platforms as well.

The patch introduces EXYNOS_ARM64_COMMON_CLK which will be enabled by
default on our platforms. What kind of breakage do you have in mind?

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: [GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5

[Krzysztof Kozlowski]

W dniu 22.12.2015 o 13:51, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> This is also clock dependency. I put it in separate tag in case clock
>> folks want to pull it also.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-clk-exynos4-4.5
>>
>> for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08:
>>
>>   clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900)
> 
> Again, this should probably go through the clk maintainer (or have an ack).
> It's just two one-line changes though, so if they're slow to respond we can
> take it as a fallback. Resend if that's the case.
> 

Wait, I am missing something. This contains only one patch which has the
Stephen's Boyd ack:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379230.html
(this is in commit message already)

What kind of ack do you expect here? Ack for pull-request?

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: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

[Krzysztof Kozlowski]

W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
> Hi,
> 
> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>>> Hi Kukjin,
>>>>
>>>> Pinctrl for v4.5.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>>
>>>> The following changes since commit 
>>>> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>>
>>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>>> tags/samsung-drivers-4.5
>>>>
>>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>>
>>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>>> +0900)
>>>
>>> Hi,
>>>
>>> This should either go in through the pinctrl tree, or have an 
>>> acked/reviewed-by
>>> one of the pinctrl maintainers.
>>
>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>> https://patchwork.ozlabs.org/patch/450340/
> 
> Actually, is there any reason to send this through ARM SoC? Looks like
> this pull request contains only pinctrl changes which could normally
> go through pinctrl tree. Maybe Linus W. could simply pull it?

Of course, I would be happy with it.

But apparently I am the only one who continuously tracks all of these
patches for Exynos (also for subsystems different than arch/arm/mach*).
Yeah, I could ping everyone for every patch (not mine patch I mean)...
but it is easier just to grab it after acking and send it. I really
don't care about the method, just apply the damned patch ;)

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: [GIT PULL 4/9] ARM64: EXYNOS: Soc specific code for v4.5

[Krzysztof Kozlowski]

W dniu 22.12.2015 o 13:49, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:41AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> ARM64 change touch also defconfig.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-soc64-4.5
>>
>> for you to fetch changes up to db44c07a3f0b32815bd1f3e731db9e043e57cf9c:
>>
>>   arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS 
>> (2015-11-22 19:31:30 +0900)
> 
> Given that Arnd started splitting out config64 separately, there's a small
> chance we'll get a conflict here. We can deal with that if needed though.
> 
> Still, since this branch contains the previous clock branch I can't apply it
> as it is. Can you respin without that for now?

This depends on the clock change because:
1. Clock change removes last usage of ARCH_EXYNOS7,
2. This patch removes the ARCH_EXYNOS7 itself.

So if #1 has to wait, then skip this as well.

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: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

[Krzysztof Kozlowski]

W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> Pinctrl for v4.5.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-drivers-4.5
>>
>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>
>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>> +0900)
> 
> Hi,
> 
> This should either go in through the pinctrl tree, or have an 
> acked/reviewed-by
> one of the pinctrl maintainers.

It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
https://patchwork.ozlabs.org/patch/450340/

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: [GIT PULL 7/9] ARM: EXYNOS: dts: DeviceTree for v4.5

[Krzysztof Kozlowski]

W dniu 22.12.2015 o 13:52, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:44AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> A lot of stuff here, mostly cleanups. Description in tag.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-dt-4.5
>>
>> for you to fetch changes up to 2cf107f1033e0343d45b59d06f16487c8362702f:
>>
>>   ARM: dts: Unify G2D device node with other devices on exynos4 (2015-11-30 
>> 17:00:43 +0900)
>>
>> 
>> Samsung DeviceTree updates and improvements for 4.5:
>> 1. Pinctrl for Exynos5410.
>> 2. eMMC/SDIO minor fixes usage of bindings on Snow and Peach
>>Chromebooks.
>> 3. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used
>>yet and on XU3-Lite and XU4 it is not supported.
>> 4. Remove deprecated since June 2013 samsung,exynos5-hdmi.
>> 5. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now).
>>This depends on new SSS clock.
>> 6. Add rotator nodes for Exynos4 and Exynos5.
>> 7. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because
>>now it cannot be used as OTG.
>> 8. Cleanup the G2D usage on Exynos4 and add it to a proper domain
>>in case of Exynos4210.
>> 9. Put MDMA1 in proper domain on Exynos4210 as well.
>> 10. Minor cleanups.
> 
> Given the request to get acks for the pinctrl changes, can you respin this
> branch without those pieces so we can merge in the rest of it?
> 
The pinctrl changes here are only DTS changes. I reviewed the pinctrl
DTSI. Why do you want an additional ack for them?

However this contains the previous clock dependency (the SSS clock acked
by Stephen Boyd). I responded about this already so let's don't
duplicate the discussion.

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: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

[Krzysztof Kozlowski]

W dniu 23.12.2015 o 20:06, Tomasz Figa pisze:
> 2015-12-23 19:58 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
>> W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
>>> Hi,
>>>
>>> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
>>>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>>>>> Hi Kukjin,
>>>>>>
>>>>>> Pinctrl for v4.5.
>>>>>>
>>>>>> Best regards,
>>>>>> Krzysztof
>>>>>>
>>>>>>
>>>>>> The following changes since commit 
>>>>>> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>>>>
>>>>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>
>>>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>>>>> tags/samsung-drivers-4.5
>>>>>>
>>>>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>>>>
>>>>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>>>>> +0900)
>>>>>
>>>>> Hi,
>>>>>
>>>>> This should either go in through the pinctrl tree, or have an 
>>>>> acked/reviewed-by
>>>>> one of the pinctrl maintainers.
>>>>
>>>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>>>> https://patchwork.ozlabs.org/patch/450340/
>>>
>>> Actually, is there any reason to send this through ARM SoC? Looks like
>>> this pull request contains only pinctrl changes which could normally
>>> go through pinctrl tree. Maybe Linus W. could simply pull it?
>>
>> Of course, I would be happy with it.
>>
>> But apparently I am the only one who continuously tracks all of these
>> patches for Exynos (also for subsystems different than arch/arm/mach*).
>> Yeah, I could ping everyone for every patch (not mine patch I mean)...
>> but it is easier just to grab it after acking and send it. I really
>> don't care about the method, just apply the damned patch ;)
> 
> My intention was by no means to belittle your effort, really thanks
> for doing this. :)
> 
> I was just wondering if Linus couldn't pull this just as is, without
> causing further commotion and unnecessarily introducing field for
> potential conflicts between trees.

That makes sense. The pinctrl driver change is not a direct dependency
for anything in this pull request so from my side:

Acked-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Linus,
The patch can be cherry-picked from:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=samsung-drivers-4.5

(the only commit in tag: samsung-drivers-4.5)

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] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Krzysztof Kozlowski]

2015-12-07 18:43 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Monday 07 December 2015 18:38:44 Krzysztof Kozlowski wrote:
>> On 07.12.2015 18:14, Arnd Bergmann wrote:
>> > On Monday 07 December 2015 09:59:54 Krzysztof Kozlowski wrote:
>> >> For Odroid XU3-family enable the:
>> >>  - PWM fan (to control the CPU fan using thermal subsystem),
>> >>  - TI INA231 sensors (provide power measurements of big.LITTLE cores,
>> >>DRAM and GPU),
>> >>  - Samsung sound (for Odroid XU3 and Snow as well).
>> >>
>> >> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>> >>
>> >
>> > Looks good. Do you have a samsung/defconfig branch already that you
>> > can put this into, or should be pick it up into arm-soc directly?
>> >
>> > My preference is the former, but it would be a bit silly if that
>> > is the only samsung defconfig change we need.
>>
>> I had a couple of defconfig patches in my queue but I sent them last
>> week to Kukjin in pull request. He didn't pull it yet. Maybe he could
>> apply this patch after pulling?
>>
>> Anyway we can wait for a few days to sort it out. If I don't have
>> another defconfig patches then I will remind myself with applying it to
>> arm-soc.
>>
>
> Ok, sounds good.

+Cc a...@kernel.org,

I don't have any other defconfig changes in my queue, except of course
stuff which I sent in pull request. I mean the request sent initially
to Kukjin but now redirected with his ack to you guys.

If you don't mind, please apply this patch directly (with Javier's reviewed-by).

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 v7 0/6] samsung: pmu: split up SoC specific PMU data

[Krzysztof Kozlowski]

On 18.12.2015 12:32, Pankaj Dubey wrote:
> In this series I am splitting up SoC specific PMU configuration data into
> mach-exynos folder itself, before moving all of them under
> drivers/soc/samsung/. Also instead of making all changes in single patch it
> has been broken into SoC specific patches to avoid large size of patch.
> With this approach there will not be unwanted big churns just after
> adding exynos-pmu under drivers/soc/samsung.
> 
> All these patches are just refactoring to keep minimal changes while moving
> exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
> be added on top of it, in such a manner that for ARM64 build, ARM related
> SoC's PMU will not get compiled and thus unnecessary increasing kernel image 
> size.
> 
> This series have been prepared on top of Krzysztof Kozlowski's 
> next/stuff-late-not-split-per-branch branch, and it's just a rebase compared 
> to
> V6 posted and reviewed here [1]. 
> 
> [1]: https://lkml.org/lkml/2015/11/17/15
> 
> For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot
> and S2R functionality.
> 
> Tested-by: Pankaj Dubey <pankaj.du...@samsung.com>
> 
> For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
> and Odroid XU3 (Exynos5422, reboot, poweroff).
> 
> Tested-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Changes since v6:
>  - Rebasing on top of branch provided by Krzysztof, after resolving conflicts 
>caused due to Alim's patches for adoptation of generic syscon for 
> poweroff, reboot.
>  - Included Tested-by tags on individual patches as per applicability.
>  - Dropped patches v6 [1/9], v6 [2/9] as these are already present in above 
> mentioned branch.
>  - Dropped patch v6 [8/9] as after Alim's patch this patch no more required.
> 

Patchset applied cleanly with:
1. Removal of blank lines at end of two files (they appeared in v7).
2. Removal of your tested-by. The author does not provide such tag
because it is assumed that he tested it before sending. However I left
the information about testing platform near your signed-off-by.

You can find the patches on the same branch:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch

I hope I will be able to push it out to arm-soc soon...

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 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source

[Krzysztof Kozlowski]

On 16.12.2015 19:32, Sudeep Holla wrote:
> 
> 
> On 15/12/15 23:32, Krzysztof Kozlowski wrote:
>> On 16.12.2015 01:35, Sudeep Holla wrote:
>>>
>>>
>>> On 21/10/15 11:10, Sudeep Holla wrote:
>>>> Though the keyboard and other driver will continue to support the
>>>> legacy
>>>> "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the
>>>> wakeup source, "wakeup-source" is the new standard binding.
>>>>
>>>> This patch replaces all the legacy wakeup properties with the unified
>>>> "wakeup-source" property in order to avoid any futher copy-paste
>>>> duplication.
>>>>
>>>> Cc: Kukjin Kim <kg...@kernel.org>
>>>> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>
>>> Ping, do you prefer taking via your tree or should I send to armsoc
>>> directly ?
>>
>> Usually it depends on the dependencies... but:
>> 1. I just received this patch - 12/19.
> 
> Sorry for that. The initial idea was to show all the changes but merge
> the binding and dependencies first, so didn't cc all.
> 
>> 2. No cover letter, no other patches, no explanation about any
>> dependencies or other related changes. Nothing. Just one patch.
> 
> Yes this was initially posted as part of the series, but only
> dependencies were merged for v4.4
> 
>> 3. The patch mentions new standard binding. Was the new binding already
>> merged? Or is it part of these series? What about backward compatibility?
> 
> Not a brand new binding, but made existing one a standard so that we
> don't continue to be creative and generate more bindings for the same
> thing. Yes binding and dependent patches are already in mainline. And
> yes backward compatibility is maintained as mentioned in the commit
> message.

That explains everything, thanks. We'll take it through samsung-soc,
just give me some time for review.

As for other patch - the s5pv210 - I did not get it directly but I think
I can find it on list subscription archives.

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 16/19] ARM: dts: s5pv210: replace legacy *,wakeup property with wakeup-source

[Krzysztof Kozlowski]

2015-10-21 19:10 GMT+09:00 Sudeep Holla <sudeep.ho...@arm.com>:
> Though the keyboard and other driver will continue to support the legacy
> "gpio-key,wakeup", "linux,input-wakeup" boolean property to enable the
> wakeup source, "wakeup-source" is the new standard binding.
>
> This patch replaces all the legacy wakeup properties with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
>
> Cc: Marek Szyprowski <m.szyprow...@samsung.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>
> ---
>  arch/arm/boot/dts/s5pv210-aquila.dts   | 4 ++--
>  arch/arm/boot/dts/s5pv210-goni.dts | 4 ++--
>  arch/arm/boot/dts/s5pv210-smdkv210.dts | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source

[Krzysztof Kozlowski]

On 21.10.2015 19:10, Sudeep Holla wrote:
> Though the keyboard and other driver will continue to support the legacy
> "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the
> wakeup source, "wakeup-source" is the new standard binding.
> 
> This patch replaces all the legacy wakeup properties with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
> 
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>
> ---
>  arch/arm/boot/dts/exynos3250-monk.dts   |  6 +++---
>  arch/arm/boot/dts/exynos3250-rinato.dts |  6 +++---
>  arch/arm/boot/dts/exynos4210-origen.dts | 10 +-
>  arch/arm/boot/dts/exynos4210-smdkv310.dts   |  2 +-
>  arch/arm/boot/dts/exynos4210-trats.dts  |  2 +-
>  arch/arm/boot/dts/exynos4210-universal_c210.dts |  4 ++--
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  2 +-
>  arch/arm/boot/dts/exynos4412-odroidx.dts|  2 +-
>  arch/arm/boot/dts/exynos4412-origen.dts |  2 +-
>  arch/arm/boot/dts/exynos4412-smdk4412.dts   |  2 +-
>  arch/arm/boot/dts/exynos4412-trats2.dts |  4 ++--
>  arch/arm/boot/dts/exynos5250-arndale.dts| 12 ++--
>  arch/arm/boot/dts/exynos5250-snow.dts   |  4 ++--
>  arch/arm/boot/dts/exynos5250-spring.dts |  4 ++--
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts   |  2 +-
>  arch/arm/boot/dts/exynos5420-peach-pit.dts  |  4 ++--
>  arch/arm/boot/dts/exynos5800-peach-pi.dts   |  4 ++--
>  17 files changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 540a0adf2be6..b77ea2163a0a 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -43,7 +43,7 @@
>   linux,code = ;
>   label = "power key";
>   debounce-interval = <10>;
> - gpio-key,wakeup;
> + wakeup-source;
>   };
>   };
>  
> @@ -67,7 +67,7 @@
>   interrupt-parent = <>;
>   interrupts = <5 0>;
>   reg = <0x25>;
> - wakeup;
> + wakeup-source;
>  
>   muic: max77836-muic {
>   compatible = "maxim,max77836-muic";
> @@ -184,7 +184,7 @@
>   interrupt-parent = <>;
>   interrupts = <7 0>;
>   reg = <0x66>;
> - wakeup;
> + wakeup-source;
>  
>   s2mps14_osc: clocks {
>   compatible = "samsung,s2mps14-clk";
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 41a5fafb9aa9..7acd11d2d957 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -43,7 +43,7 @@
>   linux,code = ;
>   label = "power key";
>   debounce-interval = <10>;
> - gpio-key,wakeup;
> + wakeup-source;
>   };
>   };
>  
> @@ -58,7 +58,7 @@
>   interrupt-parent = <>;
>   interrupts = <5 0>;
>   reg = <0x25>;
> - wakeup;
> + wakeup-source;
>  
>   muic: max77836-muic {
>   compatible = "maxim,max77836-muic";
> @@ -245,7 +245,7 @@
>   interrupt-parent = <>;
>   interrupts = <7 0>;
>   reg = <0x66>;
> - wakeup;
> + wakeup-source;

I think here and in Monk board these four "wakeup" properties are bogus,
not parsed by driver. Instead wakeup is always initialized to true.

Anyway fixing this is not part of this patch but instead this should be
fixed in separate commit. Here everything looks good:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v6 0/9] samsung: pmu: split up SoC specific PMU data

[Krzysztof Kozlowski]

On 17.11.2015 15:05, Pankaj Dubey wrote:
> In this series I am splitting up SoC specific PMU configuration data into
> mach-exynos folder itself, before moving all of them under
> drivers/soc/samsung/. Also instead of making all changes in single patch it
> has been broken into SoC specific patches to avoid large size of patch.
> With this approach there will not be unwanted big churns just after
> adding exynos-pmu under drivers/soc/samsung.
> 
> All these patches are just refactoring to keep minimal changes while moving
> exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
> be added on top of it, in such a manner that for ARM64 build, ARM related
> SoC's PMU will not get compiled and thus unnecessary increasing kernel image 
> size.
> 
> These patches have been prepared on top of Kukjin Kim's for-next merged with
> driver-samsung and on top of
> cherry-picked change from [1].
> 
> 1: ARM: EXYNOS: Constify local exynos_pmu_data structure
>https://lkml.org/lkml/2015/10/28/917
> 
> For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot
> and S2R functionality.
> 
> Tested-by: Pankaj Dubey <pankaj.du...@samsung.com>
> 
> For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
> and Odroid XU3 (Exynos5422, reboot, poweroff).
> 
> Tested-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Changes since v5:
>  - Removed extra blank line from patch 5/9 and 6/9.
>  - Modified soc/samsung/Kconfig for config EXNOS_PMU. Added depends on ARM.
> 
> Changes since v4:
>  - In v3 I missed to give -M flag to detect rename, which made patches hard
>to review, so resubmitting patches with rename detector flag.
>  - Addressed review comments from Krzysztof.
> 
> Changes since v3:
>  - Keeping intact copyright dates in existing header files.
>  - Addressed review comments from Krzysztof for v3.
>  - Removing static inline function from exynos-pmu.h and
>keeping them in PMU driver.
>  - Added new patch (2/9) for fixing potential null pointer reference in
>exynos_sys_powerdown_conf.
>  - Added new patch (8/9) for rearranging static and non-static function for
>better readability.
> 
> Changes since v2:
>  - Removed Amit's Samsung id as it's no more valid.
>  - Rebased on latest kgene tree.
>  - Removed redundant code from regs-pmu.h
> 
> Pankaj Dubey (9):
>   ARM: EXYNOS: removing redundant code from regs-pmu.h
>   ARM: EXYNOS: Fix potential NULL pointer access in
> exynos_sys_powerdown_conf
>   ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
>   ARM: EXYNOS: split up exynos3250 SoC specific PMU data
>   ARM: EXYNOS: split up exynos4 SoC specific PMU data
>   ARM: EXYNOS: split up exynos5250 SoC specific PMU data
>   ARM: EXYNOS: split up exynos5420 SoC specific PMU data
>   ARM: EXYNOS: rearrange static and non-static functions of PMU driver
>   drivers: soc: Add support for Exynos PMU driver
> 

I tried to apply this to my branch:
next/stuff-late-not-split-per-branch
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch

Unfortunately it fails on:
error: patch failed: arch/arm/mach-exynos/pmu.c:17
error: arch/arm/mach-exynos/pmu.c: patch does not apply
Patch failed at 0001 ARM: EXYNOS: Move pmu specific headers under
"linux/soc/samsung"

because of syscon-reboot handlers (Alim's work).

I think I have all the dependencies already in my
"next/stuff-late-not-split-per-branch".
If you want to proceed now, can you rebase on top of it? Otherwise we
could wait and rebase later (after v4.5-rc1).


P.S. Please note that "next/stuff-late-not-split-per-branch" is not
included in linux-next because I am not sure if I will be able to push
it out soon.


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 v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Krzysztof Kozlowski]

On 16.11.2015 16:43, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
> 
> With this patchset, support for the whole existing SMDK range can be added.
> Actually, only bank number is different.
> 
> This patchset also depends on Exynos 5410 pinctrl support, introduced by
> patches 0003 and 0004 from this set:
> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
> 
> Pinctrl support is necessary in order to correctly configure
> multifunctional pins of the Exynos chip.
> 

Let me share the plan/status:
1. Currently Kukjin Kim is out of office (he told me he will be back on
Christmas).
2. I asked arm-soc people to pull my previous pull requests.

3. I applied this patchset to my branch:
next/stuff-late-not-split-per-branch
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch

4. This branch is not pushed to linux-next. I will sort it out if my
previous pull requests get in. I will be out of office for Christmas so
depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
not go into v4.5 (yay...).

5. If it does not get into v4.5, I will rebase it and proceed further
for v4.6.

If you have any questions, please let me know.

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: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver

[Krzysztof Kozlowski]

On 12.12.2015 16:43, Pankaj Dubey wrote:
> THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES
> 
> Series v5 got merged in kgene/for-next but due to last moment change before 
> pull
> these patches were not accepted during 4.3 merge window.After that 
> kgene/for-next
> got rebased over 4.4-rc1 these patches got dropped into another branch and 
> till
> date not included to for-next.
> 
> Since then due to minor change in "drivers/soc/", patches are not getting 
> applied
> cleanly so rebasing on current for-next and resending all these with fix in 
> memory
> mapping included.
> 
> 
> This patch set adds support for Exynos SROM controller DT based driver.
> Currently SROM register sets are used only during S2R, so driver
> basically added for taking care of S2R. It will help us in removing
> static mapping from exynos.c and other extra code handline during S2R.
> 
> This patch set also updated exynos4 and exynos5 dtsi files for with device
> node for srom, and added binding documentation for the same.
> 
> First two patches are some minor cleanup in mach-exynos.
> 
> Patchset v1 was posted here[1]
> [1]: https://lkml.org/lkml/2015/4/29/98
> Patchset v2 was posted here[2]
> [2]: https://lkml.org/lkml/2015/8/24/125
> Patchset v3 was posted here[3]
> [3]: https://lkml.org/lkml/2015/10/13/392
> Patchset v3 was posted here[4]
> [4]: https://lkml.org/lkml/2015/10/19/278
> 
> This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for 
> boot
> and S2R functionality.

Let me share the plan/status:
1. Currently Kukjin Kim is on out of office (he told me he will be back
on Christmas).
2. I asked arm-soc people to pull my requests.

3. I applied this patchset to my branch:
next/stuff-late-not-split-per-branch
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch

4. This branch is not pushed to linux-next. I will sort it out if my
previous pull requests get in. I will be out of office for Christmas so
depending on the timing of arm-soc/Christmas/Kukjin this may or may not
go into v4.5 (yay...).

5. If it does not get into v4.5, I will rebase it and proceed further
for v4.6.

If you have any questions, please let me know.

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 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks

[Krzysztof Kozlowski]

On 17.12.2015 02:23, Sylwester Nawrocki wrote:
> Krzysztof,
> 
> On 09/12/15 14:36, Krzysztof Kozlowski wrote:
>> W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze:
>>>> Adding Stephen and linux-clk at Cc.
>>>>
>>>> On 09/12/15 05:49, Krzysztof Kozlowski wrote:
>>>>>> On 08.12.2015 22:46, Marek Szyprowski wrote:
>>>>>>>>>> This patch adds clocks, which are required for preserving parent 
>>>>>>>>>> clock
>>>>>>>>>> configuration on GSCL power domain on/off.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/clk/samsung/clk-exynos5420.c   | 8 
>>>>>>>>>>  include/dt-bindings/clock/exynos5420.h | 2 ++
>>>>>>>>>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> I suppose that, with ack from clock folks, this can go through 
>>>>>> samsung-soc?
>>>>
>>>> I guess it makes more sense that making a stable branch with just
>>>> this patch to be pulled into arm-soc and clk tree. I'm fine with
>>>> applying this patch through arm-soc, but I think we also need
>>>> Mike's or Stephen ack for this.
>>>>
>>>> Acked-by: Sylwester Nawrocki <s.nawro...@samsung.com>
>>
>> I am fine with the branch approach (actually in such cases I make them
>> anyway just in case).
>>
>> As you suggested I'll wait for Mike's or Stepen's acks.
> 
> I've put the $subject patch and the other exynos5420 patch which 
> was a dependency for dts patches (both touching include/dt-bindings/
> clock/exynos5420.h) onto a stable branch. Below are details if 
> you need to pull.

Great! Thanks Sylwester.
BR,
Krzysztof


> 
> 
> The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89:
> 
>   Linux 4.4-rc5 (2015-12-13 17:42:58 -0800)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/snawrocki/samsung.git tags/for-4.5-clk-exynos5420
> 
> for you to fetch changes up to bee4f87f01dc30fcf9e05eb55b833f89fd9bb4f4:
> 
>   clk: samsung: exynos5420: add cpu clock configuration data and instantiate 
> cpu clock (2015-12-16 16:35:26 +0100)
> 
> 
> Samsung exynos5420 SoC clk subsystem support updates:
> instantiation of the cpu clocks and addition of the GSCL
> IP parent clocks to the list of available consumer clocks.
> 
> 
> Marek Szyprowski (1):
>   clk: samsung: exynos542x: add missing parent GSCL block clocks
> 
> Thomas Abraham (1):
>   clk: samsung: exynos5420: add cpu clock configuration data and 
> instantiate cpu clock
> 
>  drivers/clk/samsung/clk-exynos5420.c   |   66 
> +---
>  include/dt-bindings/clock/exynos5420.h |4 ++
>  2 files changed, 64 insertions(+), 6 deletions(-)
> 

--
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: [GIT PULL 0/9] ARM: EXYNOS: Pull request for v4.5

[Krzysztof Kozlowski]

On 17.12.2015 10:43, Krzysztof Kozlowski wrote:
> On 02.12.2015 10:39, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> A lot of stuff for v4.5 with 3 dependencies split into
>> separate tags. The need for dependency is explained both
>> in merge-commit and in description of a tag which is using
>> the dependency.
> 
> Hi everyone,
> 
> It's been like two weeks... we are after v4.4-rc5 and Christmas season
> is coming... there are some dependencies here and even more stuff waits
> out of queue for this pull request (moving SROM and PMU to drivers/soc,
> cpufreq for Exynos542x).
> 
> What I want to say is that I am really not sure whether further waiting
> is beneficial...
> All these patches have been boiling in linux-next for some time (through
> my tree).
> 
> 
> Are there any comments about this pull request? Ordering of branches?
> Weird looking tags? Bugs? etc.? Anything waits in your tree Kukjin?
> 
> 
> Maybe this could be pulled directly by arm-soc folks?
> 

Actually in the same time I sent this mail I got an ack from Kukjin (his
Business Trip to China extended further than planned), so:

Arnd, Kevin and Olof,
Could you pull this for v4.5 or share your comments?


The number of tags is not that scary... just some dependencies split
across 3 tags.


Best regards,
Krzysztof



> 
>>
>> The order goes like (but of course dependencies
>> could be pulled all at once at beginning):
>> 1. tags/samsung-dt-syscon-restart-4.5
>> 2. tags/samsung-soc-4.5
>> 3. tags/samsung-clk-arm64-symbols-4.5
>> 4. tags/samsung-soc64-4.5
>> 5. tags/samsung-drivers-4.5
>> 6. tags/samsung-clk-exynos4-4.5
>> 7. tags/samsung-dt-4.5
>> 8. tags/samsung-dt64-4.5
>> 9. tags/samsung-defconfig-4.5
>>
>> I split dependencies to three tags so clock or other folks could
>> easily grab them if needed.
>>
>> Please share your comments or pull as early as possible as we have here
>> some more dependencies than usual.
>>
>>
>> Kind 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: [GIT PULL 0/9] ARM: EXYNOS: Pull request for v4.5

[Krzysztof Kozlowski]

On 02.12.2015 10:39, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> A lot of stuff for v4.5 with 3 dependencies split into
> separate tags. The need for dependency is explained both
> in merge-commit and in description of a tag which is using
> the dependency.

Hi everyone,

It's been like two weeks... we are after v4.4-rc5 and Christmas season
is coming... there are some dependencies here and even more stuff waits
out of queue for this pull request (moving SROM and PMU to drivers/soc,
cpufreq for Exynos542x).

What I want to say is that I am really not sure whether further waiting
is beneficial...
All these patches have been boiling in linux-next for some time (through
my tree).


Are there any comments about this pull request? Ordering of branches?
Weird looking tags? Bugs? etc.? Anything waits in your tree Kukjin?


Maybe this could be pulled directly by arm-soc folks?


Best regards,
Krzysztof

> 
> The order goes like (but of course dependencies
> could be pulled all at once at beginning):
> 1. tags/samsung-dt-syscon-restart-4.5
> 2. tags/samsung-soc-4.5
> 3. tags/samsung-clk-arm64-symbols-4.5
> 4. tags/samsung-soc64-4.5
> 5. tags/samsung-drivers-4.5
> 6. tags/samsung-clk-exynos4-4.5
> 7. tags/samsung-dt-4.5
> 8. tags/samsung-dt64-4.5
> 9. tags/samsung-defconfig-4.5
> 
> I split dependencies to three tags so clock or other folks could
> easily grab them if needed.
> 
> Please share your comments or pull as early as possible as we have here
> some more dependencies than usual.
> 
> 
> Kind 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 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source

[Krzysztof Kozlowski]

On 16.12.2015 01:35, Sudeep Holla wrote:
> 
> 
> On 21/10/15 11:10, Sudeep Holla wrote:
>> Though the keyboard and other driver will continue to support the legacy
>> "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the
>> wakeup source, "wakeup-source" is the new standard binding.
>>
>> This patch replaces all the legacy wakeup properties with the unified
>> "wakeup-source" property in order to avoid any futher copy-paste
>> duplication.
>>
>> Cc: Kukjin Kim <kg...@kernel.org>
>> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Ping, do you prefer taking via your tree or should I send to armsoc
> directly ?

Usually it depends on the dependencies... but:
1. I just received this patch - 12/19.
2. No cover letter, no other patches, no explanation about any
dependencies or other related changes. Nothing. Just one patch.
3. The patch mentions new standard binding. Was the new binding already
merged? Or is it part of these series? What about backward compatibility?

BR,
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 v6 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Krzysztof Kozlowski]

On 16.12.2015 02:33, Bartlomiej Zolnierkiewicz wrote:
> From: Thomas Abraham <thomas...@samsung.com>
> 
> For Exynos542x/5800 platforms, add CPU operating points
> for migrating from Exynos specific cpufreq driver to using
> generic cpufreq driver.
> 
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
> - merged Exynos5422 fixes from Ben
> 
> Changes by Ben Gamari:
> - Port to operating-points-v2
> 
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Doug Anderson <diand...@chromium.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Andreas Faerber <afaer...@suse.de>
> Signed-off-by: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Ben Gamari <b...@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi |  10 +++
>  arch/arm/boot/dts/exynos5420.dtsi  | 110 
> +
>  arch/arm/boot/dts/exynos5422-cpus.dtsi |  10 +++
>  3 files changed, 130 insertions(+)
> 

Thanks for rebasing on "exynos5422-cpus.dtsi" patch, I appreciate this.

Looks good:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Krzysztof Kozlowski]

On 15.12.2015 08:37, Toshi Kani wrote:
> Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
> instead of strcmp() with "System RAM", in the resource table.
> 
> No functional change is made to the interface.
> 
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Toshi Kani <toshi.k...@hpe.com>
> ---
>  arch/arm/plat-samsung/pm-check.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v4 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Krzysztof Kozlowski]

On 14.12.2015 15:38, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
> 
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon <linux.am...@gmail.com>
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
> +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 47 
> +
>  2 files changed, 94 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 14.12.2015 15:38, Chanwoo Choi wrote:
> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
> 
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> ---
>  drivers/devfreq/Kconfig |  15 ++
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/exynos/Makefile |   1 +
>  drivers/devfreq/exynos/exynos-bus.c | 449 
> 
>  4 files changed, 466 insertions(+)
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 64281bb2f650..55ec774f794c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
>  
>  comment "DEVFREQ Drivers"
>  
> +config ARM_EXYNOS_BUS_DEVFREQ
> + bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
> + depends on ARCH_EXYNOS
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select DEVFREQ_EVENT_EXYNOS_PPMU
> + select PM_DEVFREQ_EVENT
> + select PM_OPP
> + help
> +   This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
> +   Memory bus has one more group of memory bus (e.g, MIF and INT block).
> +   Each memory bus group could contain many memoby bus block. It reads
> +   PPMU counters of memory controllers by using DEVFREQ-event device
> +   and adjusts the operating frequencies and voltages with OPP support.
> +   This does not yet operate with optimal voltages.
> +
>  config ARM_EXYNOS4_BUS_DEVFREQ
>   bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
>   depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
> !ARCH_MULTIPLATFORM
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9ee983d..375ebbb4fcfb 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)   += governor_powersave.o
>  obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)  += governor_userspace.o
>  
>  # DEVFREQ Drivers
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos/

Why limiting it to ARCH_EXYNOS? Are there real dependencies on exynos
mach code? Or on ARM code?

If not, then this probably should be obj-y to allow compile testing.
Particular objects would be selected by ARM_EXYNOS_BUS_DEVFREQ.

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: Odroid U3 mutex deadlock.

[Krzysztof Kozlowski]

On 12.12.2015 13:32, Anand Moon wrote:
> Hi Krzysztof,
> 
> I am just observing this deadlock om my Odroid U3.

This is not a deadlock yet, just a report from lockdep. Could be a real
issue, could be false positive, maybe some locks miss nesting annotations.

Typical information for bug report would be useful, like the exact
version (it is mentioned in lockdep report but is it really correct?)
and reproducibility. And of course git-bisect would be nice to have, see:
Documentation/BUG-HUNTING

Best regards,
Krzysztof


> --
> 
> [2.937531] =
> [2.938733] [ INFO: possible recursive locking detected ]
> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
> [2.948195] -
> [2.953577] swapper/0/1 is trying to acquire lock:
> [2.958351]  (>lock){+.+...}, at: []
> __genpd_poweron+0x64/0x108
> [2.965727]
> [2.965727] but task is already holding lock:
> [2.971543]  (>lock){+.+...}, at: []
> genpd_dev_pm_attach+0x168/0x1b8
> [2.979355]
> [2.979355] other info that might help us debug this:
> [2.985865]  Possible unsafe locking scenario:
> [2.985865]
> [2.991768]CPU0
> [2.994198]
> [2.996628]   lock(>lock);
> [2.26]   lock(>lock);
> [3.003225]
> [3.003225]  *** DEADLOCK ***
> [3.003225]
> [3.009128]  May be due to missing lock nesting notation
> [3.009128]
> [3.015900] 3 locks held by swapper/0/1:
> [3.019804]  #0:  (>mutex){..}, at: []
> __driver_attach+0x48/0x98
> [3.027442]  #1:  (>mutex){..}, at: []
> __driver_attach+0x58/0x98
> [3.035081]  #2:  (>lock){+.+...}, at: []
> genpd_dev_pm_attach+0x168/0x1b8
> [3.043326]
> [3.043326] stack backtrace:
> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [3.060444] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [3.068163] [] (show_stack) from []
> (dump_stack+0x84/0xc4)
> [3.075367] [] (dump_stack) from []
> (__lock_acquire+0x1f88/0x215c)
> [3.083262] [] (__lock_acquire) from []
> (lock_acquire+0xa4/0xd0)
> [3.090990] [] (lock_acquire) from []
> (mutex_lock_nested+0x70/0x4d4)
> [3.099061] [] (mutex_lock_nested) from []
> (__genpd_poweron+0x64/0x108)
> [3.107393] [] (__genpd_poweron) from []
> (genpd_dev_pm_attach+0x170/0x1b8)
> [3.115986] [] (genpd_dev_pm_attach) from []
> (platform_drv_probe+0x2c/0xac)
> [3.124667] [] (platform_drv_probe) from []
> (driver_probe_device+0x208/0x2fc)
> [3.133519] [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [3.141939] [] (__driver_attach) from []
> (bus_for_each_dev+0x68/0x9c)
> [3.150097] [] (bus_for_each_dev) from []
> (bus_add_driver+0x1a0/0x218)
> [3.158344] [] (bus_add_driver) from []
> (driver_register+0x78/0xf8)
> [3.166330] [] (driver_register) from []
> (exynos_drm_register_drivers+0x28/0x74)
> [3.175441] [] (exynos_drm_register_drivers) from
> [] (exynos_drm_init+0x6c/0xc4)
> [3.184556] [] (exynos_drm_init) from []
> (do_one_initcall+0x90/0x1dc)
> [3.192718] [] (do_one_initcall) from []
> (kernel_init_freeable+0x158/0x1f8)
> [3.201396] [] (kernel_init_freeable) from []
> (kernel_init+0x8/0xe8)
> [3.209469] [] (kernel_init) from []
> (ret_from_fork+0x14/0x24)
> [3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
> [3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO lookup
> [3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
> property of node '/hdmi@12D0[0]'
> [3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
> node '/hdmi@12D0[0]' - status (0)
> [3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
> mixer_component_ops)
> [3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
> hdmi_component_ops)
> [3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [3.269812] [drm] No driver support for vblank timestamp query.
> [3.323251] exynos-drm exynos-drm: fb0:  frame buffer device
> [3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> 
> ---
> -Anand Moon
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 11.12.2015 16:52, Chanwoo Choi wrote:
> Dear MyungJoo,
> 
> Almost device tree patches in this series are reviewed by Exynos maintainer.
> Could you please review this series?

Are there any objections to merging DT patches through Samsung-soc?

Looking at the code, there are no dependencies between DT and drivers,
right?

Best regards,
Krzysztof

> 
> Best Regards,
> Chanwoo Choi
> 
> On 2015년 12월 11일 14:07, Chanwoo Choi wrote:
>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
>> have the common architecture for bus between DRAM and sub-blocks in SoC.
>> This driver can support the generic bus frequency driver for Exynos SoCs.
>>
>> In devicetree, Each bus block has a bus clock, regulator, operation-point
>> and devfreq-event devices which measure the utilization of each bus block.
>>
>> Signed-off-by: Chanwoo Choi 
>> [linux.amoon: Tested on Odroid U3]
>> Tested-by: Anand Moon 
>> ---
>>  drivers/devfreq/Kconfig |  15 ++
>>  drivers/devfreq/Makefile|   1 +
>>  drivers/devfreq/exynos/Makefile |   1 +
>>  drivers/devfreq/exynos/exynos-bus.c | 449 
>> 
>>  4 files changed, 466 insertions(+)
>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/7] ARM: Exynos: use generic cpufreq driver for Exynos5420

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> The new CPU clock type allows the use of cpufreq-dt driver
> for Exynos5420.
> 
> Cc: Tomasz Figa <tomasz.f...@gmail.com>
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/mach-exynos/exynos.c | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v5 1/7] ARM: dts: Exynos542x/5800: add cluster regulator supply properties

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> Add cluster regulator supply properties as a preparation to
> adding generic cpufreq-dt driver support for Exynos542x and
> Exynos5800 based boards.
> 
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Doug Anderson <diand...@chromium.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Andreas Faerber <afaer...@suse.de>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 8 
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 8 
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 
>  arch/arm/boot/dts/exynos5800-peach-pi.dts      | 8 
>  5 files changed, 40 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> From: Thomas Abraham <thomas...@samsung.com>
> 
> For Exynos542x/5800 platforms, add CPU operating points
> for migrating from Exynos specific cpufreq driver to using
> generic cpufreq driver.
> 
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patch
> - merged Exynos5422 fixes from Ben
> 
> Changes by Ben Gamari:
> - Port to operating-points-v2
> 
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Doug Anderson <diand...@chromium.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Andreas Faerber <afaer...@suse.de>
> Signed-off-by: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Ben Gamari <b...@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi  | 122 
> +
>  arch/arm/boot/dts/exynos5422-cpus.dtsi |  10 +++
>  2 files changed, 132 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v5 7/7] ARM: Exynos: use generic cpufreq driver for Exynos5422/5800

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> The new CPU clock type allows the use of generic cpufreq-dt driver
> for Exynos5422/5800.
> 
> Cc: Tomasz Figa <tomasz.f...@gmail.com>
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/mach-exynos/exynos.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v5 6/7] ARM: dts: Exynos5800: fix CPU OPP

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> Fix CPU operating points for Exynos5800 (it use different
> voltages than Exynos5420 and supports additional frequencies).
> However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and
> 1400MHz OPP (for A7 cores) for now as they are not available
> on all boards.
> 
> Based on Hardkernel's kernel for ODROID-XU3 board.
> 
> Changes by Ben Gamari:
> - Port to operating-points-v2
> 
> Cc: Kukjin Kim <kgene@samsung.com>
> Cc: Doug Anderson <diand...@chromium.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Andreas Faerber <afaer...@suse.de>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Signed-off-by: Ben Gamari <b...@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5800.dtsi | 108 
> ++++++
>  1 file changed, 108 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Krzysztof Kozlowski]

On 11.12.2015 13:13, Viresh Kumar wrote:
> On 11-12-15, 13:00, Krzysztof Kozlowski wrote:
>> It wasn't working like this. The cpu0 got the index from booting cpu, so
>> on 5420 cpu0 was A15 and on 5422 it was A7.
>>
>> Maybe I am not aware of some changes recently in the kernel but how do
>> you want to assign the booting CPU proper number (not CPU0)?
> 
> Okay, this is how it works and I don't think you need to change the
> order of CPUs based on machines.
> 
> The boot CPU isn't controlled by the DT file but your bootloader, so
> it will be A15 on 5420 and A7 on 5422.
> 
> Now if you keep the order in DT as: 0-3 A7 and 4-7 A15 irrespective of
> the SoCs, then this is how they will be assigned.
> 
> Linux CPU numbers   Actual CPU assigned to them
> 54205422
> 
> CPU0A15-0 (boot)A7-0 (boot)
> CPU1A7-0A7-1
> CPU2A7-1A7-2
> CPU3A7-2A7-3
> CPU4A7-3A15-0
> CPU5A15-1   A15-1
> CPU6A15-2   A15-2
> CPU7A15-3   A15-3
> 
> This happens because all non-boot CPUs will be added in the order they
> are present in DT.
> 
> Now, there should be no *real* reason for you to want your CPUs to be
> always contiguous, isn't it?
> 
> In the case of 5420, cpufreq will show related CPUs as:
> Policy0: CPU0,5-7, Policy1: CPU1-4
> 
> and in the case of 5422, cpufreq will show related CPUs as:
> Policy0: CPU0-3, Policy1: CPU4-7
> 
> And I think you should really fix this now..

We had such configuration before (before df09df6f9ac3). I don't see any
benefit in what you described. Where is the "thing" to be fixed? It is
mixed up. The contiguous ordering is easier to read and more natural.

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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Krzysztof Kozlowski]

On 11.12.2015 12:32, Viresh Kumar wrote:
> On 11-12-15, 00:25, Javier Martinez Canillas wrote:
>> The problem is that the big and LITTLE cores have different ordering per 
>> SoCs:
>>
>> - Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7)
>> - Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15)
>>
>> So the OPP tables are set in this DTSI file, to prevent the OPP tables
>> in the Exynos5422 to be inverted for the cluster 0 and 1.
> 
> Oh dude, that's really *ugly*. :)
> 
> Reusing files/definitions is fine to the point where things are
> readable. But you have screwed it up so very badly.
> 
> Over that, why can't you keep cpu0-3 as A7 and 4-7 as a15 for all the
> cases? The only worrying thing for you should be that CPU0 within the
> kenrel should be controllable, right? i.e. you want a A15 to boot 5800
> and A7 to boot 5422.
> 
> If yes, than you could have kept the CPUs in 5422 as:
> 0-3: A7
> 4-7: A15
> 
> and in 5420 as:
> 4-7: A15
> 0-3: A7
> 
> Wouldnt' that work ?

It wasn't working like this. The cpu0 got the index from booting cpu, so
on 5420 cpu0 was A15 and on 5422 it was A7.

Maybe I am not aware of some changes recently in the kernel but how do
you want to assign the booting CPU proper number (not CPU0)?

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 v5 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms

[Krzysztof Kozlowski]

On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series adds generic cpufreq-dt driver support for
> Exynos542x/5800 (using the new CPU clock type which allows it).
> 
> It has been tested on Exynos5422 based ODROID-XU3 Lite board.
> 
> Depends on:
> - next-20151124 branch of linux-next kernel tree

Bartlomiej,
Thanks for update! Nice work. Everything looks good for me. As for
merging, my last pull requests are waiting on Kukjin, so I am not
grabbing more stuff till they get in. This (I hope) should happen this
weekend so:
1. Either Kukjin will pick it up directly,
2. I could apply this later and hopefully still send them for v4.5.


Sylwester,
However in case of any delay, how about merging clock changes now
through clock tree and preparing a tag for samsung-soc? If the series
won't make till v4.5 then at least dependency would be merged.

In that case you could also pick the first patch from Marek's GSCL clock.


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 v4 38/58] mtd: nand: s3c2410: use the mtd instance embedded in struct nand_chip

[Krzysztof Kozlowski]

On 10.12.2015 17:00, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Make use of this mtd instance.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> Changes generated with the following coccinelle script
> 
> --->8---
> virtual patch
> 
> @fix1@
> identifier __chipfield, __mtdfield;
> type __type;
> @@
> (
>   __type {
>   ...
>   struct nand_chip __chipfield;
>   ...
> - struct mtd_info __mtdfield;
>   ...
>   };
> |
>   __type {
>   ...
> - struct mtd_info __mtdfield;
>   ...
>   struct nand_chip __chipfield;
>   ...
>   };
> )
> 
> @fix2 depends on fix1@
> identifier fix1.__chipfield, fix1.__mtdfield;
> identifier __subfield;
> type fix1.__type;
> __type *__priv;
> @@
> (
> - __priv->__mtdfield.__subfield
> + nand_to_mtd(&__priv->__chipfield)->__subfield
> |
> - &(__priv->__mtdfield)
> + nand_to_mtd(&__priv->__chipfield)
> )
> --->8---
> ---
>  drivers/mtd/nand/s3c2410.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 

Looks correct:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v3 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
> Exynos3250 has following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK400 clock for MCUISP
> - ACLK266 clock for ISP
> - ACLK200 clock for FSYS
> - ACLK160 clock for LCD0
> - ACLK100 clock for PERIL
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 147 
> ++
>  1 file changed, 147 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v3 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.

"noes", pointed at v2.

> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon <linux.am...@gmail.com>
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 68 
> +++
>  1 file changed, 68 insertions(+)

The code itself:
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Best regards,
Krzysztof


> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 84a23f962946..99a0f4ca3d47 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -281,6 +281,74 @@
>   clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
>   #iommu-cells = <0>;
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + opp-microvolt = <95>;
> + };
> + opp@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <105>;
> + };
> + };
> +
> + bus_acp_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + };
> + };
>  };
>  
>   {
> 

--
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 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node

I think the goal of the patch was to remove duplication of nodes, not to
duplicate them. :)

Except of that patch is okay:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Best regards,
Krzysztof


> because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same
> PPMU device tree node.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos3250-monk.dts   | 41 +
>  arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  1 +
>  arch/arm/boot/dts/exynos4412-ppmu-common.dtsi   | 49 
> +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 41 +
>  5 files changed, 53 insertions(+), 120 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi

--
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 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus device-tree node of INT (internal) block
> to enable the bus frequency scaling. The following sub-blocks share
> the VDD_INT power source:
> - LEFTBUS (parent device)
> - RIGHTBUS
> - PERIL
> - LCD0
> - FSYS
> - MCUISP / ISP
> - MFC
> 
> The LEFTBUS is parent device with devfreq ondemand governor
> and the rest devices has the dependency on LEFTBUS bus.

I pointed this previously. If you wish to leave the sentence in such
form then "rest of" and "have" not "has".

Best regards,
Krzysztof

> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos3250-rinato.dts | 41 
> +
>  1 file changed, 41 insertions(+)
> 
--
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 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
>   When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon <linux.am...@gmail.com>
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 106 
> ++++++
>  1 file changed, 106 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v3 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
> one power line for all buses to translate data between DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - DMC/ACP clock for DMC (Dynamic Memory Controller)
> - ACLK200 clock for LCD0
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD0/LCD1
> - ACLK133 clock for FSYS/GPS
> - GDL/GDR clock for LEFTBUS/RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos4210.dtsi | 159 
> ++
>  1 file changed, 159 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v3 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
> 
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 48 
> +
>  2 files changed, 95 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 7bd65026761e..b6818aec7cf9 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -501,3 +501,50 @@
>   {
>   status = "okay";
>  };
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};

I meant put them in proper place, respecting alphabetical order. The 'b'
comes before 'w'.

As for the new nodes (bus_XXX) your previous sorting (first parent, then
passive) was also okay - it had sense. This is up to you. Just put
everything not at the end of file.

Best regards,
Krzysztof


> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 92438eb6eec6..0b8aff3b8cb7 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1251,3 +1251,51 @@
>   vtmu-supply = <_reg>;
>   status = "okay";
>  };
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> 

--
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] pwm: Avoid double mutex lock on pwm_enable

[Krzysztof Kozlowski]

On 11.12.2015 13:07, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>> Hi Krzysztof,

[...]

>> Yes, now you pasted the same warning I did...
>>
>> This is still the same issue. I already wrote it:
>>> 1. BUG: sleeping function called from invalid context
>>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> We can repeat it many times but that won't change anything...
>>
>> Best regards,
>> Krzysztof
> 
> Would you consider below changes to fix the above issue.
> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
> And I don't observed issue.
> 
> 1. BUG: sleeping function called from invalid context
> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
> 
> Please share your thought on this changes.
> 
> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index d24ca5f..f3f6cf9 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
> if (!pwm)
> return -EINVAL;
> 
> +   if (!mutex_is_locked(>lock))
> +   return -EINVAL;
> +
> mutex_lock(>lock);
> 
> if (!test_and_set_bit(PWMF_ENABLED, >flags)) {

First of all, Thierry suggested way of fixing this:
"Any objections to simply removing it and make all users use a workqueue
or some such if they need to control a PWM as a result of an interrupt
trigger?"
what is wrong with his approach?

Second, you are writing something that looks like mutex-try-lock...
which will fail the pwm_enable(). IMHO this *hides* the real issue and
does not solve anything (except hiding also the warning).

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 v3 03/20] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
> SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
> block.
> 
> Following list specifies the detailed relation between the clock and DMC 
> block:
> - The source clock of DMC block : div_dmc
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>  1 file changed, 34 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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] ARM: dts: Make CPU configuration more readable for exynos542x/5800

[Krzysztof Kozlowski]

Exynos5420 and Exynos5800 boards boot from big core (A15) but
Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
is property of the board - configurable by pulling up/down gpg2-1).
To make user-visible CPU ordering more consistent the 'cpus' node was
overridden by exynos5422-cpus.dtsi.

However this is a little bit ugly and error-prone. Overriding the CPU
child nodes requires to basically reverse what was done initially in
exynos5420.dtsi.

Instead, split CPU configuration entirely to separate files which should
be included by board DTS.

Suggested-by: Viresh Kumar <viresh.ku...@linaro.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

---

Tested on Exynos5422 based Odroid XU4. Please kindly test on Exynos5420
or Exynos5800 boards.
---
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |   1 +
 arch/arm/boot/dts/exynos5420-cpus.dtsi|  92 ++
 arch/arm/boot/dts/exynos5420-peach-pit.dts|   1 +
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   1 +
 arch/arm/boot/dts/exynos5420.dtsi |  72 +-
 arch/arm/boot/dts/exynos5422-cpus.dtsi| 130 ++
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   1 +
 7 files changed, 170 insertions(+), 128 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5420-cpus.dtsi

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 4ecef6981d5c..365eec6f6687 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "exynos5420.dtsi"
+#include "exynos5420-cpus.dtsi"
 #include 
 #include 
 #include 
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
new file mode 100644
index ..7aaf0313274f
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -0,0 +1,92 @@
+/*
+ * SAMSUNG EXYNOS5420 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This file provides desired ordering for Exynos5420 and Exynos5800
+ * boards: CPU[0123] being the A15.
+ *
+ * The Exynos5420, 5422 and 5800 actually share the same CPU configuration
+ * but particular boards choose different booting order.
+ *
+ * Exynos5420 and Exynos5800 always boot from Cortex-A15. On Exynos5422
+ * booting cluster (big or LITTLE) is chosen by IROM code by reading
+ * the gpg2-1 GPIO. By default all Exynos5422 based boards choose booting
+ * from the LITTLE: Cortex-A7.
+ *
+ * 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.
+ */
+
+/ {
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x0>;
+   clock-frequency = <18>;
+   cci-control-port = <_control1>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x1>;
+   clock-frequency = <18>;
+   cci-control-port = <_control1>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x2>;
+   clock-frequency = <18>;
+   cci-control-port = <_control1>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0x3>;
+   clock-frequency = <18>;
+   cci-control-port = <_control1>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x100>;
+   clock-frequency = <10>;
+   cci-control-port = <_control0>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x101>;
+   clock-frequency = <10>;
+   cci-control-port = <_control0>;
+   };
+
+  

Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Krzysztof Kozlowski]

On 11.12.2015 13:53, Javier Martinez Canillas wrote:
> Hello Viresh,
> 
> On 12/11/2015 01:38 AM, Viresh Kumar wrote:
>> On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
>>> We had such configuration before (before df09df6f9ac3). I don't see any
>>> benefit in what you described. Where is the "thing" to be fixed? It is
>>> mixed up. The contiguous ordering is easier to read and more natural.
>>
>> This is what you are doing today (keeping on one CPU per cluster to
>> simplify it):
>>
>>  cpu0: cpu@0 {
>>  device_type = "cpu";
>>  compatible = "arm,cortex-a15";
>>  reg = <0x0>;
>>  clock-frequency = <18>;
>>  cci-control-port = <_control1>;
>>  };
>>
>>  cpu4: cpu@100 {
>>  device_type = "cpu";
>>  compatible = "arm,cortex-a7";
>>  reg = <0x100>;
>>  clock-frequency = <10>;
>>  cci-control-port = <_control0>;
>>  };
>>
>>
>> Then you overwrite it with:
>>
>>  {
>>  device_type = "cpu";
>>  compatible = "arm,cortex-a7";
>>  reg = <0x100>;
>>  clock-frequency = <10>;
>>  cci-control-port = <_control0>;
>> };
>> 
>>  {
>>  device_type = "cpu";
>>  compatible = "arm,cortex-a15";
>>  reg = <0x0>;
>>  clock-frequency = <18>;
>>  cci-control-port = <_control1>;
>> };
>>
>>
>> Don't you think this isn't the right way of solving problems?
>>
>> The DT overwrite feature isn't there to do such kind of stuff, though
>> it doesn't stop you from doing that.
>>
> 
> I still fail to understand why the override is not a good way to solve
> the issue.
>  
>> Either you should keep separate paths for both the SoCs, or can solve
> 
> There's no point IMHO to duplicate the HW description since is the only
> difference between the Exynos5422 and Exynos5800 SoCs AFAIK.

Actually I think there is no nice way of making this as separate paths.
As Javier's mentioned, there aren't many differences. Currently the CPU
ordering is the only difference in DT.

Making it as separate path would create hierarchy like:
 - exynos5420-based-board.dts
   \- include: exynos5420.dtsi
  \- include: exynos5.dtsi
   \- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi)

 - exynos5422-based-board.dts
   \- include: exynos5420.dtsi
  \- include: exynos5.dtsi
   \- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi)

which of course is okay... except we keep the definition of CPUs
completely outside of main Exynos5420 DTSI. Then we have to include both
DTSI for each new DTS.

Other idea is to create artificial "exynos5420-common":
 - exynos5420-based-board.dts
   \- include: exynos5420.dtsi
   \- include: exynos5420-common.dtsi
  \- include: exynos5.dtsi
   \- include: exynos5420-cpu.dtsi

 - exynos5422-based-board.dts
   \- include: exynos5422.dtsi
  \- include: exynos5420-common.dtsi
 \- include: exynos5.dtsi
  \- include: exynos5422-cpu.dtsi

This is also confusing...

Any third idea?

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] ARM: dts: Make CPU configuration more readable for exynos542x/5800

[Krzysztof Kozlowski]

On 11.12.2015 15:21, Viresh Kumar wrote:
> On 11-12-15, 15:17, Krzysztof Kozlowski wrote:
>> Exynos5420 and Exynos5800 boards boot from big core (A15) but
>> Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
> 
> s/Exynos5420/Exynos5422

Damn, one can get confused.

Thanks for review!
Krzysztof

> and then you can add
> 
> Reviewed-by: Viresh Kumar <viresh.ku...@linaro.org>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos bus frequency
> driver.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 93 
> ++
>  1 file changed, 93 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> 

Thanks, now it looks good to me.

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 2/2] ARM: dts: exynos542x: add GSCL block parent clock management to pm domain

[Krzysztof Kozlowski]

W dniu 09.12.2015 o 17:07, Marek Szyprowski pisze:
> Add support for restoring GScaler parent clocks configuration when GSCL
> power domain is turned on.
> 
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Changelog is always nice, even though the traffic on samsung-soc is not
huge now.

Anyway, thanks for update:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks

[Krzysztof Kozlowski]

W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze:
> Adding Stephen and linux-clk at Cc.
> 
> On 09/12/15 05:49, Krzysztof Kozlowski wrote:
>> On 08.12.2015 22:46, Marek Szyprowski wrote:
>>>> This patch adds clocks, which are required for preserving parent clock
>>>> configuration on GSCL power domain on/off.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>>>> ---
>>>>  drivers/clk/samsung/clk-exynos5420.c   | 8 
>>>>  include/dt-bindings/clock/exynos5420.h | 2 ++
>>>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> I suppose that, with ack from clock folks, this can go through samsung-soc?
> 
> I guess it makes more sense that making a stable branch with just
> this patch to be pulled into arm-soc and clk tree. I'm fine with
> applying this patch through arm-soc, but I think we also need
> Mike's or Stephen ack for this.
> 
> Acked-by: Sylwester Nawrocki <s.nawro...@samsung.com>

I am fine with the branch approach (actually in such cases I make them
anyway just in case).

As you suggested I'll wait for Mike's or Stepen's acks.

BR,
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 v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:

(...)

>  .../devicetree/bindings/devfreq/exynos-bus.txt |  383 +++

How about adding this file to the MAINTAINERS to devfreq exynos entry?
Unfortunately, in current linux-next, I can find the entry for devfreq
exynos. However I saw patches adding such entries... aren't they merged
to linux-next?

Best regards,
Krzysztof

>  arch/arm/boot/dts/exynos3250-monk.dts  |6 +
>  arch/arm/boot/dts/exynos3250-rinato.dts|   47 +
>  arch/arm/boot/dts/exynos3250.dtsi  |  194 
>  arch/arm/boot/dts/exynos4210.dtsi  |  172 
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   93 +-
>  arch/arm/boot/dts/exynos4412-trats2.dts|   47 +
>  arch/arm/boot/dts/exynos4x12.dtsi  |  184 
>  drivers/devfreq/Kconfig|   37 +-
>  drivers/devfreq/Makefile   |2 +
>  drivers/devfreq/devfreq.c  |  120 ++-
>  drivers/devfreq/exynos/Makefile|3 +-
>  drivers/devfreq/exynos/exynos-bus.c|  549 ++
>  drivers/devfreq/exynos/exynos4_bus.c   | 1055 
> 
>  drivers/devfreq/exynos/exynos4_bus.h   |  110 --
>  drivers/devfreq/exynos/exynos5_bus.c   |  431 
>  drivers/devfreq/exynos/exynos_ppmu.c   |  119 ---
>  drivers/devfreq/exynos/exynos_ppmu.h   |   86 --
>  drivers/devfreq/governor.h |7 +
>  drivers/devfreq/governor_passive.c |  109 ++
>  drivers/devfreq/governor_performance.c |1 +
>  drivers/devfreq/governor_powersave.c   |1 +
>  drivers/devfreq/governor_simpleondemand.c  |1 +
>  drivers/devfreq/governor_userspace.c   |1 +
>  include/linux/devfreq.h|   28 +
>  25 files changed, 1958 insertions(+), 1828 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
>  delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
>  create mode 100644 drivers/devfreq/governor_passive.c
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 10:09, Chanwoo Choi wrote:
> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
>>> SoC.
>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>>> block.
>>>
>>> Following list specifies the detailed relation between the clock and DMC 
>>> block:
>>> - The source clock of DMC block : div_dmc
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>> ---
>>>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 2f30d632f1cc..7214c5e42150 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -687,6 +687,40 @@
>>> clock-names = "ppmu";
>>> status = "disabled";
>>> };
>>> +
>>> +   bus_dmc: bus_dmc {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_dmc_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_dmc_opp_table: opp_table1 {
>>
>> This is the firsy opp_table, right? So:
>> s/opp_table1/opp_table0/
> 
> Right. It is first opp_table in exynos3250.dtsi.
> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.

Ok

> 
>>
>>> +   compatible = "operating-points-v2";
>>> +   opp-shared;
>>> +
>>> +   opp00 {
>>> +   opp-hz = /bits/ 64 <5000>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp01 {
>>> +   opp-hz = /bits/ 64 <1>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp02 {
>>> +   opp-hz = /bits/ 64 <13400>;
>>> +   opp-microvolt = <80>;
>>
>> Why 134, not 133 MHz?
> 
> When I used the 13300, the source clock is changed to 100Mhz instead of 
> 133MHz.
> I add following test result on exynos3250-rinato board.
> 
> Case1.
> When I use the 134 MHz, the source clock is changed to 133MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real: 
> 13334)
> 
> Case2.
> When I use the 133 MHz, the source clock is changed to 100MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real: 
> 1)

Now I remember that issue. You could use here directly 13334 but
that also would look a little bit weird... so 134 is ok for me. Could
just add a comment that desired frequency is actually "133 MHz"?

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 v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
> Exynos3250 has following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK400 clock for MCUISP
> - ACLK266 clock for ISP
> - ACLK200 clock for FSYS
> - ACLK160 clock for LCD0
> - ACLK100 clock for PERIL
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 160 
> ++
>  1 file changed, 160 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 7214c5e42150..46dee1951ec1 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -721,6 +721,166 @@
>   opp-microvolt = <875000>;
>   };
>   };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_160>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_200>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mcuisp: bus_mcuisp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_400_MCUISP>;
> + clock-names = "bus";
> + operating-points-v2 = <_mcuisp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_isp: bus_isp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_266>;
> + clock-names = "bus";
> + operating-points-v2 = <_isp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peril: bus_peril {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_100>;
> + clock-names = "bus";
> + operating-points-v2 = <_peril_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <8000>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <100>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <100>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_mcuisp_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 11:17, Chanwoo Choi wrote:
> On 2015년 12월 10일 11:04, Krzysztof Kozlowski wrote:
>> On 10.12.2015 11:00, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>>>> On 10.12.2015 10:09, Chanwoo Choi wrote:
>>>>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>>>>>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>>>>>> This patch adds the DMC (Dynamic Memory Controller) bus node for 
>>>>>>> Exynos3250 SoC.
>>>>>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC 
>>>>>>> standard
>>>>>>> SDRAM devices. The bus includes the OPP tables and the source clock for 
>>>>>>> DMC
>>>>>>> block.
>>>>>>>
>>>>>>> Following list specifies the detailed relation between the clock and 
>>>>>>> DMC block:
>>>>>>> - The source clock of DMC block : div_dmc
>>>>>>>
>>>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/exynos3250.dtsi | 34 
>>>>>>> ++
>>>>>>>  1 file changed, 34 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>>>>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> index 2f30d632f1cc..7214c5e42150 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> @@ -687,6 +687,40 @@
>>>>>>> clock-names = "ppmu";
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>> +
>>>>>>> +   bus_dmc: bus_dmc {
>>>>>>> +   compatible = "samsung,exynos-bus";
>>>>>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>>>>>> +   clock-names = "bus";
>>>>>>> +   operating-points-v2 = <_dmc_opp_table>;
>>>>>>> +   status = "disabled";
>>>>>>> +   };
>>>>>>> +
>>>>>>> +   bus_dmc_opp_table: opp_table1 {
>>>>>>
>>>>>> This is the firsy opp_table, right? So:
>>>>>> s/opp_table1/opp_table0/
>>>>>
>>>>> Right. It is first opp_table in exynos3250.dtsi.
>>>>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>>>>> So, I have the plan that support the operation-points-v2 for Exynos3250 
>>>>> CPU.
>>>>
>>>> Ok
>>>>
>>>>>
>>>>>>
>>>>>>> +   compatible = "operating-points-v2";
>>>>>>> +   opp-shared;
>>>>>>> +
>>>>>>> +   opp00 {
>>>>>>> +   opp-hz = /bits/ 64 <5000>;
>>>>>>> +   opp-microvolt = <80>;
>>>>>>> +   };
>>>>>>> +   opp01 {
>>>>>>> +   opp-hz = /bits/ 64 <1>;
>>>>>>> +   opp-microvolt = <80>;
>>>>>>> +   };
>>>>>>> +   opp02 {
>>>>>>> +   opp-hz = /bits/ 64 <13400>;
>>>>>>> +   opp-microvolt = <80>;
>>>>>>
>>>>>> Why 134, not 133 MHz?
>>>>>
>>>>> When I used the 13300, the source clock is changed to 100Mhz instead 
>>>>> of 133MHz.
>>>>> I add following test result on exynos3250-rinato board.
>>>>>
>>>>> Case1.
>>>>> When I use the 134 MHz, the source clock is changed to 133MHz
>>>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) 
>>>>> (real: 13334)
>>>>>
>>>>> Case2.
>>>>> When I use the 133 MHz, the source clock is changed to 100MHz
>>>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) 
>>>>> (real: 1)
>>>>
>>>> Now I remember that issue. You could use here directly 13334 but
>>>> that also would look a little bit weird... so 134 is ok for me. Could
>>>> just add a comment that desired frequency is actually "133 MHz"?
>>>
>>> Do you prefer among following example?
>>>
>>> Example1.
>>> opp02 {
>>> /* The desired frequency is 133MHz because
>>>  * clock change has the dependency on clock driver.
>>>  * When set rate as 134MHz, the clock driver would
>>>  * change the 133MHz actually instead of 134MHz.
>>>  */
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>>
>>> Example2.
>>> opp02 {
>>> opp-hz = /bits/ 64 <13334>;
>>> opp-microvolt = <80>;
>>> };
>>
>> I would prefer the second one (13334) but I don't have strong
>> feelings about it.
> 
> If you ok, I want to maintain the original approach as following:
> 
>   opp02 {
>   opp-hz = /bits/ 64 <13400>;
>   opp-microvolt = <80>;
>   };

OK

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 v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus frequency node
> which includes the devfreq-events and regulator properties. The bus
> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
> with ondemand governor.
> 
> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
> the DMC block.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
>  arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 443a35085846..d982586a6533 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -498,6 +498,12 @@
>   };
>  };
>  
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
>   {
>   clock-frequency = <2400>;
>  };
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 3e64d5dcdd60..61477943015b 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -675,6 +675,12 @@
>   };
>  };
>  
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};

I would prefer to put this in alphabetical order... which could be
tricky because the nodes are not entirely sorted. Maybe after the ""
node?

Anyway the change looks good:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Krzysztof Kozlowski]

On 10.12.2015 09:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
> 
> (...)
> 
>>  .../devicetree/bindings/devfreq/exynos-bus.txt |  383 +++
> 
> How about adding this file to the MAINTAINERS to devfreq exynos entry?
> Unfortunately, in current linux-next, I can find the entry for devfreq

D'oh! I meant:^ I cannot find the entry for...

BR,
Krzysztof

> exynos. However I saw patches adding such entries... aren't they merged
> to linux-next?
> 
> Best regards,
> Krzysztof
> 
>>  arch/arm/boot/dts/exynos3250-monk.dts  |6 +
>>  arch/arm/boot/dts/exynos3250-rinato.dts|   47 +
>>  arch/arm/boot/dts/exynos3250.dtsi  |  194 
>>  arch/arm/boot/dts/exynos4210.dtsi  |  172 
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   93 +-
>>  arch/arm/boot/dts/exynos4412-trats2.dts|   47 +
>>  arch/arm/boot/dts/exynos4x12.dtsi  |  184 
>>  drivers/devfreq/Kconfig|   37 +-
>>  drivers/devfreq/Makefile   |2 +
>>  drivers/devfreq/devfreq.c  |  120 ++-
>>  drivers/devfreq/exynos/Makefile|3 +-
>>  drivers/devfreq/exynos/exynos-bus.c|  549 ++
>>  drivers/devfreq/exynos/exynos4_bus.c   | 1055 
>> 
>>  drivers/devfreq/exynos/exynos4_bus.h   |  110 --
>>  drivers/devfreq/exynos/exynos5_bus.c   |  431 
>>  drivers/devfreq/exynos/exynos_ppmu.c   |  119 ---
>>  drivers/devfreq/exynos/exynos_ppmu.h   |   86 --
>>  drivers/devfreq/governor.h |7 +
>>  drivers/devfreq/governor_passive.c |  109 ++
>>  drivers/devfreq/governor_performance.c |1 +
>>  drivers/devfreq/governor_powersave.c   |1 +
>>  drivers/devfreq/governor_simpleondemand.c  |1 +
>>  drivers/devfreq/governor_userspace.c   |1 +
>>  include/linux/devfreq.h|   28 +
>>  25 files changed, 1958 insertions(+), 1828 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
>>  delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
>>  create mode 100644 drivers/devfreq/governor_passive.c
>>
> 
> 

--
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 004/182] gpio: generic: factor into gpio_chip struct

[Krzysztof Kozlowski]

On 09.12.2015 22:12, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
> 
> Cc: a...@kernel.org
> Cc: Lee Jones <lee.jo...@linaro.org>
> Cc: Alexander Shiyan <shc_w...@mail.ru>
> Cc: Shawn Guo <shawn...@kernel.org>
> Cc: Sascha Hauer <ker...@pengutronix.de>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: Gregory Fong <gregory.0...@gmail.com>
> Cc: Brian Norris <computersforpe...@gmail.com>
> Cc: Florian Fainelli <f.faine...@gmail.com>
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Sudeep Holla <sudeep.ho...@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Cc: Nicolas Pitre <nicolas.pi...@linaro.org>
> Cc: Olof Johansson <o...@lixom.net>
> Cc: Vladimir Zapolskiy <vladimir_zapols...@mentor.com>
> Cc: Rabin Vincent <ra...@rab.in>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---
>  arch/arm/mach-clps711x/board-autcpu12.c |   2 +-
>  arch/arm/mach-clps711x/board-p720t.c|   2 +-
>  arch/arm/mach-imx/mach-mx21ads.c|   2 +-
>  arch/arm/mach-omap1/board-ams-delta.c   |   2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c   |   2 +-

For s3c64xx:
Acked-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch updates the documentation for passive bus devices and adds the
> detailed example of Exynos3250.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 244 
> -
>  1 file changed, 241 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index 54a1f9c46c88..c4fdc70f8eac 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference 
> should be specified
>  in devicetree file instead of each device driver. In result, this driver
>  is able to support the bus frequency for all Exynos SoCs.
>  
> -Required properties for bus device:
> +Required properties for all bus devices:
>  - compatible: Should be "samsung,exynos-bus".
>  - clock-names : the name of clock used by the bus, "bus".
>  - clocks : phandles for clock specified in "clock-names" property.
>  - #clock-cells: should be 1.
>  - operating-points-v2: the OPP table including frequency/voltage information
>to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +
> +Required properties for only parent bus device:

Maybe:
"Required properties only for parent bus devices:"

In this binding documentation file the idea of "parent" is not
explained. I now it is related to passive devfreq governor but looking
at the binding itself it is a new idea, not covered here.

>  - vdd-supply: the regulator to provide the buses with the voltage.
>  - devfreq-events: the devfreq-event device to monitor the curret utilization
>of buses.
>  
> -Optional properties for bus device:
> +Required properties for only passive bus device:

"Required properties only for passive bus devices:"

> +- devfreq: the parent bus device.
> +
> +Optional properties for only parent bus device:
>  - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count againt total cycle count.
>  
> @@ -33,7 +38,20 @@ Example1:
>   power line (regulator). The MIF (Memory Interface) AXI bus is used to
>   transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>  
> - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
> + - MIF (Memory Interface) block
> + : VDD_MIF |--- DMC (Dynamic Memory Controller)
> +
> + - INT (Internal) block
> + : VDD_INT |--- LEFTBUS (parent device)
> +   |--- PERIL
> +   |--- MFC
> +   |--- G3D
> +   |--- RIGHTBUS
> +   |--- FSYS
> +   |--- LCD0
> +   |--- PERIR
> +   |--- ISP
> +   |--- CAM
>  
>   - MIF bus's frequency/voltage table
>   ---
> @@ -46,6 +64,24 @@ Example1:
>   |L5| 40 |875000   |
>   ---
>  
> + - INT bus's frequency/voltage table
> + --
> + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
> + | name|   |LCD0|   |   |   |||
> + | |   |FSYS|   |   |   |||
> + | |   |MFC |   |   |   |||
> + --
> + |Mode |*parent|passive |passive|passive|passive|||
> + --
> + |Lv   |Frequency   ||Voltage |
> + --
> + |L1   |5  |5   |5  |5  |5  ||90  |
> + |L2   |8  |8   |8  |8  |8  ||90  |
> + |L3   |10 |10  |10 |10 |10 ||100 |
> + |L4   |134000 |134000  |20 |20 |   ||100 |
> + |L5   |20 |20  |40 |30 |   ||100 |
> + --
> +
>  Example2 :
>   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>   are listed below:
> @@ -84,6 +120,167 @@ Example2 :
>   };
>   };
>  
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible 

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 11:00, Chanwoo Choi wrote:
> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>> On 10.12.2015 10:09, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>>>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>>>> This patch adds the DMC (Dynamic Memory Controller) bus node for 
>>>>> Exynos3250 SoC.
>>>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC 
>>>>> standard
>>>>> SDRAM devices. The bus includes the OPP tables and the source clock for 
>>>>> DMC
>>>>> block.
>>>>>
>>>>> Following list specifies the detailed relation between the clock and DMC 
>>>>> block:
>>>>> - The source clock of DMC block : div_dmc
>>>>>
>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>>>>>  1 file changed, 34 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>>>> index 2f30d632f1cc..7214c5e42150 100644
>>>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>>>> @@ -687,6 +687,40 @@
>>>>>   clock-names = "ppmu";
>>>>>   status = "disabled";
>>>>>   };
>>>>> +
>>>>> + bus_dmc: bus_dmc {
>>>>> + compatible = "samsung,exynos-bus";
>>>>> + clocks = <_dmc CLK_DIV_DMC>;
>>>>> + clock-names = "bus";
>>>>> + operating-points-v2 = <_dmc_opp_table>;
>>>>> + status = "disabled";
>>>>> + };
>>>>> +
>>>>> + bus_dmc_opp_table: opp_table1 {
>>>>
>>>> This is the firsy opp_table, right? So:
>>>> s/opp_table1/opp_table0/
>>>
>>> Right. It is first opp_table in exynos3250.dtsi.
>>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>>
>> Ok
>>
>>>
>>>>
>>>>> + compatible = "operating-points-v2";
>>>>> + opp-shared;
>>>>> +
>>>>> + opp00 {
>>>>> + opp-hz = /bits/ 64 <5000>;
>>>>> + opp-microvolt = <80>;
>>>>> + };
>>>>> + opp01 {
>>>>> + opp-hz = /bits/ 64 <1>;
>>>>> + opp-microvolt = <80>;
>>>>> + };
>>>>> + opp02 {
>>>>> + opp-hz = /bits/ 64 <13400>;
>>>>> + opp-microvolt = <80>;
>>>>
>>>> Why 134, not 133 MHz?
>>>
>>> When I used the 13300, the source clock is changed to 100Mhz instead of 
>>> 133MHz.
>>> I add following test result on exynos3250-rinato board.
>>>
>>> Case1.
>>> When I use the 134 MHz, the source clock is changed to 133MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) 
>>> (real: 13334)
>>>
>>> Case2.
>>> When I use the 133 MHz, the source clock is changed to 100MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) 
>>> (real: 1)
>>
>> Now I remember that issue. You could use here directly 13334 but
>> that also would look a little bit weird... so 134 is ok for me. Could
>> just add a comment that desired frequency is actually "133 MHz"?
> 
> Do you prefer among following example?
> 
> Example1.
>   opp02 {
>   /* The desired frequency is 133MHz because
>* clock change has the dependency on clock driver.
>* When set rate as 134MHz, the clock driver would
>* change the 133MHz actually instead of 134MHz.
>*/
>   opp-hz = /bits/ 64 <13400>;
>   opp-microvolt = <80>;
>   };
> 
> Example2.
>   opp02 {
>   opp-hz = /bits/ 64 <13334>;
>   opp-microvolt = <80>;
>   };

I would prefer the second one (13334) but I don't have strong
feelings about it.

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 v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
> SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
> block.
> 
> Following list specifies the detailed relation between the clock and DMC 
> block:
> - The source clock of DMC block : div_dmc
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 2f30d632f1cc..7214c5e42150 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -687,6 +687,40 @@
>   clock-names = "ppmu";
>   status = "disabled";
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {

This is the firsy opp_table, right? So:
s/opp_table1/opp_table0/

> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <80>;

Why 134, not 133 MHz?

> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;

Shouldn't this be 825 mV, not 800? I think we used previously that value
for our devices.

Best regards,
Krzysztof


> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
>   };
>  };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 10.12.2015 09:49, Chanwoo Choi wrote:
> Hi,
> 
(...)

>>
>>> +
>>> +   bus_dmc: bus_dmc {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_dmc_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_dmc_opp_table: opp_table0 {
>>> +   compatible = "operating-points-v2";
>>> +   opp-shared;
>>> +
>>> +   opp00 {
>>
>> Maybe use convention with frequency, like:
>>  opp@5000
>> This also used in opp.txt examples.
> 
> In the Documentations/devicetree/bindings/opp/opp.txt,
> the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.

Yes, it was changed by Viresh in "PM / OPP: Rename OPP nodes as
opp@". You can find the most actual bindings in linux-next.

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 v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos bus frequency
> driver.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 94 
> ++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> new file mode 100644
> index ..54a1f9c46c88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,94 @@
> +* Generic Exynos Bus frequency device
> +
> +The Samsung Exynos SoC have many buses for data transfer between DRAM
> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
> +for buses. Generally, the each bus of Exynos SoC includes the source clock
> +and power line and then is able to change the clock according to the usage
> +of each buses on runtime. When gathering the usage of each buses on runtime,
> +thie driver uses the PPMU (Platform Performance Monitoring Unit) which

s/thie/the/

> +is able to measure the current load of sub-blocks.
> +
> +There are a little different composition among Exynos SoC because each Exynos
> +SoC has the different sub-blocks. So, this difference should be specified
> +in devicetree file instead of each device driver. In result, this driver
> +is able to support the bus frequency for all Exynos SoCs.
> +
> +Required properties for bus device:
> +- compatible: Should be "samsung,exynos-bus".
> +- clock-names : the name of clock used by the bus, "bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- #clock-cells: should be 1.

This is a clock consumer, right? So the clock-cells is not valid here.

> +- operating-points-v2: the OPP table including frequency/voltage information
> +  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +- vdd-supply: the regulator to provide the buses with the voltage.
> +- devfreq-events: the devfreq-event device to monitor the curret utilization

s/curret/current/

> +  of buses.
> +
> +Optional properties for bus device:
> +- exynos,saturation-ratio: the percentage value which is used to calibrate
> +   the performance count againt total cycle count.

s/againt/against/

> +
> +Example1:
> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
> +
> + - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq   | Voltage |
> + ---
> + |L1| 5  |80   |
> + |L2| 10 |80   |
> + |L3| 134000 |80   |
> + |L4| 20 |80   |
> + |L5| 40 |875000   |
> + ---
> +
> +Example2 :
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> + are listed below:

s/are/is/ (one bus is listed)

> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {

Maybe use convention with frequency, like:
opp@5000
This also used in opp.txt examples.


> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <80>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
> +
> + Usage case to handle the frequency and voltage of bus on runtime
> + in exynos3250-rinato.dts are listed below:

s/are/is/

> +
> + _dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;  /* VDD_MIF */
> + status = "okay";
> + };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.

s/noes/nodes/

> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 72 
> +++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index b77dac61ffb5..3bcf0939755e 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -282,6 +282,78 @@
>   clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
>   #iommu-cells = <0>;
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <95>;

The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?

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 v2 03/22] drm/exynos: gsc: add device tree support and remove usage of static mappings

[Krzysztof Kozlowski]

On 10.12.2015 15:48, Inki Dae wrote:
> CCing Mr. Kukjin and Krzysztof
> 
> 
> Hi Kukjin and Krzysztof,
> 
> Below patch includes dt binding about gsc device but it'd be nice this patch 
> to exynos drm tree with others.
> So could you give me Acked-by so that I can merge it to exynos drm tree?
> 
> Thanks,
> Inki Dae
> 
> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
>> From: Seung-Woo Kim <sw0312@samsung.com>
>>
>> This patch adds device tree support for exynos_drm_gsc. This patch
>> also fixed build issue on non-Exynos platforms, thus dependency on
>> !ARCH_MULTIPLATFORM can be now removed. The driver cannot be used
>> simultaneously with V4L2 Mem2Mem GScaller driver thought.
>>
>> Signed-off-by: Seung-Woo Kim <sw0312@samsung.com>
>> [updated commit message, removed the need for wb-lcd property, because
>> all gscallers have support for lcd writeback, replaced dependency on
>> !ARCH_MULTIPLATFORM with !VIDEO_SAMSUNG_EXYNOS_GSC]
>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>> ---
>>  .../devicetree/bindings/media/exynos5-gsc.txt  |  4 +++
>>  drivers/gpu/drm/exynos/Kconfig |  2 +-
>>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 30 
>> +++---
>>  drivers/gpu/drm/exynos/regs-gsc.h  |  4 +--
>>  4 files changed, 33 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
>> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> index 0604d42f38d1..5fe9372abb37 100644
>> --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> @@ -7,6 +7,10 @@ Required properties:
>>  - reg: should contain G-Scaler physical address location and length.
>>  - interrupts: should contain G-Scaler interrupt number
>>  
>> +Optional properties:
>> +- samsung,sysreg: handle to syscon used to control the system registers to
>> +  set writeback input and destination
>> +
>>  Example:
>>  
>>  gsc_0:  gsc@0x13e0 {


Acked-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
> exynos4412-odroidu3 board. Each PPMU dt node includes one event of
> 'PPMU Count3'.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40 
> +
>  1 file changed, 40 insertions(+)
> 

The patch itself is good but now I see that it is duplicated with
Rinato, Monk and Trats2. Probably for all other Exynos4 and
one-cluster-Exynos5 boards this would be exactly the same as well.

How about making a DTSI file with common PPMU events configuration?

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 v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 16:07, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:43, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>>>> On 10.12.2015 15:08, Chanwoo Choi wrote:
>>>>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>>>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>>>>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>>>>>> Exynos4x12 has the following AXI buses to translate data between
>>>>>>> DRAM and sub-blocks.
>>>>>>>
>>>>>>> Following list specifies the detailed relation between DRAM and 
>>>>>>> sub-blocks:
>>>>>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>>>>>> - ACLK160 clock for CAM/TV/LCD
>>>>>>> : The minimum clock of ACLK160 should be over 160MHz.
>>>>>>>   When drop the clock under 160MHz, show the broken image.
>>>>>>> - ACLK133 clock for FSYS
>>>>>>> - GDL clock for LEFTBUS
>>>>>>> - GDR clock for RIGHTBUS
>>>>>>> - SCLK_MFC clock for MFC
>>>>>>>
>>>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>>>>>>> ++
>>>>>>>  1 file changed, 112 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>>>>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>>>>>> index 3bcf0939755e..8bc4aee156b5 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>>>>>> @@ -354,6 +354,118 @@
>>>>>>> opp-microvolt = <95>;
>>>>>>> };
>>>>>>> };
>>>>>>> +
>>>>>>> +   bus_leftbus: bus_leftbus {
>>>>>>> +   compatible = "samsung,exynos-bus";
>>>>>>> +   clocks = < CLK_DIV_GDL>;
>>>>>>> +   clock-names = "bus";
>>>>>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>>>>>> +   status = "disabled";
>>>>>>> +   };
>>>>>>> +
>>>>>>> +   bus_rightbus: bus_rightbus {
>>>>>>> +   compatible = "samsung,exynos-bus";
>>>>>>> +   clocks = < CLK_DIV_GDR>;
>>>>>>> +   clock-names = "bus";
>>>>>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>>>>>> +   status = "disabled";
>>>>>>> +   };
>>>>>>
>>>>>> These two nodes are symmetrical. The MFC below and other buses in other
>>>>>> DTS share opps. How about changing the binding so multiple clocks could
>>>>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>>>>> bus device for each clock.
>>>>>
>>>>> The your commented method is possible.
>>>>>
>>>>> But, I focus on implementing the generic bus frequency driver.
>>>>>
>>>>> If specific bus device-tree node includes the one more clocks,
>>>>> when adding the new Exynos SoC, the exynos-bus.c should be added
>>>>> for new Exynos SoC. Because, each Exynos SoC has the different
>>>>> set of bus device.
>>>>>
>>>>> If we use my approach, we don't need to modify the exynos-bus.c
>>>>> driver to support for the bus frequency of new Exynos SoC.
>>>>
>>>> This won't change. The driver will just support from 1 to N clocks for
>>>> given bus device and set the same OPP to all of them. This will only
>>>> limit the number of duplicated entries. This won't affect the generic
>>>> approach of driver itself.
>>>
>>> You're right aspect of only implementation of device driver.
>>>
>>> But,
>>> If we use your commented approach, we can show the information
>>> of only parent de

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>>   When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>> ---
>>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>>> ++
>>>  1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> +   bus_leftbus: bus_leftbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDL>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_rightbus: bus_rightbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDR>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
> 
> The your commented method is possible.
> 
> But, I focus on implementing the generic bus frequency driver.
> 
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
> 
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.

This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.

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 v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus device-tree node of INT (internal) block
> to enable the bus frequency. The following sub-blocks share

"to enable the bus frequency scaling"

> the VDD_INT power source:
> - LEFTBUS (parent device)
> - RIGHTBUS
> - PERIL
> - LCD0
> - FSYS
> - MCUISP / ISP
> - MFC
> 
> The LEFTBUS is parent device with devfreq ondemand governor
> and the rest devices has the dependency on LEFTBUS bus.

How about:
"and the rest of devices depend on the LEFTBUS device."
?

The patch is good:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
> 
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
> +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 47 
> +
>  2 files changed, 94 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 171dea1e3e4a..12d08242a179 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -544,3 +544,50 @@
>   };
>   };
>  };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 40a474c4374b..aecd545803ad 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1286,3 +1286,50 @@
>   vtmu-supply = <_reg>;
>   status = "okay";
>  };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};

The nodes in both files are mostly sorted alphabetically. Could you
place them in such order as well?

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 v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
>   When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
> ++
>  1 file changed, 112 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
>   opp-microvolt = <95>;
>   };
>   };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };

These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.

Best regards,
Krzysztof

> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <_display_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK133>;
> + clock-names = "bus";
> + operating-points-v2 = <_fsys_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peri: bus_peri {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK100>;
> + clock-names = "bus";
> + operating-points-v2 = <_peri_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_fsys_opp_table: opp_table5 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + };
> +
> + bus_peri_opp_table: opp_table6 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + 

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 15:43, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:08, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>>>> Exynos4x12 has the following AXI buses to translate data between
>>>>> DRAM and sub-blocks.
>>>>>
>>>>> Following list specifies the detailed relation between DRAM and 
>>>>> sub-blocks:
>>>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>>>> - ACLK160 clock for CAM/TV/LCD
>>>>> : The minimum clock of ACLK160 should be over 160MHz.
>>>>>   When drop the clock under 160MHz, show the broken image.
>>>>> - ACLK133 clock for FSYS
>>>>> - GDL clock for LEFTBUS
>>>>> - GDR clock for RIGHTBUS
>>>>> - SCLK_MFC clock for MFC
>>>>>
>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>>>>> ++
>>>>>  1 file changed, 112 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>>>> index 3bcf0939755e..8bc4aee156b5 100644
>>>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>>>> @@ -354,6 +354,118 @@
>>>>>   opp-microvolt = <95>;
>>>>>   };
>>>>>   };
>>>>> +
>>>>> + bus_leftbus: bus_leftbus {
>>>>> + compatible = "samsung,exynos-bus";
>>>>> + clocks = < CLK_DIV_GDL>;
>>>>> + clock-names = "bus";
>>>>> + operating-points-v2 = <_leftbus_opp_table>;
>>>>> + status = "disabled";
>>>>> + };
>>>>> +
>>>>> + bus_rightbus: bus_rightbus {
>>>>> + compatible = "samsung,exynos-bus";
>>>>> + clocks = < CLK_DIV_GDR>;
>>>>> + clock-names = "bus";
>>>>> + operating-points-v2 = <_leftbus_opp_table>;
>>>>> + status = "disabled";
>>>>> + };
>>>>
>>>> These two nodes are symmetrical. The MFC below and other buses in other
>>>> DTS share opps. How about changing the binding so multiple clocks could
>>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>>> bus device for each clock.
>>>
>>> The your commented method is possible.
>>>
>>> But, I focus on implementing the generic bus frequency driver.
>>>
>>> If specific bus device-tree node includes the one more clocks,
>>> when adding the new Exynos SoC, the exynos-bus.c should be added
>>> for new Exynos SoC. Because, each Exynos SoC has the different
>>> set of bus device.
>>>
>>> If we use my approach, we don't need to modify the exynos-bus.c
>>> driver to support for the bus frequency of new Exynos SoC.
>>
>> This won't change. The driver will just support from 1 to N clocks for
>> given bus device and set the same OPP to all of them. This will only
>> limit the number of duplicated entries. This won't affect the generic
>> approach of driver itself.
> 
> You're right aspect of only implementation of device driver.
> 
> But,
> If we use your commented approach, we can show the information
> of only parent device through sysfs. We cannot see the information
> of passive device. The some information includes the current
> frequency and correlation of parent device. (But, current patchset
> don' include the topology information between parent device and
> passive device. I'll do it on later patches).
> 
> For example, 
> We can see the following bus device through /sys/class/devfreq.
> 
> drwxr-xr-x  2 root root 0 Dec 31 17:00 .
> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_display -> 
> ../../devices/platform/bus_display/devfreq/bus_display
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_fsys -> 
> ../../devices/platform/bus_fsys/devfreq/bus_fsys
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_leftbus -> 
> ../../devices/platform/b

Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch expands the voltage range of buck1/3 regulator due to as following:
> - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V.
> - INT (Internal) bus frequency needs 9uV ~ 100uV.

9->90 and duplicated "uV V". Maybe just:
900 - 1050 mV
900 - 1000 mV
?

> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

For the contents of patch:

Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

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 v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Krzysztof Kozlowski]

On 09.12.2015 22:58, Marek Szyprowski wrote:
> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
> Odroid boards.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index edf0fc8..5825abf 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -18,6 +18,24 @@
>   stdout-path = _1;
>   };
>  
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mfc_left: region@7700 {
> + compatible = "shared-dma-pool";
> + reusable;
> + reg = <0x7700 0x100>;

Doesn't this exceed the memory of Odroid X?

For other Exynos4412 boards the length is 0x80. I am curious: any
particular reason for the difference?

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 v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Krzysztof Kozlowski]

On 10.12.2015 16:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 22:58, Marek Szyprowski wrote:
>> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based

... and one more finding: I think the abbreviation is Multi Format Codec.

BR,
Krzysztof

>> Odroid boards.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
>> 
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index edf0fc8..5825abf 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -18,6 +18,24 @@
>>  stdout-path = _1;
>>  };
>>  
>> +reserved-memory {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +mfc_left: region@7700 {
>> +compatible = "shared-dma-pool";
>> +reusable;
>> +reg = <0x7700 0x100>;
> 
> Doesn't this exceed the memory of Odroid X?
> 
> For other Exynos4412 boards the length is 0x80. I am curious: any
> particular reason for the difference?
> 
> 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 v4 7/8] ARM: dts: Exynos5422: fix OPP tables

[Krzysztof Kozlowski]

On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> From: Ben Gamari 
> 
> The Exynos 5422 is identical to the 5800 except for the fact that it
> boots from the A7 cores. Consequently, the core numbering is different:
> cores 0-3 are A7s whereas 4-7 are A15s.
> 
> We can reuse the device tree of the 5800 for the 5422 but we must take
> care to override the OPP tables and CPU clocks.  These are otherwise
> inherited from the exynos5800 devicetree, which has the CPU clusters
> reversed compared to the 5422. This results in the A15 cores only
> reaching 1.4GHz, the maximum rate of the KFC clock.
> 
> Cc: Javier Martinez Canillas 
> Signed-off-by: Ben Gamari 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 

This looks like a very-non-atomic way of handling a change. You added
opp tables to exynos5420 before so at that time they will be applied to
Odroid XU3 family which uses different CPU order. After that you are
fixing the tables to proper CPU order. Direct bisectability probably
won't be an issue because all of DTS would go to separate branch... but
the logic behind confuses.

I think this should be squashed into 3/8.

Best regards,
Krzysztof

> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi 
> b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> index b7f60c8..9a5131d 100644
> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> @@ -20,8 +20,10 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a7";
>   reg = <0x100>;
> + clocks = < CLK_KFC_CLK>;
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -30,6 +32,7 @@
>   reg = <0x101>;
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -38,6 +41,7 @@
>   reg = <0x102>;
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -46,14 +50,17 @@
>   reg = <0x103>;
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
>   device_type = "cpu";
>   compatible = "arm,cortex-a15";
>   reg = <0x0>;
> + clocks = < CLK_ARM_CLK>;
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -62,6 +69,7 @@
>   reg = <0x1>;
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -70,6 +78,7 @@
>   reg = <0x2>;
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> @@ -78,4 +87,5 @@
>   reg = <0x3>;
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
> + operating-points-v2 = <_opp_table>;
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 6/8] ARM: dts: Exynos5800: fix CPU OPP

[Krzysztof Kozlowski]

On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> Fix CPU operating points for Exynos5800 (it use different
> voltages than Exynos5420 and supports additional frequencies).
> However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and
> 1400MHz OPP (for A7 cores) for now as they are not available
> on all boards.
> 
> Based on Hardkernel's kernel for ODROID-XU3 board.
> 
> Changes by Ben Gamari:
> - Port to operating-points-v2
> 
> Cc: Kukjin Kim 
> Cc: Doug Anderson 
> Cc: Javier Martinez Canillas 
> Cc: Andreas Faerber 
> Cc: Sachin Kamat 
> Cc: Thomas Abraham 
> Signed-off-by: Ben Gamari 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos5800.dtsi | 165 
> ++
>  1 file changed, 165 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5800.dtsi 
> b/arch/arm/boot/dts/exynos5800.dtsi
> index c0bb356..e417218 100644
> --- a/arch/arm/boot/dts/exynos5800.dtsi
> +++ b/arch/arm/boot/dts/exynos5800.dtsi
> @@ -17,8 +17,173 @@
>  
>  / {
>   compatible = "samsung,exynos5800", "samsung,exynos5";
> +
> + cpu0_opp_table: opp_table0 {

This includes exynos5420.dtsi, so override by label instead of
duplicating full path.

In the same time you don't have to duplicate all data - just override
what you want:
_opp_table {
opp00@18 {
opp-microvolt = <125>;
};
};

That should be sufficient I think.

> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@18 {
> + opp-hz = /bits/ 64 <18>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp01@17 {
> + opp-hz = /bits/ 64 <17>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp02@16 {
> + opp-hz = /bits/ 64 <16>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp03@15 {
> + opp-hz = /bits/ 64 <15>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp04@14 {
> + opp-hz = /bits/ 64 <14>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp05@13 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp06@12 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp07@11 {
> + opp-hz = /bits/ 64 <11>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp08@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp09@9 {
> + opp-hz = /bits/ 64 <9>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp10@8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp11@7 {
> + opp-hz = /bits/ 64 <7>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp12@6 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp13@5 {
> + opp-hz = /bits/ 64 <5>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp14@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp15@3 {
> + 

Re: [PATCH v4 7/8] ARM: dts: Exynos5422: fix OPP tables

[Krzysztof Kozlowski]

On 08.12.2015 22:41, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 12/08/2015 05:13 AM, Krzysztof Kozlowski wrote:
>> On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
>>> From: Ben Gamari <b...@smart-cactus.org>
>>>
>>> The Exynos 5422 is identical to the 5800 except for the fact that it
>>> boots from the A7 cores. Consequently, the core numbering is different:
>>> cores 0-3 are A7s whereas 4-7 are A15s.
>>>
>>> We can reuse the device tree of the 5800 for the 5422 but we must take
>>> care to override the OPP tables and CPU clocks.  These are otherwise
>>> inherited from the exynos5800 devicetree, which has the CPU clusters
>>> reversed compared to the 5422. This results in the A15 cores only
>>> reaching 1.4GHz, the maximum rate of the KFC clock.
>>>
>>> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
>>> Signed-off-by: Ben Gamari <b...@smart-cactus.org>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
>>> ---
>>>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>
>> This looks like a very-non-atomic way of handling a change. You added
>> opp tables to exynos5420 before so at that time they will be applied to
>> Odroid XU3 family which uses different CPU order. After that you are
>> fixing the tables to proper CPU order. Direct bisectability probably
>> won't be an issue because all of DTS would go to separate branch... but
>> the logic behind confuses.
>>
> 
> Agreed.
> 
>> I think this should be squashed into 3/8.
>>
> 
> I think the patch should be split in two changes, the CPUs device nodes
> having the wrong clock for clusters is a bug and has to be fixed in a
> patch before adding the OPP tables and the OPP tables changes should be
> separated and merged with patch 3/8 as you suggest.

I don't get the point about wrong clock (bug). Where is the bug? Beside
of course what was introduced in 3/8 and it is not valid for reversed
cluster order.

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