Re: [PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Hi Bartlomiej,

Thanks for the comments.

On Thu, Jul 7, 2016 at 1:17 PM, Bartlomiej Zolnierkiewicz
<b.zolnier...@samsung.com> wrote:
>
> Hi
>
> On Thursday, July 07, 2016 12:45:57 PM Sylwester Nawrocki wrote:
>> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>> > Exynos7 has the same CPU clock registers layout as that present
>
> Please precise for which Exynos7 SoC this change is needed
> (all three of them?).

As mentioned in my recently posted PMU series, the exynos7 is a quad
core A57 based SoC and not meant to be a SoC family.
I have reviewed various exynos7xxx UMs in terms of the CPU CMU. Both
exynos7580 and exynos7420 have a similar CMU register layout along
with the same mux stat bits as exynos7. Exynos7870 on the other hand
is quite different.

Please let me know what naming convention you would prefer that I use
E7/E7420/E7580 ?

>
>> > in Exynos5433 except for the bits in the MUX_STAT* registers.
>> > Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.
>>
>> > --- a/drivers/clk/samsung/clk-cpu.h
>> > +++ b/drivers/clk/samsung/clk-cpu.h
>> > @@ -63,6 +63,8 @@ struct exynos_cpuclk {
>> >  /* The CPU clock registers have Exynos5433-compatible layout */
>> >  #define CLK_CPU_HAS_E5433_REGS_LAYOUT  (1 << 2)
>>
>> > +/* Exynos5433-compatible layout with different MUX_STAT register bits */
>> > +#define CLK_CPU_HAS_MODIFIED_MUX_STAT  (1 << 3)
>>
>> It's getting a bit messy, what if there comes another SoC version
>> which has some other modification of exynos5433 registers structure?
>> We would need another variant of HAS_MODIFIED_MUX_STAT flag and we
>> could easily get lost while trying to determine which modification
>> is which. How about indicating explicitly it's an exynos7 bits
>> layout and renaming the flag to something like
>>
>> #define CLK_CPU_HAS_E7_MUX_STAT   (1 << 16) ?
>
> ditto
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>

Re: [PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Hi Bartlomiej,

Thanks for the comments.

On Thu, Jul 7, 2016 at 1:17 PM, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi
>
> On Thursday, July 07, 2016 12:45:57 PM Sylwester Nawrocki wrote:
>> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>> > Exynos7 has the same CPU clock registers layout as that present
>
> Please precise for which Exynos7 SoC this change is needed
> (all three of them?).

As mentioned in my recently posted PMU series, the exynos7 is a quad
core A57 based SoC and not meant to be a SoC family.
I have reviewed various exynos7xxx UMs in terms of the CPU CMU. Both
exynos7580 and exynos7420 have a similar CMU register layout along
with the same mux stat bits as exynos7. Exynos7870 on the other hand
is quite different.

Please let me know what naming convention you would prefer that I use
E7/E7420/E7580 ?

>
>> > in Exynos5433 except for the bits in the MUX_STAT* registers.
>> > Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.
>>
>> > --- a/drivers/clk/samsung/clk-cpu.h
>> > +++ b/drivers/clk/samsung/clk-cpu.h
>> > @@ -63,6 +63,8 @@ struct exynos_cpuclk {
>> >  /* The CPU clock registers have Exynos5433-compatible layout */
>> >  #define CLK_CPU_HAS_E5433_REGS_LAYOUT  (1 << 2)
>>
>> > +/* Exynos5433-compatible layout with different MUX_STAT register bits */
>> > +#define CLK_CPU_HAS_MODIFIED_MUX_STAT  (1 << 3)
>>
>> It's getting a bit messy, what if there comes another SoC version
>> which has some other modification of exynos5433 registers structure?
>> We would need another variant of HAS_MODIFIED_MUX_STAT flag and we
>> could easily get lost while trying to determine which modification
>> is which. How about indicating explicitly it's an exynos7 bits
>> layout and renaming the flag to something like
>>
>> #define CLK_CPU_HAS_E7_MUX_STAT   (1 << 16) ?
>
> ditto
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>

Re: [PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Hi Sylwester,

On Thu, Jul 7, 2016 at 12:45 PM, Sylwester Nawrocki
<s.nawro...@samsung.com> wrote:
> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>> Exynos7 has the same CPU clock registers layout as that present
>> in Exynos5433 except for the bits in the MUX_STAT* registers.
>> Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.
>
>> --- a/drivers/clk/samsung/clk-cpu.h
>> +++ b/drivers/clk/samsung/clk-cpu.h
>> @@ -63,6 +63,8 @@ struct exynos_cpuclk {
>>  /* The CPU clock registers have Exynos5433-compatible layout */
>>  #define CLK_CPU_HAS_E5433_REGS_LAYOUT(1 << 2)
>
>> +/* Exynos5433-compatible layout with different MUX_STAT register bits */
>> +#define CLK_CPU_HAS_MODIFIED_MUX_STAT(1 << 3)
>
> It's getting a bit messy, what if there comes another SoC version
> which has some other modification of exynos5433 registers structure?
> We would need another variant of HAS_MODIFIED_MUX_STAT flag and we
> could easily get lost while trying to determine which modification
> is which. How about indicating explicitly it's an exynos7 bits
> layout and renaming the flag to something like
>
> #define CLK_CPU_HAS_E7_MUX_STAT (1 << 16) ?
Will rename the flag to make it SoC specific as per your suggestion.

Regards,
Abhilash

Re: [PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Hi Sylwester,

On Thu, Jul 7, 2016 at 12:45 PM, Sylwester Nawrocki
 wrote:
> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>> Exynos7 has the same CPU clock registers layout as that present
>> in Exynos5433 except for the bits in the MUX_STAT* registers.
>> Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.
>
>> --- a/drivers/clk/samsung/clk-cpu.h
>> +++ b/drivers/clk/samsung/clk-cpu.h
>> @@ -63,6 +63,8 @@ struct exynos_cpuclk {
>>  /* The CPU clock registers have Exynos5433-compatible layout */
>>  #define CLK_CPU_HAS_E5433_REGS_LAYOUT(1 << 2)
>
>> +/* Exynos5433-compatible layout with different MUX_STAT register bits */
>> +#define CLK_CPU_HAS_MODIFIED_MUX_STAT(1 << 3)
>
> It's getting a bit messy, what if there comes another SoC version
> which has some other modification of exynos5433 registers structure?
> We would need another variant of HAS_MODIFIED_MUX_STAT flag and we
> could easily get lost while trying to determine which modification
> is which. How about indicating explicitly it's an exynos7 bits
> layout and renaming the flag to something like
>
> #define CLK_CPU_HAS_E7_MUX_STAT (1 << 16) ?
Will rename the flag to make it SoC specific as per your suggestion.

Regards,
Abhilash

Re: [PATCH 1/2] soc: samsung: Change type of PMU configuration register value to u32

[Abhilash Kesavan]

Hi Krzysztof,

On Wed, Jul 6, 2016 at 8:47 AM, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On Tue, Jul 5, 2016 at 10:28 PM, Abhilash Kesavan <a.kesa...@samsung.com> 
> wrote:
>> Exynos7 has certain PMU registers that needs to be configured with
>> u32 values.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
>> ---
>>  drivers/soc/samsung/exynos-pmu.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/samsung/exynos-pmu.h 
>> b/drivers/soc/samsung/exynos-pmu.h
>> index a469e36..1bdc506 100644
>> --- a/drivers/soc/samsung/exynos-pmu.h
>> +++ b/drivers/soc/samsung/exynos-pmu.h
>> @@ -18,7 +18,7 @@
>>
>>  struct exynos_pmu_conf {
>> unsigned int offset;
>> -   u8 val[NUM_SYS_POWERDOWN];
>> +   unsigned int val[NUM_SYS_POWERDOWN];
>
> You mentioned u32 but I see unsigned int here. This should be u32.
Will change.
>
> BTW, none of your emails reached my samsung inbox. I got them only
> from the lists. Please investigate why this couldn't be delivered to
> samsung.com address.

Not quite sure why that happened even after I added you as a
recipient. I'll be posting some patches soon, let's see if the same
occurs again or if it was a one-off case.

Regards,
Abhilash
>
> Best regards,
> Krzysztof

Re: [PATCH 1/2] soc: samsung: Change type of PMU configuration register value to u32

[Abhilash Kesavan]

Hi Krzysztof,

On Wed, Jul 6, 2016 at 8:47 AM, Krzysztof Kozlowski
 wrote:
> On Tue, Jul 5, 2016 at 10:28 PM, Abhilash Kesavan  
> wrote:
>> Exynos7 has certain PMU registers that needs to be configured with
>> u32 values.
>>
>> Signed-off-by: Abhilash Kesavan 
>> ---
>>  drivers/soc/samsung/exynos-pmu.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/samsung/exynos-pmu.h 
>> b/drivers/soc/samsung/exynos-pmu.h
>> index a469e36..1bdc506 100644
>> --- a/drivers/soc/samsung/exynos-pmu.h
>> +++ b/drivers/soc/samsung/exynos-pmu.h
>> @@ -18,7 +18,7 @@
>>
>>  struct exynos_pmu_conf {
>> unsigned int offset;
>> -   u8 val[NUM_SYS_POWERDOWN];
>> +   unsigned int val[NUM_SYS_POWERDOWN];
>
> You mentioned u32 but I see unsigned int here. This should be u32.
Will change.
>
> BTW, none of your emails reached my samsung inbox. I got them only
> from the lists. Please investigate why this couldn't be delivered to
> samsung.com address.

Not quite sure why that happened even after I added you as a
recipient. I'll be posting some patches soon, let's see if the same
occurs again or if it was a one-off case.

Regards,
Abhilash
>
> Best regards,
> Krzysztof

Re: [PATCH v3 2/2] clk: samsung: exynos7: Add clocks for atlas block

[Abhilash Kesavan]

Hi Sylwester,

Thanks for the review.

On Thu, Jul 7, 2016 at 12:26 PM, Sylwester Nawrocki
<s.nawro...@samsung.com> wrote:
> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>
>> +static const struct samsung_pll_rate_table pll1450x_24mhz_tbl[] = {
>> + /* rate, m, p, s */
>> + PLL_35XX_RATE(249600, 208, 2, 0),
>
> Please add U postfix to these constants to address compiler warning
> as reported by kbuild-...@01.org:

I'll fix the warning.
>
>>> drivers/clk/samsung/clk-exynos7.c:43:2: warning: this decimal constant is
> unsigned only in ISO C90
>  PLL_35XX_RATE(249600, 208, 2, 0),
>  ^
>
>
>> +static void __init exynos7_clk_atlas_init(struct device_node *np)
>> +{
>> + void __iomem *reg_base;
>> + struct samsung_clk_provider *ctx;
>> +
>> + reg_base = of_iomap(np, 0);
>> + if (!reg_base) {
>> + panic("%s: failed to map registers\n", __func__);
>> + return;
>> + }
>> +
>> + ctx = samsung_clk_init(np, reg_base, ATLAS_NR_CLK);
>> + if (!ctx) {
>> + panic("%s: unable to allocate ctx\n", __func__);
>
> You can remove this panic() call, there is already one inside
> samsung_clk_init().

Will remove it.

Thanks,
Abhilash

Re: [PATCH 2/2] soc: samsung: Add support for Exynos7 PMU

[Abhilash Kesavan]

Hi Krzysztof,

[...]
>> diff --git a/drivers/soc/samsung/exynos-pmu.c 
>> b/drivers/soc/samsung/exynos-pmu.c
>> index 0acdfd8..7cda8fb 100644
>> --- a/drivers/soc/samsung/exynos-pmu.c
>> +++ b/drivers/soc/samsung/exynos-pmu.c
>> @@ -88,6 +88,9 @@ static const struct of_device_id 
>> exynos_pmu_of_device_ids[] = {
>> }, {
>> .compatible = "samsung,exynos5420-pmu",
>> .data = _pmu_data,
>> +   }, {
>> +   .compatible = "samsung,exynos7-pmu",
>> +   .data = _pmu_data,
>
> Hi,
>
> Thanks for the patch. Few comments:

Thanks for the review.
>
> You set here compatible for Exynos7. However there are at least three
> publicly known Exynos7 chipsets (7420, 7580, 7870 -
> https://en.wikipedia.org/wiki/Exynos). My questions are:
> 1. Are all of these share the same PMU configuration?
> 2. New different Exynos7 may be released, right?

Exynos7 is a Quad Core A57 based SoC that pre-dates all the above
mentioned SoCs. It is the closest to the exynos7420 in terms of the
IPs present. The PMU configuration between exynos7 and exynos7420 is
identical except for the extra A53 configuration required in case of
the 7420. The PMU configuration for 7580 and 7870 differ from that of
eynos7 and 7420 in terms of  the registers offsets, number of
registers being configured and some extra configurations. So, while
sharing of some functions is possible across the SoCs, each SoC should
ideally have its own PMU file. The posted patch adds PMU support for
only the exynos7 SoC.
>
> The exynos7 compatible is already spread all over DTS... but probably
> it is safer to use a specific SoC revision. Unless you are sure that
> all Exynos7 SoCs will be 100% compatible here and there won't be
> another exynos7xxx-pmu.
Please let me know if I can continue to use the exynos7 compatible
since it is a distinct SoC and not indicative of a series. However, if
you feel strongly about it then I can change the compatible to use
7420 since they are quite similar.
>
>
>> },
>> { /*sentinel*/ },
>>  };
[...]
>> +static void exynos7_pmu_init(void)
>> +{
>> +   unsigned int cpu;
>> +   unsigned int tmp, i;
>> +   struct device_node *node;
>> +   static void __iomem *atlas_cmu_base;
>
> 1. Why static?
> 2. This looks like used only in if() block below. Move it there so it
> will stay local to that block.

Will re-work as per your other comments below.
>
>> +
>> +/* Enable only SC_FEEDBACK for the register list */
>> +   for (i = 0 ; i < ARRAY_SIZE(exynos7_list_feed) ; i++) {
>> +   tmp = pmu_raw_readl(exynos7_list_feed[i]);
>> +   tmp &= ~EXYNOS5_USE_SC_COUNTER;
>> +   tmp |= EXYNOS5_USE_SC_FEEDBACK;
>> +   pmu_raw_writel(tmp, exynos7_list_feed[i]);
>> +   }
>> +
>> +   /*
>> +* Disable automatic L2 flush, Disable L2 retention and
>> +* Enable STANDBYWFIL2, ACE/ACP
>> +*/
>> +   tmp = pmu_raw_readl(EXYNOS7_ATLAS_L2_OPTION);
>> +   tmp &= ~(EXYNOS7_USE_AUTO_L2FLUSHREQ | EXYNOS7_USE_RETENTION);
>> +   tmp |= (EXYNOS7_USE_STANDBYWFIL2 |
>> +   EXYNOS7_USE_DEACTIVATE_ACE |
>> +   EXYNOS7_USE_DEACTIVATE_ACP);
>> +   pmu_raw_writel(tmp, EXYNOS7_ATLAS_L2_OPTION);
>> +
>> +   /*
>> +* Enable both SC_COUNTER and SC_FEEDBACK for the CPUs
>> +* Use STANDBYWFI and SMPEN to indicate that core is ready to enter
>> +* low power mode
>> +*/
>> +   for (cpu = 0; cpu < 4; cpu++) {
>
> '4' shouldn't be hardcoded here. num_possible_cpus()?

Will change.

[...]
>> +   /*
>> +* Set clock freeze cycle count to 0 before and after arm clamp or
>> +* reset signal transition
>> +*/
>> +   node = of_find_compatible_node(NULL, NULL,
>> +   "samsung,exynos7-clock-atlas");
>> +   if (node) {
>> +   atlas_cmu_base = of_iomap(node, 0);
>> +   if (!atlas_cmu_base)
>> +   return;
>> +
>> +   __raw_writel(0x0,
>> +   atlas_cmu_base + 
>> EXYNOS7_CORE_ARMCLK_STOPCTRL);
>> +   iounmap(atlas_cmu_base);
>
> Missing:
> of_node_put(node);
>
> ...but I think this creates unnecessary dependency on different
> compatible. I understand that disabling the EXTENDED_CLKSTOP is needed
> after configuring the PMU so this code belongs here. However
> everything you need is just a mapping of CMU address. The PMU driver
> should receive in bindings everything it needs to do its work. Either
> it is a phandle to something or an address for iomap. In this case the
> PMU should probably get two addresses: PMU and optionally CMU (part of
> CMU for example). Of course bindings would have to be updated.

I will add an optional CMU phandle to the PMU bindings.
>
>> +   }
>> +
>> +   pr_info("Exynos7 PMU has been initialized\n");
>> +}
>> +
>> +const struct exynos_pmu_data 

Re: [PATCH 2/2] soc: samsung: Add support for Exynos7 PMU

[Abhilash Kesavan]

Hi Krzysztof,

[...]
>> diff --git a/drivers/soc/samsung/exynos-pmu.c 
>> b/drivers/soc/samsung/exynos-pmu.c
>> index 0acdfd8..7cda8fb 100644
>> --- a/drivers/soc/samsung/exynos-pmu.c
>> +++ b/drivers/soc/samsung/exynos-pmu.c
>> @@ -88,6 +88,9 @@ static const struct of_device_id 
>> exynos_pmu_of_device_ids[] = {
>> }, {
>> .compatible = "samsung,exynos5420-pmu",
>> .data = _pmu_data,
>> +   }, {
>> +   .compatible = "samsung,exynos7-pmu",
>> +   .data = _pmu_data,
>
> Hi,
>
> Thanks for the patch. Few comments:

Thanks for the review.
>
> You set here compatible for Exynos7. However there are at least three
> publicly known Exynos7 chipsets (7420, 7580, 7870 -
> https://en.wikipedia.org/wiki/Exynos). My questions are:
> 1. Are all of these share the same PMU configuration?
> 2. New different Exynos7 may be released, right?

Exynos7 is a Quad Core A57 based SoC that pre-dates all the above
mentioned SoCs. It is the closest to the exynos7420 in terms of the
IPs present. The PMU configuration between exynos7 and exynos7420 is
identical except for the extra A53 configuration required in case of
the 7420. The PMU configuration for 7580 and 7870 differ from that of
eynos7 and 7420 in terms of  the registers offsets, number of
registers being configured and some extra configurations. So, while
sharing of some functions is possible across the SoCs, each SoC should
ideally have its own PMU file. The posted patch adds PMU support for
only the exynos7 SoC.
>
> The exynos7 compatible is already spread all over DTS... but probably
> it is safer to use a specific SoC revision. Unless you are sure that
> all Exynos7 SoCs will be 100% compatible here and there won't be
> another exynos7xxx-pmu.
Please let me know if I can continue to use the exynos7 compatible
since it is a distinct SoC and not indicative of a series. However, if
you feel strongly about it then I can change the compatible to use
7420 since they are quite similar.
>
>
>> },
>> { /*sentinel*/ },
>>  };
[...]
>> +static void exynos7_pmu_init(void)
>> +{
>> +   unsigned int cpu;
>> +   unsigned int tmp, i;
>> +   struct device_node *node;
>> +   static void __iomem *atlas_cmu_base;
>
> 1. Why static?
> 2. This looks like used only in if() block below. Move it there so it
> will stay local to that block.

Will re-work as per your other comments below.
>
>> +
>> +/* Enable only SC_FEEDBACK for the register list */
>> +   for (i = 0 ; i < ARRAY_SIZE(exynos7_list_feed) ; i++) {
>> +   tmp = pmu_raw_readl(exynos7_list_feed[i]);
>> +   tmp &= ~EXYNOS5_USE_SC_COUNTER;
>> +   tmp |= EXYNOS5_USE_SC_FEEDBACK;
>> +   pmu_raw_writel(tmp, exynos7_list_feed[i]);
>> +   }
>> +
>> +   /*
>> +* Disable automatic L2 flush, Disable L2 retention and
>> +* Enable STANDBYWFIL2, ACE/ACP
>> +*/
>> +   tmp = pmu_raw_readl(EXYNOS7_ATLAS_L2_OPTION);
>> +   tmp &= ~(EXYNOS7_USE_AUTO_L2FLUSHREQ | EXYNOS7_USE_RETENTION);
>> +   tmp |= (EXYNOS7_USE_STANDBYWFIL2 |
>> +   EXYNOS7_USE_DEACTIVATE_ACE |
>> +   EXYNOS7_USE_DEACTIVATE_ACP);
>> +   pmu_raw_writel(tmp, EXYNOS7_ATLAS_L2_OPTION);
>> +
>> +   /*
>> +* Enable both SC_COUNTER and SC_FEEDBACK for the CPUs
>> +* Use STANDBYWFI and SMPEN to indicate that core is ready to enter
>> +* low power mode
>> +*/
>> +   for (cpu = 0; cpu < 4; cpu++) {
>
> '4' shouldn't be hardcoded here. num_possible_cpus()?

Will change.

[...]
>> +   /*
>> +* Set clock freeze cycle count to 0 before and after arm clamp or
>> +* reset signal transition
>> +*/
>> +   node = of_find_compatible_node(NULL, NULL,
>> +   "samsung,exynos7-clock-atlas");
>> +   if (node) {
>> +   atlas_cmu_base = of_iomap(node, 0);
>> +   if (!atlas_cmu_base)
>> +   return;
>> +
>> +   __raw_writel(0x0,
>> +   atlas_cmu_base + 
>> EXYNOS7_CORE_ARMCLK_STOPCTRL);
>> +   iounmap(atlas_cmu_base);
>
> Missing:
> of_node_put(node);
>
> ...but I think this creates unnecessary dependency on different
> compatible. I understand that disabling the EXTENDED_CLKSTOP is needed
> after configuring the PMU so this code belongs here. However
> everything you need is just a mapping of CMU address. The PMU driver
> should receive in bindings everything it needs to do its work. Either
> it is a phandle to something or an address for iomap. In this case the
> PMU should probably get two addresses: PMU and optionally CMU (part of
> CMU for example). Of course bindings would have to be updated.

I will add an optional CMU phandle to the PMU bindings.
>
>> +   }
>> +
>> +   pr_info("Exynos7 PMU has been initialized\n");
>> +}
>> +
>> +const struct exynos_pmu_data 

Re: [PATCH v3 2/2] clk: samsung: exynos7: Add clocks for atlas block

[Abhilash Kesavan]

Hi Sylwester,

Thanks for the review.

On Thu, Jul 7, 2016 at 12:26 PM, Sylwester Nawrocki
 wrote:
> On 07/05/2016 10:29 PM, Abhilash Kesavan wrote:
>
>> +static const struct samsung_pll_rate_table pll1450x_24mhz_tbl[] = {
>> + /* rate, m, p, s */
>> + PLL_35XX_RATE(249600, 208, 2, 0),
>
> Please add U postfix to these constants to address compiler warning
> as reported by kbuild-...@01.org:

I'll fix the warning.
>
>>> drivers/clk/samsung/clk-exynos7.c:43:2: warning: this decimal constant is
> unsigned only in ISO C90
>  PLL_35XX_RATE(249600, 208, 2, 0),
>  ^
>
>
>> +static void __init exynos7_clk_atlas_init(struct device_node *np)
>> +{
>> + void __iomem *reg_base;
>> + struct samsung_clk_provider *ctx;
>> +
>> + reg_base = of_iomap(np, 0);
>> + if (!reg_base) {
>> + panic("%s: failed to map registers\n", __func__);
>> + return;
>> + }
>> +
>> + ctx = samsung_clk_init(np, reg_base, ATLAS_NR_CLK);
>> + if (!ctx) {
>> + panic("%s: unable to allocate ctx\n", __func__);
>
> You can remove this panic() call, there is already one inside
> samsung_clk_init().

Will remove it.

Thanks,
Abhilash

[PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Exynos7 has the same CPU clock registers layout as that present
in Exynos5433 except for the bits in the MUX_STAT* registers.
Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.

Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
---
 drivers/clk/samsung/clk-cpu.c | 10 --
 drivers/clk/samsung/clk-cpu.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index 8bf7e80..d40d740 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -322,7 +322,10 @@ static int exynos5433_cpuclk_pre_rate_change(struct 
clk_notifier_data *ndata,
/* select the alternate parent */
mux_reg = readl(base + E5433_MUX_SEL2);
writel(mux_reg | 1, base + E5433_MUX_SEL2);
-   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 2);
+   if (cpuclk->flags & CLK_CPU_HAS_MODIFIED_MUX_STAT)
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
+   else
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 2);
 
/* alternate parent is active now. set the dividers */
writel(div0, base + E5433_DIV_CPU0);
@@ -348,7 +351,10 @@ static int exynos5433_cpuclk_post_rate_change(struct 
clk_notifier_data *ndata,
/* select apll as the alternate parent */
mux_reg = readl(base + E5433_MUX_SEL2);
writel(mux_reg & ~1, base + E5433_MUX_SEL2);
-   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
+   if (cpuclk->flags & CLK_CPU_HAS_MODIFIED_MUX_STAT)
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 0);
+   else
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
 
exynos5433_set_safe_div(base, div, div_mask);
spin_unlock_irqrestore(cpuclk->lock, flags);
diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
index d4b6b51..b4d9a4b 100644
--- a/drivers/clk/samsung/clk-cpu.h
+++ b/drivers/clk/samsung/clk-cpu.h
@@ -63,6 +63,8 @@ struct exynos_cpuclk {
 #define CLK_CPU_NEEDS_DEBUG_ALT_DIV(1 << 1)
 /* The CPU clock registers have Exynos5433-compatible layout */
 #define CLK_CPU_HAS_E5433_REGS_LAYOUT  (1 << 2)
+/* Exynos5433-compatible layout with different MUX_STAT register bits */
+#define CLK_CPU_HAS_MODIFIED_MUX_STAT  (1 << 3)
 };
 
 extern int __init exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
-- 
1.9.1

[PATCH v3 1/2] clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks

[Abhilash Kesavan]

Exynos7 has the same CPU clock registers layout as that present
in Exynos5433 except for the bits in the MUX_STAT* registers.
Add a new CLK_CPU_HAS_MODIFIED_MUX_STAT flag to handle this change.

Signed-off-by: Abhilash Kesavan 
---
 drivers/clk/samsung/clk-cpu.c | 10 --
 drivers/clk/samsung/clk-cpu.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index 8bf7e80..d40d740 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -322,7 +322,10 @@ static int exynos5433_cpuclk_pre_rate_change(struct 
clk_notifier_data *ndata,
/* select the alternate parent */
mux_reg = readl(base + E5433_MUX_SEL2);
writel(mux_reg | 1, base + E5433_MUX_SEL2);
-   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 2);
+   if (cpuclk->flags & CLK_CPU_HAS_MODIFIED_MUX_STAT)
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
+   else
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 2);
 
/* alternate parent is active now. set the dividers */
writel(div0, base + E5433_DIV_CPU0);
@@ -348,7 +351,10 @@ static int exynos5433_cpuclk_post_rate_change(struct 
clk_notifier_data *ndata,
/* select apll as the alternate parent */
mux_reg = readl(base + E5433_MUX_SEL2);
writel(mux_reg & ~1, base + E5433_MUX_SEL2);
-   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
+   if (cpuclk->flags & CLK_CPU_HAS_MODIFIED_MUX_STAT)
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 0);
+   else
+   wait_until_mux_stable(base + E5433_MUX_STAT2, 0, 1);
 
exynos5433_set_safe_div(base, div, div_mask);
spin_unlock_irqrestore(cpuclk->lock, flags);
diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
index d4b6b51..b4d9a4b 100644
--- a/drivers/clk/samsung/clk-cpu.h
+++ b/drivers/clk/samsung/clk-cpu.h
@@ -63,6 +63,8 @@ struct exynos_cpuclk {
 #define CLK_CPU_NEEDS_DEBUG_ALT_DIV(1 << 1)
 /* The CPU clock registers have Exynos5433-compatible layout */
 #define CLK_CPU_HAS_E5433_REGS_LAYOUT  (1 << 2)
+/* Exynos5433-compatible layout with different MUX_STAT register bits */
+#define CLK_CPU_HAS_MODIFIED_MUX_STAT  (1 << 3)
 };
 
 extern int __init exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
-- 
1.9.1

[PATCH v3 2/2] clk: samsung: exynos7: Add clocks for atlas block

[Abhilash Kesavan]

CMU_ATLAS generates all the necessary clocks for the Cortex-A57
block. Enable clock support for this block, which includes:
- addition of mux/divider/gate/pll clocks
- addition of CPU clocks configuration data
- instantiation of the atlas CPU clock

Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
---
 .../devicetree/bindings/clock/exynos7-clock.txt|   6 +
 drivers/clk/samsung/clk-exynos7.c  | 183 +
 include/dt-bindings/clock/exynos7-clk.h|  21 ++-
 3 files changed, 209 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
index 6bf1e74..b94c0bc 100644
--- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -28,6 +28,7 @@ Required Properties for Clock Controller:
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
+   - "samsung,exynos7-clock-atlas"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
@@ -64,6 +65,11 @@ Input clocks for top1 clock controller:
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
 
+Input clocks for atlas clock controller:
+   - fin_pll
+   - fout_atlas_pll
+   - sclk_bus0_pll_atlas
+
 Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index 5931a41..63948c2 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -10,8 +10,10 @@
 
 #include 
 #include 
+#include 
 
 #include "clk.h"
+#include "clk-cpu.h"
 #include 
 
 /* Register Offset definitions for CMU_TOPC (0x1057) */
@@ -36,6 +38,34 @@
 #define ENABLE_ACLK_TOPC1  0x0804
 #define ENABLE_SCLK_TOPC1  0x0A04
 
+static const struct samsung_pll_rate_table pll1450x_24mhz_tbl[] = {
+   /* rate, m, p, s */
+   PLL_35XX_RATE(249600, 208, 2, 0),
+   PLL_35XX_RATE(24, 200, 2, 0),
+   PLL_35XX_RATE(230400, 192, 2, 0),
+   PLL_35XX_RATE(22, 275, 3, 0),
+   PLL_35XX_RATE(21, 175, 2, 0),
+   PLL_35XX_RATE(20, 250, 3, 0),
+   PLL_35XX_RATE(189600, 158, 2, 0),
+   PLL_35XX_RATE(18, 150, 2, 0),
+   PLL_35XX_RATE(170400, 142, 2, 0),
+   PLL_35XX_RATE(16, 200, 3, 0),
+   PLL_35XX_RATE(15, 250, 2, 1),
+   PLL_35XX_RATE(14, 350, 3, 1),
+   PLL_35XX_RATE(13, 325, 3, 1),
+   PLL_35XX_RATE(12, 200, 2, 1),
+   PLL_35XX_RATE(11, 275, 3, 1),
+   PLL_35XX_RATE(10, 250, 3, 1),
+   PLL_35XX_RATE(9, 150, 2, 1),
+   PLL_35XX_RATE(8, 200, 3, 1),
+   PLL_35XX_RATE(7, 350, 3, 2),
+   PLL_35XX_RATE(6, 200, 2, 2),
+   PLL_35XX_RATE(5, 250, 3, 2),
+   PLL_35XX_RATE(4, 200, 3, 2),
+   PLL_35XX_RATE(3, 200, 2, 3),
+   PLL_35XX_RATE(2, 200, 3, 3),
+};
+
 static const struct samsung_fixed_factor_clock topc_fixed_factor_clks[] 
__initconst = {
FFACTOR(0, "ffac_topc_bus0_pll_div2", "mout_topc_bus0_pll", 1, 2, 0),
FFACTOR(0, "ffac_topc_bus0_pll_div4",
@@ -52,6 +82,8 @@ PNAME(mout_topc_bus1_pll_ctrl_p)  = { "fin_pll", 
"fout_bus1_pll" };
 PNAME(mout_topc_cc_pll_ctrl_p) = { "fin_pll", "fout_cc_pll" };
 PNAME(mout_topc_mfc_pll_ctrl_p)= { "fin_pll", "fout_mfc_pll" };
 
+PNAME(mout_topc_group1)= { "mout_topc_bus0_pll", 
"ffac_topc_bus0_pll_div2",
+"mout_topc_bus1_pll", "mout_topc_cc_pll" };
 PNAME(mout_topc_group2) = { "mout_topc_bus0_pll_half",
"mout_topc_bus1_pll_half", "mout_topc_cc_pll_half",
"mout_topc_mfc_pll_half" };
@@ -111,6 +143,8 @@ static const struct samsung_mux_clock topc_mux_clks[] 
__initconst = {
MUX_SEL_TOPC1, 0, 1),
MUX(0, "mout_topc_bus0_pll_out", mout_topc_bus0_pll_out_p,
MUX_SEL_TOPC1, 16, 1),
+   MUX(0, "mout_topc_bus0_pll_atlas", mout_topc_group1,
+   MUX_SEL_TOPC1, 4, 2),
 
MUX(0, "mout_aclk_ccore_133", mout_topc_group2, MUX_SEL_TOPC2, 4, 2),
 
@@ -164,6 +198,9 @@ static const struct samsung_gate_clock topc_gate_clks[] 
__initconst = {
ENABLE_SCLK_TOPC1, 13, 0, 0),
GATE(SCLK_BUS1_PLL_A, "sclk_bus1_pll_a", "dout_sclk_bus1_pll",
ENABLE_SCLK_TOPC1, 12, 0, 0),
+   GATE(SCLK_BUS0_PLL_ATLAS, "sclk_bus0_pll_atlas",
+ 

[PATCH v3 2/2] clk: samsung: exynos7: Add clocks for atlas block

[Abhilash Kesavan]

CMU_ATLAS generates all the necessary clocks for the Cortex-A57
block. Enable clock support for this block, which includes:
- addition of mux/divider/gate/pll clocks
- addition of CPU clocks configuration data
- instantiation of the atlas CPU clock

Signed-off-by: Abhilash Kesavan 
---
 .../devicetree/bindings/clock/exynos7-clock.txt|   6 +
 drivers/clk/samsung/clk-exynos7.c  | 183 +
 include/dt-bindings/clock/exynos7-clk.h|  21 ++-
 3 files changed, 209 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
index 6bf1e74..b94c0bc 100644
--- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -28,6 +28,7 @@ Required Properties for Clock Controller:
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
+   - "samsung,exynos7-clock-atlas"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
@@ -64,6 +65,11 @@ Input clocks for top1 clock controller:
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
 
+Input clocks for atlas clock controller:
+   - fin_pll
+   - fout_atlas_pll
+   - sclk_bus0_pll_atlas
+
 Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index 5931a41..63948c2 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -10,8 +10,10 @@
 
 #include 
 #include 
+#include 
 
 #include "clk.h"
+#include "clk-cpu.h"
 #include 
 
 /* Register Offset definitions for CMU_TOPC (0x1057) */
@@ -36,6 +38,34 @@
 #define ENABLE_ACLK_TOPC1  0x0804
 #define ENABLE_SCLK_TOPC1  0x0A04
 
+static const struct samsung_pll_rate_table pll1450x_24mhz_tbl[] = {
+   /* rate, m, p, s */
+   PLL_35XX_RATE(249600, 208, 2, 0),
+   PLL_35XX_RATE(24, 200, 2, 0),
+   PLL_35XX_RATE(230400, 192, 2, 0),
+   PLL_35XX_RATE(22, 275, 3, 0),
+   PLL_35XX_RATE(21, 175, 2, 0),
+   PLL_35XX_RATE(20, 250, 3, 0),
+   PLL_35XX_RATE(189600, 158, 2, 0),
+   PLL_35XX_RATE(18, 150, 2, 0),
+   PLL_35XX_RATE(170400, 142, 2, 0),
+   PLL_35XX_RATE(16, 200, 3, 0),
+   PLL_35XX_RATE(15, 250, 2, 1),
+   PLL_35XX_RATE(14, 350, 3, 1),
+   PLL_35XX_RATE(13, 325, 3, 1),
+   PLL_35XX_RATE(12, 200, 2, 1),
+   PLL_35XX_RATE(11, 275, 3, 1),
+   PLL_35XX_RATE(10, 250, 3, 1),
+   PLL_35XX_RATE(9, 150, 2, 1),
+   PLL_35XX_RATE(8, 200, 3, 1),
+   PLL_35XX_RATE(7, 350, 3, 2),
+   PLL_35XX_RATE(6, 200, 2, 2),
+   PLL_35XX_RATE(5, 250, 3, 2),
+   PLL_35XX_RATE(4, 200, 3, 2),
+   PLL_35XX_RATE(3, 200, 2, 3),
+   PLL_35XX_RATE(2, 200, 3, 3),
+};
+
 static const struct samsung_fixed_factor_clock topc_fixed_factor_clks[] 
__initconst = {
FFACTOR(0, "ffac_topc_bus0_pll_div2", "mout_topc_bus0_pll", 1, 2, 0),
FFACTOR(0, "ffac_topc_bus0_pll_div4",
@@ -52,6 +82,8 @@ PNAME(mout_topc_bus1_pll_ctrl_p)  = { "fin_pll", 
"fout_bus1_pll" };
 PNAME(mout_topc_cc_pll_ctrl_p) = { "fin_pll", "fout_cc_pll" };
 PNAME(mout_topc_mfc_pll_ctrl_p)= { "fin_pll", "fout_mfc_pll" };
 
+PNAME(mout_topc_group1)= { "mout_topc_bus0_pll", 
"ffac_topc_bus0_pll_div2",
+"mout_topc_bus1_pll", "mout_topc_cc_pll" };
 PNAME(mout_topc_group2) = { "mout_topc_bus0_pll_half",
"mout_topc_bus1_pll_half", "mout_topc_cc_pll_half",
"mout_topc_mfc_pll_half" };
@@ -111,6 +143,8 @@ static const struct samsung_mux_clock topc_mux_clks[] 
__initconst = {
MUX_SEL_TOPC1, 0, 1),
MUX(0, "mout_topc_bus0_pll_out", mout_topc_bus0_pll_out_p,
MUX_SEL_TOPC1, 16, 1),
+   MUX(0, "mout_topc_bus0_pll_atlas", mout_topc_group1,
+   MUX_SEL_TOPC1, 4, 2),
 
MUX(0, "mout_aclk_ccore_133", mout_topc_group2, MUX_SEL_TOPC2, 4, 2),
 
@@ -164,6 +198,9 @@ static const struct samsung_gate_clock topc_gate_clks[] 
__initconst = {
ENABLE_SCLK_TOPC1, 13, 0, 0),
GATE(SCLK_BUS1_PLL_A, "sclk_bus1_pll_a", "dout_sclk_bus1_pll",
ENABLE_SCLK_TOPC1, 12, 0, 0),
+   GATE(SCLK_BUS0_PLL_ATLAS, "sclk_bus0_pll_atlas",
+   "mout_topc_bu

[PATCH v3 0/2] Add CPU clock support for Exynos7

[Abhilash Kesavan]

This patch set adds the atlas clock hierarchy on Exynos7. It also
modifies the existing cpu clock infrastructure to handle exynos7
differences. These patches are a pre-requisite for enabling CPUFreq
on Exynos7. This patchset has been tested on next-20160704. The
opp device tree changes, cpufreq-dt platform addition and defconfig
enablement will be sent separately.

Previous version of this patchset can be found here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322499.html

Changes since v2:
- All the dependencies have been merged
- Code is now based on exynos5433 cpu clock support

Abhilash Kesavan (2):
  clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks
  clk: samsung: exynos7: Add clocks for atlas block

 .../devicetree/bindings/clock/exynos7-clock.txt|   6 +
 drivers/clk/samsung/clk-cpu.c  |  10 +-
 drivers/clk/samsung/clk-cpu.h  |   2 +
 drivers/clk/samsung/clk-exynos7.c  | 183 +
 include/dt-bindings/clock/exynos7-clk.h|  21 ++-
 5 files changed, 219 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH v3 0/2] Add CPU clock support for Exynos7

[Abhilash Kesavan]

This patch set adds the atlas clock hierarchy on Exynos7. It also
modifies the existing cpu clock infrastructure to handle exynos7
differences. These patches are a pre-requisite for enabling CPUFreq
on Exynos7. This patchset has been tested on next-20160704. The
opp device tree changes, cpufreq-dt platform addition and defconfig
enablement will be sent separately.

Previous version of this patchset can be found here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322499.html

Changes since v2:
- All the dependencies have been merged
- Code is now based on exynos5433 cpu clock support

Abhilash Kesavan (2):
  clk: samsung: cpu: Prepare for addition for Exynos7 CPU clocks
  clk: samsung: exynos7: Add clocks for atlas block

 .../devicetree/bindings/clock/exynos7-clock.txt|   6 +
 drivers/clk/samsung/clk-cpu.c  |  10 +-
 drivers/clk/samsung/clk-cpu.h  |   2 +
 drivers/clk/samsung/clk-exynos7.c  | 183 +
 include/dt-bindings/clock/exynos7-clk.h|  21 ++-
 5 files changed, 219 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 2/2] soc: samsung: Add support for Exynos7 PMU

[Abhilash Kesavan]

Add initial PMU settings for exynos7. This is required for
future suspend-to-ram and cpuidle support.

Signed-off-by: Eunseok Choi <es10.c...@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
---
 drivers/soc/samsung/Kconfig |   2 +-
 drivers/soc/samsung/Makefile|   3 +-
 drivers/soc/samsung/exynos-pmu.c|   3 +
 drivers/soc/samsung/exynos-pmu.h|   2 +
 drivers/soc/samsung/exynos7-pmu.c   | 367 
 include/linux/soc/samsung/exynos-regs-pmu.h | 259 
 6 files changed, 634 insertions(+), 2 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos7-pmu.c

diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2455339..c57caea 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,7 +8,7 @@ if SOC_SAMSUNG
 
 config EXYNOS_PMU
bool "Exynos PMU controller driver" if COMPILE_TEST
-   depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
+   depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
 
 config EXYNOS_PM_DOMAINS
bool "Exynos PM domains" if COMPILE_TEST
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 3619f2e..5435525 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_EXYNOS_PMU)   += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
-   exynos5250-pmu.o exynos5420-pmu.o
+   exynos5250-pmu.o exynos5420-pmu.o \
+   exynos7-pmu.o
 obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 0acdfd8..7cda8fb 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -88,6 +88,9 @@ static const struct of_device_id exynos_pmu_of_device_ids[] = 
{
}, {
.compatible = "samsung,exynos5420-pmu",
.data = _pmu_data,
+   }, {
+   .compatible = "samsung,exynos7-pmu",
+   .data = _pmu_data,
},
{ /*sentinel*/ },
 };
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index 1bdc506..d559504 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -38,7 +38,9 @@ extern const struct exynos_pmu_data exynos4212_pmu_data;
 extern const struct exynos_pmu_data exynos4412_pmu_data;
 extern const struct exynos_pmu_data exynos5250_pmu_data;
 extern const struct exynos_pmu_data exynos5420_pmu_data;
+extern const struct exynos_pmu_data exynos7_pmu_data;
 
 extern void pmu_raw_writel(u32 val, u32 offset);
 extern u32 pmu_raw_readl(u32 offset);
+extern u32 exynos_get_eint_wake_mask(void);
 #endif /* __EXYNOS_PMU_H */
diff --git a/drivers/soc/samsung/exynos7-pmu.c 
b/drivers/soc/samsung/exynos7-pmu.c
new file mode 100644
index 000..f8635da
--- /dev/null
+++ b/drivers/soc/samsung/exynos7-pmu.c
@@ -0,0 +1,367 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS7 - CPU PMU (Power Management Unit) support
+ * Author: Abhilash Kesavan <a.kesa...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos7_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } } */
+   { EXYNOS7_ATLAS_CPU0_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU1_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU2_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU3_SYS_PWR_REG,   { 0x0, 0x0, 0x8 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CPUSEQ_SYS_PWR_

[PATCH 0/2] Add PMU support for Exynos7

[Abhilash Kesavan]

Add support for the Power Management Unit on Exynos7. These patches
have been tested on an Exynos7 espresso board (next-20160704).

Abhilash Kesavan (2):
  soc: samsung: Change type of PMU configuration register value to u32
  soc: samsung: Add support for Exynos7 PMU

 drivers/soc/samsung/Makefile|   3 +-
 drivers/soc/samsung/exynos-pmu.c|   3 +
 drivers/soc/samsung/exynos-pmu.h|   4 +-
 drivers/soc/samsung/exynos7-pmu.c   | 367 
 include/linux/soc/samsung/exynos-regs-pmu.h | 259 
 5 files changed, 634 insertions(+), 2 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos7-pmu.c

-- 
1.9.1

[PATCH 1/2] soc: samsung: Change type of PMU configuration register value to u32

[Abhilash Kesavan]

Exynos7 has certain PMU registers that needs to be configured with
u32 values.

Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
---
 drivers/soc/samsung/exynos-pmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index a469e36..1bdc506 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -18,7 +18,7 @@
 
 struct exynos_pmu_conf {
unsigned int offset;
-   u8 val[NUM_SYS_POWERDOWN];
+   unsigned int val[NUM_SYS_POWERDOWN];
 };
 
 struct exynos_pmu_data {
-- 
1.9.1

[PATCH 2/2] soc: samsung: Add support for Exynos7 PMU

[Abhilash Kesavan]

Add initial PMU settings for exynos7. This is required for
future suspend-to-ram and cpuidle support.

Signed-off-by: Eunseok Choi 
Signed-off-by: Abhilash Kesavan 
---
 drivers/soc/samsung/Kconfig |   2 +-
 drivers/soc/samsung/Makefile|   3 +-
 drivers/soc/samsung/exynos-pmu.c|   3 +
 drivers/soc/samsung/exynos-pmu.h|   2 +
 drivers/soc/samsung/exynos7-pmu.c   | 367 
 include/linux/soc/samsung/exynos-regs-pmu.h | 259 
 6 files changed, 634 insertions(+), 2 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos7-pmu.c

diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2455339..c57caea 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,7 +8,7 @@ if SOC_SAMSUNG
 
 config EXYNOS_PMU
bool "Exynos PMU controller driver" if COMPILE_TEST
-   depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
+   depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
 
 config EXYNOS_PM_DOMAINS
bool "Exynos PM domains" if COMPILE_TEST
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 3619f2e..5435525 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_EXYNOS_PMU)   += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
-   exynos5250-pmu.o exynos5420-pmu.o
+   exynos5250-pmu.o exynos5420-pmu.o \
+   exynos7-pmu.o
 obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 0acdfd8..7cda8fb 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -88,6 +88,9 @@ static const struct of_device_id exynos_pmu_of_device_ids[] = 
{
}, {
.compatible = "samsung,exynos5420-pmu",
.data = _pmu_data,
+   }, {
+   .compatible = "samsung,exynos7-pmu",
+   .data = _pmu_data,
},
{ /*sentinel*/ },
 };
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index 1bdc506..d559504 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -38,7 +38,9 @@ extern const struct exynos_pmu_data exynos4212_pmu_data;
 extern const struct exynos_pmu_data exynos4412_pmu_data;
 extern const struct exynos_pmu_data exynos5250_pmu_data;
 extern const struct exynos_pmu_data exynos5420_pmu_data;
+extern const struct exynos_pmu_data exynos7_pmu_data;
 
 extern void pmu_raw_writel(u32 val, u32 offset);
 extern u32 pmu_raw_readl(u32 offset);
+extern u32 exynos_get_eint_wake_mask(void);
 #endif /* __EXYNOS_PMU_H */
diff --git a/drivers/soc/samsung/exynos7-pmu.c 
b/drivers/soc/samsung/exynos7-pmu.c
new file mode 100644
index 000..f8635da
--- /dev/null
+++ b/drivers/soc/samsung/exynos7-pmu.c
@@ -0,0 +1,367 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS7 - CPU PMU (Power Management Unit) support
+ * Author: Abhilash Kesavan 
+ *
+ * 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 "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos7_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } } */
+   { EXYNOS7_ATLAS_CPU0_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU1_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU2_SYS_PWR_REG,   { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_CPU3_SYS_PWR_REG,   { 0x0, 0x0, 0x8 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CPUSEQ_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
+   { EXYNOS7_ATLAS_NONCPU_SYS_PWR_REG, { 0x0, 0

[PATCH 0/2] Add PMU support for Exynos7

[Abhilash Kesavan]

Add support for the Power Management Unit on Exynos7. These patches
have been tested on an Exynos7 espresso board (next-20160704).

Abhilash Kesavan (2):
  soc: samsung: Change type of PMU configuration register value to u32
  soc: samsung: Add support for Exynos7 PMU

 drivers/soc/samsung/Makefile|   3 +-
 drivers/soc/samsung/exynos-pmu.c|   3 +
 drivers/soc/samsung/exynos-pmu.h|   4 +-
 drivers/soc/samsung/exynos7-pmu.c   | 367 
 include/linux/soc/samsung/exynos-regs-pmu.h | 259 
 5 files changed, 634 insertions(+), 2 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos7-pmu.c

-- 
1.9.1

[PATCH 1/2] soc: samsung: Change type of PMU configuration register value to u32

[Abhilash Kesavan]

Exynos7 has certain PMU registers that needs to be configured with
u32 values.

Signed-off-by: Abhilash Kesavan 
---
 drivers/soc/samsung/exynos-pmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index a469e36..1bdc506 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -18,7 +18,7 @@
 
 struct exynos_pmu_conf {
unsigned int offset;
-   u8 val[NUM_SYS_POWERDOWN];
+   unsigned int val[NUM_SYS_POWERDOWN];
 };
 
 struct exynos_pmu_data {
-- 
1.9.1

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
 wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas 
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power 
>>> Management support v12")
>>> Signed-off-by: Javier Martinez Canillas 
>>> ---
>>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
>>> exynos5420_set_clksrc[] = {
>>> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>>> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>>> { .offset = SRC_MASK_ISP,   .value = 0x1000, },
>>> +   { .offset = GATE_BUS_TOP,   .value = 0x, },
>>> { .offset = GATE_BUS_DISP1, .value = 0x, },
>>> { .offset = GATE_IP_PERIC,  .value = 0x, },
>>>  };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.

Tested-by: Abhilash Kesavan .

Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
 wrote:
> Hello Tomasz,
>
> On 04/07/2015 02:46 PM, Tomasz Figa wrote:
>> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
>> :
>>> So I disabled the sss clock before trying a S2R:
>>>
>>> # devmem 0x10018800 32 0xFFFB
>>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>>
>>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>>> its default value on S2R so maybe that is why it works anyways?
>>
>> Does the driver restore its value on resume (i.e. has it in the
>> save/restore array)? Remember that suspend causes all clock registers
>> to be reset. Then some of them will be configured by the lowest
>
> No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
> the kernel after a suspend/resume cycle.
>
>> bootloader stage after wake-up reset, but the kernel needs to restore
>> all of them.
>>
>
> I see, thanks for the clarification. Then I think that is a bug and
> GATE_IP_G2D needs to be added to the list of clocks to be saved and
> restored right? That's a separate issue from our current S2R problem
> though so it can be done later as a separate patch.
>
>>>
>>> # devmem 0x10018800
>>> 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>>
>>> Does this shed any more light? Could the problem be that the sss
>>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>>> required for S2R or is just that CLK_SSS prevents the parent to
>>> be gated and so it is another red herring?
>>
>> Does the board use secure firmware? If yes, it might require to do
>> some encryption on suspend, so if the firmware is broken and doesn't
>> control the clock itself, it might need the SSS clock to be running,
>> when the SLEEP SMC operation is called.
>>
>
> No, the Chromebooks don't use secure firmware AFAIK.
>
>> Anyway, I just realized that Exynos4 also need several clocks to be
>> ungated on suspend and this is handled by code [1] based on arrays
>> [2].
>>
>> [1] 
>> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
>> [2] 
>> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>>
>
> Yes I noticed that the Exynos5420 driver also does the same but did not
> want to do it there because I didn't know what value should had been used
> for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
> your explanation right, it is safe to do so since the register is going to
> be reset to its default values anyways.
>
>> Could this method work for your case as well? There would be no need
>> to call any clock API at all, just low level register writes, which is
>> okay, since this is a low level driver anyway.
>>
>
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
>
>> Best regards,
>> Tomasz
>>
>
> Best regards,
> Javier
>
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas 
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
> support v12")
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
> exynos5420_set_clksrc[] = {
> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
> { .offset = SRC_MASK_PERIC1,.value

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas
 wrote:
> Hello Abhilash,
>
> On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
>> Hi,
>>
>> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
>>  wrote:
>>> Hello Sylwester,
>>>
>>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, 
>>>>>> it
>>>>>> would be good if we could get more information on that. They are in the 
>>>>>> PMU
>>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>>> subsystems/peripheral blocks exactly are associated with them it's not 
>>>>>> clear
>>>>>> from the documentation.
>>>>>
>>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>>
>>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>>
>>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>>> documentation I have. I guess you've got something newer than REV0.00?
>>>>
>>>
>>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>>
>>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>>> the same bits from 0 to 5 and then differ from there.
>>>
>>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>>> part of the PMU register address space.
>>>>>
>>>>> In the particular case of aclk266_g2d, the doc says that the clock can 
>>>>> only
>>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are 
>>>>> associated
>>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>>
>>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>>> the camera subsystem. Such a dependency would be rather surprising.
>>>>
>>>
>>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>>
>>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>>> error in the doc I've since is suspicious that is the only difference
>>> between LPI_MASK0 and CG_STATUS0.
>>>
>>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>>> registers, before we start checking their value in the clock driver.
>>>>>>
>>>>>
>>>>> Indeed, we should really understand what the status on these registers
>>>>> means. Also is not clear from the docs how much time should be waited,
>>>>> how long until giving up, etc.
>>>>
>>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>>> related to these registers yet, except the address macro definitions
>>>> and debug traces in the power domains driver.
>>>>
>>>
>>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>>
>>>>>> Also it might be that there are indeed some clocks which must stay 
>>>>>> enabled
>>>>>> over suspend/resume cycle, then the approach with enabling/disabling 
>>>>>> clocks
>>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>>
>>>>>
>>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>>> well but I didn't find a better way to solve this issue... another option
>>>>> is to have this wo

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Abhilash,

 On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
 Hi,

 On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 Hello Sylwester,

 On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
 On 01/04/15 13:44, Javier Martinez Canillas wrote:
 On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
 It's not clear what subsystems affect state of the CG_STATUSx registers, 
 it
 would be good if we could get more information on that. They are in the 
 PMU
 block and are related to LPI (Low Power Interface handshaking), but what
 subsystems/peripheral blocks exactly are associated with them it's not 
 clear
 from the documentation.

 Yes, I've been looking at the docs again and found out a couple of things:

 * Each GC_STATUSx register bit is associated with an IP hw block
 * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

 The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
 documentation I have. I guess you've got something newer than REV0.00?


 My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
 maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
 in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).

 GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
 the same bits from 0 to 5 and then differ from there.

 So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
 part of the PMU register address space.

 In the particular case of aclk266_g2d, the doc says that the clock can 
 only
 be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are 
 associated
 with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

 In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
 bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
 the camera subsystem. Such a dependency would be rather surprising.


 Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
 these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).

 As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
 have a corresponding bit in CG_STATUS0. But I don't know if that is an
 error in the doc I've since is suspicious that is the only difference
 between LPI_MASK0 and CG_STATUS0.

 I think it's essential to understand what triggers changes in CG_STATUSx
 registers, before we start checking their value in the clock driver.


 Indeed, we should really understand what the status on these registers
 means. Also is not clear from the docs how much time should be waited,
 how long until giving up, etc.

 Exactly, I checked some kernels from http://opensource.samsung.com
 (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
 related to these registers yet, except the address macro definitions
 and debug traces in the power domains driver.


 Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.

 Also it might be that there are indeed some clocks which must stay 
 enabled
 over suspend/resume cycle, then the approach with enabling/disabling 
 clocks
 in the clock driver might not be such a hack as it looks at first sight.


 Having a clock driver to both a provider and consumer feels hacky to me as
 well but I didn't find a better way to solve this issue... another option
 is to have this workaround to solve the S2R issue while we figure out what
 the the state in the CG_STATUSx really mean.

 Let's try to diagnose the issue best we can, then we would choose the most
 accurate bug fix.


 Sounds good to me.

 Based on the earlier comments I was trying to isolate if:
 1) s2r fails because we gate aclk266_g2d (but it is one of those
 clocks that needs to be always on prior to suspend).
 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
 are not 0 (thus not following the spec).


 Thanks a lot for continue looking at this. I didn't have time to dig
 deeper on this since last week.

 As I did not have access to the hardware guys who could possibly
 confirm 1), I decided to
 a) find a configuration where CG_STATUS0 allows gating of the
 aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
 b) disable the aclk266_g2d clock using such a configuration.
 c) check s2r.

 I found a configuration [1] which gave the following after boot-up:

 I think you forgot the reference for [1] right? Since with latest

Yes, looks like I missed that. There are the changes I had:

diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..3a9e21a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -379,6 +379,7 @@
#dma-cells = 1;
#dma

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Tomasz,

 On 04/07/2015 02:46 PM, Tomasz Figa wrote:
 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
 javier.marti...@collabora.co.uk:
 So I disabled the sss clock before trying a S2R:

 # devmem 0x10018800 32 0xFFFB
 (CLK_SSS in CLK_GATE_IP_G2D is gated)

 and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
 its default value on S2R so maybe that is why it works anyways?

 Does the driver restore its value on resume (i.e. has it in the
 save/restore array)? Remember that suspend causes all clock registers
 to be reset. Then some of them will be configured by the lowest

 No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
 the kernel after a suspend/resume cycle.

 bootloader stage after wake-up reset, but the kernel needs to restore
 all of them.


 I see, thanks for the clarification. Then I think that is a bug and
 GATE_IP_G2D needs to be added to the list of clocks to be saved and
 restored right? That's a separate issue from our current S2R problem
 though so it can be done later as a separate patch.


 # devmem 0x10018800
 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

 Does this shed any more light? Could the problem be that the sss
 clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
 required for S2R or is just that CLK_SSS prevents the parent to
 be gated and so it is another red herring?

 Does the board use secure firmware? If yes, it might require to do
 some encryption on suspend, so if the firmware is broken and doesn't
 control the clock itself, it might need the SSS clock to be running,
 when the SLEEP SMC operation is called.


 No, the Chromebooks don't use secure firmware AFAIK.

 Anyway, I just realized that Exynos4 also need several clocks to be
 ungated on suspend and this is handled by code [1] based on arrays
 [2].

 [1] 
 http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
 [2] 
 http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276


 Yes I noticed that the Exynos5420 driver also does the same but did not
 want to do it there because I didn't know what value should had been used
 for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
 your explanation right, it is safe to do so since the register is going to
 be reset to its default values anyways.

 Could this method work for your case as well? There would be no need
 to call any clock API at all, just low level register writes, which is
 okay, since this is a low level driver anyway.


 Yes, the following patch [0] is enough to make S2R working. If you think
 that is correct then I'll post it as a proper patch then.

 Best regards,
 Tomasz


 Best regards,
 Javier

 [0]
 From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
 From: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Date: Tue, 7 Apr 2015 15:53:27 +0200
 Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

 Commit ae43b3289186 (ARM: 8202/1: dmaengine: pl330: Add runtime Power
 Management support v12) added pm support for the pl330 dma driver but
 it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
 during suspend and this in turn makes its parent clock aclk266_g2d to
 be gated. But the clock needs to be ungated prior suspend to allow the
 system to be suspend and resumed correctly.

 Add GATE_BUS_TOP register to the list of registers to be restored when
 the system enters into a suspend state so aclk266_g2d will be ungated.

 Thanks to Abhilash Kesavan for figuring out that this was the issue.

 Fixes: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
 support v12)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/clk/samsung/clk-exynos5420.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 07d666cc6a29..bea4a173eef5 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
 exynos5420_set_clksrc[] = {
 { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
 { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
 { .offset = SRC_MASK_ISP,   .value = 0x1000, },
 +   { .offset = GATE_BUS_TOP,   .value = 0x, },
 { .offset = GATE_BUS_DISP1, .value = 0x, },
 { .offset = GATE_IP_PERIC,  .value = 0x, },
  };

While there could be a concern that we are ungating all the clocks in
BUS_TOP, this looks like the least intrusive fix for the issue. Tested
this on Peach Pi, S2R works fine.

Thanks,
Abhilash
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Abhilash,

 On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:

 [0]
 From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
 From: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Date: Tue, 7 Apr 2015 15:53:27 +0200
 Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

 Commit ae43b3289186 (ARM: 8202/1: dmaengine: pl330: Add runtime Power
 Management support v12) added pm support for the pl330 dma driver but
 it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
 during suspend and this in turn makes its parent clock aclk266_g2d to
 be gated. But the clock needs to be ungated prior suspend to allow the
 system to be suspend and resumed correctly.

 Add GATE_BUS_TOP register to the list of registers to be restored when
 the system enters into a suspend state so aclk266_g2d will be ungated.

 Thanks to Abhilash Kesavan for figuring out that this was the issue.

 Fixes: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power 
 Management support v12)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/clk/samsung/clk-exynos5420.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 07d666cc6a29..bea4a173eef5 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
 exynos5420_set_clksrc[] = {
 { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
 { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
 { .offset = SRC_MASK_ISP,   .value = 0x1000, },
 +   { .offset = GATE_BUS_TOP,   .value = 0x, },
 { .offset = GATE_BUS_DISP1, .value = 0x, },
 { .offset = GATE_IP_PERIC,  .value = 0x, },
  };

 While there could be a concern that we are ungating all the clocks in

 Yes, I mentioned that but OTOH it will be even more dangerous to gate
 clocks that should remain enabled so I used the register default values.

 BUS_TOP, this looks like the least intrusive fix for the issue. Tested
 this on Peach Pi, S2R works fine.


 Thanks a lot for testing, does it mean I can add your Tested-by then when
 posting it as a proper patch? I'll wait for Tomasz to comment before though.

Tested-by: Abhilash Kesavan a.kesa...@samsung.com.

Abhilash
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi,

On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
 wrote:
> Hello Sylwester,
>
> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
 It's not clear what subsystems affect state of the CG_STATUSx registers, it
 would be good if we could get more information on that. They are in the PMU
 block and are related to LPI (Low Power Interface handshaking), but what
 subsystems/peripheral blocks exactly are associated with them it's not 
 clear
 from the documentation.
>>>
>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>
>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>
>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>> documentation I have. I guess you've got something newer than REV0.00?
>>
>
> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>
> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
> the same bits from 0 to 5 and then differ from there.
>
>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>> part of the PMU register address space.
>>>
>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>
>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>> the camera subsystem. Such a dependency would be rather surprising.
>>
>
> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>
> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
> have a corresponding bit in CG_STATUS0. But I don't know if that is an
> error in the doc I've since is suspicious that is the only difference
> between LPI_MASK0 and CG_STATUS0.
>
 I think it's essential to understand what triggers changes in CG_STATUSx
 registers, before we start checking their value in the clock driver.

>>>
>>> Indeed, we should really understand what the status on these registers
>>> means. Also is not clear from the docs how much time should be waited,
>>> how long until giving up, etc.
>>
>> Exactly, I checked some kernels from http://opensource.samsung.com
>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>> related to these registers yet, except the address macro definitions
>> and debug traces in the power domains driver.
>>
>
> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>
 Also it might be that there are indeed some clocks which must stay enabled
 over suspend/resume cycle, then the approach with enabling/disabling clocks
 in the clock driver might not be such a hack as it looks at first sight.

>>>
>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>> well but I didn't find a better way to solve this issue... another option
>>> is to have this workaround to solve the S2R issue while we figure out what
>>> the the state in the CG_STATUSx really mean.
>>
>> Let's try to diagnose the issue best we can, then we would choose the most
>> accurate bug fix.
>>
>
> Sounds good to me.

Based on the earlier comments I was trying to isolate if:
1) s2r fails because we gate aclk266_g2d (but it is one of those
clocks that needs to be always on prior to suspend).
2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
are not 0 (thus not following the spec).

As I did not have access to the hardware guys who could possibly
confirm 1), I decided to
a) find a configuration where CG_STATUS0 allows gating of the
aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
b) disable the aclk266_g2d clock using such a configuration.
c) check s2r.

I found a configuration [1] which gave the following after boot-up:
# devmem 0x10040914
0xFD800014 (CG_STATUS0[22:21] is 0)
# devmem 0x10020700
0xC6F8DE9F (aclk266_g2d is enabled)

At this point s2r works.

I rebooted the board with the same config as above and then disabled
aclk266_g2d.

# devmem 0x10020700 32 0xC6F8DE9D
# devmem 0x10020700
0xC6F8DE9D (aclk266_g2d is disabled)
# devmem 0x10040914
0xFD800014

and tried s2r - It fails.

>From the results, disabling the clock seems to cause the issue rather
than the CG_STATUS violation. This is all a little confusing, so
please let me know if I have missed something.

Regards,

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi,

On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Sylwester,

 On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
 On 01/04/15 13:44, Javier Martinez Canillas wrote:
 On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
 It's not clear what subsystems affect state of the CG_STATUSx registers, it
 would be good if we could get more information on that. They are in the PMU
 block and are related to LPI (Low Power Interface handshaking), but what
 subsystems/peripheral blocks exactly are associated with them it's not 
 clear
 from the documentation.

 Yes, I've been looking at the docs again and found out a couple of things:

 * Each GC_STATUSx register bit is associated with an IP hw block
 * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

 The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
 documentation I have. I guess you've got something newer than REV0.00?


 My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
 maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
 in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).

 GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
 the same bits from 0 to 5 and then differ from there.

 So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
 part of the PMU register address space.

 In the particular case of aclk266_g2d, the doc says that the clock can only
 be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
 with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

 In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
 bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
 the camera subsystem. Such a dependency would be rather surprising.


 Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
 these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).

 As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
 have a corresponding bit in CG_STATUS0. But I don't know if that is an
 error in the doc I've since is suspicious that is the only difference
 between LPI_MASK0 and CG_STATUS0.

 I think it's essential to understand what triggers changes in CG_STATUSx
 registers, before we start checking their value in the clock driver.


 Indeed, we should really understand what the status on these registers
 means. Also is not clear from the docs how much time should be waited,
 how long until giving up, etc.

 Exactly, I checked some kernels from http://opensource.samsung.com
 (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
 related to these registers yet, except the address macro definitions
 and debug traces in the power domains driver.


 Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.

 Also it might be that there are indeed some clocks which must stay enabled
 over suspend/resume cycle, then the approach with enabling/disabling clocks
 in the clock driver might not be such a hack as it looks at first sight.


 Having a clock driver to both a provider and consumer feels hacky to me as
 well but I didn't find a better way to solve this issue... another option
 is to have this workaround to solve the S2R issue while we figure out what
 the the state in the CG_STATUSx really mean.

 Let's try to diagnose the issue best we can, then we would choose the most
 accurate bug fix.


 Sounds good to me.

Based on the earlier comments I was trying to isolate if:
1) s2r fails because we gate aclk266_g2d (but it is one of those
clocks that needs to be always on prior to suspend).
2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
are not 0 (thus not following the spec).

As I did not have access to the hardware guys who could possibly
confirm 1), I decided to
a) find a configuration where CG_STATUS0 allows gating of the
aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
b) disable the aclk266_g2d clock using such a configuration.
c) check s2r.

I found a configuration [1] which gave the following after boot-up:
# devmem 0x10040914
0xFD800014 (CG_STATUS0[22:21] is 0)
# devmem 0x10020700
0xC6F8DE9F (aclk266_g2d is enabled)

At this point s2r works.

I rebooted the board with the same config as above and then disabled
aclk266_g2d.

# devmem 0x10020700 32 0xC6F8DE9D
# devmem 0x10020700
0xC6F8DE9D (aclk266_g2d is disabled)
# devmem 0x10040914
0xFD800014

and tried s2r - It fails.

From the results, disabling the clock seems to cause the issue rather
than the CG_STATUS violation. This is all a little confusing, so
please let me know if I have missed something.

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

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Kevin,

On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman  wrote:
> Javier Martinez Canillas  writes:
>
> [...]
>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in more
>> detail what the real problem really is.
>
> +1
>
> Maybe Abhilash can shed some light here?
>
> We really should know *why* this is needed because having the fix in the
> clock driver just doesn't seem right.  It seems like the DMA driver
> should be managing this clock.

I think my last mail might not have reached you (was accidentally sent
as html). We are gating the aclk266_g2d clock without checking the
CG_STATUS0 register bits as specified in the UM. It looks like we need
to keep several clocks alive or gate them only after checking the
CG_STATUSx register bits.

Regards,
Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Kevin,

On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman khil...@kernel.org wrote:
 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 [...]

 Unfortunately I don't fully understand why this clock needs to be
 enabled. It would be good if someone at Samsung can explain in more
 detail what the real problem really is.

 +1

 Maybe Abhilash can shed some light here?

 We really should know *why* this is needed because having the fix in the
 clock driver just doesn't seem right.  It seems like the DMA driver
 should be managing this clock.

I think my last mail might not have reached you (was accidentally sent
as html). We are gating the aclk266_g2d clock without checking the
CG_STATUS0 register bits as specified in the UM. It looks like we need
to keep several clocks alive or gate them only after checking the
CG_STATUSx register bits.

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

Re: linux-next: manual merge of the arm-soc tree with the arm-perf tree

[Abhilash Kesavan]

Hi Stephen,

On Mon, Mar 23, 2015 at 6:03 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/bus/Kconfig between commit c9966c98697a ("arm-cci: Split the
> code for PMU vs driver support") from the arm-perf tree and commit
> 13fbf3c8d0f7 ("drivers: bus: Sort Kconfig entries alphabetically") from
> the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Not sure if this has been reported elsewhere, but I am seeing core
boot-up failures on the exynos5420 with next-20150323 due to this.
Your conflict fix is missing the ARM_CCI symbol because of which the
CCI does not get enabled.

Suzuki, can you confirm ?

Regards,
Abhilash
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/bus/Kconfig
> index 79e297b1f221,7e9c2674af81..
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@@ -4,6 -4,21 +4,38 @@@
>
>   menu "Bus devices"
>
>  -config ARM_CCI
>  -  bool "ARM CCI driver support"
> ++config ARM_CCI400_PORT_CTRL
> ++  bool
> +   depends on ARM && OF && CPU_V7
> ++  select ARM_CCI400_COMMON
> +   help
>  -Driver supporting the CCI cache coherent interconnect for ARM
>  -platforms.
> ++Low level power management driver for CCI400 cache coherent
> ++interconnect for ARM platforms.
> ++
> ++config ARM_CCI400_PMU
> ++  bool "ARM CCI400 PMU support"
> ++  default y
> ++  depends on ARM || ARM64
> ++  depends on HW_PERF_EVENTS
> ++  select ARM_CCI400_COMMON
> ++  help
> ++Support for PMU events monitoring on the ARM CCI cache coherent
> ++interconnect.
> ++
> ++If unsure, say Y
> ++
> ++config ARM_CCI400_COMMON
> ++  bool
> ++  select ARM_CCI
> +
> + config ARM_CCN
> +   bool "ARM CCN driver support"
> +   depends on ARM || ARM64
> +   depends on PERF_EVENTS
> +   help
> + PMU (perf) driver supporting the ARM CCN (Cache Coherent Network)
> + interconnect.
> +
>   config BRCMSTB_GISB_ARB
> bool "Broadcom STB GISB bus arbiter"
> depends on ARM || MIPS
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the arm-soc tree with the arm-perf tree

[Abhilash Kesavan]

Hi Stephen,

On Mon, Mar 23, 2015 at 6:03 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi all,

 Today's linux-next merge of the arm-soc tree got a conflict in
 drivers/bus/Kconfig between commit c9966c98697a (arm-cci: Split the
 code for PMU vs driver support) from the arm-perf tree and commit
 13fbf3c8d0f7 (drivers: bus: Sort Kconfig entries alphabetically) from
 the arm-soc tree.

 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

Not sure if this has been reported elsewhere, but I am seeing core
boot-up failures on the exynos5420 with next-20150323 due to this.
Your conflict fix is missing the ARM_CCI symbol because of which the
CCI does not get enabled.

Suzuki, can you confirm ?

Regards,
Abhilash

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au

 diff --cc drivers/bus/Kconfig
 index 79e297b1f221,7e9c2674af81..
 --- a/drivers/bus/Kconfig
 +++ b/drivers/bus/Kconfig
 @@@ -4,6 -4,21 +4,38 @@@

   menu Bus devices

  -config ARM_CCI
  -  bool ARM CCI driver support
 ++config ARM_CCI400_PORT_CTRL
 ++  bool
 +   depends on ARM  OF  CPU_V7
 ++  select ARM_CCI400_COMMON
 +   help
  -Driver supporting the CCI cache coherent interconnect for ARM
  -platforms.
 ++Low level power management driver for CCI400 cache coherent
 ++interconnect for ARM platforms.
 ++
 ++config ARM_CCI400_PMU
 ++  bool ARM CCI400 PMU support
 ++  default y
 ++  depends on ARM || ARM64
 ++  depends on HW_PERF_EVENTS
 ++  select ARM_CCI400_COMMON
 ++  help
 ++Support for PMU events monitoring on the ARM CCI cache coherent
 ++interconnect.
 ++
 ++If unsure, say Y
 ++
 ++config ARM_CCI400_COMMON
 ++  bool
 ++  select ARM_CCI
 +
 + config ARM_CCN
 +   bool ARM CCN driver support
 +   depends on ARM || ARM64
 +   depends on PERF_EVENTS
 +   help
 + PMU (perf) driver supporting the ARM CCN (Cache Coherent Network)
 + interconnect.
 +
   config BRCMSTB_GISB_ARB
 bool Broadcom STB GISB bus arbiter
 depends on ARM || MIPS

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH v2 0/3] Switch to ioremap_wc in the SRAM allocator code

[Abhilash Kesavan]

Hi Greg,

On Fri, Feb 6, 2015 at 9:14 PM, Catalin Marinas  wrote:
> On Fri, Feb 06, 2015 at 01:45:25PM +0000, Abhilash Kesavan wrote:
>> Fix alignment faults seen during play-back of files with specific
>> sampling rates such as 44.1K. This is based on the discussion here:
>> http://www.spinics.net/lists/arm-kernel/msg384647.html
>>
>> Patch 1 is needed as m32r arch does not define ioremap_wc. Patch 2 adds a
>> resource managed helper function for ioremap_wc which is used in patch 3.
>>
>> Changes since v1:
>>   - Fix the compilation error with m32r due to missing ioremap_wc
>>   definition.
>>   - Fixed minor indentation issues.
>>
>> Note: Other architectures either have ioremap_wc defined or are including
>> generic "io.h"/"iomap.h". c6x arch is the only one I am not sure of.
>>
>> Abhilash Kesavan (3):
>>   m32r: add definition of ioremap_wc to io.h
>>   lib: devres: add a helper function for ioremap_wc
>>   misc: sram: switch to ioremap_wc from ioremap
>>
>>  Documentation/driver-model/devres.txt |1 +
>>  arch/m32r/include/asm/io.h|1 +
>>  drivers/misc/sram.c   |   17 ++---
>>  include/linux/io.h|2 ++
>>  lib/devres.c  |   28 
>>  5 files changed, 46 insertions(+), 3 deletions(-)
>
> For the series:
>
> Acked-by: Catalin Marinas 

These patches still apply cleanly on linux-next and have been ack'ed
by Catalin and Philipp. Would you like me to collect the tags and
resend the series or can they be applied as is ?

Thanks,
Abhilash
>
> Thanks.
>
> --
> Catalin
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] ARM: EXYNOS: Remove ARCH_HAS_BANDGAP selection

[Abhilash Kesavan]

Now that the samsung thermal driver dependency on ARCH_HAS_BANDGAP
has been removed, fix the arch code selection too.

Signed-off-by: Abhilash Kesavan 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Acked-by: Lukasz Majewski 
---
 arch/arm/mach-exynos/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 603820e..a4abcae 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -9,7 +9,6 @@
 
 menuconfig ARCH_EXYNOS
bool "Samsung EXYNOS" if ARCH_MULTI_V7
-   select ARCH_HAS_BANDGAP
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH v2 0/3] Switch to ioremap_wc in the SRAM allocator code

[Abhilash Kesavan]

Hi Greg,

On Fri, Feb 6, 2015 at 9:14 PM, Catalin Marinas catalin.mari...@arm.com wrote:
 On Fri, Feb 06, 2015 at 01:45:25PM +, Abhilash Kesavan wrote:
 Fix alignment faults seen during play-back of files with specific
 sampling rates such as 44.1K. This is based on the discussion here:
 http://www.spinics.net/lists/arm-kernel/msg384647.html

 Patch 1 is needed as m32r arch does not define ioremap_wc. Patch 2 adds a
 resource managed helper function for ioremap_wc which is used in patch 3.

 Changes since v1:
   - Fix the compilation error with m32r due to missing ioremap_wc
   definition.
   - Fixed minor indentation issues.

 Note: Other architectures either have ioremap_wc defined or are including
 generic io.h/iomap.h. c6x arch is the only one I am not sure of.

 Abhilash Kesavan (3):
   m32r: add definition of ioremap_wc to io.h
   lib: devres: add a helper function for ioremap_wc
   misc: sram: switch to ioremap_wc from ioremap

  Documentation/driver-model/devres.txt |1 +
  arch/m32r/include/asm/io.h|1 +
  drivers/misc/sram.c   |   17 ++---
  include/linux/io.h|2 ++
  lib/devres.c  |   28 
  5 files changed, 46 insertions(+), 3 deletions(-)

 For the series:

 Acked-by: Catalin Marinas catalin.mari...@arm.com

These patches still apply cleanly on linux-next and have been ack'ed
by Catalin and Philipp. Would you like me to collect the tags and
resend the series or can they be applied as is ?

Thanks,
Abhilash

 Thanks.

 --
 Catalin
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] ARM: EXYNOS: Remove ARCH_HAS_BANDGAP selection

[Abhilash Kesavan]

Now that the samsung thermal driver dependency on ARCH_HAS_BANDGAP
has been removed, fix the arch code selection too.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
 arch/arm/mach-exynos/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 603820e..a4abcae 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -9,7 +9,6 @@
 
 menuconfig ARCH_EXYNOS
bool Samsung EXYNOS if ARCH_MULTI_V7
-   select ARCH_HAS_BANDGAP
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Abhilash Kesavan]

Hi Lukasz,

On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski  wrote:
> Hi Abhilash,
>
>> This patch fixes the wrong control of PD_DET_EN (power down detection
>> mode) for Exynos7 because exynos7_tmu_control() always enables the
>> power down detection mode regardless 'on' parameter.
>>
>> Cc: Zhang Rui 
>> Cc: Eduardo Valentin 
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
>> platform_device *pdev, bool on)
>>   if (on) {
>>   con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
>> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
>>   interrupt_en =
>>   (of_thermal_is_trip_valid(tz, 7)
>>   << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
>> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
>> platform_device *pdev, bool on) interrupt_en <<
>> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
>>   con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
>> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
>>   interrupt_en = 0; /* Disable all interrupts */
>>   }
>> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
>>
>>   writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
>>   writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
>
> Could you test this patch if it isn't introducing any regression on your
> HW?

The patch does not cause any regression on exynos7 and seems logically correct.

Tested-by: Abhilash Kesavan 


Regards,
Abhilash
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Abhilash Kesavan]

Hi Lukasz,

On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski l.majew...@samsung.com wrote:
 Hi Abhilash,

 This patch fixes the wrong control of PD_DET_EN (power down detection
 mode) for Exynos7 because exynos7_tmu_control() always enables the
 power down detection mode regardless 'on' parameter.

 Cc: Zhang Rui rui.zh...@intel.com
 Cc: Eduardo Valentin edubez...@gmail.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/thermal/samsung/exynos_tmu.c
 b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
 platform_device *pdev, bool on)
   if (on) {
   con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
 + con |= (1  EXYNOS7_PD_DET_EN_SHIFT);
   interrupt_en =
   (of_thermal_is_trip_valid(tz, 7)
EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
 @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
 platform_device *pdev, bool on) interrupt_en 
 EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
   con = ~(1  EXYNOS_TMU_CORE_EN_SHIFT);
 + con = ~(1  EXYNOS7_PD_DET_EN_SHIFT);
   interrupt_en = 0; /* Disable all interrupts */
   }
 - con |= 1  EXYNOS7_PD_DET_EN_SHIFT;

   writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
   writel(con, data-base + EXYNOS_TMU_REG_CONTROL);

 Could you test this patch if it isn't introducing any regression on your
 HW?

The patch does not cause any regression on exynos7 and seems logically correct.

Tested-by: Abhilash Kesavan a.kesa...@samsung.com


Regards,
Abhilash

 --
 Best regards,

 Lukasz Majewski

 Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.

Signed-off-by: Abhilash Kesavan 
Tested-by: Tony Lindgren 
Tested-by: Heiko Stuebner 
---
 drivers/misc/sram.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..15b4d4e 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -69,12 +69,23 @@ static int sram_probe(struct platform_device *pdev)
INIT_LIST_HEAD(_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   virt_base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(virt_base))
-   return PTR_ERR(virt_base);
+   if (!res) {
+   dev_err(>dev, "found no memory resource\n");
+   return -EINVAL;
+   }
 
size = resource_size(res);
 
+   if (!devm_request_mem_region(>dev,
+   res->start, size, pdev->name)) {
+   dev_err(>dev, "could not request region for resource\n");
+   return -EBUSY;
+   }
+
+   virt_base = devm_ioremap_wc(>dev, res->start, size);
+   if (IS_ERR(virt_base))
+   return PTR_ERR(virt_base);
+
sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
return -ENOMEM;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] Switch to ioremap_wc in the SRAM allocator code

[Abhilash Kesavan]

Fix alignment faults seen during play-back of files with specific
sampling rates such as 44.1K. This is based on the discussion here:
http://www.spinics.net/lists/arm-kernel/msg384647.html

Patch 1 is needed as m32r arch does not define ioremap_wc. Patch 2 adds a
resource managed helper function for ioremap_wc which is used in patch 3.

Changes since v1:
- Fix the compilation error with m32r due to missing ioremap_wc
definition.
- Fixed minor indentation issues.

Note: Other architectures either have ioremap_wc defined or are including
generic "io.h"/"iomap.h". c6x arch is the only one I am not sure of.

Abhilash Kesavan (3):
  m32r: add definition of ioremap_wc to io.h
  lib: devres: add a helper function for ioremap_wc
  misc: sram: switch to ioremap_wc from ioremap

 Documentation/driver-model/devres.txt |1 +
 arch/m32r/include/asm/io.h|1 +
 drivers/misc/sram.c   |   17 ++---
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 5 files changed, 46 insertions(+), 3 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] m32r: add definition of ioremap_wc to io.h

[Abhilash Kesavan]

Before adding a resource managed ioremap_wc function, we need
to have ioremap_wc defined for m32r to prevent build errors.

Signed-off-by: Abhilash Kesavan 
---
 arch/m32r/include/asm/io.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 6e7787f..9cc00db 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -67,6 +67,7 @@ static inline void __iomem *ioremap(unsigned long offset, 
unsigned long size)
 
 extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
+#define ioremap_wc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Implement a resource managed writecombine ioremap function.

Signed-off-by: Abhilash Kesavan 
---
 Documentation/driver-model/devres.txt |1 +
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 3 files changed, 31 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index 6d1e8ee..7fe7fd2 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -276,6 +276,7 @@ IOMAP
   devm_ioport_unmap()
   devm_ioremap()
   devm_ioremap_nocache()
+  devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_iounmap()
   pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index fa02e55..42b33f0 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
resource_size_t offset,
   resource_size_t size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
   resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..fbe2aac 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_wc(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Tested-by: Tony Lindgren t...@atomide.com
Tested-by: Heiko Stuebner he...@sntech.de
---
 drivers/misc/sram.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..15b4d4e 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -69,12 +69,23 @@ static int sram_probe(struct platform_device *pdev)
INIT_LIST_HEAD(reserve_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   virt_base = devm_ioremap_resource(pdev-dev, res);
-   if (IS_ERR(virt_base))
-   return PTR_ERR(virt_base);
+   if (!res) {
+   dev_err(pdev-dev, found no memory resource\n);
+   return -EINVAL;
+   }
 
size = resource_size(res);
 
+   if (!devm_request_mem_region(pdev-dev,
+   res-start, size, pdev-name)) {
+   dev_err(pdev-dev, could not request region for resource\n);
+   return -EBUSY;
+   }
+
+   virt_base = devm_ioremap_wc(pdev-dev, res-start, size);
+   if (IS_ERR(virt_base))
+   return PTR_ERR(virt_base);
+
sram = devm_kzalloc(pdev-dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
return -ENOMEM;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Implement a resource managed writecombine ioremap function.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 Documentation/driver-model/devres.txt |1 +
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 3 files changed, 31 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index 6d1e8ee..7fe7fd2 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -276,6 +276,7 @@ IOMAP
   devm_ioport_unmap()
   devm_ioremap()
   devm_ioremap_nocache()
+  devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_iounmap()
   pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index fa02e55..42b33f0 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
resource_size_t offset,
   resource_size_t size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
   resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..fbe2aac 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_wc(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] m32r: add definition of ioremap_wc to io.h

[Abhilash Kesavan]

Before adding a resource managed ioremap_wc function, we need
to have ioremap_wc defined for m32r to prevent build errors.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 arch/m32r/include/asm/io.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 6e7787f..9cc00db 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -67,6 +67,7 @@ static inline void __iomem *ioremap(unsigned long offset, 
unsigned long size)
 
 extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
+#define ioremap_wc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] Switch to ioremap_wc in the SRAM allocator code

[Abhilash Kesavan]

Fix alignment faults seen during play-back of files with specific
sampling rates such as 44.1K. This is based on the discussion here:
http://www.spinics.net/lists/arm-kernel/msg384647.html

Patch 1 is needed as m32r arch does not define ioremap_wc. Patch 2 adds a
resource managed helper function for ioremap_wc which is used in patch 3.

Changes since v1:
- Fix the compilation error with m32r due to missing ioremap_wc
definition.
- Fixed minor indentation issues.

Note: Other architectures either have ioremap_wc defined or are including
generic io.h/iomap.h. c6x arch is the only one I am not sure of.

Abhilash Kesavan (3):
  m32r: add definition of ioremap_wc to io.h
  lib: devres: add a helper function for ioremap_wc
  misc: sram: switch to ioremap_wc from ioremap

 Documentation/driver-model/devres.txt |1 +
 arch/m32r/include/asm/io.h|1 +
 drivers/misc/sram.c   |   17 ++---
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 5 files changed, 46 insertions(+), 3 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Eduardo,

On Sun, Feb 1, 2015 at 12:54 AM, Eduardo Valentin  wrote:
> On Tue, Jan 27, 2015 at 11:18:22AM +0530, Abhilash Kesavan wrote:
>> Add registers, bit fields and compatible strings for Exynos7 TMU
>> (Thermal Management Unit). Following are a few of the differences
>> in the Exynos7 TMU from earlier SoCs:
>> - 8 trigger levels
>> - Different bit offsets and more registers for the rising
>> and falling thresholds.
>> - New power down detection bit in the TMU_CONTROL register
>> which does not update the CURRENT_TEMP0 when tmu power down
>> is detected.
>> - Change in bit offset for the NEXT_DATA field of EMUL_CON
>> register. EMUL_CON register address has also changed.
>> - INTSTAT and INTCLEAR registers present in earlier SoCs
>> have been combined into one INTPEND register. The register
>> address for INTCLEAR and INTPEND is also different.
>> - Since there are 8 rising/falling interrupts as against
>> at most 4 in earlier SoCs the INTEN bit offsets are different.
>> - Multiple probe support which is handled by a TMU_CONTROL1
>> register (No support for this in the current patch).
>>
>> This patch adds special clock support required only for Exynos7. It
>> also updates the "code_to_temp" prototype as Exynos7 has 9 bit
>> code-temp mapping.
>>
>> Signed-off-by: Abhilash Kesavan 
>
> Applied to my -fixes branch. However, I had to amend it myself to make
> checkpatch.pl --strict silent. In this version, it still outputs:
> CHECK: Alignment should match open parenthesis
> #209: FILE: drivers/thermal/samsung/exynos_tmu.c:558:
> +   if (!data->temp_error1 ||
> +  (pdata->min_efuse_value > data->temp_error1) ||
>
> CHECK: multiple assignments should be avoided
> #366: FILE: drivers/thermal/samsung/exynos_tmu.c:882:
> +   tmu_intstat = tmu_intclear = EXYNOS7_TMU_REG_INTPEND;
>
> total: 0 errors, 0 warnings, 2 checks, 314 lines checked
>
> next, make sure you run checkpatch.pl --strict before sending patches.

Thanks for applying these patches. As this is adding support for a new
SoC, should it not be part of your -next branch ?
I generally just run checkpatch without the "strict" option. Will
ensure that I run it with "strict" in the future.

Regards,
Abhilash
>
>
>> ---
>> This patch set has been tested on linux next-20150123 with Eduardo's
>> thermal-next branch merged along with the arch-side exynos7 related
>> dts changes applied.
>>
>> Changes since v3:
>> Addressed comments from Lukasz Majewski:
>>   - Added more comments in the code setting the thresholds.
>>   - Split the documentation out into another patch.
>> Changes since v2:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v4).
>>   - Added new exynos7 soc_type.
>> Changes since v1:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v2).
>>   - Added sclk support to patch adding Exynos7 tmu support.
>>   Previously, it was a separate patch.
>>   - Used the SOC type to decide if sclk is present.
>>
>>  drivers/thermal/samsung/exynos_tmu.c |  204 
>> --
>>  drivers/thermal/samsung/exynos_tmu.h |1 +
>>  2 files changed, 197 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 852e622..660ff69 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -119,6 +119,26 @@
>>  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
>>  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
>>
>> +/* Exynos7 specific registers */
>> +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
>> +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
>> +#define EXYNOS7_TMU_REG_INTEN0x110
>> +#define EXYNOS7_TMU_REG_INTPEND  0x118
>> +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
>> +
>> +#define EXYNOS7_TMU_TEMP_MASK0x1ff
>> +#define EXYNOS7_PD_DET_EN_SHIFT  23
>> +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
>> +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
>> +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
>> +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
>> +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
>> +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT 

Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Eduardo,

On Sun, Feb 1, 2015 at 12:54 AM, Eduardo Valentin edubez...@gmail.com wrote:
 On Tue, Jan 27, 2015 at 11:18:22AM +0530, Abhilash Kesavan wrote:
 Add registers, bit fields and compatible strings for Exynos7 TMU
 (Thermal Management Unit). Following are a few of the differences
 in the Exynos7 TMU from earlier SoCs:
 - 8 trigger levels
 - Different bit offsets and more registers for the rising
 and falling thresholds.
 - New power down detection bit in the TMU_CONTROL register
 which does not update the CURRENT_TEMP0 when tmu power down
 is detected.
 - Change in bit offset for the NEXT_DATA field of EMUL_CON
 register. EMUL_CON register address has also changed.
 - INTSTAT and INTCLEAR registers present in earlier SoCs
 have been combined into one INTPEND register. The register
 address for INTCLEAR and INTPEND is also different.
 - Since there are 8 rising/falling interrupts as against
 at most 4 in earlier SoCs the INTEN bit offsets are different.
 - Multiple probe support which is handled by a TMU_CONTROL1
 register (No support for this in the current patch).

 This patch adds special clock support required only for Exynos7. It
 also updates the code_to_temp prototype as Exynos7 has 9 bit
 code-temp mapping.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com

 Applied to my -fixes branch. However, I had to amend it myself to make
 checkpatch.pl --strict silent. In this version, it still outputs:
 CHECK: Alignment should match open parenthesis
 #209: FILE: drivers/thermal/samsung/exynos_tmu.c:558:
 +   if (!data-temp_error1 ||
 +  (pdata-min_efuse_value  data-temp_error1) ||

 CHECK: multiple assignments should be avoided
 #366: FILE: drivers/thermal/samsung/exynos_tmu.c:882:
 +   tmu_intstat = tmu_intclear = EXYNOS7_TMU_REG_INTPEND;

 total: 0 errors, 0 warnings, 2 checks, 314 lines checked

 next, make sure you run checkpatch.pl --strict before sending patches.

Thanks for applying these patches. As this is adding support for a new
SoC, should it not be part of your -next branch ?
I generally just run checkpatch without the strict option. Will
ensure that I run it with strict in the future.

Regards,
Abhilash


 ---
 This patch set has been tested on linux next-20150123 with Eduardo's
 thermal-next branch merged along with the arch-side exynos7 related
 dts changes applied.

 Changes since v3:
 Addressed comments from Lukasz Majewski:
   - Added more comments in the code setting the thresholds.
   - Split the documentation out into another patch.
 Changes since v2:
   - Rebased on top of Lukasz' latest exynos tmu series (v4).
   - Added new exynos7 soc_type.
 Changes since v1:
   - Rebased on top of Lukasz' latest exynos tmu series (v2).
   - Added sclk support to patch adding Exynos7 tmu support.
   Previously, it was a separate patch.
   - Used the SOC type to decide if sclk is present.

  drivers/thermal/samsung/exynos_tmu.c |  204 
 --
  drivers/thermal/samsung/exynos_tmu.h |1 +
  2 files changed, 197 insertions(+), 8 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index 852e622..660ff69 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -119,6 +119,26 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8

 +/* Exynos7 specific registers */
 +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
 +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
 +#define EXYNOS7_TMU_REG_INTEN0x110
 +#define EXYNOS7_TMU_REG_INTPEND  0x118
 +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
 +
 +#define EXYNOS7_TMU_TEMP_MASK0x1ff
 +#define EXYNOS7_PD_DET_EN_SHIFT  23
 +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
 +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
 +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
 +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
 +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
 +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
 +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
 +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
 +#define EXYNOS7_EMUL_DATA_SHIFT  7
 +#define EXYNOS7_EMUL_DATA_MASK   0x1ff
 +
  #define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of the TMU
 @@ -133,6 +153,7 @@
   * @lock: lock to implement synchronization.
   * @clk: pointer to the clock structure.
   * @clk_sec: pointer to the clock structure for accessing the base_second.
 + * @sclk: pointer to the clock structure for accessing the tmu special clk.
   * @temp_error1: fused value of the first

Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Lukasz,

On Thu, Jan 29, 2015 at 1:56 PM, Lukasz Majewski  wrote:
> Hi Abhilash,
>
>> Add registers, bit fields and compatible strings for Exynos7 TMU
>> (Thermal Management Unit). Following are a few of the differences
>> in the Exynos7 TMU from earlier SoCs:
>> - 8 trigger levels
>> - Different bit offsets and more registers for the rising
>> and falling thresholds.
>> - New power down detection bit in the TMU_CONTROL register
>> which does not update the CURRENT_TEMP0 when tmu power down
>> is detected.
>> - Change in bit offset for the NEXT_DATA field of EMUL_CON
>> register. EMUL_CON register address has also changed.
>> - INTSTAT and INTCLEAR registers present in earlier SoCs
>> have been combined into one INTPEND register. The register
>> address for INTCLEAR and INTPEND is also different.
>> - Since there are 8 rising/falling interrupts as against
>> at most 4 in earlier SoCs the INTEN bit offsets are different.
>> - Multiple probe support which is handled by a TMU_CONTROL1
>> register (No support for this in the current patch).
>>
>> This patch adds special clock support required only for Exynos7. It
>> also updates the "code_to_temp" prototype as Exynos7 has 9 bit
>> code-temp mapping.
>>
>> Signed-off-by: Abhilash Kesavan 
>> ---
>> This patch set has been tested on linux next-20150123 with Eduardo's
>> thermal-next branch merged along with the arch-side exynos7 related
>> dts changes applied.
>>
>> Changes since v3:
>> Addressed comments from Lukasz Majewski:
>>   - Added more comments in the code setting the thresholds.
>>   - Split the documentation out into another patch.
>> Changes since v2:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v4).
>>   - Added new exynos7 soc_type.
>> Changes since v1:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v2).
>>   - Added sclk support to patch adding Exynos7 tmu support.
>>   Previously, it was a separate patch.
>>   - Used the SOC type to decide if sclk is present.
>>
>>  drivers/thermal/samsung/exynos_tmu.c |  204
>> --
>> drivers/thermal/samsung/exynos_tmu.h |1 + 2 files changed, 197
>> insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index 852e622..660ff69 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -119,6 +119,26 @@
>>  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
>>  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
>>
>> +/* Exynos7 specific registers */
>> +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
>> +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
>> +#define EXYNOS7_TMU_REG_INTEN0x110
>> +#define EXYNOS7_TMU_REG_INTPEND  0x118
>> +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
>> +
>> +#define EXYNOS7_TMU_TEMP_MASK0x1ff
>> +#define EXYNOS7_PD_DET_EN_SHIFT  23
>> +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
>> +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
>> +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
>> +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
>> +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
>> +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
>> +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
>> +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
>> +#define EXYNOS7_EMUL_DATA_SHIFT  7
>> +#define EXYNOS7_EMUL_DATA_MASK   0x1ff
>> +
>>  #define MCELSIUS 1000
>>  /**
>>   * struct exynos_tmu_data : A structure to hold the private data of
>> the TMU @@ -133,6 +153,7 @@
>>   * @lock: lock to implement synchronization.
>>   * @clk: pointer to the clock structure.
>>   * @clk_sec: pointer to the clock structure for accessing the
>> base_second.
>> + * @sclk: pointer to the clock structure for accessing the tmu
>> special clk.
>>   * @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.
>> @@ -152,8 +173,8 @@ struct exynos_tmu_data {
>>   enum soc_type soc;
>>   struct work_struct irq_work;
>

Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Lukasz,

On Thu, Jan 29, 2015 at 1:56 PM, Lukasz Majewski l.majew...@samsung.com wrote:
 Hi Abhilash,

 Add registers, bit fields and compatible strings for Exynos7 TMU
 (Thermal Management Unit). Following are a few of the differences
 in the Exynos7 TMU from earlier SoCs:
 - 8 trigger levels
 - Different bit offsets and more registers for the rising
 and falling thresholds.
 - New power down detection bit in the TMU_CONTROL register
 which does not update the CURRENT_TEMP0 when tmu power down
 is detected.
 - Change in bit offset for the NEXT_DATA field of EMUL_CON
 register. EMUL_CON register address has also changed.
 - INTSTAT and INTCLEAR registers present in earlier SoCs
 have been combined into one INTPEND register. The register
 address for INTCLEAR and INTPEND is also different.
 - Since there are 8 rising/falling interrupts as against
 at most 4 in earlier SoCs the INTEN bit offsets are different.
 - Multiple probe support which is handled by a TMU_CONTROL1
 register (No support for this in the current patch).

 This patch adds special clock support required only for Exynos7. It
 also updates the code_to_temp prototype as Exynos7 has 9 bit
 code-temp mapping.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
 This patch set has been tested on linux next-20150123 with Eduardo's
 thermal-next branch merged along with the arch-side exynos7 related
 dts changes applied.

 Changes since v3:
 Addressed comments from Lukasz Majewski:
   - Added more comments in the code setting the thresholds.
   - Split the documentation out into another patch.
 Changes since v2:
   - Rebased on top of Lukasz' latest exynos tmu series (v4).
   - Added new exynos7 soc_type.
 Changes since v1:
   - Rebased on top of Lukasz' latest exynos tmu series (v2).
   - Added sclk support to patch adding Exynos7 tmu support.
   Previously, it was a separate patch.
   - Used the SOC type to decide if sclk is present.

  drivers/thermal/samsung/exynos_tmu.c |  204
 --
 drivers/thermal/samsung/exynos_tmu.h |1 + 2 files changed, 197
 insertions(+), 8 deletions(-)

 diff --git a/drivers/thermal/samsung/exynos_tmu.c
 b/drivers/thermal/samsung/exynos_tmu.c index 852e622..660ff69 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -119,6 +119,26 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8

 +/* Exynos7 specific registers */
 +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
 +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
 +#define EXYNOS7_TMU_REG_INTEN0x110
 +#define EXYNOS7_TMU_REG_INTPEND  0x118
 +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
 +
 +#define EXYNOS7_TMU_TEMP_MASK0x1ff
 +#define EXYNOS7_PD_DET_EN_SHIFT  23
 +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
 +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
 +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
 +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
 +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
 +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
 +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
 +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
 +#define EXYNOS7_EMUL_DATA_SHIFT  7
 +#define EXYNOS7_EMUL_DATA_MASK   0x1ff
 +
  #define MCELSIUS 1000
  /**
   * struct exynos_tmu_data : A structure to hold the private data of
 the TMU @@ -133,6 +153,7 @@
   * @lock: lock to implement synchronization.
   * @clk: pointer to the clock structure.
   * @clk_sec: pointer to the clock structure for accessing the
 base_second.
 + * @sclk: pointer to the clock structure for accessing the tmu
 special clk.
   * @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.
 @@ -152,8 +173,8 @@ struct exynos_tmu_data {
   enum soc_type soc;
   struct work_struct irq_work;
   struct mutex lock;
 - struct clk *clk, *clk_sec;
 - u8 temp_error1, temp_error2;
 + struct clk *clk, *clk_sec, *sclk;
 + u16 temp_error1, temp_error2;
   struct regulator *regulator;
   struct thermal_zone_device *tzd;

 @@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data
 *data, u8 temp)
   * Calculate a temperature value from a temperature code.
   * The unit of the temperature is degree Celsius.
   */
 -static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
 +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
  {
   struct exynos_tmu_platform_data *pdata = data-pdata;
   int temp;
 @@ -513,6 +534,84 @@ static int

Re: [PATCH v4 1/2] dts: Documentation: Add documentation for Exynos7 SoC thermal bindings

[Abhilash Kesavan]

Hi Eduardo,

On Tue, Jan 27, 2015 at 11:18 AM, Abhilash Kesavan
 wrote:
> Add documentation for exynos7 thermal bindings including compatible
> name and special clock properties.
>
> Signed-off-by: Abhilash Kesavan 
> ---
>  .../devicetree/bindings/thermal/exynos-thermal.txt |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 0f44932..695150a 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -12,6 +12,7 @@
>"samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 
> and 4
> Exynos5420 (Must pass triminfo base and triminfo 
> clock)
>"samsung,exynos5440-tmu"
> +  "samsung,exynos7-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
> @@ -32,10 +33,13 @@
>  - clocks : The main clocks for TMU device
> -- 1. operational clock for TMU channel
> -- 2. optional clock to access the shared registers of TMU channel
> +   -- 3. optional special clock for functional operation
>  - clock-names : Thermal system clock name
> -- "tmu_apbif" operational clock for current TMU channel
> -- "tmu_triminfo_apbif" clock to access the shared triminfo register
> for current TMU channel
> +   -- "tmu_sclk" clock for functional operation of the current TMU
> +   channel
>  - 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.

Can you kindly consider applying these two patches to your next tree
if they look OK ?

Regards,
Abhilash
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/2] dts: Documentation: Add documentation for Exynos7 SoC thermal bindings

[Abhilash Kesavan]

Hi Eduardo,

On Tue, Jan 27, 2015 at 11:18 AM, Abhilash Kesavan
a.kesa...@samsung.com wrote:
 Add documentation for exynos7 thermal bindings including compatible
 name and special clock properties.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
  .../devicetree/bindings/thermal/exynos-thermal.txt |4 
  1 file changed, 4 insertions(+)

 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index 0f44932..695150a 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -12,6 +12,7 @@
samsung,exynos5420-tmu-ext-triminfo for TMU channels 2, 3 
 and 4
 Exynos5420 (Must pass triminfo base and triminfo 
 clock)
samsung,exynos5440-tmu
 +  samsung,exynos7-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
 @@ -32,10 +33,13 @@
  - clocks : The main clocks for TMU device
 -- 1. operational clock for TMU channel
 -- 2. optional clock to access the shared registers of TMU channel
 +   -- 3. optional special clock for functional operation
  - clock-names : Thermal system clock name
 -- tmu_apbif operational clock for current TMU channel
 -- tmu_triminfo_apbif clock to access the shared triminfo register
 for current TMU channel
 +   -- tmu_sclk clock for functional operation of the current TMU
 +   channel
  - 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.

Can you kindly consider applying these two patches to your next tree
if they look OK ?

Regards,
Abhilash
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/2] dts: Documentation: Add documentation for Exynos7 SoC thermal bindings

[Abhilash Kesavan]

Add documentation for exynos7 thermal bindings including compatible
name and special clock properties.

Signed-off-by: Abhilash Kesavan 
---
 .../devicetree/bindings/thermal/exynos-thermal.txt |4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 0f44932..695150a 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -12,6 +12,7 @@
   "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
   "samsung,exynos5440-tmu"
+  "samsung,exynos7-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
@@ -32,10 +33,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- "tmu_apbif" operational clock for current TMU channel
-- "tmu_triminfo_apbif" clock to access the shared triminfo register
for current TMU channel
+   -- "tmu_sclk" clock for functional operation of the current TMU
+   channel
 - 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.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).

This patch adds special clock support required only for Exynos7. It
also updates the "code_to_temp" prototype as Exynos7 has 9 bit
code-temp mapping.

Signed-off-by: Abhilash Kesavan 
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.

Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.

 drivers/thermal/samsung/exynos_tmu.c |  204 --
 drivers/thermal/samsung/exynos_tmu.h |1 +
 2 files changed, 197 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6   0x50
+#define EXYNOS7_THD_TEMP_FALL7_6   0x60
+#define EXYNOS7_TMU_REG_INTEN  0x110
+#define EXYNOS7_TMU_REG_INTPEND0x118
+#define EXYNOS7_TMU_REG_EMUL_CON   0x160
+
+#define EXYNOS7_TMU_TEMP_MASK  0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT  0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT  1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT  2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT  3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT  4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT  5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT  6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT  7
+#define EXYNOS7_EMUL_DATA_SHIFT7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
 #define MCELSIUS   1000
 /**
  * struct exynos_tmu_data : A structure to hold the private data of the TMU
@@ -133,6 +153,7 @@
  * @lock: lock to implement synchronization.
  * @clk: pointer to the clock structure.
  * @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clk.
  * @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.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
-   struct clk *clk, *clk_sec;
-   u8 temp_error1, temp_error2;
+   struct clk *clk, *clk_sec, *sclk;
+   u16 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_zone_device *tzd;
 
@@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 
temp)
  * Calculate a temperature value from a temperature code.
  * The unit of the temperature is degree Celsius.
  */
-static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
 {
struct exynos_tmu_platform_data *pdata = data->pdata;
int temp;
@@ -513,6 +534,84 @@ static int exynos5440_tmu_initialize(struct 
platform_device *pdev)
return ret;
 }
 
+static int exynos7_tmu_initialize(struct platform_device *pdev)
+{
+   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+

[PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).

This patch adds special clock support required only for Exynos7. It
also updates the code_to_temp prototype as Exynos7 has 9 bit
code-temp mapping.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.

Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.

 drivers/thermal/samsung/exynos_tmu.c |  204 --
 drivers/thermal/samsung/exynos_tmu.h |1 +
 2 files changed, 197 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6   0x50
+#define EXYNOS7_THD_TEMP_FALL7_6   0x60
+#define EXYNOS7_TMU_REG_INTEN  0x110
+#define EXYNOS7_TMU_REG_INTPEND0x118
+#define EXYNOS7_TMU_REG_EMUL_CON   0x160
+
+#define EXYNOS7_TMU_TEMP_MASK  0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT  0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT  1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT  2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT  3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT  4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT  5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT  6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT  7
+#define EXYNOS7_EMUL_DATA_SHIFT7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
 #define MCELSIUS   1000
 /**
  * struct exynos_tmu_data : A structure to hold the private data of the TMU
@@ -133,6 +153,7 @@
  * @lock: lock to implement synchronization.
  * @clk: pointer to the clock structure.
  * @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clk.
  * @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.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
-   struct clk *clk, *clk_sec;
-   u8 temp_error1, temp_error2;
+   struct clk *clk, *clk_sec, *sclk;
+   u16 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_zone_device *tzd;
 
@@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 
temp)
  * Calculate a temperature value from a temperature code.
  * The unit of the temperature is degree Celsius.
  */
-static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
 {
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
@@ -513,6 +534,84 @@ static int exynos5440_tmu_initialize(struct 
platform_device *pdev)
return ret;
 }
 
+static int exynos7_tmu_initialize(struct platform_device *pdev)
+{
+   struct exynos_tmu_data *data = platform_get_drvdata(pdev

[PATCH v4 1/2] dts: Documentation: Add documentation for Exynos7 SoC thermal bindings

[Abhilash Kesavan]

Add documentation for exynos7 thermal bindings including compatible
name and special clock properties.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 .../devicetree/bindings/thermal/exynos-thermal.txt |4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 0f44932..695150a 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -12,6 +12,7 @@
   samsung,exynos5420-tmu-ext-triminfo for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
   samsung,exynos5440-tmu
+  samsung,exynos7-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
@@ -32,10 +33,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- tmu_apbif operational clock for current TMU channel
-- tmu_triminfo_apbif clock to access the shared triminfo register
for current TMU channel
+   -- tmu_sclk clock for functional operation of the current TMU
+   channel
 - 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.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Lukasz,

On Mon, Jan 19, 2015 at 6:34 PM, Lukasz Majewski  wrote:
> Hi Abhilash,
>
>> Add registers, bit fields and compatible strings for Exynos7 TMU
>> (Thermal Management Unit). Following are a few of the differences
>> in the Exynos7 TMU from earlier SoCs:
>> - 8 trigger levels
>> - Different bit offsets and more registers for the rising
>> and falling thresholds.
>> - New power down detection bit in the TMU_CONTROL register
>> which does not update the CURRENT_TEMP0 when tmu power down
>> is detected.
>> - Change in bit offset for the NEXT_DATA field of EMUL_CON
>> register. EMUL_CON register address has also changed.
>> - INTSTAT and INTCLEAR registers present in earlier SoCs
>> have been combined into one INTPEND register. The register
>> address for INTCLEAR and INTPEND is also different.
>> - Since there are 8 rising/falling interrupts as against
>> at most 4 in earlier SoCs the INTEN bit offsets are different.
>> - Multiple probe support which is handled by a TMU_CONTROL1
>> register (No support for this in the current patch).
>>
>> This patch adds special clock support required only for Exynos7
>> and updates the bindings documentation appropriately. It also updates
>> the "code_to_temp" prototype as Exynos7 has 9 bit code-temp mapping.
>>
>> Signed-off-by: Abhilash Kesavan 
>> ---
>> This patch is based on Lukasz Majewski's Exynos TMU v4 patchset:
>> http://www.spinics.net/lists/linux-samsung-soc/msg41183.html
>>
>> Changes since v2:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v4).
>>   - Added new exynos7 soc_type.
>> Changes since v1:
>>   - Rebased on top of Lukasz' latest exynos tmu series (v2).
>>   - Added sclk support to patch adding Exynos7 tmu support.
>>   Previously, it was a separate patch.
>>   - Used the SOC type to decide if sclk is present.
>>
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |4 +
>>  drivers/thermal/samsung/exynos_tmu.c   |  203
>> +++-
>> drivers/thermal/samsung/exynos_tmu.h   |1 + 3 files
>> changed, 199 insertions(+), 9 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index
>> 0f44932..695150a 100644 ---
>> a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@
>> -12,6 +12,7 @@ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels
>> 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock)
>> "samsung,exynos5440-tmu"
>> +"samsung,exynos7-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 @@ -32,10 +33,13 @@
>>  - clocks : The main clocks for TMU device
>>   -- 1. operational clock for TMU channel
>>   -- 2. optional clock to access the shared registers of TMU
>> channel
>> + -- 3. optional special clock for functional operation
>>  - clock-names : Thermal system clock name
>>   -- "tmu_apbif" operational clock for current TMU channel
>>   -- "tmu_triminfo_apbif" clock to access the shared triminfo
>> register for current TMU channel
>> + -- "tmu_sclk" clock for functional operation of the current
>> TMU
>> + channel
>>  - 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.
>
> I would recommend splitting the documentation from the code. IMHO it
> would be more readable.

I will split the documentation out into a separate patch.

>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c index 633a9e2..8b26acb 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -119,6 +119,26 @@
>>  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
>>  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
>>
>> +/* Exynos7 specific registers */
>> +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
>> +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
&

Re: [PATCH v3] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Hi Lukasz,

On Mon, Jan 19, 2015 at 6:34 PM, Lukasz Majewski l.majew...@samsung.com wrote:
 Hi Abhilash,

 Add registers, bit fields and compatible strings for Exynos7 TMU
 (Thermal Management Unit). Following are a few of the differences
 in the Exynos7 TMU from earlier SoCs:
 - 8 trigger levels
 - Different bit offsets and more registers for the rising
 and falling thresholds.
 - New power down detection bit in the TMU_CONTROL register
 which does not update the CURRENT_TEMP0 when tmu power down
 is detected.
 - Change in bit offset for the NEXT_DATA field of EMUL_CON
 register. EMUL_CON register address has also changed.
 - INTSTAT and INTCLEAR registers present in earlier SoCs
 have been combined into one INTPEND register. The register
 address for INTCLEAR and INTPEND is also different.
 - Since there are 8 rising/falling interrupts as against
 at most 4 in earlier SoCs the INTEN bit offsets are different.
 - Multiple probe support which is handled by a TMU_CONTROL1
 register (No support for this in the current patch).

 This patch adds special clock support required only for Exynos7
 and updates the bindings documentation appropriately. It also updates
 the code_to_temp prototype as Exynos7 has 9 bit code-temp mapping.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
 This patch is based on Lukasz Majewski's Exynos TMU v4 patchset:
 http://www.spinics.net/lists/linux-samsung-soc/msg41183.html

 Changes since v2:
   - Rebased on top of Lukasz' latest exynos tmu series (v4).
   - Added new exynos7 soc_type.
 Changes since v1:
   - Rebased on top of Lukasz' latest exynos tmu series (v2).
   - Added sclk support to patch adding Exynos7 tmu support.
   Previously, it was a separate patch.
   - Used the SOC type to decide if sclk is present.

  .../devicetree/bindings/thermal/exynos-thermal.txt |4 +
  drivers/thermal/samsung/exynos_tmu.c   |  203
 +++-
 drivers/thermal/samsung/exynos_tmu.h   |1 + 3 files
 changed, 199 insertions(+), 9 deletions(-)

 diff --git
 a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index
 0f44932..695150a 100644 ---
 a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@
 -12,6 +12,7 @@ samsung,exynos5420-tmu-ext-triminfo for TMU channels
 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock)
 samsung,exynos5440-tmu
 +samsung,exynos7-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 @@ -32,10 +33,13 @@
  - clocks : The main clocks for TMU device
   -- 1. operational clock for TMU channel
   -- 2. optional clock to access the shared registers of TMU
 channel
 + -- 3. optional special clock for functional operation
  - clock-names : Thermal system clock name
   -- tmu_apbif operational clock for current TMU channel
   -- tmu_triminfo_apbif clock to access the shared triminfo
 register for current TMU channel
 + -- tmu_sclk clock for functional operation of the current
 TMU
 + channel
  - 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.

 I would recommend splitting the documentation from the code. IMHO it
 would be more readable.

I will split the documentation out into a separate patch.


 diff --git a/drivers/thermal/samsung/exynos_tmu.c
 b/drivers/thermal/samsung/exynos_tmu.c index 633a9e2..8b26acb 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -119,6 +119,26 @@
  #define EXYNOS5440_TMU_TH_RISE4_SHIFT24
  #define EXYNOS5440_EFUSE_SWAP_OFFSET 8

 +/* Exynos7 specific registers */
 +#define EXYNOS7_THD_TEMP_RISE7_6 0x50
 +#define EXYNOS7_THD_TEMP_FALL7_6 0x60
 +#define EXYNOS7_TMU_REG_INTEN0x110
 +#define EXYNOS7_TMU_REG_INTPEND  0x118
 ^ I suppose that
 this misalignment is
 only done by my mail
 client and checkpatch
 is not complaining.

I re-ran checkpatch and it did not report any warnings, so perhaps it
is your e-mail client.

 +#define EXYNOS7_TMU_REG_EMUL_CON 0x160
 +
 +#define EXYNOS7_TMU_TEMP_MASK0x1ff
 +#define EXYNOS7_PD_DET_EN_SHIFT

[PATCH v3] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).

This patch adds special clock support required only for Exynos7
and updates the bindings documentation appropriately. It also updates
the "code_to_temp" prototype as Exynos7 has 9 bit code-temp mapping.

Signed-off-by: Abhilash Kesavan 
---
This patch is based on Lukasz Majewski's Exynos TMU v4 patchset:
http://www.spinics.net/lists/linux-samsung-soc/msg41183.html

Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.

 .../devicetree/bindings/thermal/exynos-thermal.txt |4 +
 drivers/thermal/samsung/exynos_tmu.c   |  203 +++-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 3 files changed, 199 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 0f44932..695150a 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -12,6 +12,7 @@
   "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
   "samsung,exynos5440-tmu"
+  "samsung,exynos7-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
@@ -32,10 +33,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- "tmu_apbif" operational clock for current TMU channel
-- "tmu_triminfo_apbif" clock to access the shared triminfo register
for current TMU channel
+   -- "tmu_sclk" clock for functional operation of the current TMU
+   channel
 - 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.
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 633a9e2..8b26acb 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6   0x50
+#define EXYNOS7_THD_TEMP_FALL7_6   0x60
+#define EXYNOS7_TMU_REG_INTEN  0x110
+#define EXYNOS7_TMU_REG_INTPEND0x118
+#define EXYNOS7_TMU_REG_EMUL_CON   0x160
+
+#define EXYNOS7_TMU_TEMP_MASK  0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT  0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT  1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT  2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT  3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT  4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT  5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT  6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT  7
+#define EXYNOS7_EMUL_DATA_SHIFT7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
 #define MCELSIUS   1000
 /**
  * struct exynos_tmu_data : A struc

[PATCH v3] thermal: exynos: Add TMU support for Exynos7 SoC

[Abhilash Kesavan]

Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).

This patch adds special clock support required only for Exynos7
and updates the bindings documentation appropriately. It also updates
the code_to_temp prototype as Exynos7 has 9 bit code-temp mapping.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
This patch is based on Lukasz Majewski's Exynos TMU v4 patchset:
http://www.spinics.net/lists/linux-samsung-soc/msg41183.html

Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.

 .../devicetree/bindings/thermal/exynos-thermal.txt |4 +
 drivers/thermal/samsung/exynos_tmu.c   |  203 +++-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 3 files changed, 199 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 0f44932..695150a 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -12,6 +12,7 @@
   samsung,exynos5420-tmu-ext-triminfo for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
   samsung,exynos5440-tmu
+  samsung,exynos7-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
@@ -32,10 +33,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- tmu_apbif operational clock for current TMU channel
-- tmu_triminfo_apbif clock to access the shared triminfo register
for current TMU channel
+   -- tmu_sclk clock for functional operation of the current TMU
+   channel
 - 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.
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 633a9e2..8b26acb 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6   0x50
+#define EXYNOS7_THD_TEMP_FALL7_6   0x60
+#define EXYNOS7_TMU_REG_INTEN  0x110
+#define EXYNOS7_TMU_REG_INTPEND0x118
+#define EXYNOS7_TMU_REG_EMUL_CON   0x160
+
+#define EXYNOS7_TMU_TEMP_MASK  0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT  0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT  1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT  2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT  3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT  4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT  5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT  6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT  7
+#define EXYNOS7_EMUL_DATA_SHIFT7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
 #define MCELSIUS   1000
 /**
  * struct exynos_tmu_data : A structure to hold the private data of the TMU
@@ -133,6 +153,7

Re: [PATCH 1/2] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Hi Greg,

On Thu, Dec 11, 2014 at 8:28 AM, Abhilash Kesavan  wrote:
> Implement a resource managed writecombine ioremap function.
>
> Signed-off-by: Abhilash Kesavan 
> ---
>  Documentation/driver-model/devres.txt |1 +
>  include/linux/io.h|2 ++
>  lib/devres.c  |   28 
>  3 files changed, 31 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt 
> b/Documentation/driver-model/devres.txt
> index b5ab416..0f80cee 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -274,6 +274,7 @@ IOMAP
>devm_ioport_unmap()
>devm_ioremap()
>devm_ioremap_nocache()
> +  devm_ioremap_wc()
>devm_ioremap_resource() : checks resource, requests memory region, ioremaps
>devm_iounmap()
>pcim_iomap()
> diff --git a/include/linux/io.h b/include/linux/io.h
> index fa02e55..42b33f0 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
> resource_size_t offset,
>resource_size_t size);
>  void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t 
> offset,
>resource_size_t size);
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +  resource_size_t size);
>  void devm_iounmap(struct device *dev, void __iomem *addr);
>  int check_signature(const volatile void __iomem *io_addr,
> const unsigned char *signature, int length);
> diff --git a/lib/devres.c b/lib/devres.c
> index 0f1dd2e..e8e1738 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
> resource_size_t offset,
>  EXPORT_SYMBOL(devm_ioremap_nocache);
>
>  /**
> + * devm_ioremap_wc - Managed ioremap_wc()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + *
> + * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +  resource_size_t size)
> +{
> +   void __iomem **ptr, *addr;
> +
> +   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> +   if (!ptr)
> +   return NULL;
> +
> +   addr = ioremap_wc(offset, size);

These two patches were applied yesterday to the char-misc tree, but
have broken build on m32r and maybe other platforms too which do not
have ioremap_wc defined. Unfortunately I missed catching this as I
built the patches only for arm64 and arm32, sorry for the trouble.
There was a patch posted a while back which added ioremap_wc for m32r
(https://lkml.org/lkml/2013/6/26/795). I would have to do something
similar for all the other archs which do not have it or is there some
other solution ?

Please drop these patches in the interim so that the build is fixed.

Regards,
Abhilash
> +   if (addr) {
> +   *ptr = addr;
> +   devres_add(dev, ptr);
> +   } else
> +   devres_free(ptr);
> +
> +   return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_wc);
> +
> +/**
>   * devm_iounmap - Managed iounmap()
>   * @dev: Generic device to unmap for
>   * @addr: Address to unmap
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Hi Greg,

On Thu, Dec 11, 2014 at 8:28 AM, Abhilash Kesavan a.kesa...@samsung.com wrote:
 Implement a resource managed writecombine ioremap function.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
  Documentation/driver-model/devres.txt |1 +
  include/linux/io.h|2 ++
  lib/devres.c  |   28 
  3 files changed, 31 insertions(+)

 diff --git a/Documentation/driver-model/devres.txt 
 b/Documentation/driver-model/devres.txt
 index b5ab416..0f80cee 100644
 --- a/Documentation/driver-model/devres.txt
 +++ b/Documentation/driver-model/devres.txt
 @@ -274,6 +274,7 @@ IOMAP
devm_ioport_unmap()
devm_ioremap()
devm_ioremap_nocache()
 +  devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_iounmap()
pcim_iomap()
 diff --git a/include/linux/io.h b/include/linux/io.h
 index fa02e55..42b33f0 100644
 --- a/include/linux/io.h
 +++ b/include/linux/io.h
 @@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
 resource_size_t offset,
resource_size_t size);
  void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t 
 offset,
resource_size_t size);
 +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
 +  resource_size_t size);
  void devm_iounmap(struct device *dev, void __iomem *addr);
  int check_signature(const volatile void __iomem *io_addr,
 const unsigned char *signature, int length);
 diff --git a/lib/devres.c b/lib/devres.c
 index 0f1dd2e..e8e1738 100644
 --- a/lib/devres.c
 +++ b/lib/devres.c
 @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
 resource_size_t offset,
  EXPORT_SYMBOL(devm_ioremap_nocache);

  /**
 + * devm_ioremap_wc - Managed ioremap_wc()
 + * @dev: Generic device to remap IO address for
 + * @offset: BUS offset to map
 + * @size: Size of map
 + *
 + * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
 + */
 +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
 +  resource_size_t size)
 +{
 +   void __iomem **ptr, *addr;
 +
 +   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
 +   if (!ptr)
 +   return NULL;
 +
 +   addr = ioremap_wc(offset, size);

These two patches were applied yesterday to the char-misc tree, but
have broken build on m32r and maybe other platforms too which do not
have ioremap_wc defined. Unfortunately I missed catching this as I
built the patches only for arm64 and arm32, sorry for the trouble.
There was a patch posted a while back which added ioremap_wc for m32r
(https://lkml.org/lkml/2013/6/26/795). I would have to do something
similar for all the other archs which do not have it or is there some
other solution ?

Please drop these patches in the interim so that the build is fixed.

Regards,
Abhilash
 +   if (addr) {
 +   *ptr = addr;
 +   devres_add(dev, ptr);
 +   } else
 +   devres_free(ptr);
 +
 +   return addr;
 +}
 +EXPORT_SYMBOL(devm_ioremap_wc);
 +
 +/**
   * devm_iounmap - Managed iounmap()
   * @dev: Generic device to unmap for
   * @addr: Address to unmap
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi Rob and Philipp,

On Tue, Jan 6, 2015 at 10:57 PM, Rob Herring  wrote:
> On Tue, Jan 6, 2015 at 10:54 AM, Philipp Zabel  wrote:
>> Hi Abhilash,
>>
>> Am Dienstag, den 06.01.2015, 19:57 +0530 schrieb Abhilash Kesavan:
>>> >> From the existing dts files, omap, imx, rockchip and exynos seem to be
>>> >> the only users of the sram allocator code. I have tested this on
>>> >> Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
>>> >> seen on these boards. Tested-by for other SoCs would be appreciated.
>>> >
>>> > Sorry for the delay, these seems to boot OK on omap4, so from that
>>> > point of view:
>>> >
>>> > Tested-by: Tony Lindgren 
>>>
>>> Thanks a lot for testing this. If someone with imx and rockchip boards
>>> could help test this out, then we could look to get this in.
>>
>> This shouldn't be a problem on i.MX, the coda driver doesn't access SRAM
>> from the CPU at all.
>
> Audio buffers are typically (perhaps not in mainline) in SRAM on i.MX
> chips which are accessed by CPU and probably mmap'ed to userspace.
> That could cause a mismatch in mappings although I would not expect
> both the kernel and user space to touch the buffer. That being said, I
> don't think this change should cause problems for i.MX (from what I
> can remember).

Thanks for the confirmation regarding the i.MX chips. That leaves
rockchip, can someone help with it please ?

Regards,
Abhilash
>
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi Rob and Philipp,

On Tue, Jan 6, 2015 at 10:57 PM, Rob Herring robherri...@gmail.com wrote:
 On Tue, Jan 6, 2015 at 10:54 AM, Philipp Zabel p.za...@pengutronix.de wrote:
 Hi Abhilash,

 Am Dienstag, den 06.01.2015, 19:57 +0530 schrieb Abhilash Kesavan:
  From the existing dts files, omap, imx, rockchip and exynos seem to be
  the only users of the sram allocator code. I have tested this on
  Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
  seen on these boards. Tested-by for other SoCs would be appreciated.
 
  Sorry for the delay, these seems to boot OK on omap4, so from that
  point of view:
 
  Tested-by: Tony Lindgren t...@atomide.com

 Thanks a lot for testing this. If someone with imx and rockchip boards
 could help test this out, then we could look to get this in.

 This shouldn't be a problem on i.MX, the coda driver doesn't access SRAM
 from the CPU at all.

 Audio buffers are typically (perhaps not in mainline) in SRAM on i.MX
 chips which are accessed by CPU and probably mmap'ed to userspace.
 That could cause a mismatch in mappings although I would not expect
 both the kernel and user space to touch the buffer. That being said, I
 don't think this change should cause problems for i.MX (from what I
 can remember).

Thanks for the confirmation regarding the i.MX chips. That leaves
rockchip, can someone help with it please ?

Regards,
Abhilash

 Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi Tony,

On Mon, Jan 5, 2015 at 11:48 PM, Tony Lindgren  wrote:
> * Abhilash Kesavan  [141217 04:37]:
>> Hi,
>>
>> On Thu, Dec 11, 2014 at 8:28 PM, Catalin Marinas
>>  wrote:
>> > On Thu, Dec 11, 2014 at 11:40:46AM +, Philipp Zabel wrote:
>> >> Hi Will,
>> >>
>> >> Am Donnerstag, den 11.12.2014, 10:39 + schrieb Will Deacon:
>> >> > On Thu, Dec 11, 2014 at 10:08:33AM +, Philipp Zabel wrote:
>> >> > > Hi Abhilash,
>> >> > >
>> >> > > Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
>> >> > > > Currently, the SRAM allocator returns device memory via ioremap.
>> >> > > > This causes issues on ARM64 when the internal SoC SRAM allocated by
>> >> > > > the generic sram driver is used for audio playback. The destination
>> >> > > > buffer address (which is ioremapped SRAM) is not 64-bit aligned for
>> >> > > > certain streams (e.g. 44.1k sampling rate). In such cases we get
>> >> > > > unhandled alignment faults. Use ioremap_wc in place of ioremap which
>> >> > > > gives us normal non-cacheable memory instead of device memory.
>> >> > >
>> >> > > Could this break the omap_bus_sync() implementation in
>> >> > > arch/arm/mach-omap2/omap4-common.c?
>> >> > >
>> >> > > void omap_bus_sync(void)
>> >> > > {
>> >> > > if (dram_sync && sram_sync) {
>> >> > > writel_relaxed(readl_relaxed(dram_sync), 
>> >> > > dram_sync);
>> >> > > writel_relaxed(readl_relaxed(sram_sync), 
>> >> > > sram_sync);
>> >> > > isb();
>> >> > > }
>> >> > > }
>> >> > >
>> >> > > It is used in wmb() and omap_do_wfi() to drain interconnect write
>> >> > > buffers on omap4/5. If sram_sync is mapped with write-combining, could
>> >> > > the last write to sram_sync stay stuck in the write-combining buffer
>> >> > > until after the function returns?
>> >> >
>> >> > I think you have that issue anyway, since you can get an early write
>> >> > response even if you use ioremap. Does the write to sram_sync have
>> >> > side-effects that we need to wait for?
>> >>
>> >> [Added Tony Lindgren and Santosh Shilimkar to Cc:]
>> >> I don't know.
>> >
>> > In addition to Will's question, do you care about the access size?
>> > ioremap() returns Device memory which is bufferable (early
>> > acknowledgement) but it guarantees the access size. With write
>> > combining, you may get a different access size than requested.
>>
>> From the existing dts files, omap, imx, rockchip and exynos seem to be
>> the only users of the sram allocator code. I have tested this on
>> Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
>> seen on these boards. Tested-by for other SoCs would be appreciated.
>
> Sorry for the delay, these seems to boot OK on omap4, so from that
> point of view:
>
> Tested-by: Tony Lindgren 

Thanks a lot for testing this. If someone with imx and rockchip boards
could help test this out, then we could look to get this in.

Regards,
Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi Tony,

On Mon, Jan 5, 2015 at 11:48 PM, Tony Lindgren t...@atomide.com wrote:
 * Abhilash Kesavan kesavan.abhil...@gmail.com [141217 04:37]:
 Hi,

 On Thu, Dec 11, 2014 at 8:28 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
  On Thu, Dec 11, 2014 at 11:40:46AM +, Philipp Zabel wrote:
  Hi Will,
 
  Am Donnerstag, den 11.12.2014, 10:39 + schrieb Will Deacon:
   On Thu, Dec 11, 2014 at 10:08:33AM +, Philipp Zabel wrote:
Hi Abhilash,
   
Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
 Currently, the SRAM allocator returns device memory via ioremap.
 This causes issues on ARM64 when the internal SoC SRAM allocated by
 the generic sram driver is used for audio playback. The destination
 buffer address (which is ioremapped SRAM) is not 64-bit aligned for
 certain streams (e.g. 44.1k sampling rate). In such cases we get
 unhandled alignment faults. Use ioremap_wc in place of ioremap which
 gives us normal non-cacheable memory instead of device memory.
   
Could this break the omap_bus_sync() implementation in
arch/arm/mach-omap2/omap4-common.c?
   
void omap_bus_sync(void)
{
if (dram_sync  sram_sync) {
writel_relaxed(readl_relaxed(dram_sync), 
dram_sync);
writel_relaxed(readl_relaxed(sram_sync), 
sram_sync);
isb();
}
}
   
It is used in wmb() and omap_do_wfi() to drain interconnect write
buffers on omap4/5. If sram_sync is mapped with write-combining, could
the last write to sram_sync stay stuck in the write-combining buffer
until after the function returns?
  
   I think you have that issue anyway, since you can get an early write
   response even if you use ioremap. Does the write to sram_sync have
   side-effects that we need to wait for?
 
  [Added Tony Lindgren and Santosh Shilimkar to Cc:]
  I don't know.
 
  In addition to Will's question, do you care about the access size?
  ioremap() returns Device memory which is bufferable (early
  acknowledgement) but it guarantees the access size. With write
  combining, you may get a different access size than requested.

 From the existing dts files, omap, imx, rockchip and exynos seem to be
 the only users of the sram allocator code. I have tested this on
 Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
 seen on these boards. Tested-by for other SoCs would be appreciated.

 Sorry for the delay, these seems to boot OK on omap4, so from that
 point of view:

 Tested-by: Tony Lindgren t...@atomide.com

Thanks a lot for testing this. If someone with imx and rockchip boards
could help test this out, then we could look to get this in.

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

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi,

On Thu, Dec 11, 2014 at 8:28 PM, Catalin Marinas
 wrote:
> On Thu, Dec 11, 2014 at 11:40:46AM +, Philipp Zabel wrote:
>> Hi Will,
>>
>> Am Donnerstag, den 11.12.2014, 10:39 + schrieb Will Deacon:
>> > On Thu, Dec 11, 2014 at 10:08:33AM +, Philipp Zabel wrote:
>> > > Hi Abhilash,
>> > >
>> > > Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
>> > > > Currently, the SRAM allocator returns device memory via ioremap.
>> > > > This causes issues on ARM64 when the internal SoC SRAM allocated by
>> > > > the generic sram driver is used for audio playback. The destination
>> > > > buffer address (which is ioremapped SRAM) is not 64-bit aligned for
>> > > > certain streams (e.g. 44.1k sampling rate). In such cases we get
>> > > > unhandled alignment faults. Use ioremap_wc in place of ioremap which
>> > > > gives us normal non-cacheable memory instead of device memory.
>> > >
>> > > Could this break the omap_bus_sync() implementation in
>> > > arch/arm/mach-omap2/omap4-common.c?
>> > >
>> > > void omap_bus_sync(void)
>> > > {
>> > > if (dram_sync && sram_sync) {
>> > > writel_relaxed(readl_relaxed(dram_sync), dram_sync);
>> > > writel_relaxed(readl_relaxed(sram_sync), sram_sync);
>> > > isb();
>> > > }
>> > > }
>> > >
>> > > It is used in wmb() and omap_do_wfi() to drain interconnect write
>> > > buffers on omap4/5. If sram_sync is mapped with write-combining, could
>> > > the last write to sram_sync stay stuck in the write-combining buffer
>> > > until after the function returns?
>> >
>> > I think you have that issue anyway, since you can get an early write
>> > response even if you use ioremap. Does the write to sram_sync have
>> > side-effects that we need to wait for?
>>
>> [Added Tony Lindgren and Santosh Shilimkar to Cc:]
>> I don't know.
>
> In addition to Will's question, do you care about the access size?
> ioremap() returns Device memory which is bufferable (early
> acknowledgement) but it guarantees the access size. With write
> combining, you may get a different access size than requested.

>From the existing dts files, omap, imx, rockchip and exynos seem to be
the only users of the sram allocator code. I have tested this on
Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
seen on these boards. Tested-by for other SoCs would be appreciated.

Regards,
Abhilash
>
> --
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Hi,

On Thu, Dec 11, 2014 at 8:28 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
 On Thu, Dec 11, 2014 at 11:40:46AM +, Philipp Zabel wrote:
 Hi Will,

 Am Donnerstag, den 11.12.2014, 10:39 + schrieb Will Deacon:
  On Thu, Dec 11, 2014 at 10:08:33AM +, Philipp Zabel wrote:
   Hi Abhilash,
  
   Am Donnerstag, den 11.12.2014, 08:28 +0530 schrieb Abhilash Kesavan:
Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.
  
   Could this break the omap_bus_sync() implementation in
   arch/arm/mach-omap2/omap4-common.c?
  
   void omap_bus_sync(void)
   {
   if (dram_sync  sram_sync) {
   writel_relaxed(readl_relaxed(dram_sync), dram_sync);
   writel_relaxed(readl_relaxed(sram_sync), sram_sync);
   isb();
   }
   }
  
   It is used in wmb() and omap_do_wfi() to drain interconnect write
   buffers on omap4/5. If sram_sync is mapped with write-combining, could
   the last write to sram_sync stay stuck in the write-combining buffer
   until after the function returns?
 
  I think you have that issue anyway, since you can get an early write
  response even if you use ioremap. Does the write to sram_sync have
  side-effects that we need to wait for?

 [Added Tony Lindgren and Santosh Shilimkar to Cc:]
 I don't know.

 In addition to Will's question, do you care about the access size?
 ioremap() returns Device memory which is bufferable (early
 acknowledgement) but it guarantees the access size. With write
 combining, you may get a different access size than requested.

From the existing dts files, omap, imx, rockchip and exynos seem to be
the only users of the sram allocator code. I have tested this on
Exynos5420, Exynos5800 and Exynos7; there is no change in behavior
seen on these boards. Tested-by for other SoCs would be appreciated.

Regards,
Abhilash

 --
 Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.

Signed-off-by: Abhilash Kesavan 
---
This is based on the discussion about the crash here:
http://www.spinics.net/lists/arm-kernel/msg384647.html

 drivers/misc/sram.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..15b4d4e 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -69,12 +69,23 @@ static int sram_probe(struct platform_device *pdev)
INIT_LIST_HEAD(_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   virt_base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(virt_base))
-   return PTR_ERR(virt_base);
+   if (!res) {
+   dev_err(>dev, "found no memory resource\n");
+   return -EINVAL;
+   }
 
size = resource_size(res);
 
+   if (!devm_request_mem_region(>dev,
+   res->start, size, pdev->name)) {
+   dev_err(>dev, "could not request region for resource\n");
+   return -EBUSY;
+   }
+
+   virt_base = devm_ioremap_wc(>dev, res->start, size);
+   if (IS_ERR(virt_base))
+   return PTR_ERR(virt_base);
+
sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
return -ENOMEM;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Implement a resource managed writecombine ioremap function.

Signed-off-by: Abhilash Kesavan 
---
 Documentation/driver-model/devres.txt |1 +
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 3 files changed, 31 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index b5ab416..0f80cee 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -274,6 +274,7 @@ IOMAP
   devm_ioport_unmap()
   devm_ioremap()
   devm_ioremap_nocache()
+  devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_iounmap()
   pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index fa02e55..42b33f0 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
resource_size_t offset,
   resource_size_t size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
   resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..e8e1738 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_wc(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] lib: devres: add a helper function for ioremap_wc

[Abhilash Kesavan]

Implement a resource managed writecombine ioremap function.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 Documentation/driver-model/devres.txt |1 +
 include/linux/io.h|2 ++
 lib/devres.c  |   28 
 3 files changed, 31 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index b5ab416..0f80cee 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -274,6 +274,7 @@ IOMAP
   devm_ioport_unmap()
   devm_ioremap()
   devm_ioremap_nocache()
+  devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_iounmap()
   pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index fa02e55..42b33f0 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
resource_size_t offset,
   resource_size_t size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
   resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..e8e1738 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+  resource_size_t size)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_wc(offset, size);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap

[Abhilash Kesavan]

Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
This is based on the discussion about the crash here:
http://www.spinics.net/lists/arm-kernel/msg384647.html

 drivers/misc/sram.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..15b4d4e 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -69,12 +69,23 @@ static int sram_probe(struct platform_device *pdev)
INIT_LIST_HEAD(reserve_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   virt_base = devm_ioremap_resource(pdev-dev, res);
-   if (IS_ERR(virt_base))
-   return PTR_ERR(virt_base);
+   if (!res) {
+   dev_err(pdev-dev, found no memory resource\n);
+   return -EINVAL;
+   }
 
size = resource_size(res);
 
+   if (!devm_request_mem_region(pdev-dev,
+   res-start, size, pdev-name)) {
+   dev_err(pdev-dev, could not request region for resource\n);
+   return -EBUSY;
+   }
+
+   virt_base = devm_ioremap_wc(pdev-dev, res-start, size);
+   if (IS_ERR(virt_base))
+   return PTR_ERR(virt_base);
+
sram = devm_kzalloc(pdev-dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
return -ENOMEM;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Bartlomiej and Lukasz,

On Wed, Nov 26, 2014 at 9:01 PM, Abhilash Kesavan
 wrote:
> Hi Eduardo,
>
> On Wed, Nov 26, 2014 at 8:44 PM, Eduardo Valentin  wrote:
>> Abhilash,
>>
>> On Wed, Nov 26, 2014 at 08:34:19PM +0530, Abhilash Kesavan wrote:
>>> Hi Eduardo,
>>>
>>> On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin  
>>> wrote:
>>> >
>>> > Abhilash,
>>> >
>>> > On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
>>> >> Exynos7 has a special clock required for the functional operation
>>> >> of the TMU that is not present in earlier SoCs. Add support for
>>> >> this clock and update the binding documentation.
>>> >>
>>> >> Signed-off-by: Abhilash Kesavan 
>>> >> ---
>>> >> Changes since v1:
>>> >>   - Added a per-soc flag to indicate the presence of special clock
>>> >>   - Changed the name of special clock from "tmu_sclk" to "sclk"
>>> >>   - Fixed the error handling for sclk
>>> >>
>>> >> Tested on 5420 and 5800 based chromebooks, no change in existing 
>>> >> behavior.
>>> >>
>>> >>  .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
>>> >>  drivers/thermal/samsung/exynos_tmu.c   |   31 
>>> >> 
>>> >>  2 files changed, 29 insertions(+), 5 deletions(-)
>>> >>
>>> >> diff --git 
>>> >> a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>>> >> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>> >> index ae738f5..acf4705 100644
>>> >> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>> >> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>> >> @@ -32,10 +32,13 @@
>>> >>  - clocks : The main clocks for TMU device
>>> >>   -- 1. operational clock for TMU channel
>>> >>   -- 2. optional clock to access the shared registers of TMU channel
>>> >> + -- 3. optional special clock for functional operation
>>> >>  - clock-names : Thermal system clock name
>>> >>   -- "tmu_apbif" operational clock for current TMU channel
>>> >>   -- "tmu_triminfo_apbif" clock to access the shared triminfo 
>>> >> register
>>> >>   for current TMU channel
>>> >> + -- "sclk" clock for functional operation of the current TMU
>>> >> + channel
>>> >>  - 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.
>>> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>>> >> b/drivers/thermal/samsung/exynos_tmu.c
>>> >> index d44d91d..8ed8409 100644
>>> >> --- a/drivers/thermal/samsung/exynos_tmu.c
>>> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
>>> >> @@ -123,11 +123,14 @@
>>> >>   * @base: base address of the single instance of the TMU controller.
>>> >>   * @base_second: base address of the common registers of the TMU 
>>> >> controller.
>>> >>   * @irq: irq number of the TMU controller.
>>> >> + * @needs_sclk: SoC specific flag indicating that sclk is required for
>>> >> + functional operation 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.
>>> >>   * @clk_sec: pointer to the clock structure for accessing the 
>>> >> base_second.
>>> >> + * @sclk: pointer to the clock structure for accessing the tmu special 
>>> >> clock.
>>> >>   * @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.
>>> >> @@ -144,10 +147,11 @@ struct exynos_tmu_data {
>>> >>   void __iomem *base;
>>> >>   void __iomem *base_second;
>>> >>   int irq;
>&g

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Bartlomiej and Lukasz,

On Wed, Nov 26, 2014 at 9:01 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Eduardo,

 On Wed, Nov 26, 2014 at 8:44 PM, Eduardo Valentin edubez...@gmail.com wrote:
 Abhilash,

 On Wed, Nov 26, 2014 at 08:34:19PM +0530, Abhilash Kesavan wrote:
 Hi Eduardo,

 On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin edubez...@gmail.com 
 wrote:
 
  Abhilash,
 
  On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
  Exynos7 has a special clock required for the functional operation
  of the TMU that is not present in earlier SoCs. Add support for
  this clock and update the binding documentation.
 
  Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
  ---
  Changes since v1:
- Added a per-soc flag to indicate the presence of special clock
- Changed the name of special clock from tmu_sclk to sclk
- Fixed the error handling for sclk
 
  Tested on 5420 and 5800 based chromebooks, no change in existing 
  behavior.
 
   .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
   drivers/thermal/samsung/exynos_tmu.c   |   31 
  
   2 files changed, 29 insertions(+), 5 deletions(-)
 
  diff --git 
  a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
  b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  index ae738f5..acf4705 100644
  --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  @@ -32,10 +32,13 @@
   - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
  + -- 3. optional special clock for functional operation
   - clock-names : Thermal system clock name
-- tmu_apbif operational clock for current TMU channel
-- tmu_triminfo_apbif clock to access the shared triminfo 
  register
for current TMU channel
  + -- sclk clock for functional operation of the current TMU
  + channel
   - 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.
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index d44d91d..8ed8409 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -123,11 +123,14 @@
* @base: base address of the single instance of the TMU controller.
* @base_second: base address of the common registers of the TMU 
  controller.
* @irq: irq number of the TMU controller.
  + * @needs_sclk: SoC specific flag indicating that sclk is required for
  + functional operation 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.
* @clk_sec: pointer to the clock structure for accessing the 
  base_second.
  + * @sclk: pointer to the clock structure for accessing the tmu special 
  clock.
* @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.
  @@ -144,10 +147,11 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
  + bool needs_sclk;
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
  - struct clk *clk, *clk_sec;
  + struct clk *clk, *clk_sec, *sclk;
u8 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
  @@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device 
  *pdev)
goto err_clk_sec;
}
 
  + if (data-needs_sclk) {
 
  Based on the trend we see from Bartlomiej's and Lukasz' works, you
  should be asking for SoC version, not adding a flag. Can you please
  crosscheck with them?

 I planned to populate this flag as true for Exynos7 in
 exynos_map_dt_data() where other soc specific methods are being setup.

 Well, that I wouldn't expect different, otherwise how your code is
 supposed to work, right?

 yes :)



 Bartlomiej/Lukasz can you kindly comment on if you would prefer the
 check to be based on the SoC version.



 Have a look on how Bartz has removed the flag based code in my -linus
 branch. Here is an example:
 https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linusid=ef3f80fc7f79c32a1b015afcbffce2a2630011a4

 OK, I see what you mean. I'll wait for Bartlomiej and Lukasz to weigh
 in as well. If they are in favor of using the SoC version then I will
 fold this into the patch adding support for Exynos7 (to be posted
 after all of Lukasz' patches are in)

Can you comment

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Eduardo,

On Wed, Nov 26, 2014 at 8:44 PM, Eduardo Valentin  wrote:
> Abhilash,
>
> On Wed, Nov 26, 2014 at 08:34:19PM +0530, Abhilash Kesavan wrote:
>> Hi Eduardo,
>>
>> On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin  
>> wrote:
>> >
>> > Abhilash,
>> >
>> > On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
>> >> Exynos7 has a special clock required for the functional operation
>> >> of the TMU that is not present in earlier SoCs. Add support for
>> >> this clock and update the binding documentation.
>> >>
>> >> Signed-off-by: Abhilash Kesavan 
>> >> ---
>> >> Changes since v1:
>> >>   - Added a per-soc flag to indicate the presence of special clock
>> >>   - Changed the name of special clock from "tmu_sclk" to "sclk"
>> >>   - Fixed the error handling for sclk
>> >>
>> >> Tested on 5420 and 5800 based chromebooks, no change in existing behavior.
>> >>
>> >>  .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
>> >>  drivers/thermal/samsung/exynos_tmu.c   |   31 
>> >> 
>> >>  2 files changed, 29 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> >> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> >> index ae738f5..acf4705 100644
>> >> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> >> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> >> @@ -32,10 +32,13 @@
>> >>  - clocks : The main clocks for TMU device
>> >>   -- 1. operational clock for TMU channel
>> >>   -- 2. optional clock to access the shared registers of TMU channel
>> >> + -- 3. optional special clock for functional operation
>> >>  - clock-names : Thermal system clock name
>> >>   -- "tmu_apbif" operational clock for current TMU channel
>> >>   -- "tmu_triminfo_apbif" clock to access the shared triminfo register
>> >>   for current TMU channel
>> >> + -- "sclk" clock for functional operation of the current TMU
>> >> + channel
>> >>  - 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.
>> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> >> b/drivers/thermal/samsung/exynos_tmu.c
>> >> index d44d91d..8ed8409 100644
>> >> --- a/drivers/thermal/samsung/exynos_tmu.c
>> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> >> @@ -123,11 +123,14 @@
>> >>   * @base: base address of the single instance of the TMU controller.
>> >>   * @base_second: base address of the common registers of the TMU 
>> >> controller.
>> >>   * @irq: irq number of the TMU controller.
>> >> + * @needs_sclk: SoC specific flag indicating that sclk is required for
>> >> + functional operation 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.
>> >>   * @clk_sec: pointer to the clock structure for accessing the 
>> >> base_second.
>> >> + * @sclk: pointer to the clock structure for accessing the tmu special 
>> >> clock.
>> >>   * @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.
>> >> @@ -144,10 +147,11 @@ struct exynos_tmu_data {
>> >>   void __iomem *base;
>> >>   void __iomem *base_second;
>> >>   int irq;
>> >> + bool needs_sclk;
>> >>   enum soc_type soc;
>> >>   struct work_struct irq_work;
>> >>   struct mutex lock;
>> >> - struct clk *clk, *clk_sec;
>> >> + struct clk *clk, *clk_sec, *sclk;
>> >>   u8 temp_error1, temp_error2;
>> >>   struct regulator *regulator;
>> >>   struct thermal_sensor_conf *reg_conf;
>> >> @@ 

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Eduardo,

On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin  wrote:
>
> Abhilash,
>
> On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
>> Exynos7 has a special clock required for the functional operation
>> of the TMU that is not present in earlier SoCs. Add support for
>> this clock and update the binding documentation.
>>
>> Signed-off-by: Abhilash Kesavan 
>> ---
>> Changes since v1:
>>   - Added a per-soc flag to indicate the presence of special clock
>>   - Changed the name of special clock from "tmu_sclk" to "sclk"
>>   - Fixed the error handling for sclk
>>
>> Tested on 5420 and 5800 based chromebooks, no change in existing behavior.
>>
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
>>  drivers/thermal/samsung/exynos_tmu.c   |   31 
>> 
>>  2 files changed, 29 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index ae738f5..acf4705 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -32,10 +32,13 @@
>>  - clocks : The main clocks for TMU device
>>   -- 1. operational clock for TMU channel
>>   -- 2. optional clock to access the shared registers of TMU channel
>> + -- 3. optional special clock for functional operation
>>  - clock-names : Thermal system clock name
>>   -- "tmu_apbif" operational clock for current TMU channel
>>   -- "tmu_triminfo_apbif" clock to access the shared triminfo register
>>   for current TMU channel
>> + -- "sclk" clock for functional operation of the current TMU
>> + channel
>>  - 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.
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index d44d91d..8ed8409 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -123,11 +123,14 @@
>>   * @base: base address of the single instance of the TMU controller.
>>   * @base_second: base address of the common registers of the TMU controller.
>>   * @irq: irq number of the TMU controller.
>> + * @needs_sclk: SoC specific flag indicating that sclk is required for
>> + functional operation 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.
>>   * @clk_sec: pointer to the clock structure for accessing the base_second.
>> + * @sclk: pointer to the clock structure for accessing the tmu special 
>> clock.
>>   * @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.
>> @@ -144,10 +147,11 @@ struct exynos_tmu_data {
>>   void __iomem *base;
>>   void __iomem *base_second;
>>   int irq;
>> + bool needs_sclk;
>>   enum soc_type soc;
>>   struct work_struct irq_work;
>>   struct mutex lock;
>> - struct clk *clk, *clk_sec;
>> + struct clk *clk, *clk_sec, *sclk;
>>   u8 temp_error1, temp_error2;
>>   struct regulator *regulator;
>>   struct thermal_sensor_conf *reg_conf;
>> @@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device 
>> *pdev)
>>   goto err_clk_sec;
>>   }
>>
>> + if (data->needs_sclk) {
>
> Based on the trend we see from Bartlomiej's and Lukasz' works, you
> should be asking for SoC version, not adding a flag. Can you please
> crosscheck with them?

I planned to populate this flag as true for Exynos7 in
exynos_map_dt_data() where other soc specific methods are being setup.

Bartlomiej/Lukasz can you kindly comment on if you would prefer the
check to be based on the SoC version.

Regards,
Abhilash
>
> Cheers,
>
> Eduardo Valentin
>
>> + data->sclk = devm_clk_get(>dev, "sclk");
>> + if (IS_ERR(data->sclk)) {
>> + dev_err(>dev, "Failed to get sclk\n");
>> + goto err

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Eduardo,

On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin edubez...@gmail.com wrote:

 Abhilash,

 On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
 Exynos7 has a special clock required for the functional operation
 of the TMU that is not present in earlier SoCs. Add support for
 this clock and update the binding documentation.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
 Changes since v1:
   - Added a per-soc flag to indicate the presence of special clock
   - Changed the name of special clock from tmu_sclk to sclk
   - Fixed the error handling for sclk

 Tested on 5420 and 5800 based chromebooks, no change in existing behavior.

  .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
  drivers/thermal/samsung/exynos_tmu.c   |   31 
 
  2 files changed, 29 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 index ae738f5..acf4705 100644
 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
 @@ -32,10 +32,13 @@
  - clocks : The main clocks for TMU device
   -- 1. operational clock for TMU channel
   -- 2. optional clock to access the shared registers of TMU channel
 + -- 3. optional special clock for functional operation
  - clock-names : Thermal system clock name
   -- tmu_apbif operational clock for current TMU channel
   -- tmu_triminfo_apbif clock to access the shared triminfo register
   for current TMU channel
 + -- sclk clock for functional operation of the current TMU
 + channel
  - 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.
 diff --git a/drivers/thermal/samsung/exynos_tmu.c 
 b/drivers/thermal/samsung/exynos_tmu.c
 index d44d91d..8ed8409 100644
 --- a/drivers/thermal/samsung/exynos_tmu.c
 +++ b/drivers/thermal/samsung/exynos_tmu.c
 @@ -123,11 +123,14 @@
   * @base: base address of the single instance of the TMU controller.
   * @base_second: base address of the common registers of the TMU controller.
   * @irq: irq number of the TMU controller.
 + * @needs_sclk: SoC specific flag indicating that sclk is required for
 + functional operation 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.
   * @clk_sec: pointer to the clock structure for accessing the base_second.
 + * @sclk: pointer to the clock structure for accessing the tmu special 
 clock.
   * @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.
 @@ -144,10 +147,11 @@ struct exynos_tmu_data {
   void __iomem *base;
   void __iomem *base_second;
   int irq;
 + bool needs_sclk;
   enum soc_type soc;
   struct work_struct irq_work;
   struct mutex lock;
 - struct clk *clk, *clk_sec;
 + struct clk *clk, *clk_sec, *sclk;
   u8 temp_error1, temp_error2;
   struct regulator *regulator;
   struct thermal_sensor_conf *reg_conf;
 @@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device 
 *pdev)
   goto err_clk_sec;
   }

 + if (data-needs_sclk) {

 Based on the trend we see from Bartlomiej's and Lukasz' works, you
 should be asking for SoC version, not adding a flag. Can you please
 crosscheck with them?

I planned to populate this flag as true for Exynos7 in
exynos_map_dt_data() where other soc specific methods are being setup.

Bartlomiej/Lukasz can you kindly comment on if you would prefer the
check to be based on the SoC version.

Regards,
Abhilash

 Cheers,

 Eduardo Valentin

 + data-sclk = devm_clk_get(pdev-dev, sclk);
 + if (IS_ERR(data-sclk)) {
 + dev_err(pdev-dev, Failed to get sclk\n);
 + goto err_clk;
 + } else {
 + ret = clk_prepare_enable(data-sclk);
 + if (ret) {
 + dev_err(pdev-dev, Failed to enable sclk\n);
 + goto err_clk;
 + }
 + }
 + }
 +
   ret = exynos_tmu_initialize(pdev);
   if (ret) {
   dev_err(pdev-dev, Failed to initialize TMU\n);
 - goto err_clk;
 + goto err_sclk;
   }

   exynos_tmu_control(pdev, true);
 @@ -896,7 +914,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
   sizeof(struct thermal_sensor_conf), 
 GFP_KERNEL);
   if (!sensor_conf) {
   ret = -ENOMEM;
 - goto

Re: [PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Hi Eduardo,

On Wed, Nov 26, 2014 at 8:44 PM, Eduardo Valentin edubez...@gmail.com wrote:
 Abhilash,

 On Wed, Nov 26, 2014 at 08:34:19PM +0530, Abhilash Kesavan wrote:
 Hi Eduardo,

 On Wed, Nov 26, 2014 at 8:15 PM, Eduardo Valentin edubez...@gmail.com 
 wrote:
 
  Abhilash,
 
  On Wed, Nov 26, 2014 at 06:21:10AM +0530, Abhilash Kesavan wrote:
  Exynos7 has a special clock required for the functional operation
  of the TMU that is not present in earlier SoCs. Add support for
  this clock and update the binding documentation.
 
  Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
  ---
  Changes since v1:
- Added a per-soc flag to indicate the presence of special clock
- Changed the name of special clock from tmu_sclk to sclk
- Fixed the error handling for sclk
 
  Tested on 5420 and 5800 based chromebooks, no change in existing behavior.
 
   .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
   drivers/thermal/samsung/exynos_tmu.c   |   31 
  
   2 files changed, 29 insertions(+), 5 deletions(-)
 
  diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
  b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  index ae738f5..acf4705 100644
  --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
  @@ -32,10 +32,13 @@
   - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
  + -- 3. optional special clock for functional operation
   - clock-names : Thermal system clock name
-- tmu_apbif operational clock for current TMU channel
-- tmu_triminfo_apbif clock to access the shared triminfo register
for current TMU channel
  + -- sclk clock for functional operation of the current TMU
  + channel
   - 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.
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index d44d91d..8ed8409 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -123,11 +123,14 @@
* @base: base address of the single instance of the TMU controller.
* @base_second: base address of the common registers of the TMU 
  controller.
* @irq: irq number of the TMU controller.
  + * @needs_sclk: SoC specific flag indicating that sclk is required for
  + functional operation 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.
* @clk_sec: pointer to the clock structure for accessing the 
  base_second.
  + * @sclk: pointer to the clock structure for accessing the tmu special 
  clock.
* @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.
  @@ -144,10 +147,11 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
  + bool needs_sclk;
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
  - struct clk *clk, *clk_sec;
  + struct clk *clk, *clk_sec, *sclk;
u8 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
  @@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device 
  *pdev)
goto err_clk_sec;
}
 
  + if (data-needs_sclk) {
 
  Based on the trend we see from Bartlomiej's and Lukasz' works, you
  should be asking for SoC version, not adding a flag. Can you please
  crosscheck with them?

 I planned to populate this flag as true for Exynos7 in
 exynos_map_dt_data() where other soc specific methods are being setup.

 Well, that I wouldn't expect different, otherwise how your code is
 supposed to work, right?

yes :)



 Bartlomiej/Lukasz can you kindly comment on if you would prefer the
 check to be based on the SoC version.



 Have a look on how Bartz has removed the flag based code in my -linus
 branch. Here is an example:
 https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linusid=ef3f80fc7f79c32a1b015afcbffce2a2630011a4

OK, I see what you mean. I'll wait for Bartlomiej and Lukasz to weigh
in as well. If they are in favor of using the SoC version then I will
fold this into the patch adding support for Exynos7 (to be posted
after all of Lukasz' patches are in)

Thanks,
Abhilash

 Regards,
 Abhilash
 
  Cheers,
 
  Eduardo Valentin
 
  + data-sclk = devm_clk_get(pdev-dev, sclk

[PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Exynos7 has a special clock required for the functional operation
of the TMU that is not present in earlier SoCs. Add support for
this clock and update the binding documentation.

Signed-off-by: Abhilash Kesavan 
---
Changes since v1:
- Added a per-soc flag to indicate the presence of special clock
- Changed the name of special clock from "tmu_sclk" to "sclk"
- Fixed the error handling for sclk

Tested on 5420 and 5800 based chromebooks, no change in existing behavior.

 .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
 drivers/thermal/samsung/exynos_tmu.c   |   31 
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index ae738f5..acf4705 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -32,10 +32,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- "tmu_apbif" operational clock for current TMU channel
-- "tmu_triminfo_apbif" clock to access the shared triminfo register
for current TMU channel
+   -- "sclk" clock for functional operation of the current TMU
+   channel
 - 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.
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index d44d91d..8ed8409 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -123,11 +123,14 @@
  * @base: base address of the single instance of the TMU controller.
  * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
+ * @needs_sclk: SoC specific flag indicating that sclk is required for
+   functional operation 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.
  * @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clock.
  * @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.
@@ -144,10 +147,11 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
+   bool needs_sclk;
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
-   struct clk *clk, *clk_sec;
+   struct clk *clk, *clk_sec, *sclk;
u8 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
@@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
 
+   if (data->needs_sclk) {
+   data->sclk = devm_clk_get(>dev, "sclk");
+   if (IS_ERR(data->sclk)) {
+   dev_err(>dev, "Failed to get sclk\n");
+   goto err_clk;
+   } else {
+   ret = clk_prepare_enable(data->sclk);
+   if (ret) {
+   dev_err(>dev, "Failed to enable sclk\n");
+   goto err_clk;
+   }
+   }
+   }
+
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(>dev, "Failed to initialize TMU\n");
-   goto err_clk;
+   goto err_sclk;
}
 
exynos_tmu_control(pdev, true);
@@ -896,7 +914,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
sizeof(struct thermal_sensor_conf), GFP_KERNEL);
if (!sensor_conf) {
ret = -ENOMEM;
-   goto err_clk;
+   goto err_sclk;
}
sprintf(sensor_conf->name, "therm_zone%d", data->id);
sensor_conf->read_temperature = (int (*)(void *))exynos_tmu_read;
@@ -928,7 +946,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
ret = exynos_register_thermal(sensor_conf);
if (ret) {
dev_err(>dev, "Failed to register thermal interface\n");
-   goto err_clk;
+

[PATCH v2] thermal: exynos: add special clock support

[Abhilash Kesavan]

Exynos7 has a special clock required for the functional operation
of the TMU that is not present in earlier SoCs. Add support for
this clock and update the binding documentation.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
Changes since v1:
- Added a per-soc flag to indicate the presence of special clock
- Changed the name of special clock from tmu_sclk to sclk
- Fixed the error handling for sclk

Tested on 5420 and 5800 based chromebooks, no change in existing behavior.

 .../devicetree/bindings/thermal/exynos-thermal.txt |3 ++
 drivers/thermal/samsung/exynos_tmu.c   |   31 
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index ae738f5..acf4705 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -32,10 +32,13 @@
 - clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
+   -- 3. optional special clock for functional operation
 - clock-names : Thermal system clock name
-- tmu_apbif operational clock for current TMU channel
-- tmu_triminfo_apbif clock to access the shared triminfo register
for current TMU channel
+   -- sclk clock for functional operation of the current TMU
+   channel
 - 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.
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index d44d91d..8ed8409 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -123,11 +123,14 @@
  * @base: base address of the single instance of the TMU controller.
  * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
+ * @needs_sclk: SoC specific flag indicating that sclk is required for
+   functional operation 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.
  * @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clock.
  * @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.
@@ -144,10 +147,11 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
+   bool needs_sclk;
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
-   struct clk *clk, *clk_sec;
+   struct clk *clk, *clk_sec, *sclk;
u8 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
@@ -883,10 +887,24 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
 
+   if (data-needs_sclk) {
+   data-sclk = devm_clk_get(pdev-dev, sclk);
+   if (IS_ERR(data-sclk)) {
+   dev_err(pdev-dev, Failed to get sclk\n);
+   goto err_clk;
+   } else {
+   ret = clk_prepare_enable(data-sclk);
+   if (ret) {
+   dev_err(pdev-dev, Failed to enable sclk\n);
+   goto err_clk;
+   }
+   }
+   }
+
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(pdev-dev, Failed to initialize TMU\n);
-   goto err_clk;
+   goto err_sclk;
}
 
exynos_tmu_control(pdev, true);
@@ -896,7 +914,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
sizeof(struct thermal_sensor_conf), GFP_KERNEL);
if (!sensor_conf) {
ret = -ENOMEM;
-   goto err_clk;
+   goto err_sclk;
}
sprintf(sensor_conf-name, therm_zone%d, data-id);
sensor_conf-read_temperature = (int (*)(void *))exynos_tmu_read;
@@ -928,7 +946,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
ret = exynos_register_thermal(sensor_conf);
if (ret) {
dev_err(pdev-dev, Failed to register thermal interface\n);
-   goto err_clk;
+   goto err_sclk;
}
data-reg_conf = sensor_conf;
 
@@ -936,10 +954,12 @@ static int exynos_tmu_probe(struct platform_device *pdev

[PATCH v2] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

From: Pankaj Dubey 

Exynos7 has a similar serial controller to that present in older Samsung
SoCs. To re-use the existing serial driver on Exynos7 we need to have
SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
possible because these symbols are dependent on PLAT_SAMSUNG which is
not present for the ARMv8 based exynos7.

Change the dependency of these symbols from PLAT_SAMSUNG to the serial
driver thus making it available on exynos7. As the existing platform
specific code making use of these symbols is related to uart driver this
change in dependency should not cause any issues.

Signed-off-by: Pankaj Dubey 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Abhilash Kesavan 
Cc: Greg Kroah-Hartman 
Acked-by: Greg Kroah-Hartman 
---
Changes in v2:
- Added Greg's ack and Kukjin Kim as a recepient

 drivers/tty/serial/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index e71a28b..d0ce88c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
 
 config SERIAL_SAMSUNG_UARTS_4
bool
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
help
  Internal node for the common case of 4 Samsung compatible UARTs
 
 config SERIAL_SAMSUNG_UARTS
int
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
help
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hi Kukjin,

On Wed, Nov 19, 2014 at 12:58 PM, Kukjin Kim  wrote:
> On 11/18/14 03:59, Greg KH wrote:
>> On Mon, Nov 17, 2014 at 10:14:51AM +0530, Abhilash Kesavan wrote:
>>> From: Pankaj Dubey 
>>>
>>> Exynos7 has a similar serial controller to that present in older Samsung
>>> SoCs. To re-use the existing serial driver on Exynos7 we need to have
>>> SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
>>> possible because these symbols are dependent on PLAT_SAMSUNG which is
>>> not present for the ARMv8 based exynos7.
>>>
>>> Change the dependency of these symbols from PLAT_SAMSUNG to the serial
>>> driver thus making it available on exynos7. As the existing platform
>>> specific code making use of these symbols is related to uart driver this
>>> change in dependency should not cause any issues.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>> Signed-off-by: Naveen Krishna Chatradhi 
>>> Signed-off-by: Abhilash Kesavan 
>>> Cc: Greg Kroah-Hartman 
>>> ---
>> Acked-by: Greg Kroah-Hartman 
>>
> Greg, thanks for your ack on this.
>
> Abhilash,
>
> I can't find the original patch in my mailbox, can you please re-send to
> me with adding Greg's ack?

Will send it you with Greg's Ack.

Thanks,
Abhilash
>
> Thanks,
> Kukjin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hi Kukjin,

On Wed, Nov 19, 2014 at 12:58 PM, Kukjin Kim kgene@samsung.com wrote:
 On 11/18/14 03:59, Greg KH wrote:
 On Mon, Nov 17, 2014 at 10:14:51AM +0530, Abhilash Kesavan wrote:
 From: Pankaj Dubey pankaj.du...@samsung.com

 Exynos7 has a similar serial controller to that present in older Samsung
 SoCs. To re-use the existing serial driver on Exynos7 we need to have
 SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
 possible because these symbols are dependent on PLAT_SAMSUNG which is
 not present for the ARMv8 based exynos7.

 Change the dependency of these symbols from PLAT_SAMSUNG to the serial
 driver thus making it available on exynos7. As the existing platform
 specific code making use of these symbols is related to uart driver this
 change in dependency should not cause any issues.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
 Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

 Greg, thanks for your ack on this.

 Abhilash,

 I can't find the original patch in my mailbox, can you please re-send to
 me with adding Greg's ack?

Will send it you with Greg's Ack.

Thanks,
Abhilash

 Thanks,
 Kukjin
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

From: Pankaj Dubey pankaj.du...@samsung.com

Exynos7 has a similar serial controller to that present in older Samsung
SoCs. To re-use the existing serial driver on Exynos7 we need to have
SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
possible because these symbols are dependent on PLAT_SAMSUNG which is
not present for the ARMv8 based exynos7.

Change the dependency of these symbols from PLAT_SAMSUNG to the serial
driver thus making it available on exynos7. As the existing platform
specific code making use of these symbols is related to uart driver this
change in dependency should not cause any issues.

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Changes in v2:
- Added Greg's ack and Kukjin Kim as a recepient

 drivers/tty/serial/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index e71a28b..d0ce88c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
 
 config SERIAL_SAMSUNG_UARTS_4
bool
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
help
  Internal node for the common case of 4 Samsung compatible UARTs
 
 config SERIAL_SAMSUNG_UARTS
int
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
help
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

From: Pankaj Dubey 

Exynos7 has a similar serial controller to that present in older Samsung
SoCs. To re-use the existing serial driver on Exynos7 we need to have
SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
possible because these symbols are dependent on PLAT_SAMSUNG which is
not present for the ARMv8 based exynos7.

Change the dependency of these symbols from PLAT_SAMSUNG to the serial
driver thus making it available on exynos7. As the existing platform
specific code making use of these symbols is related to uart driver this
change in dependency should not cause any issues.

Signed-off-by: Pankaj Dubey 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Abhilash Kesavan 
Cc: Greg Kroah-Hartman 
---
Re-sending as the previous version did not reach Greg KH.

 drivers/tty/serial/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index e71a28b..d0ce88c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
 
 config SERIAL_SAMSUNG_UARTS_4
bool
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
help
  Internal node for the common case of 4 Samsung compatible UARTs
 
 config SERIAL_SAMSUNG_UARTS
int
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
help
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hello Greg,

On Mon, Nov 17, 2014 at 2:40 AM, gre...@linuxfoundation.org
 wrote:
> On Sun, Nov 16, 2014 at 07:47:02AM +0530, Abhilash Kesavan wrote:
>> Hello Greg,
>>
>> On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan
>>  wrote:
>> > Hi Greg,
>> >
>> > On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
>> >  wrote:
>> >> Hi Tomasz,
>> >>
>> >> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa  
>> >> wrote:
>> >>> Hi Abhilash,
>> >>>
>> >>> The patch itself seems fine, but I wonder if those config options aren't
>> >>> really just leftovers from the past and couldn't be completely removed.
>> >>>
>> >>> On 29.09.2014 07:16, Abhilash Kesavan wrote:
>> >>>> From: Pankaj Dubey 
>> >>>>
>> >>>> Exynos7 has a similar serial controller to that present in older Samsung
>> >>>> SoCs. To re-use the existing serial driver on Exynos7 we need to have
>> >>>> SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
>> >>>> possible because these symbols are dependent on PLAT_SAMSUNG which is
>> >>>> not present for the ARMv8 based exynos7.
>> >>>>
>> >>>> Change the dependency of these symbols from PLAT_SAMSUNG to the serial
>> >>>> driver thus making it available on exynos7. As the existing platform
>> >>>> specific code making use of these symbols is related to uart driver this
>> >>>> change in dependency should not cause any issues.
>> >>>>
>> >>>> Signed-off-by: Pankaj Dubey 
>> >>>> Signed-off-by: Naveen Krishna Chatradhi 
>> >>>> Signed-off-by: Abhilash Kesavan 
>> >>>> Cc: Greg Kroah-Hartman 
>> >>>> ---
>> >>>> Build tested with s3c6400_defconfig, exynos_defconfig and arm64's 
>> >>>> defconfig
>> >>>> with and without the serial driver enabled.
>> >>>>
>> >>>>  drivers/tty/serial/Kconfig |4 ++--
>> >>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> >>>>
>> >>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> >>>> index 81f6ee7..e6c0bcb 100644
>> >>>> --- a/drivers/tty/serial/Kconfig
>> >>>> +++ b/drivers/tty/serial/Kconfig
>> >>>> @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
>> >>>>
>> >>>>  config SERIAL_SAMSUNG_UARTS_4
>> >>>>   bool
>> >>>> - depends on PLAT_SAMSUNG
>> >>>> + depends on SERIAL_SAMSUNG
>> >>>>   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
>> >>>> CPU_S3C2442)
>> >>>>   help
>> >>>> Internal node for the common case of 4 Samsung compatible UARTs
>> >>>
>> >>> The only place where this symbol is used is below.
>> >>>
>> >>>>
>> >>>>  config SERIAL_SAMSUNG_UARTS
>> >>>>   int
>> >>>> - depends on PLAT_SAMSUNG
>> >>>> + depends on SERIAL_SAMSUNG
>> >>>>   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
>> >>>>   default 3
>> >>>>   help
>> >>>>
>> >>>
>> >>> With this symbol the situation isn't that easy, but still should be
>> >>> manageable.
>> >>>
>> >>> Looking at the serial-samsung driver, all occurrences of
>> >>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
>> >>> defined number equal to the maximum value - in this case 4.
>> >>>
>> >>> There are also two places in arch/arm where this symbol is used:
>> >>>
>> >>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
>> >>> ports which need suspend/resume handling. Since on s3c64xx the number is
>> >>> always 4, it can be simply defined locally as a constant.
>> >>>
>> >>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
>> >>> static array of UART ports and to check whether the UART driver is
>> >>> enabled. In former case I believe it should be safe to hardcode it to 4
>> >>> as well, in latte

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hello Greg,

On Mon, Nov 17, 2014 at 2:40 AM, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
 On Sun, Nov 16, 2014 at 07:47:02AM +0530, Abhilash Kesavan wrote:
 Hello Greg,

 On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
  Hi Greg,
 
  On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
  kesavan.abhil...@gmail.com wrote:
  Hi Tomasz,
 
  On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa tomasz.f...@gmail.com 
  wrote:
  Hi Abhilash,
 
  The patch itself seems fine, but I wonder if those config options aren't
  really just leftovers from the past and couldn't be completely removed.
 
  On 29.09.2014 07:16, Abhilash Kesavan wrote:
  From: Pankaj Dubey pankaj.du...@samsung.com
 
  Exynos7 has a similar serial controller to that present in older Samsung
  SoCs. To re-use the existing serial driver on Exynos7 we need to have
  SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
  possible because these symbols are dependent on PLAT_SAMSUNG which is
  not present for the ARMv8 based exynos7.
 
  Change the dependency of these symbols from PLAT_SAMSUNG to the serial
  driver thus making it available on exynos7. As the existing platform
  specific code making use of these symbols is related to uart driver this
  change in dependency should not cause any issues.
 
  Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
  Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
  Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
  Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
  ---
  Build tested with s3c6400_defconfig, exynos_defconfig and arm64's 
  defconfig
  with and without the serial driver enabled.
 
   drivers/tty/serial/Kconfig |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
  index 81f6ee7..e6c0bcb 100644
  --- a/drivers/tty/serial/Kconfig
  +++ b/drivers/tty/serial/Kconfig
  @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
 
   config SERIAL_SAMSUNG_UARTS_4
bool
  - depends on PLAT_SAMSUNG
  + depends on SERIAL_SAMSUNG
default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
  CPU_S3C2442)
help
  Internal node for the common case of 4 Samsung compatible UARTs
 
  The only place where this symbol is used is below.
 
 
   config SERIAL_SAMSUNG_UARTS
int
  - depends on PLAT_SAMSUNG
  + depends on SERIAL_SAMSUNG
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
help
 
 
  With this symbol the situation isn't that easy, but still should be
  manageable.
 
  Looking at the serial-samsung driver, all occurrences of
  CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
  defined number equal to the maximum value - in this case 4.
 
  There are also two places in arch/arm where this symbol is used:
 
  1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
  ports which need suspend/resume handling. Since on s3c64xx the number is
  always 4, it can be simply defined locally as a constant.
 
  2) In arch/arm/plat-samsung/init.c it is used to determine size of a
  static array of UART ports and to check whether the UART driver is
  enabled. In former case I believe it should be safe to hardcode it to 4
  as well, in latter CONFIG_SERIAL_SAMSUNG can be used.
 
  I will post patches removing these two symbols.
 
  I posted a couple of patches handling Tomasz' comments but Kukjin
  prefers the approach in this patch (Discussion here:
  http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
  Can you please review the patch.

 This is a gentle reminder. The patch is required for serial enablement
 on the new exynos7 SoC, kindly take a look.

 What patch?  I fail to see anything in my inboxes that I can apply, only
 this long thread that makes no sense at all.

 Please resend anything that you want to have applied, in a format that I
 can apply it, _AND_ get everyone to agree that it is the correct
 solution.

 Asking me to go look up random web archives, of mailing list threads I
 was never copied on, is a sure way to get your email ignored, as again,
 there is nothing I can do with it.  You know better than this.

Apologies for the patch not reaching you. I will re-send it right now.
Kukjin Kim has already approved the approach under discussion; however
the patch needs to go via Kukjin's tree due to other patches that
depend on it. Hence, I require your ack on it.

Once again, sorry for the inconvenience.

Thanks,
Abhilash
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

From: Pankaj Dubey pankaj.du...@samsung.com

Exynos7 has a similar serial controller to that present in older Samsung
SoCs. To re-use the existing serial driver on Exynos7 we need to have
SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
possible because these symbols are dependent on PLAT_SAMSUNG which is
not present for the ARMv8 based exynos7.

Change the dependency of these symbols from PLAT_SAMSUNG to the serial
driver thus making it available on exynos7. As the existing platform
specific code making use of these symbols is related to uart driver this
change in dependency should not cause any issues.

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Re-sending as the previous version did not reach Greg KH.

 drivers/tty/serial/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index e71a28b..d0ce88c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
 
 config SERIAL_SAMSUNG_UARTS_4
bool
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
help
  Internal node for the common case of 4 Samsung compatible UARTs
 
 config SERIAL_SAMSUNG_UARTS
int
-   depends on PLAT_SAMSUNG
+   depends on SERIAL_SAMSUNG
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
help
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hello Greg,

On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan
 wrote:
> Hi Greg,
>
> On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
>  wrote:
>> Hi Tomasz,
>>
>> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa  wrote:
>>> Hi Abhilash,
>>>
>>> The patch itself seems fine, but I wonder if those config options aren't
>>> really just leftovers from the past and couldn't be completely removed.
>>>
>>> On 29.09.2014 07:16, Abhilash Kesavan wrote:
>>>> From: Pankaj Dubey 
>>>>
>>>> Exynos7 has a similar serial controller to that present in older Samsung
>>>> SoCs. To re-use the existing serial driver on Exynos7 we need to have
>>>> SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
>>>> possible because these symbols are dependent on PLAT_SAMSUNG which is
>>>> not present for the ARMv8 based exynos7.
>>>>
>>>> Change the dependency of these symbols from PLAT_SAMSUNG to the serial
>>>> driver thus making it available on exynos7. As the existing platform
>>>> specific code making use of these symbols is related to uart driver this
>>>> change in dependency should not cause any issues.
>>>>
>>>> Signed-off-by: Pankaj Dubey 
>>>> Signed-off-by: Naveen Krishna Chatradhi 
>>>> Signed-off-by: Abhilash Kesavan 
>>>> Cc: Greg Kroah-Hartman 
>>>> ---
>>>> Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
>>>> with and without the serial driver enabled.
>>>>
>>>>  drivers/tty/serial/Kconfig |4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>>> index 81f6ee7..e6c0bcb 100644
>>>> --- a/drivers/tty/serial/Kconfig
>>>> +++ b/drivers/tty/serial/Kconfig
>>>> @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
>>>>
>>>>  config SERIAL_SAMSUNG_UARTS_4
>>>>   bool
>>>> - depends on PLAT_SAMSUNG
>>>> + depends on SERIAL_SAMSUNG
>>>>   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
>>>> CPU_S3C2442)
>>>>   help
>>>> Internal node for the common case of 4 Samsung compatible UARTs
>>>
>>> The only place where this symbol is used is below.
>>>
>>>>
>>>>  config SERIAL_SAMSUNG_UARTS
>>>>   int
>>>> - depends on PLAT_SAMSUNG
>>>> + depends on SERIAL_SAMSUNG
>>>>   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
>>>>   default 3
>>>>   help
>>>>
>>>
>>> With this symbol the situation isn't that easy, but still should be
>>> manageable.
>>>
>>> Looking at the serial-samsung driver, all occurrences of
>>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
>>> defined number equal to the maximum value - in this case 4.
>>>
>>> There are also two places in arch/arm where this symbol is used:
>>>
>>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
>>> ports which need suspend/resume handling. Since on s3c64xx the number is
>>> always 4, it can be simply defined locally as a constant.
>>>
>>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
>>> static array of UART ports and to check whether the UART driver is
>>> enabled. In former case I believe it should be safe to hardcode it to 4
>>> as well, in latter CONFIG_SERIAL_SAMSUNG can be used.
>>
>> I will post patches removing these two symbols.
>
> I posted a couple of patches handling Tomasz' comments but Kukjin
> prefers the approach in this patch (Discussion here:
> http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
> Can you please review the patch.

This is a gentle reminder. The patch is required for serial enablement
on the new exynos7 SoC, kindly take a look.

Thanks,
Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hello Greg,

On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Greg,

 On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Tomasz,

 On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Abhilash,

 The patch itself seems fine, but I wonder if those config options aren't
 really just leftovers from the past and couldn't be completely removed.

 On 29.09.2014 07:16, Abhilash Kesavan wrote:
 From: Pankaj Dubey pankaj.du...@samsung.com

 Exynos7 has a similar serial controller to that present in older Samsung
 SoCs. To re-use the existing serial driver on Exynos7 we need to have
 SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
 possible because these symbols are dependent on PLAT_SAMSUNG which is
 not present for the ARMv8 based exynos7.

 Change the dependency of these symbols from PLAT_SAMSUNG to the serial
 driver thus making it available on exynos7. As the existing platform
 specific code making use of these symbols is related to uart driver this
 change in dependency should not cause any issues.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
 Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
 with and without the serial driver enabled.

  drivers/tty/serial/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
 index 81f6ee7..e6c0bcb 100644
 --- a/drivers/tty/serial/Kconfig
 +++ b/drivers/tty/serial/Kconfig
 @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG

  config SERIAL_SAMSUNG_UARTS_4
   bool
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
 CPU_S3C2442)
   help
 Internal node for the common case of 4 Samsung compatible UARTs

 The only place where this symbol is used is below.


  config SERIAL_SAMSUNG_UARTS
   int
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
   default 3
   help


 With this symbol the situation isn't that easy, but still should be
 manageable.

 Looking at the serial-samsung driver, all occurrences of
 CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
 defined number equal to the maximum value - in this case 4.

 There are also two places in arch/arm where this symbol is used:

 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
 ports which need suspend/resume handling. Since on s3c64xx the number is
 always 4, it can be simply defined locally as a constant.

 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
 static array of UART ports and to check whether the UART driver is
 enabled. In former case I believe it should be safe to hardcode it to 4
 as well, in latter CONFIG_SERIAL_SAMSUNG can be used.

 I will post patches removing these two symbols.

 I posted a couple of patches handling Tomasz' comments but Kukjin
 prefers the approach in this patch (Discussion here:
 http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
 Can you please review the patch.

This is a gentle reminder. The patch is required for serial enablement
on the new exynos7 SoC, kindly take a look.

Thanks,
Abhilash
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hi Greg,

On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
 wrote:
> Hi Tomasz,
>
> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa  wrote:
>> Hi Abhilash,
>>
>> The patch itself seems fine, but I wonder if those config options aren't
>> really just leftovers from the past and couldn't be completely removed.
>>
>> On 29.09.2014 07:16, Abhilash Kesavan wrote:
>>> From: Pankaj Dubey 
>>>
>>> Exynos7 has a similar serial controller to that present in older Samsung
>>> SoCs. To re-use the existing serial driver on Exynos7 we need to have
>>> SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
>>> possible because these symbols are dependent on PLAT_SAMSUNG which is
>>> not present for the ARMv8 based exynos7.
>>>
>>> Change the dependency of these symbols from PLAT_SAMSUNG to the serial
>>> driver thus making it available on exynos7. As the existing platform
>>> specific code making use of these symbols is related to uart driver this
>>> change in dependency should not cause any issues.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>> Signed-off-by: Naveen Krishna Chatradhi 
>>> Signed-off-by: Abhilash Kesavan 
>>> Cc: Greg Kroah-Hartman 
>>> ---
>>> Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
>>> with and without the serial driver enabled.
>>>
>>>  drivers/tty/serial/Kconfig |4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> index 81f6ee7..e6c0bcb 100644
>>> --- a/drivers/tty/serial/Kconfig
>>> +++ b/drivers/tty/serial/Kconfig
>>> @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
>>>
>>>  config SERIAL_SAMSUNG_UARTS_4
>>>   bool
>>> - depends on PLAT_SAMSUNG
>>> + depends on SERIAL_SAMSUNG
>>>   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
>>> CPU_S3C2442)
>>>   help
>>> Internal node for the common case of 4 Samsung compatible UARTs
>>
>> The only place where this symbol is used is below.
>>
>>>
>>>  config SERIAL_SAMSUNG_UARTS
>>>   int
>>> - depends on PLAT_SAMSUNG
>>> + depends on SERIAL_SAMSUNG
>>>   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
>>>   default 3
>>>   help
>>>
>>
>> With this symbol the situation isn't that easy, but still should be
>> manageable.
>>
>> Looking at the serial-samsung driver, all occurrences of
>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
>> defined number equal to the maximum value - in this case 4.
>>
>> There are also two places in arch/arm where this symbol is used:
>>
>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
>> ports which need suspend/resume handling. Since on s3c64xx the number is
>> always 4, it can be simply defined locally as a constant.
>>
>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
>> static array of UART ports and to check whether the UART driver is
>> enabled. In former case I believe it should be safe to hardcode it to 4
>> as well, in latter CONFIG_SERIAL_SAMSUNG can be used.
>
> I will post patches removing these two symbols.

I posted a couple of patches handling Tomasz' comments but Kukjin
prefers the approach in this patch (Discussion here:
http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
Can you please review the patch.

Regards,
Abhilash
>
> Regards,
> Abhilash
>>
>> Best regards,
>> Tomasz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hi Greg,

On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Tomasz,

 On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Abhilash,

 The patch itself seems fine, but I wonder if those config options aren't
 really just leftovers from the past and couldn't be completely removed.

 On 29.09.2014 07:16, Abhilash Kesavan wrote:
 From: Pankaj Dubey pankaj.du...@samsung.com

 Exynos7 has a similar serial controller to that present in older Samsung
 SoCs. To re-use the existing serial driver on Exynos7 we need to have
 SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
 possible because these symbols are dependent on PLAT_SAMSUNG which is
 not present for the ARMv8 based exynos7.

 Change the dependency of these symbols from PLAT_SAMSUNG to the serial
 driver thus making it available on exynos7. As the existing platform
 specific code making use of these symbols is related to uart driver this
 change in dependency should not cause any issues.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
 Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
 with and without the serial driver enabled.

  drivers/tty/serial/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
 index 81f6ee7..e6c0bcb 100644
 --- a/drivers/tty/serial/Kconfig
 +++ b/drivers/tty/serial/Kconfig
 @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG

  config SERIAL_SAMSUNG_UARTS_4
   bool
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
 CPU_S3C2442)
   help
 Internal node for the common case of 4 Samsung compatible UARTs

 The only place where this symbol is used is below.


  config SERIAL_SAMSUNG_UARTS
   int
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
   default 3
   help


 With this symbol the situation isn't that easy, but still should be
 manageable.

 Looking at the serial-samsung driver, all occurrences of
 CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
 defined number equal to the maximum value - in this case 4.

 There are also two places in arch/arm where this symbol is used:

 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
 ports which need suspend/resume handling. Since on s3c64xx the number is
 always 4, it can be simply defined locally as a constant.

 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
 static array of UART ports and to check whether the UART driver is
 enabled. In former case I believe it should be safe to hardcode it to 4
 as well, in latter CONFIG_SERIAL_SAMSUNG can be used.

 I will post patches removing these two symbols.

I posted a couple of patches handling Tomasz' comments but Kukjin
prefers the approach in this patch (Discussion here:
http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
Can you please review the patch.

Regards,
Abhilash

 Regards,
 Abhilash

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

Re: [PATCH] iio: adc: exynos_adc: Add support for ADCv3 on exynos7

[Abhilash Kesavan]

Hi Chanwoo,

On Sat, Nov 1, 2014 at 11:57 AM, Chanwoo Choi  wrote:
> Hi Abhilash,
>
> On Sat, Nov 1, 2014 at 1:00 PM, Abhilash Kesavan
>  wrote:
>> Hi Chanwoo,
>>
>> On Fri, Oct 31, 2014 at 9:44 PM, Chanwoo Choi  wrote:
>>> Hi Abhilash,
>>>
>>> On Fri, Oct 31, 2014 at 11:01 PM, Abhilash Kesavan
>>>  wrote:
>>>> Hi Chanwoo,
>>>>
>>>> Thanks for the quick response.
>>>>
>>>> On Fri, Oct 31, 2014 at 6:17 PM, Chanwoo Choi  
>>>> wrote:
>>>>> Hi Abhilash,
>>>>>
>>>>> On 10/31/2014 09:38 PM, Abhilash Kesavan wrote:
>>>>>> The ADC on exynos7 is quite similar to ADCv2. The differences are as
>>>>>> follows:
>>>>>>   - v3 has 8 input channels (10 in v2).
>>>>>>   - v3 does not include an ADC PHY control register.
>>>>>>   - Some ADC_CON2 register bits being used in v2 are listed as
>>>>>> reserved in v3. This results in a different init_hw function
>>>>>> for v3.
>>>>>>
>>>>>> Signed-off-by: Abhilash Kesavan 
>>>>>> ---
>>>>>> - Based on Naveen's "iio: exynos-adc: use syscon instead of ioremap" 
>>>>>> patchset
>>>>>> http://comments.gmane.org/gmane.linux.kernel.iio/13943
>>>>>>
>>>>>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 ++
>>>>>>  drivers/iio/adc/exynos_adc.c   |   32 
>>>>>> 
>>>>>>  2 files changed, 34 insertions(+)
>>>>>>
>>>>>> diff --git 
>>>>>> a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>>>>>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>>>> index c368210..a11e32c 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>>>> @@ -14,6 +14,8 @@ Required properties:
>>>>>>   for exynos4412/5250 and s5pv210 
>>>>>> controllers.
>>>>>>   Must be "samsung,exynos-adc-v2" for
>>>>>>   future controllers.
>>>>>> + Must be "samsung,exynos-adc-v3" for
>>>>>> + the ADC in Exynos7 and compatibles
>>>>>
>>>>> I prefer to use 'exynos7-adc' instead of 'exynos-adc-v3'.
>>>>> Exynos7 has little different from existing ADCv2.
>>>>
>>>> Sure, I'll change it. The reason for my choosing v3 was that reading
>>>> the version register (0x20 offset) showed a value of 0x8009 in
>>>> Exynos7 as against 0x8008 in both 5420 and 3250.
>>>>>
>>>>> Also, If you want to use 'exynos-adc-v3' compatible,
>>>>> Exynos7's TRM have to include the correct version(v3) infromation.
>>>>
>>>> I could not see any mention of the ADC controller version in the
>>>> Exynos7 UM other than the version register. Does that mean it is v2 ?
>>>
>>> So am I. I don't see any version number of ADC in Exynos TRM.
>> OK, considering the small differences between ADCv2 and this
>> controller, I will change the compatible to exynos7-adc.
>> Patch will be posted in a bit.
>>>
>>> Additionally,
>>> I have a question about Exynos7. If you possible,
>>> did you tell me about full name of Exynos7 SoC (e.g., Exynos5433, 
>>> Exynos52..)?
>> The soc name is Exynos7 and it has 4 A57 cores.
>
> I wondered what is Exynos7. Thanks for your reply.

Exynos7 is a System-On-Chip that is based on 64-bit ARMv8 RISC
processor. As mentioned earlier, it has a Cortex-A57 quad core
configuration targeted towards high-performance applications.

I have posted v2 with your suggested modifications
(https://lkml.org/lkml/2014/11/1/2), kindly review.

Regards,
Abhilash

>
> Best Regards,
> Chanwoo Choi
>
>>>
>>> Best Regards,
>>> Chanwoo Choi
>>>
>>>>
>>>> Regards,
>>>> Abhilash
>>>>>
>>>>> Thanks,
>>>>> Chanwoo Choi
>>>>>
>>>>>
>>>>>
>>>>>>   Must be "samsung,exynos3250-adc&

Re: [PATCH] iio: adc: exynos_adc: Add support for ADCv3 on exynos7

[Abhilash Kesavan]

Hi Chanwoo,

On Sat, Nov 1, 2014 at 11:57 AM, Chanwoo Choi cwcho...@gmail.com wrote:
 Hi Abhilash,

 On Sat, Nov 1, 2014 at 1:00 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Chanwoo,

 On Fri, Oct 31, 2014 at 9:44 PM, Chanwoo Choi cwcho...@gmail.com wrote:
 Hi Abhilash,

 On Fri, Oct 31, 2014 at 11:01 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Chanwoo,

 Thanks for the quick response.

 On Fri, Oct 31, 2014 at 6:17 PM, Chanwoo Choi cw00.c...@samsung.com 
 wrote:
 Hi Abhilash,

 On 10/31/2014 09:38 PM, Abhilash Kesavan wrote:
 The ADC on exynos7 is quite similar to ADCv2. The differences are as
 follows:
   - v3 has 8 input channels (10 in v2).
   - v3 does not include an ADC PHY control register.
   - Some ADC_CON2 register bits being used in v2 are listed as
 reserved in v3. This results in a different init_hw function
 for v3.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
 - Based on Naveen's iio: exynos-adc: use syscon instead of ioremap 
 patchset
 http://comments.gmane.org/gmane.linux.kernel.iio/13943

  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 ++
  drivers/iio/adc/exynos_adc.c   |   32 
 
  2 files changed, 34 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
 b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
 index c368210..a11e32c 100644
 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
 +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
 @@ -14,6 +14,8 @@ Required properties:
   for exynos4412/5250 and s5pv210 
 controllers.
   Must be samsung,exynos-adc-v2 for
   future controllers.
 + Must be samsung,exynos-adc-v3 for
 + the ADC in Exynos7 and compatibles

 I prefer to use 'exynos7-adc' instead of 'exynos-adc-v3'.
 Exynos7 has little different from existing ADCv2.

 Sure, I'll change it. The reason for my choosing v3 was that reading
 the version register (0x20 offset) showed a value of 0x8009 in
 Exynos7 as against 0x8008 in both 5420 and 3250.

 Also, If you want to use 'exynos-adc-v3' compatible,
 Exynos7's TRM have to include the correct version(v3) infromation.

 I could not see any mention of the ADC controller version in the
 Exynos7 UM other than the version register. Does that mean it is v2 ?

 So am I. I don't see any version number of ADC in Exynos TRM.
 OK, considering the small differences between ADCv2 and this
 controller, I will change the compatible to exynos7-adc.
 Patch will be posted in a bit.

 Additionally,
 I have a question about Exynos7. If you possible,
 did you tell me about full name of Exynos7 SoC (e.g., Exynos5433, 
 Exynos52..)?
 The soc name is Exynos7 and it has 4 A57 cores.

 I wondered what is Exynos7. Thanks for your reply.

Exynos7 is a System-On-Chip that is based on 64-bit ARMv8 RISC
processor. As mentioned earlier, it has a Cortex-A57 quad core
configuration targeted towards high-performance applications.

I have posted v2 with your suggested modifications
(https://lkml.org/lkml/2014/11/1/2), kindly review.

Regards,
Abhilash


 Best Regards,
 Chanwoo Choi


 Best Regards,
 Chanwoo Choi


 Regards,
 Abhilash

 Thanks,
 Chanwoo Choi



   Must be samsung,exynos3250-adc for
   controllers compatible with ADC of 
 Exynos3250.
   Must be samsung,s3c2410-adc for
 diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
 index fe03177..74d0a9d 100644
 --- a/drivers/iio/adc/exynos_adc.c
 +++ b/drivers/iio/adc/exynos_adc.c
 @@ -390,6 +390,35 @@ static const struct exynos_adc_data 
 exynos3250_adc_data = {
   .start_conv = exynos_adc_v2_start_conv,
  };

 +static void exynos_adc_v3_init_hw(struct exynos_adc *info)
 +{
 + u32 con1, con2;
 +
 + if (info-data-needs_adc_phy)
 + regmap_write(info-pmu_map, info-data-phy_offset, 1);
 +
 + con1 = ADC_V2_CON1_SOFT_RESET;
 + writel(con1, ADC_V2_CON1(info-regs));
 +
 + con2 = readl(ADC_V2_CON2(info-regs));
 + con2 = ~ADC_V2_CON2_C_TIME(7);
 + con2 |= ADC_V2_CON2_C_TIME(0);
 + writel(con2, ADC_V2_CON2(info-regs));
 +
 + /* Enable interrupts */
 + writel(1, ADC_V2_INT_EN(info-regs));
 +}
 +
 +static const struct exynos_adc_data exynos_adc_v3_data = {
 + .num_channels   = MAX_ADC_V1_CHANNELS,
 + .mask   = ADC_DATX_MASK, /* 12 bit ADC resolution */
 +
 + .init_hw= exynos_adc_v3_init_hw,
 + .exit_hw= exynos_adc_v2_exit_hw,
 + .clear_irq  = exynos_adc_v2_clear_irq,
 + .start_conv = exynos_adc_v2_start_conv,
 +};
 +
  static const struct of_device_id exynos_adc_match[] = {
   {
   .compatible = samsung,s3c2410-adc,
 @@ -413,6 +442,9 @@ static const struct of_device_id

[PATCH v2] iio: adc: exynos_adc: Add support for exynos7

[Abhilash Kesavan]

The ADC on exynos7 is quite similar to ADCv2. The differences are as
follows:
- exynos7-adc has 8 input channels (as against 10 in ADCv2).
- exynos7 does not include an ADC PHY control register.
- Some ADC_CON2 register bits being used in ADCv2 are listed as
  reserved in exynos7-adc. This results in a different init_hw
  function for exynos7.

Signed-off-by: Abhilash Kesavan 
---
- Based on Naveen's "iio: exynos-adc: use syscon instead of ioremap" patchset
http://comments.gmane.org/gmane.linux.kernel.iio/13943

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |  2 ++
 drivers/iio/adc/exynos_adc.c   | 32 ++
 2 files changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index c368210..f46ca9a 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
+   Must be "samsung,exynos7-adc" for
+   the ADC in Exynos7 and compatibles
Must be "samsung,s3c2410-adc" for
the ADC in s3c2410 and compatibles
Must be "samsung,s3c2416-adc" for
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index fe03177..3a2dbb3 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -390,6 +390,35 @@ static const struct exynos_adc_data exynos3250_adc_data = {
.start_conv = exynos_adc_v2_start_conv,
 };
 
+static void exynos_adc_exynos7_init_hw(struct exynos_adc *info)
+{
+   u32 con1, con2;
+
+   if (info->data->needs_adc_phy)
+   regmap_write(info->pmu_map, info->data->phy_offset, 1);
+
+   con1 = ADC_V2_CON1_SOFT_RESET;
+   writel(con1, ADC_V2_CON1(info->regs));
+
+   con2 = readl(ADC_V2_CON2(info->regs));
+   con2 &= ~ADC_V2_CON2_C_TIME(7);
+   con2 |= ADC_V2_CON2_C_TIME(0);
+   writel(con2, ADC_V2_CON2(info->regs));
+
+   /* Enable interrupts */
+   writel(1, ADC_V2_INT_EN(info->regs));
+}
+
+static const struct exynos_adc_data exynos7_adc_data = {
+   .num_channels   = MAX_ADC_V1_CHANNELS,
+   .mask   = ADC_DATX_MASK, /* 12 bit ADC resolution */
+
+   .init_hw= exynos_adc_exynos7_init_hw,
+   .exit_hw= exynos_adc_v2_exit_hw,
+   .clear_irq  = exynos_adc_v2_clear_irq,
+   .start_conv = exynos_adc_v2_start_conv,
+};
+
 static const struct of_device_id exynos_adc_match[] = {
{
.compatible = "samsung,s3c2410-adc",
@@ -415,6 +444,9 @@ static const struct of_device_id exynos_adc_match[] = {
}, {
.compatible = "samsung,exynos3250-adc",
.data = _adc_data,
+   }, {
+   .compatible = "samsung,exynos7-adc",
+   .data = _adc_data,
},
{},
 };
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: adc: exynos_adc: Add support for ADCv3 on exynos7

[Abhilash Kesavan]

Hi Chanwoo,

On Fri, Oct 31, 2014 at 9:44 PM, Chanwoo Choi  wrote:
> Hi Abhilash,
>
> On Fri, Oct 31, 2014 at 11:01 PM, Abhilash Kesavan
>  wrote:
>> Hi Chanwoo,
>>
>> Thanks for the quick response.
>>
>> On Fri, Oct 31, 2014 at 6:17 PM, Chanwoo Choi  wrote:
>>> Hi Abhilash,
>>>
>>> On 10/31/2014 09:38 PM, Abhilash Kesavan wrote:
>>>> The ADC on exynos7 is quite similar to ADCv2. The differences are as
>>>> follows:
>>>>   - v3 has 8 input channels (10 in v2).
>>>>   - v3 does not include an ADC PHY control register.
>>>>   - Some ADC_CON2 register bits being used in v2 are listed as
>>>> reserved in v3. This results in a different init_hw function
>>>> for v3.
>>>>
>>>> Signed-off-by: Abhilash Kesavan 
>>>> ---
>>>> - Based on Naveen's "iio: exynos-adc: use syscon instead of ioremap" 
>>>> patchset
>>>> http://comments.gmane.org/gmane.linux.kernel.iio/13943
>>>>
>>>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 ++
>>>>  drivers/iio/adc/exynos_adc.c   |   32 
>>>> 
>>>>  2 files changed, 34 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>>>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>> index c368210..a11e32c 100644
>>>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>> @@ -14,6 +14,8 @@ Required properties:
>>>>   for exynos4412/5250 and s5pv210 controllers.
>>>>   Must be "samsung,exynos-adc-v2" for
>>>>   future controllers.
>>>> + Must be "samsung,exynos-adc-v3" for
>>>> + the ADC in Exynos7 and compatibles
>>>
>>> I prefer to use 'exynos7-adc' instead of 'exynos-adc-v3'.
>>> Exynos7 has little different from existing ADCv2.
>>
>> Sure, I'll change it. The reason for my choosing v3 was that reading
>> the version register (0x20 offset) showed a value of 0x8009 in
>> Exynos7 as against 0x8008 in both 5420 and 3250.
>>>
>>> Also, If you want to use 'exynos-adc-v3' compatible,
>>> Exynos7's TRM have to include the correct version(v3) infromation.
>>
>> I could not see any mention of the ADC controller version in the
>> Exynos7 UM other than the version register. Does that mean it is v2 ?
>
> So am I. I don't see any version number of ADC in Exynos TRM.
OK, considering the small differences between ADCv2 and this
controller, I will change the compatible to exynos7-adc.
Patch will be posted in a bit.
>
> Additionally,
> I have a question about Exynos7. If you possible,
> did you tell me about full name of Exynos7 SoC (e.g., Exynos5433, Exynos52..)?
The soc name is Exynos7 and it has 4 A57 cores.
>
> Best Regards,
> Chanwoo Choi
>
>>
>> Regards,
>> Abhilash
>>>
>>> Thanks,
>>> Chanwoo Choi
>>>
>>>
>>>
>>>>   Must be "samsung,exynos3250-adc" for
>>>>   controllers compatible with ADC of 
>>>> Exynos3250.
>>>>   Must be "samsung,s3c2410-adc" for
>>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>>> index fe03177..74d0a9d 100644
>>>> --- a/drivers/iio/adc/exynos_adc.c
>>>> +++ b/drivers/iio/adc/exynos_adc.c
>>>> @@ -390,6 +390,35 @@ static const struct exynos_adc_data 
>>>> exynos3250_adc_data = {
>>>>   .start_conv = exynos_adc_v2_start_conv,
>>>>  };
>>>>
>>>> +static void exynos_adc_v3_init_hw(struct exynos_adc *info)
>>>> +{
>>>> + u32 con1, con2;
>>>> +
>>>> + if (info->data->needs_adc_phy)
>>>> + regmap_write(info->pmu_map, info->data->phy_offset, 1);
>>>> +
>>>> + con1 = ADC_V2_CON1_SOFT_RESET;
>>>> + writel(con1, ADC_V2_CON1(info->regs));
>>>> +
>>>> + con2 = readl(ADC_V2_CON2(info->regs));
>>>> + con2 &= ~ADC_V2_CON2_C_TIME(7);
>>>> + con2 |= ADC_V2_CON2_

Re: [PATCH] iio: adc: exynos_adc: Add support for ADCv3 on exynos7

[Abhilash Kesavan]

Hi Chanwoo,

Thanks for the quick response.

On Fri, Oct 31, 2014 at 6:17 PM, Chanwoo Choi  wrote:
> Hi Abhilash,
>
> On 10/31/2014 09:38 PM, Abhilash Kesavan wrote:
>> The ADC on exynos7 is quite similar to ADCv2. The differences are as
>> follows:
>>   - v3 has 8 input channels (10 in v2).
>>   - v3 does not include an ADC PHY control register.
>>   - Some ADC_CON2 register bits being used in v2 are listed as
>> reserved in v3. This results in a different init_hw function
>>     for v3.
>>
>> Signed-off-by: Abhilash Kesavan 
>> ---
>> - Based on Naveen's "iio: exynos-adc: use syscon instead of ioremap" patchset
>> http://comments.gmane.org/gmane.linux.kernel.iio/13943
>>
>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 ++
>>  drivers/iio/adc/exynos_adc.c   |   32 
>> 
>>  2 files changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> index c368210..a11e32c 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> @@ -14,6 +14,8 @@ Required properties:
>>   for exynos4412/5250 and s5pv210 controllers.
>>   Must be "samsung,exynos-adc-v2" for
>>   future controllers.
>> + Must be "samsung,exynos-adc-v3" for
>> + the ADC in Exynos7 and compatibles
>
> I prefer to use 'exynos7-adc' instead of 'exynos-adc-v3'.
> Exynos7 has little different from existing ADCv2.

Sure, I'll change it. The reason for my choosing v3 was that reading
the version register (0x20 offset) showed a value of 0x8009 in
Exynos7 as against 0x8008 in both 5420 and 3250.
>
> Also, If you want to use 'exynos-adc-v3' compatible,
> Exynos7's TRM have to include the correct version(v3) infromation.

I could not see any mention of the ADC controller version in the
Exynos7 UM other than the version register. Does that mean it is v2 ?

Regards,
Abhilash
>
> Thanks,
> Chanwoo Choi
>
>
>
>>   Must be "samsung,exynos3250-adc" for
>>   controllers compatible with ADC of Exynos3250.
>>   Must be "samsung,s3c2410-adc" for
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index fe03177..74d0a9d 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -390,6 +390,35 @@ static const struct exynos_adc_data exynos3250_adc_data 
>> = {
>>   .start_conv = exynos_adc_v2_start_conv,
>>  };
>>
>> +static void exynos_adc_v3_init_hw(struct exynos_adc *info)
>> +{
>> + u32 con1, con2;
>> +
>> + if (info->data->needs_adc_phy)
>> + regmap_write(info->pmu_map, info->data->phy_offset, 1);
>> +
>> + con1 = ADC_V2_CON1_SOFT_RESET;
>> + writel(con1, ADC_V2_CON1(info->regs));
>> +
>> + con2 = readl(ADC_V2_CON2(info->regs));
>> + con2 &= ~ADC_V2_CON2_C_TIME(7);
>> + con2 |= ADC_V2_CON2_C_TIME(0);
>> + writel(con2, ADC_V2_CON2(info->regs));
>> +
>> + /* Enable interrupts */
>> + writel(1, ADC_V2_INT_EN(info->regs));
>> +}
>> +
>> +static const struct exynos_adc_data exynos_adc_v3_data = {
>> + .num_channels   = MAX_ADC_V1_CHANNELS,
>> + .mask   = ADC_DATX_MASK, /* 12 bit ADC resolution */
>> +
>> + .init_hw= exynos_adc_v3_init_hw,
>> + .exit_hw= exynos_adc_v2_exit_hw,
>> + .clear_irq  = exynos_adc_v2_clear_irq,
>> + .start_conv = exynos_adc_v2_start_conv,
>> +};
>> +
>>  static const struct of_device_id exynos_adc_match[] = {
>>   {
>>   .compatible = "samsung,s3c2410-adc",
>> @@ -413,6 +442,9 @@ static const struct of_device_id exynos_adc_match[] = {
>>   .compatible = "samsung,exynos-adc-v2",
>>   .data = _adc_v2_data,
>>   }, {
>> + .compatible = "samsung,exynos-adc-v3",
>> + .data = _adc_v3_data,
>> + }, {
>>   .compatible = "samsung,exynos3250-adc",
>>   .data = _adc_data,
>>   },
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] iio: adc: exynos_adc: Add support for ADCv3 on exynos7

[Abhilash Kesavan]

The ADC on exynos7 is quite similar to ADCv2. The differences are as
follows:
- v3 has 8 input channels (10 in v2).
- v3 does not include an ADC PHY control register.
- Some ADC_CON2 register bits being used in v2 are listed as
  reserved in v3. This results in a different init_hw function
  for v3.

Signed-off-by: Abhilash Kesavan 
---
- Based on Naveen's "iio: exynos-adc: use syscon instead of ioremap" patchset
http://comments.gmane.org/gmane.linux.kernel.iio/13943

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 ++
 drivers/iio/adc/exynos_adc.c   |   32 
 2 files changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index c368210..a11e32c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 and s5pv210 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
+   Must be "samsung,exynos-adc-v3" for
+   the ADC in Exynos7 and compatibles
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
Must be "samsung,s3c2410-adc" for
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index fe03177..74d0a9d 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -390,6 +390,35 @@ static const struct exynos_adc_data exynos3250_adc_data = {
.start_conv = exynos_adc_v2_start_conv,
 };
 
+static void exynos_adc_v3_init_hw(struct exynos_adc *info)
+{
+   u32 con1, con2;
+
+   if (info->data->needs_adc_phy)
+   regmap_write(info->pmu_map, info->data->phy_offset, 1);
+
+   con1 = ADC_V2_CON1_SOFT_RESET;
+   writel(con1, ADC_V2_CON1(info->regs));
+
+   con2 = readl(ADC_V2_CON2(info->regs));
+   con2 &= ~ADC_V2_CON2_C_TIME(7);
+   con2 |= ADC_V2_CON2_C_TIME(0);
+   writel(con2, ADC_V2_CON2(info->regs));
+
+   /* Enable interrupts */
+   writel(1, ADC_V2_INT_EN(info->regs));
+}
+
+static const struct exynos_adc_data exynos_adc_v3_data = {
+   .num_channels   = MAX_ADC_V1_CHANNELS,
+   .mask   = ADC_DATX_MASK, /* 12 bit ADC resolution */
+
+   .init_hw= exynos_adc_v3_init_hw,
+   .exit_hw= exynos_adc_v2_exit_hw,
+   .clear_irq  = exynos_adc_v2_clear_irq,
+   .start_conv = exynos_adc_v2_start_conv,
+};
+
 static const struct of_device_id exynos_adc_match[] = {
{
.compatible = "samsung,s3c2410-adc",
@@ -413,6 +442,9 @@ static const struct of_device_id exynos_adc_match[] = {
.compatible = "samsung,exynos-adc-v2",
.data = _adc_v2_data,
}, {
+   .compatible = "samsung,exynos-adc-v3",
+   .data = _adc_v3_data,
+   }, {
.compatible = "samsung,exynos3250-adc",
.data = _adc_data,
},
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/