RE: [PATCH 0/6] Samsung watchdog support clean-up

2013-06-04 Thread Kukjin Kim 
Tomasz Figa wrote:
 
 Hi Sylwester, Kukjin,
 
Hi,

 On Saturday 01 of June 2013 10:16:52 Sylwester Nawrocki wrote:
  Hi Tomasz,
 
  On 05/19/2013 12:37 AM, Tomasz Figa wrote:
   This series is aiming at cleaning up a bit watchdog support on Samsung
   SoCs. The patches tweak a bit all the watchdog handling code here and
   there, with the goal of making it DT- and multiplatform-friendly.
  
   See particular patches for more detailed descriptions.
  
   On S3C6410-based Tiny6410 board (Mini6410-compatible):
  
   Tested-by: Tomasz Figatomasz.f...@gmail.com
 
  I've tested this series on a s3c2440 based board. The system restart
  works fine.
 
  Tested-by: Sylwester Nawrocki sylvester.nawro...@gmail.com
 
 Thank you Sylwester for testing this series.
 
Thanks again :-)

 Kukjin, since it has been already tested on s3c24xx and s3c64xx and nobody
 seems to care about s5p64x0 and s5pc100 (although I don't see a reason why
 these patches should break them), could we have this series applied?
 
OK, let me test this series on the smdk64x0 then, will apply.

If any problems, let you know.

Thanks for your gentle reminder.

- Kukjin

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

Re: [PATCH] ARM: EXYNOS: Consolidate multiple low-level UART port definitions

2013-06-04 Thread Tushar Behera 
On 05/31/2013 11:50 PM, Kevin Hilman wrote:
 Tushar Behera tushar.beh...@linaro.org writes:
 
 There are two definitions for low-level UART ports for Exynos platform.
 CONFIG_S3C_LOWLEVEL_UART_PORT is used for printing Uncompressing
 Linux... done, booting the kernel. and CONFIG_S3C_UART for other
 low-level messages.

 The assumption for both the uart ports is that they are pre-configured
 in the bootloader. Since they are essentially the same always, it
 would be good to consolidate them to use only one macro, in this case
 'DEBUG_S3C_UART' would be a better option.

 'DEBUG_S3C_UART' is defined only if DEBUG_LL is enabled. We can safely
 disable this option when DEBUG_LL is not defined and we can boot various
 boards with different UART port settings. Only drawback of this
 approach is that when DEBUG_LL is not defined, we would be missing the
 print Uncompressing Linux... done, booting the kernel.
 
 Perfectly acceptable to me (and already the case on OMAP.)
 
 Since CONFIG_S3C_LOWLEVEL_UART_PORT is still used by other Samsung
 boards, the consolidation applies only for ARCH_EXYNOS.

 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 
 Acked-by: Kevin Hilman khil...@linaro.org
 

Thanks Kevin.

I have an updated version of this patch updated for all of Samsung
platforms.[1]

[1] http://www.gossamer-threads.com/lists/linux/kernel/1723429

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

Re: [PATCH 0/6] Samsung watchdog support clean-up

2013-06-04 Thread Tomasz Figa 
Hi Kukjin,

On Tuesday 04 of June 2013 18:37:54 Kukjin Kim wrote:
 Tomasz Figa wrote:
  Hi Sylwester, Kukjin,
 
 Hi,
 
  On Saturday 01 of June 2013 10:16:52 Sylwester Nawrocki wrote:
   Hi Tomasz,
   
   On 05/19/2013 12:37 AM, Tomasz Figa wrote:
This series is aiming at cleaning up a bit watchdog support on Samsung
SoCs. The patches tweak a bit all the watchdog handling code here and
there, with the goal of making it DT- and multiplatform-friendly.

See particular patches for more detailed descriptions.

On S3C6410-based Tiny6410 board (Mini6410-compatible):

Tested-by: Tomasz Figatomasz.f...@gmail.com
   
   I've tested this series on a s3c2440 based board. The system restart
   works fine.
   
   Tested-by: Sylwester Nawrocki sylvester.nawro...@gmail.com
  
  Thank you Sylwester for testing this series.
 
 Thanks again :-)
 
  Kukjin, since it has been already tested on s3c24xx and s3c64xx and nobody
  seems to care about s5p64x0 and s5pc100 (although I don't see a reason why
  these patches should break them), could we have this series applied?
 
 OK, let me test this series on the smdk64x0 then, will apply.
 
 If any problems, let you know.
 
 Thanks for your gentle reminder.

Thank you for handling this. I have a lot of patches for S3C64xx depending on 
this series queued in my private tree and it would be really nice if I could 
finally get them merged for 3.11.

Best regards,
-- 
Tomasz Figa
Linux Kernel Developer
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] ARM: s5p64x0: Use common uncompress.h part for plat-samsung

2013-06-04 Thread Tushar Behera 
On 05/19/2013 04:01 AM, Tomasz Figa wrote:
 Since uart_base can be set dynamically in arch_detect_cpu(), there is no
 need to have a copy of all code locally, just to override UART base
 address.
 
 This patch removes any duplicate code in uncompress.h variant of s5p64x0
 and implements proper arch_detect_cpu() function to initialize UART with
 SoC-specific parameters.
 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 ---
  arch/arm/mach-s5p64x0/include/mach/uncompress.h | 155 
 +---
  1 file changed, 5 insertions(+), 150 deletions(-)
 

This patch (with a minor modification) has been included in the
patchset[1] to consolidate uncompress subroutine for Samsung platforms.

[1] [PATCH v2 0/3] Consolidate uncompress code for Samsung platform
http://www.gossamer-threads.com/lists/linux/kernel/1723429


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

Re: [PATCH v2 2/5] clk: samsung: Add support to register rate_table for PLL3xxx

2013-06-04 Thread Yadwinder Singh Brar 
Hi Tomasz,

On Mon, Jun 3, 2013 at 8:55 PM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Yadwinder,

 On Thursday 30 of May 2013 12:25:40 Yadwinder Singh Brar wrote:
 Hi Doug,

 On Thu, May 30, 2013 at 5:14 AM, Doug Anderson diand...@chromium.org
 wrote:
  Vikas / Yadwinder,
 
  On Wed, May 29, 2013 at 6:37 AM, Vikas Sajjan vikas.saj...@linaro.org
 wrote:
  From: Yadwinder Singh Brar yadi.b...@samsung.com
 
  This patch defines a common rate_table which will contain recommended p,
  m, s, k values for supported rates that needs to be changed for changing
  corresponding PLL's rate.
 
  Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
  ---
 
   drivers/clk/samsung/clk-exynos4.c|8 
   drivers/clk/samsung/clk-exynos5250.c |   14 +++---
   drivers/clk/samsung/clk-pll.c|   14 --
   drivers/clk/samsung/clk-pll.h|   33
   +++-- 4 files changed, 54 insertions(+), 15
   deletions(-)
 
  I also reviewed this in our gerrit
  https://gerrit.chromium.org/gerrit/#/c/56742/, but I'll summarize
  here for the list...
 
   struct clk * __init samsung_clk_register_pll35xx(const char *name,
 
  -   const char *pname, const void __iomem *base)
  +   const char *pname, const void __iomem *base,
  +   const struct samsung_pll_rate_table *rate_table,
  +   const unsigned int rate_count)
 
  Feels like you should document here that rate_table needs to be sorted
  and the sort order.

 sure,  we will add comment  to sort the table in descending order.

  +struct samsung_pll_rate_table {
  +   unsigned  int rate;
 
  nit: extra space before int should be removed.

 ok

  Also: you can include rate here if you need a convenient place to
  store it (which sadly means that this structure can't be const).
  ...but I do like Tomasz's idea of actually calculating it.  You can't
  know it at compile time since the parent rate comes from the device
  tree.
 
  compatible = samsung,clock-xxti;
  clock-frequency = 2400;

 Actually this table should contain the recommended values
 and if we see the user manual, the input(parent) rate is also a part
 of recommended
 table of different output rate for a particular PLL for that SoC.

 From what I understood in the documentation is that there is a set of
 recommended P, M, S (, K) tuples for each PLL and they are not dependent on
 input frequency - f_in and f_out are provided in the table just for reference
 to see the relation between output frequency and input frequency.


If input rate(f_in) gets changed for PLL, then the corresponding
output rates(f_out)
will change by using same(common) set of  recommended P, M, S (, K),
and the new set of  output rates(f_out) may not be the _required_ set
of target rates.
So we need different set of P, M, S (,K) values for different f_in.

Table should contain set of P, M, S (,K) values for the _required_
target(f_out) rates
for a particular input(f_in) rate.

 I think we should ask some H/W engineer about that to make sure and choose the
 proper implementation, which will work properly for future cases, instead of
 ending with something that works just with current cases.


We already asked hardware engineer about PMS values for PLL,
and we got a table containing recommended  P, M ,S values for a given
f_in(24 MHz)
and required f_out rates.

Please let me know, why you think we are specific to current cases only ?

Regards,
Yadwinder

 Best regards,
 --
 Tomasz Figa
 Linux Kernel Developer
 Samsung RD Institute Poland
 Samsung Electronics

 So as Tomasz said input(parent) rate may change with board,
 then, do those corresponding recommended p, m, s, k will be valid?

 In case, input(parent) rate changes then we may need different set of p, m
 ,s, k values recommended for new input rate to get required(recommended to
 use) output rate.

 So, we think its better that the p, m, s and k along with the parent
 is known at the compile time ( or DT ?),
 as these p, m, s, k values are very much coupled with the parent rate
 to achieve the
  required(recommended to use) output rate.

 Also, since the sorted table is required (sorted based on rate),
 its better to have the rate in a const rate table.

 And the whole set of recommended values should come from same place(DT
 or static table),
 to keep the things simple and consistent.

 Moreover, practically for a particular SoC , we use the recommended
 input(parent) rate only for a PLL.
 So we should keep the things simple here presently.

  +   unsigned int pdiv;
  +   unsigned int mdiv;
  +   unsigned int sdiv;
  +   unsigned int kdiv;
 
  I think kdiv is signed.

 No, as these values should be the recommended values to be written in
 corresponding  register bits. So it should remain unsigned.

 K value should be considered as negative only while recalculating rate.

 As per exynos5250 user manual's section 7.3.2 :
  K value

Re: [PATCH] ARM: EXYNOS: Update defconfig for Arndale and Origen board

2013-06-04 Thread Mark Brown 
On Tue, May 28, 2013 at 10:31:41PM -0700, Olof Johansson wrote:
 On Tue, May 28, 2013 at 8:59 PM, Tushar Behera tushar.beh...@linaro.org 
 wrote:

  e. usb: ehci-s5p: add the HSIC port initialization
  f. ARM: dts: Add USB gpio entries for Arndale board

  I am not sure whether such kind of board-specific patches (e, f) are
  appreciated in the drivers. But that is all we need to get USB and
  Ethernet to work on v3.10-rc3 kernel.

 I've come across a similar situation with wifi reset sequence on the
 chromebook. On the product kernel we added some code to the board file
 to deal with it, but if we keep doing that things will grow out of
 hand.

 I don't know if it'll be unpopular, but I think it's time to start a
 drivers/platform/arm for these kind of things, and have those drivers
 probe on the system compatible value, similar to how x86 does it (with
 DMI tables). At least that's my plan for approaching the wifi
 reset/power-on sequence on the Chromebook. I hope to have patches in
 not all that long...

This does seem to be a fairly general problem for embedded systems with
devices on enumerable buses - it's even worse for things like Slimbus
where the expectation is that many devices will spend almost all of
their time powered down.  We probably need to come up with
infrastructure to enable the drivers for the individual devices to
handle this, or at least roll out such infrastructure more widely, IIRC
there's some DT stuff for PCI.


signature.asc
Description: Digital signature

[PATCH V5 0/5] clk: Samsung: audss: Register audio subsytem clocks using common clk framework

2013-06-04 Thread Padmavathi Venna 
Samsung S5PV210 and Exynos SoC has a separate subsystem for audio. This 
subsystem
has a internal clock controller which controls i2s0 and pcm0 clocks. This patch
series adds the Samsung audio subsytem clock to the common clock framework and
provides the I2S controllers clock information in the dtsi file.

This patch series is made based on Kukjin Kim for-next branch

Changes since V4:
- Reworked on the nits given by Doug.
- Removed mout_audss and mout_i2s from i2s nodes as we are not
  getting these clocks in the i2s driver.
- Modified the I2S binding documentation for clocks and pinmux.

Changes since V3:
- Replaced samsung with exynos in the macro prefixes and function names
  as this driver supports mainly exynos and s5p family.
- Added Reviewed-by:Sylwester Nawrocki s.nawro...@samsung.com

Changes since V2:
- Removed s5pv210 compatible name from driver as it is
  not yet supported which is different from Exynos series
  audio subsystem clock conroller.
- Removed clkdev lookup support and added alias names in
  the i2s0 controller node.
Changes since V1:
- Reworked on all review comments by Sylwester Nawrocki
- Added a header file for all clock indexes as requested by Sylwester
- Added different compatible names for s5pv210, exynos4 and exynos5
- Registered the pcm clocks with common clock framework

Padmavathi Venna (5):
  ARM: samsung: use #include for all device trees
  clk: samsung: register audio subsystem clocks using common clock
framework
  ARM: dts: add Exynos audio subsystem clock controller node
  ARM: dts: add clock provider information for i2s controllers in
Exynos5250
  ARM: dts: Update Samsung I2S documentation

 .../devicetree/bindings/clock/clk-exynos-audss.txt |   64 ++
 .../devicetree/bindings/sound/samsung-i2s.txt  |   40 ++
 arch/arm/boot/dts/exynos4.dtsi |2 +-
 arch/arm/boot/dts/exynos4210-origen.dts|2 +-
 arch/arm/boot/dts/exynos4210-smdkv310.dts  |2 +-
 arch/arm/boot/dts/exynos4210-trats.dts |2 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts|2 +-
 arch/arm/boot/dts/exynos4210.dtsi  |4 +-
 arch/arm/boot/dts/exynos4212.dtsi  |2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts   |2 +-
 arch/arm/boot/dts/exynos4412-origen.dts|2 +-
 arch/arm/boot/dts/exynos4412-smdk4412.dts  |2 +-
 arch/arm/boot/dts/exynos4412.dtsi  |2 +-
 arch/arm/boot/dts/exynos4x12.dtsi  |4 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |2 +-
 arch/arm/boot/dts/exynos5250-snow.dts  |4 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   20 +++-
 arch/arm/boot/dts/exynos5440-sd5v1.dts |2 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |2 +-
 arch/arm/boot/dts/exynos5440.dtsi  |2 +-
 arch/arm/boot/dts/s3c2416-smdk2416.dts |2 +-
 arch/arm/boot/dts/s3c2416.dtsi |4 +-
 arch/arm/boot/dts/s3c24xx.dtsi |2 +-
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos-audss.c |  133 
 include/dt-bindings/clk/exynos-audss-clk.h |   25 
 27 files changed, 279 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
 create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
 create mode 100644 include/dt-bindings/clk/exynos-audss-clk.h

-- 
1.7.4.4

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

[PATCH V5 1/5] ARM: samsung: use #include for all device trees

2013-06-04 Thread Padmavathi Venna 
Replace /include/ (dtc) with #include (C pre-processor) for all
Samsung DT files

Signed-off-by: Padmavathi Venna padm...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi  |2 +-
 arch/arm/boot/dts/exynos4210-origen.dts |2 +-
 arch/arm/boot/dts/exynos4210-smdkv310.dts   |2 +-
 arch/arm/boot/dts/exynos4210-trats.dts  |2 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts |2 +-
 arch/arm/boot/dts/exynos4210.dtsi   |4 ++--
 arch/arm/boot/dts/exynos4212.dtsi   |2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts|2 +-
 arch/arm/boot/dts/exynos4412-origen.dts |2 +-
 arch/arm/boot/dts/exynos4412-smdk4412.dts   |2 +-
 arch/arm/boot/dts/exynos4412.dtsi   |2 +-
 arch/arm/boot/dts/exynos4x12.dtsi   |4 ++--
 arch/arm/boot/dts/exynos5250-arndale.dts|2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts   |2 +-
 arch/arm/boot/dts/exynos5250-snow.dts   |4 ++--
 arch/arm/boot/dts/exynos5250.dtsi   |4 ++--
 arch/arm/boot/dts/exynos5440-sd5v1.dts  |2 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts   |2 +-
 arch/arm/boot/dts/exynos5440.dtsi   |2 +-
 arch/arm/boot/dts/s3c2416-smdk2416.dts  |2 +-
 arch/arm/boot/dts/s3c2416.dtsi  |4 ++--
 arch/arm/boot/dts/s3c24xx.dtsi  |2 +-
 22 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index bed40ee..3f94fe8 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -19,7 +19,7 @@
  * published by the Free Software Foundation.
  */
 
-/include/ skeleton.dtsi
+#include skeleton.dtsi
 
 / {
interrupt-parent = gic;
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index bcf8079..5f851d7 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -15,7 +15,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4210.dtsi
+#include exynos4210.dtsi
 
 / {
model = Insignal Origen evaluation board based on Exynos4210;
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 91332b7..9c01b71 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -15,7 +15,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4210.dtsi
+#include exynos4210.dtsi
 
 / {
model = Samsung smdkv310 evaluation board based on Exynos4210;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 9a14484..94eebff 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -13,7 +13,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4210.dtsi
+#include exynos4210.dtsi
 
 / {
model = Samsung Trats based on Exynos4210;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 345cdb5..889cdad 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -13,7 +13,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4210.dtsi
+#include exynos4210.dtsi
 
 / {
model = Samsung Universal C210 based on Exynos4210 rev0;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 366795a..75c2756 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -19,8 +19,8 @@
  * published by the Free Software Foundation.
 */
 
-/include/ exynos4.dtsi
-/include/ exynos4210-pinctrl.dtsi
+#include exynos4.dtsi
+#include exynos4210-pinctrl.dtsi
 
 / {
compatible = samsung,exynos4210;
diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
b/arch/arm/boot/dts/exynos4212.dtsi
index c0f60f4..6f34d7f 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -17,7 +17,7 @@
  * published by the Free Software Foundation.
 */
 
-/include/ exynos4x12.dtsi
+#include exynos4x12.dtsi
 
 / {
compatible = samsung,exynos4212;
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 53bc8bf..7bb8d48 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -12,7 +12,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4412.dtsi
+#include exynos4412.dtsi
 
 / {
model = Hardkernel ODROID-X board based on Exynos4412;
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts 
b/arch/arm/boot/dts/exynos4412-origen.dts
index 790a999..df097b5 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -13,7 +13,7 @@
 */
 
 /dts-v1/;
-/include/ exynos4412.dtsi
+#include exynos4412.dtsi
 
 / {
model = Insignal Origen evaluation board based on Exynos4412;

[PATCH V5 2/5] clk: samsung: register audio subsystem clocks using common clock framework

2013-06-04 Thread Padmavathi Venna 
Audio subsystem is introduced in s5pv210 and exynos platforms.
This has seperate clock controller which can control i2s0 and
pcm0 clocks. This patch registers the audio subsystem clocks
with the common clock framework on Exynos family.

Signed-off-by: Padmavathi Venna padm...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 .../devicetree/bindings/clock/clk-exynos-audss.txt |   64 ++
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos-audss.c |  133 
 include/dt-bindings/clk/exynos-audss-clk.h |   25 
 4 files changed, 223 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
 create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
 create mode 100644 include/dt-bindings/clk/exynos-audss-clk.h

diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt 
b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
new file mode 100644
index 000..a120180
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -0,0 +1,64 @@
+* Samsung Audio Subsystem Clock Controller
+
+The Samsung Audio Subsystem clock controller generates and supplies clocks
+to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
+binding described here is applicable to all SoC's in Exynos family.
+
+Required Properties:
+
+- compatible: should be one of the following:
+  - samsung,exynos4210-audss-clock - controller compatible with all Exynos4 
SoCs.
+  - samsung,exynos5250-audss-clock - controller compatible with all Exynos5 
SoCs.
+
+- reg: physical base address and length of the controller's register set.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume. Some of the clocks are available only on a particular
+Exynos4 SoC and this is specified where applicable.
+
+Provided clocks:
+
+Clock   ID  SoC (if specific)
+---
+
+mout_audss  0
+mout_i2s1
+dout_srp2
+dout_aud_bus3
+dout_i2s4
+srp_clk 5
+i2s_bus 6
+sclk_i2s7
+pcm_bus 8
+sclk_pcm9
+
+Example 1: An example of a clock controller node is listed below.
+
+clock_audss: audss-clock-controller@381 {
+   compatible = samsung,exynos5250-audss-clock;
+   reg = 0x0381 0x0C;
+   #clock-cells = 1;
+};
+
+Example 2: I2S controller node that consumes the clock generated by the clock
+   controller. Refer to the standard clock bindings for information
+   about 'clocks' and 'clock-names' property.
+
+i2s0: i2s@0383 {
+   compatible = samsung,i2s-v5;
+   reg = 0x0383 0x100;
+   dmas = pdma0 10
+   pdma0 9
+   pdma0 8;
+   dma-names = tx, rx, tx-sec;
+   clocks = clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_SCLK_I2S,
+   clock_audss EXYNOS_MOUT_AUDSS,
+   clock_audss EXYNOS_MOUT_I2S;
+   clock-names = iis, i2s_opclk0, i2s_opclk1,
+   mout_audss, mout_i2s;
+};
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..1876810 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
+obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
b/drivers/clk/samsung/clk-exynos-audss.c
new file mode 100644
index 000..9b1bbd5
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Padmavathi Venna padm...@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.
+ *
+ * Common Clock Framework support for Audio Subsystem Clock Controller.
+*/
+
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk-provider.h
+#include linux/of_address.h
+#include linux/syscore_ops.h
+
+#include dt-bindings/clk/exynos-audss-clk.h
+
+static DEFINE_SPINLOCK(lock);
+static struct clk **clk_table;
+static void __iomem *reg_base;
+static struct clk_onecell_data clk_data;
+
+#define ASS_CLK_SRC 0x0
+#define ASS_CLK_DIV 0x4
+#define ASS_CLK_GATE 0x8
+
+static unsigned long reg_save[][2] = {
+   {ASS_CLK_SRC,  0},
+   {ASS_CLK_DIV,  0},
+   {ASS_CLK_GATE, 0},
+};
+
+/* list of all parent clock list */
+static const char *mout_audss_p[] = { fin_pll,

[PATCH V5 3/5] ARM: dts: add Exynos audio subsystem clock controller node

2013-06-04 Thread Padmavathi Venna 
Audio subsystem introduced in s5pv210 and exynos platforms
which has a internal clock controller. This patch adds a node
for the same on exynos5250.

Signed-off-by: Padmavathi Venna padm...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index bccda67..388983e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,12 @@
#clock-cells = 1;
};
 
+   clock_audss: audss-clock-controller@381 {
+   compatible = samsung,exynos5250-audss-clock;
+   reg = 0x0381 0x0C;
+   #clock-cells = 1;
+   };
+
gic:interrupt-controller@10481000 {
compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
#interrupt-cells = 3;
-- 
1.7.4.4

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

[PATCH V5 4/5] ARM: dts: add clock provider information for i2s controllers in Exynos5250

2013-06-04 Thread Padmavathi Venna 
Add clock lookup information for i2s controllers on exynos5250 SoC.

Signed-off-by: Padmavathi Venna padm...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 388983e..1e62ca9 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -20,6 +20,8 @@
 #include skeleton.dtsi
 #include exynos5250-pinctrl.dtsi
 
+#include dt-bindings/clk/exynos-audss-clk.h
+
 / {
compatible = samsung,exynos5250;
interrupt-parent = gic;
@@ -457,6 +459,10 @@
pdma0 9
pdma0 8;
dma-names = tx, rx, tx-sec;
+   clocks = clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_SCLK_I2S;
+   clock-names = iis, i2s_opclk0, i2s_opclk1;
samsung,supports-6ch;
samsung,supports-rstclr;
samsung,supports-secdai;
@@ -471,6 +477,8 @@
dmas = pdma1 12
pdma1 11;
dma-names = tx, rx;
+   clocks = clock 307;
+   clock-names = iis;
pinctrl-names = default;
pinctrl-0 = i2s1_bus;
};
@@ -481,6 +489,8 @@
dmas = pdma0 12
pdma0 11;
dma-names = tx, rx;
+   clocks = clock 308;
+   clock-names = iis;
pinctrl-names = default;
pinctrl-0 = i2s2_bus;
};
-- 
1.7.4.4

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

[PATCH V5 5/5] ARM: dts: Update Samsung I2S documentation

2013-06-04 Thread Padmavathi Venna 
This patch updates the samsung i2s documentation for pinmux and
clock entries.

Signed-off-by: Padmavathi Venna padm...@samsung.com
---
 .../devicetree/bindings/sound/samsung-i2s.txt  |   40 ++-
 1 files changed, 13 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt 
b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 3070046..6f9d29f 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -8,6 +8,10 @@ Required SoC Specific Properties:
 - dmas: list of DMA controller phandle and DMA request line ordered pairs.
 - dma-names: identifier string for each DMA request line in the dmas property.
   These strings correspond 1:1 with the ordered pairs in dmas.
+- clocks: from common clock binding. Handle to iis clock and RCLK src clk.
+- clock-names: from common clock binding: Should be iis,i2s_opclk0 and
+  i2s_opclk1. iis is the i2s bus clock and i2s_opclk selects the src of
+  RCLK which is a mux inside i2s controller.
 
 Optional SoC Specific Properties:
 
@@ -20,44 +24,26 @@ Optional SoC Specific Properties:
   then this flag is enabled.
 - samsung,idma-addr: Internal DMA register base address of the audio
   sub system(used in secondary sound source).
-
-Required Board Specific Properties:
-
-- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK
-  interface lines. The format of the gpio specifier depends on the gpio
-  controller.
-  The syntax of samsung gpio specifier is
-   [phandle of the gpio controller node]
-[pin number within the gpio controller]
-[mux function]
-[flags and pull up/down]
-[drive strength]
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - default.
 
 Example:
 
-- SoC Specific Portion:
-
-i2s@0383 {
+i2s0: i2s@0383 {
compatible = samsung,i2s-v5;
reg = 0x0383 0x100;
dmas = pdma0 10
pdma0 9
pdma0 8;
dma-names = tx, rx, tx-sec;
+   clocks = clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_I2S_BUS,
+   clock_audss EXYNOS_SCLK_I2S;
+   clock-names = iis, i2s_opclk0, i2s_opclk1;
samsung,supports-6ch;
samsung,supports-rstclr;
samsung,supports-secdai;
samsung,idma-addr = 0x0300;
-};
-
-- Board Specific Portion:
-
-i2s@0383 {
-   gpios = gpz 0 2 0 0, /* I2S_0_SCLK */
-   gpz 1 2 0 0, /* I2S_0_CDCLK */
-   gpz 2 2 0 0, /* I2S_0_LRCK */
-   gpz 3 2 0 0, /* I2S_0_SDI */
-   gpz 4 2 0 0, /* I2S_0_SDO[1] */
-   gpz 5 2 0 0, /* I2S_0_SDO[2] */
-   gpz 6 2 0 0; /* I2S_0_SDO[3] */
+   pinctrl-names = default;
+   pinctrl-0 = i2s0_bus;
 };
-- 
1.7.4.4

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

Re: [PATCH V4 22/30] thermal: exynos: Add support for exynos5440 TMU sensor.

2013-06-04 Thread Eduardo Valentin 
On 04-06-2013 00:44, amit daniel kachhap wrote:
 Hi Jonghwa,
 
 Sorry for the late reply as I was on leave.
 
 On Sat, May 18, 2013 at 10:53 AM,  jonghwa3@samsung.com wrote:
 On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:

 This patch modifies TMU controller to add changes needed to work with
 exynos5440 platform. This sensor registers 3 instance of the tmu controller
 with the thermal zone and hence reports 3 temperature output. This 
 controller
 supports upto five trip points. For critical threshold the driver uses the
 core driver thermal framework for shutdown.

 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |   28 -
  drivers/thermal/samsung/exynos_tmu.c   |   43 
 +--
  drivers/thermal/samsung/exynos_tmu.h   |6 +++
  drivers/thermal/samsung/exynos_tmu_data.h  |2 +
  4 files changed, 72 insertions(+), 7 deletions(-)

 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index 535fd0e..970eeba 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -6,13 +6,16 @@
  samsung,exynos4412-tmu
  samsung,exynos4210-tmu
  samsung,exynos5250-tmu
 +samsung,exynos5440-tmu
  - interrupt-parent : The phandle for the interrupt controller
 -- reg : Address range of the thermal registers
 +- reg : Address range of the thermal registers. For exynos5440-tmu which 
 has 3
 + instances of TMU, 2 set of register has to supplied. First set belongs
 + to each instance of TMU and second set belongs to common TMU 
 registers.
  - interrupts : Should contain interrupt for thermal system
  - clocks : The main clock for TMU device
  - clock-names : Thermal system clock name

 -Example:
 +Example 1):

   tmu@100C {
   compatible = samsung,exynos4412-tmu;
 @@ -23,3 +26,24 @@ Example:
   clock-names = tmu_apbif;
   status = disabled;
   };
 +
 +Example 2):
 +
 + tmuctrl_0: tmuctrl@160118 {
 + compatible = samsung,exynos5440-tmu;
 + reg = 0x160118 0x230, 0x160368 0x10;
 + interrupts = 0 58 0;
 + clocks = clock 21;
 + clock-names = tmu_apbif;
 + };
 +
 +Note: For multi-instance tmu each instance should have an alias correctly
 +numbered in aliases node.
 +
 +Example:
 +
 +aliases {
 + tmuctrl0 = tmuctrl_0;
 + tmuctrl1 = tmuctrl_1;
 + tmuctrl2 = tmuctrl_2;
 +};
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 7f7b1cf..7ca9c4d 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -185,9 +185,11 @@ static int exynos_tmu_initialize(struct 
 platform_device *pdev)
   reg-threshold_th0 + i * sizeof(reg-threshold_th0));

   writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
 - } else if (data-soc == SOC_ARCH_EXYNOS) {
 + } else if (data-soc == SOC_ARCH_EXYNOS ||
 + data-soc == SOC_ARCH_EXYNOS5440) {
   /* Write temperature code for rising and falling threshold */
 - for (i = 0; i  trigger_levs; i++) {
 + for (i = 0;
 + i  trigger_levs  i  EXYNOS_MAX_TRIGGER_PER_REG; i++) {
   threshold_code = temp_to_code(data,
   pdata-trigger_levels[i]);
   if (threshold_code  0) {
 @@ -218,7 +220,30 @@ static int exynos_tmu_initialize(struct 
 platform_device *pdev)
   writel((reg-inten_rise_mask  reg-inten_rise_shift) |
   (reg-inten_fall_mask  reg-inten_fall_shift),
   data-base + reg-tmu_intclear);
 +
 + /* if 5th threshold limit is also present, use TH2 register */
 + i = EXYNOS_MAX_TRIGGER_PER_REG;
 + if (pdata-trigger_levels[i]) {
 + threshold_code = temp_to_code(data,
 + pdata-trigger_levels[i]);
 + if (threshold_code  0) {
 + ret = threshold_code;
 + goto out;
 + }
 + rising_threshold =
 + threshold_code  reg-threshold_th3_l0_shift;
 + writel(rising_threshold,
 + data-base + reg-threshold_th2);
 + if (pdata-trigger_type[i] == HW_TRIP) {
 + con = readl(data-base + reg-tmu_ctrl);
 + con |= (1  reg-therm_trip_en_shift);
 + writel(con, data-base + reg-tmu_ctrl);
 +

Re: [PATCH V4 00/30] thermal: exynos: Add thermal driver for exynos5440

2013-06-04 Thread Eduardo Valentin 
On 04-06-2013 00:55, amit daniel kachhap wrote:
 Hi Eduardo,
 
 On Wed, May 15, 2013 at 8:14 PM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 14-05-2013 05:58, Amit Daniel Kachhap wrote:
 Changes in V4:
  Almost all the changes in this version is as per suggestion from 
 Eduardo.The
  major ones are listed below,
 * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by platform. 
 With
   this change existing symbol EXYNOS_TMU_DATA is not needed.

 I was more thinking if we could have a single flag that we could use in
 thermal drivers. Besides, my proposal for ARCH_HAS_BANDGAP is still not
 merged yet.
 
 yes a single flag might be useful such as ARCH_HAS_THERMAL but this
 patch can work as an intermediate solution.

I think bandgap is a generic enough term IMO.

[1] - http://en.wikipedia.org/wiki/Bandgap_voltage_reference
[2] - http://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor


 
 Thanks,
 Amit Daniel

 * Movement of freq_clip_table from exynos_tmu.h to exynos_thermal_common.h 
 is
   explained in the commit logs.
 * Wrote all register description documentation.
 * Split 5440 TMU support patch into controller change, configuration data 
 and
   feature addition patches.
 * Remove all *LINUX_* in the header files.
 * Still regulator enable is kept optional but a TODO: comment is added to 
 fix
   it later.

 Changes in V3:
 * Added proper dependency of different exynos thermal Kconfig symbols. 
 Basically 3
  Kconfig can be enabled now and corresponds to tmu driver. exynos common 
 part
  and exynos configuration data. This issue was raised by Rui Zhang.

 Changes in V2:
 * Separated SOC data from TMU driver. This is as per suggestion from 
 Eduardo.
 * Merged the new file created for exynos5440 TMU controller with the 
 existing
  TMU controller code.
 * Removed the DT parsing code as now the SOC specific data are cleanly put
  inside the data specific file.
 * Even the register definations/bitfields are treated as data as there is
  some variation across SOC's.

 This patchset adds TMU(Thermal management Unit) driver support for
 exynos5440 platform. There are 3 instances of the TMU controllers so
 necessary cleanup/re-structure is done to handle multiple thermal zone.

 Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from
 Lukasz Majewski is already posted to mainline. Adding it here for 
 completeness.
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html)

 Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is
 added here with some changes.
 (https://patchwork.kernel.org/patch/1668371/)

 Patch (thermal: exynos: Support for TMU regulator defined at device tree)
 is a repost of my earlier 
 patch(https://patchwork-mail1.kernel.org/patch/2510771/)
 and adds regulator support.

 Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and
 patch (arm: exynos: enable ARCH_HAS_TMU) can be merged through exynos 
 platform
 maintainer as this can cause merge conflict.

 All these patches are based on thermal maintainers git tree,
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next.

 Amit Daniel Kachhap (29):
   thermal: exynos: Moving exynos thermal files into samsung directory
   thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's
   thermal: exynos: Remove CPU_THERMAL dependency for using TMU driver
   thermal: exynos: Bifurcate exynos thermal common and tmu controller
 code
   thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c
   thermal: exynos: Move exynos_thermal.h from include/* to driver/*
 folder
   thermal: exynos: Bifurcate exynos tmu driver and configuration data
   thermal: exynos: Add missing definations and code cleanup
   thermal: exynos: Add extra entries in the tmu platform data
   thermal: exynos: Support thermal tripping
   thermal: exynos: Move register definitions from driver file to data
 file
   thermal: exynos: Fix to clear only the generated interrupts
   thermal: exynos: Add support for instance based register/unregister
   thermal: exynos: Modify private_data to appropriate name driver_data
   thermal: exynos: Return success even if no cooling data supplied
   thermal: exynos: Make the zone handling dependent on trip count
   thermal: exynos: Add support to handle many instances of TMU
   thermal: exynos: Add TMU features to check instead of using SOC type
   thermal: exynos: use device resource management infrastructure
   thermal: exynos: Add support to access common register for
 multistance
   thermal: exynos: Add support for exynos5440 TMU sensor.
   thermal: exynos: Fix to set the second point correction value
 properly
   thermal: exynos: Add thermal configuration data for exynos5440 TMU
 sensor
   thermal: exynos: Add a compensation logic on swapped e-fuse values
   thermal: exynos: Add hardware mode thermal calibration support
   Documentation: thermal: Explain the exynos thermal driver model

Re: [PATCH V4 00/30] thermal: exynos: Add thermal driver for exynos5440

2013-06-04 Thread Eduardo Valentin 

Hi,

On 04-06-2013 08:57, Eduardo Valentin wrote:
 On 04-06-2013 00:55, amit daniel kachhap wrote:
 Hi Eduardo,

 On Wed, May 15, 2013 at 8:14 PM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 14-05-2013 05:58, Amit Daniel Kachhap wrote:
 Changes in V4:
  Almost all the changes in this version is as per suggestion from 
 Eduardo.The
  major ones are listed below,
 * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by platform. 
 With
   this change existing symbol EXYNOS_TMU_DATA is not needed.

 I was more thinking if we could have a single flag that we could use in
 thermal drivers. Besides, my proposal for ARCH_HAS_BANDGAP is still not
 merged yet.

 yes a single flag might be useful such as ARCH_HAS_THERMAL but this
 patch can work as an intermediate solution.
 
 I think bandgap is a generic enough term IMO.
 
 [1] - http://en.wikipedia.org/wiki/Bandgap_voltage_reference
 [2] - http://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor
 

Hit the send button too early. So, I think bandgap is a generic enough
term. Using bandgap I believe it is better because its meaning has the
implication of having a device to control thermal.

But if you feel more confident with the thermal term we can switch to
something like HAS_THERMAL_CONTROL.

 

 Thanks,
 Amit Daniel

 * Movement of freq_clip_table from exynos_tmu.h to exynos_thermal_common.h 
 is
   explained in the commit logs.
 * Wrote all register description documentation.
 * Split 5440 TMU support patch into controller change, configuration data 
 and
   feature addition patches.
 * Remove all *LINUX_* in the header files.
 * Still regulator enable is kept optional but a TODO: comment is added to 
 fix
   it later.

 Changes in V3:
 * Added proper dependency of different exynos thermal Kconfig symbols. 
 Basically 3
  Kconfig can be enabled now and corresponds to tmu driver. exynos common 
 part
  and exynos configuration data. This issue was raised by Rui Zhang.

 Changes in V2:
 * Separated SOC data from TMU driver. This is as per suggestion from 
 Eduardo.
 * Merged the new file created for exynos5440 TMU controller with the 
 existing
  TMU controller code.
 * Removed the DT parsing code as now the SOC specific data are cleanly put
  inside the data specific file.
 * Even the register definations/bitfields are treated as data as there is
  some variation across SOC's.

 This patchset adds TMU(Thermal management Unit) driver support for
 exynos5440 platform. There are 3 instances of the TMU controllers so
 necessary cleanup/re-structure is done to handle multiple thermal zone.

 Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from
 Lukasz Majewski is already posted to mainline. Adding it here for 
 completeness.
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html)

 Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is
 added here with some changes.
 (https://patchwork.kernel.org/patch/1668371/)

 Patch (thermal: exynos: Support for TMU regulator defined at device tree)
 is a repost of my earlier 
 patch(https://patchwork-mail1.kernel.org/patch/2510771/)
 and adds regulator support.

 Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and
 patch (arm: exynos: enable ARCH_HAS_TMU) can be merged through exynos 
 platform
 maintainer as this can cause merge conflict.

 All these patches are based on thermal maintainers git tree,
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next.

 Amit Daniel Kachhap (29):
   thermal: exynos: Moving exynos thermal files into samsung directory
   thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's
   thermal: exynos: Remove CPU_THERMAL dependency for using TMU driver
   thermal: exynos: Bifurcate exynos thermal common and tmu controller
 code
   thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c
   thermal: exynos: Move exynos_thermal.h from include/* to driver/*
 folder
   thermal: exynos: Bifurcate exynos tmu driver and configuration data
   thermal: exynos: Add missing definations and code cleanup
   thermal: exynos: Add extra entries in the tmu platform data
   thermal: exynos: Support thermal tripping
   thermal: exynos: Move register definitions from driver file to data
 file
   thermal: exynos: Fix to clear only the generated interrupts
   thermal: exynos: Add support for instance based register/unregister
   thermal: exynos: Modify private_data to appropriate name driver_data
   thermal: exynos: Return success even if no cooling data supplied
   thermal: exynos: Make the zone handling dependent on trip count
   thermal: exynos: Add support to handle many instances of TMU
   thermal: exynos: Add TMU features to check instead of using SOC type
   thermal: exynos: use device resource management infrastructure
   thermal: exynos: Add support to access common register for
 multistance
   thermal: exynos: Add support for exynos5440 TMU sensor.
   thermal:

Re: [PATCH V4 3/4] ARM: dts: add Exynos audio subsystem clock controller node

2013-06-04 Thread Doug Anderson 
Padma,

On Mon, Jun 3, 2013 at 9:25 PM, Padma Venkat padma@gmail.com wrote:
 Hi Doug,

 On Tue, Jun 4, 2013 at 1:43 AM, Doug Anderson diand...@chromium.org wrote:
 Padmavathi,

 On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna padm...@samsung.com 
 wrote:
 Audio subsystem introduced in s5pv210 and exynos platforms
 which has a internal clock controller. This patch adds a node
 for the same on exynos5250.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos5250.dtsi |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index bccda67..388983e 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -72,6 +72,12 @@
 #clock-cells = 1;
 };

 +   clock_audss: audss-clock-controller@381 {

 I removed this leading 0 as Tomasz Figa suggested.

Let's just leave this as-is if Tomasz wants no leading 0.  I don't
much care either way but it's really nice if we're consistent within
the file.


 Nit: other places in the same file have the leading 0, like
   i2s0: i2s@0383 {

 This was the patch which got merged earlier. So I didn't modify this.
 Is it okey if I remove  leading 0 for both of the nodes now?

No, don't touch the i2s0 one in this patch.  I guess we'll have to
merge a cleanup patch sometime later to try to normalize all this
stuff, since nobody seems to be keeping a close eye on keeping it
consistent.  I also see a whole bunch that have the 0x in the name
which is yet another inconsistency.


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

Re: [PATCH V5 3/5] ARM: dts: add Exynos audio subsystem clock controller node

2013-06-04 Thread Doug Anderson 
Padmavathi,

On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna padm...@samsung.com wrote:
 Audio subsystem introduced in s5pv210 and exynos platforms
 which has a internal clock controller. This patch adds a node
 for the same on exynos5250.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos5250.dtsi |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

Responded on patch set 4 already, but this is the same.  I'm happy with this.

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

Re: [PATCH V5 2/5] clk: samsung: register audio subsystem clocks using common clock framework

2013-06-04 Thread Doug Anderson 
Padmavathi,

On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna padm...@samsung.com wrote:
 Audio subsystem is introduced in s5pv210 and exynos platforms.
 This has seperate clock controller which can control i2s0 and
 pcm0 clocks. This patch registers the audio subsystem clocks
 with the common clock framework on Exynos family.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  .../devicetree/bindings/clock/clk-exynos-audss.txt |   64 ++
  drivers/clk/samsung/Makefile   |1 +
  drivers/clk/samsung/clk-exynos-audss.c |  133 
 
  include/dt-bindings/clk/exynos-audss-clk.h |   25 
  4 files changed, 223 insertions(+), 0 deletions(-)

Thanks for fixing up my nits.  This looks good to me.

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

Re: [PATCH V5 4/5] ARM: dts: add clock provider information for i2s controllers in Exynos5250

2013-06-04 Thread Doug Anderson 
Padmavathi,

On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna padm...@samsung.com wrote:
 Add clock lookup information for i2s controllers on exynos5250 SoC.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos5250.dtsi |   10 ++

Would still like to see a separate patch documenting these clocks in
Documentation/devicetree/bindings/sound/samsung-i2s.txt.  ...but
what's here looks good, thanks!

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

Re: [PATCH V5 4/5] ARM: dts: add clock provider information for i2s controllers in Exynos5250

2013-06-04 Thread Doug Anderson 
Padmavathi,

On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna padm...@samsung.com wrote:
 @@ -471,6 +477,8 @@
 dmas = pdma1 12
 pdma1 11;
 dma-names = tx, rx;
 +   clocks = clock 307;
 +   clock-names = iis;

...actually, glancing at the driver I'm a little surprised that you
don't need to list i2s_opclk0.  Did you test i2s1?

 pinctrl-names = default;
 pinctrl-0 = i2s1_bus;
 };
 @@ -481,6 +489,8 @@
 dmas = pdma0 12
 pdma0 11;
 dma-names = tx, rx;
 +   clocks = clock 308;
 +   clock-names = iis;

...and here.


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

Re: [PATCH V5 5/5] ARM: dts: Update Samsung I2S documentation

2013-06-04 Thread Doug Anderson 
Padmavathi,

On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna padm...@samsung.com wrote:
 This patch updates the samsung i2s documentation for pinmux and
 clock entries.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 ---
  .../devicetree/bindings/sound/samsung-i2s.txt  |   40 ++-
  1 files changed, 13 insertions(+), 27 deletions(-)

Whoops, just asked for this and now saw it.  Thanks for posting!

One note: don't use the dts tag for this commit.  That should be
only for things that are touching dts / dtsi files, not for updating
docs.


 diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt 
 b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
 index 3070046..6f9d29f 100644
 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
 +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
 @@ -8,6 +8,10 @@ Required SoC Specific Properties:
  - dmas: list of DMA controller phandle and DMA request line ordered pairs.
  - dma-names: identifier string for each DMA request line in the dmas 
 property.
These strings correspond 1:1 with the ordered pairs in dmas.
 +- clocks: from common clock binding. Handle to iis clock and RCLK src clk.
 +- clock-names: from common clock binding: Should be iis,i2s_opclk0 and
 +  i2s_opclk1. iis is the i2s bus clock and i2s_opclk selects the src of
 +  RCLK which is a mux inside i2s controller.

From your other patch apparently opclk0 and/or opclk1 are not
required.  Two of your i2c nodes don't have either, though I suspect
that you at least need opclk0.  See my comments there.

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

Re: [RFC 09/42] drivers/i2c/busses: don't check resource with devm_ioremap_resource

2013-06-04 Thread Kevin Hilman 
Wolfram Sang w...@the-dreams.de writes:

 devm_ioremap_resource does sanity checks on the given resource. No need to
 duplicate this in the driver.

 Signed-off-by: Wolfram Sang w...@the-dreams.de

Acked-by: Kevin Hilman khil...@linaro.org  # for i2c-omap.c

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

[PATCH] ARM: samsung: avoid racy early printk at bootup

2013-06-04 Thread Doug Anderson 
At boot, we've got a stack trace that looks something like this
(exynos5 as example)
* exynos5_map_io
* s3c_init_cpu
* exynos_init_io
* exynos5_dt_map_io
* paging_init
* setup_arch

When paging_init() runs we'll lose any early MMU mappings that we
might have had to allow us access to S3C_VA_UART.  We won't add those
mappings back in until after the SoC-specific map_io() function is
called.  However, we print the CPU ID _right before_ we call the
SoC-specific function.  Oops.

Things happen to work all right most of the time because the mapping
is sticking around in our TLB.  ...but if we get really unlucky (like
me!) or we put an explicit flush_tlb_all() at the start of
exynos_init_io(), then things go boom.

This patch moves the problematic printk() till after the cpu-map_io()
call.  It also switches it over to pr_info().  This patch _doesn't_
remove the questionable printks in the panic case, since we might get
lucky and the TLB might still let us print.  This patch also adds a
few warnings to help others avoid similar headaches.

Signed-off-by: Doug Anderson diand...@chromium.org
---
 arch/arm/mach-exynos/common.c | 7 +++
 arch/arm/plat-samsung/init.c  | 8 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 027c9e7..8b51b0d 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -386,6 +386,13 @@ int __init exynos_fdt_map_chipid(unsigned long node, const 
char *uname,
 
 void __init exynos_init_io(struct map_desc *mach_desc, int size)
 {
+   /*
+* WARNING: use of printk in this function or its children can be
+* deadly.  We've switched over to new page tables but haven't yet
+* added S3C_VA_UART into the mapping.  You might get lucky and see a
+* printout work, but if you call flush_tlb_all() it will fail reliably.
+*/
+
 #ifdef CONFIG_OF
if (initial_boot_params)
of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 79d10fc..494cfbb 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -49,18 +49,20 @@ void __init s3c_init_cpu(unsigned long idcode,
cpu = s3c_lookup_cpu(idcode, cputab, cputab_size);
 
if (cpu == NULL) {
+   /* Questionable printk; S3C_VA_UART not mapped yet! */
printk(KERN_ERR Unknown CPU type 0x%08lx\n, idcode);
panic(Unknown S3C24XX CPU);
}
-
-   printk(CPU %s (id 0x%08lx)\n, cpu-name, idcode);
-
if (cpu-map_io == NULL || cpu-init == NULL) {
+   /* Questionable printk; S3C_VA_UART not mapped yet! */
printk(KERN_ERR CPU %s support not enabled\n, cpu-name);
panic(Unsupported Samsung CPU);
}
 
cpu-map_io();
+
+   /* IMPORTANT: call this after cpu-map_io() so we can print reliably */
+   pr_info(CPU %s (id 0x%08lx)\n, cpu-name, idcode);
 }
 
 /* s3c24xx_init_clocks
-- 
1.8.3

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

Re: [PATCH] ARM: samsung: avoid racy early printk at bootup

2013-06-04 Thread Olof Johansson 
Hi,

On Tue, Jun 04, 2013 at 06:58:59PM -0700, Doug Anderson wrote:
 At boot, we've got a stack trace that looks something like this
 (exynos5 as example)
 * exynos5_map_io
 * s3c_init_cpu
 * exynos_init_io
 * exynos5_dt_map_io
 * paging_init
 * setup_arch
 
 When paging_init() runs we'll lose any early MMU mappings that we
 might have had to allow us access to S3C_VA_UART.  We won't add those
 mappings back in until after the SoC-specific map_io() function is
 called.  However, we print the CPU ID _right before_ we call the
 SoC-specific function.  Oops.
 
 
 Things happen to work all right most of the time because the mapping
 is sticking around in our TLB.  ...but if we get really unlucky (like
 me!) or we put an explicit flush_tlb_all() at the start of
 exynos_init_io(), then things go boom.
 
 This patch moves the problematic printk() till after the cpu-map_io()
 call.  It also switches it over to pr_info().  This patch _doesn't_
 remove the questionable printks in the panic case, since we might get
 lucky and the TLB might still let us print.  This patch also adds a
 few warnings to help others avoid similar headaches.

This seems to be caused by not calling iotable_ini() in exynos_init_io()
when a device tree is passed into the kernel, thus not setting up the
mapping for the UART in that case.

I think the solution is instead to map the uart earlier. The window of
exposure is still there, but much smaller (and similar to how it always
has been).

In current upstream, if there is no map_io mach_desc entry at all,
debug_ll_io_init() will be called on all platforms. Seems appropriate
to call that explicitly before of_scan_flat_dt() in exynos_init_io()
in this case.

Or am I missing something?


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

Re: [PATCH V4 22/30] thermal: exynos: Add support for exynos5440 TMU sensor.

2013-06-04 Thread amit daniel kachhap 
Hi Eduardo,

On Tue, Jun 4, 2013 at 6:25 PM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
 On 04-06-2013 00:44, amit daniel kachhap wrote:
 Hi Jonghwa,

 Sorry for the late reply as I was on leave.

 On Sat, May 18, 2013 at 10:53 AM,  jonghwa3@samsung.com wrote:
 On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:

 This patch modifies TMU controller to add changes needed to work with
 exynos5440 platform. This sensor registers 3 instance of the tmu controller
 with the thermal zone and hence reports 3 temperature output. This 
 controller
 supports upto five trip points. For critical threshold the driver uses the
 core driver thermal framework for shutdown.

 Acked-by: Kukjin Kim kgene@samsung.com
 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |   28 -
  drivers/thermal/samsung/exynos_tmu.c   |   43 
 +--
  drivers/thermal/samsung/exynos_tmu.h   |6 +++
  drivers/thermal/samsung/exynos_tmu_data.h  |2 +
  4 files changed, 72 insertions(+), 7 deletions(-)

 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index 535fd0e..970eeba 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -6,13 +6,16 @@
  samsung,exynos4412-tmu
  samsung,exynos4210-tmu
  samsung,exynos5250-tmu
 +samsung,exynos5440-tmu
  - interrupt-parent : The phandle for the interrupt controller
 -- reg : Address range of the thermal registers
 +- reg : Address range of the thermal registers. For exynos5440-tmu which 
 has 3
 + instances of TMU, 2 set of register has to supplied. First set 
 belongs
 + to each instance of TMU and second set belongs to common TMU 
 registers.
  - interrupts : Should contain interrupt for thermal system
  - clocks : The main clock for TMU device
  - clock-names : Thermal system clock name

 -Example:
 +Example 1):

   tmu@100C {
   compatible = samsung,exynos4412-tmu;
 @@ -23,3 +26,24 @@ Example:
   clock-names = tmu_apbif;
   status = disabled;
   };
 +
 +Example 2):
 +
 + tmuctrl_0: tmuctrl@160118 {
 + compatible = samsung,exynos5440-tmu;
 + reg = 0x160118 0x230, 0x160368 0x10;
 + interrupts = 0 58 0;
 + clocks = clock 21;
 + clock-names = tmu_apbif;
 + };
 +
 +Note: For multi-instance tmu each instance should have an alias correctly
 +numbered in aliases node.
 +
 +Example:
 +
 +aliases {
 + tmuctrl0 = tmuctrl_0;
 + tmuctrl1 = tmuctrl_1;
 + tmuctrl2 = tmuctrl_2;
 +};
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 7f7b1cf..7ca9c4d 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -185,9 +185,11 @@ static int exynos_tmu_initialize(struct 
 platform_device *pdev)
   reg-threshold_th0 + i * sizeof(reg-threshold_th0));

   writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
 - } else if (data-soc == SOC_ARCH_EXYNOS) {
 + } else if (data-soc == SOC_ARCH_EXYNOS ||
 + data-soc == SOC_ARCH_EXYNOS5440) {
   /* Write temperature code for rising and falling threshold */
 - for (i = 0; i  trigger_levs; i++) {
 + for (i = 0;
 + i  trigger_levs  i  EXYNOS_MAX_TRIGGER_PER_REG; i++) {
   threshold_code = temp_to_code(data,
   pdata-trigger_levels[i]);
   if (threshold_code  0) {
 @@ -218,7 +220,30 @@ static int exynos_tmu_initialize(struct 
 platform_device *pdev)
   writel((reg-inten_rise_mask  reg-inten_rise_shift) |
   (reg-inten_fall_mask  reg-inten_fall_shift),
   data-base + reg-tmu_intclear);
 +
 + /* if 5th threshold limit is also present, use TH2 register 
 */
 + i = EXYNOS_MAX_TRIGGER_PER_REG;
 + if (pdata-trigger_levels[i]) {
 + threshold_code = temp_to_code(data,
 + pdata-trigger_levels[i]);
 + if (threshold_code  0) {
 + ret = threshold_code;
 + goto out;
 + }
 + rising_threshold =
 + threshold_code  
 reg-threshold_th3_l0_shift;
 + writel(rising_threshold,
 + data-base + reg-threshold_th2);
 + if (pdata-trigger_type[i] == HW_TRIP) {
 + con = readl(data-base + reg-tmu_ctrl);
 + con |= (1

Re: [PATCH V4 00/30] thermal: exynos: Add thermal driver for exynos5440

2013-06-04 Thread amit daniel kachhap 
On Tue, Jun 4, 2013 at 6:31 PM, Eduardo Valentin
eduardo.valen...@ti.com wrote:

 Hi,

 On 04-06-2013 08:57, Eduardo Valentin wrote:
 On 04-06-2013 00:55, amit daniel kachhap wrote:
 Hi Eduardo,

 On Wed, May 15, 2013 at 8:14 PM, Eduardo Valentin
 eduardo.valen...@ti.com wrote:
 On 14-05-2013 05:58, Amit Daniel Kachhap wrote:
 Changes in V4:
  Almost all the changes in this version is as per suggestion from 
 Eduardo.The
  major ones are listed below,
 * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by 
 platform. With
   this change existing symbol EXYNOS_TMU_DATA is not needed.

 I was more thinking if we could have a single flag that we could use in
 thermal drivers. Besides, my proposal for ARCH_HAS_BANDGAP is still not
 merged yet.

 yes a single flag might be useful such as ARCH_HAS_THERMAL but this
 patch can work as an intermediate solution.

 I think bandgap is a generic enough term IMO.

 [1] - http://en.wikipedia.org/wiki/Bandgap_voltage_reference
 [2] - http://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor


 Hit the send button too early. So, I think bandgap is a generic enough
 term. Using bandgap I believe it is better because its meaning has the
 implication of having a device to control thermal.

 But if you feel more confident with the thermal term we can switch to
 something like HAS_THERMAL_CONTROL.

Even in my case TMU uses bandgap voltage reference circuit. so
ARCH_HAS_BANDGAP should be fine.

Thanks,
Amit Daniel



 Thanks,
 Amit Daniel

 * Movement of freq_clip_table from exynos_tmu.h to 
 exynos_thermal_common.h is
   explained in the commit logs.
 * Wrote all register description documentation.
 * Split 5440 TMU support patch into controller change, configuration data 
 and
   feature addition patches.
 * Remove all *LINUX_* in the header files.
 * Still regulator enable is kept optional but a TODO: comment is added to 
 fix
   it later.

 Changes in V3:
 * Added proper dependency of different exynos thermal Kconfig symbols. 
 Basically 3
  Kconfig can be enabled now and corresponds to tmu driver. exynos common 
 part
  and exynos configuration data. This issue was raised by Rui Zhang.

 Changes in V2:
 * Separated SOC data from TMU driver. This is as per suggestion from 
 Eduardo.
 * Merged the new file created for exynos5440 TMU controller with the 
 existing
  TMU controller code.
 * Removed the DT parsing code as now the SOC specific data are cleanly put
  inside the data specific file.
 * Even the register definations/bitfields are treated as data as there is
  some variation across SOC's.

 This patchset adds TMU(Thermal management Unit) driver support for
 exynos5440 platform. There are 3 instances of the TMU controllers so
 necessary cleanup/re-structure is done to handle multiple thermal zone.

 Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from
 Lukasz Majewski is already posted to mainline. Adding it here for 
 completeness.
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html)

 Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is
 added here with some changes.
 (https://patchwork.kernel.org/patch/1668371/)

 Patch (thermal: exynos: Support for TMU regulator defined at device tree)
 is a repost of my earlier 
 patch(https://patchwork-mail1.kernel.org/patch/2510771/)
 and adds regulator support.

 Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and
 patch (arm: exynos: enable ARCH_HAS_TMU) can be merged through exynos 
 platform
 maintainer as this can cause merge conflict.

 All these patches are based on thermal maintainers git tree,
 git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next.

 Amit Daniel Kachhap (29):
   thermal: exynos: Moving exynos thermal files into samsung directory
   thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's
   thermal: exynos: Remove CPU_THERMAL dependency for using TMU driver
   thermal: exynos: Bifurcate exynos thermal common and tmu controller
 code
   thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c
   thermal: exynos: Move exynos_thermal.h from include/* to driver/*
 folder
   thermal: exynos: Bifurcate exynos tmu driver and configuration data
   thermal: exynos: Add missing definations and code cleanup
   thermal: exynos: Add extra entries in the tmu platform data
   thermal: exynos: Support thermal tripping
   thermal: exynos: Move register definitions from driver file to data
 file
   thermal: exynos: Fix to clear only the generated interrupts
   thermal: exynos: Add support for instance based register/unregister
   thermal: exynos: Modify private_data to appropriate name driver_data
   thermal: exynos: Return success even if no cooling data supplied
   thermal: exynos: Make the zone handling dependent on trip count
   thermal: exynos: Add support to handle many instances of TMU
   thermal: exynos: Add TMU features to check instead of using SOC type
   thermal: