Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

[Lan Tianyu]

On 2013年11月25日 22:11, Viresh Kumar wrote:
> This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors and core. This is required for early 
> suspend
> and late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung, 
> tegra,
>   etc.. They solved it with driver specific PM notifiers where they used to
>   disable their driver's ->target() routine. Most of these are updated in this
>   patchset to use new infrastructure.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> 
> So to solve these issues we introduce early suspend and late resume callbacks
> which would remove need of cpufreq drivers to implement PM notifiers to 
> disable
> transition after suspend and before resume.
> 
> @Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
> doesn't work for you. I am sure it will not, but would be better if you 
> confirm
> that.
> 
> Viresh Kumar (6):
>   cpufreq: suspend governors on system suspend/hibernate
>   cpufreq: call driver's suspend/resume for each policy
>   cpufreq: Implement cpufreq_generic_suspend()
>   cpufreq: exynos: Use cpufreq_generic_suspend()
>   cpufreq: s5pv210: Use cpufreq_generic_suspend()
>   cpufreq: Tegra: Use cpufreq_generic_suspend()
> 

Patch 1-2,
Tested-by: Lan Tianyu 

>  drivers/base/power/main.c |   5 ++
>  drivers/cpufreq/cpufreq.c | 133 
> +-
>  drivers/cpufreq/exynos-cpufreq.c  |  97 ++-
>  drivers/cpufreq/s5pv210-cpufreq.c |  49 +-
>  drivers/cpufreq/tegra-cpufreq.c   |  54 ++--
>  include/linux/cpufreq.h   |   6 ++
>  6 files changed, 99 insertions(+), 245 deletions(-)
> 


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

Re: [PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework

[Amit Kachhap]

On 11/25/13, Bartlomiej Zolnierkiewicz  wrote:
>
> Hi,
>
> Could you please also apply this patch?
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
>> There is little sense in having separate config option for
>> registering EXYNOS TMU driver with the core thermal framework.
>> Fix it by integrating EXYNOS_THERMAL_CORE config option with
>> EXYNOS_THERMAL one.
>>
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.

Thanks,
Amit D
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/thermal/samsung/Kconfig | 14 +++---
>>  drivers/thermal/samsung/Makefile|  2 +-
>>  drivers/thermal/samsung/exynos_thermal_common.h | 12 
>>  3 files changed, 4 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/Kconfig
>> b/drivers/thermal/samsung/Kconfig
>> index f760389..04eabee 100644
>> --- a/drivers/thermal/samsung/Kconfig
>> +++ b/drivers/thermal/samsung/Kconfig
>> @@ -5,14 +5,6 @@ config EXYNOS_THERMAL
>>If you say yes here you get support for the TMU (Thermal Management
>>Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
>> initialises
>>the TMU, reports temperature and handles cooling action if defined.
>> -  This driver uses the Exynos core thermal APIs and TMU configuration
>> -  data from the supported SoCs.
>> -
>> -config EXYNOS_THERMAL_CORE
>> -bool "Core thermal framework support for EXYNOS SOCs"
>> -depends on EXYNOS_THERMAL
>> -help
>> -  If you say yes here you get support for EXYNOS TMU
>> -  (Thermal Management Unit) common registration/unregistration
>> -  functions to the core thermal layer and also to use the generic
>> -  CPU cooling APIs.
>> +  This driver uses the Exynos core thermal APIs, TMU configuration data
>> +  from the supported SoCs, common registration/unregistration functions
>> +  to the core thermal layer and also the generic CPU cooling APIs.
>> diff --git a/drivers/thermal/samsung/Makefile
>> b/drivers/thermal/samsung/Makefile
>> index c09d830..a829107 100644
>> --- a/drivers/thermal/samsung/Makefile
>> +++ b/drivers/thermal/samsung/Makefile
>> @@ -4,4 +4,4 @@
>>  obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
>>  exynos_thermal-y:= exynos_tmu.o
>>  exynos_thermal-y+= exynos_tmu_data.o
>> -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+= 
>> exynos_thermal_common.o
>> +exynos_thermal-y+= exynos_thermal_common.o
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
>> b/drivers/thermal/samsung/exynos_thermal_common.h
>> index 3eb2ed9..8681679 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> @@ -88,20 +88,8 @@ struct thermal_sensor_conf {
>>  struct device *dev;
>>  };
>>
>> -/*Functions used exynos based thermal sensor driver*/
>> -#ifdef CONFIG_EXYNOS_THERMAL_CORE
>>  void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
>>  int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
>>  void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
>> -#else
>> -static inline void
>> -exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
>> return; }
>>
>> -static inline int
>> -exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
>> 0; }
>> -
>> -static inline void
>> -exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
>> }
>> -
>> -#endif /* CONFIG_EXYNOS_THERMAL_CORE */
>>  #endif /* _EXYNOS_THERMAL_COMMON_H */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

[Amit Kachhap]

On 10/4/13, Bartlomiej Zolnierkiewicz  wrote:
> Menu for Samsung thermal support is visible on all Samsung
> platforms while thermal drivers are currently available only
> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
> with ARCH_EXYNOS one.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
Looks good, so
Acked-by: Amit Daniel Kachhap 

> ---
>  drivers/thermal/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a709c63..05cf95c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
>
>  menu "Samsung thermal drivers"
> -depends on PLAT_SAMSUNG
> +depends on ARCH_EXYNOS
>  source "drivers/thermal/samsung/Kconfig"
>  endmenu
>
> --
> 1.8.2.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux 3.13-rc1 make dw_mmc-exynos more worse

[randy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Jaehoon,
I have noticed that before it, but in dw_mmc driver, I won't meet this
problem.
As you can seen in dts, I have defined a clock source.
Or the clock source what I choose is not correct?
I don't know how to debug this, I don't know much about it.
Actually, I don't really understand the contain in chapter 7 of datasheet.
I am sorry for that.
Would you like to tell me some more about it?

于 2013年11月26日 12:32, Jaehoon Chung 写道:
> Hi, Randy,
> 
> It seems a problem that controller didn't find the clock source. 
> Also you can see the below message. Did you check the clock 
> source?
> 
>> [1.125000] s3c-sdhci 1255.sdhci: failed to get io clock
> 
> Actually, need to prevent the "null pointer dereference" for clock 
> in dw-mmc.c
> 
> And If dw-mmc controller can be used, recommend to use it. dw-mmc 
> can use DDR mode, but sdhci can't.
> 
> Best Regards, Jaehoon Chung
> 
> On 11/26/2013 10:47 AM, randy wrote: 于 2013年11月26日 08:41, Tomasz 
> Figa 写道:
 On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
> Hi,
> 
> On Sun, Nov 24, 2013 at 4:07 AM, randy 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> After pull the merge of 3.13-rc1, the dw_mmc-exynos will 
>> make the boot stock.In 3.13, it is just stocked udev in 
>> 3.13 and makse udev timeout but kernel report the emmc 
>> device is found.
>> 
>> And in the 
>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
>> I saw that it is need to define which gpio ports that a 
>> emmc slot use, but when I watched others dts, they use 
>> pinctrl, which is correct? Here is the log and dts
> 
> [..]
> 
>> ===log begin 
>> =
> [..]
>> [0.00] CPU EXYNOS4412 (id 0xe4412011)
> 
> [..]
> 
>> [1.095000] mmc0: no vmmc regulator found [ 1.13]
>> mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci]
>> using ADMA [1.13] Synopsys Designware Multimedia
>> Card Interface Driver [ 1.13] Unable to handle kernel
>> NULL pointer dereference at virtual address 002a [
>> 1.13] pgd = c0004000 [1.13] [002a]
>> *pgd= [ 1.135000] Internal error: Oops: 5 [#1]
>> PREEMPT SMP ARM [ 1.14] Modules linked in: [
>> 1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> 3.13.0-rc1-8-g584fa45-dirty #3 [ 1.15] task: 
>> ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [ 1.155000] PC
>> is at clk_get_rate+0x18/0x5c [1.16] LR is at 
>> clk_prepare_lock+0xc/0xd8 [1.165000] pc : 
>> [] lr : []psr: a113 [ 
>> 1.165000] sp : ef0a9e20 ip : ee94eb40  fp :  [ 
>> 1.175000] r10: c0571510  r9 : ef0a8000  r8 : ef227a10 [ 
>> 1.18] r7 : c043544c  r6 : fffe  r5 : ee94ead0
>> r4 : fffe [1.185000] r3 : ef0a4000  r2 :
>> 0001 r1 : 02b9  r0 : 0001 [ 1.195000] Flags:
>> NzCv IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment
>> kernel [ 1.20] Control: 10c5387d  Table: 4000404a
>> DAC: 0015 [1.205000] Process swapper/0 (pid: 1,
>> stack limit = 0xef0a8240) [1.21] Stack:
>> (0xef0a9e20 to 0xef0aa000) [1.215000] 9e20: c0308474
>> ee9ea610 ee94ead0 c0308488 c0308474 ee9ea610 
>> c030592c [ 1.225000] 9e40: ef227a10 1000 c043544c
>> c020a920 c0838b04 17d78400 ee9ea610 ef227a00 [
>> 1.235000] 9e60: ef227a10 c05d6b1c  c05d6b1c
>> c05890b0 ef0a8000 c0571510 c0269448 [ 1.24] 9e80:
>> c0269430 ef227a10 c061291c c0268088  ef227a10
>> c05d6b1c ef227a44 [ 1.25] 9ea0:  c026822c
>>  c05d6b1c c02681a0 c02668a8 ef005478 ef212740 [
>> 1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
>> c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
>> 0006 c059575c c05df580 c026884c  c05a2e14
>> 0006 c00088dc [ 1.275000] 9f00: c0603f70 ef163e00
>> c040e334 6113 c05b5000 a113 c05b5054 c05b5050 [
>> 1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4
>> 0093 c0035158 c05b5054 c05a2a20 [1.29] 9f40:
>> c050ae2c c054a438 0006 0006  c05a2e14
>> 0006 c059575c [ 1.30] 9f60: c05df580 0093
>> c0595768 c0571510  c0571c48 0006 0006 [
>> 1.305000] 9f80: c0571510 c003df68  c0403544
>>     [1.315000] 9fa0:
>>  c040354c  c000e738  
>>   [ 1.32] 9fc0:  
>>       [
>> 1.33] 9fe0:    
>> 0013  be73efa4 bffd [1.34]
>> [] (clk_get_rate+0x18/0x5c) from [] 
>> (dw_mci_exynos_setup_clock+0x14/0x2c) [1.35] 
>> [] (dw_

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> Since all Exynos platforms have been converted to dmaengine and many of
> the older platforms are in the process of conversion they do not need to
> use the legacy s3c-dma APIs for DMA but can instead use the standard ASoC
> dmaengine helpers. This both allows them to benefit from improvements
> implemented in the generic code and supports multiplatform.
>
> Signed-off-by: Mark Brown 
> ---
>
> This depends on Tomasz's s3c64xx dmaengine conversion since that is how
> I've tested it - if possible I'd like to get that merged into ASoC and
> SPI early after -rc1, since I maintian both trees it's possibly easiest
> if I go ahead any apply it?
>
>  sound/soc/samsung/Kconfig | 13 +--
>  sound/soc/samsung/Makefile|  6 ++--
>  sound/soc/samsung/dma.h   |  3 ++
>  sound/soc/samsung/dmaengine.c | 82 
> +++
>  4 files changed, 100 insertions(+), 4 deletions(-)
>  create mode 100644 sound/soc/samsung/dmaengine.c
>

[snip]

>  void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
> diff --git a/sound/soc/samsung/dmaengine.c b/sound/soc/samsung/dmaengine.c
> new file mode 100644
> index 000..ad0a371
> --- /dev/null
> +++ b/sound/soc/samsung/dmaengine.c
> @@ -0,0 +1,82 @@
> +/*
> + * dmaengine.c - Samsung dmaengine wrapper
> + *
> + * Author: Mark Brown 
> + * Copyright 2013 Linaro
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dma.h"
> +
> +#ifdef CONFIG_ARCH_S3C64XX
> +#define filter_fn pl08x_filter_id
> +#else
> +#define filter_fn NULL
> +#endif
> +
> +static const struct snd_dmaengine_pcm_config samsung_dmaengine_pcm_config = {
> +   .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
> +   .compat_filter_fn = filter_fn,
> +};
> +
> +void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
> +   struct s3c_dma_params *playback,
> +   struct s3c_dma_params *capture)
> +{
> +   struct snd_dmaengine_dai_dma_data *playback_data = NULL;
> +   struct snd_dmaengine_dai_dma_data *capture_data = NULL;
> +
> +   if (playback) {
> +   playback_data = &playback->dma_data;
> +   playback_data->filter_data = (void *)playback->channel;
> +   playback_data->chan_name = playback->ch_name;
> +   playback_data->addr = playback->dma_addr;
> +   playback_data->addr_width = playback->dma_size;
> +   }
> +   if (capture) {
> +   capture_data = &capture->dma_data;
> +   capture_data->filter_data = (void *)capture->channel;
> +   capture_data->chan_name = capture->ch_name;
> +   capture_data->addr = capture->dma_addr;
> +   capture_data->addr_width = capture->dma_size;
> +   }
> +
> +   snd_soc_dai_init_dma_data(dai, playback_data, capture_data);
> +}
> +EXPORT_SYMBOL_GPL(samsung_asoc_init_dma_data);
> +
> +int samsung_asoc_dma_platform_register(struct device *dev)
> +{
> +   return snd_dmaengine_pcm_register(dev, &samsung_dmaengine_pcm_config,
> + SND_DMAENGINE_PCM_FLAG_COMPAT);

also need to pass flag SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME here?

I tested this patch set on smdk5420 i2s. During playback audio playing
fast and there is underrun error like below.
underrun!!! (at least 0.061 ms long)
underrun!!! (at least 0.043 ms long)

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

Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init

[Padma Venkat]

Hi Mark,

On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> In preparation for using the dmaengine helpers in ASoC rather than the
> dmaengine wrappers for the Samsung API wrap the configuration of dma_data.
> The dmaengine code expects different data to that used by the legacy API.
>
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/samsung/ac97.c | 51 
> +++-
>  sound/soc/samsung/dma.c  |  8 
>  sound/soc/samsung/dma.h  |  3 +++
>  sound/soc/samsung/i2s.c  |  2 +-
>  sound/soc/samsung/pcm.c  | 18 +
>  5 files changed, 38 insertions(+), 44 deletions(-)
>

[snip]

> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index a5cbdb4..67d9fa9 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -963,7 +963,7 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
> }
> clk_prepare_enable(i2s->clk);
>
> -   snd_soc_dai_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
> +   samsung_asoc_init_dma_data(dai, &i2s->dma_playback, 
> &i2s->dma_capture);

we have to initialize the dma data for i2s secondary dai also
otherwise there is a crash in dmaengine_pcm_new during probe.

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

Re: linux 3.13-rc1 make dw_mmc-exynos more worse

[Jaehoon Chung]

Hi, Randy,

It seems a problem that controller didn't find the clock source.
Also you can see the below message. Did you check the clock source?

> [1.125000] s3c-sdhci 1255.sdhci: failed to get io clock

Actually, need to prevent the "null pointer dereference" for clock in dw-mmc.c

And If dw-mmc controller can be used, recommend to use it.
dw-mmc can use DDR mode, but sdhci can't.

Best Regards,
Jaehoon Chung

On 11/26/2013 10:47 AM, randy wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 于 2013年11月26日 08:41, Tomasz Figa 写道:
>> On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
>>> Hi,
>>>
>>> On Sun, Nov 24, 2013 at 4:07 AM, randy 
>>> wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

 After pull the merge of 3.13-rc1, the dw_mmc-exynos will make
 the boot stock.In 3.13, it is just stocked udev in 3.13 and
 makse udev timeout but kernel report the emmc device is found.

 And in the
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw
 that it is need to define which gpio ports that a emmc slot
 use, but when I watched others dts, they use pinctrl, which is
 correct? Here is the log and dts
>>>
>>> [..]
>>>
 ===log begin =
>>> [..]
 [0.00] CPU EXYNOS4412 (id 0xe4412011)
>>>
>>> [..]
>>>
 [1.095000] mmc0: no vmmc regulator found [1.13]
 mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using
 ADMA [1.13] Synopsys Designware Multimedia Card
 Interface Driver [1.13] Unable to handle kernel NULL
 pointer dereference at virtual address 002a [1.13]
 pgd = c0004000 [1.13] [002a] *pgd= [
 1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [
 1.14] Modules linked in: [1.14] CPU: 0 PID: 1 Comm:
 swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3 [
 1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [
 1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is
 at clk_prepare_lock+0xc/0xd8 [1.165000] pc : []
 lr : []psr: a113 [1.165000] sp : ef0a9e20
 ip : ee94eb40  fp :  [1.175000] r10: c0571510  r9 :
 ef0a8000  r8 : ef227a10 [1.18] r7 : c043544c  r6 :
 fffe  r5 : ee94ead0  r4 : fffe [1.185000] r3 :
 ef0a4000  r2 : 0001  r1 : 02b9  r0 : 0001 [
 1.195000] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
 Segment kernel [1.20] Control: 10c5387d  Table:
 4000404a  DAC: 0015 [1.205000] Process swapper/0 (pid:
 1, stack limit = 0xef0a8240) [1.21] Stack: (0xef0a9e20
 to 0xef0aa000) [1.215000] 9e20: c0308474 ee9ea610 ee94ead0
 c0308488 c0308474 ee9ea610  c030592c [1.225000]
 9e40: ef227a10 1000 c043544c c020a920 c0838b04 17d78400
 ee9ea610 ef227a00 [1.235000] 9e60: ef227a10 c05d6b1c
  c05d6b1c c05890b0 ef0a8000 c0571510 c0269448 [
 1.24] 9e80: c0269430 ef227a10 c061291c c0268088  
 ef227a10 c05d6b1c ef227a44 [1.25] 9ea0: 
 c026822c  c05d6b1c c02681a0 c02668a8 ef005478 ef212740 
 [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
 c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
 0006 c059575c c05df580 c026884c  c05a2e14 0006
 c00088dc [1.275000] 9f00: c0603f70 ef163e00 c040e334
 6113 c05b5000 a113 c05b5054 c05b5050 [1.28]
 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093 c0035158
 c05b5054 c05a2a20 [1.29] 9f40: c050ae2c c054a438
 0006 0006  c05a2e14 0006 c059575c [
 1.30] 9f60: c05df580 0093 c0595768 c0571510  
 c0571c48 0006 0006 [1.305000] 9f80: c0571510
 c003df68  c0403544     
 [1.315000] 9fa0:  c040354c  c000e738
     [1.32] 9fc0:
       
  [1.33] 9fe0:   
  0013  be73efa4 bffd [1.34]
 [] (clk_get_rate+0x18/0x5c) from [] 
 (dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
 [] (dw_mci_exynos_setup_clock+0x14/0x2c) from 
 [] (dw_mci_probe+0x15c/0xca4) [1.36]
 [] (dw_mci_probe+0x15c/0xca4) from []
 (platform_drv_probe+0x18/0x48) [1.365000] []
 (platform_drv_probe+0x18/0x48) from []
 (driver_probe_device+0x100/0x218) [1.375000] []
 (driver_probe_device+0x100/0x218) from []
 (__driver_attach+0x8c/0x90) [1.385000] []
 (__driver_attach+0x8c/0x90) from []
 (bus_for_each_dev+0x54/0x88) [1.395000] []
 (bus_for_each_dev+0x54/0x88) from []
 (bus_add_driver+0xd4/0x1d0) [1.405000] []
 (bus_add_driver+0xd4/0x1d0) from []
 (driver_r

[PATCH 2/2 v2] i2c: exynos5: configure fifo_depth based on HSI2C module version

[Naveen Krishna Chatradhi]

fifo_depth of the HSI2C is not constant
Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
Exynos5260 supports fifo_depth of 16bytes

This patch configures the fifo_depth based on HSI2C modules version.

Signed-off-by: Naveen Krishna Chatradhi 
[For finding out the difference and initial contribution]
Signed-off-by: Pankaj Dubey 
---
Changes since v1:
Added missed out Signed-off-by line for initial contribution
Also rebasing on linux-i2c for-next

 drivers/i2c/busses/i2c-exynos5.c |   29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 497ff91..a3fdcd8 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -77,12 +77,6 @@
 #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)  ((x) << 4)
 #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)  ((x) << 16)
 
-/* As per user manual FIFO max depth is 64bytes */
-#define HSI2C_FIFO_MAX 0x40
-/* default trigger levels for Tx and Rx FIFOs */
-#define HSI2C_DEF_TXFIFO_LVL   (HSI2C_FIFO_MAX - 0x30)
-#define HSI2C_DEF_RXFIFO_LVL   (HSI2C_FIFO_MAX - 0x10)
-
 /* I2C_TRAILING_CTL Register bits */
 #define HSI2C_TRAILING_COUNT   (0xf)
 
@@ -187,6 +181,9 @@ struct exynos5_i2c {
 
/* Version of HS-I2C Hardware */
unsigned intversion;
+
+   /* FIFO depth */
+   unsigned intfifo_depth;
 };
 
 enum hsi2c_version {
@@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
 
-   len = HSI2C_FIFO_MAX - fifo_level;
+   len = i2c->fifo_depth - fifo_level;
if (len > (i2c->msg->len - i2c->msg_ptr))
len = i2c->msg->len - i2c->msg_ptr;
 
@@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
u32 i2c_auto_conf = 0;
u32 fifo_ctl;
unsigned long flags;
+   unsigned short trig_lvl;
 
i2c_ctl = readl(i2c->regs + HSI2C_CTL);
i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
@@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
*i2c, int stop)
 
i2c_auto_conf = HSI2C_READ_WRITE;
 
-   fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
+   trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
+   (i2c->fifo_depth * 3/4) : i2c->msg->len;
+   fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= (HSI2C_INT_RX_ALMOSTFULL_EN |
HSI2C_INT_TRAILING_EN);
} else {
i2c_ctl |= HSI2C_TXCHON;
 
-   fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(HSI2C_DEF_RXFIFO_LVL);
+   trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
+   (i2c->fifo_depth * 1/4) : i2c->msg->len;
+   fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
}
 
@@ -716,10 +720,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
i2c->version = exynos5_i2c_get_version(pdev);
 
/* The HS-I2C core on Exynos5260 needs a reset to start with */
-   if (i2c->version == EXYNOS_5260)
+   if (i2c->version == EXYNOS_5260) {
+   i2c->fifo_depth = 16;
exynos5_i2c_reset(i2c);
-   else
+   } else {
+   i2c->fifo_depth = 64;
exynos5_i2c_init(i2c);
+   }
 
ret = i2c_add_adapter(&i2c->adap);
if (ret < 0) {
-- 
1.7.10.4

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

[PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Chatradhi]

This patch adds new compatible to support HSI2C module on Exynos5260
HSI2C module on Exynos5260 needs to be reset during during initialization.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
Rebasing on linux-i2c for-next

 .../devicetree/bindings/i2c/i2c-exynos5.txt|6 +++-
 drivers/i2c/busses/i2c-exynos5.c   |   31 ++--
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
index 056732c..704ab92 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -5,7 +5,11 @@ at various speeds ranging from 100khz to 3.4Mhz.
 
 Required properties:
   - compatible: value should be.
-  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available on
+   Exynos5250/5420 SoCs.
+   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
+   on Exynos5260 SoCs.
+
   - reg: physical base address of the controller and length of memory mapped
 region.
   - interrupts: interrupt number to the cpu.
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index da39ff0..497ff91 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -184,14 +184,35 @@ struct exynos5_i2c {
 * 2. Fast speed upto 1Mbps
 */
int speed_mode;
+
+   /* Version of HS-I2C Hardware */
+   unsigned intversion;
+};
+
+enum hsi2c_version {
+   EXYNOS_5,
+   EXYNOS_5260
 };
 
 static const struct of_device_id exynos5_i2c_match[] = {
-   { .compatible = "samsung,exynos5-hsi2c" },
+   {
+   .compatible = "samsung,exynos5-hsi2c",
+   .data = (void *)EXYNOS_5 },
+   {
+   .compatible = "samsung,exynos5260-hsi2c",
+   .data = (void *)EXYNOS_5260 },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
 
+static inline unsigned int exynos5_i2c_get_version(struct platform_device 
*pdev)
+{
+   const struct of_device_id *match;
+
+   match = of_match_node(exynos5_i2c_match, pdev->dev.of_node);
+   return (unsigned int)match->data;
+}
+
 static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
 {
writel(readl(i2c->regs + HSI2C_INT_STATUS),
@@ -692,7 +713,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   exynos5_i2c_init(i2c);
+   i2c->version = exynos5_i2c_get_version(pdev);
+
+   /* The HS-I2C core on Exynos5260 needs a reset to start with */
+   if (i2c->version == EXYNOS_5260)
+   exynos5_i2c_reset(i2c);
+   else
+   exynos5_i2c_init(i2c);
 
ret = i2c_add_adapter(&i2c->adap);
if (ret < 0) {
-- 
1.7.10.4

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

[PATCH v4] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Chatradhi]

For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
on a fixed 66 MHz peripheral clock, and therefore is completely
independent of the cpu frequency.
Thus, registering for a CPU freq notifier is very wasteful.

This patch modifes the code such that, i2c bus registers to
cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.

This change should save a bunch of cpufreq transitions calls
which does not apply to exynos SoCs.

Signed-off-by: Naveen Krishna Chatradhi 
Acked-by: Kyungmin Park 
Reviewed-by: Doug Anderson 
---
Changes since v3:
As per discussion at https://patchwork.kernel.org/patch/3235091/
Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of CPU_FREQ_S3C24XX

upstrea linux kernel and linuxsamsung already has the commit
f023f8dd59. Hence, rebasing the patch.

 drivers/i2c/busses/i2c-s3c2410.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bf8fb94..a77ce13 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -123,7 +123,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
struct pinctrl  *pctrl;
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
struct notifier_block   freq_transition;
 #endif
 };
@@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, 
unsigned int *got)
return 0;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
 
 #define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
 
-- 
1.7.10.4

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

Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[viresh kumar]

On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index dc196bb..6d93f91 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -255,6 +255,9 @@ struct cpufreq_driver {
>  int cpufreq_register_driver(struct cpufreq_driver *driver_data);
>  int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
>  
> +void cpufreq_suspend(void);
> +void cpufreq_resume(void);
> +
>  const char *cpufreq_get_current_driver(void);
>  
>  static inline void cpufreq_verify_within_limits(struct cpufreq_policy 
> *policy,

A minor fix here to get kernel compiled without cpufreq support enabled:

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 8d8b2f4..d40809d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -259,9 +259,6 @@ struct cpufreq_driver {
 int cpufreq_register_driver(struct cpufreq_driver *driver_data);
 int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);

-void cpufreq_suspend(void);
-void cpufreq_resume(void);
-
 const char *cpufreq_get_current_driver(void);

 static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy,
@@ -287,6 +284,14 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy 
*policy)
policy->cpuinfo.max_freq);
 }

+#ifdef CONFIG_CPU_FREQ
+void cpufreq_suspend(void);
+void cpufreq_resume(void);
+#elif
+static inline void cpufreq_suspend(void) {}
+static inline void cpufreq_resume(void) {}
+#endif
+
 /*
  * CPUFREQ NOTIFIER INTERFACE*
  */
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Ch]

Hello Doug,

On 26 November 2013 05:11, Doug Anderson  wrote:
> Naveen,
>
> On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi
>  wrote:
>> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
>> on a fixed 66 MHz peripheral clock, and therefore is completely
>> independent of the cpu frequency.
>> Thus, registering for a CPU freq notifier is very wasteful.
>>
>> This patch modifes the code such that, i2c bus registers to
>> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>>
>> This change should save a bunch of cpufreq transitions calls
>> which does not apply to exynos SoCs.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Acked-by: Kyungmin Park 
>> Reviewed-by: Doug Anderson 
>> ---
>> Changes since v2:
>> None, Rebased on for-next of linux-i2c git repo.
>>
>> Changes since v1:
>> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
>> As commented by Tomasz
>>
>>  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Can you please spin this with comments from
> ?  Thanks!
Thanks for pointing out for me

To summarize, Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of ARM_S3C24XX_CPUFREQ right.

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



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

Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[Viresh Kumar]

On 26 November 2013 04:59, Rafael J. Wysocki  wrote:
>> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
>>
>>   might_sleep();
>>
>> + cpufreq_suspend();
>> +
>>
>>   mutex_lock(&dpm_list_mtx);
>>   pm_transition = state;
>>   async_error = 0;
>
> Shouldn't it do cpufreq_resume() on errors?

Yes and this is already done I believe. In case dpm_suspend() fails,
dpm_resume() gets called. Isn't it?

>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> +void cpufreq_suspend(void)
>> +{
>> + struct cpufreq_policy *policy;
>> +
>> + if (!has_target())
>> + return;
>> +
>> + pr_debug("%s: Suspending Governors\n", __func__);
>> +
>> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
>> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
>> + pr_err("%s: Failed to stop governor for policy: %p\n",
>> + __func__, policy);
>
> This appears to be racy.  Is it really racy, or just seemingly?

Why does it look racy to you? Userspace should be frozen by now,
policy_list should be stable as well as nobody would touch it.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux 3.13-rc1 make dw_mmc-exynos more worse

[randy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

于 2013年11月26日 08:41, Tomasz Figa 写道:
> On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
>> Hi,
>> 
>> On Sun, Nov 24, 2013 at 4:07 AM, randy 
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> After pull the merge of 3.13-rc1, the dw_mmc-exynos will make
>>> the boot stock.In 3.13, it is just stocked udev in 3.13 and
>>> makse udev timeout but kernel report the emmc device is found.
>>> 
>>> And in the
>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw
>>> that it is need to define which gpio ports that a emmc slot
>>> use, but when I watched others dts, they use pinctrl, which is
>>> correct? Here is the log and dts
>> 
>> [..]
>> 
>>> ===log begin =
>> [..]
>>> [0.00] CPU EXYNOS4412 (id 0xe4412011)
>> 
>> [..]
>> 
>>> [1.095000] mmc0: no vmmc regulator found [1.13]
>>> mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using
>>> ADMA [1.13] Synopsys Designware Multimedia Card
>>> Interface Driver [1.13] Unable to handle kernel NULL
>>> pointer dereference at virtual address 002a [1.13]
>>> pgd = c0004000 [1.13] [002a] *pgd= [
>>> 1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [
>>> 1.14] Modules linked in: [1.14] CPU: 0 PID: 1 Comm:
>>> swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3 [
>>> 1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [
>>> 1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is
>>> at clk_prepare_lock+0xc/0xd8 [1.165000] pc : []
>>> lr : []psr: a113 [1.165000] sp : ef0a9e20
>>> ip : ee94eb40  fp :  [1.175000] r10: c0571510  r9 :
>>> ef0a8000  r8 : ef227a10 [1.18] r7 : c043544c  r6 :
>>> fffe  r5 : ee94ead0  r4 : fffe [1.185000] r3 :
>>> ef0a4000  r2 : 0001  r1 : 02b9  r0 : 0001 [
>>> 1.195000] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
>>> Segment kernel [1.20] Control: 10c5387d  Table:
>>> 4000404a  DAC: 0015 [1.205000] Process swapper/0 (pid:
>>> 1, stack limit = 0xef0a8240) [1.21] Stack: (0xef0a9e20
>>> to 0xef0aa000) [1.215000] 9e20: c0308474 ee9ea610 ee94ead0
>>> c0308488 c0308474 ee9ea610  c030592c [1.225000]
>>> 9e40: ef227a10 1000 c043544c c020a920 c0838b04 17d78400
>>> ee9ea610 ef227a00 [1.235000] 9e60: ef227a10 c05d6b1c
>>>  c05d6b1c c05890b0 ef0a8000 c0571510 c0269448 [
>>> 1.24] 9e80: c0269430 ef227a10 c061291c c0268088  
>>> ef227a10 c05d6b1c ef227a44 [1.25] 9ea0: 
>>> c026822c  c05d6b1c c02681a0 c02668a8 ef005478 ef212740 
>>> [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
>>> c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
>>> 0006 c059575c c05df580 c026884c  c05a2e14 0006
>>> c00088dc [1.275000] 9f00: c0603f70 ef163e00 c040e334
>>> 6113 c05b5000 a113 c05b5054 c05b5050 [1.28]
>>> 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093 c0035158
>>> c05b5054 c05a2a20 [1.29] 9f40: c050ae2c c054a438
>>> 0006 0006  c05a2e14 0006 c059575c [
>>> 1.30] 9f60: c05df580 0093 c0595768 c0571510  
>>> c0571c48 0006 0006 [1.305000] 9f80: c0571510
>>> c003df68  c0403544     
>>> [1.315000] 9fa0:  c040354c  c000e738
>>>     [1.32] 9fc0:
>>>       
>>>  [1.33] 9fe0:   
>>>  0013  be73efa4 bffd [1.34]
>>> [] (clk_get_rate+0x18/0x5c) from [] 
>>> (dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
>>> [] (dw_mci_exynos_setup_clock+0x14/0x2c) from 
>>> [] (dw_mci_probe+0x15c/0xca4) [1.36]
>>> [] (dw_mci_probe+0x15c/0xca4) from []
>>> (platform_drv_probe+0x18/0x48) [1.365000] []
>>> (platform_drv_probe+0x18/0x48) from []
>>> (driver_probe_device+0x100/0x218) [1.375000] []
>>> (driver_probe_device+0x100/0x218) from []
>>> (__driver_attach+0x8c/0x90) [1.385000] []
>>> (__driver_attach+0x8c/0x90) from []
>>> (bus_for_each_dev+0x54/0x88) [1.395000] []
>>> (bus_for_each_dev+0x54/0x88) from []
>>> (bus_add_driver+0xd4/0x1d0) [1.405000] []
>>> (bus_add_driver+0xd4/0x1d0) from []
>>> (driver_register+0x78/0xf4) [1.415000] []
>>> (driver_register+0x78/0xf4) from []
>>> (do_one_initcall+0xec/0x148) [1.42] []
>>> (do_one_initcall+0xec/0x148) from []
>>> (kernel_init_freeable+0xfc/0x1c8) [1.43] []
>>> (kernel_init_freeable+0xfc/0x1c8) from []
>>> (kernel_init+0x8/0x110) [1.44] []
>>> (kernel_init+0x8/0x110) from [] 
>>> (ret_from_fork+0x14/0x3c) [1.45] Code: ebfffd18
>>> e354 01a05004 0a08 (e594302c)
>> 
>> 
>> Looks like a clock issue on 4412? I only have 5250 that I boot
>> test on, no EXY

Re: linux 3.13-rc1 make dw_mmc-exynos more worse

[Tomasz Figa]

On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
> Hi,
> 
> On Sun, Nov 24, 2013 at 4:07 AM, randy  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > After pull the merge of 3.13-rc1, the dw_mmc-exynos will make the boot
> > stock.In 3.13, it is just stocked udev in 3.13 and makse udev timeout
> > but kernel report the emmc device is found.
> >
> > And in the Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I
> > saw that it is need to define which gpio ports that a emmc slot use,
> > but when I watched others dts, they use pinctrl, which is correct?
> > Here is the log and dts
> 
> [..]
> 
> > ===log begin =
> [..]
> > [0.00] CPU EXYNOS4412 (id 0xe4412011)
> 
> [..]
> 
> > [1.095000] mmc0: no vmmc regulator found
> > [1.13] mmc0: SDHCI controller on samsung-hsmmc
> > [1253.sdhci] using ADMA
> > [1.13] Synopsys Designware Multimedia Card Interface Driver
> > [1.13] Unable to handle kernel NULL pointer dereference at
> > virtual address 002a
> > [1.13] pgd = c0004000
> > [1.13] [002a] *pgd=
> > [1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > [1.14] Modules linked in:
> > [1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > 3.13.0-rc1-8-g584fa45-dirty #3
> > [1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000
> > [1.155000] PC is at clk_get_rate+0x18/0x5c
> > [1.16] LR is at clk_prepare_lock+0xc/0xd8
> > [1.165000] pc : []lr : []psr: a113
> > [1.165000] sp : ef0a9e20  ip : ee94eb40  fp : 
> > [1.175000] r10: c0571510  r9 : ef0a8000  r8 : ef227a10
> > [1.18] r7 : c043544c  r6 : fffe  r5 : ee94ead0  r4 : fffe
> > [1.185000] r3 : ef0a4000  r2 : 0001  r1 : 02b9  r0 : 0001
> > [1.195000] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> > Segment kernel
> > [1.20] Control: 10c5387d  Table: 4000404a  DAC: 0015
> > [1.205000] Process swapper/0 (pid: 1, stack limit = 0xef0a8240)
> > [1.21] Stack: (0xef0a9e20 to 0xef0aa000)
> > [1.215000] 9e20: c0308474 ee9ea610 ee94ead0 c0308488 c0308474
> > ee9ea610  c030592c
> > [1.225000] 9e40: ef227a10 1000 c043544c c020a920 c0838b04
> > 17d78400 ee9ea610 ef227a00
> > [1.235000] 9e60: ef227a10 c05d6b1c  c05d6b1c c05890b0
> > ef0a8000 c0571510 c0269448
> > [1.24] 9e80: c0269430 ef227a10 c061291c c0268088 
> > ef227a10 c05d6b1c ef227a44
> > [1.25] 9ea0:  c026822c  c05d6b1c c02681a0
> > c02668a8 ef005478 ef212740
> > [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864 c0511e38
> > c05d6b1c 0006 c05d6b1c
> > [1.265000] 9ee0: 0006 c059575c c05df580 c026884c 
> > c05a2e14 0006 c00088dc
> > [1.275000] 9f00: c0603f70 ef163e00 c040e334 6113 c05b5000
> > a113 c05b5054 c05b5050
> > [1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
> > c0035158 c05b5054 c05a2a20
> > [1.29] 9f40: c050ae2c c054a438 0006 0006 
> > c05a2e14 0006 c059575c
> > [1.30] 9f60: c05df580 0093 c0595768 c0571510 
> > c0571c48 0006 0006
> > [1.305000] 9f80: c0571510 c003df68  c0403544 
> >   
> > [1.315000] 9fa0:  c040354c  c000e738 
> >   
> > [1.32] 9fc0:     
> >   
> > [1.33] 9fe0:     0013
> >  be73efa4 bffd
> > [1.34] [] (clk_get_rate+0x18/0x5c) from []
> > (dw_mci_exynos_setup_clock+0x14/0x2c)
> > [1.35] [] (dw_mci_exynos_setup_clock+0x14/0x2c) from
> > [] (dw_mci_probe+0x15c/0xca4)
> > [1.36] [] (dw_mci_probe+0x15c/0xca4) from
> > [] (platform_drv_probe+0x18/0x48)
> > [1.365000] [] (platform_drv_probe+0x18/0x48) from
> > [] (driver_probe_device+0x100/0x218)
> > [1.375000] [] (driver_probe_device+0x100/0x218) from
> > [] (__driver_attach+0x8c/0x90)
> > [1.385000] [] (__driver_attach+0x8c/0x90) from
> > [] (bus_for_each_dev+0x54/0x88)
> > [1.395000] [] (bus_for_each_dev+0x54/0x88) from
> > [] (bus_add_driver+0xd4/0x1d0)
> > [1.405000] [] (bus_add_driver+0xd4/0x1d0) from
> > [] (driver_register+0x78/0xf4)
> > [1.415000] [] (driver_register+0x78/0xf4) from
> > [] (do_one_initcall+0xec/0x148)
> > [1.42] [] (do_one_initcall+0xec/0x148) from
> > [] (kernel_init_freeable+0xfc/0x1c8)
> > [1.43] [] (kernel_init_freeable+0xfc/0x1c8) from
> > [] (kernel_init+0x8/0x110)
> > [1.44] [] (kernel_init+0x8/0x110) from []
> > (ret_from_fork+0x14/0x3c)
> > [1.45] Code: ebfffd18 e354 01a05004 0a08 (e594302c)
> 
> 
> Looks like a clock issue on 4412? I only have 5250 that I boot test
> on, no EXYNOS4 coverage at all (I had an Odroid-X but it w

Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes

[Tomasz Figa]

On Monday 25 of November 2013 15:46:12 Linus Walleij wrote:
> On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa  wrote:
> > Stephen:
> >> Is the lifetime of the string "returned" by
> >> of_property_read_string_index() really so short that you must copy the
> >> string? I'd be tempted just to store the pointer, although perhaps you
> >> need to get() the node so that's safe.
> >
> > Right. I have done it the copy-less way in other places, but missed this
> > one. Thanks.
> 
> So I guess I'm waiting for a new version of this patch, right?

Right.

Best regards,
Tomasz

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

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Tomasz Figa]

On Monday 25 of November 2013 22:01:42 Kevin Bracey wrote:
> On 25/11/2013 16:34, Linus Walleij wrote:
> > On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park  wrote:
> >> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren  
> >> wrote:
> >>> I think that last point should be addressed by having a driver that owns
> >>> the GPIO set it to the desired output level, and the implementation of
> >> Some pins are not connected (NC). At that cases, there's no drivers to
> >> handle it. To reduce power leakage, it sets proper configuration with
> >> values instead of reset values.
> > This is correspondant to the PIN_CONFIG_OUTPUT from
> > include/linux/pinctrl/pinconf-generic.h
> 
> Indeed it is - I was waiting for someone to point that out. Now we've 
> got there...
> 
> I've been working on extending the shmobile PFC driver to provide 
> "gpio-mode" and implement PIN_CONFIG_OUTPUT as described by 
> Documentation/pinctrl.txt, primarily to handle sleep states, but I have 
> begun to wonder about the initial state problem, as discussed here.
> 
> As far as I can see, we can't currently specify "fallback" states for 
> pins, which is one of Tomasz' key requirements.
> 
> We can specify "hog" states, and we can specify "default for a driver", 
> but not "default before/in absence of a driver" or "sleep in absence of 
> a driver". Having a hog precludes any finer driver control, AFAICT.
> 
> Some of our existing pre-pinconf board files have a "unused pins" table 
> which is used to claim and pull GPIOs. I've converted that to "hog" 
> pinconf, but that only works because the table omits all pins used by 
> drivers. And, unsurprisingly, that's been error-prone; if those tables 
> originally covered all unused pins, they don't any more.
> 
> I'd like confidence that we can get every pin into the correct state by 
> having a fully-populated table containing all pins, that can be used 
> regardless of which drivers start. I think what we're lacking is a "weak 
> hog". Whatever you call that. :)
> 
> That would also specify the state to fallback to when a group is 
> released (where we currently do pinmux_disable_setting).
> 
> Thoughts?

I fully agree with Kevin. We're currently also using "hogs" for this, but
as Kevin mentioned, this is error prone, as it can be used for pins that
are not touched by any drivers.

IMHO a way to specify a default safe state of all pins (with lowest power
consumption, without possibility of glitching external devices, etc.)
would be really useful for Samsung platforms (and probably Renesas ones
as Kevin wrote).

Best regards,
Tomasz

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Ben Dooks]

On Mon, Nov 25, 2013 at 02:55:37PM -0800, Doug Anderson wrote:
> On modern SoCs the watchdog timer is parented on a clock that doesn't
> change every time we have a cpufreq change.  That means we don't need
> to constantly adjust the watchdog timer, so avoid registering for and
> dealing with cpufreq transitions unless we've actually got
> CPU_FREQ_S3C24XX defined.

The S3C2410 to at-least S3C2440 there is only one PLL/clock-divider
set so changing any part of that can change frequency supplied to
the watchdog.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Tomasz Figa]

On Tuesday 26 of November 2013 00:08:31 Ben Dooks wrote:
> On Mon, Nov 25, 2013 at 02:55:37PM -0800, Doug Anderson wrote:
> > On modern SoCs the watchdog timer is parented on a clock that doesn't
> > change every time we have a cpufreq change.  That means we don't need
> > to constantly adjust the watchdog timer, so avoid registering for and
> > dealing with cpufreq transitions unless we've actually got
> > CPU_FREQ_S3C24XX defined.
> 
> The S3C2410 to at-least S3C2440 there is only one PLL/clock-divider
> set so changing any part of that can change frequency supplied to
> the watchdog.

And so we're leaving the notifier code intact, just changing the ifdef
conditionm which decides whether it should be compiled in, from a (too)
generic one to an S3C24xx-specific one.

Best regards,
Tomasz

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

Re: [PATCH V9 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register

[Tomasz Figa]

On Monday 25 of November 2013 14:44:01 Doug Anderson wrote:
> > +
> >  struct s3c2410_wdt {
> > struct device   *dev;
> > struct clk  *clock;
> > @@ -94,7 +107,49 @@ struct s3c2410_wdt {
> > unsigned long   wtdat_save;
> > struct watchdog_device  wdt_device;
> > struct notifier_block   freq_transition;
> > +   struct s3c2410_wdt_variant *drv_data;
> > +   struct regmap *pmureg;
> 
> Total nit, but everything else in this structure is tab aligned and
> your new elements are not.

That would mean adding extra tabs in lines above to align them with the
longest drv_data field.

AFAIK we're observing a trend of moving away from such field alignment,
so IMHO it would be better to keep this as is in this version and just
send a separate patch removing the alignment of remaining fields.

> 
> >  static int s3c2410wdt_probe(struct platform_device *pdev)
> >  {
> > struct device *dev;
> > @@ -354,6 +443,16 @@ static int s3c2410wdt_probe(struct platform_device 
> > *pdev)
> > spin_lock_init(&wdt->lock);
> > wdt->wdt_device = s3c2410_wdd;
> >
> > +   wdt->drv_data = get_wdt_drv_data(pdev);
> > +   if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> > +   wdt->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> > +   
> > "samsung,syscon-phandle");
> > +   if (IS_ERR(wdt->pmureg)) {
> > +   dev_err(dev, "syscon regmap lookup failed.\n");
> > +   return PTR_ERR(wdt->pmureg);
> 
> nit: this function appears to never call "return" directly.  You'll
> match other error handling better if you do:
> 
> ret = PTR_ERR(wdt->pmureg);
> goto err;

Jumping away just to a single return statement isn't really a good idea.
If there is nothing to do, returning right away seems less confusing IMHO
(and saves you one line of code per each such error case as a side
effect).

A separate patch could be possibly made to clean-up remaining error cases
and remove the err label.

As for all the remaining points, I agree with Doug.

Best regards,
Tomasz

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

Re: [PATCH v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ

[Tomasz Figa]

On Monday 25 of November 2013 15:36:43 Doug Anderson wrote:
> On modern SoCs the watchdog timer is parented on a clock that doesn't
> change every time we have a cpufreq change.  That means we don't need
> to constantly adjust the watchdog timer, so avoid registering for and
> dealing with cpufreq transitions unless we've actually got
> CONFIG_ARM_S3C24XX_CPUFREQ defined.
> 
> Note that this is more than just an optimization.  The s3c2410
> watchdog driver actually pats the watchdog on every CPU frequency
> change.  On modern systems these happen many times per second (even in
> a system where "nothing" is happening).  That effectively makes any
> userspace watchdog program useless (the watchdog is constantly patted
> by the kernel).  If we need ARM_S3C24XX_CPUFREQ defined on a
> multiplatform kernel we'll need to make sure that kernel supports
> common clock and change this to user common clock framework.
> 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2:
> - Use the updated config name.
> 
>  drivers/watchdog/s3c2410_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

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

[PATCH v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ

[Doug Anderson]

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CONFIG_ARM_S3C24XX_CPUFREQ defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need ARM_S3C24XX_CPUFREQ defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- Use the updated config name.

 drivers/watchdog/s3c2410_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..c1ada33 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_S3C24XX_CPUFREQ
 
 static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb,
  unsigned long val, void *data)
-- 
1.8.4.1

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

Re: [PATCH v3] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Doug Anderson]

Naveen,

On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi
 wrote:
> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
> on a fixed 66 MHz peripheral clock, and therefore is completely
> independent of the cpu frequency.
> Thus, registering for a CPU freq notifier is very wasteful.
>
> This patch modifes the code such that, i2c bus registers to
> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>
> This change should save a bunch of cpufreq transitions calls
> which does not apply to exynos SoCs.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Acked-by: Kyungmin Park 
> Reviewed-by: Doug Anderson 
> ---
> Changes since v2:
> None, Rebased on for-next of linux-i2c git repo.
>
> Changes since v1:
> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
> As commented by Tomasz
>
>  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Can you please spin this with comments from
?  Thanks!

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Tomasz Figa]

On Monday 25 of November 2013 15:28:29 Doug Anderson wrote:
> Guenter,
> 
> On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck  wrote:
> > On 11/25/2013 02:55 PM, Doug Anderson wrote:
> >>
> >> On modern SoCs the watchdog timer is parented on a clock that doesn't
> >> change every time we have a cpufreq change.  That means we don't need
> >> to constantly adjust the watchdog timer, so avoid registering for and
> >> dealing with cpufreq transitions unless we've actually got
> >> CPU_FREQ_S3C24XX defined.
> >>
> >> Note that this is more than just an optimization.  The s3c2410
> >> watchdog driver actually pats the watchdog on every CPU frequency
> >> change.  On modern systems these happen many times per second (even in
> >> a system where "nothing" is happening).  That effectively makes any
> >> userspace watchdog program useless (the watchdog is constantly patted
> >> by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
> >> multiplatform kernel we'll need to make sure that kernel supports
> >> common clock and change this to user common clock framework.
> >>
> >> Signed-off-by: Doug Anderson 
> >> ---
> >>   drivers/watchdog/s3c2410_wdt.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/watchdog/s3c2410_wdt.c
> >> b/drivers/watchdog/s3c2410_wdt.c
> >> index 7d8fd04..4980f84 100644
> >> --- a/drivers/watchdog/s3c2410_wdt.c
> >> +++ b/drivers/watchdog/s3c2410_wdt.c
> >> @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void
> >> *param)
> >> return IRQ_HANDLED;
> >>   }
> >>
> >> -#ifdef CONFIG_CPU_FREQ
> >> +#ifdef CONFIG_CPU_FREQ_S3C24XX
> >>
> > Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> > in the current upstream kernel, so it appears that this depends on some
> > out-of-tree changes.
> 
> Whoops!  I guess I just trusted another patch and didn't dig.  I was
> basing this on https://patchwork.kernel.org/patch/3023421/
> 
> Ah, I see that Tomasz just found the answer.  I'll update my patch.

Seems like I originally gave you the wrong symbol name, looking at our
internal 3.10 tree, where the rename is not present yet, and nobody
noticed. Sorry for that.

Best regards,
Tomasz

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

RE: [PATCH] ARM: exynos_defconfig: increase CONFIG_NR_CPUS value to 8

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Bart,
> 
> On Thursday 21 of November 2013 13:06:06 Bartlomiej Zolnierkiewicz wrote:
> > Current CONFIG_NR_CPUS value (2) is too small for:
> > - EXYNOS4412 (4 cores)
> > - EXYNOS5440 (4 cores)
> > - EXYNOS5410 (8 cores)
> > - EXYNOS5420 (8 cores)
> >
> > Set CONFIG_NR_CPUS to 8 so it is correct for all currently
> > supported SoCs.
> >
> > Signed-off-by: Kyungmin Park 
> > Signed-off-by: Bartlomiej Zolnierkiewicz 
> > ---
> >  arch/arm/configs/exynos_defconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Definitely a change we want to have.
> 
> Reviewed-by: Tomasz Figa 
> 
Applied and you can see this in my tree in a couple of days.

Thanks,
Kukjin

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Tomasz Figa]

On Monday 25 of November 2013 15:23:27 Guenter Roeck wrote:
> On 11/25/2013 02:55 PM, Doug Anderson wrote:
> > On modern SoCs the watchdog timer is parented on a clock that doesn't
> > change every time we have a cpufreq change.  That means we don't need
> > to constantly adjust the watchdog timer, so avoid registering for and
> > dealing with cpufreq transitions unless we've actually got
> > CPU_FREQ_S3C24XX defined.
> >
> > Note that this is more than just an optimization.  The s3c2410
> > watchdog driver actually pats the watchdog on every CPU frequency
> > change.  On modern systems these happen many times per second (even in
> > a system where "nothing" is happening).  That effectively makes any
> > userspace watchdog program useless (the watchdog is constantly patted
> > by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
> > multiplatform kernel we'll need to make sure that kernel supports
> > common clock and change this to user common clock framework.
> >
> > Signed-off-by: Doug Anderson 
> > ---
> >   drivers/watchdog/s3c2410_wdt.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> > index 7d8fd04..4980f84 100644
> > --- a/drivers/watchdog/s3c2410_wdt.c
> > +++ b/drivers/watchdog/s3c2410_wdt.c
> > @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void 
> > *param)
> > return IRQ_HANDLED;
> >   }
> >
> > -#ifdef CONFIG_CPU_FREQ
> > +#ifdef CONFIG_CPU_FREQ_S3C24XX
> >
> Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> in the current upstream kernel, so it appears that this depends on some
> out-of-tree changes.

Seems like it got renamed to ARM_S3C24XX_CPUFREQ by f023f8dd59.

Best regards,
Tomasz

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Doug Anderson]

Guenter,

On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck  wrote:
> On 11/25/2013 02:55 PM, Doug Anderson wrote:
>>
>> On modern SoCs the watchdog timer is parented on a clock that doesn't
>> change every time we have a cpufreq change.  That means we don't need
>> to constantly adjust the watchdog timer, so avoid registering for and
>> dealing with cpufreq transitions unless we've actually got
>> CPU_FREQ_S3C24XX defined.
>>
>> Note that this is more than just an optimization.  The s3c2410
>> watchdog driver actually pats the watchdog on every CPU frequency
>> change.  On modern systems these happen many times per second (even in
>> a system where "nothing" is happening).  That effectively makes any
>> userspace watchdog program useless (the watchdog is constantly patted
>> by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
>> multiplatform kernel we'll need to make sure that kernel supports
>> common clock and change this to user common clock framework.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>>   drivers/watchdog/s3c2410_wdt.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c
>> b/drivers/watchdog/s3c2410_wdt.c
>> index 7d8fd04..4980f84 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void
>> *param)
>> return IRQ_HANDLED;
>>   }
>>
>> -#ifdef CONFIG_CPU_FREQ
>> +#ifdef CONFIG_CPU_FREQ_S3C24XX
>>
> Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> in the current upstream kernel, so it appears that this depends on some
> out-of-tree changes.

Whoops!  I guess I just trusted another patch and didn't dig.  I was
basing this on https://patchwork.kernel.org/patch/3023421/

Ah, I see that Tomasz just found the answer.  I'll update my patch.

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

Re: [PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Guenter Roeck]

On 11/25/2013 02:55 PM, Doug Anderson wrote:

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CPU_FREQ_S3C24XX defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
  drivers/watchdog/s3c2410_wdt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..4980f84 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
  }

-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_S3C24XX


Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
in the current upstream kernel, so it appears that this depends on some
out-of-tree changes.

Thanks,
Guenter

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

[PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

[Doug Anderson]

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CPU_FREQ_S3C24XX defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.

Signed-off-by: Doug Anderson 
---
 drivers/watchdog/s3c2410_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..4980f84 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param)
return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_CPU_FREQ_S3C24XX
 
 static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb,
  unsigned long val, void *data)
-- 
1.8.4.1

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

Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[Rafael J. Wysocki]

On Monday, November 25, 2013 07:41:41 PM Viresh Kumar wrote:
> 
> This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors. This is required for early suspend and
> late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board 
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung,
>   tegra, etc.. They solved it with driver specific PM notifiers where they
>   used to disable their driver's ->target() routine.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
> 
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> Reported-by: Lan Tianyu 
> Reported-by: Nishanth Menon 
> Reported-by: Jinhyuk Choi 
> Signed-off-by: Viresh Kumar 
> 
> ---
> drivers/base/power/main.c |  5 +
> 
>  drivers/cpufreq/cpufreq.c | 50
>  +++ include/linux/cpufreq.h  
>  |  3 +++
>  3 files changed, 58 insertions(+)
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 1b41fca..c9fbb9d 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -29,6 +29,7 @@
> 
>  #include 
>  #include 
>  #include 
> 
> +#include 
> 
>  #include 
>  #include 
> 
> @@ -789,6 +790,8 @@ void dpm_resume(pm_message_t state)
> 
>   mutex_unlock(&dpm_list_mtx);
>   async_synchronize_full();
>   dpm_show_time(starttime, state, NULL);
> 
> +
> + cpufreq_resume();
> 
>  }
>  
>  /**
> 
> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> 
>   might_sleep();
> 
> + cpufreq_suspend();
> +
> 
>   mutex_lock(&dpm_list_mtx);
>   pm_transition = state;
>   async_error = 0;

Shouldn't it do cpufreq_resume() on errors?

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 02d534d..b6c7821 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -26,6 +26,7 @@
> 
>  #include 
>  #include 
>  #include 
> 
> +#include 
> 
>  #include 
>  #include 
>  #include 
> 
> @@ -47,6 +48,9 @@ static LIST_HEAD(cpufreq_policy_list);
> 
>  static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
>  #endif
> 
> +/* Flag to suspend/resume CPUFreq governors */
> +static bool cpufreq_suspended;
> +
> 
>  static inline bool has_target(void)
>  {
>  
>   return cpufreq_driver->target_index || cpufreq_driver->target;
> 
> @@ -1462,6 +1466,48 @@ static struct subsys_interface cpufreq_interface = {
> 
>   .remove_dev = cpufreq_remove_dev,
>  
>  };
> 
> +/*
> + * Callbacks for suspending/resuming governors as some platforms can't
> change + * frequency after this point in suspend cycle. Because some of the
> devices + * (like: i2c, regulators, etc) they use for changing frequency
> are suspended + * quickly after this point.
> + */
> +void cpufreq_suspend(void)
> +{
> + struct cpufreq_policy *policy;
> +
> + if (!has_target())
> + return;
> +
> + pr_debug("%s: Suspending Governors\n", __func__);
> +
> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> + pr_err("%s: Failed to stop governor for policy: %p\n",
> + __func__, policy);

This appears to be racy.  Is it really racy, or just seemingly?

> +
> + cpufreq_suspended = true;
> +}
> +
> +void cpufreq_resume(void)
> +{
> + struct cpufreq_policy *policy;
> +
> + if (!has_target())
> + return;
> +
> + pr_debug("%s: Resuming Governors\n", __func__);
> +
> + cpufreq_suspended = false;
> +
> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> + if (__cpufreq_governor(policy, CPUFREQ_GOV_START) ||
> + __cpufreq_governor(policy,
> + CPUFREQ_GOV_LIMITS))
> + pr_err("%s: Failed to start governor for policy: %p\n",
> + __func__, policy);
> +}
> +
> 
>  /**
>  
>   * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
>   *
> 
> @@ -1764,6 +1810,10 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,> 
>   struct cpufreq_governor *gov = NULL;
>  
>  #endif
> 
> + /* Don't start any gove

Re: [PATCH V9 3/3] ARM: dts: update watchdog device nodes for Exynos5250 and Exynos5420

[Doug Anderson]

Leela Krishna,

On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala
 wrote:
> In Exynos5 series SoCs, PMU has registers to enable/disable mask/unmask
> watchdog timer which is not the case with s3c series SoCs so, there is a
> need to have different compatible names for watchdog to handle these pmu
> registers access.
>
> Hence this patch removes watchdog node from Exynos5.dtsi common file and
> make it separate by updating existing node in Exynos5250 and adding new node
> to Exynos5420. This patch also makes the watchdog node enabled by default
>
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Tomasz Figa 
> ---
>  arch/arm/boot/dts/exynos5.dtsi|7 ---
>  arch/arm/boot/dts/exynos5250.dtsi |6 +-
>  arch/arm/boot/dts/exynos5420.dtsi |9 +
>  3 files changed, 14 insertions(+), 8 deletions(-)

I've got this locally running in our tree
 based on your
patch.

Reviewed-by: Doug Anderson 
Tested-by: Doug Anderson 

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

Re: [PATCH V9 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register

[Doug Anderson]

Hi Leela Krishna,

On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala
 wrote:
> Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap 
> interface
> to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST registers 
> of PMU
> to mask/unmask enable/disable of watchdog in probe and s2r scenarios.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  .../devicetree/bindings/watchdog/samsung-wdt.txt   |   21 ++-
>  drivers/watchdog/Kconfig   |1 +
>  drivers/watchdog/s3c2410_wdt.c |  145 
> ++--
>  3 files changed, 157 insertions(+), 10 deletions(-)

...

> +struct s3c2410_wdt_variant {
> +   int disable_reg;
> +   int mask_reset_reg;
> +   int mask_bit;
> +   u32 quirks;
> +};

Ideally you could add descriptions.  I added them in a patch based on
yours 
,
but since yours hasn't landed perhaps you can do it directly?

/**
 * struct s3c2410_wdt_variant - Per-variant config data
 *
 * @disable_reg: Offset in pmureg for the register that disables the watchdog
 * timer reset functionality.
 * @mask_reset_reg: Offset in pmureg for the register that masks the watchdog
 * timer reset functionality.
 * @mask_bit: Bit number for the watchdog timer in the disable register and the
 * mask reset register.
 * @quirks: A bitfield of quirks.
 */

> +
>  struct s3c2410_wdt {
> struct device   *dev;
> struct clk  *clock;
> @@ -94,7 +107,49 @@ struct s3c2410_wdt {
> unsigned long   wtdat_save;
> struct watchdog_device  wdt_device;
> struct notifier_block   freq_transition;
> +   struct s3c2410_wdt_variant *drv_data;
> +   struct regmap *pmureg;

Total nit, but everything else in this structure is tab aligned and
your new elements are not.

>  static int s3c2410wdt_probe(struct platform_device *pdev)
>  {
> struct device *dev;
> @@ -354,6 +443,16 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
> spin_lock_init(&wdt->lock);
> wdt->wdt_device = s3c2410_wdd;
>
> +   wdt->drv_data = get_wdt_drv_data(pdev);
> +   if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> +   wdt->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> +   
> "samsung,syscon-phandle");
> +   if (IS_ERR(wdt->pmureg)) {
> +   dev_err(dev, "syscon regmap lookup failed.\n");
> +   return PTR_ERR(wdt->pmureg);

nit: this function appears to never call "return" directly.  You'll
match other error handling better if you do:

ret = PTR_ERR(wdt->pmureg);
goto err;

(if someone else has already said they don't like that, just ignore me).

> +   }
> +   }
> +
> wdt_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (wdt_irq == NULL) {
> dev_err(dev, "no irq resource specified\n");
> @@ -444,6 +543,14 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>  (wtcon & S3C2410_WTCON_RSTEN) ? "en" : "dis",
>  (wtcon & S3C2410_WTCON_INTEN) ? "en" : "dis");
>
> +   if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> +   ret = s3c2410wdt_mask_and_disable_reset(wdt, false);
> +   if (ret < 0) {
> +   dev_err(wdt->dev, "failed to update pmu register");
> +   goto err_cpufreq;
> +   }
> +   }

There are a few minor problems here:

1. You're putting a potential failure condition _after_ printing that
the watchdog is enabled.  You should put your code above the
"dev_info".

2. Error handling doesn't seem quite right.  If you fail here you'll
be returning an error but you might have started the watchdog already.
 Perhaps you should be moving the "mask_and_disable" up a little and
then you an undo it if needed?

3. I think it would be fine to put the "dev_err" directly in the
s3c2410wdt_mask_and_disable_reset() as per Guenter, but still return
the error code.  You'll still use the error code here, right?

> +
> return 0;
>
>   err_cpufreq:
> @@ -459,8 +566,15 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>
>  static int s3c2410wdt_remove(struct platform_device *dev)
>  {
> +   int ret;
> struct s3c2410_wdt *wdt = platform_get_drvdata(dev);
>
> +   if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> +   ret = s3c2410wdt_mask_and_disable_reset(wdt, true);

This function does return an error.  Why not pass the error on
through?  The system wouldn't be in such a stellar state, but if
regmap is failing it's probably pretty bad anyway...



Nothing here is terrible and I wouldn't be upset if you landed these
as-is, but since it seems that Guenter is requesting a spin.  Perhaps
you could address my comments, too?


-Doug
--

Re: [PATCH V9 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files

[Doug Anderson]

Hi Leela Krishna,

On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala
 wrote:
> This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to
> handle PMU register accesses in a centralized way using syscon driver
>
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Tomasz Figa 
> ---
>  Documentation/devicetree/bindings/arm/samsung/pmu.txt |   16 
>  arch/arm/boot/dts/exynos5250.dtsi |5 +
>  arch/arm/boot/dts/exynos5420.dtsi |5 +
>  3 files changed, 26 insertions(+)

Looks good to me.  I've tested this applied to our local tree
 and it's
working well for me.

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

Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

[Nishanth Menon]

On 11/25/2013 08:11 AM, Viresh Kumar wrote:
> This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors and core. This is required for early 
> suspend
> and late resume of governors and cpufreq core.
> 
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
> board
>   wasn't working well with suspend/resume as calls for removing non-boot CPUs
>   was turning out into a call to drivers ->target() which then tries to play
>   with regulators. But regulators and their I2C bus were already suspended and
>   this resulted in a failure. Many platforms have such problems, samsung, 
> tegra,
>   etc.. They solved it with driver specific PM notifiers where they used to
>   disable their driver's ->target() routine. Most of these are updated in this
>   patchset to use new infrastructure.
> 
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
>   tunables configuration for clusters/sockets with non-boot CPUs was getting
>   lost after suspend/resume, as we were notifying governors with
>   CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
>   deallocating memory for tunables. This is also fixed with this patch as 
> don't
>   allow any operation on Governors during suspend/resume now.
> 
> 
> So to solve these issues we introduce early suspend and late resume callbacks
> which would remove need of cpufreq drivers to implement PM notifiers to 
> disable
> transition after suspend and before resume.
> 
> @Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
> doesn't work for you. I am sure it will not, but would be better if you 
> confirm
> that.
> 
> Viresh Kumar (6):
>   cpufreq: suspend governors on system suspend/hibernate
>   cpufreq: call driver's suspend/resume for each policy
patches 1-2,
Tested-by: Nishanth Menon 
http://pastebin.mozilla.org/3670932

Prior to these two patches: http://pastebin.mozilla.org/3670933
cpufreq driver used: cpufreq_cpu0


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

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Kevin Bracey]

On 25/11/2013 16:34, Linus Walleij wrote:

On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park  wrote:

On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren  wrote:

I think that last point should be addressed by having a driver that owns
the GPIO set it to the desired output level, and the implementation of

Some pins are not connected (NC). At that cases, there's no drivers to
handle it. To reduce power leakage, it sets proper configuration with
values instead of reset values.

This is correspondant to the PIN_CONFIG_OUTPUT from
include/linux/pinctrl/pinconf-generic.h


Indeed it is - I was waiting for someone to point that out. Now we've 
got there...


I've been working on extending the shmobile PFC driver to provide 
"gpio-mode" and implement PIN_CONFIG_OUTPUT as described by 
Documentation/pinctrl.txt, primarily to handle sleep states, but I have 
begun to wonder about the initial state problem, as discussed here.


As far as I can see, we can't currently specify "fallback" states for 
pins, which is one of Tomasz' key requirements.


We can specify "hog" states, and we can specify "default for a driver", 
but not "default before/in absence of a driver" or "sleep in absence of 
a driver". Having a hog precludes any finer driver control, AFAICT.


Some of our existing pre-pinconf board files have a "unused pins" table 
which is used to claim and pull GPIOs. I've converted that to "hog" 
pinconf, but that only works because the table omits all pins used by 
drivers. And, unsurprisingly, that's been error-prone; if those tables 
originally covered all unused pins, they don't any more.


I'd like confidence that we can get every pin into the correct state by 
having a fully-populated table containing all pins, that can be used 
regardless of which drivers start. I think what we're lacking is a "weak 
hog". Whatever you call that. :)


That would also specify the state to fallback to when a group is 
released (where we currently do pinmux_disable_setting).


Thoughts?

Kevin


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

Re: [PATCH V3 0/6] cpufreq: suspend early/resume late

[Stephen Warren]

On 11/25/2013 07:11 AM, Viresh Kumar wrote:
> This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors and core. This is required for early 
> suspend
> and late resume of governors and cpufreq core.

Patches 1-3,6,
Tested-by: Stephen Warren 

Patch 6,
Acked-by: Stephen Warren 

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

Re: [PATCH v3 3/3] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework

[Matt Porter]

On Tue, Nov 05, 2013 at 05:13:21PM +0100, Kamil Debski wrote:
> Change the used phy driver to the new Exynos USB phy driver that uses the
> generic phy framework.
> 
> Signed-off-by: Kamil Debski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/usb/gadget/s3c-hsotg.c |   12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index bb31262..dc7f20c 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -162,7 +163,7 @@ struct s3c_hsotg_ep {
>  struct s3c_hsotg {
>   struct device*dev;
>   struct usb_gadget_driver *driver;
> - struct usb_phy  *phy;
> + struct phy   *phy;
>   struct s3c_hsotg_plat*plat;
>  
>   spinlock_t  lock;
> @@ -2905,9 +2906,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg 
> *hsotg)
>   dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
>  
>   if (hsotg->phy)
> - usb_phy_init(hsotg->phy);
> + phy_power_on(hsotg->phy);
>   else if (hsotg->plat->phy_init)
>   hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
> +

Stray whitespace

>  }
>  
>  /**
> @@ -2922,7 +2924,7 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg 
> *hsotg)
>   struct platform_device *pdev = to_platform_device(hsotg->dev);
>  
>   if (hsotg->phy)
> - usb_phy_shutdown(hsotg->phy);
> + phy_power_off(hsotg->phy);
>   else if (hsotg->plat->phy_exit)
>   hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
>  }
> @@ -3529,7 +3531,7 @@ static void s3c_hsotg_delete_debug(struct s3c_hsotg 
> *hsotg)
>  static int s3c_hsotg_probe(struct platform_device *pdev)
>  {
>   struct s3c_hsotg_plat *plat = dev_get_platdata(&pdev->dev);
> - struct usb_phy *phy;
> + struct phy *phy;
>   struct device *dev = &pdev->dev;
>   struct s3c_hsotg_ep *eps;
>   struct s3c_hsotg *hsotg;
> @@ -3544,7 +3546,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   }
>  
> - phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + phy = devm_phy_get(&pdev->dev, "device");

A more descriptive string would be useful here IMHO. Since this is USB
2.0 IP, perhaps "usb2-phy" like musb uses.

phy-names = "usb2-phy";

looks far more unique than

phy-names = "device";

in the dts.

Also, this has impact on the samsung-hsotg.txt binding. It should be
updated to reflect the required generic phy properties that will be
used when booting from DT:

- phys: phy provider specifier
- phy-names: shall be "device" 

[or "usb2-phy" if the above suggestion is adopted]

I've rebased my BCM281xx UDC series [1] against this s3c-hsotg generic
phy support and it's working fine. I do add phy_init/phy_exit support
which is probably better coming in with my series as my phy driver
makes use of the init method.

Tested-by: Matt Porter 

-Matt

[1] http://www.kernelhub.org/?msg=367354&p=2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework

[Bartlomiej Zolnierkiewicz]

Hi,

Could you please also apply this patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
> There is little sense in having separate config option for
> registering EXYNOS TMU driver with the core thermal framework.
> Fix it by integrating EXYNOS_THERMAL_CORE config option with
> EXYNOS_THERMAL one.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/thermal/samsung/Kconfig | 14 +++---
>  drivers/thermal/samsung/Makefile|  2 +-
>  drivers/thermal/samsung/exynos_thermal_common.h | 12 
>  3 files changed, 4 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
> index f760389..04eabee 100644
> --- a/drivers/thermal/samsung/Kconfig
> +++ b/drivers/thermal/samsung/Kconfig
> @@ -5,14 +5,6 @@ config EXYNOS_THERMAL
> If you say yes here you get support for the TMU (Thermal Management
> Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver 
> initialises
> the TMU, reports temperature and handles cooling action if defined.
> -   This driver uses the Exynos core thermal APIs and TMU configuration
> -   data from the supported SoCs.
> -
> -config EXYNOS_THERMAL_CORE
> - bool "Core thermal framework support for EXYNOS SOCs"
> - depends on EXYNOS_THERMAL
> - help
> -   If you say yes here you get support for EXYNOS TMU
> -   (Thermal Management Unit) common registration/unregistration
> -   functions to the core thermal layer and also to use the generic
> -   CPU cooling APIs.
> +   This driver uses the Exynos core thermal APIs, TMU configuration data
> +   from the supported SoCs, common registration/unregistration functions
> +   to the core thermal layer and also the generic CPU cooling APIs.
> diff --git a/drivers/thermal/samsung/Makefile 
> b/drivers/thermal/samsung/Makefile
> index c09d830..a829107 100644
> --- a/drivers/thermal/samsung/Makefile
> +++ b/drivers/thermal/samsung/Makefile
> @@ -4,4 +4,4 @@
>  obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
>  exynos_thermal-y := exynos_tmu.o
>  exynos_thermal-y += exynos_tmu_data.o
> -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
> +exynos_thermal-y += exynos_thermal_common.o
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
> b/drivers/thermal/samsung/exynos_thermal_common.h
> index 3eb2ed9..8681679 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.h
> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
> @@ -88,20 +88,8 @@ struct thermal_sensor_conf {
>   struct device *dev;
>  };
>  
> -/*Functions used exynos based thermal sensor driver*/
> -#ifdef CONFIG_EXYNOS_THERMAL_CORE
>  void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
>  int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
>  void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
> -#else
> -static inline void
> -exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) { return; 
> }
>  
> -static inline int
> -exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return 0; 
> }
> -
> -static inline void
> -exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return; }
> -
> -#endif /* CONFIG_EXYNOS_THERMAL_CORE */
>  #endif /* _EXYNOS_THERMAL_COMMON_H */

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

Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

[Bartlomiej Zolnierkiewicz]

Hi,

Could you please apply this patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

On Friday, October 04, 2013 02:36:42 PM Bartlomiej Zolnierkiewicz wrote:
> Menu for Samsung thermal support is visible on all Samsung
> platforms while thermal drivers are currently available only
> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
> with ARCH_EXYNOS one.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/thermal/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a709c63..05cf95c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
>  
>  menu "Samsung thermal drivers"
> -depends on PLAT_SAMSUNG
> +depends on ARCH_EXYNOS
>  source "drivers/thermal/samsung/Kconfig"
>  endmenu

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

Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes

[Linus Walleij]

On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa  wrote:
> Stephen:
>> Is the lifetime of the string "returned" by
>> of_property_read_string_index() really so short that you must copy the
>> string? I'd be tempted just to store the pointer, although perhaps you
>> need to get() the node so that's safe.
>
> Right. I have done it the copy-less way in other places, but missed this
> one. Thanks.

So I guess I'm waiting for a new version of this patch, right?

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

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Linus Walleij]

On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park  wrote:
> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren  wrote:

>> I think that last point should be addressed by having a driver that owns
>> the GPIO set it to the desired output level, and the implementation of

> Some pins are not connected (NC). At that cases, there's no drivers to
> handle it. To reduce power leakage, it sets proper configuration with
> values instead of reset values.

This is correspondant to the PIN_CONFIG_OUTPUT from
include/linux/pinctrl/pinconf-generic.h

I.e. driving a pin - any pin, even one that cannot do GPIO - high
or low as default.

One could argue that if you can drive the pin high/low using
software then by definition it *is* GPIO. Even if it cannot trigger
IRQs or anything.

The rationale for having it in pinconf-generic is basically for
use cases such that one of the the pin config states the device
pass through may relate to what the documentation calls
the "GPIO mode fallacy" - a state on the pins that is definately
related to the use case of a certain device, but puts the pin
in something the manual calls "GPIO mode" in order to save
power.

But from a use case point of view that is not GPIO, it is the
typically the sleep state of a certain pin when used with a
certain device.

I'll see if I can think of some doc patch to make this more clear...

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

[PATCH V3 0/6] cpufreq: suspend early/resume late

[Viresh Kumar]

This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors and core. This is required for early suspend
and late resume of governors and cpufreq core.

There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
board
  wasn't working well with suspend/resume as calls for removing non-boot CPUs
  was turning out into a call to drivers ->target() which then tries to play
  with regulators. But regulators and their I2C bus were already suspended and
  this resulted in a failure. Many platforms have such problems, samsung, tegra,
  etc.. They solved it with driver specific PM notifiers where they used to
  disable their driver's ->target() routine. Most of these are updated in this
  patchset to use new infrastructure.

- Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
  tunables configuration for clusters/sockets with non-boot CPUs was getting
  lost after suspend/resume, as we were notifying governors with
  CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
  deallocating memory for tunables. This is also fixed with this patch as don't
  allow any operation on Governors during suspend/resume now.


So to solve these issues we introduce early suspend and late resume callbacks
which would remove need of cpufreq drivers to implement PM notifiers to disable
transition after suspend and before resume.

@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you confirm
that.

Viresh Kumar (6):
  cpufreq: suspend governors on system suspend/hibernate
  cpufreq: call driver's suspend/resume for each policy
  cpufreq: Implement cpufreq_generic_suspend()
  cpufreq: exynos: Use cpufreq_generic_suspend()
  cpufreq: s5pv210: Use cpufreq_generic_suspend()
  cpufreq: Tegra: Use cpufreq_generic_suspend()

 drivers/base/power/main.c |   5 ++
 drivers/cpufreq/cpufreq.c | 133 +-
 drivers/cpufreq/exynos-cpufreq.c  |  97 ++-
 drivers/cpufreq/s5pv210-cpufreq.c |  49 +-
 drivers/cpufreq/tegra-cpufreq.c   |  54 ++--
 include/linux/cpufreq.h   |   6 ++
 6 files changed, 99 insertions(+), 245 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

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

[PATCH V3 5/6] cpufreq: s5pv210: Use cpufreq_generic_suspend()

[Viresh Kumar]

Currently we have implemented PM notifiers to disable/enable ->target() routines
functionality during suspend/resume.

Now we have support present in cpufreq core, lets use it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/s5pv210-cpufreq.c | 49 +++
 1 file changed, 3 insertions(+), 46 deletions(-)

diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
b/drivers/cpufreq/s5pv210-cpufreq.c
index e3973da..89c052e 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -444,18 +443,6 @@ exit:
return ret;
 }
 
-#ifdef CONFIG_PM
-static int s5pv210_cpufreq_suspend(struct cpufreq_policy *policy)
-{
-   return 0;
-}
-
-static int s5pv210_cpufreq_resume(struct cpufreq_policy *policy)
-{
-   return 0;
-}
-#endif
-
 static int check_mem_type(void __iomem *dmc_reg)
 {
unsigned long val;
@@ -511,6 +498,7 @@ static int __init s5pv210_cpu_init(struct cpufreq_policy 
*policy)
s5pv210_dram_conf[1].refresh = (__raw_readl(S5P_VA_DMC1 + 0x30) * 1000);
s5pv210_dram_conf[1].freq = clk_get_rate(dmc1_clk);
 
+   policy->suspend_freq = SLEEP_FREQ;
return cpufreq_generic_init(policy, s5pv210_freq_table, 4);
 
 out_dmc1:
@@ -520,32 +508,6 @@ out_dmc0:
return ret;
 }
 
-static int s5pv210_cpufreq_notifier_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
-   int ret;
-
-   switch (event) {
-   case PM_SUSPEND_PREPARE:
-   ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
-   if (ret < 0)
-   return NOTIFY_BAD;
-
-   /* Disable updation of cpu frequency */
-   no_cpufreq_access = true;
-   return NOTIFY_OK;
-   case PM_POST_RESTORE:
-   case PM_POST_SUSPEND:
-   /* Enable updation of cpu frequency */
-   no_cpufreq_access = false;
-   cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
-
-   return NOTIFY_OK;
-   }
-
-   return NOTIFY_DONE;
-}
-
 static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
 unsigned long event, void *ptr)
 {
@@ -567,15 +529,11 @@ static struct cpufreq_driver s5pv210_driver = {
.init   = s5pv210_cpu_init,
.name   = "s5pv210",
 #ifdef CONFIG_PM
-   .suspend= s5pv210_cpufreq_suspend,
-   .resume = s5pv210_cpufreq_resume,
+   .suspend= cpufreq_generic_suspend,
+   .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ 
again */
 #endif
 };
 
-static struct notifier_block s5pv210_cpufreq_notifier = {
-   .notifier_call = s5pv210_cpufreq_notifier_event,
-};
-
 static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
.notifier_call = s5pv210_cpufreq_reboot_notifier_event,
 };
@@ -595,7 +553,6 @@ static int __init s5pv210_cpufreq_init(void)
return PTR_ERR(int_regulator);
}
 
-   register_pm_notifier(&s5pv210_cpufreq_notifier);
register_reboot_notifier(&s5pv210_cpufreq_reboot_notifier);
 
return cpufreq_register_driver(&s5pv210_driver);
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH V3 2/6] cpufreq: call driver's suspend/resume for each policy

[Viresh Kumar]

Earlier cpufreq suspend/resume callbacks into drivers were getting called only
for the boot CPU, as by the time callbacks were called non-boot CPUs were
already removed. Because we might still need driver specific actions on
suspend/resume, its better to use earlier infrastructure from the early
suspend/late resume calls.

In effect, we call suspend/resume for each policy. The resume part also takes
care of synchronising frequency for boot CPU, which might turn out be different
than what cpufreq core believes.

Hence, the earlier syscore infrastructure is getting removed now.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 98 +--
 1 file changed, 18 insertions(+), 80 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b6c7821..026efe4a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -1481,10 +1480,15 @@ void cpufreq_suspend(void)
 
pr_debug("%s: Suspending Governors\n", __func__);
 
-   list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+   list_for_each_entry(policy, &cpufreq_policy_list, policy_list) {
if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
pr_err("%s: Failed to stop governor for policy: %p\n",
__func__, policy);
+   else if (cpufreq_driver->suspend &&
+   cpufreq_driver->suspend(policy))
+   pr_err("%s: Failed to suspend driver: %p\n", __func__,
+   policy);
+   }
 
cpufreq_suspended = true;
 }
@@ -1500,92 +1504,27 @@ void cpufreq_resume(void)
 
cpufreq_suspended = false;
 
-   list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+   list_for_each_entry(policy, &cpufreq_policy_list, policy_list) {
if (__cpufreq_governor(policy, CPUFREQ_GOV_START) ||
__cpufreq_governor(policy,
CPUFREQ_GOV_LIMITS))
pr_err("%s: Failed to start governor for policy: %p\n",
__func__, policy);
-}
-
-/**
- * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
- *
- * This function is only executed for the boot processor.  The other CPUs
- * have been put offline by means of CPU hotplug.
- */
-static int cpufreq_bp_suspend(void)
-{
-   int ret = 0;
-
-   int cpu = smp_processor_id();
-   struct cpufreq_policy *policy;
-
-   pr_debug("suspending cpu %u\n", cpu);
-
-   /* If there's no policy for the boot CPU, we have nothing to do. */
-   policy = cpufreq_cpu_get(cpu);
-   if (!policy)
-   return 0;
-
-   if (cpufreq_driver->suspend) {
-   ret = cpufreq_driver->suspend(policy);
-   if (ret)
-   printk(KERN_ERR "cpufreq: suspend failed in ->suspend "
-   "step on CPU %u\n", policy->cpu);
-   }
-
-   cpufreq_cpu_put(policy);
-   return ret;
-}
-
-/**
- * cpufreq_bp_resume - Restore proper frequency handling of the boot CPU.
- *
- * 1.) resume CPUfreq hardware support (cpufreq_driver->resume())
- * 2.) schedule call cpufreq_update_policy() ASAP as interrupts are
- * restored. It will verify that the current freq is in sync with
- * what we believe it to be. This is a bit later than when it
- * should be, but nonethteless it's better than calling
- * cpufreq_driver->get() here which might re-enable interrupts...
- *
- * This function is only executed for the boot CPU.  The other CPUs have not
- * been turned on yet.
- */
-static void cpufreq_bp_resume(void)
-{
-   int ret = 0;
+   else if (cpufreq_driver->resume &&
+   cpufreq_driver->resume(policy))
+   pr_err("%s: Failed to resume driver: %p\n", __func__,
+   policy);
 
-   int cpu = smp_processor_id();
-   struct cpufreq_policy *policy;
-
-   pr_debug("resuming cpu %u\n", cpu);
-
-   /* If there's no policy for the boot CPU, we have nothing to do. */
-   policy = cpufreq_cpu_get(cpu);
-   if (!policy)
-   return;
-
-   if (cpufreq_driver->resume) {
-   ret = cpufreq_driver->resume(policy);
-   if (ret) {
-   printk(KERN_ERR "cpufreq: resume failed in ->resume "
-   "step on CPU %u\n", policy->cpu);
-   goto fail;
-   }
+   /*
+* schedule call cpufreq_update_policy() for boot CPU, i.e. last
+* policy in list. It will verify that the current freq is in
+* sync with what we believe it to be.
+   

[PATCH V3 4/6] cpufreq: exynos: Use cpufreq_generic_suspend()

[Viresh Kumar]

Currently we have implemented PM notifiers to disable/enable ->target() routines
functionality during suspend/resume.

Now we have support present in cpufreq core, lets use it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/exynos-cpufreq.c | 97 +++-
 1 file changed, 6 insertions(+), 91 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..88a4e28 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -26,10 +25,6 @@ static struct exynos_dvfs_info *exynos_info;
 
 static struct regulator *arm_regulator;
 
-static unsigned int locking_frequency;
-static bool frequency_locked;
-static DEFINE_MUTEX(cpufreq_lock);
-
 static unsigned int exynos_getspeed(unsigned int cpu)
 {
return clk_get_rate(exynos_info->cpu_clk) / 1000;
@@ -138,82 +133,12 @@ out:
 
 static int exynos_target(struct cpufreq_policy *policy, unsigned int index)
 {
-   struct cpufreq_frequency_table *freq_table = exynos_info->freq_table;
-   int ret = 0;
-
-   mutex_lock(&cpufreq_lock);
-
-   if (frequency_locked)
-   goto out;
-
-   ret = exynos_cpufreq_scale(freq_table[index].frequency);
-
-out:
-   mutex_unlock(&cpufreq_lock);
-
-   return ret;
-}
-
-#ifdef CONFIG_PM
-static int exynos_cpufreq_suspend(struct cpufreq_policy *policy)
-{
-   return 0;
-}
-
-static int exynos_cpufreq_resume(struct cpufreq_policy *policy)
-{
-   return 0;
+   return exynos_cpufreq_scale(exynos_info->freq_table[index].frequency);
 }
-#endif
-
-/**
- * exynos_cpufreq_pm_notifier - block CPUFREQ's activities in suspend-resume
- * context
- * @notifier
- * @pm_event
- * @v
- *
- * While frequency_locked == true, target() ignores every frequency but
- * locking_frequency. The locking_frequency value is the initial frequency,
- * which is set by the bootloader. In order to eliminate possible
- * inconsistency in clock values, we save and restore frequencies during
- * suspend and resume and block CPUFREQ activities. Note that the standard
- * suspend/resume cannot be used as they are too deep (syscore_ops) for
- * regulator actions.
- */
-static int exynos_cpufreq_pm_notifier(struct notifier_block *notifier,
-  unsigned long pm_event, void *v)
-{
-   int ret;
-
-   switch (pm_event) {
-   case PM_SUSPEND_PREPARE:
-   mutex_lock(&cpufreq_lock);
-   frequency_locked = true;
-   mutex_unlock(&cpufreq_lock);
-
-   ret = exynos_cpufreq_scale(locking_frequency);
-   if (ret < 0)
-   return NOTIFY_BAD;
-
-   break;
-
-   case PM_POST_SUSPEND:
-   mutex_lock(&cpufreq_lock);
-   frequency_locked = false;
-   mutex_unlock(&cpufreq_lock);
-   break;
-   }
-
-   return NOTIFY_OK;
-}
-
-static struct notifier_block exynos_cpufreq_nb = {
-   .notifier_call = exynos_cpufreq_pm_notifier,
-};
 
 static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
+   policy->suspend_freq = exynos_getspeed(policy->cpu);
return cpufreq_generic_init(policy, exynos_info->freq_table, 10);
 }
 
@@ -227,8 +152,7 @@ static struct cpufreq_driver exynos_driver = {
.name   = "exynos_cpufreq",
.attr   = cpufreq_generic_attr,
 #ifdef CONFIG_PM
-   .suspend= exynos_cpufreq_suspend,
-   .resume = exynos_cpufreq_resume,
+   .suspend= cpufreq_generic_suspend,
 #endif
 };
 
@@ -263,19 +187,10 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
 
-   locking_frequency = exynos_getspeed(0);
-
-   register_pm_notifier(&exynos_cpufreq_nb);
-
-   if (cpufreq_register_driver(&exynos_driver)) {
-   pr_err("%s: failed to register cpufreq driver\n", __func__);
-   goto err_cpufreq;
-   }
-
-   return 0;
-err_cpufreq:
-   unregister_pm_notifier(&exynos_cpufreq_nb);
+   if (!cpufreq_register_driver(&exynos_driver))
+   return 0;
 
+   pr_err("%s: failed to register cpufreq driver\n", __func__);
regulator_put(arm_regulator);
 err_vdd_arm:
kfree(exynos_info);
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH V3 6/6] cpufreq: Tegra: Use cpufreq_generic_suspend()

[Viresh Kumar]

Currently we have implemented PM notifiers to disable/enable ->target() routines
functionality during suspend/resume.

Now we have support present in cpufreq core, lets use it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/tegra-cpufreq.c | 54 +
 1 file changed, 6 insertions(+), 48 deletions(-)

diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index f42df7e..336368b 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 
 static struct cpufreq_frequency_table freq_table[] = {
{ .frequency = 216000 },
@@ -48,8 +47,6 @@ static struct clk *pll_p_clk;
 static struct clk *emc_clk;
 
 static unsigned long target_cpu_speed[NUM_CPUS];
-static DEFINE_MUTEX(tegra_cpu_lock);
-static bool is_suspended;
 
 static unsigned int tegra_getspeed(unsigned int cpu)
 {
@@ -137,50 +134,10 @@ static unsigned long tegra_cpu_highest_speed(void)
 
 static int tegra_target(struct cpufreq_policy *policy, unsigned int index)
 {
-   unsigned int freq;
-   int ret = 0;
-
-   mutex_lock(&tegra_cpu_lock);
-
-   if (is_suspended) {
-   ret = -EBUSY;
-   goto out;
-   }
-
-   freq = freq_table[index].frequency;
-
-   target_cpu_speed[policy->cpu] = freq;
-
-   ret = tegra_update_cpu_speed(policy, tegra_cpu_highest_speed());
-
-out:
-   mutex_unlock(&tegra_cpu_lock);
-   return ret;
+   target_cpu_speed[policy->cpu] = freq_table[index].frequency;
+   return tegra_update_cpu_speed(policy, tegra_cpu_highest_speed());
 }
 
-static int tegra_pm_notify(struct notifier_block *nb, unsigned long event,
-   void *dummy)
-{
-   mutex_lock(&tegra_cpu_lock);
-   if (event == PM_SUSPEND_PREPARE) {
-   struct cpufreq_policy *policy = cpufreq_cpu_get(0);
-   is_suspended = true;
-   pr_info("Tegra cpufreq suspend: setting frequency to %d kHz\n",
-   freq_table[0].frequency);
-   tegra_update_cpu_speed(policy, freq_table[0].frequency);
-   cpufreq_cpu_put(policy);
-   } else if (event == PM_POST_SUSPEND) {
-   is_suspended = false;
-   }
-   mutex_unlock(&tegra_cpu_lock);
-
-   return NOTIFY_OK;
-}
-
-static struct notifier_block tegra_cpu_pm_notifier = {
-   .notifier_call = tegra_pm_notify,
-};
-
 static int tegra_cpu_init(struct cpufreq_policy *policy)
 {
int ret;
@@ -192,6 +149,7 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
clk_prepare_enable(cpu_clk);
 
target_cpu_speed[policy->cpu] = tegra_getspeed(policy->cpu);
+   policy->suspend_freq = freq_table[0].frequency;
 
/* FIXME: what's the actual transition time? */
ret = cpufreq_generic_init(policy, freq_table, 300 * 1000);
@@ -201,9 +159,6 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
return ret;
}
 
-   if (policy->cpu == 0)
-   register_pm_notifier(&tegra_cpu_pm_notifier);
-
return 0;
 }
 
@@ -223,6 +178,9 @@ static struct cpufreq_driver tegra_cpufreq_driver = {
.exit   = tegra_cpu_exit,
.name   = "tegra",
.attr   = cpufreq_generic_attr,
+#ifdef CONFIG_PM
+   .suspend= cpufreq_generic_suspend,
+#endif
 };
 
 static int __init tegra_cpufreq_init(void)
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate

[Viresh Kumar]

This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and late
resume of governors and cpufreq core.

There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His 
board
  wasn't working well with suspend/resume as calls for removing non-boot CPUs
  was turning out into a call to drivers ->target() which then tries to play
  with regulators. But regulators and their I2C bus were already suspended and
  this resulted in a failure. Many platforms have such problems, samsung, tegra,
  etc.. They solved it with driver specific PM notifiers where they used to
  disable their driver's ->target() routine.
- Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
  tunables configuration for clusters/sockets with non-boot CPUs was getting
  lost after suspend/resume, as we were notifying governors with
  CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
  deallocating memory for tunables. This is also fixed with this patch as don't
  allow any operation on Governors during suspend/resume now.

Reported-by: Lan Tianyu 
Reported-by: Nishanth Menon 
Reported-by: Jinhyuk Choi 
Signed-off-by: Viresh Kumar 
---
 drivers/base/power/main.c |  5 +
 drivers/cpufreq/cpufreq.c | 50 +++
 include/linux/cpufreq.h   |  3 +++
 3 files changed, 58 insertions(+)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..c9fbb9d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -789,6 +790,8 @@ void dpm_resume(pm_message_t state)
mutex_unlock(&dpm_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, NULL);
+
+   cpufreq_resume();
 }
 
 /**
@@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
 
might_sleep();
 
+   cpufreq_suspend();
+
mutex_lock(&dpm_list_mtx);
pm_transition = state;
async_error = 0;
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..b6c7821 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +48,9 @@ static LIST_HEAD(cpufreq_policy_list);
 static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
 #endif
 
+/* Flag to suspend/resume CPUFreq governors */
+static bool cpufreq_suspended;
+
 static inline bool has_target(void)
 {
return cpufreq_driver->target_index || cpufreq_driver->target;
@@ -1462,6 +1466,48 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
 };
 
+/*
+ * Callbacks for suspending/resuming governors as some platforms can't change
+ * frequency after this point in suspend cycle. Because some of the devices
+ * (like: i2c, regulators, etc) they use for changing frequency are suspended
+ * quickly after this point.
+ */
+void cpufreq_suspend(void)
+{
+   struct cpufreq_policy *policy;
+
+   if (!has_target())
+   return;
+
+   pr_debug("%s: Suspending Governors\n", __func__);
+
+   list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+   if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
+   pr_err("%s: Failed to stop governor for policy: %p\n",
+   __func__, policy);
+
+   cpufreq_suspended = true;
+}
+
+void cpufreq_resume(void)
+{
+   struct cpufreq_policy *policy;
+
+   if (!has_target())
+   return;
+
+   pr_debug("%s: Resuming Governors\n", __func__);
+
+   cpufreq_suspended = false;
+
+   list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+   if (__cpufreq_governor(policy, CPUFREQ_GOV_START) ||
+   __cpufreq_governor(policy,
+   CPUFREQ_GOV_LIMITS))
+   pr_err("%s: Failed to start governor for policy: %p\n",
+   __func__, policy);
+}
+
 /**
  * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
  *
@@ -1764,6 +1810,10 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
struct cpufreq_governor *gov = NULL;
 #endif
 
+   /* Don't start any governor operations if we are entering suspend */
+   if (cpufreq_suspended)
+   return 0;
+
if (policy->governor->max_transition_latency &&
policy->cpuinfo.transition_latency >
policy->governor->max_transition_latency) {
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index dc196bb..6d93f91 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -255,6 +255,9 @@ struct cpufreq_driver {
 int

[PATCH V3 3/6] cpufreq: Implement cpufreq_generic_suspend()

[Viresh Kumar]

Multiple platforms need to set CPU to a particular frequency before suspending
system. And so they need a common infrastructure which is provided by this
patch. Those platforms just need to initialize their ->suspend() pointers with
the generic routine.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 25 +
 include/linux/cpufreq.h   |  3 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 026efe4a..f6da551 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1466,6 +1466,31 @@ static struct subsys_interface cpufreq_interface = {
 };
 
 /*
+ * In case platform wants some specific frequency to be configured
+ * during suspend..
+ */
+int cpufreq_generic_suspend(struct cpufreq_policy *policy)
+{
+   int ret;
+
+   if (!policy->suspend_freq) {
+   pr_err("%s: suspend_freq can't be zero\n", __func__);
+   return -EINVAL;
+   }
+
+   pr_debug("%s: Setting suspend-freq: %u\n", __func__,
+   policy->suspend_freq);
+
+   ret = __cpufreq_driver_target(policy, policy->suspend_freq,
+   CPUFREQ_RELATION_H);
+   if (ret)
+   pr_err("%s: unable to set suspend-freq: %u. err: %d\n",
+   __func__, policy->suspend_freq, ret);
+
+   return ret;
+}
+
+/*
  * Callbacks for suspending/resuming governors as some platforms can't change
  * frequency after this point in suspend cycle. Because some of the devices
  * (like: i2c, regulators, etc) they use for changing frequency are suspended
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 6d93f91..94ccac5 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -72,6 +72,8 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
 * governors are used */
+   unsigned intsuspend_freq; /* freq to set during suspend */
+
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
@@ -257,6 +259,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver 
*driver_data);
 
 void cpufreq_suspend(void);
 void cpufreq_resume(void);
+int cpufreq_generic_suspend(struct cpufreq_policy *policy);
 
 const char *cpufreq_get_current_driver(void);
 
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 2/2] cpufreq: exynos: Frequency lock should be considered in hibernation also.

[Jonghwan Choi]

The Frequency lock value should be higher or same than the booting frequency,
which is set by the bootloader. To eliminate possible inconsistency
in frequency, we save and restore frequency during suspend & resume
and disable CPUFREQ activity. This should be considered in hibernation also.

Signed-off-by: Jonghwan Choi 
---
 drivers/cpufreq/exynos-cpufreq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block 
*notifier,
int ret;
 
switch (pm_event) {
+   case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(&cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block 
*notifier,
 
break;
 
+   case PM_POST_HIBERNATION:
+   case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(&cpufreq_lock);
frequency_locked = false;
-- 
1.8.1.2

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

Re: linux 3.13-rc1 make dw_mmc-exynos more worse

[randy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

于 2013年11月25日 16:33, Seungwon Jeon 写道:
> On Mon, November 25, 2013, Olof Johansson wrote:
>> Hi,
>> 
>> On Sun, Nov 24, 2013 at 4:07 AM, randy  
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> After pull the merge of 3.13-rc1, the dw_mmc-exynos will make 
>>> the boot stock.In 3.13, it is just stocked udev in 3.13 and 
>>> makse udev timeout but kernel report the emmc device is found.
>>> 
>>> And in the 
>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw 
>>> that it is need to define which gpio ports that a emmc slot 
>>> use, but when I watched others dts, they use pinctrl, which is 
>>> correct? Here is the log and dts
>> 
>> [..]
>> 
>>> ===log begin =
>> [..]
>>> [0.00] CPU EXYNOS4412 (id 0xe4412011)
>> 
>> [..]
>> 
>>> [1.095000] mmc0: no vmmc regulator found [1.13] 
>>> mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using 
>>> ADMA [1.13] Synopsys Designware Multimedia Card 
>>> Interface Driver [1.13] Unable to handle kernel NULL 
>>> pointer dereference at virtual address 002a [1.13] 
>>> pgd = c0004000 [1.13] [002a] *pgd= [ 
>>> 1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 
>>> 1.14] Modules linked in: [1.14] CPU: 0 PID: 1
>>> Comm: swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3
>>> [ 1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [ 
>>> 1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is 
>>> at clk_prepare_lock+0xc/0xd8 [1.165000] pc : [] 
>>> lr : []psr: a113 [1.165000] sp :
>>> ef0a9e20 ip : ee94eb40  fp :  [1.175000] r10:
>>> c0571510  r9 : ef0a8000  r8 : ef227a10 [1.18] r7 :
>>> c043544c  r6 : fffe  r5 : ee94ead0  r4 : fffe [
>>> 1.185000] r3 : ef0a4000  r2 : 0001  r1 : 02b9  r0 :
>>> 0001 [ 1.195000] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32
>>> ISA ARM Segment kernel [1.20] Control: 10c5387d
>>> Table: 4000404a  DAC: 0015 [1.205000] Process swapper/0
>>> (pid: 1, stack limit = 0xef0a8240) [1.21] Stack:
>>> (0xef0a9e20 to 0xef0aa000) [1.215000] 9e20: c0308474
>>> ee9ea610 ee94ead0 c0308488 c0308474 ee9ea610  c030592c
>>> [1.225000] 9e40: ef227a10 1000 c043544c c020a920
>>> c0838b04 17d78400 ee9ea610 ef227a00 [1.235000] 9e60:
>>> ef227a10 c05d6b1c  c05d6b1c c05890b0 ef0a8000 c0571510
>>> c0269448 [ 1.24] 9e80: c0269430 ef227a10 c061291c c0268088
>>>  ef227a10 c05d6b1c ef227a44 [1.25] 9ea0:
>>>  c026822c  c05d6b1c c02681a0 c02668a8 ef005478
>>> ef212740 [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438
>>> c0267864 c0511e38 c05d6b1c 0006 c05d6b1c [1.265000]
>>> 9ee0: 0006 c059575c c05df580 c026884c  c05a2e14
>>> 0006 c00088dc [1.275000] 9f00: c0603f70 ef163e00
>>> c040e334 6113 c05b5000 a113 c05b5054 c05b5050 [
>>> 1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
>>> c0035158 c05b5054 c05a2a20 [1.29] 9f40: c050ae2c
>>> c054a438 0006 0006  c05a2e14 0006 c059575c
>>> [ 1.30] 9f60: c05df580 0093 c0595768 c0571510 
>>>  c0571c48 0006 0006 [1.305000] 9f80: c0571510 
>>> c003df68  c0403544    
>>>  [1.315000] 9fa0:  c040354c  c000e738 
>>>     [1.32] 9fc0: 
>>>        
>>>  [1.33] 9fe0:    
>>>  0013  be73efa4 bffd [1.34] 
>>> [] (clk_get_rate+0x18/0x5c) from [] 
>>> (dw_mci_exynos_setup_clock+0x14/0x2c) [1.35] 
>>> [] (dw_mci_exynos_setup_clock+0x14/0x2c) from 
>>> [] (dw_mci_probe+0x15c/0xca4) [1.36] 
>>> [] (dw_mci_probe+0x15c/0xca4) from [] 
>>> (platform_drv_probe+0x18/0x48) [1.365000] [] 
>>> (platform_drv_probe+0x18/0x48) from [] 
>>> (driver_probe_device+0x100/0x218) [1.375000] [] 
>>> (driver_probe_device+0x100/0x218) from [] 
>>> (__driver_attach+0x8c/0x90) [1.385000] [] 
>>> (__driver_attach+0x8c/0x90) from [] 
>>> (bus_for_each_dev+0x54/0x88) [1.395000] [] 
>>> (bus_for_each_dev+0x54/0x88) from [] 
>>> (bus_add_driver+0xd4/0x1d0) [1.405000] [] 
>>> (bus_add_driver+0xd4/0x1d0) from [] 
>>> (driver_register+0x78/0xf4) [1.415000] [] 
>>> (driver_register+0x78/0xf4) from [] 
>>> (do_one_initcall+0xec/0x148) [1.42] [] 
>>> (do_one_initcall+0xec/0x148) from [] 
>>> (kernel_init_freeable+0xfc/0x1c8) [1.43] [] 
>>> (kernel_init_freeable+0xfc/0x1c8) from [] 
>>> (kernel_init+0x8/0x110) [1.44] [] 
>>> (kernel_init+0x8/0x110) from [] 
>>> (ret_from_fork+0x14/0x3c) [1.45] Code: ebfffd18 
>>> e354 01a05004 0a08 (e594302c)
>> 
>> 
>> Looks like a clock issue on 4412? I only have 5250 that I 

[PATCH 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default

[Mark Brown]

From: Mark Brown 

Rather than requiring each board to explicitly disable the SPI controllers
it is not using instead require boards to enable those that they are using.
This is less work overall since normally at most one of the controllers is
in use and avoids issues caused by inappropriate pinmuxing.

Signed-off-by: Mark Brown 
Acked-by: Tomasz Figa 
---
 arch/arm/boot/dts/cros5250-common.dtsi|  9 +
 arch/arm/boot/dts/exynos5250-arndale.dts  | 12 
 arch/arm/boot/dts/exynos5250-smdk5250.dts |  6 ++
 arch/arm/boot/dts/exynos5250.dtsi |  3 +++
 4 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b8a73..0fcca2930c61 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -286,19 +286,12 @@
};
};
 
-   spi_0: spi@12d2 {
-   status = "disabled";
-   };
-
spi_1: spi@12d3 {
+   status = "okay";
samsung,spi-src-clk = <0>;
num-cs = <1>;
};
 
-   spi_2: spi@12d4 {
-   status = "disabled";
-   };
-
hdmi {
hpd-gpio = <&gpx3 7 0>;
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 684527087aa4..0385b58116ec 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -434,18 +434,6 @@
status = "okay";
};
 
-   spi_0: spi@12d2 {
-   status = "disabled";
-   };
-
-   spi_1: spi@12d3 {
-   status = "disabled";
-   };
-
-   spi_2: spi@12d4 {
-   status = "disabled";
-   };
-
gpio_keys {
compatible = "gpio-keys";
 
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index f86d56760a45..5d0395e07eee 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -189,6 +189,8 @@
};
 
spi_1: spi@12d3 {
+   status = "okay";
+
w25q80bw@0 {
#address-cells = <1>;
#size-cells = <1>;
@@ -214,10 +216,6 @@
};
};
 
-   spi_2: spi@12d4 {
-   status = "disabled";
-   };
-
hdmi {
hpd-gpio = <&gpx3 7 0>;
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 9db5047812f3..9b58532854e1 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -349,6 +349,7 @@
 
spi_0: spi@12d2 {
compatible = "samsung,exynos4210-spi";
+   status = "disabled";
reg = <0x12d2 0x100>;
interrupts = <0 66 0>;
dmas = <&pdma0 5
@@ -364,6 +365,7 @@
 
spi_1: spi@12d3 {
compatible = "samsung,exynos4210-spi";
+   status = "disabled";
reg = <0x12d3 0x100>;
interrupts = <0 67 0>;
dmas = <&pdma1 5
@@ -379,6 +381,7 @@
 
spi_2: spi@12d4 {
compatible = "samsung,exynos4210-spi";
+   status = "disabled";
reg = <0x12d4 0x100>;
interrupts = <0 68 0>;
dmas = <&pdma0 7
-- 
1.8.4.4

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

[PATCH 3/3] ARM: dts: Rename Exynos5250 ChromeOS common file to have exynos prefix

[Mark Brown]

From: Mark Brown 

Make it easier to notice the common file for ChromeOS devices based on
the Exynos5250 by giving it the exynos5250 prefix that the boards have.

Signed-off-by: Mark Brown 
Acked-by: Tomasz Figa 
---
 arch/arm/boot/dts/{cros5250-common.dtsi => exynos5250-cros-common.dtsi} | 0
 arch/arm/boot/dts/exynos5250-snow.dts   | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/arm/boot/dts/{cros5250-common.dtsi => exynos5250-cros-common.dtsi} 
(100%)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/cros5250-common.dtsi
rename to arch/arm/boot/dts/exynos5250-cros-common.dtsi
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e245e8d..7e2669c6f7f5 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -10,7 +10,7 @@
 
 /dts-v1/;
 #include "exynos5250.dtsi"
-#include "cros5250-common.dtsi"
+#include "exynos5250-cros-common.dtsi"
 
 / {
model = "Google Snow";
-- 
1.8.4.4

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

[PATCH 2/3] ARM: dts: Disable I2C controllers by default on Exynos5250

[Mark Brown]

From: Mark Brown 

Ensure that unused I2C controllers are not activated, causing problems due
to inappropriate pinmuxing or similar, by marking the controllers as
disabled by default and requiring boards to explicitly enable those that
are in use.

Signed-off-by: Mark Brown 
Acked-by: Tomasz Figa 
---
 arch/arm/boot/dts/cros5250-common.dtsi| 12 
 arch/arm/boot/dts/exynos5250-arndale.dts  | 32 ---
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 25 +---
 arch/arm/boot/dts/exynos5250.dtsi | 10 ++
 4 files changed, 31 insertions(+), 48 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 0fcca2930c61..7dbba0859a1d 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -30,6 +30,7 @@
};
 
i2c@12C6 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
 
@@ -173,6 +174,7 @@
};
 
i2c@12C7 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
 
@@ -186,6 +188,7 @@
};
 
i2c@12C8 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
 
@@ -196,30 +199,31 @@
};
 
i2c@12C9 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
};
 
i2c@12CA {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
};
 
i2c@12CB {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
};
 
-   i2c@12CC {
-   status = "disabled";
-   };
-
i2c@12CD {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
};
 
i2c@12CE {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
 
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 0385b58116ec..6fbe89fd7d41 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -34,6 +34,7 @@
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
samsung,i2c-slave-addr = <0x66>;
+   status = "okay";
 
s5m8767_pmic@66 {
compatible = "samsung,s5m8767-pmic";
@@ -319,11 +320,9 @@
};
};
 
-   i2c@12C7 {
-   status = "disabled";
-   };
-
i2c@12C8 {
+   status = "okay";
+
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
samsung,i2c-slave-addr = <0x50>;
@@ -335,7 +334,10 @@
};
 
i2c@12C9 {
+   status = "okay";
+
wm1811a@1a {
+
compatible = "wlf,wm1811";
reg = <0x1a>;
 
@@ -353,23 +355,9 @@
};
};
 
-   i2c@12CA {
-   status = "disabled";
-   };
-
-   i2c@12CB {
-   status = "disabled";
-   };
-
-   i2c@12CC {
-   status = "disabled";
-   };
-
-   i2c@12CD {
-   status = "disabled";
-   };
-
i2c@12CE {
+   status = "okay";
+
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
samsung,i2c-slave-addr = <0x38>;
@@ -380,10 +368,6 @@
};
};
 
-   i2c@121D {
-   status = "disabled";
-   };
-
dwmmc_0: dwmmc0@1220 {
num-slots = <1>;
supports-highspeed;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 5d0395e07eee..a17b1a0a8abc 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -30,6 +30,7 @@
i2c@12C6 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
+   status = "okay";
 
eeprom@50 {
compatible = "samsung,s524ad0xd1";
@@ -64,6 +65,7 @@
i2c@12C7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
+   status = "okay";
 
eeprom@51 {
compatible = "samsung,s524ad0xd1";
@@ -89,6 +91,7 @@
 

Вы можете располагать орлиным зрением

[tre-anton]

Мы отвоевываем людям зрение http://goo.gl/2m4NKq

[PATCH v8] videobuf2: Add missing lock held on vb2_fop_relase

[Ricardo Ribalda Delgado]

From: Ricardo Ribalda 

vb2_fop_release does not held the lock although it is modifying the
queue->owner field.

This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:

[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops:  #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[] []
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX:  RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX:  RSI: dead00200200 RDI: 
[ 308.298012] RBP: 88014dc03e58 R08:  R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS:  ES:  CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000 
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [] v4l2_read+0x7e/0xc0
[ 308.298296] [] vfs_read+0xa9/0x160
[ 308.298312] [] SyS_read+0x52/0xb0
[ 308.298328] [] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
---

v2: Comments by Sylvester Nawrocki

fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.

v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab

Use vb2_fop_release_locked instead of __vb2_fop_release

v4: Comments by Sylvester Nawrocki

Rename vb2_fop_release_locked to __vb2_fop_release and fix patch format

v5: Comments by Sylvester Nawrocki and Hans Verkuil

Rename __vb2_fop_release to vb2_fop_release_unlock and rearrange
arguments

v6: Comments by Hans Verkuil

Fix typo on description
Rename vb2_fop_release_locked to vb2_fop_release_no_lock

v7: Comments by Hans Verkuil and Sylvester Nawrocki

Export _vb2_fop_release instead of using vb2_fop_release_no_lock

v8: Comments by Hans Verkuil and rebase

Missed semicolon

Signed-off-by: Ricardo Ribalda 
Acked-by: Hans Verkuil 
Acked-by: Sylwester Nawrocki 
 drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c|  2 +-
 drivers/media/v4l2-core/videobuf2-core.c | 15 ++-
 include/media/videobuf2-core.h   |  1 +
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..8a712ca 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc->streaming = false;
}
 
-   ret = vb2_fop_release(file);
+   ret = _vb2_fop_release(file, NULL);
 
if (close) {
clear_bit(ST_CAPT_BUSY, &fimc->state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..d3b32b6 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(&entity->parent->graph_mutex);
}
 
-   vb2_fop_release(file);
+   _vb2_fop_release(file, NULL);
pm_runtime_put(&fimc->pdev->dev);
clear_bit(ST_FLITE_SUSPE

RE: linux 3.13-rc1 make dw_mmc-exynos more worse

[Seungwon Jeon]

On Mon, November 25, 2013, Olof Johansson wrote:
> Hi,
> 
> On Sun, Nov 24, 2013 at 4:07 AM, randy  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > After pull the merge of 3.13-rc1, the dw_mmc-exynos will make the boot
> > stock.In 3.13, it is just stocked udev in 3.13 and makse udev timeout
> > but kernel report the emmc device is found.
> >
> > And in the Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I
> > saw that it is need to define which gpio ports that a emmc slot use,
> > but when I watched others dts, they use pinctrl, which is correct?
> > Here is the log and dts
> 
> [..]
> 
> > ===log begin =
> [..]
> > [0.00] CPU EXYNOS4412 (id 0xe4412011)
> 
> [..]
> 
> > [1.095000] mmc0: no vmmc regulator found
> > [1.13] mmc0: SDHCI controller on samsung-hsmmc
> > [1253.sdhci] using ADMA
> > [1.13] Synopsys Designware Multimedia Card Interface Driver
> > [1.13] Unable to handle kernel NULL pointer dereference at
> > virtual address 002a
> > [1.13] pgd = c0004000
> > [1.13] [002a] *pgd=
> > [1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > [1.14] Modules linked in:
> > [1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > 3.13.0-rc1-8-g584fa45-dirty #3
> > [1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000
> > [1.155000] PC is at clk_get_rate+0x18/0x5c
> > [1.16] LR is at clk_prepare_lock+0xc/0xd8
> > [1.165000] pc : []lr : []psr: a113
> > [1.165000] sp : ef0a9e20  ip : ee94eb40  fp : 
> > [1.175000] r10: c0571510  r9 : ef0a8000  r8 : ef227a10
> > [1.18] r7 : c043544c  r6 : fffe  r5 : ee94ead0  r4 : fffe
> > [1.185000] r3 : ef0a4000  r2 : 0001  r1 : 02b9  r0 : 0001
> > [1.195000] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> > Segment kernel
> > [1.20] Control: 10c5387d  Table: 4000404a  DAC: 0015
> > [1.205000] Process swapper/0 (pid: 1, stack limit = 0xef0a8240)
> > [1.21] Stack: (0xef0a9e20 to 0xef0aa000)
> > [1.215000] 9e20: c0308474 ee9ea610 ee94ead0 c0308488 c0308474
> > ee9ea610  c030592c
> > [1.225000] 9e40: ef227a10 1000 c043544c c020a920 c0838b04
> > 17d78400 ee9ea610 ef227a00
> > [1.235000] 9e60: ef227a10 c05d6b1c  c05d6b1c c05890b0
> > ef0a8000 c0571510 c0269448
> > [1.24] 9e80: c0269430 ef227a10 c061291c c0268088 
> > ef227a10 c05d6b1c ef227a44
> > [1.25] 9ea0:  c026822c  c05d6b1c c02681a0
> > c02668a8 ef005478 ef212740
> > [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864 c0511e38
> > c05d6b1c 0006 c05d6b1c
> > [1.265000] 9ee0: 0006 c059575c c05df580 c026884c 
> > c05a2e14 0006 c00088dc
> > [1.275000] 9f00: c0603f70 ef163e00 c040e334 6113 c05b5000
> > a113 c05b5054 c05b5050
> > [1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
> > c0035158 c05b5054 c05a2a20
> > [1.29] 9f40: c050ae2c c054a438 0006 0006 
> > c05a2e14 0006 c059575c
> > [1.30] 9f60: c05df580 0093 c0595768 c0571510 
> > c0571c48 0006 0006
> > [1.305000] 9f80: c0571510 c003df68  c0403544 
> >   
> > [1.315000] 9fa0:  c040354c  c000e738 
> >   
> > [1.32] 9fc0:     
> >   
> > [1.33] 9fe0:     0013
> >  be73efa4 bffd
> > [1.34] [] (clk_get_rate+0x18/0x5c) from []
> > (dw_mci_exynos_setup_clock+0x14/0x2c)
> > [1.35] [] (dw_mci_exynos_setup_clock+0x14/0x2c) from
> > [] (dw_mci_probe+0x15c/0xca4)
> > [1.36] [] (dw_mci_probe+0x15c/0xca4) from
> > [] (platform_drv_probe+0x18/0x48)
> > [1.365000] [] (platform_drv_probe+0x18/0x48) from
> > [] (driver_probe_device+0x100/0x218)
> > [1.375000] [] (driver_probe_device+0x100/0x218) from
> > [] (__driver_attach+0x8c/0x90)
> > [1.385000] [] (__driver_attach+0x8c/0x90) from
> > [] (bus_for_each_dev+0x54/0x88)
> > [1.395000] [] (bus_for_each_dev+0x54/0x88) from
> > [] (bus_add_driver+0xd4/0x1d0)
> > [1.405000] [] (bus_add_driver+0xd4/0x1d0) from
> > [] (driver_register+0x78/0xf4)
> > [1.415000] [] (driver_register+0x78/0xf4) from
> > [] (do_one_initcall+0xec/0x148)
> > [1.42] [] (do_one_initcall+0xec/0x148) from
> > [] (kernel_init_freeable+0xfc/0x1c8)
> > [1.43] [] (kernel_init_freeable+0xfc/0x1c8) from
> > [] (kernel_init+0x8/0x110)
> > [1.44] [] (kernel_init+0x8/0x110) from []
> > (ret_from_fork+0x14/0x3c)
> > [1.45] Code: ebfffd18 e354 01a05004 0a08 (e594302c)
> 
> 
> Looks like a clock issue on 4412? I only have 5250 that I boot test
> on, no EXYNOS4 coverage at all (I had an Odroid-X but it wasn't useful