Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support

2014-10-09 Thread Krzysztof Kozlowski
On śro, 2014-10-08 at 15:44 +0200, Javier Martinez Canillas wrote:
 Regulators can run on different operating modes (opmodes). This allows
 systems to choose the most efficient opmode for each regulator. The
 regulator core defines a set of generic modes so each system can define
 the opmode in these generic terms and drivers are responsible to map the
 generic modes to the ones supported by each hardware according to their
 data-sheet.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  Documentation/devicetree/bindings/regulator/regulator.txt | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
 b/Documentation/devicetree/bindings/regulator/regulator.txt
 index ccba90b..a9d6767 100644
 --- a/Documentation/devicetree/bindings/regulator/regulator.txt
 +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
 @@ -23,6 +23,14 @@ Optional properties:
state among following defined suspend states:
3: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
4: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
 +- regulator-initial-mode: initial regulator operating mode. One of following:
 + 1: REGULATOR_MODE_FAST- Regulator can handle fast changes.
 + 2: REGULATOR_MODE_NORMAL  - Normal regulator power supply mode.
 + 4: REGULATOR_MODE_IDLE- Regulator runs in a more efficient mode.
 + 8: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode.
 +  modes are defined in the dt-bindings/regulator/regulator.h header and can 
 be
 +  used in device tree sources files. If no mode is defined, then the OS will 
 not
 +  manage the operating mode and the HW default values will be used instead.
  - regulator-state-mem sub-root node for Suspend-to-RAM mode
: suspend to memory, the device goes to sleep, but all data stored in 
 memory,
only some external interrupt can wake the device.

I agree with the need and the idea of generic bindings for operating
modes for regulators. At least for Exynos-based boards the PMICs have
quite similar opmodes.

However the regulator mode from consumer.h (and in above doc) does not
match well with these opmodes. Example is yours patch 4/5:
 - idle (more efficient mode) maps to low power mode in suspend,
 - standby (the most efficient mode) maps to OFF in suspend.

Actually we are not enable efficient modes but we configure how the
regulator will behave when AP says - I'm suspending.


Another issue: is initial_state not doing all this already?

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] drm/exynos: fix vblank handling during dpms off

2014-10-09 Thread Russell King - ARM Linux
On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
 But there might be another issue, which is that calls to  
 drm_vblank_get() will return -EINVAL if invoked between drm_blank_off  
 and drm_blank_on. Is this really the desired behavior? Can it at least  
 happen? If so, how are drivers supposed to react to this situation?

I've not yet seen the commit which causes this problem, but I hope
that drm_wait_vblank() isn't affected by this.  In current mainline,
drm_vblank_get() is used inside drm_wait_vblank(), which is called as
a result of userspace calling DRM_IOCTL_WAIT_VBLANK.

So, what is the effect of this change on user applications making use
of the vblank wait ioctl - and is that change intended?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-09 Thread Javier Martinez Canillas
Hello Abhilash,

On Thu, Oct 9, 2014 at 4:37 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Kevin,

 On Thu, Oct 9, 2014 at 4:49 AM, Kevin Hilman khil...@kernel.org wrote:
 Vikas Sajjan vikas.saj...@samsung.com writes:

 [...]

 Tested on Kukjin Kim's tree, for-next branch +
 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html
 2] 
 https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html
 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK

 on Exynos5420 based chromebook (peach-pit board)

 Below procedures were followed to test S2R:
 Procedure A:
   1. make multi_v7_defconfig
   2  enable MCPM for 5420
   3. enable S3C RTC
   5. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
 /sys/power/state
 Procedure B:
   1. make exynos_defconfig
   4. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
 /sys/power/state

 I went tried to this on exynos5800-peach-pi and found first that
 exynos_defonfig is missing the MAX77802 kconfig options for the RTC
 source clock:

 CONFIG_REGULATOR_MAX77802=y
 CONFIG_COMMON_CLK_MAX77802=y

 I am using exynos_defconfig (no changes) with the internal SoC RTC
 which is enabled by default. I did not enable the MAX77802 RTC.

That is because you probably are using kukjin's for-next branch as a
base but I had the same issue when testing s2r on linux-next.

The problem is that linux-next contains commit 546b117fdf17 (rtc:
s3c: add support for RTC of Exynos3250 SoC) that added a required
rtc_src DT property for the Samsung's S3C RTC that is used to
specify the source clock XrtcXTI.

On Peach boards, the S3C source clock is the max77802 32kHZ AP clock
so I fixed that with commit 8bd43b6 (ARM: dts: Add rtc_src clk for
s3c-rtc on exynos Peach boards) but didn't send a patch to enable the
max77802 subdevices on exynos_defconfig.

I'll post a patch to enable those config options today and maybe they
can be considered as -rc material.


 With those, rtc0 then comes up, but isn't waking from suspend.  However,
 writing something to rtc0/wakealarm does result in /proc/interrupts
 having an interrupt for the RTC, it's just not waking the system.

 Anyone else tried this on 5800/peach-pi?

 I have tested this on a Peach-Pi and the system is resuming fine. The
 patches applied on kgene's for-next branch along with the
 aclk200_disp1 fix are:
 http://lkml.org/lkml/2014/9/30/156
 https://lkml.org/lkml/2014/10/6/89
 http://www.spinics.net/lists/arm-kernel/msg368207.html
 http://www.spinics.net/lists/linux-samsung-soc/msg37647.html


Kevin, I didn't test it on 5800 peach pi but I did test it on 5420
peach pit and as Abhilash said, I also needed Vikas patch [0] to flag
the aclk200_disp1 and aclk300_disp1 clocks as CLK_IGNORE_UNUSED to
prevent the ccf to disable them. With that patch Suspend-to-Ram worked
for me and resuming using both the internal S3C RTC and the max77802
RTC.

Also I tested the pm_tests and all of them passed on my peach pit.

On peach pi you shouldn't need the clock patch AFAIU if you enable the
needed kconfig options to have display working since those clocks are
used by the display controller so they won't be disabled due unused.

Hope it helps,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg367197.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: fix vblank handling during dpms off

2014-10-09 Thread Thierry Reding
On Thu, Oct 09, 2014 at 09:52:58AM +0100, Russell King - ARM Linux wrote:
 On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
  But there might be another issue, which is that calls to  
  drm_vblank_get() will return -EINVAL if invoked between drm_blank_off  
  and drm_blank_on. Is this really the desired behavior? Can it at least  
  happen? If so, how are drivers supposed to react to this situation?
 
 I've not yet seen the commit which causes this problem, but I hope
 that drm_wait_vblank() isn't affected by this.  In current mainline,
 drm_vblank_get() is used inside drm_wait_vblank(), which is called as
 a result of userspace calling DRM_IOCTL_WAIT_VBLANK.
 
 So, what is the effect of this change on user applications making use
 of the vblank wait ioctl - and is that change intended?

There's no effect on user applications if the driver behaves properly.
As far as I can tell, every driver that calls drm_vblank_off() but not
drm_vblank_on() will break. You can easily test this by running libdrm
modetest -s ... -v, which instead of toggling between the test pattern
and an all-gray framebuffer will switch to the gray one once and then
hang.

I guess that was probably not intended, but according to the new rules
all these drivers have now become buggy. So before merging this patch I
think we need to fix existing drivers to avoid regressions.

Thierry


pgpbuEXgiTUPk.pgp
Description: PGP signature


Re: [PATCH] drm/exynos: fix vblank handling during dpms off

2014-10-09 Thread Alexandre Courbot
On Thu, Oct 9, 2014 at 7:08 PM, Thierry Reding tred...@nvidia.com wrote:
 On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
 On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
 Hi,
 
 +CC possible victims
 
 On 10/02/2014 12:52 PM, Inki Dae wrote:
 On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
 Hi Andrzej,
 
 On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
 The patch disables vblanks during dpms off only if pagefilp has
 not been finished. It also replaces drm_vblank_off with 
 drm_crtc_vblank_put.
 It fixes issue with page_flip ioctl not being able to acquire vblank 
 counter.
 This problem isn't related with pageflip, it just causes from
 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
 drm_vblank_get() after drm_vblank_off()).
 
 We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
 after the commit .
 
 This patch should break also other drivers, it seems at least following
 drms could be affected:
 armada, sti, tegra.

 Indeed we (tegra) have just been hit by this. The problem seems to come from
 the fact that we have been using drm_vblank_pre_modeset,
 drm_vblank_post_modeset and drm_vblank_off conjointly. All these functions
 depend on the value of vblank-inmodeset, and 7ffd7a68511 increases the
 vblank reference counter only in drm_vblank_off, which can result in the
 acquired reference never being released.

 The following seems to fix this for Tegra, by stopping using
 drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:

 diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
 index b08df07cad47..3955d81236d0 100644
 --- a/drivers/gpu/drm/tegra/dc.c
 +++ b/drivers/gpu/drm/tegra/dc.c
 @@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {

  static void tegra_crtc_disable(struct drm_crtc *crtc)
  {
 -   struct tegra_dc *dc = to_tegra_dc(crtc);
 struct drm_device *drm = crtc-dev;
 struct drm_plane *plane;

 @@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
 }
 }

 -   drm_vblank_off(drm, dc-pipe);
 +   drm_crtc_vblank_off(crtc);
  }

  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
 @@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
 u32 value;
 int err;

 -   drm_vblank_pre_modeset(crtc-dev, dc-pipe);
 +   drm_crtc_vblank_off(crtc);

 err = tegra_crtc_setup_clk(crtc, mode);
 if (err) {
 @@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
 value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
 tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);

 -   drm_vblank_post_modeset(crtc-dev, dc-pipe);
 +   drm_crtc_vblank_on(crtc);
  }

  static void tegra_crtc_load_lut(struct drm_crtc *crtc)

 Thierry, does this look ok to you?

 Yes, that looks like almost the same patch that I sent out yesterday.
 The difference is that I didn't replace the drm_vblank_pre_modeset()
 call with drm_vblank_off() like you did, but rather just dropped the
 former.

 I /think/ your version is more correct in that regard.

Feel free to take that extra line in your patch then. ;)


 Thierry

 But there might be another issue, which is that calls to drm_vblank_get()
 will return -EINVAL if invoked between drm_blank_off and drm_blank_on. Is
 this really the desired behavior? Can it at least happen? If so, how are
 drivers supposed to react to this situation?

 It shouldn't happen. If drm_vblank_off() and drm_vblank_on() are called
 around a modeset they should never conflict with drm_vblank_get(), at
 least on Tegra, because the modeset and page-flip IOCTLs will be
 serialized.

Ok, that's good. I was just wondering whether this case has been thought of.

Actually, and seeing how drm_vblank_pre/post_modeset() have become
useless (if not harmful), maybe it would be a good idea to come with a
fixup patch that gets rid of them altogether and make their callers
invoke drm_vblank_off/on() instead?
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

2014-10-09 Thread Vivek Gautam
Ajay,


On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar ajayn...@gmail.com wrote:
 Hi,

 On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
 These patches are based on 'for-next' branch of kgene's linux-samsung tree.

 Refactoring the exynos-dp-video phy to use pmu-system-controller handle
 and access the register using mfd-syscon and regmap.
 Simultaneously, removing the support for older dptx-phy, since it's obsolete
 now and noone uses it.

 Vivek Gautam (3):
   phy: exynos-dp-video: Use syscon support to control pmu register
   drm/exynos: dp: Remove support for unused dptx-phy
   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
  drivers/phy/phy-exynos-dp-video.c  |   76 
 ++--
  6 files changed, 75 insertions(+), 74 deletions(-)

 --
 1.7.10.4

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

 I have tested this patchset on exynos5800-peach-pi, and I can see DP
 display with the above patches.

we expect Tested-by, if you have tested please give the same.


-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

2014-10-09 Thread Ajay kumar
On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Ajay,


 On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar ajayn...@gmail.com wrote:
 Hi,

 On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
 These patches are based on 'for-next' branch of kgene's linux-samsung tree.

 Refactoring the exynos-dp-video phy to use pmu-system-controller handle
 and access the register using mfd-syscon and regmap.
 Simultaneously, removing the support for older dptx-phy, since it's obsolete
 now and noone uses it.

 Vivek Gautam (3):
   phy: exynos-dp-video: Use syscon support to control pmu register
   drm/exynos: dp: Remove support for unused dptx-phy
   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
  drivers/phy/phy-exynos-dp-video.c  |   76 
 ++--
  6 files changed, 75 insertions(+), 74 deletions(-)

 --
 1.7.10.4

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

 I have tested this patchset on exynos5800-peach-pi, and I can see DP
 display with the above patches.

 we expect Tested-by, if you have tested please give the same.
Tested-by: Ajay Kumar ajaykumar...@samsung.com

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


[PATCH 3/3] ARM: multi_v7_defconfig: Enable clock and RTC driver for S2M and S5M

2014-10-09 Thread Krzysztof Kozlowski
The multi_v7 config already enables MFD and regulators drivers for
Samsung's S2MPS11/S2MPS14 and S5M8767. Enable also drivers for the rest
of these PMICs features: clock and RTC.

These PMICs are used on Arndale (Exynos 5250 and 5420) and Origen
(Exynos 4412) evaluation boards, Google Spring, Samsung Gear2 (Exynos
3250) and some other phones based on Exynos5.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 3d37e9d2914f..1a60a69f26ad 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -391,6 +391,7 @@ CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_SUNXI=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_RTC_DRV_TEGRA=y
+CONFIG_RTC_DRV_S5M=y
 CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_MV_XOR=y
@@ -414,6 +415,7 @@ CONFIG_NVEC_POWER=y
 CONFIG_NVEC_PAZ00=y
 CONFIG_QCOM_GSBI=y
 CONFIG_COMMON_CLK_QCOM=y
+CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_MSM_GCC_8660=y
 CONFIG_MSM_MMCC_8960=y
 CONFIG_MSM_MMCC_8974=y
-- 
1.9.1

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


[PATCH 2/3] ARM: multi_v7_defconfig: Enable Maxim 77836 for Gear2 board

2014-10-09 Thread Krzysztof Kozlowski
Enable all Maxim 14577 drivers and Maxim 17040 fuel gauge driver to
support the Maxim 77836 PMIC present on Samsung Rinato board (Gear 2).

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/configs/multi_v7_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 9702b140ae04..3d37e9d2914f 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -247,6 +247,8 @@ CONFIG_GPIO_PALMAS=y
 CONFIG_GPIO_TPS6586X=y
 CONFIG_GPIO_TPS65910=y
 CONFIG_BATTERY_SBS=y
+CONFIG_BATTERY_MAX17040=y
+CONFIG_CHARGER_MAX14577=y
 CONFIG_CHARGER_TPS65090=y
 CONFIG_POWER_RESET_AS3722=y
 CONFIG_POWER_RESET_GPIO=y
@@ -266,6 +268,7 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_MFD_MAX14577=y
 CONFIG_MFD_MAX8907=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_STMPE=y
@@ -277,6 +280,7 @@ CONFIG_REGULATOR_AB8500=y
 CONFIG_REGULATOR_AS3722=y
 CONFIG_REGULATOR_BCM590XX=y
 CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_MAX14577=y
 CONFIG_REGULATOR_MAX8907=y
 CONFIG_REGULATOR_PALMAS=y
 CONFIG_REGULATOR_S2MPS11=y
@@ -415,6 +419,8 @@ CONFIG_MSM_MMCC_8960=y
 CONFIG_MSM_MMCC_8974=y
 CONFIG_TEGRA_IOMMU_GART=y
 CONFIG_TEGRA_IOMMU_SMMU=y
+CONFIG_EXTCON=y
+CONFIG_EXTCON_MAX14577=y
 CONFIG_MEMORY=y
 CONFIG_IIO=y
 CONFIG_XILINX_XADC=y
-- 
1.9.1

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


[PATCH 1/3] ARM: exynos_defconfig: Enable Maxim 77836 for Gear2 board

2014-10-09 Thread Krzysztof Kozlowski
Enable all Maxim 14577 drivers and Maxim 17040 fuel gauge driver to
support the Maxim 77836 PMIC present on Samsung Rinato board (Gear 2).

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

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index b14d8c3f7e12..ce600b654297 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -78,6 +78,8 @@ CONFIG_SPI_S3C64XX=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_BATTERY_SBS=y
+CONFIG_BATTERY_MAX17040=y
+CONFIG_CHARGER_MAX14577=y
 CONFIG_CHARGER_TPS65090=y
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
@@ -88,6 +90,7 @@ CONFIG_S3C2410_WATCHDOG=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_MFD_MAX14577=y
 CONFIG_MFD_MAX77686=y
 CONFIG_MFD_MAX77693=y
 CONFIG_MFD_MAX8997=y
@@ -95,6 +98,7 @@ CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_TPS65090=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_MAX14577=y
 CONFIG_REGULATOR_MAX8997=y
 CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_MAX77693=y
@@ -140,6 +144,8 @@ CONFIG_PL330_DMA=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_EXYNOS_IOMMU=y
+CONFIG_EXTCON=y
+CONFIG_EXTCON_MAX14577=y
 CONFIG_IIO=y
 CONFIG_EXYNOS_ADC=y
 CONFIG_PWM=y
-- 
1.9.1

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


Re: [PATCH] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board

2014-10-09 Thread Arnd Bergmann
On Thursday 09 October 2014 10:46:59 Ulf Hansson wrote:
 On 8 October 2014 20:28, Arnd Bergmann a...@arndb.de wrote:
  On Wednesday 08 October 2014 08:29:16 Doug Anderson wrote:
 
  On Wed, Oct 8, 2014 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote:
   Why does it cause a regression though? Does this mean you are breaking
   any boot with an old DT file and a new kernel? That would be very
   bad, the driver is supposed to keep working with an existing dtb.
 
  The old dts file specified completely the wrong regulator.  It
  happened that the old code didn't really care, but when the code was
  fixed to care then things broke.  If we need to keep old dts files
  working then the most sensible place to do it would be in a fixup old
  broken device trees stage somewhere in kernel boot.
 
  Ok, got it. I guess it's better to apply this one first then.
 
  Arnd
 
 Thanks for your comments Arnd! I have applied this once to my mmc tree
 now. Please tell me soon if you want to carry this through arm-soc
 instead, thus I can drop it.

No, please take it yourself, Linus has already taken the arm-soc pull
requests.

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


[PATCH v5 0/6] Add initial support for pinctrl on Exynos7

2014-10-09 Thread Abhilash Kesavan
Changes since v4:
- Rebased over Tomasz Figa's pinctrl clean-up patches[1]

Changes since v3:
- Changed variable name from exynos_wkup_irq_chip to irq_chip
- Added acked-by tag from Tomasz Figa

Changes since v2:
- Added a .irq_chip field to the samsung_pin_bank struct
- Consolidated the wakeup and gpio irqd_ops

Changes since v1:
- Marked the newly created irq_chip instances as __initdata
- Used kmemdup to keep a copy of the irq_chip
- Change the pinctrl name from sd0_rdqs to sd0_ds as per UM
- Moved the pinctrl enablement for exynos7 into a separate patch
- Added tested-by and reviewed-by tags from Thomas Abraham

This series has been tested on linux-next (20141008)
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/ with
the following dependencies and [1].
 
a) Samsung Serial symbol clean-up for exynos7 serial driver enablement (v2)
   http://www.spinics.net/lists/arm-kernel/msg366947.html
   http://www.spinics.net/lists/arm-kernel/msg366948.html
b) dts, kbuild: Implement support for dtb vendor subdirs patchset - rebased
   http://comments.gmane.org/gmane.linux.kbuild.devel/12131
c) arch: arm64: enable support for Samsung Exynos7 SoC patchset (v5) - rebased
   http://www.spinics.net/lists/arm-kernel/msg364014.html

[1] https://lkml.org/lkml/2014/10/2/476

Abhilash Kesavan (3):
  pinctrl: exynos: Generalize the eint16_31 demux code
  pinctrl: exynos: Consolidate irq domain callbacks
  pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

Naveen Krishna Ch (3):
  pinctrl: exynos: Add initial driver data for Exynos7
  arm64: dts: Add initial pinctrl support to EXYNOS7
  arm64: exynos: Enable pinctrl support for Exynos7

 .../bindings/pinctrl/samsung-pinctrl.txt   |3 +
 arch/arm64/Kconfig |2 +
 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi|  560 
 arch/arm64/boot/dts/exynos/exynos7.dtsi|   66 +++
 drivers/pinctrl/samsung/pinctrl-exynos.c   |  188 +--
 drivers/pinctrl/samsung/pinctrl-exynos.h   |3 +
 drivers/pinctrl/samsung/pinctrl-samsung.c  |2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h  |3 +
 8 files changed, 791 insertions(+), 36 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi

-- 
1.7.9.5

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


[PATCH v5 1/6] pinctrl: exynos: Generalize the eint16_31 demux code

2014-10-09 Thread Abhilash Kesavan
The function exynos_irq_demux_eint16_31 uses pre-defined offsets for external
interrupt pending status and mask registers. So this function is not extensible
for Exynos7 SoC which has these registers at different offsets. Generalize
the exynos_irq_demux_eint16_31 function by using the pending/mask register
offset values from the exynos_irq_chip structure. This is done by adding a
irq_chip field to the samsung_pin_bank struct.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  |   14 ++
 drivers/pinctrl/samsung/pinctrl-samsung.h |2 ++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 6190106..0cca117 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -260,7 +260,7 @@ static int exynos_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
struct samsung_pin_bank *b = h-host_data;
 
irq_set_chip_data(virq, b);
-   irq_set_chip_and_handler(virq, exynos_gpio_irq_chip.chip,
+   irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
set_irq_flags(virq, IRQF_VALID);
return 0;
@@ -343,6 +343,8 @@ static int exynos_eint_gpio_init(struct 
samsung_pinctrl_drv_data *d)
ret = -ENOMEM;
goto err_domains;
}
+
+   bank-irq_chip = exynos_gpio_irq_chip;
}
 
return 0;
@@ -444,9 +446,9 @@ static void exynos_irq_demux_eint16_31(unsigned int irq, 
struct irq_desc *desc)
 
for (i = 0; i  eintd-nr_banks; ++i) {
struct samsung_pin_bank *b = eintd-banks[i];
-   pend = readl(d-virt_base + EXYNOS_WKUP_EPEND_OFFSET
+   pend = readl(d-virt_base + b-irq_chip-eint_pend
+ b-eint_offset);
-   mask = readl(d-virt_base + EXYNOS_WKUP_EMASK_OFFSET
+   mask = readl(d-virt_base + b-irq_chip-eint_mask
+ b-eint_offset);
exynos_irq_demux_eint(pend  ~mask, b-irq_domain);
}
@@ -457,7 +459,9 @@ static void exynos_irq_demux_eint16_31(unsigned int irq, 
struct irq_desc *desc)
 static int exynos_wkup_irq_map(struct irq_domain *h, unsigned int virq,
irq_hw_number_t hw)
 {
-   irq_set_chip_and_handler(virq, exynos_wkup_irq_chip.chip,
+   struct samsung_pin_bank *b = h-host_data;
+
+   irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
irq_set_chip_data(virq, h-host_data);
set_irq_flags(virq, IRQF_VALID);
@@ -509,6 +513,8 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
return -ENXIO;
}
 
+   bank-irq_chip = exynos_wkup_irq_chip;
+
if (!of_find_property(bank-of_node, interrupts, NULL)) {
bank-eint_type = EINT_TYPE_WKUP_MUX;
++muxed_banks;
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h 
b/drivers/pinctrl/samsung/pinctrl-samsung.h
index ec43b7d..3076b8b 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -151,6 +151,7 @@ struct samsung_pin_bank_data {
  * @irq_domain: IRQ domain of the bank.
  * @gpio_chip: GPIO chip of the bank.
  * @grange: linux gpio pin range supported by this bank.
+ * @irq_chip: link to irq chip for external gpio and wakeup interrupts.
  * @slock: spinlock protecting bank registers
  * @pm_save: saved register values during suspend
  */
@@ -171,6 +172,7 @@ struct samsung_pin_bank {
struct irq_domain *irq_domain;
struct gpio_chip gpio_chip;
struct pinctrl_gpio_range grange;
+   struct exynos_irq_chip *irq_chip;
spinlock_t slock;
 
u32 pm_save[PINCFG_TYPE_NUM + 1]; /* +1 to handle double CON registers*/
-- 
1.7.9.5

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


[PATCH v5 2/6] pinctrl: exynos: Consolidate irq domain callbacks

2014-10-09 Thread Abhilash Kesavan
Adding a irq_chip field to the samsung_pin_bank struct helps in
consolidating the irq domain callbacks for external gpio and wakeup
interrupt controllers. The exynos_wkup_irqd_ops and exynos_gpio_irqd_ops
have now been merged into a single exynos_eint_irqd_ops.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 drivers/pinctrl/samsung/pinctrl-exynos.c |   32 ++
 1 file changed, 6 insertions(+), 26 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0cca117..f7ac9c7 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -254,7 +254,7 @@ static struct exynos_irq_chip exynos_gpio_irq_chip = {
.eint_pend = EXYNOS_GPIO_EPEND_OFFSET,
 };
 
-static int exynos_gpio_irq_map(struct irq_domain *h, unsigned int virq,
+static int exynos_eint_irq_map(struct irq_domain *h, unsigned int virq,
irq_hw_number_t hw)
 {
struct samsung_pin_bank *b = h-host_data;
@@ -267,10 +267,10 @@ static int exynos_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
 }
 
 /*
- * irq domain callbacks for external gpio interrupt controller.
+ * irq domain callbacks for external gpio and wakeup interrupt controllers.
  */
-static const struct irq_domain_ops exynos_gpio_irqd_ops = {
-   .map= exynos_gpio_irq_map,
+static const struct irq_domain_ops exynos_eint_irqd_ops = {
+   .map= exynos_eint_irq_map,
.xlate  = irq_domain_xlate_twocell,
 };
 
@@ -329,7 +329,7 @@ static int exynos_eint_gpio_init(struct 
samsung_pinctrl_drv_data *d)
if (bank-eint_type != EINT_TYPE_GPIO)
continue;
bank-irq_domain = irq_domain_add_linear(bank-of_node,
-   bank-nr_pins, exynos_gpio_irqd_ops, bank);
+   bank-nr_pins, exynos_eint_irqd_ops, bank);
if (!bank-irq_domain) {
dev_err(dev, gpio irq domain add failed\n);
ret = -ENXIO;
@@ -456,26 +456,6 @@ static void exynos_irq_demux_eint16_31(unsigned int irq, 
struct irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static int exynos_wkup_irq_map(struct irq_domain *h, unsigned int virq,
-   irq_hw_number_t hw)
-{
-   struct samsung_pin_bank *b = h-host_data;
-
-   irq_set_chip_and_handler(virq, b-irq_chip-chip,
-   handle_level_irq);
-   irq_set_chip_data(virq, h-host_data);
-   set_irq_flags(virq, IRQF_VALID);
-   return 0;
-}
-
-/*
- * irq domain callbacks for external wakeup interrupt controller.
- */
-static const struct irq_domain_ops exynos_wkup_irqd_ops = {
-   .map= exynos_wkup_irq_map,
-   .xlate  = irq_domain_xlate_twocell,
-};
-
 /*
  * exynos_eint_wkup_init() - setup handling of external wakeup interrupts.
  * @d: driver data of samsung pinctrl driver.
@@ -507,7 +487,7 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
continue;
 
bank-irq_domain = irq_domain_add_linear(bank-of_node,
-   bank-nr_pins, exynos_wkup_irqd_ops, bank);
+   bank-nr_pins, exynos_eint_irqd_ops, bank);
if (!bank-irq_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
-- 
1.7.9.5

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


[PATCH v5 3/6] pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

2014-10-09 Thread Abhilash Kesavan
Exynos7 uses different offsets for wakeup interrupt configuration registers.
So a new irq_chip instance for Exynos7 wakeup interrupts is added. The irq_chip
selection is now based on the wakeup interrupt controller compatible string.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 .../bindings/pinctrl/samsung-pinctrl.txt   |2 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   |   45 +++-
 drivers/pinctrl/samsung/pinctrl-exynos.h   |3 ++
 3 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index e82aaf4..f80519a 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -136,6 +136,8 @@ B. External Wakeup Interrupts: For supporting external 
wakeup interrupts, a
found on Samsung S3C64xx SoCs,
  - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs.
+ - samsung,exynos7-wakeup-eint: represents wakeup interrupt controller
+   found on Samsung Exynos7 SoC.
- interrupt-parent: phandle of the interrupt parent to which the external
  wakeup interrupts are forwarded to.
- interrupts: interrupt used by multiplexed wakeup interrupts.
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index f7ac9c7..e8f8f16 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -56,12 +56,6 @@ static const struct samsung_pin_bank_type bank_type_alive = {
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
 };
 
-/* list of external wakeup controllers supported */
-static const struct of_device_id exynos_wkup_irq_ids[] = {
-   { .compatible = samsung,exynos4210-wakeup-eint, },
-   { }
-};
-
 static void exynos_irq_mask(struct irq_data *irqd)
 {
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
@@ -384,9 +378,9 @@ static int exynos_wkup_irq_set_wake(struct irq_data *irqd, 
unsigned int on)
 /*
  * irq_chip for wakeup interrupts
  */
-static struct exynos_irq_chip exynos_wkup_irq_chip = {
+static struct exynos_irq_chip exynos4210_wkup_irq_chip __initdata = {
.chip = {
-   .name = exynos_wkup_irq_chip,
+   .name = exynos4210_wkup_irq_chip,
.irq_unmask = exynos_irq_unmask,
.irq_mask = exynos_irq_mask,
.irq_ack = exynos_irq_ack,
@@ -400,6 +394,31 @@ static struct exynos_irq_chip exynos_wkup_irq_chip = {
.eint_pend = EXYNOS_WKUP_EPEND_OFFSET,
 };
 
+static struct exynos_irq_chip exynos7_wkup_irq_chip __initdata = {
+   .chip = {
+   .name = exynos7_wkup_irq_chip,
+   .irq_unmask = exynos_irq_unmask,
+   .irq_mask = exynos_irq_mask,
+   .irq_ack = exynos_irq_ack,
+   .irq_set_type = exynos_irq_set_type,
+   .irq_set_wake = exynos_wkup_irq_set_wake,
+   .irq_request_resources = exynos_irq_request_resources,
+   .irq_release_resources = exynos_irq_release_resources,
+   },
+   .eint_con = EXYNOS7_WKUP_ECON_OFFSET,
+   .eint_mask = EXYNOS7_WKUP_EMASK_OFFSET,
+   .eint_pend = EXYNOS7_WKUP_EPEND_OFFSET,
+};
+
+/* list of external wakeup controllers supported */
+static const struct of_device_id exynos_wkup_irq_ids[] = {
+   { .compatible = samsung,exynos4210-wakeup-eint,
+   .data = exynos4210_wkup_irq_chip },
+   { .compatible = samsung,exynos7-wakeup-eint,
+   .data = exynos7_wkup_irq_chip },
+   { }
+};
+
 /* interrupt handler for wakeup interrupts 0..15 */
 static void exynos_irq_eint0_15(unsigned int irq, struct irq_desc *desc)
 {
@@ -468,12 +487,18 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
struct samsung_pin_bank *bank;
struct exynos_weint_data *weint_data;
struct exynos_muxed_weint_data *muxed_data;
+   struct exynos_irq_chip *irq_chip;
unsigned int muxed_banks = 0;
unsigned int i;
int idx, irq;
 
for_each_child_of_node(dev-of_node, np) {
-   if (of_match_node(exynos_wkup_irq_ids, np)) {
+   const struct of_device_id *match;
+
+   match = of_match_node(exynos_wkup_irq_ids, np);
+   if (match) {
+   irq_chip = kmemdup(match-data,
+   sizeof(*irq_chip), GFP_KERNEL);
wkup_np = np;
break;
}
@@ -493,7 +518,7 @@ static int exynos_eint_wkup_init(struct 

[PATCH v5 5/6] arm64: dts: Add initial pinctrl support to EXYNOS7

2014-10-09 Thread Abhilash Kesavan
From: Naveen Krishna Ch naveenkrishna...@gmail.com

Add initial pin configuration nodes for EXYNOS7.

Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |  560 +++
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   66 +++
 2 files changed, 626 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
new file mode 100644
index 000..c7c41c1
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -0,0 +1,560 @@
+/*
+ * Samsung's Exynos7 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos7 SoC pin-mux and pin-config options are listed as
+ * device tree nodes in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+pinctrl_alive {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   interrupt-parent = gic;
+   #interrupt-cells = 2;
+   interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
+0 4 0, 0 5 0, 0 6 0, 0 7 0;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   interrupt-parent = gic;
+   #interrupt-cells = 2;
+   interrupts = 0 8 0, 0 9 0, 0 10 0, 0 11 0,
+0 12 0, 0 13 0, 0 14 0, 0 15 0;
+   };
+
+   gpa2: gpa2 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpa3: gpa3 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+};
+
+pinctrl_bus0 {
+   gpb0: gpb0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc2: gpc2 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc3: gpc3 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd2: gpd2 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd4: gpd4 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd5: gpd5 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd6: gpd6 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd7: gpd7 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd8: gpd8 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpg0: gpg0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   

[PATCH v5 4/6] pinctrl: exynos: Add initial driver data for Exynos7

2014-10-09 Thread Abhilash Kesavan
From: Naveen Krishna Ch naveenkrishna...@gmail.com

This patch adds initial driver data for Exynos7 pinctrl support.

Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 .../bindings/pinctrl/samsung-pinctrl.txt   |1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   |  105 
 drivers/pinctrl/samsung/pinctrl-samsung.c  |2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h  |1 +
 4 files changed, 109 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index f80519a..8425838 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -18,6 +18,7 @@ Required Properties:
   - samsung,exynos5250-pinctrl: for Exynos5250 compatible pin-controller.
   - samsung,exynos5260-pinctrl: for Exynos5260 compatible pin-controller.
   - samsung,exynos5420-pinctrl: for Exynos5420 compatible pin-controller.
+  - samsung,exynos7-pinctrl: for Exynos7 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
   the address space it occupies.
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index e8f8f16..fbeff99 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1164,3 +1164,108 @@ const struct samsung_pin_ctrl exynos5420_pin_ctrl[] 
__initconst = {
.eint_gpio_init = exynos_eint_gpio_init,
},
 };
+
+/* pin banks of exynos7 pin-controller - ALIVE */
+static const struct samsung_pin_bank_data exynos7_pin_banks0[] __initconst = {
+   EXYNOS_PIN_BANK_EINTW(8, 0x000, gpa0, 0x00),
+   EXYNOS_PIN_BANK_EINTW(8, 0x020, gpa1, 0x04),
+   EXYNOS_PIN_BANK_EINTW(8, 0x040, gpa2, 0x08),
+   EXYNOS_PIN_BANK_EINTW(8, 0x060, gpa3, 0x0c),
+};
+
+/* pin banks of exynos7 pin-controller - BUS0 */
+static const struct samsung_pin_bank_data exynos7_pin_banks1[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(5, 0x000, gpb0, 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, gpc0, 0x04),
+   EXYNOS_PIN_BANK_EINTG(2, 0x040, gpc1, 0x08),
+   EXYNOS_PIN_BANK_EINTG(6, 0x060, gpc2, 0x0c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x080, gpc3, 0x10),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0a0, gpd0, 0x14),
+   EXYNOS_PIN_BANK_EINTG(6, 0x0c0, gpd1, 0x18),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0e0, gpd2, 0x1c),
+   EXYNOS_PIN_BANK_EINTG(5, 0x100, gpd4, 0x20),
+   EXYNOS_PIN_BANK_EINTG(4, 0x120, gpd5, 0x24),
+   EXYNOS_PIN_BANK_EINTG(6, 0x140, gpd6, 0x28),
+   EXYNOS_PIN_BANK_EINTG(3, 0x160, gpd7, 0x2c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x180, gpd8, 0x30),
+   EXYNOS_PIN_BANK_EINTG(2, 0x1a0, gpg0, 0x34),
+   EXYNOS_PIN_BANK_EINTG(4, 0x1c0, gpg3, 0x38),
+};
+
+/* pin banks of exynos7 pin-controller - NFC */
+static const struct samsung_pin_bank_data exynos7_pin_banks2[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(3, 0x000, gpj0, 0x00),
+};
+
+/* pin banks of exynos7 pin-controller - TOUCH */
+static const struct samsung_pin_bank_data exynos7_pin_banks3[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(3, 0x000, gpj1, 0x00),
+};
+
+/* pin banks of exynos7 pin-controller - FF */
+static const struct samsung_pin_bank_data exynos7_pin_banks4[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(4, 0x000, gpg4, 0x00),
+};
+
+/* pin banks of exynos7 pin-controller - ESE */
+static const struct samsung_pin_bank_data exynos7_pin_banks5[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(5, 0x000, gpv7, 0x00),
+};
+
+/* pin banks of exynos7 pin-controller - FSYS0 */
+static const struct samsung_pin_bank_data exynos7_pin_banks6[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(7, 0x000, gpr4, 0x00),
+};
+
+/* pin banks of exynos7 pin-controller - FSYS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks7[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(4, 0x000, gpr0, 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, gpr1, 0x04),
+   EXYNOS_PIN_BANK_EINTG(5, 0x040, gpr2, 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, gpr3, 0x0c),
+};
+
+const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
+   {
+   /* pin-controller instance 0 Alive data */
+   .pin_banks  = exynos7_pin_banks0,
+   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks0),
+   .eint_gpio_init = exynos_eint_gpio_init,
+   .eint_wkup_init = exynos_eint_wkup_init,
+   }, {
+   /* pin-controller instance 1 BUS0 data */
+   .pin_banks  = exynos7_pin_banks1,
+   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks1),
+

[PATCH v5 6/6] arm64: exynos: Enable pinctrl support for Exynos7

2014-10-09 Thread Abhilash Kesavan
From: Naveen Krishna Ch naveenkrishna...@gmail.com

Enable pinctrl support for exynos7 SoCs.

Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Linus Walleij linus.wall...@linaro.org
---
 arch/arm64/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 56e5b7c..f9c42fa 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -155,6 +155,8 @@ config ARCH_EXYNOS7
bool ARMv8 based Samsung Exynos7
select ARCH_EXYNOS
select COMMON_CLK_SAMSUNG
+   select PINCTRL
+   select PINCTRL_EXYNOS
help
  This enables support for Samsung Exynos7 SoC family
 
-- 
1.7.9.5

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


Re: [GIT PULL 3/3] 3rd Round of Exynos-PM-2 Updates for v3.18

2014-10-09 Thread Bartlomiej Zolnierkiewicz

Hi,

On Thursday, October 02, 2014 03:35:18 PM Bartlomiej Zolnierkiewicz wrote:
 
 Hi,
 
 On Wednesday, October 01, 2014 08:31:47 PM Arnd Bergmann wrote:
  On Wednesday 01 October 2014 18:49:20 Bartlomiej Zolnierkiewicz wrote:
   On Wednesday, October 01, 2014 06:01:29 PM Arnd Bergmann wrote:
On Thursday 25 September 2014, Kukjin Kim wrote:
 Exynos 2nd PM related updates for v3.18
 
 - 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
 

I needed another fixup to make this build, but I'm not sure about
whether this is the right solution.
   
   Could you please share the build errors and the used config?
  
  I'm building with an additional series that works around all known
  build failures in randconfig, so it's possible that the configuration
  causes other problems in your tree, or that one of my own patches
  introduces the problem and the exynos tree by itself is fine.
  
  This is the build error I get:
  
  arch/arm/mach-exynos/built-in.o: In function `exynos_suspend':
  :(.text+0x294): undefined reference to `cpu_suspend'
  :(.text+0x29c): undefined reference to `cpu_suspend'
  arch/arm/mach-exynos/built-in.o: In function `skip_cp15':
  :(.data+0x58): undefined reference to `cpu_resume'
  arch/arm/mach-exynos/built-in.o: In function `cp15_save_power':
  :(.data+0x70): undefined reference to `cpu_resume'
  
  The defconfig file is attached, the details don't matter to
  other readers, except that it has CONFIG_ARM_CPU_SUSPEND
  disabled, which means that sleep.S can't be linked properly.
 
 It turned out that the breakage came through Exynos tree.  ARM:
 EXYNOS: Add support for firmware-assisted suspend/resume added to
 arch/arm/mach-exynos/firmware.c new references to functions from
 arch/arm/mach-exynos/sleep.S causing the CONFIG_PM_SLEEP=n build
 breakage.  Then ARM: EXYNOS: Fix build with PM_SLEEP=n and
 ARM_EXYNOS_CPUIDLE=y tried to fix the CONFIG_PM_SLEEP=n issue by
 always building sleep.S causing in turn the CONFIG_ARM_CPU_SUSPEND=n
 build breakage.  I have not noticed the problem earlier because I
 have overlooked the fact that cpu_suspend() is available only when
 CONFIG_ARM_CPU_SUSPEND=y and in all configs tested by me it was on
 (it gets disabled only when both CONFIG_PM and CONFIG_MCPM are off).
 Sorry for that.
 
 Your patch seems to be a correct fix except that the resume entry
 should use IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) instead of
 IS_ENABLED(CONFIG_PM_SLEEP) as resume firmware operations is also
 used by Exynos cpuidle support.
 
 How should we proceed further to get this tree merged?

ping?  Arnd, Kukjin?

 PS What is interesting in your defconfig is that it has CONFIG_MCPM
 enabled but CONFIG_ARM_CPU_SUSPEND is disabled so there are probably
 some MPCM related changes in your tree.

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

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


Re: [PATCH 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards

2014-10-09 Thread Javier Martinez Canillas
Hello Mark,

On 10/08/2014 09:51 PM, Mark Brown wrote:
 On Wed, Oct 08, 2014 at 06:25:00PM +0200, Javier Martinez Canillas
 What this series tried to solve is when you have to set a opmode on
 boot to change how the physical suspend is managed by the PMIC.
 
 Think about the consequences of what's being said here.  The goal is to
 set the mode in system suspend which will presumably be a minimal power
 consumption mode where minimal load is expected.  What's being said is
 that in order to implement this we want to set the default mode used
 while the system is running to this mode.  This will mean that we'll be
 in this low power mode while running full speed.  That in turn not only
 means that the DT says something other than what we're trying to do and
 hence looks like it's buggy but most likely also means that the system
 won't run stably under load since the regulators are in power saving
 mode.


No, while system is running the regulator won't be in low power mode even
after changing the mode. The mode only affects what the PMIC will do with
the regulator when the system enters to and exit from sleep mode and the
AP signals the PMIC about it.

Maybe you already got it from my previous email but I'll summarize how the
hardware works just to be sure we are on the same page:

* The PMIC allows the AP to power up and down voltage rails via a PWRREQ
  pin to signal when it enters and exit from sleep mode.

* Each regulator control register has a 2-bit field called OPMODE in the
  data-sheet that allows to set 4 different operating modes. For most
  regulators, the modes are the following:

  0x0: Output OFF (regardless of PWRREQ)
  0x1: Output ON/OFF controlled by PWRREQ
   PWRREQ = HIGH (1): Output ON in Normal Mode
   PWRREQ = LOW (0): Output OFF
  0x2: Output ON with Low Power Mode controlled by PWRREQ
   PWRREQ = HIGH (1): Output ON in Low Power Mode
   PWRREQ = LOW (0): Output OFF
  0x3: Output ON in Normal Mode (regardless of PWRREQ)

* Not all regulators have the same modes, for example 0x1 in some LDOs
  means Output ON in Low Power Mode regardless of PWRREQ and so on.

Since PWRREQ is HIGH when the AP is in normal mode, there are only two
modes that most regulators can be on runtime: ON and OFF.
 
 As has been said previously please try to think about things in terms of
 abstractions and what the actual goal is, don't try to shoehorn things
 into places they happen to solve the immediate problem without regard to
 the bigger picture or comprehensibility.


I could had proposed a DT property that would be specific to the max77802
regulator driver but instead I really tried to not only care about my
particular use case and come up with a solution that could be generic and
useful for others.

As Krzysztof said in other thread, this feature is common to many Maxim
PMICs and AFAIK the Rockchip RK808 PMIC has a similar feature to choose
between two modes: Output ON vs Output ON/OFF controlled by a SLEEP pin.

But maybe trying to make it generic was my mistake and a device-specific
DT binding is the proper solution here...
 
  This appears to set the supply which is labelled as VDD_ARM into standby
  mode by default (from a first glance the change appears to set all
  supplies into standby mode) and of course we currently have no way of
  changing the mode at runtime in DT systems.  Are you *really* sure this
  is a good idea of which an electrical engineer would approve, CPU cores
  are typically one of the most demanding workloads available for a
  regulator?
 
 Well, the standby mode for this regulator is actually:
 
 Output ON/OFF Controlled by PWRREQ
  PWRREQ=HIGH (1): Output ON in Normal Mode
  PWRREQ=LOW (0): Output OFF
 
 This isn't a mode at all.  This is an enable control and hence it
 should not be implemented as a mode.  It should be adequately documented
 but for the avoidance of doubt a regulation mode should control the
 quality and efficiency of regulation, if something can cause the
 regulator to be disabled (except perhaps as a consequence of handling a
 failure in regulation) then it shouldn't be a mode.
 

I see, I thought that an operating mode could be anything that alter the
regulator behavior either during runtime or when the system is suspended.
But under your definition, it is true that most max77802 regulators have
only two modes: ON and OFF (and some of them have a third Low Power mode).

I think though that a generic way to configure this enable control feature
is needed. Maybe adding a new pair of .{get,set}_suspend_control function
pointers to struct regulator_ops and an .initial_suspend_ctrl field to the
struct regulation_constraints?

That way the core could parse a generic DT property and call the function
handlers but each driver can document in their own DT bindings what their
control values are and how those affects the regulators during suspend?

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe 

Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support

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

Thanks a lot for your feedback.

On 10/09/2014 10:45 AM, Krzysztof Kozlowski wrote:
 On śro, 2014-10-08 at 15:44 +0200, Javier Martinez Canillas wrote:
 --- a/Documentation/devicetree/bindings/regulator/regulator.txt
 +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
 @@ -23,6 +23,14 @@ Optional properties:
state among following defined suspend states:
3: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
4: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
 +- regulator-initial-mode: initial regulator operating mode. One of 
 following:
 +1: REGULATOR_MODE_FAST- Regulator can handle fast changes.
 +2: REGULATOR_MODE_NORMAL  - Normal regulator power supply mode.
 +4: REGULATOR_MODE_IDLE- Regulator runs in a more efficient mode.
 +8: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode.
 +  modes are defined in the dt-bindings/regulator/regulator.h header and can 
 be
 +  used in device tree sources files. If no mode is defined, then the OS 
 will not
 +  manage the operating mode and the HW default values will be used instead.
  - regulator-state-mem sub-root node for Suspend-to-RAM mode
: suspend to memory, the device goes to sleep, but all data stored in 
 memory,
only some external interrupt can wake the device.
 
 I agree with the need and the idea of generic bindings for operating
 modes for regulators. At least for Exynos-based boards the PMICs have
 quite similar opmodes.
 
 However the regulator mode from consumer.h (and in above doc) does not
 match well with these opmodes. Example is yours patch 4/5:
  - idle (more efficient mode) maps to low power mode in suspend,
  - standby (the most efficient mode) maps to OFF in suspend.
 
 Actually we are not enable efficient modes but we configure how the
 regulator will behave when AP says - I'm suspending.


Agree, Mark also pointed out that there is a difference between changing
how the regulator will behave on runtime vs changing how the regulator
will behave during system suspend. AFAIU from his explanation, the modes
defined in consumer.h only applies to the former and conceptually there
should be a difference between those two cases even when the Maxim PMIC
seems to mix it both in the data-sheet and by using the same field.

I answered Mark on patch #5 with a suggestion on how to handle this in
a generic way to avoid each driver having their own custom DT binding
and duplicating the parsing code.

Could you please answer there with your thoughts?
 
 
 Another issue: is initial_state not doing all this already?
 

One of the options I indeed evaluated was if using initial_state could be
possible. But currently the .set_suspend_mode function handler is only
called for the STANDBY, MEM and MAX suspend modes. While is true that this
could be extended to also support PM_SUSPEND_ON, I don't think that it
makes sense conceptually. Since is not the same to set a mode to be used
at runtime than setting a mode to be used during suspend.

AFAIU that is the reason why there are separate .set_suspend_mode and
.set_mode operations and that's why there are both an .initial_state
and an .initial_mode.

 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 1/5] regulator: of: Add regulator-initial-mode parse support

2014-10-09 Thread Javier Martinez Canillas
Hello Mark,

On 10/09/2014 12:27 PM, Mark Rutland wrote:
 
 Well, is not fairly obvious to me. One can also say the opposite, why the
 kernel is documenting a DT binding that is not (currently) implemented?
 
 Checkpatch will complain regarding undocumented bindings, so from a
 pragmatic point of view the binding must come first.

 Personally, when I read a patch series I do an initial pass in-order,
 and having the binding first makes things clearer. I might have some
 questions regarding the binding that the driver answers later, and it makes it
 easier to spot undocumented properties or conventions used by the
 driver. Doing so the other way around usually leaves me with more
 questions at the end.


Thanks a lot for the explanation, it certainly makes sense then to have
the DT binding before. I'll propose a patch to add that information to
Documentation/devicetree/bindings/submitting-patches.txt so people
(like me) who didn't find it obvious can know what the convention is.
 
 That's why what makes the most sense for me is what the old convention did,
 add the DT binding docs in the same patch that implements the binding.
 
 Having a separate patch for the binding is very helpful for those of us
 doing review. For one thing it helps us to find the binding document,
 which can be important when a driver is thousands of lines long. For
 another it means that we can be clear that our Acked-by, Reviewed-by,
 etc apply to the binding and not necessarily the rest of the code.
 

Agreed.

 For small patches, this is obviously less of a concern.
 
 Thanks,
 Mark.
 

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 00/21] thermal: exynos: Thermal code rework to use device tree

2014-10-09 Thread Lukasz Majewski
1. Introduction

Following patches aim to clean up the current implementation of the thermal
framework on Exynos devices.

The main goal was to use a generic code for reading thermal configuration
(of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files
were removed.

Around 400 lines of code (LOC) were removed directly by this patch, which
is around 20% of the Exynos thermal code base.

This work should NOT bring any functional changes to Exynos thermal 
subsystem.

2. Patch-set structure

This series starts with extending current of-thermal.c implementation with
exporting information about trip points and support for setting emulated 
temperature. Those changes were necessary to reuse this code in Exynos.

Then the cpu_cooling functionality has been preserved to allow cooling
devices by reducing operating frequency. Definition of trip points and
cpufreq's cooling properties were moved to device tree.

Then the rework of the way in which configuration data is provided to
the Exynos thermal subsystem was performed. Now device tree is used for
configuration.

Patch series end with removing exynos5250/exynos3250 TMU compatibles.
Both SoCs have thermal management unit (TMU) compatible with the one first 
introduced at Exynos4412.

3. Dead code removal

Thermal support for some SoCs, previously available in the exynos_tmu_data.c 
file, was removed since, as of 3.17-rc6, they didn't have TMU bindings.

Moreover, support for cpu_cooling devices was preserved only on those
SoCs which had available and working cpufreq driver.

4. Testing

Test devices:
- Exynos4210 - Trats (TMU zone + cpu_cooling)
- Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling)
- Exynos5250 - Arndale (TMU zone + cpu_cooling)
- Exynos5420 - Arndale-octa (only TMU zones)

Unfortunately, I don't posses Exynos5440 for testing. Its functionality
has been preserved in the code, but not tested on the hardware. I would
be grateful for help in testing.

5. Prerequisites:

This work requires following patches developed by Bartlomiej Zolnierkiewicz:

5.1. [PATCH v3] ARM: dts: add CPU nodes for Exynos4 SoCs
http://article.gmane.org/gmane.linux.kernel.samsung-soc/37946/match=patch+v3+arm+dts+add+cpu+nodes+exynos4+socs

5.2. First thermal clean up patch set (from patch 1 to 33):

[PATCH 00/33] thermal: exynos: convert the driver to use per-SoC type operations
http://article.gmane.org/gmane.linux.kernel.samsung-soc/37642/match=patch+00+33+thermal+exynos+convert+driver+use+per+soc+type+operations


Lukasz Majewski (21):
  thermal: of: Extend of-thermal.c to provide number of trip points
  thermal: of: Extend of-thermal.c to provide check if trip point is
enabled
  thermal: of: Extend of-thermal.c to provide number of non critical
trip points
  thermal: of: Extend current of-thermal.c code to allow setting
emulated temp
  thermal: exynos: cosmetic: Correct comment format
  thermal: exynos: Provide thermal_exynos.h file to be included in
device tree files
  thermal: dts: trats: Enable TMU on the Exynos4210 trats device
  thermal: dts: exynos: Adding LD010 regulator node necessary for TMU on
Odroid U3 board
  thermal: dts: Provide bindings and enable TMU at Exynos4x12 devices
  thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu
cooling functionality
  thermal: cpu_cooling: Modify exynos thermal code to use device tree
for cpu cooling configuration
  thermal: exynos: dts: Add default definition for the TMU sensor
  thermal: dts: Default trip points definition for Exynos5420 SoCs
  thermal: exynos: dts: Define default thermal-zones for Exynos4
  thermal: dts: exynos: Trip points and sensor configuration data for
Exynos5440
  thermal: exynos: dts: Provide device tree bindings identical to one in
exynos_tmu_data.c
  thermal: samsung: core: Exynos TMU rework to use device tree for
configuration
  thermal: exynos: Remove exynos_thermal_common.[c|h] files
  thermal: exynos: Remove exynos_tmu_data.c file
  thermal: exynos: Make Exynos5250 TMU compatible with Exynos4412
  thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412

 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi|  52 +++
 arch/arm/boot/dts/exynos4.dtsi|   5 +
 arch/arm/boot/dts/exynos4210-trats.dts|  19 +
 arch/arm/boot/dts/exynos4210.dtsi |  28 +-
 arch/arm/boot/dts/exynos4212.dtsi |   5 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi   |  27 ++
 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi |  24 ++
 arch/arm/boot/dts/exynos4412.dtsi |   5 +-
 arch/arm/boot/dts/exynos4x12.dtsi |  13 +
 arch/arm/boot/dts/exynos5250.dtsi |  29 +-
 arch/arm/boot/dts/exynos5420-trip-points.dtsi |  35 ++
 arch/arm/boot/dts/exynos5420.dtsi |  33 ++
 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi |  25 ++
 arch/arm/boot/dts/exynos5440-trip-points.dtsi |  25 ++
 arch/arm/boot/dts/exynos5440.dtsi  

[PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

2014-10-09 Thread Lukasz Majewski
This patch extends the of-thermal.c to provide information about number of
available non critical (i.e. non HW) trip points in the system.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/of-thermal.c   | 12 
 drivers/thermal/thermal_core.h |  5 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 23c8d6c..cd74e64 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct thermal_zone_device *tz, 
int trip)
return 1;
 }
 
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
+{
+   struct __thermal_zone *data = tz-devdata;
+   int i;
+
+   for (i = 0; i  data-ntrips; i++)
+   if (data-trips[i].type != THERMAL_TRIP_CRITICAL)
+   continue;
+
+   return --i;
+}
+
 static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
 {
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index ed8ff05..334a7be 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
 void of_thermal_destroy_zones(void);
 int of_thermal_get_ntrips(struct thermal_zone_device *);
 int of_thermal_is_trip_en(struct thermal_zone_device *, int);
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
 #else
 static inline int of_parse_thermal_zones(void) { return 0; }
 static inline void of_thermal_destroy_zones(void) { }
@@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct thermal_zone_device *, int)
 {
return 0;
 }
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
+{
+   return 0;
+}
 #endif
 
 #endif /* __THERMAL_CORE_H__ */
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 07/21] thermal: dts: trats: Enable TMU on the Exynos4210 trats device

2014-10-09 Thread Lukasz Majewski
The thermal IP block (Thermal Management Unit) called TMU has been enabled
in this device.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4210-trats.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..b59019c 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -424,6 +424,10 @@
status = okay;
};
 
+   tmu@100C {
+   status = okay;
+   };
+
camera {
pinctrl-names = default;
pinctrl-0 = ;
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 06/21] thermal: exynos: Provide thermal_exynos.h file to be included in device tree files

2014-10-09 Thread Lukasz Majewski
This patch is a preparatory patch for being able to read Exynos thermal
configuration from the device tree.

The DTC is not able to interpret enums properly and hence it is necessary
to #define those values explicitly.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c |  2 +-
 drivers/thermal/samsung/exynos_tmu.h | 23 +++-
 include/dt-bindings/thermal/thermal_exynos.h | 40 
 3 files changed, 44 insertions(+), 21 deletions(-)
 create mode 100644 include/dt-bindings/thermal/thermal_exynos.h

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index fa29b95..2f55daa 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -159,7 +159,7 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
-   enum soc_type soc;
+   int soc;
struct work_struct irq_work;
struct mutex lock;
struct clk *clk, *clk_sec;
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index da3009b..a089391 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -26,24 +26,7 @@
 
 #include exynos_thermal_common.h
 
-enum calibration_type {
-   TYPE_ONE_POINT_TRIMMING,
-   TYPE_ONE_POINT_TRIMMING_25,
-   TYPE_ONE_POINT_TRIMMING_85,
-   TYPE_TWO_POINT_TRIMMING,
-   TYPE_NONE,
-};
-
-enum soc_type {
-   SOC_ARCH_EXYNOS3250 = 1,
-   SOC_ARCH_EXYNOS4210,
-   SOC_ARCH_EXYNOS4412,
-   SOC_ARCH_EXYNOS5250,
-   SOC_ARCH_EXYNOS5260,
-   SOC_ARCH_EXYNOS5420,
-   SOC_ARCH_EXYNOS5420_TRIMINFO,
-   SOC_ARCH_EXYNOS5440,
-};
+#include dt-bindings/thermal/thermal_exynos.h
 
 /**
  * struct exynos_tmu_platform_data
@@ -115,8 +98,8 @@ struct exynos_tmu_platform_data {
u8 second_point_trim;
u8 default_temp_offset;
 
-   enum calibration_type cal_type;
-   enum soc_type type;
+   u32 cal_type;
+   u32 type;
struct freq_clip_table freq_tab[4];
unsigned int freq_tab_count;
 };
diff --git a/include/dt-bindings/thermal/thermal_exynos.h 
b/include/dt-bindings/thermal/thermal_exynos.h
new file mode 100644
index 000..5d91d64
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal_exynos.h
@@ -0,0 +1,40 @@
+/*
+ * thermal_exynos.h - Samsung EXYNOS TMU device tree definitions
+ *
+ *  Copyright (C) 2014 Samsung Electronics
+ *  Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef _EXYNOS_THERMAL_TMU_DT_H
+#define _EXYNOS_THERMAL_TMU_DT_H
+
+#define TYPE_ONE_POINT_TRIMMING 0
+#define TYPE_ONE_POINT_TRIMMING_25 1
+#define TYPE_ONE_POINT_TRIMMING_85 2
+#define TYPE_TWO_POINT_TRIMMING 3
+#define TYPE_NONE 4
+
+#define SOC_ARCH_EXYNOS3250 1
+#define SOC_ARCH_EXYNOS4210 2
+#define SOC_ARCH_EXYNOS4412 3
+#define SOC_ARCH_EXYNOS5250 4
+#define SOC_ARCH_EXYNOS5260 5
+#define SOC_ARCH_EXYNOS5420_TRIMINFO 6
+#define SOC_ARCH_EXYNOS5420 7
+#define SOC_ARCH_EXYNOS5440 8
+
+#endif /* _EXYNOS_THERMAL_TMU_DT_H */
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 05/21] thermal: exynos: cosmetic: Correct comment format

2014-10-09 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 9e7f720..fa29b95 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -606,7 +606,7 @@ out:
 #define exynos5440_tmu_set_emulation NULL
 static int exynos_tmu_set_emulation(void *drv_data,unsigned long temp)
{ return -EINVAL; }
-#endif/*CONFIG_THERMAL_EMULATION*/
+#endif /* CONFIG_THERMAL_EMULATION */
 
 static int exynos4210_tmu_read(struct exynos_tmu_data *data)
 {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp

2014-10-09 Thread Lukasz Majewski
Before this change it was only possible to set get_temp() and get_trend()
methods to be used in the common code handling passing parameters via
device tree to cpu-thermal CPU thermal zone device.

Now it is possible to also set emulated value of temperature for debug
purposes.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/of-thermal.c | 25 ++---
 include/linux/thermal.h  |  6 --
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index cd74e64..f206375 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -98,10 +98,22 @@ struct __thermal_zone {
void *sensor_data;
int (*get_temp)(void *, long *);
int (*get_trend)(void *, long *);
+   int (*set_emul_temp)(void *, unsigned long);
 };
 
 /***   DT thermal zone device callbacks   ***/
 
+static int of_thermal_set_emul_temp(struct thermal_zone_device *tz,
+   unsigned long temp)
+{
+   struct __thermal_zone *data = tz-devdata;
+
+   if (!data-set_emul_temp)
+   return -EINVAL;
+
+   return data-set_emul_temp(data-sensor_data, temp);
+}
+
 static int of_thermal_get_temp(struct thermal_zone_device *tz,
   unsigned long *temp)
 {
@@ -352,7 +364,8 @@ static struct thermal_zone_device *
 thermal_zone_of_add_sensor(struct device_node *zone,
   struct device_node *sensor, void *data,
   int (*get_temp)(void *, long *),
-  int (*get_trend)(void *, long *))
+  int (*get_trend)(void *, long *),
+  int (*set_emul_temp)(void *, unsigned long))
 {
struct thermal_zone_device *tzd;
struct __thermal_zone *tz;
@@ -366,10 +379,12 @@ thermal_zone_of_add_sensor(struct device_node *zone,
mutex_lock(tzd-lock);
tz-get_temp = get_temp;
tz-get_trend = get_trend;
+   tz-set_emul_temp = set_emul_temp;
tz-sensor_data = data;
 
tzd-ops-get_temp = of_thermal_get_temp;
tzd-ops-get_trend = of_thermal_get_trend;
+   tzd-ops-set_emul_temp = of_thermal_set_emul_temp;
mutex_unlock(tzd-lock);
 
return tzd;
@@ -411,7 +426,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
 struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
void *data, int (*get_temp)(void *, long *),
-   int (*get_trend)(void *, long *))
+   int (*get_trend)(void *, long *),
+   int (*set_emul_temp)(void *, unsigned long))
 {
struct device_node *np, *child, *sensor_np;
 
@@ -453,7 +469,8 @@ thermal_zone_of_sensor_register(struct device *dev, int 
sensor_id,
return thermal_zone_of_add_sensor(child, sensor_np,
  data,
  get_temp,
- get_trend);
+ get_trend,
+ set_emul_temp);
}
}
of_node_put(np);
@@ -494,9 +511,11 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
mutex_lock(tzd-lock);
tzd-ops-get_temp = NULL;
tzd-ops-get_trend = NULL;
+   tzd-ops-set_emul_temp = NULL;
 
tz-get_temp = NULL;
tz-get_trend = NULL;
+   tz-set_emul_temp = NULL;
tz-sensor_data = NULL;
mutex_unlock(tzd-lock);
 }
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 0305cde..36010e9 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -290,14 +290,16 @@ struct thermal_genl_event {
 struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int id,
void *data, int (*get_temp)(void *, long *),
-   int (*get_trend)(void *, long *));
+   int (*get_trend)(void *, long *),
+   int (*set_emul_temp)(void *, unsigned long));
 void thermal_zone_of_sensor_unregister(struct device *dev,
   struct thermal_zone_device *tz);
 #else
 static inline struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int id,
void *data, int (*get_temp)(void *, long *),
-   int (*get_trend)(void *, long *))
+   int (*get_trend)(void *, long *),
+   int (*set_emul_temp)(void *, unsigned long))
 {
return NULL;
 }
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe 

[PATCH 02/21] thermal: of: Extend of-thermal.c to provide check if trip point is enabled

2014-10-09 Thread Lukasz Majewski
This patch extends the of-thermal.c to provide check if trip point is
enabled.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/of-thermal.c   | 9 +
 drivers/thermal/thermal_core.h | 5 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b2390d9..23c8d6c 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -119,6 +119,15 @@ int of_thermal_get_ntrips(struct thermal_zone_device *tz)
return data-ntrips;
 }
 
+int of_thermal_is_trip_en(struct thermal_zone_device *tz, int trip)
+{
+   struct __thermal_zone *data = tz-devdata;
+
+   if (trip = data-ntrips || trip  0)
+   return 0;
+   return 1;
+}
+
 static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
 {
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 587ca5c..ed8ff05 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -82,6 +82,7 @@ static inline void thermal_gov_user_space_unregister(void) {}
 int of_parse_thermal_zones(void);
 void of_thermal_destroy_zones(void);
 int of_thermal_get_ntrips(struct thermal_zone_device *);
+int of_thermal_is_trip_en(struct thermal_zone_device *, int);
 #else
 static inline int of_parse_thermal_zones(void) { return 0; }
 static inline void of_thermal_destroy_zones(void) { }
@@ -89,6 +90,10 @@ static inline int of_thermal_get_ntrips(struct 
thermal_zone_device *)
 {
return 0;
 }
+int of_thermal_is_trip_en(struct thermal_zone_device *, int)
+{
+   return 0;
+}
 #endif
 
 #endif /* __THERMAL_CORE_H__ */
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 01/21] thermal: of: Extend of-thermal.c to provide number of trip points

2014-10-09 Thread Lukasz Majewski
This patch extends the of-thermal.c to provide information about number of
available trip points.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/of-thermal.c   | 6 ++
 drivers/thermal/thermal_core.h | 5 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index f8eb625..b2390d9 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -113,6 +113,12 @@ static int of_thermal_get_temp(struct thermal_zone_device 
*tz,
return data-get_temp(data-sensor_data, temp);
 }
 
+int of_thermal_get_ntrips(struct thermal_zone_device *tz)
+{
+   struct __thermal_zone *data = tz-devdata;
+   return data-ntrips;
+}
+
 static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
 {
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 3db339f..587ca5c 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -81,9 +81,14 @@ static inline void thermal_gov_user_space_unregister(void) {}
 #ifdef CONFIG_THERMAL_OF
 int of_parse_thermal_zones(void);
 void of_thermal_destroy_zones(void);
+int of_thermal_get_ntrips(struct thermal_zone_device *);
 #else
 static inline int of_parse_thermal_zones(void) { return 0; }
 static inline void of_thermal_destroy_zones(void) { }
+static inline int of_thermal_get_ntrips(struct thermal_zone_device *)
+{
+   return 0;
+}
 #endif
 
 #endif /* __THERMAL_CORE_H__ */
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 08/21] thermal: dts: exynos: Adding LD010 regulator node necessary for TMU on Odroid U3 board

2014-10-09 Thread Lukasz Majewski
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index adadaf9..5364f1a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -209,6 +209,13 @@
regulator-always-on;
};
 
+   ldo10_reg: LDO10 {
+   regulator-name = VDD18_MIPIHSI_1.8V;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   regulator-always-on;
+   };
+
ldo11_reg: LDO11 {
regulator-name = VDD18_ABB1_1.8V;
regulator-min-microvolt = 180;
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 09/21] thermal: dts: Provide bindings and enable TMU at Exynos4x12 devices

2014-10-09 Thread Lukasz Majewski
This commit adds necessary bindings for enabling TMU IP block on the
Exynos4412 Odroid U3 device.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  5 +
 arch/arm/boot/dts/exynos4x12.dtsi   | 10 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 5364f1a..5d4ecc3 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -374,6 +374,11 @@
ehci: ehci@1258 {
status = okay;
};
+
+   tmu@100C {
+   vtmu-supply = ldo10_reg;
+   status = okay;
+   };
 };
 
 pinctrl_1 {
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 861bb91..c12890c 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -271,4 +271,14 @@
compatible = samsung,exynos4x12-usb2-phy;
samsung,sysreg-phandle = sys_reg;
};
+
+   tmu@100C {
+   compatible = samsung,exynos4412-tmu;
+   interrupt-parent = combiner;
+   reg = 0x100C 0x100;
+   interrupts = 2 4;
+   clocks = clock 383;
+   clock-names = tmu_apbif;
+   status = disabled;
+   };
 };
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 12/21] thermal: exynos: dts: Add default definition for the TMU sensor

2014-10-09 Thread Lukasz Majewski
Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure the
on chip temperature. Hence it is possible to group TMU configuration parameters
in one dts include file.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi

diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi 
b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
new file mode 100644
index 000..ee6d8bb
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
@@ -0,0 +1,24 @@
+/*
+ * Device tree sources for Exynos4412 TMU sensor configuration
+ *
+ * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include dt-bindings/thermal/thermal_exynos.h
+
+#thermal-sensor-cells = 0;
+gain = 8;
+reference_voltage = 16;
+noise_cancel_mode = 4;
+efuse_value = 55;
+min_efuse_value = 40;
+max_efuse_value = 100;
+first_point_trim = 25;
+second_point_trim = 85;
+default_temp_offset = 50;
+cal_type = TYPE_ONE_POINT_TRIMMING;
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 14/21] thermal: exynos: dts: Define default thermal-zones for Exynos4

2014-10-09 Thread Lukasz Majewski
Trip points corresponding to the one defined in the exynos_tmu_data.c
for Exynos4 have been included.
This thermal-zones attribute is afterwards reused for Exynos4210, Exynos4412
and Exynos5250.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi 
b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
new file mode 100644
index 000..506600a
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
@@ -0,0 +1,52 @@
+/*
+ * Device tree sources for Exynos4 thermal zone
+ *
+ * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+/ {
+  thermal-zones {
+   cpu_thermal: cpu-thermal {
+   thermal-sensors = tmu 0;
+   polling-delay-passive = 0;
+   polling-delay = 0;
+   trips {
+   cpu_alert0: cpu-alert-0 {
+   temperature = 7; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu_alert1: cpu-alert-1 {
+   temperature = 95000; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu_alert2: cpu-alert-2 {
+   temperature = 11; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu_crit0: cpu-crit-0 {
+   temperature = 12; /* millicelsius */
+   hysteresis = 0; /* millicelsius */
+   type = critical;
+   };
+   };
+   cooling-maps {
+   map0 {
+   trip = cpu_alert0;
+   };
+   map1 {
+   trip = cpu_alert1;
+   };
+   };
+   };
+  };
+};
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 10/21] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality

2014-10-09 Thread Lukasz Majewski
Presented patch aims to move data necessary for correct CPU cooling device
configuration from exynos_tmu_data.c to device tree.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4210-trats.dts  | 15 +++
 arch/arm/boot/dts/exynos4210.dtsi   |  5 -
 arch/arm/boot/dts/exynos4212.dtsi   |  5 -
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 +++
 arch/arm/boot/dts/exynos4412.dtsi   |  5 -
 arch/arm/boot/dts/exynos5250.dtsi   | 20 +++-
 6 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index b59019c..d9dd9a7 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -428,6 +428,21 @@
status = okay;
};
 
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   cooling-maps {
+   map0 {
+   /* Corresponds to 800MHz at freq_table */
+   cooling-device = cpu0 2 2;
+   };
+   map1 {
+  /* Corresponds to 200MHz at freq_table */
+  cooling-device = cpu0 4 4;
+  };
+  };
+   };
+   };
+
camera {
pinctrl-names = default;
pinctrl-0 = ;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 477d455..10e8915 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -45,10 +45,13 @@
#address-cells = 1;
#size-cells = 0;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0x900;
+   cooling-min-level = 4;
+   cooling-max-level = 2;
+   #cooling-cells = 2; /* min followed by max */
};
 
cpu@1 {
diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
b/arch/arm/boot/dts/exynos4212.dtsi
index 484a2da..6405954 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -26,10 +26,13 @@
#address-cells = 1;
#size-cells = 0;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0xA00;
+   cooling-min-level = 13;
+   cooling-max-level = 7;
+   #cooling-cells = 2; /* min followed by max */
};
 
cpu@1 {
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 5d4ecc3..28e7a4c 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -379,6 +379,21 @@
vtmu-supply = ldo10_reg;
status = okay;
};
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   cooling-maps {
+   map0 {
+   /* Corresponds to 800MHz at freq_table */
+   cooling-device = cpu0 7 7;
+   };
+   map1 {
+  /* Corresponds to 200MHz at freq_table */
+  cooling-device = cpu0 13 13;
+  };
+  };
+   };
+   };
 };
 
 pinctrl_1 {
diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 529fd13..9ed8925 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,10 +26,13 @@
#address-cells = 1;
#size-cells = 0;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0xA00;
+   cooling-min-level = 13;
+   cooling-max-level = 7;
+   #cooling-cells = 2; /* min followed by max */
};
 
cpu@1 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..c322fb9 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,14 @@
#address-cells = 1;
#size-cells = 0;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = cpu;
 

[PATCH 11/21] thermal: cpu_cooling: Modify exynos thermal code to use device tree for cpu cooling configuration

2014-10-09 Thread Lukasz Majewski
Up till now exynos_tmu_data.c was used for storing CPU cooling configuration
data. Now the Exynos thermal core code uses device tree to get this data.
For this purpose generic thermal code for configuring CPU cooling was
used.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/cpufreq/exynos-cpufreq.c|  23 -
 drivers/thermal/samsung/exynos_thermal_common.c | 122 ++--
 drivers/thermal/samsung/exynos_tmu.c|   7 --
 drivers/thermal/samsung/exynos_tmu.h|   5 -
 drivers/thermal/samsung/exynos_tmu_data.c   |  42 +---
 5 files changed, 94 insertions(+), 105 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 1e0ec57..fdedb8d 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -18,10 +18,13 @@
 #include linux/cpufreq.h
 #include linux/platform_device.h
 #include linux/of.h
+#include linux/cpu_cooling.h
+#include linux/cpu.h
 
 #include exynos-cpufreq.h
 
 static struct exynos_dvfs_info *exynos_info;
+static struct thermal_cooling_device *cdev;
 static struct regulator *arm_regulator;
 static unsigned int locking_frequency;
 
@@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
 
 static int exynos_cpufreq_probe(struct platform_device *pdev)
 {
+   struct device_node *np;
int ret = -EINVAL;
 
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -198,9 +202,24 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
/* Done here as we want to capture boot frequency */
locking_frequency = clk_get_rate(exynos_info-cpu_clk) / 1000;
 
-   if (!cpufreq_register_driver(exynos_driver))
-   return 0;
+   if (cpufreq_register_driver(exynos_driver))
+   goto err;
 
+   np = of_find_node_by_path(/cpus/cpu@0);
+   if (!np) {
+   pr_err(failed to find cpu0 node\n);
+   return -ENOENT;
+   }
+   if (of_find_property(np, #cooling-cells, NULL)) {
+   cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+   if (IS_ERR(cdev))
+   pr_err(running cpufreq without cooling device: %ld\n,
+  PTR_ERR(cdev));
+   }
+   of_node_put(np);
+
+   return 0;
+ err:
dev_err(pdev-dev, failed to register cpufreq driver\n);
regulator_put(arm_regulator);
 err_vdd_arm:
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..c306de5 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -133,47 +133,62 @@ static int exynos_get_crit_temp(struct 
thermal_zone_device *thermal,
 static int exynos_bind(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev)
 {
-   int ret = 0, i, tab_size, level;
-   struct freq_clip_table *tab_ptr, *clip_data;
struct exynos_thermal_zone *th_zone = thermal-devdata;
struct thermal_sensor_conf *data = th_zone-sensor_conf;
+   struct device_node *child, *gchild, *np;
+   struct of_phandle_args cooling_spec;
+   unsigned long max, state = 0;
+   int ret = 0, i = 0;
 
-   tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
-   tab_size = data-cooling_data.freq_clip_count;
-
-   if (tab_ptr == NULL || tab_size == 0)
+   /*
+* Below code is necessary to skip binding when cpufreq's
+* frequency table is not yet initialized.
+*/
+   cdev-ops-get_max_state(cdev, state);
+   if (!state  !th_zone-cool_dev_size) {
+   th_zone-cool_dev_size = 1;
+   th_zone-cool_dev[0] = cdev;
+   th_zone-bind = false;
return 0;
+   }
 
-   /* find the cooling device registered*/
-   for (i = 0; i  th_zone-cool_dev_size; i++)
-   if (cdev == th_zone-cool_dev[i])
-   break;
+   np = of_find_node_by_path(/thermal-zones/cpu-thermal);
+   if (!np) {
+   pr_err(failed to find thmerla-zones/cpu-thermal node\n);
+   return -ENOENT;
+   }
 
-   /* No matching cooling device */
-   if (i == th_zone-cool_dev_size)
-   return 0;
+   child = of_get_child_by_name(np, cooling-maps);
 
-   /* Bind the thermal zone to the cpufreq cooling device */
-   for (i = 0; i  tab_size; i++) {
-   clip_data = (struct freq_clip_table *)(tab_ptr[i]);
-   level = cpufreq_cooling_get_level(0, clip_data-freq_clip_max);
-   if (level == THERMAL_CSTATE_INVALID)
-   return 0;
-   switch (GET_ZONE(i)) {
-   case MONITOR_ZONE:
-   case WARN_ZONE:
-   if (thermal_zone_bind_cooling_device(thermal, i, cdev,
- 

[PATCH 17/21] thermal: samsung: core: Exynos TMU rework to use device tree for configuration

2014-10-09 Thread Lukasz Majewski
This patch brings support for providing configuration via device tree.
Previously, data hardcoded in the exynos_tmu_data.c file was used, which is
not scalable and error prone.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/Makefile |   2 -
 drivers/thermal/samsung/exynos_tmu.c | 266 ---
 drivers/thermal/samsung/exynos_tmu.h |  51 ---
 3 files changed, 154 insertions(+), 165 deletions(-)

diff --git a/drivers/thermal/samsung/Makefile b/drivers/thermal/samsung/Makefile
index c09d830..1e47d0d 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -3,5 +3,3 @@
 #
 obj-$(CONFIG_EXYNOS_THERMAL)   += exynos_thermal.o
 exynos_thermal-y   := exynos_tmu.o
-exynos_thermal-y   += exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)   += exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 1d6b1cb..e26042a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1,6 +1,10 @@
 /*
  * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
  *
+ *  Copyright (C) 2014 Samsung Electronics
+ *  Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
+ *  Lukasz Majewski l.majew...@samsung.com
+ *
  *  Copyright (C) 2011 Samsung Electronics
  *  Donggeun Kim dg77@samsung.com
  *  Amit Daniel Kachhap amit.kach...@linaro.org
@@ -31,8 +35,8 @@
 #include linux/platform_device.h
 #include linux/regulator/consumer.h
 
-#include exynos_thermal_common.h
 #include exynos_tmu.h
+#include ../thermal_core.h
 
 /* Exynos generic registers */
 #define EXYNOS_TMU_REG_TRIMINFO0x0
@@ -130,6 +134,7 @@
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
+#define MCELSIUS   1000
 /**
  * struct exynos_tmu_data : A structure to hold the private data of the TMU
driver
@@ -165,7 +170,8 @@ struct exynos_tmu_data {
struct clk *clk, *clk_sec;
u8 temp_error1, temp_error2;
struct regulator *regulator;
-   struct thermal_sensor_conf *reg_conf;
+   struct thermal_zone_device *tzd;
+
int (*tmu_initialize)(struct platform_device *pdev);
void (*tmu_control)(struct platform_device *pdev, bool on);
int (*tmu_read)(struct exynos_tmu_data *data);
@@ -174,6 +180,33 @@ struct exynos_tmu_data {
void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
 };
 
+static void exynos_report_trigger(struct exynos_tmu_data *p)
+{
+   char data[10], *envp[] = { data, NULL };
+   struct thermal_zone_device *tz = p-tzd;
+   unsigned long temp;
+   unsigned int i;
+
+   if (!p) {
+   pr_err(Wrong temperature configuration data\n);
+   return;
+   }
+
+   thermal_zone_device_update(tz);
+
+   mutex_lock(tz-lock);
+   /* Find the level for which trip happened */
+   for (i = 0; i  of_thermal_get_ntrips(tz); i++) {
+   tz-ops-get_trip_temp(tz, i, temp);
+   if (tz-last_temperature  temp)
+   break;
+   }
+
+   snprintf(data, sizeof(data), %u, i);
+   kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
+   mutex_unlock(tz-lock);
+}
+
 /*
  * TMU treats temperature as a mapped temperature code.
  * The temperature is converted differently depending on the calibration type.
@@ -249,16 +282,22 @@ static void sanitize_temp_error(struct exynos_tmu_data 
*data, u32 trim_info)
 
 static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold, bool 
falling)
 {
-   struct exynos_tmu_platform_data *pdata = data-pdata;
-   int i;
+   struct thermal_zone_device *tz = data-tzd;
+   unsigned long temp, temp_hist;
+   int i, ret;
 
-   for (i = 0; i  pdata-non_hw_trigger_levels; i++) {
-   u8 temp = pdata-trigger_levels[i];
+   for (i = 0; i  of_thermal_get_non_crit_ntrips(tz); i++) {
+   ret = tz-ops-get_trip_temp(tz, i, temp);
+   if (ret)
+   return 0;
 
-   if (falling)
-   temp -= pdata-threshold_falling;
-   else
+   temp /= MCELSIUS;
+   if (falling) {
+   tz-ops-get_trip_hyst(tz, i, temp_hist);
+   temp -= (temp_hist / MCELSIUS);
+   } else {
threshold = ~(0xff  8 * i);
+   }
 
threshold |= temp_to_code(data, temp)  8 * i;
}
@@ -320,9 +359,10 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
 static int exynos4210_tmu_initialize(struct platform_device *pdev)
 {
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-   struct exynos_tmu_platform_data *pdata = data-pdata;
-   unsigned int status;
+   struct 

[PATCH 21/21] thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412

2014-10-09 Thread Lukasz Majewski
Since both SoCs have the same TMU IP block embedded on them, it is
not necessary to maintain separate compatible entry.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index f1e8c9b..7818e2f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -744,9 +744,6 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
 
 static const struct of_device_id exynos_tmu_match[] = {
{
-   .compatible = samsung,exynos3250-tmu,
-   },
-   {
.compatible = samsung,exynos4210-tmu,
},
{
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 18/21] thermal: exynos: Remove exynos_thermal_common.[c|h] files

2014-10-09 Thread Lukasz Majewski
After defining all necessary Exynos data in the device tree
those files can be removed.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_thermal_common.c | 448 
 drivers/thermal/samsung/exynos_thermal_common.h | 106 --
 2 files changed, 554 deletions(-)
 delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
 delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.h

diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
b/drivers/thermal/samsung/exynos_thermal_common.c
deleted file mode 100644
index c306de5..000
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ /dev/null
@@ -1,448 +0,0 @@
-/*
- * exynos_thermal_common.c - Samsung EXYNOS common thermal file
- *
- *  Copyright (C) 2013 Samsung Electronics
- *  Amit Daniel Kachhap amit.dan...@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
- */
-
-#include linux/cpu_cooling.h
-#include linux/err.h
-#include linux/slab.h
-#include linux/thermal.h
-
-#include exynos_thermal_common.h
-
-struct exynos_thermal_zone {
-   enum thermal_device_mode mode;
-   struct thermal_zone_device *therm_dev;
-   struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
-   unsigned int cool_dev_size;
-   struct platform_device *exynos4_dev;
-   struct thermal_sensor_conf *sensor_conf;
-   bool bind;
-};
-
-/* Get mode callback functions for thermal zone */
-static int exynos_get_mode(struct thermal_zone_device *thermal,
-   enum thermal_device_mode *mode)
-{
-   struct exynos_thermal_zone *th_zone = thermal-devdata;
-   if (th_zone)
-   *mode = th_zone-mode;
-   return 0;
-}
-
-/* Set mode callback functions for thermal zone */
-static int exynos_set_mode(struct thermal_zone_device *thermal,
-   enum thermal_device_mode mode)
-{
-   struct exynos_thermal_zone *th_zone = thermal-devdata;
-   if (!th_zone) {
-   dev_err(thermal-device,
-   thermal zone not registered\n);
-   return 0;
-   }
-
-   mutex_lock(thermal-lock);
-
-   if (mode == THERMAL_DEVICE_ENABLED 
-   !th_zone-sensor_conf-trip_data.trigger_falling)
-   thermal-polling_delay = IDLE_INTERVAL;
-   else
-   thermal-polling_delay = 0;
-
-   mutex_unlock(thermal-lock);
-
-   th_zone-mode = mode;
-   thermal_zone_device_update(thermal);
-   dev_dbg(th_zone-sensor_conf-dev,
-   thermal polling set for duration=%d msec\n,
-   thermal-polling_delay);
-   return 0;
-}
-
-
-/* Get trip type callback functions for thermal zone */
-static int exynos_get_trip_type(struct thermal_zone_device *thermal, int trip,
-enum thermal_trip_type *type)
-{
-   struct exynos_thermal_zone *th_zone = thermal-devdata;
-   int max_trip = th_zone-sensor_conf-trip_data.trip_count;
-   int trip_type;
-
-   if (trip  0 || trip = max_trip)
-   return -EINVAL;
-
-   trip_type = th_zone-sensor_conf-trip_data.trip_type[trip];
-
-   if (trip_type == SW_TRIP)
-   *type = THERMAL_TRIP_CRITICAL;
-   else if (trip_type == THROTTLE_ACTIVE)
-   *type = THERMAL_TRIP_ACTIVE;
-   else if (trip_type == THROTTLE_PASSIVE)
-   *type = THERMAL_TRIP_PASSIVE;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-/* Get trip temperature callback functions for thermal zone */
-static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int trip,
-   unsigned long *temp)
-{
-   struct exynos_thermal_zone *th_zone = thermal-devdata;
-   int max_trip = th_zone-sensor_conf-trip_data.trip_count;
-
-   if (trip  0 || trip = max_trip)
-   return -EINVAL;
-
-   *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
-   /* convert the temperature into millicelsius */
-   *temp = *temp * MCELSIUS;
-
-   return 0;
-}
-
-/* Get critical temperature callback functions for thermal zone */
-static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
-   unsigned long *temp)
-{
-   struct exynos_thermal_zone 

[PATCH 19/21] thermal: exynos: Remove exynos_tmu_data.c file

2014-10-09 Thread Lukasz Majewski
Data already present in the exynos_tmu_data.c file has been moved to the
appropriate device tree files.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu_data.c | 228 --
 1 file changed, 228 deletions(-)
 delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.c

diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
deleted file mode 100644
index a993f3d..000
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * exynos_tmu_data.c - Samsung EXYNOS tmu data file
- *
- *  Copyright (C) 2013 Samsung Electronics
- *  Amit Daniel Kachhap amit.dan...@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
- */
-
-#include exynos_thermal_common.h
-#include exynos_tmu.h
-
-struct exynos_tmu_init_data const exynos4210_default_tmu_data = {
-   .tmu_data = {
-   {
-   .threshold = 80,
-   .trigger_levels[0] = 5,
-   .trigger_levels[1] = 20,
-   .trigger_levels[2] = 30,
-   .trigger_enable[0] = true,
-   .trigger_enable[1] = true,
-   .trigger_enable[2] = true,
-   .trigger_enable[3] = false,
-   .trigger_type[0] = THROTTLE_ACTIVE,
-   .trigger_type[1] = THROTTLE_ACTIVE,
-   .trigger_type[2] = SW_TRIP,
-   .max_trigger_level = 4,
-   .non_hw_trigger_levels = 3,
-   .gain = 15,
-   .reference_voltage = 7,
-   .cal_type = TYPE_ONE_POINT_TRIMMING,
-   .min_efuse_value = 40,
-   .max_efuse_value = 100,
-   .first_point_trim = 25,
-   .second_point_trim = 85,
-   .default_temp_offset = 50,
-   .type = SOC_ARCH_EXYNOS4210,
-   },
-   },
-   .tmu_count = 1,
-};
-
-#define EXYNOS3250_TMU_DATA \
-   .threshold_falling = 10, \
-   .trigger_levels[0] = 70, \
-   .trigger_levels[1] = 95, \
-   .trigger_levels[2] = 110, \
-   .trigger_levels[3] = 120, \
-   .trigger_enable[0] = true, \
-   .trigger_enable[1] = true, \
-   .trigger_enable[2] = true, \
-   .trigger_enable[3] = false, \
-   .trigger_type[0] = THROTTLE_ACTIVE, \
-   .trigger_type[1] = THROTTLE_ACTIVE, \
-   .trigger_type[2] = SW_TRIP, \
-   .trigger_type[3] = HW_TRIP, \
-   .max_trigger_level = 4, \
-   .non_hw_trigger_levels = 3, \
-   .gain = 8, \
-   .reference_voltage = 16, \
-   .noise_cancel_mode = 4, \
-   .cal_type = TYPE_TWO_POINT_TRIMMING, \
-   .efuse_value = 55, \
-   .min_efuse_value = 40, \
-   .max_efuse_value = 100, \
-   .first_point_trim = 25, \
-   .second_point_trim = 85, \
-   .default_temp_offset = 50
-
-struct exynos_tmu_init_data const exynos3250_default_tmu_data = {
-   .tmu_data = {
-   {
-   EXYNOS3250_TMU_DATA,
-   .type = SOC_ARCH_EXYNOS3250,
-   },
-   },
-   .tmu_count = 1,
-};
-
-#define EXYNOS4412_TMU_DATA \
-   .threshold_falling = 10, \
-   .trigger_levels[0] = 70, \
-   .trigger_levels[1] = 95, \
-   .trigger_levels[2] = 110, \
-   .trigger_levels[3] = 120, \
-   .trigger_enable[0] = true, \
-   .trigger_enable[1] = true, \
-   .trigger_enable[2] = true, \
-   .trigger_enable[3] = false, \
-   .trigger_type[0] = THROTTLE_ACTIVE, \
-   .trigger_type[1] = THROTTLE_ACTIVE, \
-   .trigger_type[2] = SW_TRIP, \
-   .trigger_type[3] = HW_TRIP, \
-   .max_trigger_level = 4, \
-   .non_hw_trigger_levels = 3, \
-   .gain = 8, \
-   .reference_voltage = 16, \
-   .noise_cancel_mode = 4, \
-   .cal_type = TYPE_ONE_POINT_TRIMMING, \
-   .efuse_value = 55, \
-   .min_efuse_value = 40, \
-   .max_efuse_value = 100, \
-   .first_point_trim = 25, \
-   .second_point_trim = 85, \
-   .default_temp_offset = 50
-
-struct exynos_tmu_init_data const exynos4412_default_tmu_data = {
-   .tmu_data = {
-   {
-   EXYNOS4412_TMU_DATA,
-   .type = SOC_ARCH_EXYNOS4412,
-   },
-   },
-   

[PATCH 15/21] thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440

2014-10-09 Thread Lukasz Majewski
This commit provides information about Exynos5440 device configuration.
Previously this information was available in exynos_tmu_data.c file.
Now it is available in the device tree.
Such approach allows reusing some common code for thermal.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 25 +++
 arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 +++
 2 files changed, 50 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi

diff --git a/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi 
b/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
new file mode 100644
index 000..336cb12
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos5440 TMU sensor configuration
+ *
+ * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include dt-bindings/thermal/thermal_exynos.h
+
+#thermal-sensor-cells = 0;
+gain = 5;
+reference_voltage = 16;
+noise_cancel_mode = 4;
+efuse_value = 0x5d2d;
+min_efuse_value = 16;
+max_efuse_value = 76;
+first_point_trim = 25;
+second_point_trim = 70;
+default_temp_offset = 25;
+cal_type = TYPE_ONE_POINT_TRIMMING;
+type = SOC_ARCH_EXYNOS5440;
diff --git a/arch/arm/boot/dts/exynos5440-trip-points.dtsi 
b/arch/arm/boot/dts/exynos5440-trip-points.dtsi
new file mode 100644
index 000..48adfa8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-trip-points.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for default Exynos5440 thermal zone definition
+ *
+ * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+polling-delay-passive = 0;
+polling-delay = 0;
+trips {
+   cpu-alert-0 {
+   temperature = 10; /* millicelsius */
+   hysteresis = 0; /* millicelsius */
+   type = active;
+   };
+   cpu-crit-0 {
+   temperature = 105; /* millicelsius */
+   hysteresis = 0; /* millicelsius */
+   type = critical;
+   };
+};
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-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 16/21] thermal: exynos: dts: Provide device tree bindings identical to one in exynos_tmu_data.c

2014-10-09 Thread Lukasz Majewski
Presented device tree bindings provide data already hardcoded in the
exynos_tmu_data.c file.
After this commit, it should be possible to reuse common thermal core
framework in Exynos SoCs.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi|  5 +
 arch/arm/boot/dts/exynos4210.dtsi | 23 ++-
 arch/arm/boot/dts/exynos4x12.dtsi |  3 +++
 arch/arm/boot/dts/exynos5250.dtsi |  7 +--
 arch/arm/boot/dts/exynos5420.dtsi | 33 +
 arch/arm/boot/dts/exynos5440.dtsi | 18 ++
 6 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e0278ec..1735bb3 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -21,6 +21,7 @@
 
 #include dt-bindings/clock/exynos4.h
 #include dt-bindings/clock/exynos-audss-clk.h
+#include dt-bindings/thermal/thermal_exynos.h
 #include skeleton.dtsi
 
 / {
@@ -645,4 +646,8 @@
samsung,sysreg = sys_reg;
status = disabled;
};
+
+   tmu: tmu@100C {
+   #include exynos4412-tmu-sensor-conf.dtsi
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 10e8915..1c52681 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -21,6 +21,8 @@
 
 #include exynos4.dtsi
 #include exynos4210-pinctrl.dtsi
+#include exynos4-cpu-thermal.dtsi
+#include dt-bindings/thermal/thermal_exynos.h
 
 / {
compatible = samsung,exynos4210, samsung,exynos4;
@@ -146,16 +148,35 @@
reg = 0x0386 0x1000;
};
 
-   tmu@100C {
+   tmu: tmu@100C {
compatible = samsung,exynos4210-tmu;
interrupt-parent = combiner;
reg = 0x100C 0x100;
interrupts = 2 4;
clocks = clock CLK_TMU_APBIF;
clock-names = tmu_apbif;
+   gain = 15;
+   reference_voltage = 7;
+   type = SOC_ARCH_EXYNOS4210;
status = disabled;
};
 
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = 85000; /* millicelsius */
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = 10; /* millicelsius */
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = 11; /* millicelsius */
+ };
+   };
+   };
+   };
+
g2d@1280 {
compatible = samsung,s5pv210-g2d;
reg = 0x1280 0x1000;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c12890c..a7dda7e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -19,6 +19,8 @@
 
 #include exynos4.dtsi
 #include exynos4x12-pinctrl.dtsi
+#include exynos4-cpu-thermal.dtsi
+#include dt-bindings/thermal/thermal_exynos.h
 
 / {
aliases {
@@ -279,6 +281,7 @@
interrupts = 2 4;
clocks = clock 383;
clock-names = tmu_apbif;
+   type = SOC_ARCH_EXYNOS4412;
status = disabled;
};
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index c322fb9..e71ec78 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -20,8 +20,9 @@
 #include dt-bindings/clock/exynos5250.h
 #include exynos5.dtsi
 #include exynos5250-pinctrl.dtsi
-
+#include exynos4-cpu-thermal.dtsi
 #include dt-bindings/clock/exynos-audss-clk.h
+#include dt-bindings/thermal/thermal_exynos.h
 
 / {
compatible = samsung,exynos5250, samsung,exynos5;
@@ -236,12 +237,14 @@
status = disabled;
};
 
-   tmu@1006 {
+   tmu: tmu@1006 {
compatible = samsung,exynos5250-tmu;
reg = 0x1006 0x100;
interrupts = 0 65 0;
clocks = clock CLK_TMU;
clock-names = tmu_apbif;
+   type = SOC_ARCH_EXYNOS5250;
+   #include exynos4412-tmu-sensor-conf.dtsi
};
 
thermal-zones {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..4bebc6f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -756,6 +756,8 @@
interrupts = 0 65 0;
clocks = clock CLK_TMU;
clock-names = tmu_apbif;
+   #include exynos4412-tmu-sensor-conf.dtsi
+   type = SOC_ARCH_EXYNOS5420;
};
 
tmu_cpu1: 

[PATCH 13/21] thermal: dts: Default trip points definition for Exynos5420 SoCs

2014-10-09 Thread Lukasz Majewski
This code groups in one place default settings of trip points. It is used
in SoCs with multiple instances of TMU sensor.

Separate device tree file prevents from multiple copying of the same data.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5420-trip-points.dtsi

diff --git a/arch/arm/boot/dts/exynos5420-trip-points.dtsi 
b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
new file mode 100644
index 000..09d6c56
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
@@ -0,0 +1,35 @@
+/*
+ * Device tree sources for default Exynos 5420 thermal zone definition
+ *
+ * Copyright (c) 2014 Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+polling-delay-passive = 0;
+polling-delay = 0;
+trips {
+   cpu-alert-0 {
+   temperature = 85000; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu-alert-1 {
+   temperature = 103000; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu-alert-2 {
+   temperature = 11; /* millicelsius */
+   hysteresis = 1; /* millicelsius */
+   type = active;
+   };
+   cpu-crit-0 {
+   temperature = 120; /* millicelsius */
+   hysteresis = 0; /* millicelsius */
+   type = critical;
+   };
+};
-- 
2.0.0.rc2

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


Re: [PATCH 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards

2014-10-09 Thread Mark Brown
On Thu, Oct 09, 2014 at 04:27:37PM +0200, Javier Martinez Canillas wrote:

 I see, I thought that an operating mode could be anything that alter the
 regulator behavior either during runtime or when the system is suspended.
 But under your definition, it is true that most max77802 regulators have

It's not just me, it's the code and all the users and documentation...

 only two modes: ON and OFF (and some of them have a third Low Power mode).

...but let's be clear, only on (normal) and low power are modes here.
Like I keep saying please think things through - if modes also include
enable control why would they be treated separately in the API?

 I think though that a generic way to configure this enable control feature
 is needed. Maybe adding a new pair of .{get,set}_suspend_control function
 pointers to struct regulator_ops and an .initial_suspend_ctrl field to the
 struct regulation_constraints?

 That way the core could parse a generic DT property and call the function
 handlers but each driver can document in their own DT bindings what their
 control values are and how those affects the regulators during suspend?

That maps poorly onto a lot of devices which have control schemes which
are more complex than this, for example placing regulators into groups
which are then controlled en masse or with internal sequencing options.
There's also the general taste thing with an API that basically just
consists of passing a random value through - there's a lack of
generality there, it wouldn't be possible to write a generic user of the
API which is a bit of a warning sign.

If you just care about the specific this pin controls enable in sleep
state I'd suggest making an interface that very specifically does that.


signature.asc
Description: Digital signature


[PATCH 1/1] ARM: exynos_defconfig: re-enable USB gadget and max77802 options

2014-10-09 Thread Javier Martinez Canillas
Commit 43eeaa42e03a (ARM: exynos_defconfig: savedefconfig) removed a
set of Kconfig symbols. For most of them there were no functional change
since are selected by other Kconfig options or were deprecated but some
options are not explicitly selected so they should not had been removed.

The options that have to be enabled are USB gadget and the MAX77802 PMIC
support which were enabled in commits:

508423bebcda (ARM: exynos_defconfig: enable USB gadget support)
6e80e3d87549 (ARM: exynos_defconfig: Enable MAX77802)

Enable those options to leave the config in the state before the change.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/configs/exynos_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index b14d8c3..a36fe1c 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -54,6 +54,7 @@ CONFIG_SMSC911X=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_GADGET=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_CROS_EC=y
@@ -97,6 +98,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_REGULATOR_MAX8997=y
 CONFIG_REGULATOR_MAX77686=y
+CONFIG_REGULATOR_MAX77802=y
 CONFIG_REGULATOR_MAX77693=y
 CONFIG_REGULATOR_S2MPA01=y
 CONFIG_REGULATOR_S2MPS11=y
@@ -133,11 +135,13 @@ CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MAX77686=y
+CONFIG_RTC_DRV_MAX77802=y
 CONFIG_RTC_DRV_S5M=y
 CONFIG_RTC_DRV_S3C=y
 CONFIG_DMADEVICES=y
 CONFIG_PL330_DMA=y
 CONFIG_COMMON_CLK_MAX77686=y
+CONFIG_COMMON_CLK_MAX77802=y
 CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_EXYNOS_IOMMU=y
 CONFIG_IIO=y
-- 
2.1.0

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


Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support

2014-10-09 Thread Mark Brown
On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote:

 Agree, Mark also pointed out that there is a difference between changing
 how the regulator will behave on runtime vs changing how the regulator
 will behave during system suspend. AFAIU from his explanation, the modes
 defined in consumer.h only applies to the former and conceptually there
 should be a difference between those two cases even when the Maxim PMIC
 seems to mix it both in the data-sheet and by using the same field.

No, that's not accurate at all - you're still not getting the concepts
of modes or suspend handling in the regulator API.  I really think you
need to take a step back and try to understand what's currently there
before trying to make changes here.  We've got a set of operations we
can use to change the regulator configuration, if you look at the
existing driver interface you'll see that these are matched with
equivalent operations for setting the behaviour when in suspend
(including a set_suspend_mode() operation).  

Like I keep saying abstractions are really important to making sure the
code is maintainable.


signature.asc
Description: Digital signature


Re: [PATCH 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards

2014-10-09 Thread Javier Martinez Canillas
Hello Mark,

Thanks for your feedback.

On 10/09/2014 07:48 PM, Mark Brown wrote:
 On Thu, Oct 09, 2014 at 04:27:37PM +0200, Javier Martinez Canillas wrote:
 
 I see, I thought that an operating mode could be anything that alter the
 regulator behavior either during runtime or when the system is suspended.
 But under your definition, it is true that most max77802 regulators have
 
 It's not just me, it's the code and all the users and documentation...
 

Sorry, I didn't mean that you are not correct but more that I was wrong
on my assumptions.

 only two modes: ON and OFF (and some of them have a third Low Power mode).
 
 ...but let's be clear, only on (normal) and low power are modes here.
 Like I keep saying please think things through - if modes also include
 enable control why would they be treated separately in the API?
 

Right, I got confused again by the terminology in the Maxim data-sheet that
list output OFF as an opmode but I understand that OFF is not a mode and
that the regulator API treats it separately.

 I think though that a generic way to configure this enable control feature
 is needed. Maybe adding a new pair of .{get,set}_suspend_control function
 pointers to struct regulator_ops and an .initial_suspend_ctrl field to the
 struct regulation_constraints?
 
 That way the core could parse a generic DT property and call the function
 handlers but each driver can document in their own DT bindings what their
 control values are and how those affects the regulators during suspend?
 
 That maps poorly onto a lot of devices which have control schemes which
 are more complex than this, for example placing regulators into groups
 which are then controlled en masse or with internal sequencing options.
 There's also the general taste thing with an API that basically just
 consists of passing a random value through - there's a lack of
 generality there, it wouldn't be possible to write a generic user of the
 API which is a bit of a warning sign.
 
 If you just care about the specific this pin controls enable in sleep
 state I'd suggest making an interface that very specifically does that.
 

Yes, I'll not try to make it generic and will do something that is specific
to this device.

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 v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-09 Thread Kevin Hilman
Javier Martinez Canillas jav...@dowhile0.org writes:

 Hello Abhilash,

 On Thu, Oct 9, 2014 at 4:37 AM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Kevin,

 On Thu, Oct 9, 2014 at 4:49 AM, Kevin Hilman khil...@kernel.org wrote:
 Vikas Sajjan vikas.saj...@samsung.com writes:

 [...]

 Tested on Kukjin Kim's tree, for-next branch +
 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html
 2] 
 https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html
 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK

 on Exynos5420 based chromebook (peach-pit board)

 Below procedures were followed to test S2R:
 Procedure A:
   1. make multi_v7_defconfig
   2  enable MCPM for 5420
   3. enable S3C RTC
   5. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
 /sys/power/state
 Procedure B:
   1. make exynos_defconfig
   4. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
 /sys/power/state

 I went tried to this on exynos5800-peach-pi and found first that
 exynos_defonfig is missing the MAX77802 kconfig options for the RTC
 source clock:

 CONFIG_REGULATOR_MAX77802=y
 CONFIG_COMMON_CLK_MAX77802=y

 I am using exynos_defconfig (no changes) with the internal SoC RTC
 which is enabled by default. I did not enable the MAX77802 RTC.

 That is because you probably are using kukjin's for-next branch as a
 base but I had the same issue when testing s2r on linux-next.

 The problem is that linux-next contains commit 546b117fdf17 (rtc:
 s3c: add support for RTC of Exynos3250 SoC) that added a required
 rtc_src DT property for the Samsung's S3C RTC that is used to
 specify the source clock XrtcXTI.

 On Peach boards, the S3C source clock is the max77802 32kHZ AP clock
 so I fixed that with commit 8bd43b6 (ARM: dts: Add rtc_src clk for
 s3c-rtc on exynos Peach boards) but didn't send a patch to enable the
 max77802 subdevices on exynos_defconfig.

 I'll post a patch to enable those config options today and maybe they
 can be considered as -rc material.

Great, thanks.


 With those, rtc0 then comes up, but isn't waking from suspend.  However,
 writing something to rtc0/wakealarm does result in /proc/interrupts
 having an interrupt for the RTC, it's just not waking the system.

 Anyone else tried this on 5800/peach-pi?

 I have tested this on a Peach-Pi and the system is resuming fine. The
 patches applied on kgene's for-next branch along with the
 aclk200_disp1 fix are:
 http://lkml.org/lkml/2014/9/30/156
 https://lkml.org/lkml/2014/10/6/89
 http://www.spinics.net/lists/arm-kernel/msg368207.html
 http://www.spinics.net/lists/linux-samsung-soc/msg37647.html


 Kevin, I didn't test it on 5800 peach pi but I did test it on 5420
 peach pit and as Abhilash said, I also needed Vikas patch [0] to flag
 the aclk200_disp1 and aclk300_disp1 clocks as CLK_IGNORE_UNUSED to
 prevent the ccf to disable them. With that patch Suspend-to-Ram worked
 for me and resuming using both the internal S3C RTC and the max77802
 RTC.

 Also I tested the pm_tests and all of them passed on my peach pit.

 On peach pi you shouldn't need the clock patch AFAIU if you enable the
 needed kconfig options to have display working since those clocks are
 used by the display controller so they won't be disabled due unused.

Thanks for the explanation. 

Trying $SUBJECT series on top of kukjin's for-next is working fine, but
I'm still not able to make it work on linux-next, with or without the
CLK_IGNORE_UNUSED patch.

Abhilash, can you try this on exynos5800/peach-pi with linux-next and
see what else is missing from linux-next?  It would be really nice to
get this fully working upstream.

Note also the enabling CPUidle depends on $SUBJECT series as well.

Kevin


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


Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support

2014-10-09 Thread Javier Martinez Canillas
On 10/09/2014 09:01 PM, Mark Brown wrote:
 On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote:
 
 Agree, Mark also pointed out that there is a difference between changing
 how the regulator will behave on runtime vs changing how the regulator
 will behave during system suspend. AFAIU from his explanation, the modes
 defined in consumer.h only applies to the former and conceptually there
 should be a difference between those two cases even when the Maxim PMIC
 seems to mix it both in the data-sheet and by using the same field.
 
 No, that's not accurate at all - you're still not getting the concepts
 of modes or suspend handling in the regulator API.  I really think you
 need to take a step back and try to understand what's currently there
 before trying to make changes here.  We've got a set of operations we
 can use to change the regulator configuration, if you look at the
 existing driver interface you'll see that these are matched with
 equivalent operations for setting the behaviour when in suspend
 (including a set_suspend_mode() operation).  
 

I tried to say that there is a difference between the need to change
within the kernel a regulator configuration (e.g: change opmode from
normal to low power) when the system is going to enter in suspend state
vs setting a register at probe time that will force the PMIC to change
the regulator to low power mode on suspend without kernel intervention.

 Like I keep saying abstractions are really important to making sure the
 code is maintainable.
 

Agree, I'll try to come up with a more sensible solution by using the
existing abstractions from the regulator framework.

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: exynos5422-odroid-xu3: MCPM: only 6 of 8 CPUs coming online

2014-10-09 Thread Kevin Hilman
Hi Abhilash,

Abhilash Kesavan a.kesa...@samsung.com writes:

 I had noticed a similar issue where only 6 cores would come up during
 development on 5420. This was because there was a check in our u-boot
 secondary boot-up path which would put a core into WFI if a flag was
 not present and hence fail to boot. I wonder if it is the same
 situation in your case too.
 Is the u-boot for odroid-xu3 publically available or can you check if there 
 is any such code present in your secondary bring-up path.

I'm using the hardkernel u-boot[1], branch: odroidxu3-v2012.07.  I'm
currently using the pre-built binaries that are in the
sd_fuse/hardkernel directory of that branch, but I can rebuild u-boot if
needed.

I'm not very familiar with u-boot, but if f you have some pointers where
to start looking in that code, that would be helpful.

Kevin

[1] https://github.com/hardkernel/u-boot.git

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


Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-09 Thread Javier Martinez Canillas
Hello Kevin,

On Thu, Oct 9, 2014 at 11:50 PM, Kevin Hilman khil...@kernel.org wrote:

 On Peach boards, the S3C source clock is the max77802 32kHZ AP clock
 so I fixed that with commit 8bd43b6 (ARM: dts: Add rtc_src clk for
 s3c-rtc on exynos Peach boards) but didn't send a patch to enable the
 max77802 subdevices on exynos_defconfig.

 I'll post a patch to enable those config options today and maybe they
 can be considered as -rc material.

 Great, thanks.


Now I remember why I didn't enable those options at the time and it
was because Vivek Gautam already did. Now, I see that the max77802
config options were removed on a later patch, probably by mistake.

So I posted a patch [0] to re-enable those options but it seems I
forgot to cc you, sorry about that.

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/10/9/413
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-09 Thread Kevin Hilman
Kevin Hilman khil...@kernel.org writes:

[...]

 Trying $SUBJECT series on top of kukjin's for-next is working fine, but
 I'm still not able to make it work on linux-next, with or without the
 CLK_IGNORE_UNUSED patch.

Nevermind, turns out I didn't apply the CLK_IGNORE_UNUSED PATCH.  If I
actually apply it, I have it working on top of linux-next.  However, it
seems to have some issues with the nonboot CPUs resuming:

[   11.319833] Enabling non-boot CPUs ...
[   12.319134] CPU1: failed to come online
[   12.319235] Error taking CPU1 up: -5
[   13.319137] CPU2: failed to come online
[   13.319209] Error taking CPU2 up: -5
[   14.319133] CPU3: failed to come online
[   14.319224] Error taking CPU3 up: -5

Are you guys seeing all the non-boot CPUs coming up?  They fail to come
online, but the /sys/devices/.../cpu?/online reports that they are
online, which means the next attempt to hotplug them will probably BUG().

Also, If I turn off the switcher (enabled by default exynos_defconfig),
resume still has problems bringing all the nonboot CPUs online, and then
has a bunch of I2C errors[1].

And one more..., if I try enabling CPUidle[1] with exynos_defconfig, S2R
causes a reboot (seems to be on resume.)

Kevin


[1] 
[   47.644273] cros-ec-spi spi2.0: EC failed to respond in time
[   47.648535] cros-ec-spi spi2.0: spi transfer failed: -110
[   47.653866] tps65090-charger tps65090-charger: tps65090_charger_isr(): Error 
in reading reg 0xa

[2]
CONFIG_CPU_IDLE=y
CONFIG_ARM_BIG_LITTLE_CPUIDLE=y
CONFIG_ARM_EXYNOS_CPUIDLE=n

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


Re: [PATCH 1/1] ARM: exynos_defconfig: re-enable USB gadget and max77802 options

2014-10-09 Thread Kevin Hilman
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Commit 43eeaa42e03a (ARM: exynos_defconfig: savedefconfig) removed a
 set of Kconfig symbols. For most of them there were no functional change
 since are selected by other Kconfig options or were deprecated but some
 options are not explicitly selected so they should not had been removed.

 The options that have to be enabled are USB gadget and the MAX77802 PMIC
 support which were enabled in commits:

 508423bebcda (ARM: exynos_defconfig: enable USB gadget support)
 6e80e3d87549 (ARM: exynos_defconfig: Enable MAX77802)

 Enable those options to leave the config in the state before the change.

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

Acked-by: Kevin Hilman khil...@linaro.org
Tested-by: Kevin Hilman khil...@linaro.org

This is needed to get RTC wakeup from suspend working on
exynos5800-peach-pi.

Note that the s3c-rtc works fine, but the max77802-rtc doesn't seem to
work be functional for me:

[2.408178] max77802-rtc max77802-rtc: rtc core: registered max77802-rtc as 
rtc0
[3.595485] s3c-rtc 101e.rtc: rtc core: registered s3c as rtc1

root@(none):/# hwclock --rtc /dev/rtc0
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed:
Invalid argument
root@(none):/# hwclock --rtc /dev/rtc1
Thu Oct  9 23:33:06 2014  -0.111978 seconds

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


Re: [PATCH 21/21] thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412

2014-10-09 Thread Chanwoo Choi
On 10/10/2014 01:38 AM, Lukasz Majewski wrote:
 Since both SoCs have the same TMU IP block embedded on them, it is
 not necessary to maintain separate compatible entry.
 
 Signed-off-by: Lukasz Majewski l.majew...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c | 3 ---
  1 file changed, 3 deletions(-)
 
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index f1e8c9b..7818e2f 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -744,9 +744,6 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
  
  static const struct of_device_id exynos_tmu_match[] = {
   {
 - .compatible = samsung,exynos3250-tmu,
 - },
 - {

If you want to remove compatible string for Exynos3250,
you have to modify it on exynos3250.dtsi.

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


Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-09 Thread Abhilash Kesavan
Hi Kevin,

On Fri, Oct 10, 2014 at 4:29 AM, Kevin Hilman khil...@kernel.org wrote:
 Kevin Hilman khil...@kernel.org writes:

 [...]

 Trying $SUBJECT series on top of kukjin's for-next is working fine, but
 I'm still not able to make it work on linux-next, with or without the
 CLK_IGNORE_UNUSED patch.

 Nevermind, turns out I didn't apply the CLK_IGNORE_UNUSED PATCH.  If I
 actually apply it, I have it working on top of linux-next.  However, it
 seems to have some issues with the nonboot CPUs resuming:

 [   11.319833] Enabling non-boot CPUs ...
 [   12.319134] CPU1: failed to come online
 [   12.319235] Error taking CPU1 up: -5
 [   13.319137] CPU2: failed to come online
 [   13.319209] Error taking CPU2 up: -5
 [   14.319133] CPU3: failed to come online
 [   14.319224] Error taking CPU3 up: -5

 Are you guys seeing all the non-boot CPUs coming up?  They fail to come
 online, but the /sys/devices/.../cpu?/online reports that they are
 online, which means the next attempt to hotplug them will probably BUG().

 Also, If I turn off the switcher (enabled by default exynos_defconfig),
 resume still has problems bringing all the nonboot CPUs online, and then
 has a bunch of I2C errors[1].

 And one more..., if I try enabling CPUidle[1] with exynos_defconfig, S2R
 causes a reboot (seems to be on resume.)

I tested S2R on my Peach-Pi (Exynos5800) on linux-next-20141009. My tree has:

a57db95 TEMP: Use CLK_IGNORE_UNUSED for aclk200_disp1
18158ac ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
d86cb2d ARM: exynos5: Add Suspend-to-RAM support for 5420
93f1b7c ARM: exynos5: Add PMU support for 5420
8dcc2db ARM: EXYNOS: Move PMU specific definitions from common.h
493a16a ARM: EXYNOS: Add platform driver support for Exynos PMU
64e73fb mfd: syscon: Decouple syscon interface from platform devices
af7b574 Add linux-next specific files for 20141009
4658bc0 Merge branch 'akpm/master'
9784a19 mm: add strictlimit knob

I have tested the following scenarios using exynos_defconfig with
CONFIG_COMMON_CLK_MAX77802 enabled:

1) CONFIG_BIG_LITTLE enabled (default in exynos_defconfig)
2) CONFIG_BIG_LITTLE disabled
3) CONFIG_ARM_BIG_LITTLE_CPUIDLE enabled

In all 3 cases the secondary cores as well as the system resume fine.
Can you please confirm if your kernel has a similar configuration ?

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