Re: [PATCH v3 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish

2014-10-21 Thread Krzysztof Kozłowski
On 20.10.2014 23:05, Javier Martinez Canillas wrote:
 Hello,
 
 This series add support for Exynos platforms to prepare regulators for
 system suspend. The regulator core has a set of helpers functions to be
 used when the system is entering and leaving from a suspend state but
 currently there is only one user in mainline.
 
 This user is drivers/mfd/sec-core.c but it calls regulator_suspend_prepare()
 from within the driver power-management suspend function. This does not
 seems to be correct since the regulator suspend prepare function affects all
 regulators in the system and not only the ones managed by this device.
 
 So patch #1 in this series revert the commit that introduced that change and
 patch #2 calls the regulator framework suspend/finish functions from the
 Exynos platform power-management code. The first patch should be queued 
 through
 the mfd tree and the second through the linux-samsung tree.
 
 Changes since v2:
  - Check for regulator_suspend_finish() return value for an error.
Suggested by Doug Anderson.
 
 Changes since v1:
  - Remove the call to regulator_suspend_prepare() from drivers/mfd/sec-core.c
as suggested by Doug Anderson.
  - Call regulator_suspend_prepare() before s3c_pm_check_prepare() as suggested
by Doug Anderson.
  - Added Lee Jones to cc list since there is a change for the mfd framework.
 
 Javier Martinez Canillas (2):
   Revert mfd: sec-core: Prepare regulators for suspend state to reduce
 power-consumption
   ARM: EXYNOS: Call regulator core suspend prepare and finish functions
 
  arch/arm/mach-exynos/suspend.c | 23 +++
  drivers/mfd/Kconfig|  1 -
  drivers/mfd/sec-core.c | 10 --
  3 files changed, 23 insertions(+), 11 deletions(-)

Patchset tested on Trats2 board (Exynos4412 with max77686 PMIC, modified
DTS to disable buck[134] during suspend to RAM).

Tested-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] mmc: dw_mmc: exynos: Add support for exynos7

2014-10-21 Thread Vivek Gautam
On Mon, Sep 1, 2014 at 11:14 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Jaehoon,

 +Prabu Thangamuthu

 On Fri, Aug 29, 2014 at 4:14 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi, Abhilash.

 On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
 From: Abhilash Kesavan a.kesa...@samsung.com

 The Exynos7 has a DWMMC controller (v2.70a) which is different from
 prior versions. This patch adds new compatible strings for exynos7.
 This patch also fixes the CLKSEL register offset on exynos7.

 If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some 
 offset is changed for 64-bit address)
 But i didn't see any patches at mailing.
 Do you have the plan which send patch of dw-mmc.c?

 We are using a rebased version of
 http://www.spinics.net/lists/linux-mmc/msg21742.html to handle the
 dwmmc side changes. We should have mentioned this dependency as the
 patch is required for proper functioning of dwmmc on Exynos7.
 Stress tests are on-going with that patch and once it looks good, we
 will post our results so that the original patch may be taken forward.

 Regards,
 Abhilash

 Best Regards,
 Jaehoon Chung

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 ---

I have tested this patch following set of patches:

On Exynos7 support side:
1) dts, kbuild: Implement support for dtb vendor subdirs patchset
http://comments.gmane.org/gmane.linux.kbuild.devel/12131
2) arch: arm64: Enable support for Samsung Exynos7 SoC  (V5)
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
3) Serial clean-up patches for Exynos7
http://www.spinics.net/lists/arm-kernel/msg367348.html
http://www.spinics.net/lists/arm-kernel/msg367349.html
4) Add initial support for pinctrl on Exynos7  (V5)
http://www.spinics.net/lists/linux-samsung-soc/msg37708.html

On MMC side:
1) mmc: dw_mmc: Add IDMAC 64-bit address mode support  (V7)
https://lkml.org/lkml/2014/10/20/58
2) mmc: dw_mmc: Reset DMA before enabling IDMAC  (V2)
http://www.gossamer-threads.com/lists/linux/kernel/2028229

eMMC and SD are running fine on Exynos7.

If this change looks good, then we can take it in.

  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
  drivers/mmc/host/dw_mmc-exynos.c   |   91 
 +---
  2 files changed, 82 insertions(+), 13 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 index 6cd3525..ee4fc05 100644
 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 @@ -18,6 +18,10 @@ Required Properties:
 specific extensions.
   - samsung,exynos5420-dw-mshc: for controllers with Samsung 
 Exynos5420
 specific extensions.
 + - samsung,exynos7-dw-mshc: for controllers with Samsung Exynos7
 +   specific extensions.
 + - samsung,exynos7-dw-mshc-smu: for controllers with Samsung Exynos7
 +   specific extensions having an SMU.

  * samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
 interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
 diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
 b/drivers/mmc/host/dw_mmc-exynos.c
 index 0fbc53a..509365c 100644
 --- a/drivers/mmc/host/dw_mmc-exynos.c
 +++ b/drivers/mmc/host/dw_mmc-exynos.c
 @@ -25,6 +25,7 @@
  #define NUM_PINS(x)  (x + 2)

  #define SDMMC_CLKSEL 0x09C
 +#define SDMMC_CLKSEL64   0x0A8
  #define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x)  7)  0)
  #define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x)  7)  16)
  #define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x)  7)  24)
 @@ -65,6 +66,8 @@ enum dw_mci_exynos_type {
   DW_MCI_TYPE_EXYNOS5250,
   DW_MCI_TYPE_EXYNOS5420,
   DW_MCI_TYPE_EXYNOS5420_SMU,
 + DW_MCI_TYPE_EXYNOS7,
 + DW_MCI_TYPE_EXYNOS7_SMU,
  };

  /* Exynos implementation specific driver private data */
 @@ -95,6 +98,12 @@ static struct dw_mci_exynos_compatible {
   }, {
   .compatible = samsung,exynos5420-dw-mshc-smu,
   .ctrl_type  = DW_MCI_TYPE_EXYNOS5420_SMU,
 + }, {
 + .compatible = samsung,exynos7-dw-mshc,
 + .ctrl_type  = DW_MCI_TYPE_EXYNOS7,
 + }, {
 + .compatible = samsung,exynos7-dw-mshc-smu,
 + .ctrl_type  = DW_MCI_TYPE_EXYNOS7_SMU,
   },
  };

 @@ -102,7 +111,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv = host-priv;

 - if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU) {
 + if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU ||
 + priv-ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU) {
   mci_writel(host, MPSBEGIN0, 0);
   mci_writel(host, MPSEND0, DWMCI_BLOCK_NUM);
   mci_writel(host, MPSCTRL0, DWMCI_MPSCTRL_SECURE_WRITE_BIT |
 @@ -153,11 +163,22 @@ 

Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7

2014-10-21 Thread Vivek Gautam
On Tue, Oct 21, 2014 at 1:47 PM, Vivek Gautam gautam.vi...@samsung.com wrote:

Corrected Tomasz's mail id, as the earlier samsung one is not valid now.
Also giving a Tested-by

 On Mon, Sep 1, 2014 at 11:14 AM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Jaehoon,

 +Prabu Thangamuthu

 On Fri, Aug 29, 2014 at 4:14 PM, Jaehoon Chung jh80.ch...@samsung.com 
 wrote:
 Hi, Abhilash.

 On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
 From: Abhilash Kesavan a.kesa...@samsung.com

 The Exynos7 has a DWMMC controller (v2.70a) which is different from
 prior versions. This patch adds new compatible strings for exynos7.
 This patch also fixes the CLKSEL register offset on exynos7.

 If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some 
 offset is changed for 64-bit address)
 But i didn't see any patches at mailing.
 Do you have the plan which send patch of dw-mmc.c?

 We are using a rebased version of
 http://www.spinics.net/lists/linux-mmc/msg21742.html to handle the
 dwmmc side changes. We should have mentioned this dependency as the
 patch is required for proper functioning of dwmmc on Exynos7.
 Stress tests are on-going with that patch and once it looks good, we
 will post our results so that the original patch may be taken forward.

 Regards,
 Abhilash

 Best Regards,
 Jaehoon Chung

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 ---

 I have tested this patch following set of patches:

 On Exynos7 support side:
 1) dts, kbuild: Implement support for dtb vendor subdirs patchset
 http://comments.gmane.org/gmane.linux.kbuild.devel/12131
 2) arch: arm64: Enable support for Samsung Exynos7 SoC  (V5)
 http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
 3) Serial clean-up patches for Exynos7
 http://www.spinics.net/lists/arm-kernel/msg367348.html
 http://www.spinics.net/lists/arm-kernel/msg367349.html
 4) Add initial support for pinctrl on Exynos7  (V5)
 http://www.spinics.net/lists/linux-samsung-soc/msg37708.html

 On MMC side:
 1) mmc: dw_mmc: Add IDMAC 64-bit address mode support  (V7)
 https://lkml.org/lkml/2014/10/20/58
 2) mmc: dw_mmc: Reset DMA before enabling IDMAC  (V2)
 http://www.gossamer-threads.com/lists/linux/kernel/2028229

 eMMC and SD are running fine on Exynos7.

Tested-by: Vivek Gautam gautam.vi...@samsung.com


 If this change looks good, then we can take it in.

  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
  drivers/mmc/host/dw_mmc-exynos.c   |   91 
 +---
  2 files changed, 82 insertions(+), 13 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 index 6cd3525..ee4fc05 100644
 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 @@ -18,6 +18,10 @@ Required Properties:
 specific extensions.
   - samsung,exynos5420-dw-mshc: for controllers with Samsung 
 Exynos5420
 specific extensions.
 + - samsung,exynos7-dw-mshc: for controllers with Samsung Exynos7
 +   specific extensions.
 + - samsung,exynos7-dw-mshc-smu: for controllers with Samsung Exynos7
 +   specific extensions having an SMU.

  * samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
 interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
 diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
 b/drivers/mmc/host/dw_mmc-exynos.c
 index 0fbc53a..509365c 100644
 --- a/drivers/mmc/host/dw_mmc-exynos.c
 +++ b/drivers/mmc/host/dw_mmc-exynos.c
 @@ -25,6 +25,7 @@
  #define NUM_PINS(x)  (x + 2)

  #define SDMMC_CLKSEL 0x09C
 +#define SDMMC_CLKSEL64   0x0A8
  #define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x)  7)  0)
  #define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x)  7)  16)
  #define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x)  7)  24)
 @@ -65,6 +66,8 @@ enum dw_mci_exynos_type {
   DW_MCI_TYPE_EXYNOS5250,
   DW_MCI_TYPE_EXYNOS5420,
   DW_MCI_TYPE_EXYNOS5420_SMU,
 + DW_MCI_TYPE_EXYNOS7,
 + DW_MCI_TYPE_EXYNOS7_SMU,
  };

  /* Exynos implementation specific driver private data */
 @@ -95,6 +98,12 @@ static struct dw_mci_exynos_compatible {
   }, {
   .compatible = samsung,exynos5420-dw-mshc-smu,
   .ctrl_type  = DW_MCI_TYPE_EXYNOS5420_SMU,
 + }, {
 + .compatible = samsung,exynos7-dw-mshc,
 + .ctrl_type  = DW_MCI_TYPE_EXYNOS7,
 + }, {
 + .compatible = samsung,exynos7-dw-mshc-smu,
 + .ctrl_type  = DW_MCI_TYPE_EXYNOS7_SMU,
   },
  };

 @@ -102,7 +111,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv = host-priv;

 - if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU) {
 + if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU ||
 +

Re: [PATCH v3] ARM: dts: exynos3250: add JPEG codec device node

2014-10-21 Thread Pankaj Dubey
Hi Jacek Anaszewski,

On Tue, Sep 9, 2014 at 6:39 PM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/boot/dts/exynos3250.dtsi |   13 +
  1 file changed, 13 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 1d52de6..bbc1e4c 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -216,6 +216,19 @@
 interrupts = 0 240 0;
 };

 +   jpeg-codec@1183 {
 +   compatible = samsung,exynos3250-jpeg;
 +   reg = 0x1183 0x1000;
 +   interrupts = 0 171 0;
 +   clocks = cmu CLK_JPEG, cmu CLK_SCLK_JPEG;
 +   clock-names = jpeg, sclk;
 +   samsung,power-domain = pd_cam;
 +   assigned-clocks = cmu CLK_MOUT_CAM_BLK, cmu 
 CLK_SCLK_JPEG;
 +   assigned-clock-rates = 0, 15000;
 +   assigned-clock-parents = cmu CLK_DIV_MPLL_PRE;
 +   status = disabled;
 +   };
 +
 mshc_0: mshc@1251 {
 compatible = samsung,exynos5250-dw-mshc;
 reg = 0x1251 0x1000;
 --
 1.7.9.5


I tested this patch on Exynos3250 based Espresso board, hence please
feel free to add.

Tested-by: Pankaj Dubey pankaj.du...@samsung.com

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


[PATCH 0/2] regulator: max77686/trats2: Disable some regulators in suspend

2014-10-21 Thread Krzysztof Kozlowski
Hi,

This patchset makes use of Javier Martinez Cainllas changes [1].
It allows disabling some of the regulators during suspend to RAM.

Javier's patchset is necessary only to test it.

[1] [PATCH v3 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish
https://lkml.org/lkml/2014/10/20/545

Best regards,
Krzysztof

Krzysztof Kozlowski (2):
  regulator: max77686: Implement suspend disable for some LDOs
  ARM: dts: exynos4412-trats: Add suspend configuration for max77686
regulators

 arch/arm/boot/dts/exynos4412-trats2.dts | 135 +---
 drivers/regulator/max77686.c|  19 +
 2 files changed, 124 insertions(+), 30 deletions(-)

-- 
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 1/2] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Krzysztof Kozlowski
Some LDOs of Maxim 77686 PMIC support disabling during system suspend
(LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
of set_suspend_mode function. In that case the mode was one of:
 - disable,
 - normal mode,
 - low power mode.
However there are no bindings for setting the mode during suspend.

Implement a set_suspend_disable function for regulators supporting this.
This helps reducing energy consumption during system sleep.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/regulator/max77686.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index ef1af2debbd2..84603051f24d 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -123,6 +123,24 @@ static int max77686_set_suspend_mode(struct regulator_dev 
*rdev,
return 0;
 }
 
+static int max77686_ldo_set_suspend_disable(struct regulator_dev *rdev,
+unsigned int mode)
+{
+   unsigned int val;
+   struct max77686_data *max77686 = rdev_get_drvdata(rdev);
+   int ret;
+
+   val = 0x1  MAX77686_OPMODE_SHIFT;
+
+   ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask, val);
+   if (ret)
+   return ret;
+
+   max77686-opmode[rdev_get_id(rdev)] = val;
+   return 0;
+}
+
 /* Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state */
 static int max77686_ldo_set_suspend_mode(struct regulator_dev *rdev,
 unsigned int mode)
@@ -212,6 +230,7 @@ static struct regulator_ops max77686_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
.set_suspend_mode   = max77686_ldo_set_suspend_mode,
+   .set_suspend_disable= max77686_ldo_set_suspend_disable,
 };
 
 static struct regulator_ops max77686_buck1_ops = {
-- 
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: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Krzysztof Kozlowski
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.

Additionally remove old and not supported bindings:
 - regulator-mem-off
 - regulator-mem-idle
 - regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 135 +---
 1 file changed, 105 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index dd9ac66770f7..c2fbee36021a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -225,7 +225,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo2_reg: ldo2 {
@@ -234,7 +236,9 @@
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo3_reg: ldo3 {
@@ -243,7 +247,9 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo4_reg: ldo4 {
@@ -252,7 +258,9 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo5_reg: ldo5 {
@@ -261,7 +269,9 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo6_reg: ldo6 {
@@ -270,7 +280,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo7_reg: ldo7 {
@@ -279,7 +291,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo8_reg: ldo8 {
@@ -287,7 +301,9 @@
regulator-name = VMIPI_1.0V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
-   regulator-mem-off;
+   

Re: [PATCH 2/2] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 10:25 AM, Krzysztof Kozlowski wrote:
 Add suspend to RAM configuration for max77686 regulators. Some LDOs and
 bucks are disabled. This reduces energy consumption during S2R,
 approximately from 17 mA to 9 mA.
 
 Additionally remove old and not supported bindings:
  - regulator-mem-off
  - regulator-mem-idle
  - regulator-mem-on
 The max77686 driver does not parse them and they are not documented
 anywere.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts | 135 
 +---
  1 file changed, 105 insertions(+), 30 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
 b/arch/arm/boot/dts/exynos4412-trats2.dts
 index dd9ac66770f7..c2fbee36021a 100644
 --- a/arch/arm/boot/dts/exynos4412-trats2.dts
 +++ b/arch/arm/boot/dts/exynos4412-trats2.dts

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Best regards,
Javier

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


Re: [PATCH 2/2] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Chanwoo Choi
Hi Krzysztof,

I think that the state of some regulators should be changed in suspend state.

On 10/21/2014 05:25 PM, Krzysztof Kozlowski wrote:
 Add suspend to RAM configuration for max77686 regulators. Some LDOs and
 bucks are disabled. This reduces energy consumption during S2R,
 approximately from 17 mA to 9 mA.
 
 Additionally remove old and not supported bindings:
  - regulator-mem-off
  - regulator-mem-idle
  - regulator-mem-on
 The max77686 driver does not parse them and they are not documented
 anywere.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts | 135 
 +---
  1 file changed, 105 insertions(+), 30 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
 b/arch/arm/boot/dts/exynos4412-trats2.dts
 index dd9ac66770f7..c2fbee36021a 100644
 --- a/arch/arm/boot/dts/exynos4412-trats2.dts
 +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
 @@ -225,7 +225,9 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo2_reg: ldo2 {
 @@ -234,7 +236,9 @@
   regulator-min-microvolt = 120;
   regulator-max-microvolt = 120;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo3_reg: ldo3 {
 @@ -243,7 +247,9 @@
   regulator-min-microvolt = 180;
   regulator-max-microvolt = 180;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo4_reg: ldo4 {
 @@ -252,7 +258,9 @@
   regulator-min-microvolt = 280;
   regulator-max-microvolt = 280;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo5_reg: ldo5 {
 @@ -261,7 +269,9 @@
   regulator-min-microvolt = 180;
   regulator-max-microvolt = 180;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo6_reg: ldo6 {
 @@ -270,7 +280,9 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo7_reg: ldo7 {
 @@ -279,7 +291,9 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo8_reg: ldo8 {
 @@ -287,7 +301,9 @@
   regulator-name = VMIPI_1.0V;
   regulator-min-microvolt = 100;
   

Re: [PATCH 1/2] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 10:25 AM, Krzysztof Kozlowski wrote:
 Some LDOs of Maxim 77686 PMIC support disabling during system suspend
 (LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part

You should also document what each regulator support in the max77686 DT binding
doc, which btw I see is in Documentation/devicetree/bindings/mfd/max77686.txt
while I think it should be in Documentation/devicetree/bindings/regulators/

I just posted a patch to add this information to the max77802 DT binding doc [0]
so maybe you can add something along those lines?

 of set_suspend_mode function. In that case the mode was one of:
  - disable,
  - normal mode,
  - low power mode.
 However there are no bindings for setting the mode during suspend.
 
 Implement a set_suspend_disable function for regulators supporting this.
 This helps reducing energy consumption during system sleep.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/regulator/max77686.c | 19 +++
  1 file changed, 19 insertions(+)
 
 diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
 index ef1af2debbd2..84603051f24d 100644
 --- a/drivers/regulator/max77686.c
 +++ b/drivers/regulator/max77686.c
 @@ -123,6 +123,24 @@ static int max77686_set_suspend_mode(struct 
 regulator_dev *rdev,
   return 0;
  }
  
 +static int max77686_ldo_set_suspend_disable(struct regulator_dev *rdev,
 +  unsigned int mode)
 +{
 + unsigned int val;
 + struct max77686_data *max77686 = rdev_get_drvdata(rdev);
 + int ret;
 +
 + val = 0x1  MAX77686_OPMODE_SHIFT;

Maybe instead of using magic numbers you can document what 0x1 means here.
I don't have access to the max77686 data-sheet but I do have for the max77802
so my educated guess is that 0x1 means Output ON/OFF Controlled by PWRREQ
and that the Exynos 4412 XPWRRGTON pin is connected to the max77686 PWRREQ in
the Trats2 board.

 +
 + ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 +  rdev-desc-enable_mask, val);
 + if (ret)
 + return ret;
 +
 + max77686-opmode[rdev_get_id(rdev)] = val;
 + return 0;
 +}
 +

There is already a max77686_buck_set_suspend_disable() that is used by BUCK 1-4.

At least in the max77802, all regulators expect LDO 1, 3, 20 and 21 support OFF
by PWRREQ so with some refactoring (using a function to get the opmode shift)
you can use the same function for all regulators that support this instead of
having separate .set_suspend_disable function handlers.

  /* Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state */
  static int max77686_ldo_set_suspend_mode(struct regulator_dev *rdev,
unsigned int mode)
 @@ -212,6 +230,7 @@ static struct regulator_ops max77686_ldo_ops = {
   .set_voltage_sel= regulator_set_voltage_sel_regmap,
   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
   .set_suspend_mode   = max77686_ldo_set_suspend_mode,
 + .set_suspend_disable= max77686_ldo_set_suspend_disable,

You probably want add .set_suspend_enable as well.

  };
  
  static struct regulator_ops max77686_buck1_ops = {
 

In general, could you please take a look to the latest patches I posted for the
max77802? They are in a topic branch in Mark's regulator tree [1]. I would like
both 77686 and 77802 drivers to handle things similarly even though I know that
the PMICs don't behave identically and that's why we decided to have different
drivers (although maybe that was a mistake and makes more sense to merge them).

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2014/10/20/320
[1]: 
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=topic/max77802

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


Re: [PATCH 2/2] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Krzysztof Kozlowski
On wto, 2014-10-21 at 17:56 +0900, Chanwoo Choi wrote:
 Hi Krzysztof,
 
 I think that the state of some regulators should be changed in suspend state.
 
 On 10/21/2014 05:25 PM, Krzysztof Kozlowski wrote:
  Add suspend to RAM configuration for max77686 regulators. Some LDOs and
  bucks are disabled. This reduces energy consumption during S2R,
  approximately from 17 mA to 9 mA.
  
  Additionally remove old and not supported bindings:
   - regulator-mem-off
   - regulator-mem-idle
   - regulator-mem-on
  The max77686 driver does not parse them and they are not documented
  anywere.
  
  Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
  ---
   arch/arm/boot/dts/exynos4412-trats2.dts | 135 
  +---
   1 file changed, 105 insertions(+), 30 deletions(-)
  
  diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
  b/arch/arm/boot/dts/exynos4412-trats2.dts
  index dd9ac66770f7..c2fbee36021a 100644
  --- a/arch/arm/boot/dts/exynos4412-trats2.dts
  +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
  @@ -225,7 +225,9 @@
  regulator-min-microvolt = 100;
  regulator-max-microvolt = 100;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo2_reg: ldo2 {
  @@ -234,7 +236,9 @@
  regulator-min-microvolt = 120;
  regulator-max-microvolt = 120;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo3_reg: ldo3 {
  @@ -243,7 +247,9 @@
  regulator-min-microvolt = 180;
  regulator-max-microvolt = 180;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo4_reg: ldo4 {
  @@ -252,7 +258,9 @@
  regulator-min-microvolt = 280;
  regulator-max-microvolt = 280;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo5_reg: ldo5 {
  @@ -261,7 +269,9 @@
  regulator-min-microvolt = 180;
  regulator-max-microvolt = 180;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo6_reg: ldo6 {
  @@ -270,7 +280,9 @@
  regulator-min-microvolt = 100;
  regulator-max-microvolt = 100;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo7_reg: ldo7 {
  @@ -279,7 +291,9 @@
  regulator-min-microvolt = 100;
  regulator-max-microvolt = 100;
  regulator-always-on;
  -   regulator-mem-on;
  +   regulator-state-mem {
  +   regulator-on-in-suspend;
  +   };
  };
   
  ldo8_reg: ldo8 {
  @@ -287,7 +301,9 @@
  regulator-name = VMIPI_1.0V;
  regulator-min-microvolt = 100;
  

Re: [PATCH 1/2] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Krzysztof Kozlowski
On wto, 2014-10-21 at 11:10 +0200, Javier Martinez Canillas wrote:
 Hello Krzysztof,
 
 On 10/21/2014 10:25 AM, Krzysztof Kozlowski wrote:
  Some LDOs of Maxim 77686 PMIC support disabling during system suspend
  (LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
 
 You should also document what each regulator support in the max77686 DT 
 binding
 doc, which btw I see is in Documentation/devicetree/bindings/mfd/max77686.txt
 while I think it should be in Documentation/devicetree/bindings/regulators/
 I just posted a patch to add this information to the max77802 DT binding doc 
 [0]
 so maybe you can add something along those lines?

Sure, I'll document this.

  of set_suspend_mode function. In that case the mode was one of:
   - disable,
   - normal mode,
   - low power mode.
  However there are no bindings for setting the mode during suspend.
  
  Implement a set_suspend_disable function for regulators supporting this.
  This helps reducing energy consumption during system sleep.
  
  Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
  ---
   drivers/regulator/max77686.c | 19 +++
   1 file changed, 19 insertions(+)
  
  diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
  index ef1af2debbd2..84603051f24d 100644
  --- a/drivers/regulator/max77686.c
  +++ b/drivers/regulator/max77686.c
  @@ -123,6 +123,24 @@ static int max77686_set_suspend_mode(struct 
  regulator_dev *rdev,
  return 0;
   }
   
  +static int max77686_ldo_set_suspend_disable(struct regulator_dev *rdev,
  +unsigned int mode)
  +{
  +   unsigned int val;
  +   struct max77686_data *max77686 = rdev_get_drvdata(rdev);
  +   int ret;
  +
  +   val = 0x1  MAX77686_OPMODE_SHIFT;
 
 Maybe instead of using magic numbers you can document what 0x1 means here.
 I don't have access to the max77686 data-sheet but I do have for the max77802
 so my educated guess is that 0x1 means Output ON/OFF Controlled by PWRREQ
 and that the Exynos 4412 XPWRRGTON pin is connected to the max77686 PWRREQ in
 the Trats2 board.

OK.

 
  +
  +   ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
  +rdev-desc-enable_mask, val);
  +   if (ret)
  +   return ret;
  +
  +   max77686-opmode[rdev_get_id(rdev)] = val;
  +   return 0;
  +}
  +
 
 There is already a max77686_buck_set_suspend_disable() that is used by BUCK 
 1-4.
 
 At least in the max77802, all regulators expect LDO 1, 3, 20 and 21 support 
 OFF
 by PWRREQ so with some refactoring (using a function to get the opmode shift)
 you can use the same function for all regulators that support this instead of
 having separate .set_suspend_disable function handlers.

OK, I can merge this into one suspend_disable.

 
   /* Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state */
   static int max77686_ldo_set_suspend_mode(struct regulator_dev *rdev,
   unsigned int mode)
  @@ -212,6 +230,7 @@ static struct regulator_ops max77686_ldo_ops = {
  .set_voltage_sel= regulator_set_voltage_sel_regmap,
  .set_voltage_time_sel   = regulator_set_voltage_time_sel,
  .set_suspend_mode   = max77686_ldo_set_suspend_mode,
  +   .set_suspend_disable= max77686_ldo_set_suspend_disable,
 
 You probably want add .set_suspend_enable as well.

Yes, I'll add it.

 
   };
   
   static struct regulator_ops max77686_buck1_ops = {
  
 
 In general, could you please take a look to the latest patches I posted for 
 the
 max77802? They are in a topic branch in Mark's regulator tree [1]. I would 
 like
 both 77686 and 77802 drivers to handle things similarly even though I know 
 that
 the PMICs don't behave identically and that's why we decided to have different
 drivers (although maybe that was a mistake and makes more sense to merge 
 them).

I looked at them. In this patchset I didn't want to implement fully the
whole suspend-mode-thing. Just the first, easier part - set suspend
disable.

In general I would like to do it similar to your solution but that is
work for future. Especially as I would like to wait for merging your
Add max77802 regulator operating mode support.

Best regards,
Krzysztof

 
 Thanks a lot and best regards,
 Javier
 
 [0]: https://lkml.org/lkml/2014/10/20/320
 [1]: 
 https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=topic/max77802

--
To unsubscribe from this list: send the line unsubscribe linux-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] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 11:36 AM, Krzysztof Kozlowski wrote:
 On wto, 2014-10-21 at 11:10 +0200, Javier Martinez Canillas wrote:
 
 In general, could you please take a look to the latest patches I posted for 
 the
 max77802? They are in a topic branch in Mark's regulator tree [1]. I would 
 like
 both 77686 and 77802 drivers to handle things similarly even though I know 
 that
 the PMICs don't behave identically and that's why we decided to have 
 different
 drivers (although maybe that was a mistake and makes more sense to merge 
 them).
 
 I looked at them. In this patchset I didn't want to implement fully the
 whole suspend-mode-thing. Just the first, easier part - set suspend
 disable.
 

Agreed, incremental support makes sense to me as well.

I also want to configure the regulator modes in suspend for the Snow Chromebook
using the same modes that are in the downstream Chrome OS tree and I think your
changes will be enough for that too.

 In general I would like to do it similar to your solution but that is
 work for future. Especially as I would like to wait for merging your
 Add max77802 regulator operating mode support.
 

Perfect, thanks a lot for working on this!

 Best regards,
 Krzysztof
 

Best regards,
Javier

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


Re: [PATCH 2/2] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 11:23 AM, Krzysztof Kozlowski wrote:
   
 ldo9_reg: ldo9 {
  @@ -295,7 +311,9 @@
 regulator-name = CAM_ISP_MIPI_1.2V;
 regulator-min-microvolt = 120;
 regulator-max-microvolt = 120;
  -  regulator-mem-idle;
  +  regulator-state-mem {
  +  regulator-on-in-suspend;
 
 CAM_ISP_MIPI_1.2V is used for camera, I think this regulator should turn off 
 in suspend state
 because camear could not be used in suspend state.
 
 LDO9 does not support off in suspend mode controlled by PWRREQ. It
 supports only switching to low power mode if PWRREQ level goes low.
 
 Thus the driver does not provide set_suspend_enable or
 set_suspend_disable for LDO0. Do you want to add such function to the
 max77686 driver which will explicitly disable the regulator (write 0x0
 to control reg)?
 
 

I think for those regulators you can just use regulator_disable_regmap()
as the .set_suspend_disable function handler?

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


Re: [PATCH 2/2] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Krzysztof Kozlowski
On wto, 2014-10-21 at 12:00 +0200, Javier Martinez Canillas wrote:
 Hello Krzysztof,
 
 On 10/21/2014 11:23 AM, Krzysztof Kozlowski wrote:

ldo9_reg: ldo9 {
   @@ -295,7 +311,9 @@
regulator-name = 
   CAM_ISP_MIPI_1.2V;
regulator-min-microvolt = 
   120;
regulator-max-microvolt = 
   120;
   -regulator-mem-idle;
   +regulator-state-mem {
   +regulator-on-in-suspend;
  
  CAM_ISP_MIPI_1.2V is used for camera, I think this regulator should turn 
  off in suspend state
  because camear could not be used in suspend state.
  
  LDO9 does not support off in suspend mode controlled by PWRREQ. It
  supports only switching to low power mode if PWRREQ level goes low.
  
  Thus the driver does not provide set_suspend_enable or
  set_suspend_disable for LDO0. Do you want to add such function to the
  max77686 driver which will explicitly disable the regulator (write 0x0
  to control reg)?
  
  
 
 I think for those regulators you can just use regulator_disable_regmap()
 as the .set_suspend_disable function handler?

Sure... but this does not solve the philosophical problem - this is not
a special suspend configuration. It is disabling the regulator manually,
from regulator core code. Instead probably the camera driver should
disable the regulator in suspend callback.

Another point - I think none of other regulators do this way.

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 11/18] iommu: exynos: remove useless device_add/remove callbacks

2014-10-21 Thread Alban Browaeys
Le mardi 16 septembre 2014 à 13:54 +0200, Marek Szyprowski a écrit :
 The driver doesn't need to do anything important in device add/remove
 callbacks, because initialization will be done from device-tree specific
 callbacks added later. IOMMU groups created by current code were never
 used.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com


The exyons iommu init fails if those are removed, that is it never reach
init_done:
1. exynos_iommu_setup
2. - exynos_iommu_init
3. ---bus_set_iommu
4. -- add_iommu_group

that is (4) add_iommu_group returns ENODEV to bus_set_iommu, the latter
doing so to exynos_iommu_init. Which thus error out before the init_done
is set to true.

Mind restoring device_add/remove  is not that easy. Either I did not and
modified add_iommu_group to return 0 if add_device was not defined. This
works.
Otherwise I did revert this patch but had to also move the iommu_init
from iommu.c before of_iommu_init in arch/arm/kernel/setup.c (switching
iommu_init to global namespace in the process). This to avoid use of not
yet initialized mutex  iommu_group_mutex and crash that follow suit.
This mutex is used in iommu_group_add_device called by
exynos_iommu_add_device.

The logs of the first issue, ie exynos_iommo_init and bus_set_iommu
returns ENODEV

[0.602816] exynos_iommu_init: Failed to register exynos-iommu
driver.
[0.603358] platform 1362.sysmmu: device is not dma coherent
[0.603384] platform 1362.sysmmu: device is not behind an iommu
[0.605243] exynos-sysmmu 1362.sysmmu: genpd_dev_pm_attach()
failed to find PM domain: -2
[0.606399] exynos_iommu_init: Failed to register exynos-iommu
driver.
[0.607263] platform 1363.sysmmu: device is not dma coherent
[0.607290] platform 1363.sysmmu: device is not behind an iommu
[0.609111] exynos-sysmmu 1362.sysmmu: genpd_dev_pm_attach()
failed to find PM domain: -2
[0.609464] exynos-sysmmu 1362.sysmmu: Unbalanced
pm_runtime_enable!
[0.609868] exynos-sysmmu 1363.sysmmu: genpd_dev_pm_attach()
failed to find PM domain: -2
(...)
[0.946506] platform 1080.g2d: device is not dma coherent
[0.946553] platform 1080.g2d: device is not behind an iommu
(...)



Mind the power domain failure comes from me not finding a way to apply
the power domain registration this early yet .


Best regards,
Alban Broweys


 ---
  drivers/iommu/exynos-iommu.c | 28 
  1 file changed, 28 deletions(-)
 
 diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
 index b271348a4ec1..1b3f00726cd4 100644
 --- a/drivers/iommu/exynos-iommu.c
 +++ b/drivers/iommu/exynos-iommu.c
 @@ -1055,32 +1055,6 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct 
 iommu_domain *domain,
   return phys;
  }
  
 -static int exynos_iommu_add_device(struct device *dev)
 -{
 - struct iommu_group *group;
 - int ret;
 -
 - group = iommu_group_get(dev);
 -
 - if (!group) {
 - group = iommu_group_alloc();
 - if (IS_ERR(group)) {
 - dev_err(dev, Failed to allocate IOMMU group\n);
 - return PTR_ERR(group);
 - }
 - }
 -
 - ret = iommu_group_add_device(group, dev);
 - iommu_group_put(group);
 -
 - return ret;
 -}
 -
 -static void exynos_iommu_remove_device(struct device *dev)
 -{
 - iommu_group_remove_device(dev);
 -}
 -
  static const struct iommu_ops exynos_iommu_ops = {
   .domain_init = exynos_iommu_domain_init,
   .domain_destroy = exynos_iommu_domain_destroy,
 @@ -1089,8 +1063,6 @@ static const struct iommu_ops exynos_iommu_ops = {
   .map = exynos_iommu_map,
   .unmap = exynos_iommu_unmap,
   .iova_to_phys = exynos_iommu_iova_to_phys,
 - .add_device = exynos_iommu_add_device,
 - .remove_device = exynos_iommu_remove_device,
   .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
  };
  


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


[PATCH v3 03/13] [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails

2014-10-21 Thread Arun Kumar K
From: Prathyush K prathyus...@samsung.com

The enter_suspend flag is set after we enter mfc suspend function but if
suspend fails after that due to any reason (like hardware timeout etc),
this flag must be cleared before returning an error. Otherwise, this
flag never gets cleared and the MFC suspend will always return an error
on subsequent tries. If clock off fails, disable hw_lock also.

Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 165bc86..79c9537 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1284,11 +1284,17 @@ static int s5p_mfc_suspend(struct device *dev)
m_dev-int_cond, msecs_to_jiffies(MFC_INT_TIMEOUT));
if (ret == 0) {
mfc_err(Waiting for hardware to finish timed out\n);
+   clear_bit(0, m_dev-enter_suspend);
return -EIO;
}
}
 
-   return s5p_mfc_sleep(m_dev);
+   ret = s5p_mfc_sleep(m_dev);
+   if (ret) {
+   clear_bit(0, m_dev-enter_suspend);
+   clear_bit(0, m_dev-hw_lock);
+   }
+   return ret;
 }
 
 static int s5p_mfc_resume(struct device *dev)
-- 
1.7.9.5

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


[PATCH v3 01/13] [media] s5p-mfc: support MIN_BUFFERS query for encoder

2014-10-21 Thread Arun Kumar K
From: Kiran AVND avnd.ki...@samsung.com

Add V4L2_CID_MIN_BUFFERS_FOR_OUTPUT query for encoder.
Once mfc encoder state is HEAD_PARSED, which is sequence
header produced, dpb_count is avaialable. Let user space
query this value.

Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |   42 ++
 1 file changed, 42 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a904a1c..4816f31 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -690,6 +690,16 @@ static struct mfc_control controls[] = {
.step = 1,
.default_value = 0,
},
+   {
+   .id = V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   .name = Minimum number of output bufs,
+   .minimum = 1,
+   .maximum = 32,
+   .step = 1,
+   .default_value = 1,
+   .is_volatile = 1,
+   },
 };
 
 #define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1624,8 +1634,40 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
return ret;
 }
 
+static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct s5p_mfc_ctx *ctx = ctrl_to_ctx(ctrl);
+   struct s5p_mfc_dev *dev = ctx-dev;
+
+   switch (ctrl-id) {
+   case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
+   if (ctx-state = MFCINST_HEAD_PARSED 
+   ctx-state  MFCINST_ABORT) {
+   ctrl-val = ctx-pb_count;
+   break;
+   } else if (ctx-state != MFCINST_INIT) {
+   v4l2_err(dev-v4l2_dev, Encoding not initialised\n);
+   return -EINVAL;
+   }
+   /* Should wait for the header to be produced */
+   s5p_mfc_clean_ctx_int_flags(ctx);
+   s5p_mfc_wait_for_done_ctx(ctx,
+   S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
+   if (ctx-state = MFCINST_HEAD_PARSED 
+   ctx-state  MFCINST_ABORT) {
+   ctrl-val = ctx-pb_count;
+   } else {
+   v4l2_err(dev-v4l2_dev, Encoding not initialised\n);
+   return -EINVAL;
+   }
+   break;
+   }
+   return 0;
+}
+
 static const struct v4l2_ctrl_ops s5p_mfc_enc_ctrl_ops = {
.s_ctrl = s5p_mfc_enc_s_ctrl,
+   .g_volatile_ctrl = s5p_mfc_enc_g_v_ctrl,
 };
 
 static int vidioc_s_parm(struct file *file, void *priv,
-- 
1.7.9.5

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


[PATCH v3 00/13] Fixes from Chrome OS tree for MFC driver

2014-10-21 Thread Arun Kumar K
Upstreaming the fixes which have gone in to Chrome OS tree for MFC driver.
Tested on MFCV8, MFCV7 and MFCV6 based Exynos5 based boards, peach-pi
(5800), peach-pit (5420) and snow (5250).

Changes from v2:
1) Rebased on latest media-tree
2) Dropped the patch (14/14) from previous set
   s5p-mfc: Don't change the image size to smaller than the request.

Changes from v1:
1) Addressed all review comments from Kamil.
2) Dropped patches
   [media] s5p-mfc: set B-frames as 2 while encoding
   [media] s5p-mfc: remove reduntant clock on  clock off
   [media] s5p-mfc: don't disable clock when next ctx is pending
3) Rebased on media-tree

Arun Mankuzhi (2):
  [media] s5p-mfc: modify mfc wakeup sequence for V8
  [media] s5p-mfc: De-init MFC when watchdog kicks in

Ilja Friedel (1):
  [media] s5p-mfc: Only set timestamp/timecode for new frames.

Kiran AVND (4):
  [media] s5p-mfc: support MIN_BUFFERS query for encoder
  [media] s5p-mfc: keep RISC ON during reset for V7/V8
  [media] s5p-mfc: check mfc bus ctrl before reset
  [media] s5p-mfc: flush dpbs when resolution changes

Pawel Osciak (5):
  [media] s5p-mfc: Fix REQBUFS(0) for encoder.
  [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.
  [media] s5p-mfc: Remove unused alloc field from private buffer
struct.
  [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution
change.
  [media] s5p-mfc: fix a race in interrupt flags handling

Prathyush K (1):
  [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails

 drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c|   45 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  122 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|6 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|   54 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |   13 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   32 +-
 8 files changed, 188 insertions(+), 89 deletions(-)

-- 
1.7.9.5

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


[PATCH v3 02/13] [media] s5p-mfc: Fix REQBUFS(0) for encoder.

2014-10-21 Thread Arun Kumar K
From: Pawel Osciak posc...@chromium.org

Handle REQBUFS(0) for CAPTURE queue as well. Also use the proper queue to call
it on for OUTPUT.

Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4816f31..6a1c890 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1147,6 +1147,11 @@ static int vidioc_reqbufs(struct file *file, void *priv,
(reqbufs-memory != V4L2_MEMORY_USERPTR))
return -EINVAL;
if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+   if (reqbufs-count == 0) {
+   ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+   ctx-capture_state = QUEUE_FREE;
+   return ret;
+   }
if (ctx-capture_state != QUEUE_FREE) {
mfc_err(invalid capture state: %d\n,
ctx-capture_state);
@@ -1168,6 +1173,14 @@ static int vidioc_reqbufs(struct file *file, void *priv,
return -ENOMEM;
}
} else if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+   if (reqbufs-count == 0) {
+   mfc_debug(2, Freeing buffers\n);
+   ret = vb2_reqbufs(ctx-vq_src, reqbufs);
+   s5p_mfc_hw_call(dev-mfc_ops, release_codec_buffers,
+   ctx);
+   ctx-output_state = QUEUE_FREE;
+   return ret;
+   }
if (ctx-output_state != QUEUE_FREE) {
mfc_err(invalid output state: %d\n,
ctx-output_state);
-- 
1.7.9.5

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


[PATCH v3 04/13] [media] s5p-mfc: Only set timestamp/timecode for new frames.

2014-10-21 Thread Arun Kumar K
From: Ilja Friedel i...@chromium.org

Timestamp i of a previously decoded buffer was overwritten for some
H.264 streams with timestamp i+1 of the next buffer. This happened when
encountering frame_type S5P_FIMV_DECODE_FRAME_SKIPPED, indicating no
new frame.

In most cases this wrong indexing might not have been noticed except
for a one frame delay in frame presentation. For H.264 streams though
that require reordering of frames for presentation, it caused a slightly
erratic presentation time lookup and consequently dropped frames in the
Pepper Flash plugin.

Signed-off-by: Ilja H. Friedel i...@google.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 79c9537..eb71055 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -220,11 +220,14 @@ static void s5p_mfc_handle_frame_copy_time(struct 
s5p_mfc_ctx *ctx)
size_t dec_y_addr;
unsigned int frame_type;
 
-   dec_y_addr = s5p_mfc_hw_call(dev-mfc_ops, get_dec_y_adr, dev);
+   /* Make sure we actually have a new frame before continuing. */
frame_type = s5p_mfc_hw_call(dev-mfc_ops, get_dec_frame_type, dev);
+   if (frame_type == S5P_FIMV_DECODE_FRAME_SKIPPED)
+   return;
+   dec_y_addr = s5p_mfc_hw_call(dev-mfc_ops, get_dec_y_adr, dev);
 
/* Copy timestamp / timecode from decoded src to dst and set
-  appropriate flags */
+  appropriate flags. */
src_buf = list_entry(ctx-src_queue.next, struct s5p_mfc_buf, list);
list_for_each_entry(dst_buf, ctx-dst_queue, list) {
if (vb2_dma_contig_plane_dma_addr(dst_buf-b, 0) == dec_y_addr) 
{
@@ -250,6 +253,11 @@ static void s5p_mfc_handle_frame_copy_time(struct 
s5p_mfc_ctx *ctx)
dst_buf-b-v4l2_buf.flags |=
V4L2_BUF_FLAG_BFRAME;
break;
+   default:
+   /* Don't know how to handle
+  S5P_FIMV_DECODE_FRAME_OTHER_FRAME. */
+   mfc_debug(2, Unexpected frame type: %d\n,
+   frame_type);
}
break;
}
-- 
1.7.9.5

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


[PATCH v3 05/13] [media] s5p-mfc: keep RISC ON during reset for V7/V8

2014-10-21 Thread Arun Kumar K
From: Kiran AVND avnd.ki...@samsung.com

Reset sequence for MFC V7 and V8 do not need RISC_ON
to be set to 0, while for MFC V6 it is still needed.

Also, remove a couple of register settings during Reset
which are not needed from V6 onwards.

Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |   25 ++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 3e41ca1..5b0c334 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -340,6 +340,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
enum s5p_mfc_fw_ver fw_ver;
+   bool risc_on; /* indicates if RISC is on or off */
 };
 
 /**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0c885a8..f5bb6b2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -139,12 +139,6 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
mfc_debug_enter();
 
if (IS_MFCV6_PLUS(dev)) {
-   /* Reset IP */
-   /*  except RISC, reset */
-   mfc_write(dev, 0xFEE, S5P_FIMV_MFC_RESET_V6);
-   /*  reset release */
-   mfc_write(dev, 0x0, S5P_FIMV_MFC_RESET_V6);
-
/* Zero Initialization of MFC registers */
mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD_V6);
mfc_write(dev, 0, S5P_FIMV_HOST2RISC_CMD_V6);
@@ -153,8 +147,13 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i  S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
-   /* Reset */
-   mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+   /* Reset
+* set RISC_ON to 0 during power_on  wake_up.
+* V6 needs RISC_ON set to 0 during reset also.
+*/
+   if ((!dev-risc_on) || (!IS_MFCV7(dev)))
+   mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
mfc_write(dev, 0, S5P_FIMV_MFC_RESET_V6);
} else {
@@ -226,6 +225,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, MFC reset..\n);
s5p_mfc_clock_on();
+   dev-risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
@@ -238,8 +238,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
s5p_mfc_clear_cmds(dev);
/* 3. Release reset signal to the RISC */
s5p_mfc_clean_dev_int_flags(dev);
-   if (IS_MFCV6_PLUS(dev))
+   if (IS_MFCV6_PLUS(dev)) {
+   dev-risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, Will now wait for completion of firmware transfer\n);
@@ -336,6 +338,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, MFC reset..\n);
s5p_mfc_clock_on();
+   dev-risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
@@ -354,8 +357,10 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
return ret;
}
/* 4. Release reset signal to the RISC */
-   if (IS_MFCV6_PLUS(dev))
+   if (IS_MFCV6_PLUS(dev)) {
+   dev-risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, Ok, now will write a command to wakeup the system\n);
-- 
1.7.9.5

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


[PATCH v3 06/13] [media] s5p-mfc: check mfc bus ctrl before reset

2014-10-21 Thread Arun Kumar K
From: Kiran AVND avnd.ki...@samsung.com

during reset sequence, it is advisable to follow the below
sequence, in order to avoid unexpected behavior from MFC
. set SFR 0x7110 MFC_BUS_RESET_CTRL 0x1
  // wait for REQ_STATUS to be 1
. get SFR 0x7110 MFC_BUS_RESET_CTRL 0x3
  // reset now

Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h  |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |   25 -
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 51cb2dd..83e01f3 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -71,6 +71,7 @@
 #define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16
 #define S5P_FIMV_R2H_CMD_ERR_RET_V632
 
+#define S5P_FIMV_MFC_BUS_RESET_CTRL0x7110
 #define S5P_FIMV_FW_VERSION_V6 0xf000
 
 #define S5P_FIMV_INSTANCE_ID_V60xf008
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index f5bb6b2..0d3661b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -129,6 +129,25 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
return 0;
 }
 
+int s5p_mfc_bus_reset(struct s5p_mfc_dev *dev)
+{
+   unsigned int status;
+   unsigned long timeout;
+
+   /* Reset */
+   mfc_write(dev, 0x1, S5P_FIMV_MFC_BUS_RESET_CTRL);
+   timeout = jiffies + msecs_to_jiffies(MFC_BW_TIMEOUT);
+   /* Check bus status */
+   do {
+   if (time_after(jiffies, timeout)) {
+   mfc_err(Timeout while resetting MFC.\n);
+   return -EIO;
+   }
+   status = mfc_read(dev, S5P_FIMV_MFC_BUS_RESET_CTRL);
+   } while ((status  0x2) == 0);
+   return 0;
+}
+
 /* Reset the device */
 int s5p_mfc_reset(struct s5p_mfc_dev *dev)
 {
@@ -147,11 +166,15 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i  S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
+   /* check bus reset control before reset */
+   if (dev-risc_on)
+   if (s5p_mfc_bus_reset(dev))
+   return -EIO;
/* Reset
 * set RISC_ON to 0 during power_on  wake_up.
 * V6 needs RISC_ON set to 0 during reset also.
 */
-   if ((!dev-risc_on) || (!IS_MFCV7(dev)))
+   if ((!dev-risc_on) || (!IS_MFCV7_PLUS(dev)))
mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
 
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
-- 
1.7.9.5

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


[PATCH v3 10/13] [media] s5p-mfc: flush dpbs when resolution changes

2014-10-21 Thread Arun Kumar K
From: Kiran AVND avnd.ki...@samsung.com

While resolution change is detected by MFC, we flush out
older dpbs, send the resolution change event to application,
and then accept further queuing of new src buffers.

Sometimes, we error out during dpb flush because of lack of src
buffers. Since we have not started decoding new resolution yet,
it is simpler to push zero-size buffer until we flush out all dpbs.

This is already been done while handling EOS command, and this patch
extends the same logic to resolution change as well.

Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 8798b14..7b1cf73 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1532,27 +1532,11 @@ static inline int s5p_mfc_get_new_ctx(struct 
s5p_mfc_dev *dev)
 static inline void s5p_mfc_run_dec_last_frames(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx-dev;
-   struct s5p_mfc_buf *temp_vb;
-   unsigned long flags;
-
-   spin_lock_irqsave(dev-irqlock, flags);
-
-   /* Frames are being decoded */
-   if (list_empty(ctx-src_queue)) {
-   mfc_debug(2, No src buffers.\n);
-   spin_unlock_irqrestore(dev-irqlock, flags);
-   return;
-   }
-   /* Get the next source buffer */
-   temp_vb = list_entry(ctx-src_queue.next, struct s5p_mfc_buf, list);
-   temp_vb-flags |= MFC_BUF_FLAG_USED;
-   s5p_mfc_set_dec_stream_buffer_v6(ctx,
-   vb2_dma_contig_plane_dma_addr(temp_vb-b, 0), 0, 0);
-   spin_unlock_irqrestore(dev-irqlock, flags);
 
+   s5p_mfc_set_dec_stream_buffer_v6(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
s5p_mfc_clean_ctx_int_flags(ctx);
-   s5p_mfc_decode_one_frame_v6(ctx, 1);
+   s5p_mfc_decode_one_frame_v6(ctx, MFC_DEC_LAST_FRAME);
 }
 
 static inline int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx)
-- 
1.7.9.5

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


[PATCH v3 07/13] [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.

2014-10-21 Thread Arun Kumar K
From: Pawel Osciak posc...@chromium.org

If the software watchdog kicks in, the watchdog worker is not synchronized
with hardware interrupts and does not block other instances. It's possible
for it to clear the hw_lock, making other instances trigger a BUG() on
hw_lock checks. Since it's not fatal to clear the hw_lock to zero twice,
just WARN in those cases for now. We should not explode, as firmware will
return errors as needed for other instances after it's reloaded, or they
will time out.

A clean fix should involve killing other instances when watchdog kicks in,
but requires a major redesign of locking in the driver.

Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index eb71055..8620236 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -342,8 +342,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
ctx-state = MFCINST_RES_CHANGE_INIT;
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
return;
@@ -415,8 +414,7 @@ leave_handle_frame:
clear_work_bit(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
/* if suspending, wake up device and do not try_run again*/
if (test_bit(0, dev-enter_suspend))
@@ -463,8 +461,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
break;
}
}
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
@@ -518,8 +515,7 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
}
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
@@ -557,16 +553,14 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
} else {
ctx-dpb_flush_flag = 0;
}
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
 
s5p_mfc_clock_off();
 
wake_up(ctx-queue);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
} else {
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
 
s5p_mfc_clock_off();
 
@@ -643,8 +637,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
mfc_err(post_frame_start() failed\n);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, dev-hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
} else {
-- 
1.7.9.5

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


[PATCH v3 08/13] [media] s5p-mfc: modify mfc wakeup sequence for V8

2014-10-21 Thread Arun Kumar K
From: Arun Mankuzhi aru...@samsung.com

From MFC V8, the MFC wakeup sequence has changed.
MFC wakeup command has to be sent after the host receives
firmware load complete status from risc.

Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |   78 +++--
 1 file changed, 61 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0d3661b..7c3eaa5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -353,6 +353,58 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
return ret;
 }
 
+static int s5p_mfc_v8_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+   int ret;
+
+   /* Release reset signal to the RISC */
+   dev-risc_on = 1;
+   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
+   mfc_err(Failed to reset MFCV8\n);
+   return -EIO;
+   }
+   mfc_debug(2, Write command to wakeup MFCV8\n);
+   ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
+   if (ret) {
+   mfc_err(Failed to send command to MFCV8 - timeout\n);
+   return ret;
+   }
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+   mfc_err(Failed to wakeup MFC\n);
+   return -EIO;
+   }
+   return ret;
+}
+
+static int s5p_mfc_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+   int ret;
+
+   /* Send MFC wakeup command */
+   ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
+   if (ret) {
+   mfc_err(Failed to send command to MFC - timeout\n);
+   return ret;
+   }
+
+   /* Release reset signal to the RISC */
+   if (IS_MFCV6_PLUS(dev)) {
+   dev-risc_on = 1;
+   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   } else {
+   mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+   }
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+   mfc_err(Failed to wakeup MFC\n);
+   return -EIO;
+   }
+   return ret;
+}
+
 int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
 {
int ret;
@@ -365,6 +417,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
+   s5p_mfc_clock_off();
return ret;
}
mfc_debug(2, Done MFC reset..\n);
@@ -373,25 +426,16 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 2. Initialize registers of channel I/F */
s5p_mfc_clear_cmds(dev);
s5p_mfc_clean_dev_int_flags(dev);
-   /* 3. Initialize firmware */
-   ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
-   if (ret) {
-   mfc_err(Failed to send command to MFC - timeout\n);
-   return ret;
-   }
-   /* 4. Release reset signal to the RISC */
-   if (IS_MFCV6_PLUS(dev)) {
-   dev-risc_on = 1;
-   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
-   }
+   /* 3. Send MFC wakeup command and wait for completion*/
+   if (IS_MFCV8(dev))
+   ret = s5p_mfc_v8_wait_wakeup(dev);
else
-   mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
-   mfc_debug(2, Ok, now will write a command to wakeup the system\n);
-   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
-   mfc_err(Failed to load firmware\n);
-   return -EIO;
-   }
+   ret = s5p_mfc_wait_wakeup(dev);
+
s5p_mfc_clock_off();
+   if (ret)
+   return ret;
+
dev-int_cond = 0;
if (dev-int_err != 0 || dev-int_type !=
S5P_MFC_R2H_CMD_WAKEUP_RET) {
-- 
1.7.9.5

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


[PATCH v3 09/13] [media] s5p-mfc: De-init MFC when watchdog kicks in

2014-10-21 Thread Arun Kumar K
From: Arun Mankuzhi aru...@samsung.com

If the software watchdog kicks in, we need to de-init MFC
before reloading firmware and re-intializing it again.

Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8620236..39f8f2a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -159,6 +159,10 @@ static void s5p_mfc_watchdog_worker(struct work_struct 
*work)
}
clear_bit(0, dev-hw_lock);
spin_unlock_irqrestore(dev-irqlock, flags);
+
+   /* De-init MFC */
+   s5p_mfc_deinit_hw(dev);
+
/* Double check if there is at least one instance running.
 * If no instance is in memory than no firmware should be present */
if (dev-num_inst  0) {
-- 
1.7.9.5

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


[PATCH v3 12/13] [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution change.

2014-10-21 Thread Arun Kumar K
From: Pawel Osciak posc...@chromium.org

G_CTRL on V4L2_CID_MIN_BUFFERS_FOR_CAPTURE will fail if userspace happens to
query it after getting a resolution change event and before the codec has
a chance to parse the header and switch to an initialized state.

Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index a98fe02..de90465 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -740,7 +740,8 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
ctx-state  MFCINST_ABORT) {
ctrl-val = ctx-pb_count;
break;
-   } else if (ctx-state != MFCINST_INIT) {
+   } else if (ctx-state != MFCINST_INIT 
+   ctx-state != MFCINST_RES_CHANGE_END) {
v4l2_err(dev-v4l2_dev, Decoding not initialised\n);
return -EINVAL;
}
-- 
1.7.9.5

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


[PATCH v3 13/13] [media] s5p-mfc: fix a race in interrupt flags handling

2014-10-21 Thread Arun Kumar K
From: Pawel Osciak posc...@chromium.org

Interrupt result flags have to be cleared before a hardware job is run.
Otherwise, if they are cleared asynchronously, we may end up clearing them
after the interrupt for which we wanted to wait has already arrived, thus
overwriting the job results that we intended to wait for.

To prevent this, clear the flags only under hw_lock and before running
a hardware job.

Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |2 --
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|3 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |   13 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   12 ++--
 5 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 7c3eaa5..86d43d9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -468,7 +468,6 @@ int s5p_mfc_open_mfc_inst(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx)
}
 
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_OPEN_INSTANCE_RET, 0)) {
@@ -494,7 +493,6 @@ void s5p_mfc_close_mfc_inst(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx)
 {
ctx-state = MFCINST_RETURN_INST;
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
/* Wait until instance is returned or timeout occurred */
if (s5p_mfc_wait_for_done_ctx(ctx,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index de90465..74bcec8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -334,7 +334,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
MFCINST_RES_CHANGE_END)) {
/* If the MFC is parsing the header,
 * so wait until it is finished */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx, S5P_MFC_R2H_CMD_SEQ_DONE_RET,
0);
}
@@ -746,7 +745,6 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be parsed */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx-state = MFCINST_HEAD_PARSED 
@@ -1058,7 +1056,6 @@ static void s5p_mfc_stop_streaming(struct vb2_queue *q)
if (IS_MFCV6_PLUS(dev)  (ctx-state == MFCINST_RUNNING)) {
ctx-state = MFCINST_FLUSH;
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_DPB_FLUSH_RET, 0))
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 6a1c890..7f919e4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1663,7 +1663,6 @@ static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be produced */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx-state = MFCINST_HEAD_PARSED 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 7cf0796..0c4fcf2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1178,7 +1178,6 @@ static void s5p_mfc_run_res_change(struct s5p_mfc_ctx 
*ctx)
 
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_decode_one_frame_v5(ctx, MFC_DEC_RES_CHANGE);
 }
 
@@ -1192,7 +1191,6 @@ static int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx, 
int last_frame)
last_frame = MFC_DEC_LAST_FRAME;
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
-

[PATCH v3 11/13] [media] s5p-mfc: Remove unused alloc field from private buffer struct.

2014-10-21 Thread Arun Kumar K
From: Pawel Osciak posc...@chromium.org

This field is no longer used as MFC driver doesn't use vb2 alloc contexts
anymore.

Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 5b0c334..15f7663 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -237,8 +237,6 @@ struct s5p_mfc_variant {
 
 /**
  * struct s5p_mfc_priv_buf - represents internal used buffer
- * @alloc: allocation-specific context for each buffer
- * (videobuf2 allocator)
  * @ofs:   offset of each buffer, will be used for MFC
  * @virt:  kernel virtual address, only valid when the
  * buffer accessed by driver
@@ -246,7 +244,6 @@ struct s5p_mfc_variant {
  * @size:  size of the buffer
  */
 struct s5p_mfc_priv_buf {
-   void*alloc;
unsigned long   ofs;
void*virt;
dma_addr_t  dma;
-- 
1.7.9.5

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


[PATCH v2 1/4] regulator: max77686: Replace hard-coded opmode values with defines

2014-10-21 Thread Krzysztof Kozlowski
Add defines for regulator operating modes which should be more readable,
especially if one does not have Maxim 77686 datasheet.

The patch does not introduce any functional change.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/regulator/max77686.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index ef1af2debbd2..cffe0c69d57d 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -45,6 +45,16 @@
 #define MAX77686_DVS_MINUV 60
 #define MAX77686_DVS_UVSTEP12500
 
+/* On/off controlled by PWRREQ */
+#define MAX77686_OPMODE_OFF_PWRREQ 0x1
+/*
+ * For some regulators this means:
+ *  - forcing low power mode.
+ *  - low power mode controlled by PWRREQ.
+ */
+#define MAX77686_OPMODE_LOWPOWER   0x2
+#define MAX77686_OPMODE_NORMAL 0x3
+
 #define MAX77686_OPMODE_SHIFT  6
 #define MAX77686_OPMODE_BUCK234_SHIFT  4
 #define MAX77686_OPMODE_MASK   0x3
@@ -76,9 +86,10 @@ static int max77686_buck_set_suspend_disable(struct 
regulator_dev *rdev)
int ret, id = rdev_get_id(rdev);
 
if (id == MAX77686_BUCK1)
-   val = 0x1;
+   val = MAX77686_OPMODE_OFF_PWRREQ;
else
-   val = 0x1  MAX77686_OPMODE_BUCK234_SHIFT;
+   val = MAX77686_OPMODE_OFF_PWRREQ
+MAX77686_OPMODE_BUCK234_SHIFT;
 
ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 rdev-desc-enable_mask, val);
@@ -103,10 +114,10 @@ static int max77686_set_suspend_mode(struct regulator_dev 
*rdev,
 
switch (mode) {
case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
-   val = 0x2  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_OPMODE_LOWPOWER  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
-   val = 0x3  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_OPMODE_NORMAL  MAX77686_OPMODE_SHIFT;
break;
default:
pr_warn(%s: regulator_suspend_mode : 0x%x not supported\n,
@@ -133,13 +144,13 @@ static int max77686_ldo_set_suspend_mode(struct 
regulator_dev *rdev,
 
switch (mode) {
case REGULATOR_MODE_STANDBY:/* switch off */
-   val = 0x1  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_OPMODE_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
-   val = 0x2  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_OPMODE_LOWPOWER  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
-   val = 0x3  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_OPMODE_NORMAL  MAX77686_OPMODE_SHIFT;
break;
default:
pr_warn(%s: regulator_suspend_mode : 0x%x not supported\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 4/4] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Krzysztof Kozlowski
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.

Additionally remove old and not supported bindings:
 - regulator-mem-off
 - regulator-mem-idle
 - regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index dd9ac66770f7..8067eb447829 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -225,7 +225,6 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo2_reg: ldo2 {
@@ -234,7 +233,9 @@
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo3_reg: ldo3 {
@@ -243,7 +244,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo4_reg: ldo4 {
@@ -252,7 +252,6 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo5_reg: ldo5 {
@@ -261,7 +260,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo6_reg: ldo6 {
@@ -270,7 +268,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo7_reg: ldo7 {
@@ -279,7 +279,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo8_reg: ldo8 {
@@ -287,7 +289,9 @@
regulator-name = VMIPI_1.0V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
-   regulator-mem-off;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
ldo9_reg: ldo9 {
@@ -295,7 +299,6 @@
regulator-name = CAM_ISP_MIPI_1.2V;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
-   regulator-mem-idle;
};
 
ldo10_reg: ldo10 {
@@ -303,7 +306,9 @@
regulator-name = VMIPI_1.8V;
   

[PATCH v2 3/4] mfd/regulator: dt-bindings: max77686: Document regulators off in suspend

2014-10-21 Thread Krzysztof Kozlowski
Add information which regulators can be disabled during system suspend.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 Documentation/devicetree/bindings/mfd/max77686.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 678f3cf0b8f0..75fdfaf41831 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -34,6 +34,12 @@ to get matched with their hardware counterparts as follow:
-BUCKn  :   for BUCKs, where n can lie in range 1 to 9.
example: BUCK1, BUCK5, BUCK9.
 
+  Regulators which can be turned off during system suspend:
+   -LDOn   :   2, 6-8, 10-12, 14-16,
+   -BUCKn  :   1-4.
+  Use standard regulator bindings for it ('regulator-off-in-suspend').
+
+
 Example:
 
max77686@09 {
-- 
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 2/4] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Krzysztof Kozlowski
Some LDOs of Maxim 77686 PMIC support disabling during system suspend
(LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
of set_suspend_mode function. In that case the mode was one of:
 - disable,
 - normal mode,
 - low power mode.
However there are no bindings for setting the mode during suspend.

Add suspend disable for LDO regulators supporting this to the existing
max77686_buck_set_suspend_disable() function. This helps reducing
energy consumption during system sleep.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/regulator/max77686.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index cffe0c69d57d..05df72d584bf 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -79,17 +79,33 @@ struct max77686_data {
 };
 
 /* Some BUCKS supports Normal[ON/OFF] mode during suspend */
-static int max77686_buck_set_suspend_disable(struct regulator_dev *rdev)
+static int max77686_set_suspend_disable(struct regulator_dev *rdev)
 {
unsigned int val;
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
int ret, id = rdev_get_id(rdev);
 
-   if (id == MAX77686_BUCK1)
+   switch (id) {
+   case MAX77686_BUCK1:
val = MAX77686_OPMODE_OFF_PWRREQ;
-   else
+   break;
+   case MAX77686_BUCK2:
+   case MAX77686_BUCK3:
+   case MAX77686_BUCK4:
val = MAX77686_OPMODE_OFF_PWRREQ
 MAX77686_OPMODE_BUCK234_SHIFT;
+   break;
+   case MAX77686_LDO2:
+   case MAX77686_LDO6 ... MAX77686_LDO8:
+   case MAX77686_LDO10 ... MAX77686_LDO12:
+   case MAX77686_LDO14 ... MAX77686_LDO16:
+   val = MAX77686_OPMODE_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
+   break;
+   default:
+   pr_warn(%s: regulator_suspend_disable not supported\n,
+   rdev-desc-name);
+   return -EINVAL;
+   }
 
ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 rdev-desc-enable_mask, val);
@@ -171,6 +187,9 @@ static int max77686_enable(struct regulator_dev *rdev)
 {
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
 
+   if (max77686-opmode[rdev_get_id(rdev)] == MAX77686_OPMODE_OFF_PWRREQ)
+   max77686-opmode[rdev_get_id(rdev)] = MAX77686_OPMODE_NORMAL;
+
return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
  rdev-desc-enable_mask,
  max77686-opmode[rdev_get_id(rdev)]);
@@ -223,6 +242,8 @@ static struct regulator_ops max77686_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
.set_suspend_mode   = max77686_ldo_set_suspend_mode,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 static struct regulator_ops max77686_buck1_ops = {
@@ -234,7 +255,8 @@ static struct regulator_ops max77686_buck1_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
-   .set_suspend_disable= max77686_buck_set_suspend_disable,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 static struct regulator_ops max77686_buck_dvs_ops = {
@@ -247,7 +269,8 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
.set_ramp_delay = max77686_set_ramp_delay,
-   .set_suspend_disable= max77686_buck_set_suspend_disable,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 #define regulator_desc_ldo(num){   
\
-- 
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 0/4] regulator: max77686/trats2: Disable some regulators in suspend

2014-10-21 Thread Krzysztof Kozlowski
Hi,


Changes since v1

1. Add patch 1/4 and 3/4.
2. Patch 2/4: Extend existing set_suspend_disable (for bucks) with
   LDO support. Implement set_suspend_enable. Suggested by Javier.
3. Patch 4/4: Add regulator suspend properties only to regulators
   actually supporting this. Other regulators, not implementing
   suspend enable/disable, will warn (VCC_1.8V_IO: No configuration).
4. Patch 4/4: In suspend enable VHSIC_1.0V and VHSIC_1.8V regulators.
   Suggested by Chanwoo Choi.


Description
===
This patchset makes use of Javier Martinez Cainllas changes [1].
It allows disabling some of the regulators during suspend to RAM.

Javier's patchset is necessary only to test it.

[1] [PATCH v3 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish
https://lkml.org/lkml/2014/10/20/545


Best regards,
Krzysztof


Krzysztof Kozlowski (4):
  regulator: max77686: Replace hard-coded opmode values with defines
  regulator: max77686: Implement suspend disable for some LDOs
  mfd/regulator: dt-bindings: max77686: Document regulators off in
suspend
  ARM: dts: exynos4412-trats: Add suspend configuration for max77686
regulators

 Documentation/devicetree/bindings/mfd/max77686.txt |  6 ++
 arch/arm/boot/dts/exynos4412-trats2.dts| 72 +-
 drivers/regulator/max77686.c   | 58 +
 3 files changed, 94 insertions(+), 42 deletions(-)

-- 
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: [GIT PULL 2/3] 1st Round of Samsung PM updates for v3.19

2014-10-21 Thread Bartlomiej Zolnierkiewicz

Hi,

On Tuesday, October 21, 2014 12:54:27 AM Kukjin Kim wrote:
 Hi,
 
 Same, I've just rebased for Samsung PM updates for v3.19.
 Please pull.

Unfortunately this pull request has the same issue that caused Arnd to
refuse the pull for v3.18:

  https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37320.html

You can find the fix for the issue at the bottom of this mail.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

 Thanks,
 Kukjin
 
 ---
 
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
 
Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
 
 are available in the git repository at:
 
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
 tags/samsung-pm
 
 for you to fetch changes up to b588aaec6d0d846c88bfa2ba95e76147386a4cd6:
 
ARM: EXYNOS: SWRESET is needed to boot secondary CPU on exynos3250 
 (2014-10-21 00:06:36 +0900)
 
 
 Samsung PM updates for v3.19
 
 - Refactor the pm code to use DT based lookup instead of
using soc_is_exynos
 
 - Firmware supporting suspend and resume to excute of low
level operations to enter and leave power mode for exynos
: introduce suspend() and resume() firmware operations
 
 - Fix AFTR mode on boards with secure firmware enabled and
allows exynos cpuidle driver usage on exynos4x12 SoCs
 
 - Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y
 
 - SWRESET is needed to boot secondary CPU on exynos3250
 
 
 Bartlomiej Zolnierkiewicz (6):
ARM: EXYNOS: replace EXYNOS_BOOT_VECTOR_* macros by static inlines
ARM: firmware: add AFTR mode support to firmware do_idle method
ARM: EXYNOS: add secure firmware support to AFTR mode code
ARM: EXYNOS: fix register setup for AFTR mode code
ARM: EXYNOS: allow driver usage on Exynos4x12 SoCs
ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y
 
 Krzysztof Kozlowski (1):
ARM: EXYNOS: SWRESET is needed to boot secondary CPU on exynos3250
 
 Tomasz Figa (2):
ARM: firmware: Introduce suspend and resume operations
ARM: EXYNOS: Add support for firmware-assisted suspend/resume
 
 Vikas Sajjan (2):
ARM: EXYNOS: Move Disabling of JPEG USE_RETENTION for exynos5250 
 to pmu.c
ARM: EXYNOS: Refactor the pm code to use DT based lookup
 
   Documentation/arm/firmware.txt |  28 +--
   arch/arm/include/asm/firmware.h|  10 +-
   arch/arm/mach-exynos/Kconfig   |   5 +
   arch/arm/mach-exynos/Makefile  |   6 +-
   arch/arm/mach-exynos/common.h  |  13 ++
   arch/arm/mach-exynos/exynos.c  |   5 +-
   arch/arm/mach-exynos/firmware.c|  65 +-
   arch/arm/mach-exynos/platsmp.c |  23 +++
   arch/arm/mach-exynos/pm.c  | 310 
   arch/arm/mach-exynos/pmu.c |   1 +
   arch/arm/mach-exynos/regs-pmu.h|   3 +
   arch/arm/mach-exynos/sleep.S   |  28 +++
   arch/arm/mach-exynos/smc.h |   4 +
   arch/arm/mach-exynos/suspend.c | 356 
 +
   arch/arm/mach-tegra/cpuidle-tegra114.c |   2 +-
   arch/arm/plat-samsung/Makefile |   1 +
   16 files changed, 559 insertions(+), 301 deletions(-)
   create mode 100644 arch/arm/mach-exynos/suspend.c

From: Arnd Bergmann a...@arndb.de
Subject: [PATCH] ARM: EXYNOS: Fix build with ARM_CPU_SUSPEND=n

ARM: EXYNOS: Add support for firmware-assisted suspend/resume patch
added to arch/arm/mach-exynos/firmware.c new references to functions
from arch/arm/mach-exynos/sleep.S causing the new CONFIG_PM_SLEEP=n
build breakages.  Then ARM: EXYNOS: Fix build with PM_SLEEP=n and
ARM_EXYNOS_CPUIDLE=y patch tried to fix the CONFIG_PM_SLEEP=n issues
by always building sleep.S which caused the CONFIG_ARM_CPU_SUSPEND=n
build breakage.  Fix it by building arch/arm/mach-exynos/sleep.o only
for CONFIG_EXYNOS_CPU_SUSPEND=y and adding appropriate IS_ENABLED()
checks to arch/arm/mach-exynos/firmware.c.

From: Arnd Bergmann a...@arndb.de
[b.zolnierkie: fixed -resume check and added patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/mach-exynos/Makefile   |4 ++--
 arch/arm/mach-exynos/firmware.c |6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

Index: b/arch/arm/mach-exynos/Makefile
===
--- a/arch/arm/mach-exynos/Makefile 2014-10-07 18:27:43.023737860 +0200
+++ b/arch/arm/mach-exynos/Makefile 2014-10-21 13:14:32.827064742 +0200
@@ -9,9 +9,9 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
 
 # Core
 
-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
sleep.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o
 
-obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += 

RE: [GIT PULL 2/3] 1st Round of Samsung PM updates for v3.19

2014-10-21 Thread Kukjin Kim
Bartlomiej Zolnierkiewicz wrote:
 
 Hi,
 
Hi,

 On Tuesday, October 21, 2014 12:54:27 AM Kukjin Kim wrote:
  Hi,
 
  Same, I've just rebased for Samsung PM updates for v3.19.
  Please pull.
 
 Unfortunately this pull request has the same issue that caused Arnd to
 refuse the pull for v3.18:
 
Oops, I've missed that :(

   https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37320.html
 
 You can find the fix for the issue at the bottom of this mail.
 
OK, I will fix and send new pull-request soon.

Thanks for your point out.

@ Arnd, Olof, Kevin,

Please kindly ignore this but 1/3 and 3/3 should be fine ;)

- Kukjin

 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
  Thanks,
  Kukjin
 
  ---
 
  The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
 
 Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
 
  are available in the git repository at:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  tags/samsung-pm
 
  for you to fetch changes up to b588aaec6d0d846c88bfa2ba95e76147386a4cd6:
 
 ARM: EXYNOS: SWRESET is needed to boot secondary CPU on exynos3250
  (2014-10-21 00:06:36 +0900)
 
  
  Samsung PM updates for v3.19
 
  - Refactor the pm code to use DT based lookup instead of
 using soc_is_exynos
 
  - Firmware supporting suspend and resume to excute of low
 level operations to enter and leave power mode for exynos
 : introduce suspend() and resume() firmware operations
 
  - Fix AFTR mode on boards with secure firmware enabled and
 allows exynos cpuidle driver usage on exynos4x12 SoCs
 
  - Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y
 
  - SWRESET is needed to boot secondary CPU on exynos3250
 
  
  Bartlomiej Zolnierkiewicz (6):
 ARM: EXYNOS: replace EXYNOS_BOOT_VECTOR_* macros by static inlines
 ARM: firmware: add AFTR mode support to firmware do_idle method
 ARM: EXYNOS: add secure firmware support to AFTR mode code
 ARM: EXYNOS: fix register setup for AFTR mode code
 ARM: EXYNOS: allow driver usage on Exynos4x12 SoCs
 ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y
 
  Krzysztof Kozlowski (1):
 ARM: EXYNOS: SWRESET is needed to boot secondary CPU on exynos3250
 
  Tomasz Figa (2):
 ARM: firmware: Introduce suspend and resume operations
 ARM: EXYNOS: Add support for firmware-assisted suspend/resume
 
  Vikas Sajjan (2):
 ARM: EXYNOS: Move Disabling of JPEG USE_RETENTION for exynos5250
  to pmu.c
 ARM: EXYNOS: Refactor the pm code to use DT based lookup
 
Documentation/arm/firmware.txt |  28 +--
arch/arm/include/asm/firmware.h|  10 +-
arch/arm/mach-exynos/Kconfig   |   5 +
arch/arm/mach-exynos/Makefile  |   6 +-
arch/arm/mach-exynos/common.h  |  13 ++
arch/arm/mach-exynos/exynos.c  |   5 +-
arch/arm/mach-exynos/firmware.c|  65 +-
arch/arm/mach-exynos/platsmp.c |  23 +++
arch/arm/mach-exynos/pm.c  | 310 
arch/arm/mach-exynos/pmu.c |   1 +
arch/arm/mach-exynos/regs-pmu.h|   3 +
arch/arm/mach-exynos/sleep.S   |  28 +++
arch/arm/mach-exynos/smc.h |   4 +
arch/arm/mach-exynos/suspend.c | 356
  +
arch/arm/mach-tegra/cpuidle-tegra114.c |   2 +-
arch/arm/plat-samsung/Makefile |   1 +
16 files changed, 559 insertions(+), 301 deletions(-)
create mode 100644 arch/arm/mach-exynos/suspend.c
 
 From: Arnd Bergmann a...@arndb.de
 Subject: [PATCH] ARM: EXYNOS: Fix build with ARM_CPU_SUSPEND=n
 
 ARM: EXYNOS: Add support for firmware-assisted suspend/resume patch
 added to arch/arm/mach-exynos/firmware.c new references to functions
 from arch/arm/mach-exynos/sleep.S causing the new CONFIG_PM_SLEEP=n
 build breakages.  Then ARM: EXYNOS: Fix build with PM_SLEEP=n and
 ARM_EXYNOS_CPUIDLE=y patch tried to fix the CONFIG_PM_SLEEP=n issues
 by always building sleep.S which caused the CONFIG_ARM_CPU_SUSPEND=n
 build breakage.  Fix it by building arch/arm/mach-exynos/sleep.o only
 for CONFIG_EXYNOS_CPU_SUSPEND=y and adding appropriate IS_ENABLED()
 checks to arch/arm/mach-exynos/firmware.c.
 
 From: Arnd Bergmann a...@arndb.de
 [b.zolnierkie: fixed -resume check and added patch description]
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 ---
  arch/arm/mach-exynos/Makefile   |4 ++--
  arch/arm/mach-exynos/firmware.c |6 +++---
  2 files changed, 5 insertions(+), 5 deletions(-)
 
 Index: b/arch/arm/mach-exynos/Makefile
 ===
 --- a/arch/arm/mach-exynos/Makefile   2014-10-07 18:27:43.023737860 +0200
 +++ 

Re: [PATCH v2 1/4] regulator: max77686: Replace hard-coded opmode values with defines

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

Thanks a lot for the re-spin.

On 10/21/2014 01:23 PM, Krzysztof Kozlowski wrote:
 Add defines for regulator operating modes which should be more readable,
 especially if one does not have Maxim 77686 datasheet.
 
 The patch does not introduce any functional change.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/regulator/max77686.c | 25 ++---
  1 file changed, 18 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
 index ef1af2debbd2..cffe0c69d57d 100644
 --- a/drivers/regulator/max77686.c
 +++ b/drivers/regulator/max77686.c
 @@ -45,6 +45,16 @@
  #define MAX77686_DVS_MINUV   60
  #define MAX77686_DVS_UVSTEP  12500
  
 +/* On/off controlled by PWRREQ */
 +#define MAX77686_OPMODE_OFF_PWRREQ   0x1

Minor nit: maybe this should be called MAX77802_OFF_PWRREQ (without the OPMODE)?
Since afaiu from a conceptual pov the regulators only supports two modes: normal
and low power mode.

If a regulator is disabled or put in low power mode by PWRREQ on suspend, then
is not really an operating mode (the regulator output will still be normal until
suspend) but an enable pin to switch a regulator mode automatically by the SoC.

 +/*
 + * For some regulators this means:
 + *  - forcing low power mode.
 + *  - low power mode controlled by PWRREQ.
 + */
 +#define MAX77686_OPMODE_LOWPOWER 0x2

Can you also add a #define MAX77686_LP_PWRREQ 0x2 and use each one when
appropriate? That will better document when 0x2 means low power by PWRREQ
and when it means change regulator mode to low power.

Also, are you sure that forcing low power mode is 0x2 and not 0x1?

I'm asking because I see in the max77802 data-sheet that regulators that
supports its mode to be low power during runtime are using 0x1:

01b: Output ON in Low Power Mode

Maybe is different in the max77686 or I misunderstood your comment though...

 +#define MAX77686_OPMODE_NORMAL   0x3
 +
  #define MAX77686_OPMODE_SHIFT6
  #define MAX77686_OPMODE_BUCK234_SHIFT4
  #define MAX77686_OPMODE_MASK 0x3
 @@ -76,9 +86,10 @@ static int max77686_buck_set_suspend_disable(struct 
 regulator_dev *rdev)
   int ret, id = rdev_get_id(rdev);
  
   if (id == MAX77686_BUCK1)
 - val = 0x1;
 + val = MAX77686_OPMODE_OFF_PWRREQ;
   else
 - val = 0x1  MAX77686_OPMODE_BUCK234_SHIFT;
 + val = MAX77686_OPMODE_OFF_PWRREQ
 +  MAX77686_OPMODE_BUCK234_SHIFT;
  
   ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
rdev-desc-enable_mask, val);
 @@ -103,10 +114,10 @@ static int max77686_set_suspend_mode(struct 
 regulator_dev *rdev,
  
   switch (mode) {
   case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
 - val = 0x2  MAX77686_OPMODE_SHIFT;
 + val = MAX77686_OPMODE_LOWPOWER  MAX77686_OPMODE_SHIFT;
   break;
   case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
 - val = 0x3  MAX77686_OPMODE_SHIFT;
 + val = MAX77686_OPMODE_NORMAL  MAX77686_OPMODE_SHIFT;
   break;
   default:
   pr_warn(%s: regulator_suspend_mode : 0x%x not supported\n,
 @@ -133,13 +144,13 @@ static int max77686_ldo_set_suspend_mode(struct 
 regulator_dev *rdev,
  
   switch (mode) {
   case REGULATOR_MODE_STANDBY:/* switch off */
 - val = 0x1  MAX77686_OPMODE_SHIFT;
 + val = MAX77686_OPMODE_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
   break;
   case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
 - val = 0x2  MAX77686_OPMODE_SHIFT;
 + val = MAX77686_OPMODE_LOWPOWER  MAX77686_OPMODE_SHIFT;
   break;
   case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
 - val = 0x3  MAX77686_OPMODE_SHIFT;
 + val = MAX77686_OPMODE_NORMAL  MAX77686_OPMODE_SHIFT;
   break;
   default:
   pr_warn(%s: regulator_suspend_mode : 0x%x not supported\n,
 

If you do those two changes please feel free to add my Reviewed-by.

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


Re: [PATCH v2 2/4] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 01:23 PM, Krzysztof Kozlowski wrote:
 Some LDOs of Maxim 77686 PMIC support disabling during system suspend
 (LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
 of set_suspend_mode function. In that case the mode was one of:
  - disable,
  - normal mode,
  - low power mode.
 However there are no bindings for setting the mode during suspend.
 
 Add suspend disable for LDO regulators supporting this to the existing
 max77686_buck_set_suspend_disable() function. This helps reducing
 energy consumption during system sleep.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/regulator/max77686.c | 33 -
  1 file changed, 28 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
 index cffe0c69d57d..05df72d584bf 100644
 --- a/drivers/regulator/max77686.c
 +++ b/drivers/regulator/max77686.c
 @@ -79,17 +79,33 @@ struct max77686_data {
  };
  
  /* Some BUCKS supports Normal[ON/OFF] mode during suspend */
 -static int max77686_buck_set_suspend_disable(struct regulator_dev *rdev)
 +static int max77686_set_suspend_disable(struct regulator_dev *rdev)
  {
   unsigned int val;
   struct max77686_data *max77686 = rdev_get_drvdata(rdev);
   int ret, id = rdev_get_id(rdev);
  
 - if (id == MAX77686_BUCK1)
 + switch (id) {
 + case MAX77686_BUCK1:
   val = MAX77686_OPMODE_OFF_PWRREQ;
 - else
 + break;
 + case MAX77686_BUCK2:
 + case MAX77686_BUCK3:
 + case MAX77686_BUCK4:
   val = MAX77686_OPMODE_OFF_PWRREQ
MAX77686_OPMODE_BUCK234_SHIFT;
 + break;
 + case MAX77686_LDO2:
 + case MAX77686_LDO6 ... MAX77686_LDO8:
 + case MAX77686_LDO10 ... MAX77686_LDO12:
 + case MAX77686_LDO14 ... MAX77686_LDO16:
 + val = MAX77686_OPMODE_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
 + break;
 + default:
 + pr_warn(%s: regulator_suspend_disable not supported\n,
 + rdev-desc-name);
 + return -EINVAL;
 + }
  
   ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
rdev-desc-enable_mask, val);
 @@ -171,6 +187,9 @@ static int max77686_enable(struct regulator_dev *rdev)
  {
   struct max77686_data *max77686 = rdev_get_drvdata(rdev);
  
 + if (max77686-opmode[rdev_get_id(rdev)] == MAX77686_OPMODE_OFF_PWRREQ)
 + max77686-opmode[rdev_get_id(rdev)] = MAX77686_OPMODE_NORMAL;
 +
   return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 rdev-desc-enable_mask,
 max77686-opmode[rdev_get_id(rdev)]);
 @@ -223,6 +242,8 @@ static struct regulator_ops max77686_ldo_ops = {
   .set_voltage_sel= regulator_set_voltage_sel_regmap,
   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
   .set_suspend_mode   = max77686_ldo_set_suspend_mode,
 + .set_suspend_disable= max77686_set_suspend_disable,
 + .set_suspend_enable = max77686_enable,
  };
  
  static struct regulator_ops max77686_buck1_ops = {
 @@ -234,7 +255,8 @@ static struct regulator_ops max77686_buck1_ops = {
   .get_voltage_sel= regulator_get_voltage_sel_regmap,
   .set_voltage_sel= regulator_set_voltage_sel_regmap,
   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
 - .set_suspend_disable= max77686_buck_set_suspend_disable,
 + .set_suspend_disable= max77686_set_suspend_disable,
 + .set_suspend_enable = max77686_enable,
  };
  
  static struct regulator_ops max77686_buck_dvs_ops = {
 @@ -247,7 +269,8 @@ static struct regulator_ops max77686_buck_dvs_ops = {
   .set_voltage_sel= regulator_set_voltage_sel_regmap,
   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
   .set_ramp_delay = max77686_set_ramp_delay,
 - .set_suspend_disable= max77686_buck_set_suspend_disable,
 + .set_suspend_disable= max77686_set_suspend_disable,
 + .set_suspend_enable = max77686_enable,
  };
  
  #define regulator_desc_ldo(num)  {   
 \
 

Looks good to me.

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

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


Re: [PATCH v2 3/4] mfd/regulator: dt-bindings: max77686: Document regulators off in suspend

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 01:23 PM, Krzysztof Kozlowski wrote:
 Add information which regulators can be disabled during system suspend.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  Documentation/devicetree/bindings/mfd/max77686.txt | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
 b/Documentation/devicetree/bindings/mfd/max77686.txt
 index 678f3cf0b8f0..75fdfaf41831 100644
 --- a/Documentation/devicetree/bindings/mfd/max77686.txt
 +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
 @@ -34,6 +34,12 @@ to get matched with their hardware counterparts as follow:
   -BUCKn  :   for BUCKs, where n can lie in range 1 to 9.
   example: BUCK1, BUCK5, BUCK9.
  
 +  Regulators which can be turned off during system suspend:
 + -LDOn   :   2, 6-8, 10-12, 14-16,
 + -BUCKn  :   1-4.
 +  Use standard regulator bindings for it ('regulator-off-in-suspend').
 +
 +
  Example:
  
   max77686@09 {
 

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

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


Re: [PATCH v2 4/4] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 01:23 PM, Krzysztof Kozlowski wrote:
 Add suspend to RAM configuration for max77686 regulators. Some LDOs and
 bucks are disabled. This reduces energy consumption during S2R,
 approximately from 17 mA to 9 mA.
 
 Additionally remove old and not supported bindings:
  - regulator-mem-off
  - regulator-mem-idle
  - regulator-mem-on
 The max77686 driver does not parse them and they are not documented
 anywere.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts | 72 
 +++--
  1 file changed, 42 insertions(+), 30 deletions(-)
 

I'm not familiar with the board but the change looks good to me assuming each
regulator is doing the right thing.

I already gave you my Reviewed-by for the previous version but was not carried:

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

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


Re: [PATCH v2 1/4] regulator: max77686: Replace hard-coded opmode values with defines

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 02:22 PM, Krzysztof Kozlowski wrote:
 On wto, 2014-10-21 at 13:57 +0200, Javier Martinez Canillas wrote:
   
  +/* On/off controlled by PWRREQ */
  +#define MAX77686_OPMODE_OFF_PWRREQ0x1
 
 Minor nit: maybe this should be called MAX77802_OFF_PWRREQ (without the 
 OPMODE)?
 Since afaiu from a conceptual pov the regulators only supports two modes: 
 normal
 and low power mode.
 
 If a regulator is disabled or put in low power mode by PWRREQ on suspend, 
 then
 is not really an operating mode (the regulator output will still be normal 
 until
 suspend) but an enable pin to switch a regulator mode automatically by the 
 SoC.
 
 No problem. This is just a define for value used in register. However
 OPMODE is used in other places in that driver:
 #define MAX77686_OPMODE_SHIFT   6
 #define MAX77686_OPMODE_BUCK234_SHIFT   4
 #define MAX77686_OPMODE_MASK0x3

 So this would be a little inconsistent...

Indeed, although I think there is a difference between talking about the OPMODE
field of the regulators control register (which the shift and mask refer to)
and the semantics of the value that is written (whether is an mode or an enable
pin).

But yeah, I agree the Maxim documentation is confusing and confused me too
before Mark explained to me that only two operating modes exist for this device.

 
 
  +/*
  + * For some regulators this means:
  + *  - forcing low power mode.
  + *  - low power mode controlled by PWRREQ.
  + */
  +#define MAX77686_OPMODE_LOWPOWER  0x2
 
 Can you also add a #define MAX77686_LP_PWRREQ 0x2 and use each one when
 appropriate? That will better document when 0x2 means low power by PWRREQ
 and when it means change regulator mode to low power.
 
 Actually I made mistake in that comment. The 0x2 means force low power
 mode only for buck1-4... but there is no set_suspend_mode for these
 bucks. So this #define has only one semantic value.
 
 Also, are you sure that forcing low power mode is 0x2 and not 0x1?
 
 You're right, for other LDOs, low power mode may be forced with 0x1. For
 such regulators the max77686_set_suspend_mode() is used which does not
 set value 0x1. This means that each define has only one semantic
 meaning.
 
 I'll re-spin and fix the documentation to reflect both device
 capabilities and how the driver currently works.
 
 Thanks for pointing this.
 

You are welcome.

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


[PATCH v3 3/4] mfd/regulator: dt-bindings: max77686: Document regulators off in suspend

2014-10-21 Thread Krzysztof Kozlowski
Add information which regulators can be disabled during system suspend.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 Documentation/devicetree/bindings/mfd/max77686.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 678f3cf0b8f0..75fdfaf41831 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -34,6 +34,11 @@ to get matched with their hardware counterparts as follow:
-BUCKn  :   for BUCKs, where n can lie in range 1 to 9.
example: BUCK1, BUCK5, BUCK9.
 
+  Regulators which can be turned off during system suspend:
+   -LDOn   :   2, 6-8, 10-12, 14-16,
+   -BUCKn  :   1-4.
+  Use standard regulator bindings for it ('regulator-off-in-suspend').
+
 Example:
 
max77686@09 {
-- 
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 v3 4/4] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Krzysztof Kozlowski
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.

Additionally remove old and not supported bindings:
 - regulator-mem-off
 - regulator-mem-idle
 - regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index dd9ac66770f7..8067eb447829 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -225,7 +225,6 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo2_reg: ldo2 {
@@ -234,7 +233,9 @@
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo3_reg: ldo3 {
@@ -243,7 +244,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo4_reg: ldo4 {
@@ -252,7 +252,6 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo5_reg: ldo5 {
@@ -261,7 +260,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
-   regulator-mem-on;
};
 
ldo6_reg: ldo6 {
@@ -270,7 +268,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo7_reg: ldo7 {
@@ -279,7 +279,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
-   regulator-mem-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   };
};
 
ldo8_reg: ldo8 {
@@ -287,7 +289,9 @@
regulator-name = VMIPI_1.0V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
-   regulator-mem-off;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
};
 
ldo9_reg: ldo9 {
@@ -295,7 +299,6 @@
regulator-name = CAM_ISP_MIPI_1.2V;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
-   regulator-mem-idle;
};
 
ldo10_reg: ldo10 {
@@ -303,7 +306,9 @@
  

[PATCH v3 0/4] regulator: max77686/trats2: Disable some regulators in suspend

2014-10-21 Thread Krzysztof Kozlowski
Hi,


Changes since v2

1. Patch 1/4: Fully describe different values used for controlling
   the regulators (low power modes, enable, disable). Remove opmode
   from new defines. Suggested by Javier.
2. Patch 2/4: minor nits after changing patch 1.
3. Add Javier's reviewed-by to 2, 3 and 4 patch.
4. Patch 3/4 (changes in documentation) should be picked up by Lee
   Jones but I'm resending it anyway.

Changes since v1

1. Add patch 1/4 and 3/4.
2. Patch 2/4: Extend existing set_suspend_disable (for bucks) with
   LDO support. Implement set_suspend_enable. Suggested by Javier.
3. Patch 4/4: Add regulator suspend properties only to regulators
   actually supporting this. Other regulators, not implementing
   suspend enable/disable, will warn (VCC_1.8V_IO: No configuration).
4. Patch 4/4: In suspend enable VHSIC_1.0V and VHSIC_1.8V regulators.
   Suggested by Chanwoo Choi.


Description
===
This patchset makes use of Javier Martinez Cainllas changes [1].
It allows disabling some of the regulators during suspend to RAM.

Javier's patchset is necessary only to test it.

[1] [PATCH v3 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish
https://lkml.org/lkml/2014/10/20/545


Best regards,
Krzysztof


Krzysztof Kozlowski (4):
  regulator: max77686: Replace hard-coded opmode values with defines
  regulator: max77686: Implement suspend disable for some LDOs
  mfd/regulator: dt-bindings: max77686: Document regulators off in
suspend
  ARM: dts: exynos4412-trats: Add suspend configuration for max77686
regulators

 Documentation/devicetree/bindings/mfd/max77686.txt |  6 ++
 arch/arm/boot/dts/exynos4412-trats2.dts| 72 -
 drivers/regulator/max77686.c   | 73 ++
 3 files changed, 108 insertions(+), 43 deletions(-)

-- 
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 v3 2/4] regulator: max77686: Implement suspend disable for some LDOs

2014-10-21 Thread Krzysztof Kozlowski
Some LDOs of Maxim 77686 PMIC support disabling during system suspend
(LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
of set_suspend_mode function. In that case the mode was one of:
 - disable,
 - normal mode,
 - low power mode.
However there are no bindings for setting the mode during suspend.

Add suspend disable for LDO regulators supporting this to the existing
max77686_buck_set_suspend_disable() function. This helps reducing
energy consumption during system sleep.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/regulator/max77686.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index 3d0922051488..81f4b69adc82 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -87,18 +87,31 @@ struct max77686_data {
unsigned int opmode[MAX77686_REGULATORS];
 };
 
-/* Some BUCKS supports Normal[ON/OFF] mode during suspend */
-static int max77686_buck_set_suspend_disable(struct regulator_dev *rdev)
+/* Some BUCKs and LDOs supports Normal[ON/OFF] mode during suspend */
+static int max77686_set_suspend_disable(struct regulator_dev *rdev)
 {
unsigned int val;
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
int ret, id = rdev_get_id(rdev);
 
-   if (id == MAX77686_BUCK1)
+   switch (id) {
+   case MAX77686_BUCK1:
val = MAX77686_BUCK_OFF_PWRREQ;
-   else
-   val = MAX77686_BUCK_OFF_PWRREQ
-MAX77686_OPMODE_BUCK234_SHIFT;
+   break;
+   case MAX77686_BUCK2 ... MAX77686_BUCK4:
+   val = MAX77686_BUCK_OFF_PWRREQ  MAX77686_OPMODE_BUCK234_SHIFT;
+   break;
+   case MAX77686_LDO2:
+   case MAX77686_LDO6 ... MAX77686_LDO8:
+   case MAX77686_LDO10 ... MAX77686_LDO12:
+   case MAX77686_LDO14 ... MAX77686_LDO16:
+   val = MAX77686_LDO_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
+   break;
+   default:
+   pr_warn(%s: regulator_suspend_disable not supported\n,
+   rdev-desc-name);
+   return -EINVAL;
+   }
 
ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 rdev-desc-enable_mask, val);
@@ -180,6 +193,16 @@ static int max77686_enable(struct regulator_dev *rdev)
 {
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
 
+   /*
+* One enable function is used for LDO and bucks. Assuming
+* the same values are used for enable registers.
+*/
+   BUILD_BUG_ON(MAX77686_LDO_OFF_PWRREQ != MAX77686_BUCK_OFF_PWRREQ);
+   BUILD_BUG_ON(MAX77686_LDO_NORMAL != MAX77686_BUCK_NORMAL);
+
+   if (max77686-opmode[rdev_get_id(rdev)] == MAX77686_LDO_OFF_PWRREQ)
+   max77686-opmode[rdev_get_id(rdev)] = MAX77686_LDO_NORMAL;
+
return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
  rdev-desc-enable_mask,
  max77686-opmode[rdev_get_id(rdev)]);
@@ -232,6 +255,8 @@ static struct regulator_ops max77686_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
.set_suspend_mode   = max77686_ldo_set_suspend_mode,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 static struct regulator_ops max77686_buck1_ops = {
@@ -243,7 +268,8 @@ static struct regulator_ops max77686_buck1_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
-   .set_suspend_disable= max77686_buck_set_suspend_disable,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 static struct regulator_ops max77686_buck_dvs_ops = {
@@ -256,7 +282,8 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
.set_ramp_delay = max77686_set_ramp_delay,
-   .set_suspend_disable= max77686_buck_set_suspend_disable,
+   .set_suspend_disable= max77686_set_suspend_disable,
+   .set_suspend_enable = max77686_enable,
 };
 
 #define regulator_desc_ldo(num){   
\
-- 
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 v3 1/4] regulator: max77686: Replace hard-coded opmode values with defines

2014-10-21 Thread Krzysztof Kozlowski
Add defines for regulator operating modes which should be more readable,
especially if one does not have Maxim 77686 datasheet.

The patch does not introduce any functional change.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/regulator/max77686.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index ef1af2debbd2..3d0922051488 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -45,6 +45,25 @@
 #define MAX77686_DVS_MINUV 60
 #define MAX77686_DVS_UVSTEP12500
 
+/* Values used for configuring Buck[1234] */
+#define MAX77686_BUCK_OFF_PWRREQ   0x1
+#define MAX77686_BUCK_LOWPOWER 0x2
+#define MAX77686_BUCK_NORMAL   0x3
+
+/*
+ * Values used for configuring LDOn:
+ *  - LDO1, 3-5, 9, 13, 17-26: forcing low power mode
+ */
+#define MAX77686_LDO_LOWPOWER  0x1
+/*
+ * In the same time for LDOn:
+ *  - LDO2, 6-8, 10-12, 14-16: on/off controlled by PWRREQ
+ */
+#define MAX77686_LDO_OFF_PWRREQ0x1
+/* Low power mode controlled by PWRREQ */
+#define MAX77686_LDO_LOWPOWER_PWRREQ   0x2
+#define MAX77686_LDO_NORMAL0x3
+
 #define MAX77686_OPMODE_SHIFT  6
 #define MAX77686_OPMODE_BUCK234_SHIFT  4
 #define MAX77686_OPMODE_MASK   0x3
@@ -76,9 +95,10 @@ static int max77686_buck_set_suspend_disable(struct 
regulator_dev *rdev)
int ret, id = rdev_get_id(rdev);
 
if (id == MAX77686_BUCK1)
-   val = 0x1;
+   val = MAX77686_BUCK_OFF_PWRREQ;
else
-   val = 0x1  MAX77686_OPMODE_BUCK234_SHIFT;
+   val = MAX77686_BUCK_OFF_PWRREQ
+MAX77686_OPMODE_BUCK234_SHIFT;
 
ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
 rdev-desc-enable_mask, val);
@@ -103,10 +123,10 @@ static int max77686_set_suspend_mode(struct regulator_dev 
*rdev,
 
switch (mode) {
case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
-   val = 0x2  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_LDO_LOWPOWER_PWRREQ  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
-   val = 0x3  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_LDO_NORMAL  MAX77686_OPMODE_SHIFT;
break;
default:
pr_warn(%s: regulator_suspend_mode : 0x%x not supported\n,
@@ -133,13 +153,13 @@ static int max77686_ldo_set_suspend_mode(struct 
regulator_dev *rdev,
 
switch (mode) {
case REGULATOR_MODE_STANDBY:/* switch off */
-   val = 0x1  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_LDO_OFF_PWRREQ  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_IDLE:   /* ON in LP Mode */
-   val = 0x2  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_LDO_LOWPOWER_PWRREQ  MAX77686_OPMODE_SHIFT;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
-   val = 0x3  MAX77686_OPMODE_SHIFT;
+   val = MAX77686_LDO_NORMAL  MAX77686_OPMODE_SHIFT;
break;
default:
pr_warn(%s: regulator_suspend_mode : 0x%x not supported\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


Re: [PATCH v3 1/4] regulator: max77686: Replace hard-coded opmode values with defines

2014-10-21 Thread Javier Martinez Canillas
Hello Krzysztof,

On 10/21/2014 03:19 PM, Krzysztof Kozlowski wrote:
 Add defines for regulator operating modes which should be more readable,
 especially if one does not have Maxim 77686 datasheet.
 
 The patch does not introduce any functional change.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/regulator/max77686.c | 34 +++---
  1 file changed, 27 insertions(+), 7 deletions(-)
 

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

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


Re: [PATCH v3 3/4] mfd/regulator: dt-bindings: max77686: Document regulators off in suspend

2014-10-21 Thread Lee Jones
On Tue, 21 Oct 2014, Krzysztof Kozlowski wrote:

 Add information which regulators can be disabled during system suspend.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  Documentation/devicetree/bindings/mfd/max77686.txt | 6 ++
  1 file changed, 6 insertions(+)

This has been applied already.

 diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
 b/Documentation/devicetree/bindings/mfd/max77686.txt
 index 678f3cf0b8f0..75fdfaf41831 100644
 --- a/Documentation/devicetree/bindings/mfd/max77686.txt
 +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
 @@ -34,6 +34,11 @@ to get matched with their hardware counterparts as follow:
   -BUCKn  :   for BUCKs, where n can lie in range 1 to 9.
   example: BUCK1, BUCK5, BUCK9.
  
 +  Regulators which can be turned off during system suspend:
 + -LDOn   :   2, 6-8, 10-12, 14-16,
 + -BUCKn  :   1-4.
 +  Use standard regulator bindings for it ('regulator-off-in-suspend').
 +
  Example:
  
   max77686@09 {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-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 6/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7

2014-10-21 Thread Alim Akhtar
Hi Abhilash,

On Tue, Oct 21, 2014 at 11:13 AM, Abhilash Kesavan
a.kesa...@samsung.com wrote:
 Add nodes for 3 mmc channels, 12 i2c channels, rtc, and watchdog
 on Exynos7.

 Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
  arch/arm64/boot/dts/exynos/exynos7-espresso.dts |   41 
  arch/arm64/boot/dts/exynos/exynos7.dtsi |  256 
 +++
  2 files changed, 297 insertions(+)

 diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
 b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
 index e2c8283..d081c26 100644
 --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
 +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
 @@ -18,6 +18,8 @@

 aliases {
 serial0 = serial_2;
 +   mshc0 = mmc_0;
 +   mshc2 = mmc_2;
 };

 chosen {
 @@ -37,3 +39,42 @@
  serial_2 {
 status = okay;
  };
 +
 +rtc {
 +   status = okay;
 +};
 +
 +watchdog {
 +   status = okay;
 +};
 +
 +mmc_0 {
 +   status = okay;
 +   num-slots = 1;
 +   broken-cd;
 +   caps2-mmc-hs200-1_8v;
Please use mmc_hs200-1_8v instead.
 +   supports-highspeed;
As per synopsys-dw-mshc DT binding documentation, supports-highspeed
property is deprecated, so please use common DT binding for this,
which is cap-mmc-highspeed.
 +   non-removable;
 +   card-detect-delay = 200;
 +   clock-frequency = 8;
 +   samsung,dw-mshc-ciu-div = 3;
 +   samsung,dw-mshc-sdr-timing = 0 4;
 +   samsung,dw-mshc-ddr-timing = 0 2;
 +   pinctrl-names = default;
 +   pinctrl-0 = sd0_clk sd0_cmd sd0_qrdy sd0_bus1 sd0_bus4 
 sd0_bus8;
 +   bus-width = 8;
 +};
 +
 +mmc_2 {
 +   status = okay;
 +   num-slots = 1;
 +   supports-highspeed;
Here also common DT binding please cap-sd-highspeed
 +   card-detect-delay = 200;
 +   clock-frequency = 4;
 +   samsung,dw-mshc-ciu-div = 3;
 +   samsung,dw-mshc-sdr-timing = 2 3;
 +   samsung,dw-mshc-ddr-timing = 1 2;
 +   pinctrl-names = default;
 +   pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus1 sd2_bus4;
 +   bus-width = 4;
 +};
 diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
 b/arch/arm64/boot/dts/exynos/exynos7.dtsi
 index 6db8c78..1300ded 100644
 --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
 +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
 @@ -113,6 +113,27 @@
   dout_sclk_mfc_pll;
 };

 +   clock_top1: clock-controller@105e {
 +   compatible = samsung,exynos7-clock-top1;
 +   reg = 0x105e 0xb000;
 +   #clock-cells = 1;
 +   clocks = fin_pll, clock_topc DOUT_SCLK_BUS0_PLL,
 +clock_topc DOUT_SCLK_BUS1_PLL,
 +clock_topc DOUT_SCLK_CC_PLL,
 +clock_topc DOUT_SCLK_MFC_PLL;
 +   clock-names = fin_pll, dout_sclk_bus0_pll,
 + dout_sclk_bus1_pll, 
 dout_sclk_cc_pll,
 + dout_sclk_mfc_pll;
 +   };
 +
 +   clock_ccore: clock-controller@105b {
 +   compatible = samsung,exynos7-clock-ccore;
 +   reg = 0x105b 0xd00;
 +   #clock-cells = 1;
 +   clocks = fin_pll, clock_topc 
 DOUT_ACLK_CCORE_133;
 +   clock-names = fin_pll, dout_aclk_ccore_133;
 +   };
 +
 clock_peric0: clock-controller@1361 {
 compatible = samsung,exynos7-clock-peric0;
 reg = 0x1361 0xd00;
 @@ -143,6 +164,27 @@
 clock-names = fin_pll, dout_aclk_peris_66;
 };

 +   clock_fsys0: clock-controller@10e9 {
 +   compatible = samsung,exynos7-clock-fsys0;
 +   reg = 0x10e9 0xd00;
 +   #clock-cells = 1;
 +   clocks = fin_pll, clock_top1 
 DOUT_ACLK_FSYS0_200,
 +clock_top1 DOUT_SCLK_MMC2;
 +   clock-names = fin_pll, dout_aclk_fsys0_200,
 + dout_sclk_mmc2;
 +   };
 +
 +   clock_fsys1: clock-controller@156e {
 +   compatible = samsung,exynos7-clock-fsys1;
 +   reg = 0x156e 0xd00;
 +   #clock-cells = 1;
 +   clocks = fin_pll, clock_top1 
 DOUT_ACLK_FSYS1_200,
 +clock_top1 DOUT_SCLK_MMC0,
 +clock_top1 DOUT_SCLK_MMC1;
 +   clock-names = fin_pll, dout_aclk_fsys1_200,
 + dout_sclk_mmc0, dout_sclk_mmc1;
 +   };
 

Re: [PATCH v2 6/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7

2014-10-21 Thread Tomasz Figa
On 21.10.2014 15:52, Alim Akhtar wrote:
 +mmc_0 {
 +   status = okay;
 +   num-slots = 1;
 +   broken-cd;
 +   caps2-mmc-hs200-1_8v;
 Please use mmc_hs200-1_8v instead.

I guess you mean mmc-hs200-1_8v (with a hyphen between mmc and hs200).

 +   supports-highspeed;
 As per synopsys-dw-mshc DT binding documentation, supports-highspeed
 property is deprecated, so please use common DT binding for this,
 which is cap-mmc-highspeed.
 +   non-removable;
 +   card-detect-delay = 200;
 +   clock-frequency = 8;
 +   samsung,dw-mshc-ciu-div = 3;
 +   samsung,dw-mshc-sdr-timing = 0 4;
 +   samsung,dw-mshc-ddr-timing = 0 2;
 +   pinctrl-names = default;
 +   pinctrl-0 = sd0_clk sd0_cmd sd0_qrdy sd0_bus1 sd0_bus4 
 sd0_bus8;
 +   bus-width = 8;
 +};
 +
 +mmc_2 {
 +   status = okay;
 +   num-slots = 1;
 +   supports-highspeed;
 Here also common DT binding please cap-sd-highspeed

Above you suggest cap-mmc-highspeed to replace the same deprecated
property, but here cap-sd-highspeed. What is the rationale behind
using only one particular new property and not both for both controllers?

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


Re: [PATCH] arm64: dts: exynos7: add support for cpuidle core power down

2014-10-21 Thread Lorenzo Pieralisi
On Fri, Oct 17, 2014 at 10:43:59AM +0100, Chander Kashyap wrote:
 Hi Lorenzo,
 
 On Wed, Oct 15, 2014 at 2:30 PM, Lorenzo Pieralisi
 lorenzo.pieral...@arm.com wrote:
  On Wed, Oct 15, 2014 at 07:35:20AM +0100, Chander Kashyap wrote:
  Exynos7 has core power down state where cores can be powered off 
  independently.
  This patch adds support for this state.
 
  Please tell us more about the idle-state values you are adding, in 
  particular
  entry, exit latencies and min-residency values.
 
 Entry latency: This value is calculated as follows:
 
 On entry to arm64_enter_idle_state:
 timestamp1 = ktimeget();
 
 after returning from cpu_suspend()
 
 timestamp2 = ktimeget();
 
 latency = timestamp2-timestamp1;
 
 Cpu is not allowed to enter core powerdown by skipping wfi instruction at end.
This may not be the worst case (because the worst case depends on the state
of the cache in the core unless the latency is power down command dominated,
so at the cost of being pedantic, please make sure that's what you are
measuring and document it in the commit log).

 Hence calculated time contains entry time + failure exit time.
 
 
 Regarding
 exit-latency and target-residency time, got these values from HW team.
 
 I am using these as initial values and I will be working on optimizing
 these values with further experiments.
 If you could suggest any formal method of deriving these values, i can
 try those methods as well.

Well, you have to set the core/cluster in worst case scenario and
compute the break-even residency against wfi (since you have two
states); it certainly has a dependency on PSCI implementation too among
other things.

exit-latency should come from HW design even though there is a cache
refill factor to be considered too and should be factored in.

Lorenzo

 
 
  Signed-off-by: Chander Kashyap k.chan...@samsung.com
  ---
  This patch has following dependencies:
- [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
- [PATCH v9 0/8] ARM generic idle states

  http://permalink.gmane.org/gmane.linux.power-management.general/49224
 
  Series above was merged, so dependency is stale.
 
 i will remove this
 
 
   arch/arm64/boot/dts/exynos/exynos7.dtsi |   18 ++
   1 file changed, 18 insertions(+)dont
 
  diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
  b/arch/arm64/boot/dts/exynos/exynos7.dtsi
  index ce221ac..8e0a034 100644
  --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
  +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
  @@ -36,6 +36,7 @@
device_type = cpu;
compatible = arm,cortex-a57, arm,armv8;
enable-method = psci;
  + cpu-idle-states = CPU_SLEEP;
 
  I would add cpu-idle-states phandle after the reg property, as defined
  in the idle states bindings.
 
 i will move this after reg property.
 
 
reg = 0x0;
};
 
  @@ -43,6 +44,7 @@
device_type = cpu;
compatible = arm,cortex-a57, arm,armv8;
enable-method = psci;
  + cpu-idle-states = CPU_SLEEP;
reg = 0x1;
};
 
  @@ -50,6 +52,7 @@
device_type = cpu;
compatible = arm,cortex-a57, arm,armv8;
enable-method = psci;
  + cpu-idle-states = CPU_SLEEP;
reg = 0x2;
};
 
  @@ -57,8 +60,23 @@
device_type = cpu;
compatible = arm,cortex-a57, arm,armv8;
enable-method = psci;
  + cpu-idle-states = CPU_SLEEP;
reg = 0x3;
};
  +
  + idle-states {
  + entry-method = arm,psci;
  +
  + CPU_SLEEP: cpu-sleep {
  + compatible = arm,idle-state;
  + local-timer-stop;
  + arm,psci-suspend-param = 0x001;
  + entry-latency-us = 20;
  + exit-latency-us = 150;
  + min-residency-us = 2100;
  + status = enabled;
 
  status ? This is not a documented property. If you need it please explain
  why, define its bindings and we can see how to accommodate it.
 
 I will add okay for status property. As per the bindings posted by you.
 
 regards,
 
  Thank you,
  Lorenzo
 
  + };
  + };
};
 
psci {
  --
  1.7.9.5
 
 
 
 
  ___
  linux-arm-kernel mailing list
  linux-arm-ker...@lists.infradead.org
  http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 --
 To unsubscribe from this list: send 

Re: [PATCH v2 6/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7

2014-10-21 Thread Alim Akhtar
Hi Tomasz,

On Tue, Oct 21, 2014 at 7:30 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 21.10.2014 15:52, Alim Akhtar wrote:
 +mmc_0 {
 +   status = okay;
 +   num-slots = 1;
 +   broken-cd;
 +   caps2-mmc-hs200-1_8v;
 Please use mmc_hs200-1_8v instead.

 I guess you mean mmc-hs200-1_8v (with a hyphen between mmc and hs200).

Yes, right, that was a typo. Thanks.
 +   supports-highspeed;
 As per synopsys-dw-mshc DT binding documentation, supports-highspeed
 property is deprecated, so please use common DT binding for this,
 which is cap-mmc-highspeed.
 +   non-removable;
 +   card-detect-delay = 200;
 +   clock-frequency = 8;
 +   samsung,dw-mshc-ciu-div = 3;
 +   samsung,dw-mshc-sdr-timing = 0 4;
 +   samsung,dw-mshc-ddr-timing = 0 2;
 +   pinctrl-names = default;
 +   pinctrl-0 = sd0_clk sd0_cmd sd0_qrdy sd0_bus1 sd0_bus4 
 sd0_bus8;
 +   bus-width = 8;
 +};
 +
 +mmc_2 {
 +   status = okay;
 +   num-slots = 1;
 +   supports-highspeed;
 Here also common DT binding please cap-sd-highspeed

 Above you suggest cap-mmc-highspeed to replace the same deprecated
 property, but here cap-sd-highspeed. What is the rationale behind
 using only one particular new property and not both for both controllers?

Well, on this particular board dw_mmc channels are dedicated to use
only one kind of card. e.g. mmc_0 is for eMMC and which is
non-removable and mmc_2 is for SD cards. Although controller supports
both the properties on all channel on this SoC.

 Best regards,
 Tomasz



-- 
Regards,
Alim
--
To unsubscribe from this list: send the line unsubscribe linux-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] clocksource: exynos_mct: fix exynos4_mct_write

2014-10-21 Thread Tobias Jakobi
EXYNOS4_MCT_L_MASK is defined as 0xff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.

Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.

Fix this by putting the inversion at the correct position again.

Reported-by: GP Orcullo kinsama...@gmail.com
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
 drivers/clocksource/exynos_mct.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 9403061..83564c9 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -97,8 +97,8 @@ static void exynos4_mct_write(unsigned int value, unsigned 
long offset)
writel_relaxed(value, reg_base + offset);
 
if (likely(offset = EXYNOS4_MCT_L_BASE(0))) {
-   stat_addr = (offset  ~EXYNOS4_MCT_L_MASK) + MCT_L_WSTAT_OFFSET;
-   switch (offset  EXYNOS4_MCT_L_MASK) {
+   stat_addr = (offset  EXYNOS4_MCT_L_MASK) + MCT_L_WSTAT_OFFSET;
+   switch (offset  ~EXYNOS4_MCT_L_MASK) {
case MCT_L_TCON_OFFSET:
mask = 1  3;  /* L_TCON write status */
break;
-- 
2.0.4

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


Re: [PATCH v3 4/4] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators

2014-10-21 Thread Chanwoo Choi
Hi Krzysztof,

On 10/21/2014 10:19 PM, Krzysztof Kozlowski wrote:
 Add suspend to RAM configuration for max77686 regulators. Some LDOs and
 bucks are disabled. This reduces energy consumption during S2R,
 approximately from 17 mA to 9 mA.
 
 Additionally remove old and not supported bindings:
  - regulator-mem-off
  - regulator-mem-idle
  - regulator-mem-on
 The max77686 driver does not parse them and they are not documented
 anywere.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts | 72 
 +++--
  1 file changed, 42 insertions(+), 30 deletions(-)

Looks good to me.

Reviewed-by: Chanwoo Choi cw00.c...@samsung.com

Thanks,
Chanwoo Choi

 
 diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
 b/arch/arm/boot/dts/exynos4412-trats2.dts
 index dd9ac66770f7..8067eb447829 100644
 --- a/arch/arm/boot/dts/exynos4412-trats2.dts
 +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
 @@ -225,7 +225,6 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
   };
  
   ldo2_reg: ldo2 {
 @@ -234,7 +233,9 @@
   regulator-min-microvolt = 120;
   regulator-max-microvolt = 120;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo3_reg: ldo3 {
 @@ -243,7 +244,6 @@
   regulator-min-microvolt = 180;
   regulator-max-microvolt = 180;
   regulator-always-on;
 - regulator-mem-on;
   };
  
   ldo4_reg: ldo4 {
 @@ -252,7 +252,6 @@
   regulator-min-microvolt = 280;
   regulator-max-microvolt = 280;
   regulator-always-on;
 - regulator-mem-on;
   };
  
   ldo5_reg: ldo5 {
 @@ -261,7 +260,6 @@
   regulator-min-microvolt = 180;
   regulator-max-microvolt = 180;
   regulator-always-on;
 - regulator-mem-on;
   };
  
   ldo6_reg: ldo6 {
 @@ -270,7 +268,9 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo7_reg: ldo7 {
 @@ -279,7 +279,9 @@
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
   regulator-always-on;
 - regulator-mem-on;
 + regulator-state-mem {
 + regulator-on-in-suspend;
 + };
   };
  
   ldo8_reg: ldo8 {
 @@ -287,7 +289,9 @@
   regulator-name = VMIPI_1.0V;
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 100;
 - regulator-mem-off;
 + regulator-state-mem {
 + regulator-off-in-suspend;
 + };
   };
  
   ldo9_reg: ldo9 {
 @@ -295,7 +299,6 @@
   regulator-name = CAM_ISP_MIPI_1.2V;
   regulator-min-microvolt = 120;
   regulator-max-microvolt = 120;
 -