Re: [PATCH 0/5] ARM: dts: exynos5420: add support for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Thanks Chander,

I am posting v2 with the suggested changes.

regards,
Rahul Sharma.

On Thu, Jun 20, 2013 at 11:45 AM, Chander Kashyap
 wrote:
> On 20 June 2013 11:11, Rahul Sharma  wrote:
>> Add dt nodes and clocks for hdmi subsystem. It also add pinctrl
>> node for hdmi hpd gpio and update binding documents.
>>
>> This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
>> at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git
>>
>> device tree binding document for hdmi compatible type is update at
>> http://www.spinics.net/lists/dri-devel/msg39987.html
>>
>> Andrew Bresticker (1):
>>   ARM: dts: exynos5420: add i2c device nodes
>>
>> Rahul Sharma (4):
>>   ARM: dts: exynos5420: add dt nodes for hdmi subsystem
>>   ARM: dts: exynos5420: add clocks for hdmi subsystem
>>   ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node
>>   ARM: dts: update binding documentation for hdmi subsystem
> While populating exnos5420.dtsi, move nodes with common properties
> across exynos5420 and exynos5420 to exynos5.dtsi
>>
>>  .../devicetree/bindings/video/exynos_hdmi.txt  |   17 -
>>  .../devicetree/bindings/video/exynos_mixer.txt |4 ++
>>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 ++
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |   17 +
>>  arch/arm/boot/dts/exynos5420.dtsi  |   74 
>> 
>>  5 files changed, 116 insertions(+), 3 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
>
>
>
> --
> with warm regards,
> Chander Kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] ARM: dts: exynos5420: add dt nodes for hdmi subsystem

2013-06-19 Thread Rahul Sharma
ok Sachin. Thanks.

On Thu, Jun 20, 2013 at 12:08 PM, Sachin Kamat  wrote:
> On 20 June 2013 11:11, Rahul Sharma  wrote:
>> Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts |   15 +++
>>  arch/arm/boot/dts/exynos5420.dtsi |   12 
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> index 08607df..b3721bd 100644
>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> @@ -30,4 +30,19 @@
>> clock-frequency = <2400>;
>> };
>> };
>> +
>> +   hdmi {
>> +   hpd-gpio = <&gpx3 7 0>;
>> +   };
>> +
>> +   i2c_2: i2c@12C8 {
>> +   samsung,i2c-sda-delay = <100>;
>> +   samsung,i2c-max-bus-freq = <66000>;
>> +   status = "okay";
>> +
>> +   hdmiddc@50 {
>> +   compatible = "samsung,exynos4210-hdmiddc";
>> +   reg = <0x50>;
>> +   };
>> +   };
>>  };
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index b0ec047..45aadf9 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -201,4 +201,16 @@
>> clock-names = "i2c";
>> status = "disabled";
>> };
>> +
>> +   hdmi {
>> +   compatible = "samsung,exynos4212-hdmi";
>> +   reg = <0x1453 0x7>;
>> +   interrupts = <0 95 0>;
>> +   };
>> +
>> +   mixer: mixer@1445 {
>> +   compatible = "samsung,exynos5420-mixer";
>> +   reg = <0x1445 0x1>;
>> +   interrupts = <0 94 0>;
>> +   };
>
> If these are the parent nodes, disable them here and enable in the board 
> files.
>
>
> --
> With warm regards,
> Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

2013-06-19 Thread Jingoo Han
On Wednesday, June 19, 2013 9:43 PM, Arnd Bergmann wrote:
> On Wednesday 19 June 2013, Jingoo Han wrote:
> > Then, do you mean the following?
> >
> > static int __exit exynos_pcie_remove(struct platform_device *pdev)
> > {
> > struct pcie_port *pp = platform_get_drvdata(pdev);
> >
> > clk_disable_unprepare(pp->bus_clk);
> > clk_disable_unprepare(pp->clk);
> >
> > return 0;
> > }
> >
> > static struct platform_driver exynos_pcie_driver = {
> > .remove = __exit_p(exynos_pcie_remove),
> >
> > [.]
> >
> > /* Exynos PCIe driver does not allow module unload */
> >
> > static int __init pcie_init(void)
> > {
> > hook_fault_code(16 + 6, exynos_pcie_abort, SIGBUS, 0,
> > "imprecise external abort");
> >
> > platform_driver_probe(&exynos_pcie_driver, exynos_pcie_probe);
> >
> > return 0;
> > }
> > subsys_initcall(pcie_init);
> >
> > MODULE_AUTHOR("Jingoo Han ");
> > MODULE_DESCRIPTION("Samsung PCIe host controller driver");
> > MODULE_LICENSE("GPLv2");
> >
> 
> Yes, this looks good. I would probably use platform_driver_register
> rather than platform_driver_probe, but that is your choice. using
> platform_driver_probe() mean you cannot deal with deferred probing.

Hi Arnd,

Thank you for your reply. :)
I will send PATCH v6, soon.
I really appreciate your comments.

Hi Thomas Abraham, Kukjin Kim,
Thank you for your support.
It is very helpful.


Best regards,
Jingoo Han


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


Re: [PATCH 2/5] ARM: dts: exynos5420: add dt nodes for hdmi subsystem

2013-06-19 Thread Sachin Kamat
On 20 June 2013 11:11, Rahul Sharma  wrote:
> Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.
>
> Signed-off-by: Rahul Sharma 
> ---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |   15 +++
>  arch/arm/boot/dts/exynos5420.dtsi |   12 
>  2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 08607df..b3721bd 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -30,4 +30,19 @@
> clock-frequency = <2400>;
> };
> };
> +
> +   hdmi {
> +   hpd-gpio = <&gpx3 7 0>;
> +   };
> +
> +   i2c_2: i2c@12C8 {
> +   samsung,i2c-sda-delay = <100>;
> +   samsung,i2c-max-bus-freq = <66000>;
> +   status = "okay";
> +
> +   hdmiddc@50 {
> +   compatible = "samsung,exynos4210-hdmiddc";
> +   reg = <0x50>;
> +   };
> +   };
>  };
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index b0ec047..45aadf9 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -201,4 +201,16 @@
> clock-names = "i2c";
> status = "disabled";
> };
> +
> +   hdmi {
> +   compatible = "samsung,exynos4212-hdmi";
> +   reg = <0x1453 0x7>;
> +   interrupts = <0 95 0>;
> +   };
> +
> +   mixer: mixer@1445 {
> +   compatible = "samsung,exynos5420-mixer";
> +   reg = <0x1445 0x1>;
> +   interrupts = <0 94 0>;
> +   };

If these are the parent nodes, disable them here and enable in the board files.


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


Re: [PATCH 5/5] ARM: dts: update binding documentation for hdmi subsystem

2013-06-19 Thread Sachin Kamat
On 20 June 2013 11:11, Rahul Sharma  wrote:
> Adding information about clocks to mixer and hdmi dt
> nodes. Also removed the updated fields for hpd property.
>
> Signed-off-by: Rahul Sharma 

Please rebase you patch on top of [1] or fold this into it.

[1] http://permalink.gmane.org/gmane.linux.drivers.devicetree/36162


> ---
>  .../devicetree/bindings/video/exynos_hdmi.txt |   17 
> ++---
>  .../devicetree/bindings/video/exynos_mixer.txt|4 
>  2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..5dca3af 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -8,9 +8,20 @@ Required properties:
>  - hpd-gpio: following information about the hotplug gpio pin.
> a) phandle of the gpio controller node.
> b) pin number within the gpio controller.
> -   c) pin function mode.
> -   d) optional flags and pull up/down.
> -   e) drive strength.
> +   c) optional flags and pull up/down.
> +- clocks: list of clock IDs from SoC clock driver.
> +   a) hdmi: It is required for gate operation on aclk_200_disp1 clock
> +   which clocks the display1 block.
> +   b) sclk_hdmi: It is required for gate operation on sclk_hdmi clock
> +   which clocks hdmi IP.
> +   c) sclk_pixel: Parent for mux mout_hdmi.
> +   d) sclk_hdmiphy: Parent for mux mout_hdmi.
> +   e) mout_hdmi: It is required by the driver to switch between the 2
> +   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
> +   after configuration, parent is set to sclk_hdmiphy else
> +   sclk_pixel.
> +- clock-names: aliases as per driver requirements for above clock IDs:
> +   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>
>  Example:
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..54790a2 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -5,6 +5,10 @@ Required properties:
>  - reg: physical base address of the mixer and length of memory mapped
> region.
>  - interrupts: interrupt number to the cpu.
> +- clocks: list of clock IDs from SoC clock driver.
> +   a) mixer: It is required for gate operation on aclk_200_disp1 clock
> +   which clocks the display1 block.
> +   b) sclk_hdmi: Parent for mux mout_mixer.
>
>  Example:
>
> --
> 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



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


[PATCH v2 5/5] ARM: EXYNOS: Add mfc-v7 to memory reserve

2013-06-19 Thread Arun Kumar K
The patch updates the exynos5 memory reservation to reserve
memory for mfc-v7 also in addition to v6.

Signed-off-by: Arun Kumar K 
---
 arch/arm/mach-exynos/mach-exynos5-dt.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index f874b77..fdb6181 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -60,13 +60,17 @@ static char const *exynos5_dt_compat[] __initdata = {
 static void __init exynos5_reserve(void)
 {
 #ifdef CONFIG_S5P_DEV_MFC
-   struct s5p_mfc_dt_meminfo mfc_mem;
+   int i;
+   struct s5p_mfc_dt_meminfo mfc_mem[] = {
+   {.compatible = "samsung,mfc-v6"},
+   {.compatible = "samsung,mfc-v7"},
+   };
 
/* Reserve memory for MFC only if it's available */
-   mfc_mem.compatible = "samsung,mfc-v6";
-   if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem))
-   s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize, mfc_mem.loff,
-   mfc_mem.lsize);
+   for (i = 0; i < ARRAY_SIZE(mfc_mem); i++)
+   if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem[i]))
+   s5p_mfc_reserve_mem(mfc_mem[i].roff, mfc_mem[i].rsize,
+   mfc_mem[i].loff, mfc_mem[i].lsize);
 #endif
 }
 
-- 
1.7.9.5

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


[PATCH v2 2/5] ARM: dts: Remove unsused MFC clock from exynos4

2013-06-19 Thread Arun Kumar K
Removes the unused sclk_mfc from exynos4 dtsi file.

Signed-off-by: Arun Kumar K 
---
 arch/arm/boot/dts/exynos4.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..0f213a3 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -160,8 +160,8 @@
reg = <0x1340 0x1>;
interrupts = <0 94 0>;
samsung,power-domain = <&pd_mfc>;
-   clocks = <&clock 170>, <&clock 273>;
-   clock-names = "sclk_mfc", "mfc";
+   clocks = <&clock 273>;
+   clock-names = "mfc";
status = "disabled";
};
 
-- 
1.7.9.5

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


[PATCH v2 3/5] ARM: dts: Update 5250 MFC node

2013-06-19 Thread Arun Kumar K
The patch adds the MFC clock entry for the 5250 SoC and
also moves the common params to newly added exynos5.dtsi.

Signed-off-by: Arun Kumar K 
---
 arch/arm/boot/dts/exynos5.dtsi|5 +
 arch/arm/boot/dts/exynos5250.dtsi |4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..7966a10 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,9 @@
interrupts = <0 42 0>;
status = "disabled";
};
+
+   codec@1100 {
+   reg = <0x1100 0x1>;
+   interrupts = <0 96 0>;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index d04ab0a..5ffdae9 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -165,9 +165,9 @@
 
codec@1100 {
compatible = "samsung,mfc-v6";
-   reg = <0x1100 0x1>;
-   interrupts = <0 96 0>;
samsung,power-domain = <&pd_mfc>;
+   clocks = <&clock 266>;
+   clock-names = "mfc";
};
 
rtc {
-- 
1.7.9.5

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


[PATCH v2 0/5] DT/ARCH updates for MFC

2013-06-19 Thread Arun Kumar K
The patch series updates the DT nodes of MFC in Exynos4,
Exynos 5250 and creates node in 5420. Also updates the
memory reserve in exynos5 for mfc-v7.

Changes from v1:
- Made status disabled in dtsi and enable in dts
  as suggested by Sachin Kamat.
- Moved common properties to exynos5.dtsi as
  suggested by Chander.
- Updated binding documentation for special clk removal
- Updated exynos4 dtsi

Arun Kumar K (5):
  ARM: dts: Update clocks entry in MFC binding documentation
  ARM: dts: Remove unsused MFC clock from exynos4
  ARM: dts: Update 5250 MFC node
  ARM: dts: Add MFC node for exynos 5420
  ARM: EXYNOS: Add mfc-v7 to memory reserve

 .../devicetree/bindings/media/s5p-mfc.txt  |   10 +-
 arch/arm/boot/dts/exynos4.dtsi |4 ++--
 arch/arm/boot/dts/exynos5.dtsi |5 +
 arch/arm/boot/dts/exynos5250.dtsi  |4 ++--
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |6 ++
 arch/arm/boot/dts/exynos5420.dtsi  |7 +++
 arch/arm/mach-exynos/mach-exynos5-dt.c |   14 +-
 7 files changed, 36 insertions(+), 14 deletions(-)

-- 
1.7.9.5

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


[PATCH v2 1/5] ARM: dts: Update clocks entry in MFC binding documentation

2013-06-19 Thread Arun Kumar K
MFC driver is updated to use only one clock instead of
two. Correcting this in the binding documentation.

Signed-off-by: Arun Kumar K 
---
 .../devicetree/bindings/media/s5p-mfc.txt  |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index df37b02..d75c3e5 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -15,9 +15,9 @@ Required properties:
  mapped region.
 
   - interrupts : MFC interrupt number to the CPU.
-  - clocks : from common clock binding: handle to mfc clocks.
-  - clock-names : from common clock binding: must contain "sclk_mfc" and "mfc",
- corresponding to entries in the clocks property.
+  - clocks : from common clock binding: handle to mfc clock.
+  - clock-names : from common clock binding: must contain "mfc",
+ corresponding to entry in the clocks property.
 
   - samsung,mfc-r : Base address of the first memory bank used by MFC
for DMA contiguous memory allocation and its size.
@@ -37,8 +37,8 @@ mfc: codec@1340 {
reg = <0x1340 0x1>;
interrupts = <0 94 0>;
samsung,power-domain = <&pd_mfc>;
-   clocks = <&clock 170>, <&clock 273>;
-   clock-names = "sclk_mfc", "mfc";
+   clocks = <&clock 273>;
+   clock-names = "mfc";
 };
 
 Board specific DT entry:
-- 
1.7.9.5

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


[PATCH v2 4/5] ARM: dts: Add MFC node for exynos 5420

2013-06-19 Thread Arun Kumar K
The patch adds MFC nodes for exynos 5420 and for
smdk 5420 board.

Signed-off-by: Arun Kumar K 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |6 ++
 arch/arm/boot/dts/exynos5420.dtsi |7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..09ebecf 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,10 @@
clock-frequency = <2400>;
};
};
+
+   codec@1100 {
+   samsung,mfc-r = <0x4300 0x80>;
+   samsung,mfc-l = <0x5100 0x80>;
+   status = "okay";
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8474d63..3ef604d 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -100,4 +100,11 @@
clocks = <&clock 260>, <&clock 131>;
clock-names = "uart", "clk_uart_baud0";
};
+
+   codec@1100 {
+   compatible = "samsung,mfc-v7";
+   clocks = <&clock 401>;
+   clock-names = "mfc";
+   status = "disabled";
+   };
 };
-- 
1.7.9.5

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


Re: [PATCH 0/5] ARM: dts: exynos5420: add support for hdmi subsystem

2013-06-19 Thread Chander Kashyap
On 20 June 2013 11:11, Rahul Sharma  wrote:
> Add dt nodes and clocks for hdmi subsystem. It also add pinctrl
> node for hdmi hpd gpio and update binding documents.
>
> This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
> at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git
>
> device tree binding document for hdmi compatible type is update at
> http://www.spinics.net/lists/dri-devel/msg39987.html
>
> Andrew Bresticker (1):
>   ARM: dts: exynos5420: add i2c device nodes
>
> Rahul Sharma (4):
>   ARM: dts: exynos5420: add dt nodes for hdmi subsystem
>   ARM: dts: exynos5420: add clocks for hdmi subsystem
>   ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node
>   ARM: dts: update binding documentation for hdmi subsystem
While populating exnos5420.dtsi, move nodes with common properties
across exynos5420 and exynos5420 to exynos5.dtsi
>
>  .../devicetree/bindings/video/exynos_hdmi.txt  |   17 -
>  .../devicetree/bindings/video/exynos_mixer.txt |4 ++
>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 ++
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |   17 +
>  arch/arm/boot/dts/exynos5420.dtsi  |   74 
> 
>  5 files changed, 116 insertions(+), 3 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



--
with warm regards,
Chander Kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-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] ARM: dts: exynos5420: add i2c device nodes

2013-06-19 Thread Chander Kashyap
On 20 June 2013 11:11, Rahul Sharma  wrote:
> From: Andrew Bresticker 
>
> This adds device-tree nodes for the i2c busses on Exynos
> 5420 platforms.
>
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Rahul Sharma 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |   56 
> +
>  1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8c54c4b..b0ec047 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -24,6 +24,10 @@
> pinctrl2 = &pinctrl_2;
> pinctrl3 = &pinctrl_3;
> pinctrl4 = &pinctrl_4;
> +   i2c0 = &i2c_0;
> +   i2c1 = &i2c_1;
> +   i2c2 = &i2c_2;
> +   i2c3 = &i2c_3;
> };
>
> cpus {
> @@ -145,4 +149,56 @@
> clocks = <&clock 260>, <&clock 131>;
> clock-names = "uart", "clk_uart_baud0";
> };
> +
> +   i2c_0: i2c@12C6 {
> +   compatible = "samsung,s3c2440-i2c";
> +   reg = <0x12C6 0x100>;
> +   interrupts = <0 56 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c0_bus>;
> +   clocks = <&clock 261>;
> +   clock-names = "i2c";
> +   status = "disabled";
> +   };
Please move the common properties of exynos5250 and exynos5420 to exynos5.dtsi.
> +
> +   i2c_1: i2c@12C7 {
> +   compatible = "samsung,s3c2440-i2c";
> +   reg = <0x12C7 0x100>;
> +   interrupts = <0 57 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c1_bus>;
> +   clocks = <&clock 262>;
> +   clock-names = "i2c";
> +   status = "disabled";
> +   };
> +
> +   i2c_2: i2c@12C8 {
> +   compatible = "samsung,s3c2440-i2c";
> +   reg = <0x12C8 0x100>;
> +   interrupts = <0 58 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c2_bus>;
> +   clocks = <&clock 263>;
> +   clock-names = "i2c";
> +   status = "disabled";
> +   };
> +
> +   i2c_3: i2c@12C9 {
> +   compatible = "samsung,s3c2440-i2c";
> +   reg = <0x12C9 0x100>;
> +   interrupts = <0 59 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c3_bus>;
> +   clocks = <&clock 264>;
> +   clock-names = "i2c";
> +   status = "disabled";
> +   };
>  };
> --
> 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



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


[PATCH] ARM: dts: Add device tree support for dwmmc

2013-06-19 Thread Sunil Joshi
From: Alim Akhtar 

This patch adds alias names, device tree nodes for
dw-mmc controller for exynos5420 soc.

Signed-off-by: Alim Akhtar 
Signed-off-by: Prathyush K 
Signed-off-by: Arun Kumar K 
Signed-off-by: Sunil Joshi 
---
 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |2 +-
 arch/arm/boot/dts/exynos5.dtsi |3 ++
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   38 
 arch/arm/boot/dts/exynos5420.dtsi  |   21 +++
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 6d1c098..c48570e 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -15,7 +15,7 @@ Required Properties:
- "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
  specific extensions.
- "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
- specific extensions.
+ and Exynos5420 specific extensions.
 
 * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
   unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..6cb6f03 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -55,6 +55,7 @@
interrupts = <0 75 0>;
#address-cells = <1>;
#size-cells = <0>;
+   status = "disabled";
};
 
dwmmc_1: dwmmc1@1221 {
@@ -62,6 +63,7 @@
interrupts = <0 76 0>;
#address-cells = <1>;
#size-cells = <0>;
+   status = "disabled";
};
 
dwmmc_2: dwmmc2@1222 {
@@ -69,6 +71,7 @@
interrupts = <0 77 0>;
#address-cells = <1>;
#size-cells = <0>;
+   status = "disabled";
};
 
serial@12C0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..d05de7a 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,42 @@
clock-frequency = <2400>;
};
};
+
+   dwmmc0@1220 {
+   status = "okay";
+   num-slots = <1>;
+   broken-cd;
+   bypass-smu;
+   supports-highspeed;
+   fifo-depth = <0x40>;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <0 4>;
+   samsung,dw-mshc-ddr-timing = <0 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   };
+   };
+
+   dwmmc2@1222 {
+   status = "okay";
+   num-slots = <1>;
+   supports-highspeed;
+   fifo-depth = <0x40>;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <4>;
+   };
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..0736994 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -24,6 +24,9 @@
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
+   mshc0 = &dwmmc_0;
+   mshc1 = &dwmmc_1;
+   mshc2 = &dwmmc_2;
};
 
cpus {
@@ -145,4 +148,22 @@
clocks = <&clock 260>, <&clock 131>;
clock-names = "uart", "clk_uart_baud0";
};
+
+   dwmmc_0: dwmmc0@1220 {
+   reg = <0x1220 0x2000>;
+   clocks = <&clock 351>, <&clock 132>;
+   clock-names = "biu", "ciu";
+   };
+
+   dwmmc_1: dwmmc1@1221 {
+   reg = <0x1221 0x2000>;
+   clocks = <&clock 352>, <&clock 133>;
+   clock-names = "biu", "ciu";
+   };
+
+   dwmmc_2: dwmmc2@1222 {
+   reg = <0x1222 0x2000>;
+   clocks = <&clock 353>, <&clock 134>;
+   clock-names = "biu", "ciu";
+   };
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a mes

[PATCH 1/5] ARM: dts: exynos5420: add i2c device nodes

2013-06-19 Thread Rahul Sharma
From: Andrew Bresticker 

This adds device-tree nodes for the i2c busses on Exynos
5420 platforms.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420.dtsi |   56 +
 1 file changed, 56 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..b0ec047 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -24,6 +24,10 @@
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
+   i2c0 = &i2c_0;
+   i2c1 = &i2c_1;
+   i2c2 = &i2c_2;
+   i2c3 = &i2c_3;
};
 
cpus {
@@ -145,4 +149,56 @@
clocks = <&clock 260>, <&clock 131>;
clock-names = "uart", "clk_uart_baud0";
};
+
+   i2c_0: i2c@12C6 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C6 0x100>;
+   interrupts = <0 56 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_bus>;
+   clocks = <&clock 261>;
+   clock-names = "i2c";
+   status = "disabled";
+   };
+
+   i2c_1: i2c@12C7 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C7 0x100>;
+   interrupts = <0 57 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_bus>;
+   clocks = <&clock 262>;
+   clock-names = "i2c";
+   status = "disabled";
+   };
+
+   i2c_2: i2c@12C8 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C8 0x100>;
+   interrupts = <0 58 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_bus>;
+   clocks = <&clock 263>;
+   clock-names = "i2c";
+   status = "disabled";
+   };
+
+   i2c_3: i2c@12C9 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C9 0x100>;
+   interrupts = <0 59 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c3_bus>;
+   clocks = <&clock 264>;
+   clock-names = "i2c";
+   status = "disabled";
+   };
 };
-- 
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


[PATCH 2/5] ARM: dts: exynos5420: add dt nodes for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   15 +++
 arch/arm/boot/dts/exynos5420.dtsi |   12 
 2 files changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..b3721bd 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,19 @@
clock-frequency = <2400>;
};
};
+
+   hdmi {
+   hpd-gpio = <&gpx3 7 0>;
+   };
+
+   i2c_2: i2c@12C8 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <66000>;
+   status = "okay";
+
+   hdmiddc@50 {
+   compatible = "samsung,exynos4210-hdmiddc";
+   reg = <0x50>;
+   };
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index b0ec047..45aadf9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -201,4 +201,16 @@
clock-names = "i2c";
status = "disabled";
};
+
+   hdmi {
+   compatible = "samsung,exynos4212-hdmi";
+   reg = <0x1453 0x7>;
+   interrupts = <0 95 0>;
+   };
+
+   mixer: mixer@1445 {
+   compatible = "samsung,exynos5420-mixer";
+   reg = <0x1445 0x1>;
+   interrupts = <0 94 0>;
+   };
 };
-- 
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


[PATCH 4/5] ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node

2013-06-19 Thread Rahul Sharma
Add pinctrl node for hdmi-hpd gpio pin to exynos5420
device tree files.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
 arch/arm/boot/dts/exynos5420-smdk5420.dts |2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 5848c42..5706ad9 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -59,6 +59,13 @@
interrupt-controller;
#interrupt-cells = <2>;
};
+
+   hdmi_hpd_irq: hdmi-hpd-irq {
+   samsung,pins = "gpx3-7";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <1>;
+   samsung,pin-drv = <0>;
+   };
};
 
pinctrl@1341 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index b3721bd..2d6c74f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -33,6 +33,8 @@
 
hdmi {
hpd-gpio = <&gpx3 7 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_hpd_irq>;
};
 
i2c_2: i2c@12C8 {
-- 
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


[PATCH 5/5] ARM: dts: update binding documentation for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Adding information about clocks to mixer and hdmi dt
nodes. Also removed the updated fields for hpd property.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_hdmi.txt |   17 ++---
 .../devicetree/bindings/video/exynos_mixer.txt|4 
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..5dca3af 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -8,9 +8,20 @@ Required properties:
 - hpd-gpio: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
-   c) pin function mode.
-   d) optional flags and pull up/down.
-   e) drive strength.
+   c) optional flags and pull up/down.
+- clocks: list of clock IDs from SoC clock driver.
+   a) hdmi: It is required for gate operation on aclk_200_disp1 clock
+   which clocks the display1 block.
+   b) sclk_hdmi: It is required for gate operation on sclk_hdmi clock
+   which clocks hdmi IP.
+   c) sclk_pixel: Parent for mux mout_hdmi.
+   d) sclk_hdmiphy: Parent for mux mout_hdmi.
+   e) mout_hdmi: It is required by the driver to switch between the 2
+   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
+   after configuration, parent is set to sclk_hdmiphy else
+   sclk_pixel.
+- clock-names: aliases as per driver requirements for above clock IDs:
+   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..54790a2 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -5,6 +5,10 @@ Required properties:
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
+- clocks: list of clock IDs from SoC clock driver.
+   a) mixer: It is required for gate operation on aclk_200_disp1 clock
+   which clocks the display1 block.
+   b) sclk_hdmi: Parent for mux mout_mixer.
 
 Example:
 
-- 
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


[PATCH 0/5] ARM: dts: exynos5420: add support for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Add dt nodes and clocks for hdmi subsystem. It also add pinctrl
node for hdmi hpd gpio and update binding documents.

This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git

device tree binding document for hdmi compatible type is update at
http://www.spinics.net/lists/dri-devel/msg39987.html

Andrew Bresticker (1):
  ARM: dts: exynos5420: add i2c device nodes

Rahul Sharma (4):
  ARM: dts: exynos5420: add dt nodes for hdmi subsystem
  ARM: dts: exynos5420: add clocks for hdmi subsystem
  ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node
  ARM: dts: update binding documentation for hdmi subsystem

 .../devicetree/bindings/video/exynos_hdmi.txt  |   17 -
 .../devicetree/bindings/video/exynos_mixer.txt |4 ++
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 ++
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   17 +
 arch/arm/boot/dts/exynos5420.dtsi  |   74 
 5 files changed, 116 insertions(+), 3 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


[PATCH 3/5] ARM: dts: exynos5420: add clocks for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Add clocks for hdmi and mixer for exynos5420 SoC.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 45aadf9..60685a2 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -206,11 +206,17 @@
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
+   clocks = <&clock 413>, <&clock 143>, <&clock 144>,
+   <&clock 158>, <&clock 1024>;
+   clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
+   "sclk_hdmiphy", "mout_hdmi";
};
 
mixer: mixer@1445 {
compatible = "samsung,exynos5420-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
+   clocks = <&clock 431>, <&clock 143>;
+   clock-names = "mixer", "sclk_hdmi";
};
 };
-- 
1.7.10.4

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


Re: [PATCH 2/3] ARM: dts: Add MFC node for exynos 5420

2013-06-19 Thread Arun Kumar K
Hi Chander,

On Wed, Jun 19, 2013 at 5:34 PM, Chander Kashyap
 wrote:
> On 19 June 2013 14:22, Arun Kumar K  wrote:
>> The patch adds MFC nodes for exynos 5420 and for
>> smdk 5420 board.
>>
>> Signed-off-by: Arun Kumar K 
>> ---
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts |5 +
>>  arch/arm/boot/dts/exynos5420.dtsi |8 
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> index 08607df..682532c 100644
>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> @@ -30,4 +30,9 @@
>> clock-frequency = <2400>;
>> };
>> };
>> +
>> +   codec@1100 {
>> +   samsung,mfc-r = <0x4300 0x80>;
>> +   samsung,mfc-l = <0x5100 0x80>;
>> +   };
>>  };
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 8474d63..cb74356 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -100,4 +100,12 @@
>> clocks = <&clock 260>, <&clock 131>;
>> clock-names = "uart", "clk_uart_baud0";
>> };
>> +
>> +   codec@1100 {
>> +   compatible = "samsung,mfc-v7";
>> +   reg = <0x1100 0x1>;
>> +   interrupts = <0 96 0>;
>> +   clocks = <&clock 401>;
>> +   clock-names = "mfc";
>> +   };
> Is it not possible to move the common part of this node to common
> exynos5.dtsi? As exynos5250 is using same property values.

Yes that can be done. I have kept it separate as the IP is different
and compatible is also changing. But the reg and interrupt remains same
and hopefully that can be moved to common exynos5.dtsi.

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


Re: [PATCH V6 29/30] ARM: dts: Add device tree node for exynos5440 TMU controller

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds device node for TMU controller. There are 3
> instances of the controllers so 3 nodes are created.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 

Reviewed-by: Eduardo Valentin 

> ---
>  arch/arm/boot/dts/exynos5440.dtsi |   30 ++
>  1 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
> b/arch/arm/boot/dts/exynos5440.dtsi
> index f6b1c89..716e90c 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -16,6 +16,12 @@
>  
>   interrupt-parent = <&gic>;
>  
> + aliases {
> + tmuctrl0 = &tmuctrl_0;
> + tmuctrl1 = &tmuctrl_1;
> + tmuctrl2 = &tmuctrl_2;
> + };
> +
>   clock: clock-controller@0x16 {
>   compatible = "samsung,exynos5440-clock";
>   reg = <0x16 0x1000>;
> @@ -216,4 +222,28 @@
>   clock-names = "rtc";
>   status = "disabled";
>   };
> +
> + tmuctrl_0: tmuctrl@160118 {
> + compatible = "samsung,exynos5440-tmu";
> + reg = <0x160118 0x230>, <0x160368 0x10>;
> + interrupts = <0 58 0>;
> + clocks = <&clock 21>;
> + clock-names = "tmu_apbif";
> + };
> +
> + tmuctrl_1: tmuctrl@16011C {
> + compatible = "samsung,exynos5440-tmu";
> + reg = <0x16011C 0x230>, <0x160368 0x10>;
> + interrupts = <0 58 0>;
> + clocks = <&clock 21>;
> + clock-names = "tmu_apbif";
> + };
> +
> + tmuctrl_2: tmuctrl@160120 {
> + compatible = "samsung,exynos5440-tmu";
> + reg = <0x160120 0x230>, <0x160368 0x10>;
> + interrupts = <0 58 0>;
> + clocks = <&clock 21>;
> + clock-names = "tmu_apbif";
> + };
>  };
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 28/30] thermal: exynos: Support for TMU regulator defined at device tree

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> TMU probe function now checks for a device tree defined regulator.
> For compatibility reasons it is allowed to probe driver even without
> this regulator defined.
> 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  .../devicetree/bindings/thermal/exynos-thermal.txt |4 +++
>  drivers/thermal/samsung/exynos_tmu.c   |   23 
> 
>  2 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index e6386ea..284f530 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -16,6 +16,9 @@
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> +- vtmu-supply: This entry is optional and provides the regulator node 
> supplying
> + voltage to TMU. If needed this entry can be placed inside
> + board/platform specific dts file.
>  
>  Example 1):
>  
> @@ -27,6 +30,7 @@ Example 1):
>   clocks = <&clock 383>;
>   clock-names = "tmu_apbif";
>   status = "disabled";
> + vtmu-supply = <&tmu_regulator_node>;
>   };
>  
>  Example 2):
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 7a259f4..441efd5 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "exynos_thermal_common.h"
>  #include "exynos_tmu.h"
> @@ -48,6 +49,7 @@
>   * @clk: pointer to the clock structure.
>   * @temp_error1: fused value of the first point trim.
>   * @temp_error2: fused value of the second point trim.
> + * @regulator: pointer to the TMU regulator structure.
>   * @reg_conf: pointer to structure to register with core thermal.
>   */
>  struct exynos_tmu_data {
> @@ -61,6 +63,7 @@ struct exynos_tmu_data {
>   struct mutex lock;
>   struct clk *clk;
>   u8 temp_error1, temp_error2;
> + struct regulator *regulator;
>   struct thermal_sensor_conf *reg_conf;
>  };
>  
> @@ -510,10 +513,27 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>   struct exynos_tmu_platform_data *pdata;
>   struct resource res;
> + int ret;
>  
>   if (!data)
>   return -ENODEV;
>  
> + /*
> +  * Try enabling the regulator if found
> +  * TODO: Add regulator as an SOC feature, so that regulator enable
> +  * is a compulsory call.
> +  */
> + data->regulator = devm_regulator_get(&pdev->dev, "vtmu");
> + if (!IS_ERR(data->regulator)) {
> + ret = regulator_enable(data->regulator);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to enable vtmu\n");
> + return ret;
> + }
> + } else {
> + dev_info(&pdev->dev, "Regulator node (vtmu) not found\n");
> + }
> +
>   data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
>   if (data->id < 0)
>   data->id = 0;
> @@ -680,6 +700,9 @@ static int exynos_tmu_remove(struct platform_device *pdev)
>  
>   clk_unprepare(data->clk);
>  
> + if (!IS_ERR(data->regulator))
> + regulator_disable(data->regulator);
> +
>   return 0;
>  }
>  
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 27/30] Documentation: thermal: Explain the exynos thermal driver model

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch updates the documentation to explain the driver model
> and file layout.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  Documentation/thermal/exynos_thermal |   43 ++---
>  1 files changed, 34 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/thermal/exynos_thermal 
> b/Documentation/thermal/exynos_thermal
> index 2b46f67..9010c44 100644
> --- a/Documentation/thermal/exynos_thermal
> +++ b/Documentation/thermal/exynos_thermal
> @@ -1,17 +1,17 @@
> -Kernel driver exynos4_tmu
> +Kernel driver exynos_tmu
>  =
>  
>  Supported chips:
> -* ARM SAMSUNG EXYNOS4 series of SoC
> -  Prefix: 'exynos4-tmu'
> +* ARM SAMSUNG EXYNOS4, EXYNOS5 series of SoC
>Datasheet: Not publicly available
>  
>  Authors: Donggeun Kim 
> +Authors: Amit Daniel 
>  
> -Description
> 
> +TMU controller Description:
> +---
>  
> -This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
> +This driver allows to read temperature inside SAMSUNG EXYNOS4/5 series of 
> SoC.
>  
>  The chip only exposes the measured 8-bit temperature code value
>  through a register.
> @@ -34,9 +34,9 @@ The three equations are:
>TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
> Temperature code measured at 85 degree Celsius which is unchanged
>  
> -TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
> +TMU(Thermal Management Unit) in EXYNOS4/5 generates interrupt
>  when temperature exceeds pre-defined levels.
> -The maximum number of configurable threshold is four.
> +The maximum number of configurable threshold is five.
>  The threshold levels are defined as follows:
>Level_0: current temperature > trigger_level_0 + threshold
>Level_1: current temperature > trigger_level_1 + threshold
> @@ -47,6 +47,31 @@ The threshold levels are defined as follows:
>through the corresponding registers.
>  
>  When an interrupt occurs, this driver notify kernel thermal framework
> -with the function exynos4_report_trigger.
> +with the function exynos_report_trigger.
>  Although an interrupt condition for level_0 can be set,
>  it can be used to synchronize the cooling action.
> +
> +TMU driver description:
> +---
> +
> +The exynos thermal driver is structured as,
> +
> + Kernel Core thermal framework
> + (thermal_core.c, step_wise.c, cpu_cooling.c)
> + ^
> + |
> + |
> +TMU configuration data ---> TMU Driver  <--> Exynos Core thermal 
> wrapper
> +(exynos_tmu_data.c)(exynos_tmu.c)   (exynos_thermal_common.c)
> +(exynos_tmu_data.h)(exynos_tmu.h)   (exynos_thermal_common.h)
> +
> +a) TMU configuration data: This consist of TMU register offsets/bitfields
> + described through structure exynos_tmu_registers. Also several
> + other platform data (struct exynos_tmu_platform_data) members
> + are used to configure the TMU.
> +b) TMU driver: This component initialises the TMU controller and sets 
> different
> + thresholds. It invokes core thermal implementation with the call
> + exynos_report_trigger.
> +c) Exynos Core thermal wrapper: This provides 3 wrapper function to use the
> + Kernel core thermal framework. They are 
> exynos_unregister_thermal,
> + exynos_register_thermal and exynos_report_trigger.
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 26/30] thermal: exynos: Add hardware mode thermal calibration support

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds support for h/w mode calibration in the TMU controller.
> soc's like 5440 support this features.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_tmu.c  |   15 +++
>  drivers/thermal/samsung/exynos_tmu.h  |6 ++
>  drivers/thermal/samsung/exynos_tmu_data.c |2 ++
>  drivers/thermal/samsung/exynos_tmu_data.h |2 ++
>  4 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index af0e6ca..7a259f4 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -73,6 +73,9 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 
> temp)
>   struct exynos_tmu_platform_data *pdata = data->pdata;
>   int temp_code;
>  
> + if (pdata->cal_mode == HW_MODE)
> + return temp;
> +
>   if (data->soc == SOC_ARCH_EXYNOS4210)
>   /* temp should range between 25 and 125 */
>   if (temp < 25 || temp > 125) {
> @@ -107,6 +110,9 @@ static int code_to_temp(struct exynos_tmu_data *data, u8 
> temp_code)
>   struct exynos_tmu_platform_data *pdata = data->pdata;
>   int temp;
>  
> + if (pdata->cal_mode == HW_MODE)
> + return temp_code;
> +
>   if (data->soc == SOC_ARCH_EXYNOS4210)
>   /* temp_code should range between 75 and 175 */
>   if (temp_code < 75 || temp_code > 175) {
> @@ -155,6 +161,9 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
>   __raw_writel(1, data->base + reg->triminfo_ctrl);
>  
> + if (pdata->cal_mode == HW_MODE)
> + goto skip_calib_data;
> +
>   /* Save trimming info in order to perform calibration */
>   if (data->soc == SOC_ARCH_EXYNOS5440) {
>   /*
> @@ -190,6 +199,7 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   (pdata->efuse_value >> reg->triminfo_85_shift) &
>   EXYNOS_TMU_TEMP_MASK;
>  
> +skip_calib_data:
>   if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
>   dev_err(&pdev->dev, "Invalid max trigger level\n");
>   goto out;
> @@ -319,6 +329,11 @@ static void exynos_tmu_control(struct platform_device 
> *pdev, bool on)
>   con |= (pdata->noise_cancel_mode << reg->therm_trip_mode_shift);
>   }
>  
> + if (pdata->cal_mode == HW_MODE) {
> + con &= ~(reg->calib_mode_mask << reg->calib_mode_shift);
> + con |= pdata->cal_type << reg->calib_mode_shift;

cal_type is an enum and you don't set any constant value to those
enumerations. are you sure you want to rely on it for bit field handling?

> + }
> +
>   if (on) {
>   con |= (1 << reg->core_en_shift);
>   interrupt_en =
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index 73aaed7..abfa1eb 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -88,6 +88,10 @@ enum soc_type {
>   * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
>   register.
>   * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl 
> register.
> + * @calib_mode_shift: shift bits of calibration mode value in tmu_ctrl
> + register.
> + * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
> + register.
>   * @therm_trip_tq_en_shift: shift bits of thermal trip enable by TQ pin in
>   tmu_ctrl register.
>   * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
> @@ -149,6 +153,8 @@ struct exynos_tmu_registers {
>   u32 therm_trip_en_shift;
>   u32 buf_slope_sel_shift;
>   u32 buf_slope_sel_mask;
> + u32 calib_mode_shift;
> + u32 calib_mode_mask;
>   u32 therm_trip_tq_en_shift;
>   u32 core_en_shift;
>  
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index b34e726..47c5d6b 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -189,6 +189,8 @@ static const struct exynos_tmu_registers 
> exynos5440_tmu_registers = {
>   .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
>   .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
>   .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .calib_mode_shift = EXYNOS_TMU_CALIB_MODE_SHIFT,
> + .calib_mode_mask = EXYNOS_TMU_CALIB_MODE_MASK,
>   .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
>   .tmu_status = EXYNOS5440_TMU_S0_7_STATUS,
>   .tmu_cur_temp = EXYNOS5440_TMU_S0_7_TEMP,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
> b/drivers/thermal/samsung/exynos_tmu_

Re: [PATCH V6 25/30] thermal: exynos: Fix to set the second point correction value

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch sets the second point trimming value according to the platform
> data if the register value is 0.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_tmu.c |   13 +
>  1 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index a4dbc84..af0e6ca 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -180,10 +180,15 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
>   EXYNOS_TMU_TEMP_MASK);
>  
> - if ((pdata->min_efuse_value > data->temp_error1) ||
> - (data->temp_error1 > pdata->max_efuse_value) ||
> - (data->temp_error2 != 0))
> - data->temp_error1 = pdata->efuse_value;
> + if (!data->temp_error1 ||
> + (pdata->min_efuse_value > data->temp_error1) ||
> + (data->temp_error1 > pdata->max_efuse_value))
> + data->temp_error1 = pdata->efuse_value & EXYNOS_TMU_TEMP_MASK;
> +
> + if (!data->temp_error2)
> + data->temp_error2 =
> + (pdata->efuse_value >> reg->triminfo_85_shift) &
> + EXYNOS_TMU_TEMP_MASK;
>  
>   if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
>   dev_err(&pdev->dev, "Invalid max trigger level\n");
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Hi Tomasz, Lucas,

How does this patch look to you ? Please share your views.

regards,
Rahul Sharma.

On Wed, Jun 19, 2013 at 6:21 PM, Rahul Sharma  wrote:
> This patch adds new combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Drivers continue to support the previous compatible strings
> but further addition of these compatible strings in device tree
> is deprecated.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/video/exynos_hdmi.txt   |7 +--
>  .../devicetree/bindings/video/exynos_hdmiddc.txt  |7 +--
>  .../devicetree/bindings/video/exynos_hdmiphy.txt  |7 +--
>  Documentation/devicetree/bindings/video/exynos_mixer.txt  |8 ++--
>  drivers/gpu/drm/exynos/exynos_ddc.c   |2 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
>  drivers/gpu/drm/exynos/exynos_hdmiphy.c   |4 
>  drivers/gpu/drm/exynos/exynos_mixer.c |   13 
> -
>  8 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..c71d0f0 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,10 @@
>  Device-Tree bindings for drm hdmi driver
>
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> +   1) "samsung,exynos5-hdmi" 
> +   2) "samsung,exynos4210-hdmi"
> +   3) "samsung,exynos4212-hdmi"
>  - reg: physical base address of the hdmi and length of memory mapped
> region.
>  - interrupts: interrupt number to the cpu.
> @@ -15,7 +18,7 @@ Required properties:
>  Example:
>
> hdmi {
> -   compatible = "samsung,exynos5-hdmi";
> +   compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..41eee97 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,15 @@
>  Device-Tree bindings for hdmiddc driver
>
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be one of the following
> +   1) "samsung,exynos5-hdmiddc" 
> +   2) "samsung,exynos4210-hdmiddc"
> +
>  - reg: I2C address of the hdmiddc device.
>
>  Example:
>
> hdmiddc {
> -   compatible = "samsung,exynos5-hdmiddc";
> +   compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..162f641 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,15 @@
>  Device-Tree bindings for hdmiphy driver
>
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be one of the following:
> +   1) "samsung,exynos5-hdmiphy" 
> +   2) "samsung,exynos4210-hdmiphy".
> +   3) "samsung,exynos4212-hdmiphy".
>  - reg: I2C address of the hdmiphy device.
>
>  Example:
>
> hdmiphy {
> -   compatible = "samsung,exynos5-hdmiphy";
> +   compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..9131b99 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,11 @@
>  Device-Tree bindings for mixer driver
>
>  Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be one of the following:
> +   1) "samsung,exynos5-mixer" 
> +   2) "samsung,exynos4210-mixer"
> +   3) "samsung,exynos5250-mixer"
> +
>  - reg: physical base address of the mixer and length of memory mapped
> region.
>  - interrupts: interrupt number to the cpu.
> @@ -9,7 +13,7 @@ Required properties:
>  Example:
>
> mixer {
> -   compatible = "samsung,exynos5-mixer";
> +   compatible = "samsung,exynos5250-mixer";
> reg = <0x1445 0x1>;
> 

Re: [PATCH V6 24/30] thermal: exynos: Add thermal configuration data for exynos5440 TMU sensor

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds configuration data for exynos5440 soc. Also register
> definations for the controller are added.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_tmu.c  |4 ++
>  drivers/thermal/samsung/exynos_tmu_data.c |   71 
> +
>  drivers/thermal/samsung/exynos_tmu_data.h |7 +++
>  3 files changed, 82 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index db4035d..a4dbc84 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -455,6 +455,10 @@ static const struct of_device_id exynos_tmu_match[] = {
>   .compatible = "samsung,exynos5250-tmu",
>   .data = (void *)EXYNOS5250_TMU_DRV_DATA,
>   },
> + {
> + .compatible = "samsung,exynos5440-tmu",
> + .data = (void *)EXYNOS5440_TMU_DRV_DATA,
> + },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, exynos_tmu_match);
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index 694557e..b34e726 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -175,3 +175,74 @@ struct exynos_tmu_init_data const 
> exynos5250_default_tmu_data = {
>   .tmu_count = 1,
>  };
>  #endif
> +
> +#if defined(CONFIG_SOC_EXYNOS5440)
> +static const struct exynos_tmu_registers exynos5440_tmu_registers = {
> + .triminfo_data = EXYNOS5440_TMU_S0_7_TRIM,
> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .tmu_ctrl = EXYNOS5440_TMU_S0_7_CTRL,
> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
> + .tmu_status = EXYNOS5440_TMU_S0_7_STATUS,
> + .tmu_cur_temp = EXYNOS5440_TMU_S0_7_TEMP,
> + .threshold_th0 = EXYNOS5440_TMU_S0_7_TH0,
> + .threshold_th1 = EXYNOS5440_TMU_S0_7_TH1,
> + .threshold_th2 = EXYNOS5440_TMU_S0_7_TH2,
> + .threshold_th3_l0_shift = EXYNOS5440_TMU_TH_RISE4_SHIFT,
> + .tmu_inten = EXYNOS5440_TMU_S0_7_IRQEN,
> + .inten_rise_mask = EXYNOS5440_TMU_RISE_INT_MASK,
> + .inten_rise_shift = EXYNOS5440_TMU_RISE_INT_SHIFT,
> + .inten_fall_mask = EXYNOS5440_TMU_FALL_INT_MASK,
> + .inten_fall_shift = EXYNOS5440_TMU_FALL_INT_SHIFT,
> + .inten_rise0_shift = EXYNOS5440_TMU_INTEN_RISE0_SHIFT,
> + .inten_rise1_shift = EXYNOS5440_TMU_INTEN_RISE1_SHIFT,
> + .inten_rise2_shift = EXYNOS5440_TMU_INTEN_RISE2_SHIFT,
> + .inten_rise3_shift = EXYNOS5440_TMU_INTEN_RISE3_SHIFT,
> + .inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
> + .tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
> + .tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
> + .emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
> + .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> + .tmu_pmin = EXYNOS5440_TMU_PMIN,
> +};
> +
> +#define EXYNOS5440_TMU_DATA \
> + .trigger_levels[0] = 100, \
> + .trigger_levels[4] = 105, \
> + .trigger_enable[0] = 1, \
> + .trigger_type[0] = SW_TRIP, \
> + .trigger_type[4] = HW_TRIP, \

No active / passive cooling?

> + .max_trigger_level = 5, \
> + .gain = 5, \
> + .reference_voltage = 16, \
> + .noise_cancel_mode = 4, \
> + .cal_type = TYPE_ONE_POINT_TRIMMING, \
> + .cal_mode = 0, \
> + .efuse_value = 0x5b2d, \
> + .min_efuse_value = 16, \
> + .max_efuse_value = 76, \
> + .first_point_trim = 25, \
> + .second_point_trim = 70, \
> + .default_temp_offset = 25, \
> + .type = SOC_ARCH_EXYNOS5440, \
> + .registers = &exynos5440_tmu_registers, \
> + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
> + TMU_SUPPORT_MULTI_INST | TMU_SUPPORT_SHARED_MEMORY),

No freq table on 5440? hmm.. So no cpufreq_cooling then? Any reason why
not? I suppose one of these 3 sensors are on your CPU domain, right?

> +
> +struct exynos_tmu_init_data const exynos5440_default_tmu_data = {
> + .tmu_data = {
> + { EXYNOS5440_TMU_DATA } ,
> + { EXYNOS5440_TMU_DATA } ,
> + { EXYNOS5440_TMU_DATA } ,
> + },
> + .tmu_count = 3,
> +};
> +#endif
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
> b/drivers/thermal/samsung/exynos_tmu_data.h
> index ad263e9..43ce5fb 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.h
> +++ b/d

Re: [PATCH V6 23/30] thermal: exynos: Add driver support for exynos5440 TMU sensor

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, 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: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Jungseok Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   24 -
>  drivers/thermal/samsung/exynos_thermal_common.h|2 +-
>  drivers/thermal/samsung/exynos_tmu.c   |   54 
> +---
>  drivers/thermal/samsung/exynos_tmu.h   |6 ++
>  drivers/thermal/samsung/exynos_tmu_data.h  |   36 +
>  5 files changed, 112 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 0ea33f7..e6386ea 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -6,6 +6,7 @@
>  "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. For soc's which has multiple
>   instances of TMU and some registers are shared across all TMU's like
> @@ -16,7 +17,7 @@
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
>  
> -Example:
> +Example 1):
>  
>   tmu@100C {
>   compatible = "samsung,exynos4412-tmu";
> @@ -27,3 +28,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_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 0c189d6..7d7c29a 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -27,7 +27,7 @@
>  #define SENSOR_NAME_LEN  16
>  #define MAX_TRIP_COUNT   8
>  #define MAX_COOLING_DEVICE 4
> -#define MAX_THRESHOLD_LEVS 4
> +#define MAX_THRESHOLD_LEVS 5
>  
>  #define ACTIVE_INTERVAL 500
>  #define IDLE_INTERVAL 1
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 150a869..db4035d 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -156,7 +156,26 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   __raw_writel(1, data->base + reg->triminfo_ctrl);
>  
>   /* Save trimming info in order to perform calibration */
> - trim_info = readl(data->base + reg->triminfo_data);
> + if (data->soc == SOC_ARCH_EXYNOS5440) {

should this become some bit at your pdata->features? TMU_SUPPORTS(pdata,
TRIMINFO) for instance?

> + /*
> +  * For exynos5440 soc triminfo value is swapped between TMU0 and
> +  * TMU2, so the below logic is needed.
> +  */
> + switch (data->id) {
> + case 0:
> + trim_info = readl(data->base +
> + EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> + break;
> + case 1:
> + trim_info = readl(data->base + reg->triminfo_data);
> + break;
> + case 2:
> + trim_info = readl(data->base -
> + EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> + }
> + } else {
> + trim_info = readl(data->base + reg->triminfo_data);
> + }
>   data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
>   data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
>   EXYNOS_TMU_TEMP_MASK);
> @@ -201,7 +220,8 @@ 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

Re: [PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer

2013-06-19 Thread 김승우
Hello Rahul,

This patch is exactly same with v2 2/4 and only rebased on v3 1/3, so my
ack is valid for this patch.

On 2013년 06월 19일 21:51, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
> 
> Signed-off-by: Rahul Sharma 

Acked-by: Seung-Woo Kim 

Anyway, this patch can be merged after merging [Patch v3 1/3] as like v2.

Best Regards,
- Seung-Woo Kim

> ---
>  .../devicetree/bindings/video/exynos_mixer.txt |1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   49 
> +++-
>  drivers/gpu/drm/exynos/regs-mixer.h|7 +++
>  3 files changed, 45 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9131b99..3334b0a 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -5,6 +5,7 @@ Required properties:
>   1) "samsung,exynos5-mixer" 
>   2) "samsung,exynos4210-mixer"
>   3) "samsung,exynos5250-mixer"
> + 4) "samsung,exynos5420-mixer"
>  
>  - reg: physical base address of the mixer and length of memory mapped
>   region.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6225501..b1280b4 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
>  };
>  
>  struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> unsigned int height)
>   val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>   MXR_CFG_SCAN_PROGRASSIVE);
>  
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>  
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>  }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
> *ctx, int win)
>   /* setup geometry */
>   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>  
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
>   val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>   val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>   val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
> int win)
>   mixer_cfg_layer(ctx, win, true);
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>   mixer_layer_update(ctx);
>  
>   mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>  
>  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>  {
> + struct mixer_context *mixer_ctx = ctx;
>   u32 w, h;
>  
>   w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
> drm_display_mode *mode)
>   mode->hdisplay, mode->vdisplay, mode->vrefresh,
>   (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>  
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
>   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>   (w >= 1664 && w <= 1920 && h >= 936 && h 

Re: [PATCH V6 22/30] thermal: exynos: Add support to access common register for multistance

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds support to parse one more common set of TMU register. First
> set of register belongs to each instance of TMU and second set belongs to
> common TMU registers.
> 
> Acked-by: Jonghwa Lee 
> Acked-by: Kukjin Kim 
> Signed-off-by: Amit Daniel Kachhap 

This patch is fine:

Acked-by: Eduardo Valentin 

But please read my concern on next patch.

> ---
>  .../devicetree/bindings/thermal/exynos-thermal.txt |6 +-
>  drivers/thermal/samsung/exynos_tmu.c   |   20 
> 
>  2 files changed, 25 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 535fd0e..0ea33f7 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -7,7 +7,11 @@
>  "samsung,exynos4210-tmu"
>  "samsung,exynos5250-tmu"
>  - interrupt-parent : The phandle for the interrupt controller
> -- reg : Address range of the thermal registers
> +- reg : Address range of the thermal registers. For soc's which has multiple
> + instances of TMU and some registers are shared across all TMU's like
> + interrupt related then 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
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 877dab8..150a869 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -40,6 +40,7 @@
>   * @id: identifier of the one instance of the TMU controller.
>   * @pdata: pointer to the tmu platform/configuration data
>   * @base: base address of the single instance of the TMU controller.
> + * @base_common: base address of the common registers of the TMU controller.
>   * @irq: irq number of the TMU controller.
>   * @soc: id of the SOC type.
>   * @irq_work: pointer to the irq work structure.
> @@ -53,6 +54,7 @@ struct exynos_tmu_data {
>   int id;
>   struct exynos_tmu_platform_data *pdata;
>   void __iomem *base;
> + void __iomem *base_common;
>   int irq;
>   enum soc_type soc;
>   struct work_struct irq_work;
> @@ -478,6 +480,24 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>   return -ENODEV;
>   }
>   data->pdata = pdata;
> + /*
> +  * Check if the TMU shares some registers and then try to map the
> +  * memory of common registers.
> +  */
> + if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
> + return 0;
> +
> + if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
> + dev_err(&pdev->dev, "failed to get Resource 1\n");
> + return -ENODEV;
> + }
> +
> + data->base_common = devm_ioremap(&pdev->dev, res.start,
> + resource_size(&res));
> + if (!data->base) {
> + dev_err(&pdev->dev, "Failed to ioremap memory\n");
> + return -ENOMEM;
> + }
>  
>   return 0;
>  }
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 21/30] ARM: dts: thermal: exynos4: Add documentation for Exynos SoC thermal bindings

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> From: Lukasz Majewski 
> 
> Proper description for Exynos4 bindings added to Documentation/devicetree/
> bindings
> 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   25 
> 
>  1 files changed, 25 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> new file mode 100644
> index 000..535fd0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -0,0 +1,25 @@
> +* Exynos Thermal Management Unit (TMU)
> +
> +** Required properties:
> +
> +- compatible : One of the following:
> +"samsung,exynos4412-tmu"
> +"samsung,exynos4210-tmu"
> +"samsung,exynos5250-tmu"
> +- interrupt-parent : The phandle for the interrupt controller
> +- reg : Address range of the thermal registers
> +- interrupts : Should contain interrupt for thermal system
> +- clocks : The main clock for TMU device
> +- clock-names : Thermal system clock name

Should this include the documentation on the alias needed by patch 18?
tmuctrl?


> +
> +Example:
> +
> + tmu@100C {
> + compatible = "samsung,exynos4412-tmu";
> + interrupt-parent = <&combiner>;
> + reg = <0x100C 0x100>;
> + interrupts = <2 4>;
> + clocks = <&clock 383>;
> + clock-names = "tmu_apbif";
> + status = "disabled";
> + };
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 20/30] thermal: exynos: use device resource management infrastructure

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch uses the device pointer stored in the configuration structure
> and converts to dev_* prints and devm API's.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 


Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_thermal_common.c |   39 ++
>  1 files changed, 25 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 2873ca3..59b47e3 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -52,7 +52,8 @@ static int exynos_set_mode(struct thermal_zone_device 
> *thermal,
>  {
>   struct exynos_thermal_zone *th_zone = thermal->devdata;
>   if (!th_zone) {
> - pr_notice("thermal zone not registered\n");
> + dev_err(th_zone->sensor_conf->dev,
> + "thermal zone not registered\n");
>   return 0;
>   }
>  
> @@ -68,8 +69,9 @@ static int exynos_set_mode(struct thermal_zone_device 
> *thermal,
>  
>   th_zone->mode = mode;
>   thermal_zone_device_update(thermal);
> - pr_info("thermal polling set for duration=%d msec\n",
> - thermal->polling_delay);
> + dev_dbg(th_zone->sensor_conf->dev,
> + "thermal polling set for duration=%d msec\n",
> + thermal->polling_delay);
>   return 0;
>  }
>  
> @@ -159,7 +161,8 @@ static int exynos_bind(struct thermal_zone_device 
> *thermal,
>   case WARN_ZONE:
>   if (thermal_zone_bind_cooling_device(thermal, i, cdev,
>   level, 0)) {
> - pr_err("error binding cdev inst %d\n", i);
> + dev_err(data->dev,
> + "error unbinding cdev inst=%d\n", i);
>   ret = -EINVAL;
>   }
>   th_zone->bind = true;
> @@ -204,7 +207,8 @@ static int exynos_unbind(struct thermal_zone_device 
> *thermal,
>   case WARN_ZONE:
>   if (thermal_zone_unbind_cooling_device(thermal, i,
>   cdev)) {
> - pr_err("error unbinding cdev inst=%d\n", i);
> + dev_err(data->dev,
> + "error unbinding cdev inst=%d\n", i);
>   ret = -EINVAL;
>   }
>   th_zone->bind = false;
> @@ -224,7 +228,8 @@ static int exynos_get_temp(struct thermal_zone_device 
> *thermal,
>   void *data;
>  
>   if (!th_zone->sensor_conf) {
> - pr_info("Temperature sensor not initialised\n");
> + dev_err(th_zone->sensor_conf->dev,
> + "Temperature sensor not initialised\n");
>   return -EINVAL;
>   }
>   data = th_zone->sensor_conf->driver_data;
> @@ -243,7 +248,8 @@ static int exynos_set_emul_temp(struct 
> thermal_zone_device *thermal,
>   struct exynos_thermal_zone *th_zone = thermal->devdata;
>  
>   if (!th_zone->sensor_conf) {
> - pr_info("Temperature sensor not initialised\n");
> + dev_err(th_zone->sensor_conf->dev,
> + "Temperature sensor not initialised\n");
>   return -EINVAL;
>   }
>   data = th_zone->sensor_conf->driver_data;
> @@ -337,11 +343,13 @@ int exynos_register_thermal(struct thermal_sensor_conf 
> *sensor_conf)
>   struct exynos_thermal_zone *th_zone;
>  
>   if (!sensor_conf || !sensor_conf->read_temperature) {
> - pr_err("Temperature sensor not initialised\n");
> + dev_err(sensor_conf->dev,
> + "Temperature sensor not initialised\n");
>   return -EINVAL;
>   }
>  
> - th_zone = kzalloc(sizeof(struct exynos_thermal_zone), GFP_KERNEL);
> + th_zone = devm_kzalloc(sensor_conf->dev,
> + sizeof(struct exynos_thermal_zone), GFP_KERNEL);
>   if (!th_zone)
>   return -ENOMEM;
>  
> @@ -350,7 +358,8 @@ int exynos_register_thermal(struct thermal_sensor_conf 
> *sensor_conf)
>   cpumask_set_cpu(0, &mask_val);
>   th_zone->cool_dev[0] = cpufreq_cooling_register(&mask_val);
>   if (IS_ERR(th_zone->cool_dev[0])) {
> - pr_err("Failed to register cpufreq cooling device\n");
> + dev_err(sensor_conf->dev,
> + "Failed to register cpufreq cooling device\n");
>   ret = -EINVAL;
>   goto err_unregister;
>   }
> @@ -364,14 +373,16 @@ int exynos_register_thermal(struct thermal_sensor_conf 
> *sensor_conf)
> 

Re: [PATCH V6 19/30] thermal: exynos: Add TMU features to check instead of using SOC type

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds several features supported by TMU as bitfields.
> This features varies across different SOC type and comparing
> the features present in the TMU is more logical than comparing
> the soc itself.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_tmu.c  |   26 +++-
>  drivers/thermal/samsung/exynos_tmu.h  |   31 
> +
>  drivers/thermal/samsung/exynos_tmu_data.c |6 -
>  3 files changed, 52 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 1880c4e..877dab8 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -142,13 +142,15 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   mutex_lock(&data->lock);
>   clk_enable(data->clk);
>  
> - status = readb(data->base + reg->tmu_status);
> - if (!status) {
> - ret = -EBUSY;
> - goto out;
> + if (TMU_SUPPORTS(pdata, READY_STATUS)) {
> + status = readb(data->base + reg->tmu_status);
> + if (!status) {
> + ret = -EBUSY;
> + goto out;
> + }
>   }
>  
> - if (data->soc == SOC_ARCH_EXYNOS)
> + if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
>   __raw_writel(1, data->base + reg->triminfo_ctrl);
>  
>   /* Save trimming info in order to perform calibration */
> @@ -287,7 +289,7 @@ static void exynos_tmu_control(struct platform_device 
> *pdev, bool on)
>   pdata->trigger_enable[2] << reg->inten_rise2_shift |
>   pdata->trigger_enable[1] << reg->inten_rise1_shift |
>   pdata->trigger_enable[0] << reg->inten_rise0_shift;
> - if (pdata->threshold_falling)
> + if (TMU_SUPPORTS(pdata, FALLING_TRIP))
>   interrupt_en |=
>   interrupt_en << reg->inten_fall0_shift;
>   } else {
> @@ -329,7 +331,7 @@ static int exynos_tmu_set_emulation(void *drv_data, 
> unsigned long temp)
>   unsigned int val;
>   int ret = -EINVAL;
>  
> - if (data->soc == SOC_ARCH_EXYNOS4210)
> + if (!TMU_SUPPORTS(pdata, EMULATION))
>   goto out;
>  
>   if (temp && temp < MCELSIUS)
> @@ -343,9 +345,13 @@ static int exynos_tmu_set_emulation(void *drv_data, 
> unsigned long temp)
>   if (temp) {
>   temp /= MCELSIUS;
>  
> - val = (EXYNOS_EMUL_TIME << reg->emul_time_shift) |
> - (temp_to_code(data, temp)
> -  << reg->emul_temp_shift) | EXYNOS_EMUL_ENABLE;
> + if (TMU_SUPPORTS(pdata, EMUL_TIME)) {
> + val &= ~(EXYNOS_EMUL_TIME_MASK << reg->emul_time_shift);
> + val |= (EXYNOS_EMUL_TIME << reg->emul_time_shift);
> + }
> + val &= ~(EXYNOS_EMUL_DATA_MASK << reg->emul_temp_shift);
> + val |= (temp_to_code(data, temp) << reg->emul_temp_shift) |
> + EXYNOS_EMUL_ENABLE;
>   } else {
>   val &= ~EXYNOS_EMUL_ENABLE;
>   }
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index b614407..6f55673 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -41,6 +41,34 @@ enum soc_type {
>  };
>  
>  /**
> + * EXYNOS TMU supported features.
> + * TMU_SUPPORT_EMULATION - This features is used to set user defined
> + *   temperature to the TMU controller.
> + * TMU_SUPPORT_MULTI_INST - This features denotes that the soc
> + *   has many instances of TMU.
> + * TMU_SUPPORT_TRIM_RELOAD - This features shows that trimming can
> + *   be reloaded.
> + * TMU_SUPPORT_FALLING_TRIP - This features shows that interrupt can
> + *   be registered for falling trips also.
> + * TMU_SUPPORT_READY_STATUS - This feature tells that the TMU current
> + *   state(active/idle) can be checked.
> + * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
> + *   sample time.
> + * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
> + *   sensors shares some common registers.
> + * TMU_SUPPORT - macro to compare the above features with the supplied.
> + */
> +#define TMU_SUPPORT_EMULATIONBIT(0)
> +#define TMU_SUPPORT_MULTI_INST   BIT(1)
> +#define TMU_SUPPORT_TRIM_RELOAD  BIT(2)
> +#define TMU_SUPPORT_FALLING_TRIP BIT(3)
> +#define TMU_SUPPORT_READY_STATUS BIT(4)
> +#define TMU_SUPPORT_EMUL_TIMEBIT(5)
> +#define TMU_SUPPORT_SHARED_M

Re: [PATCH V6 18/30] thermal: exynos: Add support to handle many instances of TMU

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds support to handle multiple instances of the TMU controllers.
> This is done by removing the static structure to register with the core 
> thermal
> and creating it dynamically for each instance of the TMU controller. The
> interrupt is made shared type to handle shared interrupts. Also
> the identifier of the TMU controller is extracted from device tree alias.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_thermal_common.h |1 +
>  drivers/thermal/samsung/exynos_tmu.c|  147 
> ---
>  drivers/thermal/samsung/exynos_tmu.h|   13 ++
>  drivers/thermal/samsung/exynos_tmu_data.c   |  145 --
>  drivers/thermal/samsung/exynos_tmu_data.h   |4 +-
>  5 files changed, 197 insertions(+), 113 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index dd0077e..0c189d6 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -84,6 +84,7 @@ struct thermal_sensor_conf {
>   struct thermal_cooling_conf cooling_data;
>   void *driver_data;
>   void *pzone_data;
> + struct device *dev;
>  };
>  
>  /*Functions used exynos based thermal sensor driver*/
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 4356118..1880c4e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -26,15 +26,32 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "exynos_thermal_common.h"
>  #include "exynos_tmu.h"
>  #include "exynos_tmu_data.h"
>  
> +/**
> + * struct exynos_tmu_data : A structure to hold the private data of the TMU
> + driver
> + * @id: identifier of the one instance of the TMU controller.
> + * @pdata: pointer to the tmu platform/configuration data
> + * @base: base address of the single instance of the TMU controller.
> + * @irq: irq number of the TMU controller.
> + * @soc: id of the SOC type.
> + * @irq_work: pointer to the irq work structure.
> + * @lock: lock to implement synchronization.
> + * @clk: pointer to the clock structure.
> + * @temp_error1: fused value of the first point trim.
> + * @temp_error2: fused value of the second point trim.
> + * @reg_conf: pointer to structure to register with core thermal.
> + */
>  struct exynos_tmu_data {
> + int id;
>   struct exynos_tmu_platform_data *pdata;
> - struct resource *mem;
>   void __iomem *base;
>   int irq;
>   enum soc_type soc;
> @@ -42,6 +59,7 @@ struct exynos_tmu_data {
>   struct mutex lock;
>   struct clk *clk;
>   u8 temp_error1, temp_error2;
> + struct thermal_sensor_conf *reg_conf;
>  };
>  
>  /*
> @@ -345,12 +363,6 @@ static int exynos_tmu_set_emulation(void *drv_data,  
> unsigned long temp)
>   { return -EINVAL; }
>  #endif/*CONFIG_THERMAL_EMULATION*/
>  
> -static struct thermal_sensor_conf exynos_sensor_conf = {
> - .name   = "exynos-therm",
> - .read_temperature   = (int (*)(void *))exynos_tmu_read,
> - .write_emul_temp= exynos_tmu_set_emulation,
> -};
> -
>  static void exynos_tmu_work(struct work_struct *work)
>  {
>   struct exynos_tmu_data *data = container_of(work,
> @@ -359,7 +371,7 @@ static void exynos_tmu_work(struct work_struct *work)
>   const struct exynos_tmu_registers *reg = pdata->registers;
>   unsigned int val_irq;
>  
> - exynos_report_trigger(&exynos_sensor_conf);
> + exynos_report_trigger(data->reg_conf);
>   mutex_lock(&data->lock);
>   clk_enable(data->clk);
>  
> @@ -404,33 +416,73 @@ MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>  #endif
>  
>  static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
> - struct platform_device *pdev)
> + struct platform_device *pdev, int id)
>  {
> + struct  exynos_tmu_init_data *data_table;
> + struct exynos_tmu_platform_data *tmu_data;
>  #ifdef CONFIG_OF
>   if (pdev->dev.of_node) {
>   const struct of_device_id *match;
>   match = of_match_node(exynos_tmu_match, pdev->dev.of_node);
>   if (!match)
>   return NULL;
> - return (struct exynos_tmu_platform_data *) match->data;
> + data_table = (struct exynos_tmu_init_data *) match->data;
> + if (!data_table || id >= data_table->tmu_count)
> + return NULL;
> + tmu_data = data_table->tmu_data;
> + return (struct exynos_tmu_platform_data *) (tmu_data + id);
>   }
>  #endif
>   return NULL;
>  }
>  
> -static int exynos_tmu_probe(struct platform_device *pdev)
> +static int exynos_map_dt_data(struct platfor

Re: [PATCH V6 17/30] thermal: exynos: Remove non DT based support

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> Recently non DT support from Exynos platform is removed and hence
> removing non DT support from the driver also. This will help in easy
> maintainence.
> 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_tmu.c |   17 +
>  1 files changed, 1 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index acbd295..4356118 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -403,19 +403,6 @@ static const struct of_device_id exynos_tmu_match[] = {
>  MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>  #endif
>  
> -static struct platform_device_id exynos_tmu_driver_ids[] = {
> - {
> - .name   = "exynos4210-tmu",
> - .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
> - },
> - {
> - .name   = "exynos5250-tmu",
> - .driver_data= (kernel_ulong_t)EXYNOS5250_TMU_DRV_DATA,
> - },
> - { },
> -};
> -MODULE_DEVICE_TABLE(platform, exynos_tmu_driver_ids);
> -
>  static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
>   struct platform_device *pdev)
>  {
> @@ -428,8 +415,7 @@ static inline struct  exynos_tmu_platform_data 
> *exynos_get_driver_data(
>   return (struct exynos_tmu_platform_data *) match->data;
>   }
>  #endif
> - return (struct exynos_tmu_platform_data *)
> - platform_get_device_id(pdev)->driver_data;
> + return NULL;
>  }
>  
>  static int exynos_tmu_probe(struct platform_device *pdev)
> @@ -586,7 +572,6 @@ static struct platform_driver exynos_tmu_driver = {
>   },
>   .probe = exynos_tmu_probe,
>   .remove = exynos_tmu_remove,
> - .id_table = exynos_tmu_driver_ids,
>  };
>  
>  module_platform_driver(exynos_tmu_driver);
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 15/30] thermal: exynos: Return success even if no cooling data supplied

2013-06-19 Thread Eduardo Valentin
On 19-06-2013 18:54, Eduardo Valentin wrote:
> On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
>> This patch removes the error return in the bind/unbind routine
>> as the platform may not register any cpufreq cooling data.
>>
>> Acked-by: Kukjin Kim 
>> Acked-by: Jonghwa Lee 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
>> b/drivers/thermal/samsung/exynos_thermal_common.c
>> index 7064eb7..86d39aa 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.c
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
>> @@ -131,7 +131,7 @@ static int exynos_bind(struct thermal_zone_device 
>> *thermal,
>>  tab_size = data->cooling_data.freq_clip_count;
>>  
>>  if (tab_ptr == NULL || tab_size == 0)
>> -return -EINVAL;
>> +return 0;
>>  
>>  /* find the cooling device registered*/
>>  for (i = 0; i < th_zone->cool_dev_size; i++)
>> @@ -180,7 +180,7 @@ static int exynos_unbind(struct thermal_zone_device 
>> *thermal,
>>  tab_size = data->cooling_data.freq_clip_count;
>>  
>>  if (tab_size == 0)
>> -return -EINVAL;
>> +return 0;
>>  
>>  /* find the cooling device registered*/
>>  for (i = 0; i < th_zone->cool_dev_size; i++)
>>
> 
> I have one question before acking this one: what happens if one
> registers a TMU with no freq tab? Say the case where you have three
> sensors, just like SOC_ARCH_EXYNOS5440. Would you register
> cpufreq_cooling device for all of them? In other way, are you having 3
> cpufreq_cooling devices?

I am actually fine with this patch. just saw that you adjust things on
patch 16.

Acked-by: Eduardo Valentin 

> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 16/30] thermal: exynos: Make the zone handling use trip information

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This code simplifies the zone handling to use the trip information passed
> by the TMU driver and not the hardcoded macros. This also helps in adding
> more zone support.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_thermal_common.c |   61 
> +--
>  drivers/thermal/samsung/exynos_thermal_common.h |3 +-
>  drivers/thermal/samsung/exynos_tmu.c|5 ++-
>  3 files changed, 40 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 86d39aa..2873ca3 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -78,17 +78,22 @@ static int exynos_set_mode(struct thermal_zone_device 
> *thermal,
>  static int exynos_get_trip_type(struct thermal_zone_device *thermal, int 
> trip,
>enum thermal_trip_type *type)
>  {
> - switch (GET_ZONE(trip)) {
> - case MONITOR_ZONE:
> - case WARN_ZONE:
> - *type = THERMAL_TRIP_ACTIVE;
> - break;
> - case PANIC_ZONE:
> - *type = THERMAL_TRIP_CRITICAL;
> - break;
> - default:
> + 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;
> +
>   return 0;
>  }
>  
> @@ -97,8 +102,9 @@ 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 < GET_TRIP(MONITOR_ZONE) || trip > GET_TRIP(PANIC_ZONE))
> + if (trip < 0 || trip >= max_trip)
>   return -EINVAL;
>  
>   *temp = th_zone->sensor_conf->trip_data.trip_val[trip];
> @@ -112,10 +118,10 @@ static int exynos_get_trip_temp(struct 
> thermal_zone_device *thermal, int trip,
>  static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
>   unsigned long *temp)
>  {
> - int ret;
> - /* Panic zone */
> - ret = exynos_get_trip_temp(thermal, GET_TRIP(PANIC_ZONE), temp);
> - return ret;
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
> + int max_trip = th_zone->sensor_conf->trip_data.trip_count;
> + /* Get the temp of highest trip*/
> + return exynos_get_trip_temp(thermal, max_trip - 1, temp);
>  }
>  
>  /* Bind callback functions for thermal zone */
> @@ -340,19 +346,22 @@ int exynos_register_thermal(struct thermal_sensor_conf 
> *sensor_conf)
>   return -ENOMEM;
>  
>   th_zone->sensor_conf = sensor_conf;
> - cpumask_set_cpu(0, &mask_val);
> - th_zone->cool_dev[0] = cpufreq_cooling_register(&mask_val);
> - if (IS_ERR(th_zone->cool_dev[0])) {
> - pr_err("Failed to register cpufreq cooling device\n");
> - ret = -EINVAL;
> - goto err_unregister;
> + if (sensor_conf->cooling_data.freq_clip_count > 0) {
> + cpumask_set_cpu(0, &mask_val);
> + th_zone->cool_dev[0] = cpufreq_cooling_register(&mask_val);

Did you mean th_zone->cool_dev[th_zone->cool_dev_size] ?

I think the logic behind the allocation of these cpufreq cooling devices
needs to be revisited. You always assigned to cool_dev[0], but you
always iterate the array until cool_dev_size. Remember that
cool_dev_size now is per th_zone, not global.

> + if (IS_ERR(th_zone->cool_dev[0])) {
> + pr_err("Failed to register cpufreq cooling device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> + th_zone->cool_dev_size++;
>   }
> - th_zone->cool_dev_size++;
>  
> - th_zone->therm_dev = thermal_zone_device_register(sensor_conf->name,
> - EXYNOS_ZONE_COUNT, 0, th_zone, &exynos_dev_ops, NULL, 0,
> - sensor_conf->trip_data.trigger_falling ?
> - 0 : IDLE_INTERVAL);
> + th_zone->therm_dev = thermal_zone_device_register(
> + sensor_conf->name, sensor_conf->trip_data.trip_count,
> + 0, th_zone, &exynos_dev_ops, NULL, 0,
> + sensor_conf->trip_data.trigger_falling ? 0 :
> + IDLE_INTERVAL)

Re: [PATCH V6 15/30] thermal: exynos: Return success even if no cooling data supplied

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch removes the error return in the bind/unbind routine
> as the platform may not register any cpufreq cooling data.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 7064eb7..86d39aa 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -131,7 +131,7 @@ static int exynos_bind(struct thermal_zone_device 
> *thermal,
>   tab_size = data->cooling_data.freq_clip_count;
>  
>   if (tab_ptr == NULL || tab_size == 0)
> - return -EINVAL;
> + return 0;
>  
>   /* find the cooling device registered*/
>   for (i = 0; i < th_zone->cool_dev_size; i++)
> @@ -180,7 +180,7 @@ static int exynos_unbind(struct thermal_zone_device 
> *thermal,
>   tab_size = data->cooling_data.freq_clip_count;
>  
>   if (tab_size == 0)
> - return -EINVAL;
> + return 0;
>  
>   /* find the cooling device registered*/
>   for (i = 0; i < th_zone->cool_dev_size; i++)
> 

I have one question before acking this one: what happens if one
registers a TMU with no freq tab? Say the case where you have three
sensors, just like SOC_ARCH_EXYNOS5440. Would you register
cpufreq_cooling device for all of them? In other way, are you having 3
cpufreq_cooling devices?


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Mark Brown
On Wed, Jun 19, 2013 at 09:32:44PM +0200, Tomasz Figa wrote:
> On Wednesday 19 of June 2013 20:22:11 Mark Brown wrote:

> > No, I didn't - that's most likely it, I didn't really investigate.  I
> > didn't test the watchdog stuff as the clocks didn't get sent to me.

> I always try to keep you on Cc of my patches for s3c64xx, as you are the 
> most active user of this platform (if not the only one other than me) and 
> this was the case for clock patches as well, just checked that.

Yes, I had the clock patches but they depended on something or other I
think.  I did test a previous verion IIRC.  There are other users I'm
aware of (you can probably take a wild guess where from the board)
though they tend not to be terribly active upstream.


signature.asc
Description: Digital signature


Re: [PATCH V6 14/30] thermal: exynos: Modify private_data to appropriate name driver_data

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch renames member private_data to driver_data of the thermal
> zone registration structure as this item stores the driver related
> data and uses it to call the driver related callbacks.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_thermal_common.c |4 ++--
>  drivers/thermal/samsung/exynos_thermal_common.h |2 +-
>  drivers/thermal/samsung/exynos_tmu.c|2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 2af1e3b..7064eb7 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -221,7 +221,7 @@ static int exynos_get_temp(struct thermal_zone_device 
> *thermal,
>   pr_info("Temperature sensor not initialised\n");
>   return -EINVAL;
>   }
> - data = th_zone->sensor_conf->private_data;
> + data = th_zone->sensor_conf->driver_data;
>   *temp = th_zone->sensor_conf->read_temperature(data);
>   /* convert the temperature into millicelsius */
>   *temp = *temp * MCELSIUS;
> @@ -240,7 +240,7 @@ static int exynos_set_emul_temp(struct 
> thermal_zone_device *thermal,
>   pr_info("Temperature sensor not initialised\n");
>   return -EINVAL;
>   }
> - data = th_zone->sensor_conf->private_data;
> + data = th_zone->sensor_conf->driver_data;
>   if (th_zone->sensor_conf->write_emul_temp)
>   ret = th_zone->sensor_conf->write_emul_temp(data, temp);
>   return ret;
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index a845c2d..1e9a326 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -83,7 +83,7 @@ struct thermal_sensor_conf {
>   int (*write_emul_temp)(void *drv_data, unsigned long temp);
>   struct thermal_trip_point_conf trip_data;
>   struct thermal_cooling_conf cooling_data;
> - void *private_data;
> + void *driver_data;
>   void *pzone_data;
>  };
>  
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index a7bba69..40e0cfd 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -504,7 +504,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>   exynos_tmu_control(pdev, true);
>  
>   /* Register the sensor with thermal management interface */
> - (&exynos_sensor_conf)->private_data = data;
> + (&exynos_sensor_conf)->driver_data = data;
>   exynos_sensor_conf.trip_data.trip_count = pdata->trigger_enable[0] +
>   pdata->trigger_enable[1] + pdata->trigger_enable[2]+
>   pdata->trigger_enable[3];
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 13/30] thermal: exynos: Add support for instance based register/unregister

2013-06-19 Thread Eduardo Valentin
Hi,

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This code modifies the thermal driver to have multiple thermal zone
> support by replacing the global thermal zone variable with device data
> member of thermal_zone_device.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_thermal_common.c |   36 ++
>  drivers/thermal/samsung/exynos_thermal_common.h |9 +++--
>  drivers/thermal/samsung/exynos_tmu.c|   15 +
>  3 files changed, 36 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index dd49c9f..2af1e3b 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -36,12 +36,11 @@ struct exynos_thermal_zone {
>   bool bind;
>  };
>  
> -static struct exynos_thermal_zone *th_zone;
> -
>  /* 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;
> @@ -51,25 +50,26 @@ static int exynos_get_mode(struct thermal_zone_device 
> *thermal,
>  static int exynos_set_mode(struct thermal_zone_device *thermal,
>   enum thermal_device_mode mode)
>  {
> - if (!th_zone->therm_dev) {
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
> + if (!th_zone) {
>   pr_notice("thermal zone not registered\n");
>   return 0;
>   }
>  
> - mutex_lock(&th_zone->therm_dev->lock);
> + mutex_lock(&thermal->lock);
>  
>   if (mode == THERMAL_DEVICE_ENABLED &&
>   !th_zone->sensor_conf->trip_data.trigger_falling)
> - th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
> + thermal->polling_delay = IDLE_INTERVAL;
>   else
> - th_zone->therm_dev->polling_delay = 0;
> + thermal->polling_delay = 0;
>  
> - mutex_unlock(&th_zone->therm_dev->lock);
> + mutex_unlock(&thermal->lock);
>  
>   th_zone->mode = mode;
> - thermal_zone_device_update(th_zone->therm_dev);
> + thermal_zone_device_update(thermal);
>   pr_info("thermal polling set for duration=%d msec\n",
> - th_zone->therm_dev->polling_delay);
> + thermal->polling_delay);
>   return 0;
>  }
>  
> @@ -96,6 +96,8 @@ static int exynos_get_trip_type(struct thermal_zone_device 
> *thermal, int trip,
>  static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int 
> trip,
>   unsigned long *temp)
>  {
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
> +
>   if (trip < GET_TRIP(MONITOR_ZONE) || trip > GET_TRIP(PANIC_ZONE))
>   return -EINVAL;
>  
> @@ -122,6 +124,7 @@ static int exynos_bind(struct thermal_zone_device 
> *thermal,
>  {
>   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;
>  
>   tab_ptr = (struct freq_clip_table *)data->cooling_data.freq_data;
> @@ -168,6 +171,7 @@ static int exynos_unbind(struct thermal_zone_device 
> *thermal,
>   struct thermal_cooling_device *cdev)
>  {
>   int ret = 0, i, tab_size;
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>   struct thermal_sensor_conf *data = th_zone->sensor_conf;
>  
>   if (th_zone->bind == false)
> @@ -210,6 +214,7 @@ static int exynos_unbind(struct thermal_zone_device 
> *thermal,
>  static int exynos_get_temp(struct thermal_zone_device *thermal,
>   unsigned long *temp)
>  {
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>   void *data;
>  
>   if (!th_zone->sensor_conf) {
> @@ -229,6 +234,7 @@ static int exynos_set_emul_temp(struct 
> thermal_zone_device *thermal,
>  {
>   void *data;
>   int ret = -EINVAL;
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>  
>   if (!th_zone->sensor_conf) {
>   pr_info("Temperature sensor not initialised\n");
> @@ -276,11 +282,12 @@ static struct thermal_zone_device_ops const 
> exynos_dev_ops = {
>   * This function may be called from interrupt based temperature sensor
>   * when threshold is changed.
>   */
> -void exynos_report_trigger(void)
> +void exynos_report_trigger(struct thermal_sensor_conf *conf)
>  {
>   unsigned int i;
>   char data[10];
>   char *envp[] = { data, NULL };
> + struct exynos_thermal_zone *th_zone = conf->pzone_data;
>  
>   if (!th_zone || !th_zone->therm_dev)
>   return;

Re: [PATCH V6 12/30] thermal: exynos: Fix to clear only the generated interrupts

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch uses the TMU status register to know the generated interrupts
> and only clear them in the interrupt handler.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---

Acked-by: Eduardo Valentin 

>  drivers/thermal/samsung/exynos_tmu.c  |   11 +--
>  drivers/thermal/samsung/exynos_tmu_data.c |2 ++
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 33f494e..f6f63ca 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -351,17 +351,16 @@ static void exynos_tmu_work(struct work_struct *work)
>   struct exynos_tmu_data, irq_work);
>   struct exynos_tmu_platform_data *pdata = data->pdata;
>   const struct exynos_tmu_registers *reg = pdata->registers;
> + unsigned int val_irq;
>  
>   exynos_report_trigger();
>   mutex_lock(&data->lock);
>   clk_enable(data->clk);
>  
> - if (data->soc == SOC_ARCH_EXYNOS)
> - writel((reg->inten_rise_mask << reg->inten_rise_shift) |
> - (reg->inten_fall_mask << reg->inten_fall_shift),
> - data->base + reg->tmu_intclear);
> - else
> - writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
> + /* TODO: take action based on particular interrupt */
> + val_irq = readl(data->base + reg->tmu_intstat);
> + /* clear the interrupts */
> + writel(val_irq, data->base + reg->tmu_intclear);
>  
>   clk_disable(data->clk);
>   mutex_unlock(&data->lock);
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index e7cb1cc..7fcf183 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -45,6 +45,7 @@ static const struct exynos_tmu_registers 
> exynos4210_tmu_registers = {
>   .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
>   .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
>   .inten_rise3_shift = EXYNOS_TMU_INTEN_RISE3_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>  };
>  struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
> @@ -112,6 +113,7 @@ static const struct exynos_tmu_registers 
> exynos5250_tmu_registers = {
>   .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
>   .inten_rise3_shift = EXYNOS_TMU_INTEN_RISE3_SHIFT,
>   .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>   .emul_con = EXYNOS_EMUL_CON,
>   .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 11/30] thermal: exynos: Support thermal tripping

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU, and thermal
> tripping by hardware logic. Thermal tripping means that PMU cuts off the
> whole power of SoC by controlling external voltage regulator.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Jonghwan Choi 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_tmu.c  |   45 +---
>  drivers/thermal/samsung/exynos_tmu_data.c |2 +
>  drivers/thermal/samsung/exynos_tmu_data.h |2 +
>  3 files changed, 44 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 6fd776f..33f494e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -117,7 +117,7 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>   struct exynos_tmu_platform_data *pdata = data->pdata;
>   const struct exynos_tmu_registers *reg = pdata->registers;
> - unsigned int status, trim_info;
> + unsigned int status, trim_info = 0, con;
>   unsigned int rising_threshold = 0, falling_threshold = 0;
>   int ret = 0, threshold_code, i, trigger_levs = 0;
>  
> @@ -144,10 +144,26 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   (data->temp_error2 != 0))
>   data->temp_error1 = pdata->efuse_value;
>  
> - /* Count trigger levels to be enabled */
> - for (i = 0; i < MAX_THRESHOLD_LEVS; i++)
> - if (pdata->trigger_levels[i])
> + if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
> + dev_err(&pdev->dev, "Invalid max trigger level\n");
> + goto out;
> + }
> +
> + for (i = 0; i < pdata->max_trigger_level; i++) {
> + if (!pdata->trigger_levels[i])
> + continue;
> +
> + if ((pdata->trigger_type[i] == HW_TRIP) &&
> + (!pdata->trigger_levels[pdata->max_trigger_level - 1])) {
> + dev_err(&pdev->dev, "Invalid hw trigger level\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* Count trigger levels except the HW trip*/
> + if (!(pdata->trigger_type[i] == HW_TRIP))
>   trigger_levs++;
> + }
>  
>   if (data->soc == SOC_ARCH_EXYNOS4210) {
>   /* Write temperature code for threshold */
> @@ -165,7 +181,8 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
>   } else if (data->soc == SOC_ARCH_EXYNOS) {
>   /* 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) {
> @@ -191,6 +208,24 @@ 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 last threshold limit is also present */
> + i = pdata->max_trigger_level - 1;
> + if (pdata->trigger_levels[i] &&
> + (pdata->trigger_type[i] == HW_TRIP)) {
> + threshold_code = temp_to_code(data,
> + pdata->trigger_levels[i]);
> + if (threshold_code < 0) {
> + ret = threshold_code;
> + goto out;
> + }
> + rising_threshold |= threshold_code << 8 * i;
> + writel(rising_threshold,
> + data->base + reg->threshold_th0);
> + con = readl(data->base + reg->tmu_ctrl);
> + con |= (1 << reg->therm_trip_en_shift);
> + writel(con, data->base + reg->tmu_ctrl);
> + }
>   }
>  out:
>   clk_disable(data->clk);
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index 589a519..e7cb1cc 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -123,6 +123,7 @@ struct exynos_tmu_platform_data const 
> exynos5250_default_tmu_data = {
>   .trigger_levels[0] = 85,
>   .trigger_levels[1] = 103,
>   .trigger_levels[2] = 110,
> + .trigger_levels

Re: [PATCH V6 10/30] thermal: exynos: Move register definitions from driver to data file

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch migrates the TMU register definition/bitfields to data file. This
> is needed to support SoC's which use the same TMU controller but register
> validity, offsets or bitfield may slightly vary across SOC's.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/exynos_tmu.c  |  172 +---
>  drivers/thermal/samsung/exynos_tmu.h  |  133 ++
>  drivers/thermal/samsung/exynos_tmu_data.c |   59 ++
>  drivers/thermal/samsung/exynos_tmu_data.h |   68 +++
>  4 files changed, 315 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 401ec98..6fd776f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -32,76 +32,6 @@
>  #include "exynos_tmu.h"
>  #include "exynos_tmu_data.h"
>  
> -/* Exynos generic registers */
> -#define EXYNOS_TMU_REG_TRIMINFO  0x0
> -#define EXYNOS_TMU_REG_CONTROL   0x20
> -#define EXYNOS_TMU_REG_STATUS0x28
> -#define EXYNOS_TMU_REG_CURRENT_TEMP  0x40
> -#define EXYNOS_TMU_REG_INTEN 0x70
> -#define EXYNOS_TMU_REG_INTSTAT   0x74
> -#define EXYNOS_TMU_REG_INTCLEAR  0x78
> -
> -#define EXYNOS_TMU_TRIM_TEMP_MASK0xff
> -#define EXYNOS_TMU_GAIN_SHIFT8
> -#define EXYNOS_TMU_GAIN_MASK 0xf
> -#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> -#define EXYNOS_TMU_REF_VOLTAGE_MASK  0x1f
> -#define EXYNOS_TMU_BUF_SLOPE_SEL_MASK0xf
> -#define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT   8
> -#define EXYNOS_TMU_CORE_EN_SHIFT 0
> -
> -/* Exynos4210 specific registers */
> -#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44
> -#define EXYNOS4210_TMU_REG_TRIG_LEVEL0   0x50
> -#define EXYNOS4210_TMU_REG_TRIG_LEVEL1   0x54
> -#define EXYNOS4210_TMU_REG_TRIG_LEVEL2   0x58
> -#define EXYNOS4210_TMU_REG_TRIG_LEVEL3   0x5C
> -#define EXYNOS4210_TMU_REG_PAST_TEMP00x60
> -#define EXYNOS4210_TMU_REG_PAST_TEMP10x64
> -#define EXYNOS4210_TMU_REG_PAST_TEMP20x68
> -#define EXYNOS4210_TMU_REG_PAST_TEMP30x6C
> -
> -#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK  0x1
> -#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK  0x10
> -#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK  0x100
> -#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK  0x1000
> -#define EXYNOS4210_TMU_TRIG_LEVEL_MASK   0x
> -#define EXYNOS4210_TMU_INTCLEAR_VAL  0x
> -
> -/* Exynos5250 and Exynos4412 specific registers */
> -#define EXYNOS_TMU_TRIMINFO_CON  0x14
> -#define EXYNOS_THD_TEMP_RISE 0x50
> -#define EXYNOS_THD_TEMP_FALL 0x54
> -#define EXYNOS_EMUL_CON  0x80
> -
> -#define EXYNOS_TRIMINFO_RELOAD   0x1
> -#define EXYNOS_TRIMINFO_SHIFT0x0
> -#define EXYNOS_TMU_RISE_INT_MASK 0x111
> -#define EXYNOS_TMU_RISE_INT_SHIFT0
> -#define EXYNOS_TMU_FALL_INT_MASK 0x111
> -#define EXYNOS_TMU_FALL_INT_SHIFT12
> -#define EXYNOS_TMU_CLEAR_RISE_INT0x111
> -#define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12)
> -#define EXYNOS_TMU_TRIP_MODE_SHIFT   13
> -#define EXYNOS_TMU_TRIP_MODE_MASK0x7
> -
> -#define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
> -#define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
> -#define EXYNOS_TMU_INTEN_RISE2_SHIFT 8
> -#define EXYNOS_TMU_INTEN_RISE3_SHIFT 12
> -#define EXYNOS_TMU_INTEN_FALL0_SHIFT 16
> -#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20
> -#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24
> -
> -#ifdef CONFIG_THERMAL_EMULATION
> -#define EXYNOS_EMUL_TIME 0x57F0
> -#define EXYNOS_EMUL_TIME_MASK0x
> -#define EXYNOS_EMUL_TIME_SHIFT   16
> -#define EXYNOS_EMUL_DATA_SHIFT   8
> -#define EXYNOS_EMUL_DATA_MASK0xFF
> -#define EXYNOS_EMUL_ENABLE   0x1
> -#endif /* CONFIG_THERMAL_EMULATION */
> -
>  struct exynos_tmu_data {
>   struct exynos_tmu_platform_data *pdata;
>   struct resource *mem;
> @@ -186,6 +116,7 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>  {
>   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>   struct exynos_tmu_platform_data *pdata = data->pdata;
> + const struct exynos_tmu_registers *reg = pdata->registers;
>   unsigned int status, trim_info;
>   unsigned int rising_threshold = 0, falling_threshold = 0;
>   int ret = 0, threshold_code, i, trigger_levs = 0;
> @@ -193,20 +124,20 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   mutex_lock(&data->lock);
>   clk_enable(data->clk);
>  
> - status = readb(data->base + EXYNOS_TMU_REG_STATUS);
> + status = readb(data->base + reg->tmu_status);
>   if (!status) {
>   ret = -EBUSY;
>   goto out;
>   }
>  
> - if (data->soc == SOC_ARCH_EXYNOS) {
> - __raw_writel(EXYNOS_TRIMINFO_

Re: [PATCH V6 09/30] thermal: exynos: Add extra entries in the tmu platform data

2013-06-19 Thread Eduardo Valentin
On 19-06-2013 16:19, Eduardo Valentin wrote:
> On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
>> This patch adds entries min_efuse_value, max_efuse_value, 
>> default_temp_offset,
>> trigger_type, cal_type, trim_first_point, trim_second_point, 
>> max_trigger_level
>> trigger_enable in the TMU platform data structure. Also the driver is 
>> modified
>> to use the data passed by these new platform memebers instead of the constant
>> macros. All these changes helps in separating the SOC specific data part from
>> the TMU driver.
>>
>> Acked-by: Kukjin Kim 
>> Acked-by: Jonghwa Lee 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  drivers/thermal/samsung/exynos_thermal_common.h |7 +++
>>  drivers/thermal/samsung/exynos_tmu.c|   43 ++--
>>  drivers/thermal/samsung/exynos_tmu.h|   49 
>> ++
>>  drivers/thermal/samsung/exynos_tmu_data.c   |   35 
>>  4 files changed, 86 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
>> b/drivers/thermal/samsung/exynos_thermal_common.h
>> index 068f56c..fd789a5 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> @@ -44,6 +44,13 @@
>>  
>>  #define EXYNOS_ZONE_COUNT   3
>>  
>> +enum trigger_type {
>> +THROTTLE_ACTIVE = 1,
>> +THROTTLE_PASSIVE,
>> +SW_TRIP,
>> +HW_TRIP,
>> +};
>> +
>>  /**
>>   * struct freq_clip_table
>>   * @freq_clip_max: maximum frequency allowed for this cooling state.
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index fa33a48..401ec98 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -49,7 +49,6 @@
>>  #define EXYNOS_TMU_BUF_SLOPE_SEL_MASK   0xf
>>  #define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT  8
>>  #define EXYNOS_TMU_CORE_EN_SHIFT0
>> -#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET  50
>>  
>>  /* Exynos4210 specific registers */
>>  #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP   0x44
>> @@ -94,9 +93,6 @@
>>  #define EXYNOS_TMU_INTEN_FALL1_SHIFT20
>>  #define EXYNOS_TMU_INTEN_FALL2_SHIFT24
>>  
>> -#define EFUSE_MIN_VALUE 40
>> -#define EFUSE_MAX_VALUE 100
>> -
>>  #ifdef CONFIG_THERMAL_EMULATION
>>  #define EXYNOS_EMUL_TIME0x57F0
>>  #define EXYNOS_EMUL_TIME_MASK   0x
>> @@ -136,15 +132,16 @@ static int temp_to_code(struct exynos_tmu_data *data, 
>> u8 temp)
>>  
>>  switch (pdata->cal_type) {
>>  case TYPE_TWO_POINT_TRIMMING:
>> -temp_code = (temp - 25) *
>> -(data->temp_error2 - data->temp_error1) /
>> -(85 - 25) + data->temp_error1;
>> +temp_code = (temp - pdata->first_point_trim) *
>> +(data->temp_error2 - data->temp_error1) /
>> +(pdata->second_point_trim - pdata->first_point_trim) +
>> +data->temp_error1;
>>  break;
>>  case TYPE_ONE_POINT_TRIMMING:
>> -temp_code = temp + data->temp_error1 - 25;
>> +temp_code = temp + data->temp_error1 - pdata->first_point_trim;
>>  break;
>>  default:
>> -temp_code = temp + EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
>> +temp_code = temp + pdata->default_temp_offset;
>>  break;
>>  }
>>  out:
>> @@ -169,14 +166,16 @@ static int code_to_temp(struct exynos_tmu_data *data, 
>> u8 temp_code)
>>  
>>  switch (pdata->cal_type) {
>>  case TYPE_TWO_POINT_TRIMMING:
>> -temp = (temp_code - data->temp_error1) * (85 - 25) /
>> -(data->temp_error2 - data->temp_error1) + 25;
>> +temp = (temp_code - data->temp_error1) *
>> +(pdata->second_point_trim - pdata->first_point_trim) /
>> +(data->temp_error2 - data->temp_error1) +
>> +pdata->first_point_trim;
>>  break;
>>  case TYPE_ONE_POINT_TRIMMING:
>> -temp = temp_code - data->temp_error1 + 25;
>> +temp = temp_code - data->temp_error1 + pdata->first_point_trim;
>>  break;
>>  default:
>> -temp = temp_code - EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
>> +temp = temp_code - pdata->default_temp_offset;
>>  break;
>>  }
>>  out:
>> @@ -209,8 +208,8 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>>  data->temp_error1 = trim_info & EXYNOS_TMU_TRIM_TEMP_MASK;
>>  data->temp_error2 = ((trim_info >> 8) & EXYNOS_TMU_TRIM_TEMP_MASK);
>>  
>> -if ((EFUSE_MIN_VALUE > data->temp_error1) ||
>> -(data->temp_error1 > EFUSE_MAX_VALUE) ||
>> +if ((pdata->min_efuse_value > data->temp_error1) ||
>> +(data->temp_error1 > pdata->max_efuse_value) ||
>>  (data->temp_error2 != 0))
>>  data->temp_error1 = pdata->efuse_value;
>>  
>> @@ -300,10 

Re: [PATCH V6 09/30] thermal: exynos: Add extra entries in the tmu platform data

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds entries min_efuse_value, max_efuse_value, default_temp_offset,
> trigger_type, cal_type, trim_first_point, trim_second_point, max_trigger_level
> trigger_enable in the TMU platform data structure. Also the driver is modified
> to use the data passed by these new platform memebers instead of the constant
> macros. All these changes helps in separating the SOC specific data part from
> the TMU driver.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_thermal_common.h |7 +++
>  drivers/thermal/samsung/exynos_tmu.c|   43 ++--
>  drivers/thermal/samsung/exynos_tmu.h|   49 ++
>  drivers/thermal/samsung/exynos_tmu_data.c   |   35 
>  4 files changed, 86 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 068f56c..fd789a5 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -44,6 +44,13 @@
>  
>  #define EXYNOS_ZONE_COUNT3
>  
> +enum trigger_type {
> + THROTTLE_ACTIVE = 1,
> + THROTTLE_PASSIVE,
> + SW_TRIP,
> + HW_TRIP,
> +};
> +
>  /**
>   * struct freq_clip_table
>   * @freq_clip_max: maximum frequency allowed for this cooling state.
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index fa33a48..401ec98 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -49,7 +49,6 @@
>  #define EXYNOS_TMU_BUF_SLOPE_SEL_MASK0xf
>  #define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT   8
>  #define EXYNOS_TMU_CORE_EN_SHIFT 0
> -#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET   50
>  
>  /* Exynos4210 specific registers */
>  #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44
> @@ -94,9 +93,6 @@
>  #define EXYNOS_TMU_INTEN_FALL1_SHIFT 20
>  #define EXYNOS_TMU_INTEN_FALL2_SHIFT 24
>  
> -#define EFUSE_MIN_VALUE 40
> -#define EFUSE_MAX_VALUE 100
> -
>  #ifdef CONFIG_THERMAL_EMULATION
>  #define EXYNOS_EMUL_TIME 0x57F0
>  #define EXYNOS_EMUL_TIME_MASK0x
> @@ -136,15 +132,16 @@ static int temp_to_code(struct exynos_tmu_data *data, 
> u8 temp)
>  
>   switch (pdata->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - 25) *
> - (data->temp_error2 - data->temp_error1) /
> - (85 - 25) + data->temp_error1;
> + temp_code = (temp - pdata->first_point_trim) *
> + (data->temp_error2 - data->temp_error1) /
> + (pdata->second_point_trim - pdata->first_point_trim) +
> + data->temp_error1;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 - 25;
> + temp_code = temp + data->temp_error1 - pdata->first_point_trim;
>   break;
>   default:
> - temp_code = temp + EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
> + temp_code = temp + pdata->default_temp_offset;
>   break;
>   }
>  out:
> @@ -169,14 +166,16 @@ static int code_to_temp(struct exynos_tmu_data *data, 
> u8 temp_code)
>  
>   switch (pdata->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) * (85 - 25) /
> - (data->temp_error2 - data->temp_error1) + 25;
> + temp = (temp_code - data->temp_error1) *
> + (pdata->second_point_trim - pdata->first_point_trim) /
> + (data->temp_error2 - data->temp_error1) +
> + pdata->first_point_trim;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 + 25;
> + temp = temp_code - data->temp_error1 + pdata->first_point_trim;
>   break;
>   default:
> - temp = temp_code - EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET;
> + temp = temp_code - pdata->default_temp_offset;
>   break;
>   }
>  out:
> @@ -209,8 +208,8 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>   data->temp_error1 = trim_info & EXYNOS_TMU_TRIM_TEMP_MASK;
>   data->temp_error2 = ((trim_info >> 8) & EXYNOS_TMU_TRIM_TEMP_MASK);
>  
> - if ((EFUSE_MIN_VALUE > data->temp_error1) ||
> - (data->temp_error1 > EFUSE_MAX_VALUE) ||
> + if ((pdata->min_efuse_value > data->temp_error1) ||
> + (data->temp_error1 > pdata->max_efuse_value) ||
>   (data->temp_error2 != 0))
>   data->temp_error1 = pdata->efuse_value;
>  
> @@ -300,10 +299,10 @@ static void exynos_tmu_control(struct platform_device 
> *pdev, bool on)
>   if (on) {
>   con |= (1 << EXYN

Re: [PATCH V2] thermal: exynos: Support for TMU regulator defined at device tree

2013-06-19 Thread Eduardo Valentin
On 02-05-2013 06:18, Amit Daniel Kachhap wrote:
> TMU probe function now checks for a device tree defined regulator.
> For compatibility reasons it is allowed to probe driver even without
> this regulator defined.
> 
> Signed-off-by: Luk asz Majewski 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Amit Daniel Kachhap 

I assume this one got superseeded by the same patch on your 30 patch
series, right?
https://patchwork.kernel.org/patch/2731031/


> ---
> 
> Changes in V2:
> * Added log message in regulator_get failure as suggested by Sylwester.
> * Used IS_ERR for checking regulator pointer as suggested by Sylwester.
> 
> This patch is repost of the patch posted by Lukasz Majewski
> (https://patchwork.kernel.org/patch/2488211/). I have rebased this
> patch on top of my TMU re-structured patch series
> (http://lwn.net/Articles/548634/). Although I thought of handling
> regulator as one type of feature (newly added) but could not do
> so as regulator is a board/platform property and not SOC property so
> leaving the device tree to define and handle it.
> 
>  .../devicetree/bindings/thermal/exynos-thermal.txt |4 
>  drivers/thermal/samsung/exynos_tmu.c   |   19 +++
>  2 files changed, 23 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 970eeba..ff62f7a 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -14,6 +14,9 @@
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> +- vtmu-supply: This entry is optional and provides the regulator node 
> supplying
> + voltage to TMU. If needed this entry can be placed inside
> + board/platform specific dts file.
>  
>  Example 1):
>  
> @@ -25,6 +28,7 @@ Example 1):
>   clocks = <&clock 383>;
>   clock-names = "tmu_apbif";
>   status = "disabled";
> + vtmu-supply = <&tmu_regulator_node>;
>   };
>  
>  Example 2):
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 72446c9..b7c609a 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "exynos_thermal_common.h"
> @@ -52,6 +53,7 @@
>   * @clk: pointer to the clock structure.
>   * @temp_error1: fused value of the first point trim.
>   * @temp_error2: fused value of the second point trim.
> + * @regulator: pointer to the TMU regulator structure.
>   * @reg_conf: pointer to structure to register with core thermal.
>   */
>  struct exynos_tmu_data {
> @@ -65,6 +67,7 @@ struct exynos_tmu_data {
>   struct mutex lock;
>   struct clk *clk;
>   u8 temp_error1, temp_error2;
> + struct regulator *regulator;
>   struct thermal_sensor_conf *reg_conf;
>  };
>  
> @@ -501,10 +504,23 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>   struct exynos_tmu_platform_data *pdata = data->pdata;
>   struct resource res;
> + int ret;
>  
>   if (!data)
>   return -ENODEV;
>  
> + /* Try enabling the regulator if found */
> + data->regulator = devm_regulator_get(&pdev->dev, "vtmu");
> + if (!IS_ERR(data->regulator)) {
> + ret = regulator_enable(data->regulator);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to enable vtmu\n");
> + return ret;
> + }
> + } else {
> + dev_info(&pdev->dev, "Regulator node (vtmu) not found\n");
> + }
> +
>   data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
>   if (data->id < 0)
>   data->id = 0;
> @@ -669,6 +685,9 @@ static int exynos_tmu_remove(struct platform_device *pdev)
>  
>   clk_unprepare(data->clk);
>  
> + if (!IS_ERR(data->regulator))
> + regulator_disable(data->regulator);
> +
>   platform_set_drvdata(pdev, NULL);
>  
>   return 0;
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 08/30] thermal: exynos: Add missing definations and code cleanup

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch adds some extra register bitfield definations and cleans
> up the code to prepare for moving register macros and definations inside
> the TMU data section.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_tmu.c |   62 
> +-
>  1 files changed, 46 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 5df04a1..fa33a48 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -43,9 +43,12 @@
>  
>  #define EXYNOS_TMU_TRIM_TEMP_MASK0xff
>  #define EXYNOS_TMU_GAIN_SHIFT8
> +#define EXYNOS_TMU_GAIN_MASK 0xf
>  #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> -#define EXYNOS_TMU_CORE_ON   3
> -#define EXYNOS_TMU_CORE_OFF  2
> +#define EXYNOS_TMU_REF_VOLTAGE_MASK  0x1f
> +#define EXYNOS_TMU_BUF_SLOPE_SEL_MASK0xf
> +#define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT   8
> +#define EXYNOS_TMU_CORE_EN_SHIFT 0
>  #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET   50
>  
>  /* Exynos4210 specific registers */
> @@ -63,6 +66,7 @@
>  #define EXYNOS4210_TMU_TRIG_LEVEL1_MASK  0x10
>  #define EXYNOS4210_TMU_TRIG_LEVEL2_MASK  0x100
>  #define EXYNOS4210_TMU_TRIG_LEVEL3_MASK  0x1000
> +#define EXYNOS4210_TMU_TRIG_LEVEL_MASK   0x
>  #define EXYNOS4210_TMU_INTCLEAR_VAL  0x
>  
>  /* Exynos5250 and Exynos4412 specific registers */
> @@ -72,17 +76,30 @@
>  #define EXYNOS_EMUL_CON  0x80
>  
>  #define EXYNOS_TRIMINFO_RELOAD   0x1
> +#define EXYNOS_TRIMINFO_SHIFT0x0
> +#define EXYNOS_TMU_RISE_INT_MASK 0x111
> +#define EXYNOS_TMU_RISE_INT_SHIFT0
> +#define EXYNOS_TMU_FALL_INT_MASK 0x111
> +#define EXYNOS_TMU_FALL_INT_SHIFT12
>  #define EXYNOS_TMU_CLEAR_RISE_INT0x111
>  #define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12)
> -#define EXYNOS_MUX_ADDR_VALUE6
> -#define EXYNOS_MUX_ADDR_SHIFT20
>  #define EXYNOS_TMU_TRIP_MODE_SHIFT   13
> +#define EXYNOS_TMU_TRIP_MODE_MASK0x7
> +
> +#define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
> +#define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
> +#define EXYNOS_TMU_INTEN_RISE2_SHIFT 8
> +#define EXYNOS_TMU_INTEN_RISE3_SHIFT 12
> +#define EXYNOS_TMU_INTEN_FALL0_SHIFT 16
> +#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20
> +#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24
>  
>  #define EFUSE_MIN_VALUE 40
>  #define EFUSE_MAX_VALUE 100
>  
>  #ifdef CONFIG_THERMAL_EMULATION
>  #define EXYNOS_EMUL_TIME 0x57F0
> +#define EXYNOS_EMUL_TIME_MASK0x
>  #define EXYNOS_EMUL_TIME_SHIFT   16
>  #define EXYNOS_EMUL_DATA_SHIFT   8
>  #define EXYNOS_EMUL_DATA_MASK0xFF
> @@ -261,24 +278,37 @@ static void exynos_tmu_control(struct platform_device 
> *pdev, bool on)
>   mutex_lock(&data->lock);
>   clk_enable(data->clk);
>  
> - con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
> - pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
> + con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
>  
> - if (data->soc == SOC_ARCH_EXYNOS) {
> - con |= pdata->noise_cancel_mode << EXYNOS_TMU_TRIP_MODE_SHIFT;
> - con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> + if (pdata->reference_voltage) {
> + con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK <<
> + EXYNOS_TMU_REF_VOLTAGE_SHIFT);
> + con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT;
> + }
> +
> + if (pdata->gain) {
> + con &= ~(EXYNOS_TMU_GAIN_MASK << EXYNOS_TMU_GAIN_SHIFT);
> + con |= (pdata->gain << EXYNOS_TMU_GAIN_SHIFT);
> + }
> +
> + if (pdata->noise_cancel_mode) {
> + con &= ~(EXYNOS_TMU_TRIP_MODE_MASK <<
> + EXYNOS_TMU_TRIP_MODE_SHIFT);
> + con |= (pdata->noise_cancel_mode << EXYNOS_TMU_TRIP_MODE_SHIFT);
>   }
>  
>   if (on) {
> - con |= EXYNOS_TMU_CORE_ON;



Before, in order to turn core on you had:
con = con | 3;

now you do:
con = con | (1 << 0);

To me, before you would set bit 1 and 0, now you set bit 0.


> - interrupt_en = pdata->trigger_level3_en << 12 |
> - pdata->trigger_level2_en << 8 |
> - pdata->trigger_level1_en << 4 |
> - pdata->trigger_level0_en;
> + con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> + interrupt_en =
> + pdata->trigger_level3_en << EXYNOS_TMU_INTEN_RISE3_SHIFT |
> + pdata->trigger_level2_en << EXYNOS_TMU_INTEN_RISE2_SHIFT |
> + pdata->trigger_level1_en << EXYNOS_TMU_INTEN_RISE1_SHIFT |
> + pdata->trigger_level0_en << EXYNOS_TMU_INTEN_RISE0_SHIFT;
>   if (pdata->threshold_falling)
> -   

Re: [PATCH V6 07/30] thermal: exynos: Bifurcate exynos tmu driver and configuration data

2013-06-19 Thread Eduardo Valentin
On 19-06-2013 15:35, Eduardo Valentin wrote:
> Rui,
> 
> On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
>> This code splits the exynos tmu driver code into SOC specific data parts.
>> This will simplify adding new SOC specific data to the same TMU controller.
>>
>> Acked-by: Kukjin Kim 
>> Acked-by: Jonghwa Lee 
>> Signed-off-by: Amit Daniel Kachhap 
> 
> This patch looks good to me, you may want to add my:
> 
> Acked-by: Eduardo Valentin 

Yet another minor before adding my ack, sorry this one almost fell into
the cracks (see below):

> 
>> ---
>>  drivers/thermal/samsung/Kconfig   |3 +-
>>  drivers/thermal/samsung/Makefile  |1 +
>>  drivers/thermal/samsung/exynos_tmu.c  |   67 ++---
>>  drivers/thermal/samsung/exynos_tmu_data.c |   78 
>> +
>>  drivers/thermal/samsung/exynos_tmu_data.h |   40 +++
>>  5 files changed, 125 insertions(+), 64 deletions(-)
>>  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
>>  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.h
>>
>> diff --git a/drivers/thermal/samsung/Kconfig 
>> b/drivers/thermal/samsung/Kconfig
>> index f8100b1..b653f15 100644
>> --- a/drivers/thermal/samsung/Kconfig
>> +++ b/drivers/thermal/samsung/Kconfig
>> @@ -5,7 +5,8 @@ config EXYNOS_THERMAL
>>If you say yes here you get support for the TMU (Thermal Management
>>Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
>>the TMU, reports temperature and handles cooling action if defined.
>> -  This driver uses the exynos core thermal API's.
>> +  This driver uses the exynos core thermal API's and TMU configuration
>> +  data from the supported soc's.
>>  
>>  config EXYNOS_THERMAL_CORE
>>  bool "Core thermal framework support for EXYNOS SOC's"
>> diff --git a/drivers/thermal/samsung/Makefile 
>> b/drivers/thermal/samsung/Makefile
>> index 22528d6..c09d830 100644
>> --- a/drivers/thermal/samsung/Makefile
>> +++ b/drivers/thermal/samsung/Makefile
>> @@ -3,4 +3,5 @@
>>  #
>>  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 6aa2fd2..5df04a1 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -30,6 +30,7 @@
>>  
>>  #include "exynos_thermal_common.h"
>>  #include "exynos_tmu.h"
>> +#include "exynos_tmu_data.h"
>>  
>>  /* Exynos generic registers */
>>  #define EXYNOS_TMU_REG_TRIMINFO 0x0
>> @@ -381,66 +382,6 @@ static struct thermal_sensor_conf exynos_sensor_conf = {
>>  .write_emul_temp= exynos_tmu_set_emulation,
>>  };
>>  
>> -#if defined(CONFIG_CPU_EXYNOS4210)
>> -static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
>> -.threshold = 80,
>> -.trigger_levels[0] = 5,
>> -.trigger_levels[1] = 20,
>> -.trigger_levels[2] = 30,
>> -.trigger_level0_en = 1,
>> -.trigger_level1_en = 1,
>> -.trigger_level2_en = 1,
>> -.trigger_level3_en = 0,
>> -.gain = 15,
>> -.reference_voltage = 7,
>> -.cal_type = TYPE_ONE_POINT_TRIMMING,
>> -.freq_tab[0] = {
>> -.freq_clip_max = 800 * 1000,
>> -.temp_level = 85,
>> -},
>> -.freq_tab[1] = {
>> -.freq_clip_max = 200 * 1000,
>> -.temp_level = 100,
>> -},
>> -.freq_tab_count = 2,
>> -.type = SOC_ARCH_EXYNOS4210,
>> -};
>> -#define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
>> -#else
>> -#define EXYNOS4210_TMU_DRV_DATA (NULL)
>> -#endif
>> -
>> -#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
>> -static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
>> -.threshold_falling = 10,
>> -.trigger_levels[0] = 85,
>> -.trigger_levels[1] = 103,
>> -.trigger_levels[2] = 110,
>> -.trigger_level0_en = 1,
>> -.trigger_level1_en = 1,
>> -.trigger_level2_en = 1,
>> -.trigger_level3_en = 0,
>> -.gain = 8,
>> -.reference_voltage = 16,
>> -.noise_cancel_mode = 4,
>> -.cal_type = TYPE_ONE_POINT_TRIMMING,
>> -.efuse_value = 55,
>> -.freq_tab[0] = {
>> -.freq_clip_max = 800 * 1000,
>> -.temp_level = 85,
>> -},
>> -.freq_tab[1] = {
>> -.freq_clip_max = 200 * 1000,
>> -.temp_level = 103,
>> -},
>> -.freq_tab_count = 2,
>> -.type = SOC_ARCH_EXYNOS,
>> -};
>> -#define EXYNOS_TMU_DRV_DATA (&exynos_default_tmu_data)
>> -#else
>> -#define EXYNOS_TMU_DRV_DATA (NULL)
>> -#endif
>> -
>>  #ifdef CONFIG_OF
>>  static const struct of_device_id exynos_tmu_match[] = {
>>  {
>> @@ -449,11 +390,11 @@ static const struct o

Re: [PATCH V6 07/30] thermal: exynos: Bifurcate exynos tmu driver and configuration data

2013-06-19 Thread Eduardo Valentin
Rui,

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This code splits the exynos tmu driver code into SOC specific data parts.
> This will simplify adding new SOC specific data to the same TMU controller.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

This patch looks good to me, you may want to add my:

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/Kconfig   |3 +-
>  drivers/thermal/samsung/Makefile  |1 +
>  drivers/thermal/samsung/exynos_tmu.c  |   67 ++---
>  drivers/thermal/samsung/exynos_tmu_data.c |   78 
> +
>  drivers/thermal/samsung/exynos_tmu_data.h |   40 +++
>  5 files changed, 125 insertions(+), 64 deletions(-)
>  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
>  create mode 100644 drivers/thermal/samsung/exynos_tmu_data.h
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index f8100b1..b653f15 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -5,7 +5,8 @@ config EXYNOS_THERMAL
> If you say yes here you get support for the TMU (Thermal Management
> Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
> the TMU, reports temperature and handles cooling action if defined.
> -   This driver uses the exynos core thermal API's.
> +   This driver uses the exynos core thermal API's and TMU configuration
> +   data from the supported soc's.
>  
>  config EXYNOS_THERMAL_CORE
>   bool "Core thermal framework support for EXYNOS SOC's"
> diff --git a/drivers/thermal/samsung/Makefile 
> b/drivers/thermal/samsung/Makefile
> index 22528d6..c09d830 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -3,4 +3,5 @@
>  #
>  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 6aa2fd2..5df04a1 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -30,6 +30,7 @@
>  
>  #include "exynos_thermal_common.h"
>  #include "exynos_tmu.h"
> +#include "exynos_tmu_data.h"
>  
>  /* Exynos generic registers */
>  #define EXYNOS_TMU_REG_TRIMINFO  0x0
> @@ -381,66 +382,6 @@ static struct thermal_sensor_conf exynos_sensor_conf = {
>   .write_emul_temp= exynos_tmu_set_emulation,
>  };
>  
> -#if defined(CONFIG_CPU_EXYNOS4210)
> -static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
> - .threshold = 80,
> - .trigger_levels[0] = 5,
> - .trigger_levels[1] = 20,
> - .trigger_levels[2] = 30,
> - .trigger_level0_en = 1,
> - .trigger_level1_en = 1,
> - .trigger_level2_en = 1,
> - .trigger_level3_en = 0,
> - .gain = 15,
> - .reference_voltage = 7,
> - .cal_type = TYPE_ONE_POINT_TRIMMING,
> - .freq_tab[0] = {
> - .freq_clip_max = 800 * 1000,
> - .temp_level = 85,
> - },
> - .freq_tab[1] = {
> - .freq_clip_max = 200 * 1000,
> - .temp_level = 100,
> - },
> - .freq_tab_count = 2,
> - .type = SOC_ARCH_EXYNOS4210,
> -};
> -#define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
> -#else
> -#define EXYNOS4210_TMU_DRV_DATA (NULL)
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
> -static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
> - .threshold_falling = 10,
> - .trigger_levels[0] = 85,
> - .trigger_levels[1] = 103,
> - .trigger_levels[2] = 110,
> - .trigger_level0_en = 1,
> - .trigger_level1_en = 1,
> - .trigger_level2_en = 1,
> - .trigger_level3_en = 0,
> - .gain = 8,
> - .reference_voltage = 16,
> - .noise_cancel_mode = 4,
> - .cal_type = TYPE_ONE_POINT_TRIMMING,
> - .efuse_value = 55,
> - .freq_tab[0] = {
> - .freq_clip_max = 800 * 1000,
> - .temp_level = 85,
> - },
> - .freq_tab[1] = {
> - .freq_clip_max = 200 * 1000,
> - .temp_level = 103,
> - },
> - .freq_tab_count = 2,
> - .type = SOC_ARCH_EXYNOS,
> -};
> -#define EXYNOS_TMU_DRV_DATA (&exynos_default_tmu_data)
> -#else
> -#define EXYNOS_TMU_DRV_DATA (NULL)
> -#endif
> -
>  #ifdef CONFIG_OF
>  static const struct of_device_id exynos_tmu_match[] = {
>   {
> @@ -449,11 +390,11 @@ static const struct of_device_id exynos_tmu_match[] = {
>   },
>   {
>   .compatible = "samsung,exynos4412-tmu",
> - .data = (void *)EXYNOS_TMU_DRV_DATA,
> + .data = (void *)EXYNOS5250_TMU_DRV_DATA,
>   },
>   {
>  

Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 20:22:11 Mark Brown wrote:
> On Wed, Jun 19, 2013 at 08:26:12PM +0200, Tomasz Figa wrote:
> > On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:
> > > - ret = pd->get_signal(plchan->cd);
> > > + ret = (pd->get_signal)(plchan->cd);
> > 
> > Hmm, that's strange. The former is a completely valid piece of code...
> 
> I know, hence...
> 
> > > to get it to build which makes me suspect the compiler a bit as
> > > well...
> 
> ...my comment about suspecting the compiler.
> 
> > > I was applying this to -next, are there any other dependencies I
> > > need or anything?
> > 
> > Hmm, I've been testing this on top of my common clock framework and
> > device tree patches, but I don't think this had any effect. Did you
> > add necessary clkdev lookups to the clock driver?
> 
> No, I didn't - that's most likely it, I didn't really investigate.  I
> didn't test the watchdog stuff as the clocks didn't get sent to me.

I always try to keep you on Cc of my patches for s3c64xx, as you are the 
most active user of this platform (if not the only one other than me) and 
this was the case for clock patches as well, just checked that.

Seems like I forgot to add you to watchdog patches, sorry. But you didn't 
miss anything, since they were rather trivial ones.

> > In Samsung CCF alias notation it looks like this:
> > 
> > +   ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),
> > +   ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),
> > 
> > Not sure how hard it will be to add such lookups to the old clock
> > driver, though.
> 
> It's pretty much the same providing you know which clock needs to be
> used.
> 
> > I will test this applied directly on top of current linux-next when I
> > find some time, but for now you might check out my v3.11-devel branch
> > on my github:
> > 
> > https://github.com/tom3q/linux.git
> 
> Will try to get round to it.

OK.

Best regards,
Tomasz

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


Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Mark Brown
On Wed, Jun 19, 2013 at 09:01:33PM +0200, Arnd Bergmann wrote:
> On Wednesday 19 June 2013, Tomasz Figa wrote:

> > >   if (plchan->mux_use++ == 0 && pd->get_signal) {
> > > - ret = pd->get_signal(plchan->cd);
> > > + ret = (pd->get_signal)(plchan->cd);

> > Hmm, that's strange. The former is a completely valid piece of code...

> get_signal is a macro defined in include/linux/signal.h. If that header
> gets included, neither of the two is valid.

Ah, that'll be it.  I'll post a patch to rename...


signature.asc
Description: Digital signature


Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Mark Brown
On Wed, Jun 19, 2013 at 08:26:12PM +0200, Tomasz Figa wrote:
> On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:

> > -   ret = pd->get_signal(plchan->cd);
> > +   ret = (pd->get_signal)(plchan->cd);

> Hmm, that's strange. The former is a completely valid piece of code...

I know, hence...

> > to get it to build which makes me suspect the compiler a bit as well...

...my comment about suspecting the compiler.

> > I was applying this to -next, are there any other dependencies I need or
> > anything?

> Hmm, I've been testing this on top of my common clock framework and device 
> tree patches, but I don't think this had any effect. Did you add necessary 
> clkdev lookups to the clock driver?

No, I didn't - that's most likely it, I didn't really investigate.  I
didn't test the watchdog stuff as the clocks didn't get sent to me.

> In Samsung CCF alias notation it looks like this:

> +   ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),
> +   ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),

> Not sure how hard it will be to add such lookups to the old clock driver, 
> though.

It's pretty much the same providing you know which clock needs to be
used.

> I will test this applied directly on top of current linux-next when I find 
> some time, but for now you might check out my v3.11-devel branch on my 
> github:

> https://github.com/tom3q/linux.git

Will try to get round to it.


signature.asc
Description: Digital signature


Re: [PATCH V6 06/30] thermal: exynos: Move exynos_thermal.h from include/* to driver/* folder

2013-06-19 Thread Eduardo Valentin
On 19-06-2013 15:18, Eduardo Valentin wrote:
> On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
>> This patch renames and moves include/linux/platform_data/exynos_thermal.h to
>> drivers/thermal/samsung/exynos_tmu.h. This file movement is needed as exynos
>> SOC's are not supporting non-DT based platforms and this file now just 
>> contains
>> exynos tmu driver related definations.
>> Also struct freq_clip_table is now moved to exynos_thermal_common.c as it 
>> fixes
>> the compilation issue occuring because now this new tmu header file is 
>> included
>> in tmu driver c file and not in the common thermal header file.
>>
>> Acked-by: Kukjin Kim 
>> Acked-by: Jonghwa Lee 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  drivers/thermal/samsung/exynos_thermal_common.c|1 -
>>  drivers/thermal/samsung/exynos_thermal_common.h|   15 
>>  drivers/thermal/samsung/exynos_tmu.c   |2 +-
>>  .../thermal/samsung/exynos_tmu.h   |   24 
>> ---
>>  4 files changed, 21 insertions(+), 21 deletions(-)
>>  rename include/linux/platform_data/exynos_thermal.h => 
>> drivers/thermal/samsung/exynos_tmu.h (84%)
>>
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
>> b/drivers/thermal/samsung/exynos_thermal_common.c
>> index 92e50bc..dd49c9f 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.c
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
>> @@ -21,7 +21,6 @@
>>   */
>>  
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
>> b/drivers/thermal/samsung/exynos_thermal_common.h
>> index 8df1848..068f56c 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> @@ -44,6 +44,21 @@
>>  
>>  #define EXYNOS_ZONE_COUNT   3
>>  
>> +/**
>> + * struct freq_clip_table
>> + * @freq_clip_max: maximum frequency allowed for this cooling state.
>> + * @temp_level: Temperature level at which the temperature clipping will
>> + *  happen.
>> + * @mask_val: cpumask of the allowed cpu's where the clipping will take 
>> place.
>> + *
>> + * This structure is required to be filled and passed to the
>> + * cpufreq_cooling_unregister function.
>> + */
>> +struct freq_clip_table {
>> +unsigned int freq_clip_max;
>> +unsigned int temp_level;
>> +const struct cpumask *mask_val;
>> +};

Another minor: add an empty line here.

>>  struct  thermal_trip_point_conf {
>>  int trip_val[MAX_TRIP_COUNT];
>>  int trip_count;
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 22a8874..6aa2fd2 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -27,9 +27,9 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  
>>  #include "exynos_thermal_common.h"
>> +#include "exynos_tmu.h"
>>  
>>  /* Exynos generic registers */
>>  #define EXYNOS_TMU_REG_TRIMINFO 0x0
>> diff --git a/include/linux/platform_data/exynos_thermal.h 
>> b/drivers/thermal/samsung/exynos_tmu.h
>> similarity index 84%
>> rename from include/linux/platform_data/exynos_thermal.h
>> rename to drivers/thermal/samsung/exynos_tmu.h
>> index da7e627..9e0f887 100644
>> --- a/include/linux/platform_data/exynos_thermal.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -1,8 +1,9 @@
>>  /*
>> - * exynos_thermal.h - Samsung EXYNOS TMU (Thermal Management Unit)
>> + * exynos_tmu.h - Samsung EXYNOS TMU (Thermal Management Unit)
>>   *
>>   *  Copyright (C) 2011 Samsung Electronics
>>   *  Donggeun Kim 
>> + *  Amit Daniel Kachhap 
>>   *
>>   * 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
>> @@ -19,8 +20,8 @@
>>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>>   */
>>  
>> -#ifndef _LINUX_EXYNOS_THERMAL_H
>> -#define _LINUX_EXYNOS_THERMAL_H
>> +#ifndef _EXYNOS_TMU_H
>> +#define _EXYNOS_TMU_H
>>  #include 
>>  
>>  enum calibration_type {
>> @@ -33,21 +34,6 @@ enum soc_type {
>>  SOC_ARCH_EXYNOS4210 = 1,
>>  SOC_ARCH_EXYNOS,
>>  };
>> -/**
>> - * struct freq_clip_table
>> - * @freq_clip_max: maximum frequency allowed for this cooling state.
>> - * @temp_level: Temperature level at which the temperature clipping will
>> - *  happen.
>> - * @mask_val: cpumask of the allowed cpu's where the clipping will take 
>> place.
>> - *
>> - * This structure is required to be filled and passed to the
>> - * cpufreq_cooling_unregister function.
>> - */
>> -struct freq_clip_table {
>> -unsigned int freq_clip_max;
>> -unsigned int temp_level;
>> -const struct cpumask *mask_val;
>> -};
>>  
>>  /**
>>   * struct exynos_tmu_platform_data
>> @@ -116,4 +102,4 @@ struct exynos_tmu_platform_data {
>>  struct freq_clip_table freq_tab[4];
> 
> Because you have this struct right here, you need still 

Re: [PATCH V6 06/30] thermal: exynos: Move exynos_thermal.h from include/* to driver/* folder

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch renames and moves include/linux/platform_data/exynos_thermal.h to
> drivers/thermal/samsung/exynos_tmu.h. This file movement is needed as exynos
> SOC's are not supporting non-DT based platforms and this file now just 
> contains
> exynos tmu driver related definations.
> Also struct freq_clip_table is now moved to exynos_thermal_common.c as it 
> fixes
> the compilation issue occuring because now this new tmu header file is 
> included
> in tmu driver c file and not in the common thermal header file.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/exynos_thermal_common.c|1 -
>  drivers/thermal/samsung/exynos_thermal_common.h|   15 
>  drivers/thermal/samsung/exynos_tmu.c   |2 +-
>  .../thermal/samsung/exynos_tmu.h   |   24 ---
>  4 files changed, 21 insertions(+), 21 deletions(-)
>  rename include/linux/platform_data/exynos_thermal.h => 
> drivers/thermal/samsung/exynos_tmu.h (84%)
> 
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c 
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 92e50bc..dd49c9f 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -21,7 +21,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 8df1848..068f56c 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -44,6 +44,21 @@
>  
>  #define EXYNOS_ZONE_COUNT3
>  
> +/**
> + * struct freq_clip_table
> + * @freq_clip_max: maximum frequency allowed for this cooling state.
> + * @temp_level: Temperature level at which the temperature clipping will
> + *   happen.
> + * @mask_val: cpumask of the allowed cpu's where the clipping will take 
> place.
> + *
> + * This structure is required to be filled and passed to the
> + * cpufreq_cooling_unregister function.
> + */
> +struct freq_clip_table {
> + unsigned int freq_clip_max;
> + unsigned int temp_level;
> + const struct cpumask *mask_val;
> +};
>  struct   thermal_trip_point_conf {
>   int trip_val[MAX_TRIP_COUNT];
>   int trip_count;
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 22a8874..6aa2fd2 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -27,9 +27,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "exynos_thermal_common.h"
> +#include "exynos_tmu.h"
>  
>  /* Exynos generic registers */
>  #define EXYNOS_TMU_REG_TRIMINFO  0x0
> diff --git a/include/linux/platform_data/exynos_thermal.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> similarity index 84%
> rename from include/linux/platform_data/exynos_thermal.h
> rename to drivers/thermal/samsung/exynos_tmu.h
> index da7e627..9e0f887 100644
> --- a/include/linux/platform_data/exynos_thermal.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -1,8 +1,9 @@
>  /*
> - * exynos_thermal.h - Samsung EXYNOS TMU (Thermal Management Unit)
> + * exynos_tmu.h - Samsung EXYNOS TMU (Thermal Management Unit)
>   *
>   *  Copyright (C) 2011 Samsung Electronics
>   *  Donggeun Kim 
> + *  Amit Daniel Kachhap 
>   *
>   * 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
> @@ -19,8 +20,8 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#ifndef _LINUX_EXYNOS_THERMAL_H
> -#define _LINUX_EXYNOS_THERMAL_H
> +#ifndef _EXYNOS_TMU_H
> +#define _EXYNOS_TMU_H
>  #include 
>  
>  enum calibration_type {
> @@ -33,21 +34,6 @@ enum soc_type {
>   SOC_ARCH_EXYNOS4210 = 1,
>   SOC_ARCH_EXYNOS,
>  };
> -/**
> - * struct freq_clip_table
> - * @freq_clip_max: maximum frequency allowed for this cooling state.
> - * @temp_level: Temperature level at which the temperature clipping will
> - *   happen.
> - * @mask_val: cpumask of the allowed cpu's where the clipping will take 
> place.
> - *
> - * This structure is required to be filled and passed to the
> - * cpufreq_cooling_unregister function.
> - */
> -struct freq_clip_table {
> - unsigned int freq_clip_max;
> - unsigned int temp_level;
> - const struct cpumask *mask_val;
> -};
>  
>  /**
>   * struct exynos_tmu_platform_data
> @@ -116,4 +102,4 @@ struct exynos_tmu_platform_data {
>   struct freq_clip_table freq_tab[4];

Because you have this struct right here, you need still to have:
+#include "exynos_thermal_common.h"

in your include list of exynos_tmu.h (this file).

A part from this minor issue, you can add my acked:

Acked-by: Eduardo Valentin 

>   unsigned int freq_tab_coun

Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Arnd Bergmann
On Wednesday 19 June 2013, Tomasz Figa wrote:
> On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:
> > On Sun, Jun 16, 2013 at 10:54:07PM +0200, Tomasz Figa wrote:
> > > One of the biggest roadblocks on the way of S3C64xx to DeviceTree
> > > support is its DMA driver, which is completely platform-specific and
> > > provides private API (s3c-dma), not even saying that its design is
> > > completely against multiplatform-awareness.
> > 
> > I tried to test this on my s3c64xx based system but it gave me a kernel
> > that didn't boot far enough to give console output (there's some early
> > init stuff that uses SPI...).  That said, I needed:
> > 
> > diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> > index 210a893..0f49707 100644
> > --- a/drivers/dma/amba-pl08x.c
> > +++ b/drivers/dma/amba-pl08x.c
> > @@ -313,7 +313,7 @@ static int pl08x_request_mux(struct pl08x_dma_chan
> > *plchan) int ret;
> > 
> >   if (plchan->mux_use++ == 0 && pd->get_signal) {
> > - ret = pd->get_signal(plchan->cd);
> > + ret = (pd->get_signal)(plchan->cd);
> 
> Hmm, that's strange. The former is a completely valid piece of code...

get_signal is a macro defined in include/linux/signal.h. If that header
gets included, neither of the two is valid.

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


Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This code bifurcates exynos thermal implementation into common and sensor
> specific parts. The common thermal code interacts with core thermal layer and
> core cpufreq cooling parts and is independent of SOC specific driver. This
> change is needed to cleanly add support for new TMU sensors.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/Kconfig |   19 +-
>  drivers/thermal/samsung/Makefile|4 +-
>  drivers/thermal/samsung/exynos_thermal.c|  419 
> +--
>  drivers/thermal/samsung/exynos_thermal_common.c |  384 +
>  drivers/thermal/samsung/exynos_thermal_common.h |   83 +
>  5 files changed, 490 insertions(+), 419 deletions(-)
>  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
>  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index 2cf31ad..f8100b1 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -1,8 +1,17 @@
>  config EXYNOS_THERMAL
> - tristate "Temperature sensor on Samsung EXYNOS"
> + tristate "Exynos thermal management unit driver"
>   depends on ARCH_HAS_BANDGAP

This is not really on this patch, but I think this one needs to depend
on CONFIG_OF too.

>   help
> -   If you say yes here you get support for TMU (Thermal Management
> -   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> -   the exynos thermal driver with the core thermal layer and cpu
> -   cooling API's.
> +   If you say yes here you get support for the TMU (Thermal Management
> +   Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
> +   the TMU, reports temperature and handles cooling action if defined.
> +   This driver uses the exynos core thermal API's.
> +
> +config EXYNOS_THERMAL_CORE
> + bool "Core thermal framework support for EXYNOS SOC's"
> + depends on EXYNOS_THERMAL
> + help
> +   If you say yes here you get support for EXYNOS TMU
> +   (Thermal Management Unit) common registration/unregistration
> +   functions to the core thermal layer and also to use the generic
> +   cpu cooling API's.
> diff --git a/drivers/thermal/samsung/Makefile 
> b/drivers/thermal/samsung/Makefile
> index 1fe6d93..6227d4f 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -1,4 +1,6 @@
>  #
>  # Samsung thermal specific Makefile
>  #
> -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_soc_thermal.o
> +exynos_soc_thermal-y := exynos_thermal.o
> +exynos_soc_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal.c 
> b/drivers/thermal/samsung/exynos_thermal.c
> index 03e4bbc..5293849 100644
> --- a/drivers/thermal/samsung/exynos_thermal.c
> +++ b/drivers/thermal/samsung/exynos_thermal.c
> @@ -21,23 +21,15 @@
>   *
>   */
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +
> +#include "exynos_thermal_common.h"
>  
>  /* Exynos generic registers */
>  #define EXYNOS_TMU_REG_TRIMINFO  0x0
> @@ -88,16 +80,6 @@
>  #define EFUSE_MIN_VALUE 40
>  #define EFUSE_MAX_VALUE 100
>  
> -/* In-kernel thermal framework related macros & definations */
> -#define SENSOR_NAME_LEN  16
> -#define MAX_TRIP_COUNT   8
> -#define MAX_COOLING_DEVICE 4
> -#define MAX_THRESHOLD_LEVS 4
> -
> -#define ACTIVE_INTERVAL 500
> -#define IDLE_INTERVAL 1
> -#define MCELSIUS 1000
> -
>  #ifdef CONFIG_THERMAL_EMULATION
>  #define EXYNOS_EMUL_TIME 0x57F0
>  #define EXYNOS_EMUL_TIME_SHIFT   16
> @@ -106,17 +88,6 @@
>  #define EXYNOS_EMUL_ENABLE   0x1
>  #endif /* CONFIG_THERMAL_EMULATION */
>  
> -/* CPU Zone information */
> -#define PANIC_ZONE  4
> -#define WARN_ZONE   3
> -#define MONITOR_ZONE2
> -#define SAFE_ZONE   1
> -
> -#define GET_ZONE(trip) (trip + 2)
> -#define GET_TRIP(zone) (zone - 2)
> -
> -#define EXYNOS_ZONE_COUNT3
> -
>  struct exynos_tmu_data {
>   struct exynos_tmu_platform_data *pdata;
>   struct resource *mem;
> @@ -129,384 +100,6 @@ struct exynos_tmu_data {
>   u8 temp_error1, temp_error2;
>  };
>  
> -struct   thermal_trip_point_conf {
> - int trip_val[MAX_TRIP_COUNT];
> - int trip_count;
> - u8 trigger_falling;
> -};
> -
> -struct   thermal_cooling_conf {
> - struct freq_clip_table freq_data[MAX_TRIP_COUNT];
> - int freq_clip_count;
> -};
> -
> -struct thermal_sensor_conf {
> -

Re: [PATCH V6 03/30] thermal: exynos: Remove un-necessary CPU_THERMAL dependency

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch removes the dependency on CPU_THERMAL for compiling TMU driver.
> This is useful for cases when only TMU controller needs to be initialised
> without cpu cooling action.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 


Acked-by: Eduardo Valentin 

Please have a look on my comment on your patch 04. You may want to have
this dependency still on your core part.

> ---
>  drivers/thermal/samsung/Kconfig |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index 883a8a8..2cf31ad 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -1,7 +1,6 @@
>  config EXYNOS_THERMAL
>   tristate "Temperature sensor on Samsung EXYNOS"
>   depends on ARCH_HAS_BANDGAP
> - depends on CPU_THERMAL
>   help
> If you say yes here you get support for TMU (Thermal Management
> Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 01/30] thermal: exynos: Moving exynos thermal files into samsung directory

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This movement of files is done for easy maintenance and adding more
> new sensor's support for exynos platform easily . This will also help in
> bifurcating exynos common, sensor driver and sensor data related parts.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/Kconfig|   13 +
>  drivers/thermal/Makefile   |2 +-
>  drivers/thermal/samsung/Kconfig|9 +
>  drivers/thermal/samsung/Makefile   |4 
>  drivers/thermal/{ => samsung}/exynos_thermal.c |0
>  5 files changed, 19 insertions(+), 9 deletions(-)
>  create mode 100644 drivers/thermal/samsung/Kconfig
>  create mode 100644 drivers/thermal/samsung/Makefile
>  rename drivers/thermal/{ => samsung}/exynos_thermal.c (100%)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b13c2bc..ef10cf2 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -114,14 +114,6 @@ config KIRKWOOD_THERMAL
> Support for the Kirkwood thermal sensor driver into the Linux thermal
> framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
>  
> -config EXYNOS_THERMAL
> - tristate "Temperature sensor on Samsung EXYNOS"
> - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> - depends on CPU_THERMAL
> - help
> -   If you say yes here you get support for TMU (Thermal Management
> -   Unit) on SAMSUNG EXYNOS series of SoC.
> -
>  config DOVE_THERMAL
>   tristate "Temperature sensor on Marvell Dove SoCs"
>   depends on ARCH_DOVE
> @@ -185,4 +177,9 @@ menu "Texas Instruments thermal drivers"
>  source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
>  
> +menu "Samsung thermal drivers"
> +depends on PLAT_SAMSUNG
> +source "drivers/thermal/samsung/Kconfig"
> +endmenu
> +
>  endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 67184a2..1f27ada 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -17,7 +17,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL)   += cpu_cooling.o
>  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
>  obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
>  obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
> -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-y+= samsung/
>  obj-$(CONFIG_DOVE_THERMAL)   += dove_thermal.o
>  obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
>  obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> new file mode 100644
> index 000..2d3d9dc
> --- /dev/null
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -0,0 +1,9 @@
> +config EXYNOS_THERMAL
> + tristate "Temperature sensor on Samsung EXYNOS"
> + depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> + depends on CPU_THERMAL
> + help
> +   If you say yes here you get support for TMU (Thermal Management
> +   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> +   the exynos thermal driver with the core thermal layer and cpu
> +   cooling API's.
> diff --git a/drivers/thermal/samsung/Makefile 
> b/drivers/thermal/samsung/Makefile
> new file mode 100644
> index 000..1fe6d93
> --- /dev/null
> +++ b/drivers/thermal/samsung/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Samsung thermal specific Makefile
> +#
> +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> diff --git a/drivers/thermal/exynos_thermal.c 
> b/drivers/thermal/samsung/exynos_thermal.c
> similarity index 100%
> rename from drivers/thermal/exynos_thermal.c
> rename to drivers/thermal/samsung/exynos_thermal.c
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 04/30] thermal: exynos: Bifurcate exynos thermal common and tmu controller code

2013-06-19 Thread Eduardo Valentin
Amit,

On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This code bifurcates exynos thermal implementation into common and sensor
> specific parts. The common thermal code interacts with core thermal layer and
> core cpufreq cooling parts and is independent of SOC specific driver. This
> change is needed to cleanly add support for new TMU sensors.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/samsung/Kconfig |   19 +-
>  drivers/thermal/samsung/Makefile|4 +-
>  drivers/thermal/samsung/exynos_thermal.c|  419 
> +--
>  drivers/thermal/samsung/exynos_thermal_common.c |  384 +
>  drivers/thermal/samsung/exynos_thermal_common.h |   83 +
>  5 files changed, 490 insertions(+), 419 deletions(-)
>  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
>  create mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index 2cf31ad..f8100b1 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -1,8 +1,17 @@
>  config EXYNOS_THERMAL
> - tristate "Temperature sensor on Samsung EXYNOS"
> + tristate "Exynos thermal management unit driver"
>   depends on ARCH_HAS_BANDGAP
>   help
> -   If you say yes here you get support for TMU (Thermal Management
> -   Unit) on SAMSUNG EXYNOS series of SoC. This helps in registering
> -   the exynos thermal driver with the core thermal layer and cpu
> -   cooling API's.
> +   If you say yes here you get support for the TMU (Thermal Management
> +   Unit) driver for SAMSUNG EXYNOS series of soc. This driver initialises
> +   the TMU, reports temperature and handles cooling action if defined.
> +   This driver uses the exynos core thermal API's.
> +
> +config EXYNOS_THERMAL_CORE
> + bool "Core thermal framework support for EXYNOS SOC's"
> + depends on EXYNOS_THERMAL
> + help
> +   If you say yes here you get support for EXYNOS TMU
> +   (Thermal Management Unit) common registration/unregistration
> +   functions to the core thermal layer and also to use the generic
> +   cpu cooling API's.
Should this one depend on CPU_THERMAL? Is it mandatory?

> diff --git a/drivers/thermal/samsung/Makefile 
> b/drivers/thermal/samsung/Makefile
> index 1fe6d93..6227d4f 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -1,4 +1,6 @@
>  #
>  # Samsung thermal specific Makefile
>  #
> -obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
> +obj-$(CONFIG_EXYNOS_THERMAL) += exynos_soc_thermal.o
> +exynos_soc_thermal-y := exynos_thermal.o
> +exynos_soc_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal.c 
> b/drivers/thermal/samsung/exynos_thermal.c
> index 03e4bbc..5293849 100644
> --- a/drivers/thermal/samsung/exynos_thermal.c
> +++ b/drivers/thermal/samsung/exynos_thermal.c
> @@ -21,23 +21,15 @@
>   *
>   */
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +
> +#include "exynos_thermal_common.h"
>  
>  /* Exynos generic registers */
>  #define EXYNOS_TMU_REG_TRIMINFO  0x0
> @@ -88,16 +80,6 @@
>  #define EFUSE_MIN_VALUE 40
>  #define EFUSE_MAX_VALUE 100
>  
> -/* In-kernel thermal framework related macros & definations */
> -#define SENSOR_NAME_LEN  16
> -#define MAX_TRIP_COUNT   8
> -#define MAX_COOLING_DEVICE 4
> -#define MAX_THRESHOLD_LEVS 4
> -
> -#define ACTIVE_INTERVAL 500
> -#define IDLE_INTERVAL 1
> -#define MCELSIUS 1000
> -
>  #ifdef CONFIG_THERMAL_EMULATION
>  #define EXYNOS_EMUL_TIME 0x57F0
>  #define EXYNOS_EMUL_TIME_SHIFT   16
> @@ -106,17 +88,6 @@
>  #define EXYNOS_EMUL_ENABLE   0x1
>  #endif /* CONFIG_THERMAL_EMULATION */
>  
> -/* CPU Zone information */
> -#define PANIC_ZONE  4
> -#define WARN_ZONE   3
> -#define MONITOR_ZONE2
> -#define SAFE_ZONE   1
> -
> -#define GET_ZONE(trip) (trip + 2)
> -#define GET_TRIP(zone) (zone - 2)
> -
> -#define EXYNOS_ZONE_COUNT3
> -
>  struct exynos_tmu_data {
>   struct exynos_tmu_platform_data *pdata;
>   struct resource *mem;
> @@ -129,384 +100,6 @@ struct exynos_tmu_data {
>   u8 temp_error1, temp_error2;
>  };
>  
> -struct   thermal_trip_point_conf {
> - int trip_val[MAX_TRIP_COUNT];
> - int trip_count;
> - u8 trigger_falling;
> -};
> -
> -struct   thermal_cooling_conf {
> - struct freq_clip_table freq_data[MAX_TRIP_COUNT];
> - int freq_clip_count;
> -};
> -
> -struct thermal_sensor_conf {
> - char name[SENSOR_NAME_

Re: [PATCH V6 02/30] thermal: exynos: Use ARCH_HAS_BANDGAP config to know the supported soc's

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch uses the recently added config sybmol ARCH_HAS_BANDGAP to enable
> the TMU driver. This will allow adding support for new soc easily as now it
> is the platform responsibility to enable this config symbol for a particular
> soc.
> 
> Acked-by: Kukjin Kim 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 


Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/samsung/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index 2d3d9dc..883a8a8 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -1,6 +1,6 @@
>  config EXYNOS_THERMAL
>   tristate "Temperature sensor on Samsung EXYNOS"
> - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
> + depends on ARCH_HAS_BANDGAP
>   depends on CPU_THERMAL
>   help
> If you say yes here you get support for TMU (Thermal Management
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [PATCH V6 30/30] arm: exynos: enable ARCH_HAS_BANDGAP

2013-06-19 Thread Eduardo Valentin
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch enables ARCH_HAS_BANDGAP config for exynos4210, 4212, 4412, 5250
> and 5440 SOC. This config symbol is recently added to allow the platforms
> to enable bandgap based temperature sensor.
> 
> Acked-by: Jonghwa Lee 
> Signed-off-by: Amit Daniel Kachhap 

Acked-by: Eduardo Valentin 

> ---
>  arch/arm/mach-exynos/Kconfig |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index d19edff..d3cb5c7 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -33,6 +33,7 @@ config CPU_EXYNOS4210
>   bool "SAMSUNG EXYNOS4210"
>   default y
>   depends on ARCH_EXYNOS4
> + select ARCH_HAS_BANDGAP
>   select ARM_CPU_SUSPEND if PM
>   select PM_GENERIC_DOMAINS
>   select S5P_PM if PM
> @@ -45,6 +46,7 @@ config SOC_EXYNOS4212
>   bool "SAMSUNG EXYNOS4212"
>   default y
>   depends on ARCH_EXYNOS4
> + select ARCH_HAS_BANDGAP
>   select S5P_PM if PM
>   select S5P_SLEEP if PM
>   select SAMSUNG_DMADEV
> @@ -55,6 +57,7 @@ config SOC_EXYNOS4412
>   bool "SAMSUNG EXYNOS4412"
>   default y
>   depends on ARCH_EXYNOS4
> + select ARCH_HAS_BANDGAP
>   select SAMSUNG_DMADEV
>   help
> Enable EXYNOS4412 SoC support
> @@ -63,6 +66,7 @@ config SOC_EXYNOS5250
>   bool "SAMSUNG EXYNOS5250"
>   default y
>   depends on ARCH_EXYNOS5
> + select ARCH_HAS_BANDGAP
>   select PM_GENERIC_DOMAINS if PM
>   select S5P_PM if PM
>   select S5P_SLEEP if PM
> @@ -76,6 +80,7 @@ config SOC_EXYNOS5440
>   default y
>   depends on ARCH_EXYNOS5
>   select ARCH_HAS_OPP
> + select ARCH_HAS_BANDGAP
>   select ARM_ARCH_TIMER
>   select AUTO_ZRELADDR
>   select PINCTRL
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature


Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:
> On Sun, Jun 16, 2013 at 10:54:07PM +0200, Tomasz Figa wrote:
> > One of the biggest roadblocks on the way of S3C64xx to DeviceTree
> > support is its DMA driver, which is completely platform-specific and
> > provides private API (s3c-dma), not even saying that its design is
> > completely against multiplatform-awareness.
> 
> I tried to test this on my s3c64xx based system but it gave me a kernel
> that didn't boot far enough to give console output (there's some early
> init stuff that uses SPI...).  That said, I needed:
> 
> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> index 210a893..0f49707 100644
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -313,7 +313,7 @@ static int pl08x_request_mux(struct pl08x_dma_chan
> *plchan) int ret;
> 
>   if (plchan->mux_use++ == 0 && pd->get_signal) {
> - ret = pd->get_signal(plchan->cd);
> + ret = (pd->get_signal)(plchan->cd);

Hmm, that's strange. The former is a completely valid piece of code...

>   if (ret < 0) {
>   plchan->mux_use = 0;
>   return ret;
> 
> to get it to build which makes me suspect the compiler a bit as well...
> the system has audio, SPI and MMC enabled.
> 
> I was applying this to -next, are there any other dependencies I need or
> anything?

Hmm, I've been testing this on top of my common clock framework and device 
tree patches, but I don't think this had any effect. Did you add necessary 
clkdev lookups to the clock driver?

In Samsung CCF alias notation it looks like this:

+   ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),
+   ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),

Not sure how hard it will be to add such lookups to the old clock driver, 
though.

I will test this applied directly on top of current linux-next when I find 
some time, but for now you might check out my v3.11-devel branch on my 
github:

https://github.com/tom3q/linux.git

Best regards,
Tomasz

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


[PATCH] spi/s3c64xx: Make wait_for_timeout() function name less generic

2013-06-19 Thread Mark Brown
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 0a80692..70b2213 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -583,7 +583,7 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data 
*sdd,
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 }
 
-static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+static u32 s3c64xx_spi_wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
int timeout_ms)
 {
void __iomem *regs = sdd->regs;
@@ -676,7 +676,8 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
buf = xfer->rx_buf;
do {
/* wait for data to be received in the fifo */
-   cpy_len = wait_for_timeout(sdd, (loops ? ms : 0));
+   cpy_len = s3c64xx_spi_wait_for_timeout(sdd,
+   (loops ? ms : 0));
 
switch (sdd->cur_bpw) {
case 32:
-- 
1.8.3.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 v6 2/7] clk: samsung: Define a common samsung_clk_register_pll()

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 23:44:47 Yadwinder Singh Brar wrote:
> On Wed, Jun 19, 2013 at 10:24 PM, Tomasz Figa  
wrote:
> > Hi Yadwinder,
> > 
> > Generally looks really good, but some comments inline.
> > 
> > On Monday 10 of June 2013 18:54:14 Yadwinder Singh Brar wrote:
> >> This patch defines a common samsung_clk_register_pll() and its
> >> migrating the PLL35xx & PLL36xx to use it. Other samsung PLL can
> >> also be migrated to it. It also adds exynos5250 & exynos5420 PLLs to
> >> unique id list of clocks. Since pll2550 & pll35xx and pll2650 &
> >> pll36xx have exactly same clk ops implementation, added pll2550 and
> >> pll2650 also.
> >> 
> >> +void __init samsung_clk_register_pll(struct samsung_pll_clock
> >> *clk_list, +  unsigned int nr_pll, void
> >> __iomem
> > 
> > *base)
> > 
> >> +{
> >> + struct samsung_clk_pll *pll;
> >> + struct clk *clk;
> >> + struct clk_init_data init;
> >> + struct samsung_pll_clock *list = clk_list;
> >> + int cnt;
> >> +
> >> + for (cnt = 0; cnt < nr_pll; cnt++, list++) {
> > 
> > I'd suggest moving contents of this loop to a function like following?
> > 
> > static int __init _samsung_clk_register_pll(struct samsung_pll_clock
> > *pll,> 
> > void __iomem *base)
> > 
> > This will make the code less indented and so more readable.
> 
> Yes, will do it.
> 
> >> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> >> + if (!pll) {
> >> + pr_err("%s: could not allocate pll clk %s\n",
> >> + __func__, list->name);
> >> + continue;
> >> + }
> >> +
> >> + init.name = list->name;
> >> + init.flags = list->flags;
> >> + init.parent_names = &list->parent_name;
> >> + init.num_parents = 1;
> >> +
> >> + switch (list->type) {
> >> + /* clk_ops for 35xx and 2550 are similar */
> >> + case pll_35xx:
> >> + case pll_2550:
> >> + init.ops = &samsung_pll35xx_clk_ops;
> >> + break;
> >> + /* clk_ops for 36xx and 2650 are similar */
> >> + case pll_36xx:
> >> + case pll_2650:
> >> + init.ops = &samsung_pll36xx_clk_ops;
> >> + break;
> >> + default:
> >> + pr_warn("%s: Unknown pll type for pll clk
> >> %s\n",
> >> + __func__, list->name);
> >> + }
> >> +
> >> + pll->hw.init = &init;
> >> + pll->type = list->type;
> >> + pll->lock_reg = base + list->lock_offset;
> >> + pll->con_reg = base + list->con_offset;
> >> +
> >> + clk = clk_register(NULL, &pll->hw);
> >> + if (IS_ERR(clk)) {
> >> + pr_err("%s: failed to register pll clock %s\n",
> >> + __func__, list->name);
> >> + kfree(pll);
> >> + continue;
> >> + }
> >> +
> >> + samsung_clk_add_lookup(clk, list->id);
> >> +
> >> + if (list->alias)
> >> + if (clk_register_clkdev(clk, list->alias,
> >> + list->dev_name))
> > 
> > What about
> > 
> > if (!list->alias)
> > 
> > return;
> > 
> > ret = clk_register_clkdev(clk, list->alias, list-
> >>
> >>dev_name);
> >>
> > if (ret)
> > 
> > pr_err("%s: failed to register lookup for %s",
> > 
> > __func__, list->name);
> 
> its ok, but to me it looks more clear and precise inside if(){ },
> as its length and indentation is not much deep.
> If you really insist we can do it ?

Well, you can read the code as the CPU does - if you are not interested in 
the alias you can see instantly that you don't have to read this function 
any more, because it returns if alias is NULL.

And it's always good to have lower indentation level. :)

> >> + pr_err("%s: failed to register lookup
> >> for
> > 
> > %s",
> > 
> >> + __func__, list->name);
> >> + }
> >> +}
> >> 
> >> +struct samsung_pll_clock {
> >> + unsigned intid;
> >> + const char  *dev_name;
> >> + const char  *name;
> >> + const char  *parent_name;
> >> + unsigned long   flags;
> >> + const int   con_offset;
> >> + const int   lock_offset;
> > 
> > I don't see any point of having all those const qualifiers of non-
> > pointers. This makes the struct useless for creating and initializing
> > at runtime.
> 
> OK, will remove it.
> 
> >> + enum   

Re: [PATCH v6 2/7] clk: samsung: Define a common samsung_clk_register_pll()

2013-06-19 Thread Yadwinder Singh Brar
On Wed, Jun 19, 2013 at 10:24 PM, Tomasz Figa  wrote:
> Hi Yadwinder,
>
> Generally looks really good, but some comments inline.
>
> On Monday 10 of June 2013 18:54:14 Yadwinder Singh Brar wrote:
>> This patch defines a common samsung_clk_register_pll() and its migrating
>> the PLL35xx & PLL36xx to use it. Other samsung PLL can also be migrated
>> to it. It also adds exynos5250 & exynos5420 PLLs to unique id list of
>> clocks. Since pll2550 & pll35xx and pll2650 & pll36xx have exactly same
>> clk ops implementation, added pll2550 and pll2650 also.

>> +void __init samsung_clk_register_pll(struct samsung_pll_clock
>> *clk_list, +  unsigned int nr_pll, void __iomem
> *base)
>> +{
>> + struct samsung_clk_pll *pll;
>> + struct clk *clk;
>> + struct clk_init_data init;
>> + struct samsung_pll_clock *list = clk_list;
>> + int cnt;
>> +
>> + for (cnt = 0; cnt < nr_pll; cnt++, list++) {
>
> I'd suggest moving contents of this loop to a function like following?
>
> static int __init _samsung_clk_register_pll(struct samsung_pll_clock *pll,
> void __iomem *base)
>
> This will make the code less indented and so more readable.
>

Yes, will do it.

>> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
>> + if (!pll) {
>> + pr_err("%s: could not allocate pll clk %s\n",
>> + __func__, list->name);
>> + continue;
>> + }
>> +
>> + init.name = list->name;
>> + init.flags = list->flags;
>> + init.parent_names = &list->parent_name;
>> + init.num_parents = 1;
>> +
>> + switch (list->type) {
>> + /* clk_ops for 35xx and 2550 are similar */
>> + case pll_35xx:
>> + case pll_2550:
>> + init.ops = &samsung_pll35xx_clk_ops;
>> + break;
>> + /* clk_ops for 36xx and 2650 are similar */
>> + case pll_36xx:
>> + case pll_2650:
>> + init.ops = &samsung_pll36xx_clk_ops;
>> + break;
>> + default:
>> + pr_warn("%s: Unknown pll type for pll clk %s\n",
>> + __func__, list->name);
>> + }
>> +
>> + pll->hw.init = &init;
>> + pll->type = list->type;
>> + pll->lock_reg = base + list->lock_offset;
>> + pll->con_reg = base + list->con_offset;
>> +
>> + clk = clk_register(NULL, &pll->hw);
>> + if (IS_ERR(clk)) {
>> + pr_err("%s: failed to register pll clock %s\n",
>> + __func__, list->name);
>> + kfree(pll);
>> + continue;
>> + }
>> +
>> + samsung_clk_add_lookup(clk, list->id);
>> +
>> + if (list->alias)
>> + if (clk_register_clkdev(clk, list->alias,
>> + list->dev_name))
>
> What about
>
> if (!list->alias)
> return;
>
> ret = clk_register_clkdev(clk, list->alias, list-
>>dev_name);
> if (ret)
> pr_err("%s: failed to register lookup for %s",
> __func__, list->name);
>

its ok, but to me it looks more clear and precise inside if(){ },
as its length and indentation is not much deep.
If you really insist we can do it ?

>> + pr_err("%s: failed to register lookup for
> %s",
>> + __func__, list->name);
>> + }
>> +}

>> +struct samsung_pll_clock {
>> + unsigned intid;
>> + const char  *dev_name;
>> + const char  *name;
>> + const char  *parent_name;
>> + unsigned long   flags;
>> + const int   con_offset;
>> + const int   lock_offset;
>
> I don't see any point of having all those const qualifiers of non-
> pointers. This makes the struct useless for creating and initializing at
> runtime.
>

OK, will remove it.

>> + enumsamsung_pll_type type;
>
> IMHO the enum keyword shouldn't be separated from enum name like this.
>

Any specific reason?  Just to keep indentation same for all members, I
used tabs :).

> Otherwise the patch looks fine. Maybe it's a bit too big - things could be
> done a bit more gradually, like:
> 1) first add required structs and functions,
> 2) then move existing clock drivers to use the new API, possibly one patch
> per driver,
> 3) remove the old API.
>
> This would make the whole change easier to review and, in case of any
> regressions, easier to track down the problem.
>

OK, I will split it.

Thanks,
Yadwinder
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"

Re: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-19 Thread Mark Brown
On Sun, Jun 16, 2013 at 10:54:07PM +0200, Tomasz Figa wrote:
> One of the biggest roadblocks on the way of S3C64xx to DeviceTree support
> is its DMA driver, which is completely platform-specific and provides
> private API (s3c-dma), not even saying that its design is completely
> against multiplatform-awareness.

I tried to test this on my s3c64xx based system but it gave me a kernel
that didn't boot far enough to give console output (there's some early
init stuff that uses SPI...).  That said, I needed:

diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 210a893..0f49707 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -313,7 +313,7 @@ static int pl08x_request_mux(struct pl08x_dma_chan *plchan)
int ret;
 
if (plchan->mux_use++ == 0 && pd->get_signal) {
-   ret = pd->get_signal(plchan->cd);
+   ret = (pd->get_signal)(plchan->cd);
if (ret < 0) {
plchan->mux_use = 0;
return ret;

to get it to build which makes me suspect the compiler a bit as well...
the system has audio, SPI and MMC enabled.

I was applying this to -next, are there any other dependencies I need or
anything?


signature.asc
Description: Digital signature


Re: [RFC PATCH 5/5] ARM: Samsung: Remove MIPI PHY setup code

2013-06-19 Thread Sylwester Nawrocki
On 06/16/2013 10:52 PM, Kukjin Kim wrote:
> On 06/15/13 02:45, Sylwester Nawrocki wrote:
>> > Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
>> > DPHYs so we can remove now unused code at arch/arm/plat-samsung.
>
> If so, sounds good :)
> 
>> > In case there is any board file for S5PV210 platforms using MIPI
>> > CSIS/DSIM (not any upstream currently) it should use the generic
>> > PHY API to bind the PHYs to respective PHY consumer drivers.
>
> To be honest, I didn't test this on boards but if the working is fine, 
> please go ahead without RFC.

Thanks for review. I've tested it on Exynos4412 based board, and will
check also on Exynos4210 TRATS before posting the final version.
It seems to work fine, I just won't be able to test on any non-dt
platform (s5pv210), and there is currently no users of MIPI CSIS/DSIM
on s5pv210. Moreover this series depends on the generic PHY API,
perhaps it can be merged for 3.11.

[1] http://www.spinics.net/lists/arm-kernel/msg251232.html

Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-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 PATCH 3/5] video: exynos_dsi: Use generic PHY driver

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 19:10:52 Sylwester Nawrocki wrote:
> On 06/16/2013 11:15 PM, Tomasz Figa wrote:
> > On Friday 14 of June 2013 19:45:49 Sylwester Nawrocki wrote:
> >> > Use the generic PHY API instead of the platform callback to control
> >> > the MIPI DSIM DPHY.
> >> > 
> >> > Signed-off-by: Sylwester Nawrocki 
> >> > Signed-off-by: Kyungmin Park 
> >> > ---
> >> > 
> >> >  drivers/video/display/source-exynos_dsi.c |   36
> >> > 
> >> > + include/video/exynos_dsi.h
> >> > 
> >> > |5 
> >> >  
> >> >  2 files changed, 11 insertions(+), 30 deletions(-)
> > 
> > Yes, this is what I was really missing a lot while developing this
> > driver.
> > 
> > Definitely looks good! It's a shame we don't have this driver in
> > mainline yet ;)
> 
> Yes, I should have mentioned in the cover letter this patch depends
> on modified version of this [1] patch set of yours. I'll drop this
> patch and will update the driver staying in mainline now, but I won't
> be able to test it, on a non-dt platform.
> 
> I guess even some pre-eliminary display (panel) API would be helpful.
> The CDF development seems to have been stalled for some time. I wonder
> if we could first have something that works for limited set of devices
> and be extending it gradually, rather than living with zero support
> for displays on DT based ARM platforms.

Well, the problem is that once we define a binding for displays, we will 
have to keep support for this binding even if we decide to change 
something.

But as I discussed with Laurent and Alexandre at LinuxCon Japan, we should 
be able to reuse V4L2 bindings for our purposes, so someone just needs to 
code a proof of concept implementation that doesn't necessarily provide 
full functionality yet, but allows to make something work. Probably based 
on already posted RFC versions of CDF.

CCed Laurent and Alexandre, as they might be able to shed even more light 
on this.

Best regards,
Tomasz

> 
> [1] http://www.spinics.net/lists/linux-fbdev/msg09689.html
> 
> Regards,
> Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 7/7] clk: samsung: Add EPLL and VPLL freq table for exynos5250 SoC

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:19 Yadwinder Singh Brar wrote:
> Adds the EPLL and VPLL freq table for exynos5250 SoC.
> 
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-exynos5250.c |   42
> - drivers/clk/samsung/clk.h   
> |2 +
>  2 files changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c index 6881810..13e293e 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -493,6 +493,29 @@ static __initdata struct of_device_id
> ext_clk_match[] = { { },
>  };
> 
> +static __initdata struct samsung_pll_rate_table vpll_24mhz_tbl[] = {
> + /* sorted in descending order */
> + /* PLL_36XX_RATE(rate, m, p, s, k) */
> + PLL_36XX_RATE(26600, 266, 3, 3, 0),
> + /* Not in UM, but need for eDP on snow */
> + PLL_36XX_RATE(7050, 94, 2, 4, 0),
> + { },
> +};
> +
> +static __initdata struct samsung_pll_rate_table epll_24mhz_tbl[] = {
> + /* sorted in descending order */
> + /* PLL_36XX_RATE(rate, m, p, s, k) */
> + PLL_36XX_RATE(19200, 64, 2, 2, 0),
> + PLL_36XX_RATE(180633600, 90, 3, 2, 20762),
> + PLL_36XX_RATE(18000, 90, 3, 2, 0),
> + PLL_36XX_RATE(73728000, 98, 2, 4, 19923),
> + PLL_36XX_RATE(67737600, 90, 2, 4, 20762),
> + PLL_36XX_RATE(49152000, 98, 3, 4, 19923),
> + PLL_36XX_RATE(45158400, 90, 3, 4, 20762),
> + PLL_36XX_RATE(32768000, 131, 3, 5, 4719)
> + { },
> +};
> +
>  struct __initdata samsung_pll_clock exynos5250_plls[nr_plls] = {
>   [apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", 
APLL_LOCK,
> APLL_CON0, "fout_apll", NULL),
> @@ -506,14 +529,16 @@ struct __initdata samsung_pll_clock
> exynos5250_plls[nr_plls] = { CPLL_CON0, NULL),
>   [epll] = PLL(pll_36xx, fout_epll, "fout_epll", "fin_pll", 
EPLL_LOCK,
>   EPLL_CON0, NULL),
> - [vpll] = PLL(pll_36xx, fout_vpll, "fout_vpll", "fin_pll", 
VPLL_LOCK,
> - VPLL_CON0, NULL),
> + [vpll] = PLL(pll_36xx, fout_vpll, "fout_vpll", "mout_vpllsrc",
> + VPLL_LOCK, VPLL_CON0, NULL),

IMHO the parent should be fixed in separate patch, as this doesn't seem to 
be related strictly to adding rate table.

>  };
> 
>  /* register exynox5250 clocks */
>  void __init exynos5250_clk_init(struct device_node *np)
>  {
>   void __iomem *reg_base;
> + struct clk *vpllsrc;
> + unsigned long fin_pll_rate, mout_vpllsrc_rate = 0;
> 
>   if (np) {
>   reg_base = of_iomap(np, 0);
> @@ -531,6 +556,19 @@ void __init exynos5250_clk_init(struct device_node
> *np) ext_clk_match);
>   samsung_clk_register_mux(exynos5250_pll_pmux_clks,
>   ARRAY_SIZE(exynos5250_pll_pmux_clks));
> +
> + fin_pll_rate = _get_rate("fin_pll");
> +
> + if (fin_pll_rate == (24 * MHZ))

Nit: Unnecessary parentheses around 24 * MHZ.

> + exynos5250_plls[epll].rate_table = epll_24mhz_tbl;
> +
> + vpllsrc = __clk_lookup("mout_vpllsrc");
> + if (vpllsrc)
> + mout_vpllsrc_rate = clk_get_rate(vpllsrc);
> +
> + if (mout_vpllsrc_rate == (24 * MHZ))

Ditto.

> + exynos5250_plls[vpll].rate_table =  vpll_24mhz_tbl;
> +
>   samsung_clk_register_pll(exynos5250_plls, 
ARRAY_SIZE(exynos5250_plls),
> reg_base);
>   samsung_clk_register_fixed_rate(exynos5250_fixed_rate_clks,
> diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
> index 3e6501c..378bf98 100644
> --- a/drivers/clk/samsung/clk.h
> +++ b/drivers/clk/samsung/clk.h
> @@ -40,6 +40,8 @@ struct samsung_clock_alias {
>   .alias  = a,\
>   }
> 
> +#define MHZ (1000*1000)

Nit: (1000 * 1000)

Best regards,
Tomasz

> +
>  /**
>   * struct samsung_fixed_rate_clock: information about fixed-rate clock
>   * @id: platform specific id of the clock.
--
To unsubscribe from this list: send the line "unsubscribe linux-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 PATCH 3/5] video: exynos_dsi: Use generic PHY driver

2013-06-19 Thread Sylwester Nawrocki
On 06/16/2013 11:15 PM, Tomasz Figa wrote:
> On Friday 14 of June 2013 19:45:49 Sylwester Nawrocki wrote:
>> > Use the generic PHY API instead of the platform callback to control
>> > the MIPI DSIM DPHY.
>> > 
>> > Signed-off-by: Sylwester Nawrocki 
>> > Signed-off-by: Kyungmin Park 
>> > ---
>> >  drivers/video/display/source-exynos_dsi.c |   36
>> > + include/video/exynos_dsi.h   
>> > |5 
>> >  2 files changed, 11 insertions(+), 30 deletions(-)
>
> Yes, this is what I was really missing a lot while developing this driver.
> 
> Definitely looks good! It's a shame we don't have this driver in mainline 
> yet ;)

Yes, I should have mentioned in the cover letter this patch depends
on modified version of this [1] patch set of yours. I'll drop this
patch and will update the driver staying in mainline now, but I won't
be able to test it, on a non-dt platform.

I guess even some pre-eliminary display (panel) API would be helpful.
The CDF development seems to have been stalled for some time. I wonder
if we could first have something that works for limited set of devices
and be extending it gradually, rather than living with zero support
for displays on DT based ARM platforms.

[1] http://www.spinics.net/lists/linux-fbdev/msg09689.html

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


Re: [PATCH v6 6/7] clk: samsung: Reorder MUX registration for mout_vpllsrc

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:18 Yadwinder Singh Brar wrote:
> From: Vikas Sajjan 
> 
> While trying to get rate of "mout_vpllsrc" MUX (parent) for registering
> the "fout_vpll" (child), we found get rate was failing.
> 
> So this patch moves the mout_vpllsrc MUX out of the existing common list
> and registers the mout_vpllsrc MUX before the PLL registrations.
> 
> Reviewed-by: Tomasz Figa 
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-exynos5250.c |7 ++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c index 21f5491..6881810 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -228,6 +228,10 @@ struct samsung_fixed_factor_clock
> exynos5250_fixed_factor_clks[] __initdata = { FFACTOR(none,
> "fout_bplldiv2", "fout_bpll", 1, 2, 0),
>  };
> 
> +struct samsung_mux_clock exynos5250_pll_pmux_clks[] __initdata = {
> + MUX(none, "mout_vpllsrc", mout_vpllsrc_p, SRC_TOP2, 0, 1),
> +};
> +
>  struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
>   MUX(none, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
>   MUX(none, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1),
> @@ -235,7 +239,6 @@ struct samsung_mux_clock exynos5250_mux_clks[]
> __initdata = { MUX(none, "sclk_mpll", mout_mpll_p, SRC_CORE1, 8, 1),
>   MUX(none, "mout_bpll_fout", mout_bpll_fout_p, PLL_DIV2_SEL, 0, 1),
>   MUX(none, "sclk_bpll", mout_bpll_p, SRC_CDREX, 0, 1),
> - MUX(none, "mout_vpllsrc", mout_vpllsrc_p, SRC_TOP2, 0, 1),
>   MUX(none, "sclk_vpll", mout_vpll_p, SRC_TOP2, 16, 1),
>   MUX(none, "sclk_epll", mout_epll_p, SRC_TOP2, 12, 1),
>   MUX(none, "sclk_cpll", mout_cpll_p, SRC_TOP2, 8, 1),
> @@ -526,6 +529,8 @@ void __init exynos5250_clk_init(struct device_node
> *np) samsung_clk_of_register_fixed_ext(exynos5250_fixed_rate_ext_clks,
> ARRAY_SIZE(exynos5250_fixed_rate_ext_clks),
>   ext_clk_match);
> + samsung_clk_register_mux(exynos5250_pll_pmux_clks,
> + ARRAY_SIZE(exynos5250_pll_pmux_clks));
>   samsung_clk_register_pll(exynos5250_plls, 
ARRAY_SIZE(exynos5250_plls),
> reg_base);
>   samsung_clk_register_fixed_rate(exynos5250_fixed_rate_clks,

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

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


Re: [PATCH v6 5/7] clk: samsung: Add set_rate() clk_ops for PLL36xx

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:17 Yadwinder Singh Brar wrote:
> From: Vikas Sajjan 
> 
> This patch adds set_rate and round_rate clk_ops for PLL36xx
> 
> Reviewed-by: Tomasz Figa 
> Reviewed-by: Doug Anderson 
> Signed-off-by: Vikas Sajjan 
> ---
>  drivers/clk/samsung/clk-pll.c |   79
> - 1 files changed, 78
> insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-pll.c
> b/drivers/clk/samsung/clk-pll.c index e3e7f0c..2197004 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -160,6 +160,8 @@ static const struct clk_ops
> samsung_pll35xx_clk_min_ops = { /*
>   * PLL36xx Clock Type
>   */
> +/* Maximum lock time can be 3000 * PDIV cycles */
> +#define PLL36XX_LOCK_FACTOR(3000)
> 
>  #define PLL36XX_KDIV_MASK(0x)
>  #define PLL36XX_MDIV_MASK(0x1FF)
> @@ -168,6 +170,8 @@ static const struct clk_ops
> samsung_pll35xx_clk_min_ops = { #define PLL36XX_MDIV_SHIFT(16)
>  #define PLL36XX_PDIV_SHIFT   (8)
>  #define PLL36XX_SDIV_SHIFT   (0)
> +#define PLL36XX_KDIV_SHIFT   (0)
> +#define PLL36XX_LOCK_STAT_SHIFT  (29)
> 
>  static unsigned long samsung_pll36xx_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
> @@ -190,8 +194,78 @@ static unsigned long
> samsung_pll36xx_recalc_rate(struct clk_hw *hw, return (unsigned
> long)fvco;
>  }
> 
> +static inline bool samsung_pll36xx_mpk_change(
> + const struct samsung_pll_rate_table *rate, u32 pll_con0, u32 
pll_con1)
> +{
> + u32 old_mdiv, old_pdiv, old_kdiv;
> +
> + old_mdiv = (pll_con0 >> PLL36XX_MDIV_SHIFT) & PLL36XX_MDIV_MASK;
> + old_pdiv = (pll_con0 >> PLL36XX_PDIV_SHIFT) & PLL36XX_PDIV_MASK;
> + old_kdiv = (pll_con1 >> PLL36XX_KDIV_SHIFT) & PLL36XX_KDIV_MASK;
> +
> + return (rate->mdiv != old_mdiv || rate->pdiv != old_pdiv ||
> + rate->kdiv != old_kdiv);
> +}
> +
> +static int samsung_pll36xx_set_rate(struct clk_hw *hw, unsigned long
> drate, +  unsigned long parent_rate)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + u32 tmp, pll_con0, pll_con1;
> + const struct samsung_pll_rate_table *rate;
> +
> + rate = samsung_get_pll_settings(pll, drate);
> + if (!rate) {
> + pr_err("%s: Invalid rate : %lu for pll clk %s\n", 
__func__,
> + drate, __clk_get_name(hw->clk));
> + return -EINVAL;
> + }
> +
> + pll_con0 = __raw_readl(pll->con_reg);
> + pll_con1 = __raw_readl(pll->con_reg + 4);

Please define offset constants for these two registers.

Otherwise looks good.

Best regards,
Tomasz

> +
> + if (!(samsung_pll36xx_mpk_change(rate, pll_con0, pll_con1))) {
> + /* If only s change, change just s value only*/
> + pll_con0 &= ~(PLL36XX_SDIV_MASK << PLL36XX_SDIV_SHIFT);
> + pll_con0 |= (rate->sdiv << PLL36XX_SDIV_SHIFT);
> + __raw_writel(pll_con0, pll->con_reg);
> +
> + return 0;
> + }
> +
> + /* Set PLL lock time. */
> + __raw_writel(rate->pdiv * PLL36XX_LOCK_FACTOR, pll->lock_reg);
> +
> +  /* Change PLL PMS values */
> + pll_con0 &= ~((PLL36XX_MDIV_MASK << PLL36XX_MDIV_SHIFT) |
> + (PLL36XX_PDIV_MASK << PLL36XX_PDIV_SHIFT) |
> + (PLL36XX_SDIV_MASK << PLL36XX_SDIV_SHIFT));
> + pll_con0 |= (rate->mdiv << PLL36XX_MDIV_SHIFT) |
> + (rate->pdiv << PLL36XX_PDIV_SHIFT) |
> + (rate->sdiv << PLL36XX_SDIV_SHIFT);
> + __raw_writel(pll_con0, pll->con_reg);
> +
> + pll_con1 &= ~(PLL36XX_KDIV_MASK << PLL36XX_KDIV_SHIFT);
> + pll_con1 |= rate->kdiv << PLL36XX_KDIV_SHIFT;
> + __raw_writel(pll_con1, pll->con_reg + 4);
> +
> + /* wait_lock_time */
> + do {
> + cpu_relax();
> + tmp = __raw_readl(pll->con_reg);
> + } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
> +
> + return 0;
> +}
> +
>  static const struct clk_ops samsung_pll36xx_clk_ops = {
>   .recalc_rate = samsung_pll36xx_recalc_rate,
> + .set_rate = samsung_pll36xx_set_rate,
> + .round_rate = samsung_pll_round_rate,
> +};
> +
> +static const struct clk_ops samsung_pll36xx_clk_min_ops = {
> + .recalc_rate = samsung_pll36xx_recalc_rate,
>  };
> 
>  /*
> @@ -494,7 +568,10 @@ void __init samsung_clk_register_pll(struct
> samsung_pll_clock *clk_list, /* clk_ops for 36xx and 2650 are similar
> */
>   case pll_36xx:
>   case pll_2650:
> - init.ops = &samsung_pll36xx_clk_ops;
> + if (!pll->rate_table)
> + init.ops = &samsung_pll36xx_clk_min_ops;
> + else
> + init.ops = &samsung_pll36xx_clk_ops;
>   break;
>   default:
>   pr_warn("%s: Unknown pll type for pll clk %s\n",
--
To unsubscribe from this list: s

Re: [PATCH v6 1/7] clk: samsung: Introduce a common samsung_clk_pll struct

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:13 Yadwinder Singh Brar wrote:
> This patch unifies clk strutures used for PLL35xx & PLL36xx and
> adding an extra member lock_reg, so that common code can be factored
> out.
> 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-pll.c |   30 --
>  1 files changed, 12 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-pll.c
> b/drivers/clk/samsung/clk-pll.c index 89135f6..8224bde 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -13,6 +13,14 @@
>  #include "clk.h"
>  #include "clk-pll.h"
> 
> +struct samsung_clk_pll {
> + struct clk_hw   hw;
> + void __iomem*lock_reg;
> + void __iomem*con_reg;
> +};
> +
> +#define to_clk_pll(_hw) container_of(_hw, struct samsung_clk_pll, hw)
> +
>  /*
>   * PLL35xx Clock Type
>   */
> @@ -24,17 +32,10 @@
>  #define PLL35XX_PDIV_SHIFT  (8)
>  #define PLL35XX_SDIV_SHIFT  (0)
> 
> -struct samsung_clk_pll35xx {
> - struct clk_hw   hw;
> - const void __iomem  *con_reg;
> -};
> -
> -#define to_clk_pll35xx(_hw) container_of(_hw, struct
> samsung_clk_pll35xx, hw) -
>  static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
>  {
> - struct samsung_clk_pll35xx *pll = to_clk_pll35xx(hw);
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>   u32 mdiv, pdiv, sdiv, pll_con;
>   u64 fvco = parent_rate;
> 
> @@ -56,7 +57,7 @@ static const struct clk_ops samsung_pll35xx_clk_ops =
> { struct clk * __init samsung_clk_register_pll35xx(const char *name,
> const char *pname, const void __iomem *con_reg)
>  {
> - struct samsung_clk_pll35xx *pll;
> + struct samsung_clk_pll *pll;
>   struct clk *clk;
>   struct clk_init_data init;
> 
> @@ -100,17 +101,10 @@ struct clk * __init
> samsung_clk_register_pll35xx(const char *name, #define
> PLL36XX_PDIV_SHIFT(8)
>  #define PLL36XX_SDIV_SHIFT   (0)
> 
> -struct samsung_clk_pll36xx {
> - struct clk_hw   hw;
> - const void __iomem  *con_reg;
> -};
> -
> -#define to_clk_pll36xx(_hw) container_of(_hw, struct
> samsung_clk_pll36xx, hw) -
>  static unsigned long samsung_pll36xx_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
>  {
> - struct samsung_clk_pll36xx *pll = to_clk_pll36xx(hw);
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>   u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
>   u64 fvco = parent_rate;
> 
> @@ -135,7 +129,7 @@ static const struct clk_ops samsung_pll36xx_clk_ops
> = { struct clk * __init samsung_clk_register_pll36xx(const char *name,
> const char *pname, const void __iomem *con_reg)
>  {
> - struct samsung_clk_pll36xx *pll;
> + struct samsung_clk_pll *pll;
>   struct clk *clk;
>   struct clk_init_data init;

Looks good to me.

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

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


Re: [PATCH v6 4/7] clk: samsung: Add set_rate() clk_ops for PLL35xx

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:16 Yadwinder Singh Brar wrote:
> This patch add set_rate() and round_rate() for PLL35xx
> 
> Reviewed-by: Doug Anderson 
> Reviewed-by: Tomasz Figa 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-pll.c |  105
> - 1 files changed, 104
> insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-pll.c
> b/drivers/clk/samsung/clk-pll.c index b2088dd..e3e7f0c 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -24,16 +24,51 @@ struct samsung_clk_pll {
> 
>  #define to_clk_pll(_hw) container_of(_hw, struct samsung_clk_pll, hw)
> 
> +static const struct samsung_pll_rate_table *samsung_get_pll_settings(
> + struct samsung_clk_pll *pll, unsigned long 
rate)
> +{
> + const struct samsung_pll_rate_table  *rate_table = pll-
>rate_table;
> + int i;
> +
> + for (i = 0; i < pll->rate_count; i++) {
> + if (rate == rate_table[i].rate)
> + return &rate_table[i];
> + }
> +
> + return NULL;
> +}
> +
> +static long samsung_pll_round_rate(struct clk_hw *hw,
> + unsigned long drate, unsigned long *prate)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + const struct samsung_pll_rate_table *rate_table = pll->rate_table;
> + int i;
> +
> + /* Assumming rate_table is in descending order */
> + for (i = 0; i < pll->rate_count; i++) {
> + if (drate >= rate_table[i].rate)
> + return rate_table[i].rate;
> + }
> +
> + /* return minimum supported value */
> + return rate_table[i - 1].rate;
> +}
> +
>  /*
>   * PLL35xx Clock Type
>   */
> +/* Maximum lock time can be 270 * PDIV cycles */
> +#define PLL35XX_LOCK_FACTOR  (270)
> 
>  #define PLL35XX_MDIV_MASK   (0x3FF)
>  #define PLL35XX_PDIV_MASK   (0x3F)
>  #define PLL35XX_SDIV_MASK   (0x7)
> +#define PLL35XX_LOCK_STAT_MASK   (0x1)
>  #define PLL35XX_MDIV_SHIFT  (16)
>  #define PLL35XX_PDIV_SHIFT  (8)
>  #define PLL35XX_SDIV_SHIFT  (0)
> +#define PLL35XX_LOCK_STAT_SHIFT  (29)
> 
>  static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
> @@ -53,8 +88,73 @@ static unsigned long
> samsung_pll35xx_recalc_rate(struct clk_hw *hw, return (unsigned
> long)fvco;
>  }
> 
> +static inline bool samsung_pll35xx_mp_change(
> + const struct samsung_pll_rate_table *rate, u32 pll_con)
> +{
> + u32 old_mdiv, old_pdiv;
> +
> + old_mdiv = (pll_con >> PLL35XX_MDIV_SHIFT) & PLL35XX_MDIV_MASK;
> + old_pdiv = (pll_con >> PLL35XX_PDIV_SHIFT) & PLL35XX_PDIV_MASK;
> +
> + return (rate->mdiv != old_mdiv || rate->pdiv != old_pdiv);
> +}
> +
> +static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long
> drate, +  unsigned long prate)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + const struct samsung_pll_rate_table *rate;
> + u32 tmp;
> +
> + /* Get required rate settings from table */
> + rate = samsung_get_pll_settings(pll, drate);
> + if (!rate) {
> + pr_err("%s: Invalid rate : %lu for pll clk %s\n", 
__func__,
> + drate, __clk_get_name(hw->clk));
> + return -EINVAL;
> + }
> +
> + tmp = __raw_readl(pll->con_reg);
> +
> + if (!(samsung_pll35xx_mp_change(rate, tmp))) {
> + /* If only s change, change just s value only*/
> + tmp &= ~(PLL35XX_SDIV_MASK << PLL35XX_SDIV_SHIFT);
> + tmp |= rate->sdiv << PLL35XX_SDIV_SHIFT;
> + __raw_writel(tmp, pll->con_reg);
> +
> + return 0;
> + }
> +
> + /* Set PLL lock time. */
> + __raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
> + pll->lock_reg);
> +
> + /* Change PLL PMS values */
> + tmp &= ~((PLL35XX_MDIV_MASK << PLL35XX_MDIV_SHIFT) |
> + (PLL35XX_PDIV_MASK << PLL35XX_PDIV_SHIFT) |
> + (PLL35XX_SDIV_MASK << PLL35XX_SDIV_SHIFT));
> + tmp |= (rate->mdiv << PLL35XX_MDIV_SHIFT) |
> + (rate->pdiv << PLL35XX_PDIV_SHIFT) |
> + (rate->sdiv << PLL35XX_SDIV_SHIFT);
> + __raw_writel(tmp, pll->con_reg);
> +
> + /* wait_lock_time */
> + do {
> + cpu_relax();
> + tmp = __raw_readl(pll->con_reg);
> + } while (!(tmp & (PLL35XX_LOCK_STAT_MASK
> + << PLL35XX_LOCK_STAT_SHIFT)));
> + return 0;
> +}
> +
>  static const struct clk_ops samsung_pll35xx_clk_ops = {
>   .recalc_rate = samsung_pll35xx_recalc_rate,
> + .round_rate = samsung_pll_round_rate,
> + .set_rate = samsung_pll35xx_set_rate,
> +};
> +
> +static const struct clk_ops samsung_pll35xx_clk_min_ops = {
> + .recalc_rate = samsung_pll35xx_recalc_rate,
>  };
> 
>  /*
> @@ -386,7 +486,10 @@ void __i

Re: [PATCH v6 3/7] clk: samsung: Add support to register rate_table for samsung plls

2013-06-19 Thread Tomasz Figa
On Monday 10 of June 2013 18:54:15 Yadwinder Singh Brar wrote:
> 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.
> 
> Reviewed-by: Doug Anderson 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-exynos4.c|8 
>  drivers/clk/samsung/clk-exynos5250.c |   14 +++---
>  drivers/clk/samsung/clk-exynos5420.c |   22 +++---
>  drivers/clk/samsung/clk-pll.c|   22 --
>  drivers/clk/samsung/clk-pll.h|   27 +++
> drivers/clk/samsung/clk.h|   14 +-
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c index ba25a1b..ceee66c 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -997,13 +997,13 @@ static __initdata struct of_device_id
> ext_clk_match[] = {
> 
>  struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = {
>   [apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", 
APLL_LOCK,
> - APLL_CON0, "fout_apll"),
> + APLL_CON0, "fout_apll", NULL),
>   [mpll] = PLL_A(pll_35xx, fout_mpll, "fout_mpll", "fin_pll",
> - E4X12_MPLL_LOCK, E4X12_MPLL_CON0, "fout_mpll"),
> + E4X12_MPLL_LOCK, E4X12_MPLL_CON0, "fout_mpll", NULL),
>   [epll] = PLL_A(pll_36xx, fout_epll, "fout_epll", "fin_pll", 
EPLL_LOCK,
> - EPLL_CON0, "fout_epll"),
> + EPLL_CON0, "fout_epll", NULL),
>   [vpll] = PLL_A(pll_36xx, fout_vpll, "fout_vpll", "fin_pll", 
VPLL_LOCK,
> - VPLL_CON0, "fout_vpll"),
> + VPLL_CON0, "fout_vpll", NULL),
>  };
> 
>  /* register exynos4 clocks */
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c index dc6a700..21f5491 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -492,19 +492,19 @@ static __initdata struct of_device_id
> ext_clk_match[] = {
> 
>  struct __initdata samsung_pll_clock exynos5250_plls[nr_plls] = {
>   [apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", 
APLL_LOCK,
> - APLL_CON0, "fout_apll"),
> + APLL_CON0, "fout_apll", NULL),
>   [mpll] = PLL_A(pll_35xx, fout_mpll, "fout_mpll", "fin_pll", 
MPLL_LOCK,
> - MPLL_CON0, "fout_mpll"),
> + MPLL_CON0, "fout_mpll", NULL),
>   [bpll] = PLL(pll_35xx, fout_bpll, "fout_bpll", "fin_pll", 
BPLL_LOCK,
> - BPLL_CON0),
> + BPLL_CON0, NULL),
>   [gpll] = PLL(pll_35xx, fout_gpll, "fout_gpll", "fin_pll", 
GPLL_LOCK,
> - GPLL_CON0),
> + GPLL_CON0, NULL),
>   [cpll] = PLL(pll_35xx, fout_cpll, "fout_cpll", "fin_pll", 
CPLL_LOCK,
> - CPLL_CON0),
> + CPLL_CON0, NULL),
>   [epll] = PLL(pll_36xx, fout_epll, "fout_epll", "fin_pll", 
EPLL_LOCK,
> - EPLL_CON0),
> + EPLL_CON0, NULL),
>   [vpll] = PLL(pll_36xx, fout_vpll, "fout_vpll", "fin_pll", 
VPLL_LOCK,
> - VPLL_CON0),
> + VPLL_CON0, NULL),
>  };
> 
>  /* register exynox5250 clocks */
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c index 3ea6b4f..86dfc64 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -729,27 +729,27 @@ struct samsung_gate_clock exynos5420_gate_clks[]
> __initdata = {
> 
>  struct __initdata samsung_pll_clock exynos5420_plls[nr_plls] = {
>   [apll] = PLL(pll_2550, fout_apll, "fout_apll", "fin_pll", 
APLL_LOCK,
> - APLL_CON0),
> + APLL_CON0, NULL),
>   [cpll] = PLL(pll_2550, fout_mpll, "fout_mpll", "fin_pll", 
MPLL_LOCK,
> - MPLL_CON0),
> + MPLL_CON0, NULL),
>   [dpll] = PLL(pll_2550, fout_dpll, "fout_dpll", "fin_pll", 
DPLL_LOCK,
> - DPLL_CON0),
> + DPLL_CON0, NULL),
>   [epll] = PLL(pll_2650, fout_epll, "fout_epll", "fin_pll", 
EPLL_LOCK,
> - EPLL_CON0),
> + EPLL_CON0, NULL),
>   [rpll] = PLL(pll_2650, fout_rpll, "fout_rpll", "fin_pll", 
RPLL_LOCK,
> - RPLL_CON0),
> + RPLL_CON0, NULL),
>   [ipll] = PLL(pll_2550, fout_ipll, "fout_ipll", "fin_pll", 
IPLL_LOCK,
> - IPLL_CON0),
> + IPLL_CON0, NULL),
>   [spll] = PLL(pll_2550, fout_spll, "fout_spll", "fin_pll", 
SPLL_LOCK,
> - SPLL_CON0),
> + SPLL_CON0, NULL),
>   [vpll] = PLL(pll_2550, fout_vpll, "fout_vpll", "fin_pll", 
VPLL_LOCK,
> - VPLL_CON0),
> + VPLL_CON0, NULL),
>   [mpll] = PLL(pll_2550, fout_mpll, "fout_mpll", "fin_pll", 
MPLL_LOCK,
> - MPLL_CON0),
> + MPLL_CON0, NULL),
>   [bpll] = PLL(pll_2550, fout_bpll, "fo

Re: [PATCH v6 2/7] clk: samsung: Define a common samsung_clk_register_pll()

2013-06-19 Thread Tomasz Figa
Hi Yadwinder,

Generally looks really good, but some comments inline.

On Monday 10 of June 2013 18:54:14 Yadwinder Singh Brar wrote:
> This patch defines a common samsung_clk_register_pll() and its migrating
> the PLL35xx & PLL36xx to use it. Other samsung PLL can also be migrated
> to it. It also adds exynos5250 & exynos5420 PLLs to unique id list of
> clocks. Since pll2550 & pll35xx and pll2650 & pll36xx have exactly same
> clk ops implementation, added pll2550 and pll2650 also.
> 
> Signed-off-by: Yadwinder Singh Brar 
> ---
>  drivers/clk/samsung/clk-exynos4.c|   40 +++
>  drivers/clk/samsung/clk-exynos5250.c |   60 +++-
>  drivers/clk/samsung/clk-exynos5420.c |   86 +++---
>  drivers/clk/samsung/clk-pll.c|  132
> -- drivers/clk/samsung/clk-pll.h   
> |   11 ++-
>  drivers/clk/samsung/clk.h|   48 
>  6 files changed, 242 insertions(+), 135 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c index addc738..ba25a1b 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -17,7 +17,6 @@
>  #include 
> 
>  #include "clk.h"
> -#include "clk-pll.h"
> 
>  /* Exynos4 clock controller register offsets */
>  #define SRC_LEFTBUS  0x4200
> @@ -97,12 +96,14 @@
>  #define GATE_IP_PERIL0xc950
>  #define E4210_GATE_IP_PERIR  0xc960
>  #define GATE_BLOCK   0xc970
> +#define E4X12_MPLL_LOCK  0x10008
>  #define E4X12_MPLL_CON0  0x10108
>  #define SRC_DMC  0x10200
>  #define SRC_MASK_DMC 0x10300
>  #define DIV_DMC0 0x10500
>  #define DIV_DMC1 0x10504
>  #define GATE_IP_DMC  0x10900
> +#define APLL_LOCK0x14000
>  #define APLL_CON00x14100
>  #define E4210_MPLL_CON0  0x14108
>  #define SRC_CPU  0x14200
> @@ -121,6 +122,12 @@ enum exynos4_soc {
>   EXYNOS4X12,
>  };
> 
> +/* list of PLLs to be registered */
> +enum exynos4_plls {
> + apll, mpll, epll, vpll,
> + nr_plls /* number of PLLs */
> +};
> +
>  /*
>   * Let each supported clock get a unique id. This id is used to lookup
> the clock * for device tree based platforms. The clocks are categorized
> into three @@ -988,6 +995,17 @@ static __initdata struct of_device_id
> ext_clk_match[] = { {},
>  };
> 
> +struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = {
> + [apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", 
APLL_LOCK,
> + APLL_CON0, "fout_apll"),
> + [mpll] = PLL_A(pll_35xx, fout_mpll, "fout_mpll", "fin_pll",
> + E4X12_MPLL_LOCK, E4X12_MPLL_CON0, "fout_mpll"),
> + [epll] = PLL_A(pll_36xx, fout_epll, "fout_epll", "fin_pll", 
EPLL_LOCK,
> + EPLL_CON0, "fout_epll"),
> + [vpll] = PLL_A(pll_36xx, fout_vpll, "fout_vpll", "fin_pll", 
VPLL_LOCK,
> + VPLL_CON0, "fout_vpll"),
> +};
> +
>  /* register exynos4 clocks */
>  void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc
> exynos4_soc, void __iomem *reg_base, unsigned long xom) {
> @@ -1024,22 +1042,16 @@ void __init exynos4_clk_init(struct device_node
> *np, enum exynos4_soc exynos4_so reg_base + EPLL_CON0, pll_4600);
>   vpll = samsung_clk_register_pll46xx("fout_vpll", 
"mout_vpllsrc",
>   reg_base + VPLL_CON0, pll_4650c);
> +
> + samsung_clk_add_lookup(apll, fout_apll);
> + samsung_clk_add_lookup(mpll, fout_mpll);
> + samsung_clk_add_lookup(epll, fout_epll);
> + samsung_clk_add_lookup(vpll, fout_vpll);
>   } else {
> - apll = samsung_clk_register_pll35xx("fout_apll", 
"fin_pll",
> - reg_base + APLL_CON0);
> - mpll = samsung_clk_register_pll35xx("fout_mpll", 
"fin_pll",
> - reg_base + E4X12_MPLL_CON0);
> - epll = samsung_clk_register_pll36xx("fout_epll", 
"fin_pll",
> - reg_base + EPLL_CON0);
> - vpll = samsung_clk_register_pll36xx("fout_vpll", 
"fin_pll",
> - reg_base + VPLL_CON0);
> + samsung_clk_register_pll(exynos4_plls,
> + ARRAY_SIZE(exynos4_plls), 
reg_base);
>   }
> 
> - samsung_clk_add_lookup(apll, fout_apll);
> - samsung_clk_add_lookup(mpll, fout_mpll);
> - samsung_clk_add_lookup(epll, fout_epll);
> - samsung_clk_add_lookup(vpll, fout_vpll);
> -
>   samsung_clk_register_fixed_rate(exynos4_fixed_rate_clks,
>   ARRAY_SIZE(exynos4_fixed_rate_clks));
>   samsung_clk_register_mux(exynos4_mux_clks,
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c index 7c68850..dc6a700 100644
> --- a/drivers/clk/samsung/clk-

Re: [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs

2013-06-19 Thread Sylwester Nawrocki
Hi Tomasz,

On 06/16/2013 11:11 PM, Tomasz Figa wrote:
> Hi Sylwester,
> 
> Looks good, but I added some nitpicks inline.
> 
> On Friday 14 of June 2013 19:45:47 Sylwester Nawrocki wrote:
>> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
>> receiver and MIPI DSI transmitter DPHYs.
>>
>> Signed-off-by: Sylwester Nawrocki 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  .../bindings/phy/exynos-video-mipi-phy.txt |   16 ++
>>  drivers/phy/Kconfig|   10 ++
>>  drivers/phy/Makefile   |3 +-
>>  drivers/phy/exynos_video_mipi_phy.c|  166
>>  4 files changed, 194 insertions(+), 1 deletion(-)
>>  create mode 100644
>> Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt create
>> mode 100644 drivers/phy/exynos_video_mipi_phy.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
>> b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt new
>> file mode 100644
>> index 000..32311c89
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
>> @@ -0,0 +1,16 @@
>> +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
>> +-
>> +
>> +Required properties:
>> +- compatible : "samsung,-video-phy", currently most SoCs can
> 
> I don't like this  here. It sounds like any SoC name can be put 
> here. IMHO just listing all supported compatible values should be enough.

Hmm, OK, I'll simply put there the one compatible string supported now.

>> claim +  compatibility with the S5PV210 MIPI CSIS/DSIM PHY and thus
>> should use +  "samsung,s5pv210-video-phy";
>> +- reg : offset and length of the MIPI DPHY register set;
>> +- #phy-cells : from the generic phy bindings, must be 1;
>> +
>> +For "samsung,s5pv210-video-phy" compatible DPHYs the second cell in the
>> PHY +specifier identifies the DPHY and its meaning is as follows:
>> +  0 - MIPI CSIS 0,
>> +  1 - MIPI DSIM 0,
>> +  2 - MIPI CSIS 1,
>> +  3 - MIPI DSIM 1.
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 0764a54..d234e99 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -11,3 +11,13 @@ menuconfig GENERIC_PHY
>>devices present in the kernel. This layer will have the generic
>>API by which phy drivers can create PHY using the phy framework 
> and
>>phy users can obtain reference to the PHY.
>> +
>> +if GENERIC_PHY
>> +
>> +config EXYNOS_VIDEO_MIPI_PHY
>> +bool "S5P/EXYNOS MIPI CSI-2/DSI PHY driver"
>> +depends on OF
> 
> Hmm. Is this driver designed only for OF-enabled boards?

Yes, there seems currently to be no users of MIPI CSIS/DSIM in the mainline 
kernel among the non-dt platforms, so I initially focused on DT only. I will
rework this driver to make it usable on non-dt platforms, but I currently 
have not way to fully test it. I believe S5PV210 will get migrated to device
tree sooner than anyone needs the functionality this driver provides on 
non-dt, and S5PC100 seems to be forgotten anyway.

>> +help
>> +  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
>> +  S5P and EXYNOS SoCs.
>> +endif
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 9e9560f..b16f2c1 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -2,4 +2,5 @@
>>  # Makefile for the phy drivers.
>>  #
>>
>> -obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
>> +obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
>> +obj-$(CONFIG_EXYNOS_VIDEO_MIPI_PHY) += exynos_video_mipi_phy.o
>> diff --git a/drivers/phy/exynos_video_mipi_phy.c
>> b/drivers/phy/exynos_video_mipi_phy.c new file mode 100644
>> index 000..8d4976f
>> --- /dev/null
>> +++ b/drivers/phy/exynos_video_mipi_phy.c
>> @@ -0,0 +1,166 @@
>> +/*
>> + * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
>> + *
>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Sylwester Nawrocki 
>> + *
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* MIPI_PHYn_CONTROL register bit definitions */
>> +#define EXYNOS_MIPI_PHY_ENABLE  (1 << 0)
>> +#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
>> +#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
>> +#define EXYNOS_MIPI_PHY_RESET_MASK  (3 << 1)
>> +
>> +#define EXYNOS_MAX_VIDEO_PHYS   4
>> +
>> +struct exynos_video_phy {
>> +spinlock_t slock;
>> +struct phy *phys[EXYNOS_MAX_VIDEO_PHYS];
>> +void __iomem *regs;
>> +};
>> +
>> +/*
>> + * The @id argument specifies MIPI CSIS or DSIM PHY as follows:
>> + *  0 - MIPI CSIS 0
>> + *  1 - MIPI DSIM 0
>> + *  2 - MIPI CSIS 1
>> + *  3 - 

Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

2013-06-19 Thread Rahul Sharma
Thanks Mr. Kim,

I will post v4 with aforesaid change.

regards,
Rahul Sharma.

On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim  wrote:
> On 06/19/13 22:50, Kukjin Kim wrote:
>>
>> On 06/19/13 21:51, Rahul Sharma wrote:
>>>
>>> This patch renames the combatible strings for hdmi, mixer, ddc
>>> and hdmiphy. It follows the convention of using compatible string
>>> which represent the SoC in which the IP was added for the first
>>> time.
>>>
>>> Signed-off-by: Rahul Sharma
>>
>>
>> Acked-by: Kukjin Kim 
>>
>
> Just one nit in subject:
>
> [PATCH] ARM: dts: . for exynos5250
>
> Thanks,
>
> - Kukjin
>
>>> ---
>>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>>> b/arch/arm/boot/dts/cros5250-common.dtsi
>>> index 3f0239e..dc259e8b 100644
>>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>>> @@ -190,7 +190,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc@50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -224,7 +224,7 @@
>>> samsung,i2c-max-bus-freq =<378000>;
>>>
>>> hdmiphy@38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index 3e0c792..f320d7c 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -72,7 +72,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc@50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -102,7 +102,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiphy@38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 0673524..2f7763b 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -601,7 +601,7 @@
>>> };
>>>
>>> hdmi {
>>> - compatible = "samsung,exynos5-hdmi";
>>> + compatible = "samsung,exynos4212-hdmi";
>>> reg =<0x1453 0x7>;
>>> interrupts =<0 95 0>;
>>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
>>> @@ -611,7 +611,7 @@
>>> };
>>>
>>> mixer {
>>> - compatible = "samsung,exynos5-mixer";
>>> + compatible = "samsung,exynos5250-mixer";
>>> reg =<0x1445 0x1>;
>>> interrupts =<0 94 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] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Nicolas Pitre
On Wed, 19 Jun 2013, Tomasz Figa wrote:
> On Wednesday 19 of June 2013 20:26:50 Chander Kashyap wrote:
> > On 19 June 2013 19:58, Tomasz Figa  wrote:
> > > I mean, calculate register offset based on two parameters - cluster ID
> > > and> 
> > > CPU ID, like:
> > > ...
> > > 
> > > u32 mpidr = cpu_logical_map(cpu);
> > > u32 phys_cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > > 
> > > if (soc_is_exynos()) {
> > > 
> > > u32 cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > > 
> > > phys_cpu += EXYNOS_CPUS_PER_CLUSTER * cluster;
> > > 
> > > }
> > > 
> > > reg_base = S5P_ARM_CORE_CONFIGURATION(phys_cpu);
> > > __raw_writel(0, reg_base);
> > 
> > This does not seems to viable solution, as eg. clusterID for
> > exynos4210 is 0x9 and exynos 4412 is 0xa.
> 
> We don't need to consider cluster ID for any SoC that has just one cluster. 
> That's why there is the if (soc_is_exynos()) clause, where exynos 
> is the SoC that we support and has more clusters.
> 
> > But if we wass the cpu nodes
> > thru DT, the we can comfortably rely on the logical cpu number. Also
> > EXYNOS_CPUS_PER_CLUSTER can vary from cluster to cluster.
> 
> There is nothing that prevents you from specifying the CPUs in DT in 
> different order. Moreover, even if you specify them in correct order, there 
> is nothing that prevents you from using any of the listed CPUs as boot CPU, 
> which will get the logical ID of 0.

Relying on the logical CPU number to index into hardware related 
register space is wrong, please don't do that.

If the MPIDR allocation isn't linear then this cannot be used either.

The best solution is probably to add this reg_base as a property of each 
CPU node in DT, and extract it at boot time to stash it into an array 
which can be indexed with the logical CPU number afterwards.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-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: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Chander Kashyap
On 19 June 2013 20:31, Tomasz Figa  wrote:
> On Wednesday 19 of June 2013 20:26:50 Chander Kashyap wrote:
>> On 19 June 2013 19:58, Tomasz Figa  wrote:
>> > On Wednesday 19 of June 2013 19:25:27 Chander Kashyap wrote:
>> >> On 19 June 2013 19:19, Tomasz Figa  wrote:
>> >> > On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
>> >> >> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
>> >> >> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
>> >> >> > > On 18 June 2013 23:29, Kukjin Kim 
> wrote:
>> >> >> > > > On 06/19/13 02:45, Tomasz Figa wrote:
>> >> >> > > >> Ccing Arnd and Olof, because I forgot to add them to git
>> >> >> > > >> send-email...
>> >> >> > > >>
>> >> >> > > >> Sorry for the noise.
>> >> >> > > >>
>> >> >> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
>> >> >> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control
>> >> >> > > >>> further
>> >> >> > > >>> cores
>> >> >> > > >>> properly another registers must be used.
>> >> >> > > >>>
>> >> >> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions
>> >> >> > > >>> with
>> >> >> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers
>> >> >> > > >>> for
>> >> >> > > >>> specified core.
>> >> >> > > >>>
>> >> >> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
>> >> >> > > >>> currently
>> >> >> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
>> >> >> > > >>
>> >> >> > > >> Obviously this doesn't happen currently because of the if
>> >> >> > > >> (cpu
>> >> >> > > >> ==
>> >> >> > > >> 1),
>> >> >> > > >> but>
>> >> >> > > >
>> >> >> > > > Yes, not happened...and just note exynos5440 doesn't support
>> >> >> > > > hotplug :)
>> >> >> > > > so this is available on exynos4412 and added 5420.
>> >> >> > > >
>> >> >> > > >> if logical cpu1 turned out not to be physical cpu1, then it
>> >> >> > > >> would
>> >> >> > > >> crash.
>> >> >> > > >>
>> >> >> > > >> Best regards,
>> >> >> > > >> Tomasz
>> >> >> > > >>
>> >> >> > > >>> In addition,
>> >> >> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
>> >> >> > > >>> powers
>> >> >> > > >>> off
>> >> >> > > >>> secondary cores by default.
>> >> >> > > >
>> >> >> > > > I need to test on board about above...
>> >> >> > > >
>> >> >> > > >>> Cc: sta...@vger.kernel.org
>> >> >> > > >>> Signed-off-by: Tomasz Figa
>> >> >> > > >>> Signed-off-by: Kyungmin Park
>> >> >> > > >>> ---
>> >> >> > > >>>
>> >> >> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9
>> >> >> > > >>>   +
>> >> >> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10
>> >> >> > > >>>   +++---
>> >> >> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9
>> >> >> > > >>>   +
>> >> >> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
>> >> >> > > >>>
>> >> >> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
>> >> >> > > >>>

Re: [PATCH] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 20:26:50 Chander Kashyap wrote:
> On 19 June 2013 19:58, Tomasz Figa  wrote:
> > On Wednesday 19 of June 2013 19:25:27 Chander Kashyap wrote:
> >> On 19 June 2013 19:19, Tomasz Figa  wrote:
> >> > On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
> >> >> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
> >> >> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
> >> >> > > On 18 June 2013 23:29, Kukjin Kim  
wrote:
> >> >> > > > On 06/19/13 02:45, Tomasz Figa wrote:
> >> >> > > >> Ccing Arnd and Olof, because I forgot to add them to git
> >> >> > > >> send-email...
> >> >> > > >> 
> >> >> > > >> Sorry for the noise.
> >> >> > > >> 
> >> >> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
> >> >> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control
> >> >> > > >>> further
> >> >> > > >>> cores
> >> >> > > >>> properly another registers must be used.
> >> >> > > >>> 
> >> >> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions
> >> >> > > >>> with
> >> >> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers
> >> >> > > >>> for
> >> >> > > >>> specified core.
> >> >> > > >>> 
> >> >> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
> >> >> > > >>> currently
> >> >> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
> >> >> > > >> 
> >> >> > > >> Obviously this doesn't happen currently because of the if
> >> >> > > >> (cpu
> >> >> > > >> ==
> >> >> > > >> 1),
> >> >> > > >> but>
> >> >> > > > 
> >> >> > > > Yes, not happened...and just note exynos5440 doesn't support
> >> >> > > > hotplug :)
> >> >> > > > so this is available on exynos4412 and added 5420.
> >> >> > > > 
> >> >> > > >> if logical cpu1 turned out not to be physical cpu1, then it
> >> >> > > >> would
> >> >> > > >> crash.
> >> >> > > >> 
> >> >> > > >> Best regards,
> >> >> > > >> Tomasz
> >> >> > > >> 
> >> >> > > >>> In addition,
> >> >> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
> >> >> > > >>> powers
> >> >> > > >>> off
> >> >> > > >>> secondary cores by default.
> >> >> > > > 
> >> >> > > > I need to test on board about above...
> >> >> > > > 
> >> >> > > >>> Cc: sta...@vger.kernel.org
> >> >> > > >>> Signed-off-by: Tomasz Figa
> >> >> > > >>> Signed-off-by: Kyungmin Park
> >> >> > > >>> ---
> >> >> > > >>> 
> >> >> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9
> >> >> > > >>>   +
> >> >> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10
> >> >> > > >>>   +++---
> >> >> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9
> >> >> > > >>>   +
> >> >> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
> >> >> > > >>> 
> >> >> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
> >> >> > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943
> >> >> > > >>> 100644
> >> >> > > >>> --- a/arch/arm/mach-exynos/hotplug.c
> >> >> > > >>> +++ b/arch/arm/mach-exynos/hotplug.c
> >> >> > > >&

Re: [PATCH] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Chander Kashyap
On 19 June 2013 19:58, Tomasz Figa  wrote:
> On Wednesday 19 of June 2013 19:25:27 Chander Kashyap wrote:
>> On 19 June 2013 19:19, Tomasz Figa  wrote:
>> > On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
>> >> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
>> >> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
>> >> > > On 18 June 2013 23:29, Kukjin Kim  wrote:
>> >> > > > On 06/19/13 02:45, Tomasz Figa wrote:
>> >> > > >> Ccing Arnd and Olof, because I forgot to add them to git
>> >> > > >> send-email...
>> >> > > >>
>> >> > > >> Sorry for the noise.
>> >> > > >>
>> >> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
>> >> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control
>> >> > > >>> further
>> >> > > >>> cores
>> >> > > >>> properly another registers must be used.
>> >> > > >>>
>> >> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions with
>> >> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers
>> >> > > >>> for
>> >> > > >>> specified core.
>> >> > > >>>
>> >> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
>> >> > > >>> currently
>> >> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
>> >> > > >>
>> >> > > >> Obviously this doesn't happen currently because of the if (cpu
>> >> > > >> ==
>> >> > > >> 1),
>> >> > > >> but>
>> >> > > >
>> >> > > > Yes, not happened...and just note exynos5440 doesn't support
>> >> > > > hotplug :)
>> >> > > > so this is available on exynos4412 and added 5420.
>> >> > > >
>> >> > > >> if logical cpu1 turned out not to be physical cpu1, then it
>> >> > > >> would
>> >> > > >> crash.
>> >> > > >>
>> >> > > >> Best regards,
>> >> > > >> Tomasz
>> >> > > >>
>> >> > > >>> In addition,
>> >> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
>> >> > > >>> powers
>> >> > > >>> off
>> >> > > >>> secondary cores by default.
>> >> > > >
>> >> > > > I need to test on board about above...
>> >> > > >
>> >> > > >>> Cc: sta...@vger.kernel.org
>> >> > > >>> Signed-off-by: Tomasz Figa
>> >> > > >>> Signed-off-by: Kyungmin Park
>> >> > > >>> ---
>> >> > > >>>
>> >> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9 +
>> >> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10 +++---
>> >> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9 +
>> >> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
>> >> > > >>>
>> >> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
>> >> > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943 100644
>> >> > > >>> --- a/arch/arm/mach-exynos/hotplug.c
>> >> > > >>> +++ b/arch/arm/mach-exynos/hotplug.c
>> >> > > >>> @@ -93,10 +93,11 @@ static inline void
>> >> > > >>> cpu_leave_lowpower(void)
>> >> > > >>>
>> >> > > >>>   static inline void platform_do_lowpower(unsigned int cpu,
>> >> > > >>>   int
>> >> > > >>>
>> >> > > >>> *spurious) {
>> >> > > >>>
>> >> > > >>> for (;;) {
>> >> > > >>>
>> >> > > >>> +   void __iomem *reg_base;
>> >> > > >>> +   unsigned int phys_c

[PATCH] ARM: dts: Add basic dts for Exynos4412-based Trats 2 board

2013-06-19 Thread Tomasz Figa
This patch introduces device tree sources for Samsung Trats 2 board
based on Exynos4412 SoC.

Currently support includes:
 - eMMC,
 - main PMIC (max77686),
 - serial ports,
 - GPIO keys,
 - touchscreen.

Signed-off-by: Tomasz Figa 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/exynos4412-trats2.dts | 456 
 2 files changed, 457 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4412-trats2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1357510..8cdc7cc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4412-odroidx.dtb \
exynos4412-smdk4412.dtb \
exynos4412-origen.dtb \
+   exynos4412-trats2.dtb \
exynos5250-arndale.dtb \
exynos5440-sd5v1.dtb \
exynos5250-smdk5250.dtb \
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
new file mode 100644
index 000..056b835
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -0,0 +1,456 @@
+/*
+ * Samsung's Exynos4412 based Trats 2 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Trats 2 board which is based on
+ * Samsung's Exynos4412 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+#include "exynos4412.dtsi"
+
+/ {
+   model = "Samsung Trats 2 based on Exynos4412";
+   compatible = "samsung,trats2", "samsung,exynos4412";
+
+   memory {
+   reg =  <0x4000 0x4000>;
+   };
+
+   chosen {
+   bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 
rootwait earlyprintk panic=5";
+   };
+
+   firmware@0204F000 {
+   compatible = "samsung,secure-firmware";
+   reg = <0x0204F000 0x1000>;
+   };
+
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti", "fixed-clock";
+   clock-frequency = <0>;
+   };
+
+   xusbxti {
+   compatible = "samsung,clock-xusbxti", "fixed-clock";
+   clock-frequency = <2400>;
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vemmc_reg: regulator-0 {
+   compatible = "regulator-fixed";
+   regulator-name = "VMEM_VDD_2.8V";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   gpio = <&gpk0 2 0>;
+   enable-active-high;
+   };
+
+   /* More to come */
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   key-down {
+   interrupt-parent = <&gpj1>;
+   interrupts = <2 0>;
+   gpios = <&gpj1 2 1>;
+   linux,code = <114>;
+   label = "volume down";
+   debounce-interval = <10>;
+   };
+
+   key-up {
+   interrupt-parent = <&gpj1>;
+   interrupts = <1 0>;
+   gpios = <&gpj1 1 1>;
+   linux,code = <115>;
+   label = "volume up";
+   debounce-interval = <10>;
+   };
+
+   key-power {
+   interrupt-parent = <&gpx2>;
+   interrupts = <7 0>;
+   gpios = <&gpx2 7 1>;
+   linux,code = <116>;
+   label = "power";
+   debounce-interval = <10>;
+   gpio-key,wakeup;
+   };
+   };
+
+   i2c@1389 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-slave-addr = <0x10>;
+   samsung,i2c-max-bus-freq = <40>;
+   pinctrl-0 = <&i2c3_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   mms114-touchscreen@48 {
+   compatible = "melfas,mms114";
+   reg = <0x48>;
+   interrupt-parent = <&gpm2>;
+   interrupts = <3 2>;
+   x-size = <720>;
+   y-size = <1280>;
+   avdd-supply = <&ldo23_reg>;
+   vdd-supply = <&ldo24_reg>;
+   };
+   };
+
+   i2c@138D {
+   samsung,i

[GIT PULL 2/2] Samsung CLK update for v3.11

2013-06-19 Thread Kukjin Kim

Hi Arnd, Olof

This is updates for Samsung clks but some of them didn't get Mike's ack 
but I think, it should be fine and remained in mailing list long time.


Mike, if you have any objection on this branch, please let us know.

Just note, based on tags/exynos-dt-2 to avoid merge conflicts ;)

Thanks,
- Kukjin


The following changes since commit 5f13269130d6798571ffbd9d84dbef0950984c5b:

  ARM: dts: Set BUCK7 as always on for Origen board (2013-06-19 
00:41:56 +0900)


are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/samsung-clk-1


for you to fetch changes up to 765ab41132b24c9d40b11b2100ae7f01c19a64af:

  clk: exynos5440: Staticize local symbols (2013-06-19 23:29:59 +0900)


clk updates
- fix HDMI clock number for exynos5250
- add G3D clocks for exynos5250
- add TMU clocks for exynos4
- use static for local symbols for exynos clk


Arun Kumar K (2):
  Documentation: Fix HDMI clock number for exynos5250-clock
  clk: exynos5250: Add clocks for G3D

Sachin Kamat (4):
  clk: exynos4: Add clock entries for TMU
  clk: exynos4: Staticize local symbols
  clk: exynos5250: Staticize local symbols
  clk: exynos5440: Staticize local symbols

 .../devicetree/bindings/clock/exynos4-clock.txt|  1 +
 .../devicetree/bindings/clock/exynos5250-clock.txt |  3 ++-
 drivers/clk/samsung/clk-exynos4.c  | 28 
--
 drivers/clk/samsung/clk-exynos5250.c   | 26 
+---

 drivers/clk/samsung/clk-exynos5440.c   | 14 +--
 5 files changed, 43 insertions(+), 29 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL 1/2] Samsung EXYNOS5420 PINCTRL for v3.11

2013-06-19 Thread Kukjin Kim

The following changes since commit eff4e7c7f32a4e4be60b19b209ffab5cb430b385:

  ARM: EXYNOS: extend soft-reset support for EXYNOS5420 (2013-06-19 
04:09:37 +0900)


are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/soc-exynos5420-2


for you to fetch changes up to 983dbeb35f1543668b8f3b31a735bf2163f2b233:

  pinctrl: exynos: add exynos5420 SoC specific data (2013-06-19 
22:19:08 +0900)



based on tags/soc-exynos5420-1
- add pinctrl support for exynos5420


Leela Krishna Amudala (2):
  ARM: dts: add pinctrl support to EXYNOS5420
  pinctrl: exynos: add exynos5420 SoC specific data

 .../bindings/pinctrl/samsung-pinctrl.txt   |   1 +
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  | 680 
+

 arch/arm/boot/dts/exynos5420.dtsi  |  45 ++
 drivers/pinctrl/pinctrl-exynos.c   | 118 
 drivers/pinctrl/pinctrl-samsung.c  |   2 +
 drivers/pinctrl/pinctrl-samsung.h  |   1 +
 6 files changed, 847 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5420-pinctrl.dtsi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL 0/2] Samsung 3rd pull-request for v3.11

2013-06-19 Thread Kukjin Kim

Hi Arnd, Olof

This is 3rd pull-request for v3.11.

- pinctrl for exynos5420
- update exynos clock

Please see each tag in detail

If any problems, please kindly let me know.

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


Re: [PATCH] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 19:25:27 Chander Kashyap wrote:
> On 19 June 2013 19:19, Tomasz Figa  wrote:
> > On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
> >> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
> >> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
> >> > > On 18 June 2013 23:29, Kukjin Kim  wrote:
> >> > > > On 06/19/13 02:45, Tomasz Figa wrote:
> >> > > >> Ccing Arnd and Olof, because I forgot to add them to git
> >> > > >> send-email...
> >> > > >> 
> >> > > >> Sorry for the noise.
> >> > > >> 
> >> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
> >> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control
> >> > > >>> further
> >> > > >>> cores
> >> > > >>> properly another registers must be used.
> >> > > >>> 
> >> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions with
> >> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers
> >> > > >>> for
> >> > > >>> specified core.
> >> > > >>> 
> >> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
> >> > > >>> currently
> >> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
> >> > > >> 
> >> > > >> Obviously this doesn't happen currently because of the if (cpu
> >> > > >> ==
> >> > > >> 1),
> >> > > >> but>
> >> > > > 
> >> > > > Yes, not happened...and just note exynos5440 doesn't support
> >> > > > hotplug :)
> >> > > > so this is available on exynos4412 and added 5420.
> >> > > > 
> >> > > >> if logical cpu1 turned out not to be physical cpu1, then it
> >> > > >> would
> >> > > >> crash.
> >> > > >> 
> >> > > >> Best regards,
> >> > > >> Tomasz
> >> > > >> 
> >> > > >>> In addition,
> >> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
> >> > > >>> powers
> >> > > >>> off
> >> > > >>> secondary cores by default.
> >> > > > 
> >> > > > I need to test on board about above...
> >> > > > 
> >> > > >>> Cc: sta...@vger.kernel.org
> >> > > >>> Signed-off-by: Tomasz Figa
> >> > > >>> Signed-off-by: Kyungmin Park
> >> > > >>> ---
> >> > > >>> 
> >> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9 +
> >> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10 +++---
> >> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9 +
> >> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
> >> > > >>> 
> >> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
> >> > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943 100644
> >> > > >>> --- a/arch/arm/mach-exynos/hotplug.c
> >> > > >>> +++ b/arch/arm/mach-exynos/hotplug.c
> >> > > >>> @@ -93,10 +93,11 @@ static inline void
> >> > > >>> cpu_leave_lowpower(void)
> >> > > >>> 
> >> > > >>>   static inline void platform_do_lowpower(unsigned int cpu,
> >> > > >>>   int
> >> > > >>> 
> >> > > >>> *spurious) {
> >> > > >>> 
> >> > > >>> for (;;) {
> >> > > >>> 
> >> > > >>> +   void __iomem *reg_base;
> >> > > >>> +   unsigned int phys_cpu = cpu_logical_map(cpu);
> >> > > >>> 
> >> > > >>> -   /* make cpu1 to be turned off at next WFI
> >> > > >>> command
> >> > > >>> */
> >> > > >>> -   if (cpu == 1)
> >> > &

Re: [PATCH 1/3] clk: exynos4: Staticize local symbols

2013-06-19 Thread Kukjin Kim

On 06/17/13 12:14, Sachin Kamat wrote:

On 13 June 2013 21:06, Sachin Kamat  wrote:

On 11 June 2013 09:46, Sachin Kamat  wrote:

On 5 June 2013 17:44, Kukjin Kim  wrote:

Sachin Kamat wrote:


These symbols are used only in this file and hence should be
static.

Signed-off-by: Sachin Kamat
---
  drivers/clk/samsung/clk-exynos4.c |   26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
exynos4.c
index 7104669..26f2a85 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -339,24 +339,26 @@ PNAME(mout_user_aclk200_p4x12) = {"fin_pll",
"div_aclk200", };
  PNAME(mout_user_aclk266_gps_p4x12) = {"fin_pll", "div_aclk266_gps", };

  /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata
= {
+static struct
+samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata = {


Any reason to use double lines?


This is one of the ways to avoid exceeding 80 column limit.




   FRATE(xxti, "xxti", NULL, CLK_IS_ROOT, 0),
   FRATE(xusbxti, "xusbxti", NULL, CLK_IS_ROOT, 0),
  };


[...]


-struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata =
{
+static struct
+samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata = {


Same as above.


   FRATE(none, "sclk_usbphy1", NULL, CLK_IS_ROOT, 4800),
  };


[...]

Others look good to me,
Acked-by: Kukjin Kim

Mike, please pick this into the clk tree if you're ok.



Mike,
If you are taking this through your tree, please also take the below
patch [1] as it is dependent on this series.
[1] https://patchwork.kernel.org/patch/2469891/



Ping Mike..



Kukjin,

Haven't heard back from Mike regarding this. Can you please take this
through your tree?

OK, I will. BTW, Sachin, let me modify the line added static for 
regarding 80 columns...I think, just one like is better...


Anyway, Mike, if you have any objection, please kindly let me know 
before pulling into arm-soc tree.


Thanks,
- Kukjin


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


Re: [PATCH 0/7] Common Clock Framework support for Samsung S3C64xx

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 23:17:06 Kukjin Kim wrote:
> On 06/06/13 08:57, Tomasz Figa wrote:
> > This series is an attempt to move clock support on Samsung S3C64xx SoCs
> > to Common Clock Framework.
> 
> Looks good :)

Thanks.

> > First, support for PLL types present on S3C64xx SoCs is added to
> > Samsung
> > Common Clock Framework driver. Then the main clock driver for mentioned
> > SoCs is introduced. Further patches contain fixes for drivers to make
> > them compliant with CCF semantics, migration of platform code to use
> > the new clock driver and removal of old clock management code.
> > 
> > Depends on:
> >   - [PATCH 0/6] Samsung watchdog support clean-up
> >   
> > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus=
> > 18989
> >   
> >   - [PATCH 00/15] Final Samsung PWM support cleanup
> >   
> > http://www.spinics.net/lists/arm-kernel/msg248725.html
> 
> BTW, Tomasz, so how was going on above PWM patches?
> 

I have them ready now, but the PWM maintainer has some objections, which 
will hopefully be resolved soon.

Best regards,
Tomasz

> > On S3C6410-based Tiny6410 board (Mini6410-compatible):
> > 
> > Tested-by: Tomasz Figa
> > 
> > Tomasz Figa (7):
> >clk: samsung: pll: Add support for PLL6552 and PLL6553
> >clk: samsung: Add clock driver for S3C64xx SoCs
> >ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
> >ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
> >usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
> >ARM: s3c64xx: Migrate clock handling to Common Clock Framework
> >ARM: s3c64xx: Remove old clock management code
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs

2013-06-19 Thread Kukjin Kim

On 06/13/13 06:38, Tomasz Figa wrote:

[...]


Another thing is that it's unlikely for any new SoC from S3C64xx
series to show up, so basically the clock list is fixed.


Sure.  I can take this into clk-next along with patch #1, or if you
prefer:

Acked-by: Mike Turquette


Thanks.

IMHO with all the remaining platform patches in this series, it should go
through Samsung tree.



Mike, thanks for your ack. Let me take this whole series into samsung 
tree when ready for other dependencies like PWM...


- 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 0/7] Common Clock Framework support for Samsung S3C64xx

2013-06-19 Thread Kukjin Kim

On 06/06/13 08:57, Tomasz Figa wrote:

This series is an attempt to move clock support on Samsung S3C64xx SoCs
to Common Clock Framework.


Looks good :)


First, support for PLL types present on S3C64xx SoCs is added to Samsung
Common Clock Framework driver. Then the main clock driver for mentioned
SoCs is introduced. Further patches contain fixes for drivers to make them
compliant with CCF semantics, migration of platform code to use the new
clock driver and removal of old clock management code.

Depends on:
  - [PATCH 0/6] Samsung watchdog support clean-up
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus=18989
  - [PATCH 00/15] Final Samsung PWM support cleanup
http://www.spinics.net/lists/arm-kernel/msg248725.html


BTW, Tomasz, so how was going on above PWM patches?



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

Tested-by: Tomasz Figa

Tomasz Figa (7):
   clk: samsung: pll: Add support for PLL6552 and PLL6553
   clk: samsung: Add clock driver for S3C64xx SoCs
   ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
   ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
   usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
   ARM: s3c64xx: Migrate clock handling to Common Clock Framework
   ARM: s3c64xx: Remove old clock management code

--
To unsubscribe from this list: send the line "unsubscribe linux-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/5] clk/exynos5420: add clocks for hdmi subsystem

2013-06-19 Thread Kukjin Kim

On 06/19/13 13:04, Rahul Sharma wrote:

+ mike

Mike, I'm waiting for your reply on this. If you're OK, let me take this 
series on top of exynos5420 stuff in samsung tree.


Of course, if any concerns, please let me know.

Thanks,
- Kukjin


On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  wrote:

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

This set dependents on the following patches which add support for Exynos5420
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html

Rahul Sharma (5):
   clk/exynos5420: add sclk_hdmiphy to the list of special clocks
   clk/exynos5420: add gate clock for tv sysmmu
   clk/exynos5420: fix the order of parents of hdmi mux
   clk/exynos5420: add hdmi mux to change parents in hdmi driver
   clk/exynos5420: assign sclk_pixel id to pixel clock divider

  .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
  drivers/clk/samsung/clk-exynos5420.c |   18 +++---
  2 files changed, 18 insertions(+), 7 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


Re: [PATCH] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Chander Kashyap
On 19 June 2013 19:19, Tomasz Figa  wrote:
> On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
>> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
>> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
>> > > On 18 June 2013 23:29, Kukjin Kim  wrote:
>> > > > On 06/19/13 02:45, Tomasz Figa wrote:
>> > > >> Ccing Arnd and Olof, because I forgot to add them to git
>> > > >> send-email...
>> > > >>
>> > > >> Sorry for the noise.
>> > > >>
>> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
>> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control further
>> > > >>> cores
>> > > >>> properly another registers must be used.
>> > > >>>
>> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions with
>> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers for
>> > > >>> specified core.
>> > > >>>
>> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
>> > > >>> currently
>> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
>> > > >>
>> > > >> Obviously this doesn't happen currently because of the if (cpu ==
>> > > >> 1),
>> > > >> but>
>> > > >
>> > > > Yes, not happened...and just note exynos5440 doesn't support
>> > > > hotplug :)
>> > > > so this is available on exynos4412 and added 5420.
>> > > >
>> > > >> if logical cpu1 turned out not to be physical cpu1, then it would
>> > > >> crash.
>> > > >>
>> > > >> Best regards,
>> > > >> Tomasz
>> > > >>
>> > > >>> In addition,
>> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
>> > > >>> powers
>> > > >>> off
>> > > >>> secondary cores by default.
>> > > >
>> > > > I need to test on board about above...
>> > > >
>> > > >>> Cc: sta...@vger.kernel.org
>> > > >>> Signed-off-by: Tomasz Figa
>> > > >>> Signed-off-by: Kyungmin Park
>> > > >>> ---
>> > > >>>
>> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9 +
>> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10 +++---
>> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9 +
>> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
>> > > >>>
>> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
>> > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943 100644
>> > > >>> --- a/arch/arm/mach-exynos/hotplug.c
>> > > >>> +++ b/arch/arm/mach-exynos/hotplug.c
>> > > >>> @@ -93,10 +93,11 @@ static inline void cpu_leave_lowpower(void)
>> > > >>>
>> > > >>>   static inline void platform_do_lowpower(unsigned int cpu, int
>> > > >>>
>> > > >>> *spurious) {
>> > > >>>
>> > > >>> for (;;) {
>> > > >>>
>> > > >>> +   void __iomem *reg_base;
>> > > >>> +   unsigned int phys_cpu = cpu_logical_map(cpu);
>> > > >>>
>> > > >>> -   /* make cpu1 to be turned off at next WFI command
>> > > >>> */
>> > > >>> -   if (cpu == 1)
>> > > >>> -   __raw_writel(0,
>> > > >>> S5P_ARM_CORE1_CONFIGURATION);
>> > > >>> +   reg_base = S5P_ARM_CORE_CONFIGURATION(phys_cpu);
>> > >
>> > > Tomasz,
>> > > This will break for non-zero, MPIDR value.  Say if MPIDR is 1 then
>> > > for
>> > > cpu0 phys_cpu value will be 0x100,
>> > > and address calculation will be   (S5P_ARM_CORE0_CONFIGURATION +
>> > > ((0x101) * 0x80)), which is wrong.
>>
>> Honestly, I did not understand the reasoning above, please clarify.
>>
>> > Hmm, according to the code ini

Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

2013-06-19 Thread Kukjin Kim

On 06/19/13 22:50, Kukjin Kim wrote:

On 06/19/13 21:51, Rahul Sharma wrote:

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma


Acked-by: Kukjin Kim 



Just one nit in subject:

[PATCH] ARM: dts: . for exynos5250

Thanks,
- Kukjin


---
arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =<378000>;

hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};

hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg =<0x1453 0x7>;
interrupts =<0 95 0>;
clocks =<&clock 333>,<&clock 136>,<&clock 137>,
@@ -611,7 +611,7 @@
};

mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg =<0x1445 0x1>;
interrupts =<0 94 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 v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

2013-06-19 Thread Kukjin Kim

On 06/19/13 21:51, Rahul Sharma wrote:

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma


Acked-by: Kukjin Kim 

- Kukjin


---
  arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
  arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
  arch/arm/boot/dts/exynos5250.dtsi |4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiddc@50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =<378000>;

hdmiphy@38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiddc@50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =<66000>;

hdmiphy@38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};

hdmi {
-   compatible = "samsung,exynos5-hdmi";
+   compatible = "samsung,exynos4212-hdmi";
reg =<0x1453 0x7>;
interrupts =<0 95 0>;
clocks =<&clock 333>,<&clock 136>,<&clock 137>,
@@ -611,7 +611,7 @@
};

mixer {
-   compatible = "samsung,exynos5-mixer";
+   compatible = "samsung,exynos5250-mixer";
reg =<0x1445 0x1>;
interrupts =<0 94 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] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote:
> On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote:
> > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote:
> > > On 18 June 2013 23:29, Kukjin Kim  wrote:
> > > > On 06/19/13 02:45, Tomasz Figa wrote:
> > > >> Ccing Arnd and Olof, because I forgot to add them to git
> > > >> send-email...
> > > >> 
> > > >> Sorry for the noise.
> > > >> 
> > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote:
> > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control further
> > > >>> cores
> > > >>> properly another registers must be used.
> > > >>> 
> > > >>> This patch replaces S5P_ARM_CORE1_* register definitions with
> > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers for
> > > >>> specified core.
> > > >>> 
> > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which
> > > >>> currently
> > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off.
> > > >> 
> > > >> Obviously this doesn't happen currently because of the if (cpu ==
> > > >> 1),
> > > >> but>
> > > > 
> > > > Yes, not happened...and just note exynos5440 doesn't support
> > > > hotplug :)
> > > > so this is available on exynos4412 and added 5420.
> > > > 
> > > >> if logical cpu1 turned out not to be physical cpu1, then it would
> > > >> crash.
> > > >> 
> > > >> Best regards,
> > > >> Tomasz
> > > >> 
> > > >>> In addition,
> > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader
> > > >>> powers
> > > >>> off
> > > >>> secondary cores by default.
> > > > 
> > > > I need to test on board about above...
> > > > 
> > > >>> Cc: sta...@vger.kernel.org
> > > >>> Signed-off-by: Tomasz Figa
> > > >>> Signed-off-by: Kyungmin Park
> > > >>> ---
> > > >>> 
> > > >>>   arch/arm/mach-exynos/hotplug.c   |  9 +
> > > >>>   arch/arm/mach-exynos/include/mach/regs-pmu.h | 10 +++---
> > > >>>   arch/arm/mach-exynos/platsmp.c   |  9 +
> > > >>>   3 files changed, 17 insertions(+), 11 deletions(-)
> > > >>> 
> > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c
> > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943 100644
> > > >>> --- a/arch/arm/mach-exynos/hotplug.c
> > > >>> +++ b/arch/arm/mach-exynos/hotplug.c
> > > >>> @@ -93,10 +93,11 @@ static inline void cpu_leave_lowpower(void)
> > > >>> 
> > > >>>   static inline void platform_do_lowpower(unsigned int cpu, int
> > > >>> 
> > > >>> *spurious) {
> > > >>> 
> > > >>> for (;;) {
> > > >>> 
> > > >>> +   void __iomem *reg_base;
> > > >>> +   unsigned int phys_cpu = cpu_logical_map(cpu);
> > > >>> 
> > > >>> -   /* make cpu1 to be turned off at next WFI command
> > > >>> */
> > > >>> -   if (cpu == 1)
> > > >>> -   __raw_writel(0,
> > > >>> S5P_ARM_CORE1_CONFIGURATION);
> > > >>> +   reg_base = S5P_ARM_CORE_CONFIGURATION(phys_cpu);
> > > 
> > > Tomasz,
> > > This will break for non-zero, MPIDR value.  Say if MPIDR is 1 then
> > > for
> > > cpu0 phys_cpu value will be 0x100,
> > > and address calculation will be   (S5P_ARM_CORE0_CONFIGURATION +
> > > ((0x101) * 0x80)), which is wrong.
> 
> Honestly, I did not understand the reasoning above, please clarify.
> 
> > Hmm, according to the code initializing __cpu_logical_map[] array this
> > is not true.
> > 
> > Here's the code:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/a
> > rch/arm/kernel/setup.c?id=refs/tags/next-20130619#n468
> > 
> > and for used macros and bitmasks:
> > 
> > https://git.kernel.or

Re: [PATCH v2] clk: Exynos5250: Add clocks for G3D

2013-06-19 Thread Kukjin Kim

On 05/27/13 16:20, Arun Kumar K wrote:

This patch adds the required clocks for ARM Mali IP
in Exynos5250.

Signed-off-by: Arun Kumar K


(+ Mike)

Looks good to me.

Mike, I'd like take this into samsung tree for v3.11, if you have any 
concerns, please let me know.


Thanks,
- Kukjin


---
Changes from v1
- Removed exporting of parent DIV clock for g3d
   as per Tomsz Figa's comment.
---
  .../devicetree/bindings/clock/exynos5250-clock.txt |1 +
  drivers/clk/samsung/clk-exynos5250.c   |   12 +++-
  2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 1a05761..b3700cf 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -155,6 +155,7 @@ clock which they consume.
dp  342
mixer   343
hdmi344
+  g3d  345

  Example 1: An example of a clock controller node is listed below.

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 5c97e75..0d52c19 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -23,6 +23,7 @@
  #define DIV_CPU0  0x500
  #define SRC_CORE1 0x4204
  #define SRC_TOP0  0x10210
+#define SRC_TOP1   0x10214
  #define SRC_TOP2  0x10218
  #define SRC_GSCL  0x10220
  #define SRC_DISP1_0   0x1022c
@@ -55,6 +56,7 @@
  #define DIV_PERIC50x1056c
  #define GATE_IP_GSCL  0x10920
  #define GATE_IP_MFC   0x1092c
+#define GATE_IP_G3D0x10930
  #define GATE_IP_GEN   0x10934
  #define GATE_IP_FSYS  0x10944
  #define GATE_IP_PERIC 0x10950
@@ -98,7 +100,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g3d,

nr_clks,
  };
@@ -112,6 +114,7 @@ static __initdata unsigned long exynos5250_clk_regs[] = {
DIV_CPU0,
SRC_CORE1,
SRC_TOP0,
+   SRC_TOP1,
SRC_TOP2,
SRC_GSCL,
SRC_DISP1_0,
@@ -164,10 +167,12 @@ PNAME(mout_vpllsrc_p) = { "fin_pll", "sclk_hdmi27m" };
  PNAME(mout_vpll_p)= { "mout_vpllsrc", "fout_vpll" };
  PNAME(mout_cpll_p)= { "fin_pll", "fout_cpll" };
  PNAME(mout_epll_p)= { "fin_pll", "fout_epll" };
+PNAME(mout_gpll_p) = { "fin_pll", "fout_gpll" };
  PNAME(mout_mpll_user_p)   = { "fin_pll", "sclk_mpll" };
  PNAME(mout_bpll_user_p)   = { "fin_pll", "sclk_bpll" };
  PNAME(mout_aclk166_p) = { "sclk_cpll", "sclk_mpll_user" };
  PNAME(mout_aclk200_p) = { "sclk_mpll_user", "sclk_bpll_user" };
+PNAME(mout_aclk400_p)  = { "aclk_400_g3d_mid", "sclk_gpll" };
  PNAME(mout_hdmi_p)= { "div_hdmi_pixel", "sclk_hdmiphy" };
  PNAME(mout_usb3_p)= { "sclk_mpll_user", "sclk_cpll" };
  PNAME(mout_group1_p)  = { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -223,6 +228,9 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = 
{
MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+   MUX(none, "aclk_400_g3d_mid", mout_aclk200_p, SRC_TOP0, 20, 1),
+   MUX(none, "sclk_gpll", mout_gpll_p, SRC_TOP2, 28, 1),
+   MUX(none, "mout_aclk400", mout_aclk400_p, SRC_TOP1, 28, 1),
MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
@@ -262,6 +270,7 @@ struct samsung_div_clock exynos5250_div_clks[] __initdata = 
{
DIV(none, "aclk166", "mout_aclk166", DIV_TOP0, 8, 3),
DIV(none, "aclk333", "mout_aclk333", DIV_TOP0, 20, 3),
DIV(none, "aclk200", "mout_aclk200", DIV_TOP0, 12, 3),
+   DIV(none, "aclk_400_g3d", "mout_aclk400", DIV_TOP0, 24, 3),
DIV(none, "div_cam_bayer", "mout_cam_bayer", DIV_GSCL, 12, 4),
DIV(none, "div_cam0", "mout_cam0", DIV_GSCL, 16, 4),
DIV(none, "div_cam1", "mout_cam1", DIV_GSCL, 20, 4),
@@ -462,6 +471,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata 
= {
GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+   GATE(g3d, "g3d", "aclk_400_g3d", GATE_IP_G3D, 0, 0, 0),
  };

  static __initdata struct of_device_id ext_clk_match[]

Re: clk: Exynos5250: Fix HDMI clock number in documentation

2013-06-19 Thread Kukjin Kim

On 05/22/13 05:01, Doug Anderson wrote:

Arun,

On Tue, May 21, 2013 at 4:16 AM, Arun Kumar K  wrote:

This patch corrects the HDMI clock number given wrongly
in the documentation.

Signed-off-by: Arun Kumar K

---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Doug Anderson


Applied, thanks.

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


  1   2   >