Re: [PATCH 2/2] ARM: exynos_defconfig: Enable s5p-secss driver
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > The Exynos SoC provides a Security SubSystem block for accelerating some > cryptographic operations. Enable the driver for it - s5p-secss to > utilize the hardware acceleration. > > Currently the s5p-secss driver supports AES in CBC and ECB modes. > However on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412) boards this > change introduces one booting error: > > alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: > ret=22 > > The cbc-aes-s5p properly registers itself and passes self-tests. > > Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> > --- > arch/arm/configs/exynos_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 0aee1e035be9..c47c7e069873 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -240,6 +240,7 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > +CONFIG_CRYPTO_DEV_S5P=y > CONFIG_ARM_CRYPTO=y > CONFIG_CRYPTO_SHA1_ARM_NEON=m > CONFIG_CRYPTO_SHA256_ARM=m > -- > 1.9.1 > Reviewed-by: Anand Moon <linux.am...@gmail.com> Best Regards, -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > Enable the kernel NEON mode and asm/NEON accelerated crypto algorithms > which should bring performance benefits on Exynos SoCs. Enable these as > modules because they are optional, not essential anyhow for platform > booting nor related directly to Exynos Soc. All accelerated algorithms > pass booting self-tests on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412). > > Additionally enable cpufreq statistics as they are useful for debugging. > > Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> > --- > arch/arm/configs/exynos_defconfig | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 24dcd2bb1215..0aee1e035be9 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -26,12 +26,14 @@ CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M > console=ttySAC1,115200 init=/linuxrc mem=256M" > CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_STAT_DETAILS=y > CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > CONFIG_CPUFREQ_DT=y > CONFIG_CPU_IDLE=y > CONFIG_ARM_EXYNOS_CPUIDLE=y > CONFIG_VFP=y > CONFIG_NEON=y > +CONFIG_KERNEL_MODE_NEON=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > @@ -238,7 +240,11 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > -CONFIG_CRYPTO_SHA256=y > +CONFIG_ARM_CRYPTO=y > +CONFIG_CRYPTO_SHA1_ARM_NEON=m > +CONFIG_CRYPTO_SHA256_ARM=m > +CONFIG_CRYPTO_SHA512_ARM=m > +CONFIG_CRYPTO_AES_ARM_BS=m > CONFIG_CRC_CCITT=y > CONFIG_FONTS=y > CONFIG_FONT_7x14=y > -- > 1.9.1 > Reviewed-by: Anand Moon <linux.am...@gmail.com> Best Regards, -Anand Moon -- 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] power: genpd: fix lockdep issue for all subdomains
Hi Marek,
On 4 January 2016 at 16:09, Marek Szyprowski <m.szyprow...@samsung.com> wrote:
> During genpd_poweron, genpd->lock is acquired recursively for each
> parent (master) domain, which are separate obejcts. This confuses
> lockdep, which considers every operation on genpd->lock as being done on
> the same lock class. This leads to the following false positive warning:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.4.0-rc4-xu3s #32 Not tainted
> -
> swapper/0/1 is trying to acquire lock:
> (>lock){+.+...}, at: [] __genpd_poweron+0x64/0x108
>
> but task is already holding lock:
> (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(>lock);
> lock(>lock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by swapper/0/1:
> #0: (>mutex){..}, at: [] __driver_attach+0x48/0x98
> #1: (>mutex){..}, at: [] __driver_attach+0x58/0x98
> #2: (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> stack backtrace:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0xc4)
> [] (dump_stack) from [] (__lock_acquire+0x1f88/0x215c)
> [] (__lock_acquire) from [] (lock_acquire+0xa4/0xd0)
> [] (lock_acquire) from [] (mutex_lock_nested+0x70/0x4d4)
> [] (mutex_lock_nested) from []
> (__genpd_poweron+0x64/0x108)
> [] (__genpd_poweron) from []
> (genpd_dev_pm_attach+0x170/0x1b8)
> [] (genpd_dev_pm_attach) from []
> (platform_drv_probe+0x2c/0xac)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x208/0x2fc)
> [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from []
> (exynos_drm_register_drivers+0x28/0x74)
> [] (exynos_drm_register_drivers) from []
> (exynos_drm_init+0x6c/0xc4)
> [] (exynos_drm_init) from [] (do_one_initcall+0x90/0x1dc)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x158/0x1f8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
>
> This patch replaces mutex_lock with mutex_lock_nested() and uses
> recursion depth to annotate each genpd->lock operation with separate
> lockdep subclass.
>
> Reported-by: Anand Moon <linux.am...@gmail.com>
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> ---
> drivers/base/power/domain.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index b803790..e02ddf6 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -170,16 +170,15 @@ static void genpd_queue_power_off_work(struct
> generic_pm_domain *genpd)
> queue_work(pm_wq, >power_off_work);
> }
>
> -static int genpd_poweron(struct generic_pm_domain *genpd);
> -
> /**
> * __genpd_poweron - Restore power to a given PM domain and its masters.
> * @genpd: PM domain to power up.
> + * @depth: nesting count for lockdep.
> *
> * Restore power to @genpd and all of its masters so that it is possible to
> * resume a device belonging to it.
> */
> -static int __genpd_poweron(struct generic_pm_domain *genpd)
> +static int __genpd_poweron(struct generic_pm_domain *genpd, unsigned int
> depth)
> {
> struct gpd_link *link;
> int ret = 0;
> @@ -194,11 +193,16 @@ static int __genpd_poweron(struct generic_pm_domain
> *genpd)
> * with it.
> */
> list_for_each_entry(link, >slave_links, slave_node) {
> - genpd_sd_counter_inc(link->master);
> + struct generic_pm_domain *master = link->master;
> +
> + genpd_sd_counter_inc(master);
> +
> + mutex_lock_nested(>lock, depth + 1);
> + ret = __genpd_poweron(master, depth + 1);
> + mutex_unlock(>lock);
>
> - ret = genpd_poweron(link->master);
> if (ret) {
> - genpd_sd_counter_dec(link->master);
> + genpd_sd_counter_dec(master);
> goto err;
> }
>
Re: Odroid U3 mutex deadlock.
Hi Krzysztof
On 14 December 2015 at 05:15, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.12.2015 13:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>
> This is not a deadlock yet, just a report from lockdep. Could be a real
> issue, could be false positive, maybe some locks miss nesting annotations.
>
> Typical information for bug report would be useful, like the exact
> version (it is mentioned in lockdep report but is it really correct?)
> and reproducibility. And of course git-bisect would be nice to have, see:
> Documentation/BUG-HUNTING
>
> Best regards,
> Krzysztof
>
>
Thanks for your inputs. I narrowed down to this commit.
--
commit ec459c0c77faca53cf161830cb264e51bb1abba6
Author: Marek Szyprowski <m.szyprow...@samsung.com>
Date: Wed Feb 4 23:44:15 2015 +0900
ARM: dts: add dependency between TV and LCD0 power domains for exynos4
TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
This dependency is modelled by making TV power domains a sub-domain of
LCD0 power domain.
Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
Signed-off-by: Kukjin Kim <kg...@kernel.org>
-
After reverting this I am not observing below lockdep warning report.
But after reverting this patch I observer another bug.
Best regards.
-Anand Moon
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [
Re: Odroid U3 mutex deadlock.
Hi Thomas,
On 12 December 2015 at 16:58, Thomas Pietrowski <thopie...@gmail.com> wrote:
> I'm also using 4.4.0-rc4 here on my U3+. And so far it is working well. I
> just had a freeze yesterday, but I didn't had the UART connected, so
> couldn't catch the reason. The curious thing was that the heartbeat LED was
> still blinking, but USB keyboard and Ethernet/SSH (but LEDs still on) were
> not working.
>
> Could you upload your .config? Maybe it could be useful for others :)
>
> Regards
>
> Am 12.12.2015 05:33 schrieb "Anand Moon" <linux.am...@gmail.com>:
>>
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>>
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s
>> #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [3.201396] [] (kernel_init_freeable) from []
>> (kernel_init+0x8/0xe8)
>> [3.209469] [] (kernel_init) from []
>> (ret_from_fork+0x14/0x24)
>> [3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
>> [3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO
>> lookup
>> [3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
>> property of node '/hdmi@12D0[0]'
>> [3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
>> node '/hdmi@12D0[0]' - status (0)
>> [3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
>> mixer_component_ops)
>> [3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
>> hdmi_component_ops)
>> [3.263245] [drm] Supports vblank timestamp cachi
Odroid U3 mutex deadlock.
Hi Krzysztof,
I am just observing this deadlock om my Odroid U3.
--
[2.937531] =
[2.938733] [ INFO: possible recursive locking detected ]
[2.944117] 4.4.0-rc4-xu3s #32 Not tainted
[2.948195] -
[2.953577] swapper/0/1 is trying to acquire lock:
[2.958351] (>lock){+.+...}, at: []
__genpd_poweron+0x64/0x108
[2.965727]
[2.965727] but task is already holding lock:
[2.971543] (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[2.979355]
[2.979355] other info that might help us debug this:
[2.985865] Possible unsafe locking scenario:
[2.985865]
[2.991768]CPU0
[2.994198]
[2.996628] lock(>lock);
[2.26] lock(>lock);
[3.003225]
[3.003225] *** DEADLOCK ***
[3.003225]
[3.009128] May be due to missing lock nesting notation
[3.009128]
[3.015900] 3 locks held by swapper/0/1:
[3.019804] #0: (>mutex){..}, at: []
__driver_attach+0x48/0x98
[3.027442] #1: (>mutex){..}, at: []
__driver_attach+0x58/0x98
[3.035081] #2: (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[3.043326]
[3.043326] stack backtrace:
[3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
[3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.060444] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.068163] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[3.075367] [] (dump_stack) from []
(__lock_acquire+0x1f88/0x215c)
[3.083262] [] (__lock_acquire) from []
(lock_acquire+0xa4/0xd0)
[3.090990] [] (lock_acquire) from []
(mutex_lock_nested+0x70/0x4d4)
[3.099061] [] (mutex_lock_nested) from []
(__genpd_poweron+0x64/0x108)
[3.107393] [] (__genpd_poweron) from []
(genpd_dev_pm_attach+0x170/0x1b8)
[3.115986] [] (genpd_dev_pm_attach) from []
(platform_drv_probe+0x2c/0xac)
[3.124667] [] (platform_drv_probe) from []
(driver_probe_device+0x208/0x2fc)
[3.133519] [] (driver_probe_device) from []
(__driver_attach+0x94/0x98)
[3.141939] [] (__driver_attach) from []
(bus_for_each_dev+0x68/0x9c)
[3.150097] [] (bus_for_each_dev) from []
(bus_add_driver+0x1a0/0x218)
[3.158344] [] (bus_add_driver) from []
(driver_register+0x78/0xf8)
[3.166330] [] (driver_register) from []
(exynos_drm_register_drivers+0x28/0x74)
[3.175441] [] (exynos_drm_register_drivers) from
[] (exynos_drm_init+0x6c/0xc4)
[3.184556] [] (exynos_drm_init) from []
(do_one_initcall+0x90/0x1dc)
[3.192718] [] (do_one_initcall) from []
(kernel_init_freeable+0x158/0x1f8)
[3.201396] [] (kernel_init_freeable) from []
(kernel_init+0x8/0xe8)
[3.209469] [] (kernel_init) from []
(ret_from_fork+0x14/0x24)
[3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
[3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO lookup
[3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
property of node '/hdmi@12D0[0]'
[3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
node '/hdmi@12D0[0]' - status (0)
[3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
mixer_component_ops)
[3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
hdmi_component_ops)
[3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.269812] [drm] No driver support for vblank timestamp query.
[3.323251] exynos-drm exynos-drm: fb0: frame buffer device
[3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
---
-Anand Moon
--
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] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 22 November 2015 at 05:43, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> Hi Krzysztof,
>>
>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>> <k.kozlow...@samsung.com> wrote:
>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>>> hi Krzysztof,
>>>>>>
>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>> <k.kozlow...@samsung.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>> >
>>>>>>> > Changes fix the following debug lock warning.
>>>>>>> >
>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>
>>>>>>> Hi Anand!
>>>>>>>
>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>>>> see different warning). More over you are partially reverting the commit
>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>>>> without proper explanation:
>>>>>>> 1. why this locking is inappropriate;
>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>
>>>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>>>> the real issue.
>>>>>>>
>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>> should be scheduled from function called by timer?
>>>>>>>
>>>>>>> Warning with debug atomic sleep:
>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>> swapper/0
>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>> [ 16.070524]
>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>> (show_stack+0x10/0x14)
>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>>>> (call_timer_fn+0x6c/0xf4)
>>>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>>>> (__do_softirq+0x134/0x2c0)
>>>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>>>> (irq_exit+0xd0/0x114)
>>>>>>> [ 16.157255] [] (irq
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 11 December 2015 at 09:37, Anand Moon <linux.am...@gmail.com> wrote:
> Hi Krzysztof,
>
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>> Hi Krzysztof,
>>>
>>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>>> <k.kozlow...@samsung.com> wrote:
>>>> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>> hi Krzysztof,
>>>>>
>>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>>> <k.kozlow...@samsung.com> wrote:
>>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>>>> hi Krzysztof,
>>>>>>>
>>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>>> <k.kozlow...@samsung.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>>> >
>>>>>>>> > Changes fix the following debug lock warning.
>>>>>>>> >
>>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>>
>>>>>>>> Hi Anand!
>>>>>>>>
>>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>>> locking in atomic context (if you build with debug sleep atomic you
>>>>>>>> will
>>>>>>>> see different warning). More over you are partially reverting the
>>>>>>>> commit
>>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to
>>>>>>>> enable")
>>>>>>>> without proper explanation:
>>>>>>>> 1. why this locking is inappropriate;
>>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>>
>>>>>>>> Please find the real problem, fix the real problem and throughly
>>>>>>>> explain
>>>>>>>> the real issue.
>>>>>>>>
>>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>>> should be scheduled from function called by timer?
>>>>>>>>
>>>>>>>> Warning with debug atomic sleep:
>>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>>> swapper/0
>>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>>> [ 16.070524]
>>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>>> (show_stack+0x10/0x14)
>>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>>> [ 16.125119] []
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof
On 11 December 2015 at 09:53, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 11.12.2015 13:07, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 22 November 2015 at 05:43, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> Hi Krzysztof,
>
> [...]
>
>>> Yes, now you pasted the same warning I did...
>>>
>>> This is still the same issue. I already wrote it:
>>>> 1. BUG: sleeping function called from invalid context
>>>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> We can repeat it many times but that won't change anything...
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Would you consider below changes to fix the above issue.
>> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
>> And I don't observed issue.
>>
>> 1. BUG: sleeping function called from invalid context
>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> Please share your thought on this changes.
>>
>> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index d24ca5f..f3f6cf9 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
>> if (!pwm)
>> return -EINVAL;
>>
>> + if (!mutex_is_locked(>lock))
>> + return -EINVAL;
>> +
>> mutex_lock(>lock);
>>
>> if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
>
> First of all, Thierry suggested way of fixing this:
> "Any objections to simply removing it and make all users use a workqueue
> or some such if they need to control a PWM as a result of an interrupt
> trigger?"
You are correct, current design need to be changes.
> what is wrong with his approach?
>
pwm->lock is locked but it never get unlocked, although the code looks correct.
> Second, you are writing something that looks like mutex-try-lock...
> which will fail the pwm_enable(). IMHO this *hides* the real issue and
> does not solve anything (except hiding also the warning).
Thanks for the inputs. I have realized my mistake.
>
> Best regards,
> Krzysztof
-Anand Moon
--
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 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
ts/exynos4x12.dtsi | 184 > drivers/devfreq/Kconfig| 37 +- > drivers/devfreq/Makefile |2 + > drivers/devfreq/devfreq.c | 120 ++- > drivers/devfreq/exynos/Makefile|3 +- > drivers/devfreq/exynos/exynos-bus.c| 549 ++ > drivers/devfreq/exynos/exynos4_bus.c | 1055 > > drivers/devfreq/exynos/exynos4_bus.h | 110 -- > drivers/devfreq/exynos/exynos5_bus.c | 431 > drivers/devfreq/exynos/exynos_ppmu.c | 119 --- > drivers/devfreq/exynos/exynos_ppmu.h | 86 -- > drivers/devfreq/governor.h |7 + > drivers/devfreq/governor_passive.c | 109 ++ > drivers/devfreq/governor_performance.c |1 + > drivers/devfreq/governor_powersave.c |1 + > drivers/devfreq/governor_simpleondemand.c |1 + > drivers/devfreq/governor_userspace.c |1 + > include/linux/devfreq.h| 28 + > 25 files changed, 1958 insertions(+), 1828 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > create mode 100644 drivers/devfreq/exynos/exynos-bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h > delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h > create mode 100644 drivers/devfreq/governor_passive.c > > -- > 1.9.1 > I could not get this series to work with my Odroid U3. [4.602768] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [4.605527] devfreq bus_leftbus: Couldn't update frequency transition information. [4.607319] devfreq bus_dmc: Couldn't update frequency transition information. [4.625096] usb 1-3: New USB device found, idVendor=0424, idProduct=3503 -Anand Moon -- 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 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Chanwoo Choi,
On 10 December 2015 at 05:42, Chanwoo Choi <cw00.c...@samsung.com> wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi <cw00.c...@samsung.com> wrote:
>>> This patch-set includes the two features as following. The generic exynos
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>> when executing regulator_disable() because of only parent
>>> devfreq device has the regulator instance. After fixing it,
>>> the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>> after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>> DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>> on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>> There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>> In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> clocks = <_dmc CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> status = "disabled";
>>> };
>>>
>>> bus_dmc_opp_table: opp_table0 {
>>> compatible = "operating-points-v2";
>>> opp-shared;
>>>
>>> opp00 {
>>> opp-hz = /bits/ 64 <5000>;
>>> opp-microvolt = <80>;
>>> };
>>> opp01 {
>>> opp-hz = /bits/ 64 <1>;
>>> opp-microvolt = <80>;
>>> };
>>> opp02 {
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>> opp03 {
>>> opp-hz = /bits/ 64 <2>;
>>> opp-microvolt = <80>;
>>> };
>>> opp04 {
>>> opp-hz = /bits/ 64 <4>;
>>>
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 9 December 2015 at 09:41, Chanwoo Choi <cw00.c...@samsung.com> wrote: > Hi Anand, > > On 2015년 11월 27일 09:34, Chanwoo Choi wrote: >> Hi Anand, >> >> On 2015년 11월 27일 02:17, Anand Moon wrote: >>> Hi Chanwoo, >>> >>> On 26 November 2015 at 21:42, Chanwoo Choi <cwcho...@gmail.com> wrote: >>>> On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham <myungjoo@samsung.com> >>>> wrote: >>>>> On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi <cw00.c...@samsung.com> >>>>> wrote: >>>>>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>>>>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos >>>>>> SoC >>>>>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>>>>> This driver can support the generic bus frequency driver for Exynos SoCs. >>>>>> >>>>>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>>>>> and devfreq-event devices which measure the utilization of each bus >>>>>> block. >>>>>> >>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com> >>>>>> --- >>>>>> drivers/devfreq/Kconfig | 15 ++ >>>>>> drivers/devfreq/Makefile| 1 + >>>>>> drivers/devfreq/exynos/Makefile | 1 + >>>>>> drivers/devfreq/exynos/exynos-bus.c | 443 >>>>>> >>>>>> 4 files changed, 460 insertions(+) >>>>>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>>>>> >>>>> >>>>> Are we finally getting a common Exynos bus driver with full DT support? >>>>> (can this replace both Exynos4/5 drivers and support Exynos7 series?) >>>> >>>> Yes. >>>> This patch-set would support all Exynos SoCs for bus frequency driver. >>>> To make sure the support for Exynos7 series, I need to check the TRM >>>> document of Exynos7. I think it is possible for support Exynos7. >>>> >>>> I'm going to test this driver on various Exynos-based board. >>>> >>>> Regards, >>>> Chanwoo Choi >>> >>> Please do consider Exynos 542x series as well. >> >> Sure. I'll to test it on Exynos5422-based Odroid-XU3. > > I send the v2 patchset but this patchset don't include > the support of Odroid-XU3 because of only Exynos542x has the > special addtional sequence to change the source clock > of DRAM. So, I'm going to support the bus frequency on Exynos542x. > After completing it, I'll send the separate patches. > > Thanks, > Chanwoo Choi > Not an issue. Thanks for the update. -Anand Moon -- 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 01/12] cpufreq: arm_big_little: add cluster regulator support
uster + '0';
> + reg[cluster] = regulator_get_optional(cpu_dev, name);
> + if (!IS_ERR(reg[cluster])) {
> + unsigned long opp_freq = 0;
> +
> + dev_dbg(cpu_dev, "%s: reg: %p, cluster: %d\n",
> + __func__, reg[cluster], cluster);
> + cpu_devs[cluster] = cpu_dev;
> +
> + /*
> +* Disable any OPPs where the connected regulator isn't able
> to
> +* provide the specified voltage and record minimum and
> maximum
> +* voltage levels.
> +*/
> + while (1) {
> + struct dev_pm_opp *opp;
> + unsigned long opp_uV;
> +
> + rcu_read_lock();
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, _freq);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + break;
> + }
> + opp_uV = dev_pm_opp_get_voltage(opp);
> + rcu_read_unlock();
> +
> + if (regulator_is_supported_voltage(reg[cluster],
> opp_uV,
> + opp_uV)) {
> + if (opp_uV < min_uV)
> + min_uV = opp_uV;
> + if (opp_uV > max_uV)
> + max_uV = opp_uV;
> + } else {
> + dev_pm_opp_disable(cpu_dev, opp_freq);
> + }
> +
> + opp_freq++;
> + }
> +
> + ret = regulator_set_voltage_time(reg[cluster], min_uV,
> max_uV);
> + if (ret > 0)
> + transition_latencies[cluster] = ret * 1000;
> + }
> +
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table[cluster]);
> if (ret) {
> dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d,
> err: %d\n",
> @@ -483,6 +599,11 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> else
> policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>
> + if (cur_cluster < MAX_CLUSTERS &&
> + policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
> + policy->cpuinfo.transition_latency
> + += transition_latencies[cur_cluster];
> +
> if (is_bL_switching_enabled())
> per_cpu(cpu_last_req_freq, policy->cpu) =
> clk_get_cpu_rate(policy->cpu);
>
> --
> 2.6.2
>
I am getting following warning when I am trying to use git am
root@odroidxu4:/usr/src/odroidxu3-4.y-final# git am -s cpuf1.patch
Applying: cpufreq: arm_big_little: add cluster regulator support
/usr/src/odroidxu3-4.y-final/.git/rebase-apply/patch:144: trailing whitespace.
}
warning: 1 line adds whitespace errors.
---
Also I have disabled and enabled following config options.
-CONFIG_BL_SWITCHER=y
-CONFIG_BL_SWITCHER_DUMMY_IF=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_DT_BL_CPUFREQ=y
But I could not see the cpu frequency working on my Odroid XU4. Am I
missing some thing.
Every 2.0s: cpupower -c 4 frequency-info
Thu Dec
3 04:02:36 2015
analyzing CPU 4:
driver: arm-big-little
CPUs which run at the same hardware frequency: 4 5 6 7
CPUs which need to have their frequency coordinated by software: 4 5 6 7
maximum transition latency: 0.00 ms.
hardware limits: 200 MHz - 1.80 GHz
available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600
MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30
GHz, 1.40 GHz, 1.50 GH
z, 1.60 GHz, 1.70 GHz, 1.80 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 200 MHz and 1.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.80 GHz (asserted by call to hardware).
cpufreq stats: 200 MHz:0.00%, 300 MHz:0.00%, 400 MHz:0.00%, 500
MHz:0.00%, 600 MHz:0.00%, 700 MHz:0.00%, 800 MHz:0.00%, 900 MHz:0.00%,
1000 MHz:0.00%, 1.10
GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:0.00%, 1.40 GHz:0.00%, 1.50
GHz:0.00%, 1.60 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:100.00% (1)
-Anand Moon
--
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: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 30 November 2015 at 11:12, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 27.11.2015 15:42, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 22 October 2015 at 18:34, Anand Moon <linux.am...@gmail.com> wrote:
>>> hi Krzysztof,
>>>
>>> On 22 October 2015 at 06:31, Krzysztof Kozlowski
>>> <k.kozlow...@samsung.com> wrote:
>>>> On 20.10.2015 21:56, Anand Moon wrote:
>>>>> Changes need for host controller to detect UHS-I highspeed cards.
>>>>> Changes in VDDQ_MMC2 voltage range help scale
>>>>> the required voltage to detect and load the microSD cards.
>>>>
>>>> Thanks for updating description of commit.
>>>>
>>>>>
>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>> ---
>>>>> Changes based on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> v4.4-next/dt-samsung branch
>>>>>
>>>>> Changes:
>>>>> Drop the ranp_delay for LDO9.
>>>>>
>>>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>>>> me out figure out the mmc core requirement.
>>>>>
>>>>> Also drop the previous changes:
>>>>> use cd-gpio method to detect sd-card.
>>>>> Added UHS-I bus speed support.
>>>>>
>>>>> [4.713553] random: nonblocking pool is initialized
>>>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy
>>>>> regulator
>>>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>>>> fimd_component_ops)
>>>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>>>> mixer_component_ops)
>>>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>>>> hdmi_component_ops)
>>>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>>>> [5.054571] usb 2-1: new full-speed USB device number 2 using
>>>>> exynos-ohci
>>>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg
>>>>> 0x0 status 0x0)
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> index 1af5bdc..a4be3e0 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> @@ -182,9 +182,10 @@
>>>>>
>>>>> ldo13_reg: LDO13 {
>>>>> regulator-name = "vdd_ldo13";
>>>>> - regulator-min-microvolt = <280>;
>>>>> + regulator-min-microvolt = <180>;
>>>>
>>>> You did not convinced me in previous discussion about the change to
>>>> 1.8V. I said that:
>>>>> On the same diagram few lines below:
>>>>> VDDQ_MMC2: 2.8V 250mA
>>>>
>>>> You responded:
>>>>> You are correct.
>>>>
>>>> So I am confused. Are you sure that this SD card block can/should
>>>> operate on 1.8V? Have you actually tried this?
>>>>
>>>
>>> Look like I missed this point. Here is the link I would like to share.
>>>
>>> http://www.hjreggel.net/cardspeed/cs_sdxc.html
>>> Section: Summary of SD modes
>>>
>>> https://en.wikipedia.org/wiki/Secure_Digital
>>> Section: Power consumption
>>>
>>> Their different requirement for voltage requirement for UHS-I, the max
>>> value is around 3.3V
>>
>> Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
> I asked whether you tried this, whether setting real 1.8V works fine.
> You did not respond. As you can see on Odroid schematics, the VDDQ for
> MMC[01] operates under 1.8V.
>
> The VDDQ for MMC2 - under 2.8V.
>
> In commit description you mentioned that this voltage "helps scale the
> required voltage to detect and load the microSD cards". What does it
> mean "help"? I would expect that detecting and loading of microSD cards
> either works or does not work. I am not sure how does it help.
>
> Best regards,
> Krzysztof
I will fix the commit message.
Earlier around v4.2 detection of UHS-I card was not working,but now it
seen to work in v4.4 kernel.
May be some driver issue which might have been fixed.
I am just trying to set the voltage range for LDO13 from 1.8V (min) to
2.8V (max).
If setting this is wrong according to datasheet then I will drop this setting.
-Anand Moon
--
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: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 18:34, Anand Moon <linux.am...@gmail.com> wrote:
> hi Krzysztof,
>
> On 22 October 2015 at 06:31, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> On 20.10.2015 21:56, Anand Moon wrote:
>>> Changes need for host controller to detect UHS-I highspeed cards.
>>> Changes in VDDQ_MMC2 voltage range help scale
>>> the required voltage to detect and load the microSD cards.
>>
>> Thanks for updating description of commit.
>>
>>>
>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes:
>>> Drop the ranp_delay for LDO9.
>>>
>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>> me out figure out the mmc core requirement.
>>>
>>> Also drop the previous changes:
>>> use cd-gpio method to detect sd-card.
>>> Added UHS-I bus speed support.
>>>
>>> [4.713553] random: nonblocking pool is initialized
>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>> fimd_component_ops)
>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>> mixer_component_ops)
>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>> hdmi_component_ops)
>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>>> status 0x0)
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1af5bdc..a4be3e0 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -182,9 +182,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> - regulator-min-microvolt = <280>;
>>> + regulator-min-microvolt = <180>;
>>
>> You did not convinced me in previous discussion about the change to
>> 1.8V. I said that:
>>> On the same diagram few lines below:
>>> VDDQ_MMC2: 2.8V 250mA
>>
>> You responded:
>>> You are correct.
>>
>> So I am confused. Are you sure that this SD card block can/should
>> operate on 1.8V? Have you actually tried this?
>>
>
> Look like I missed this point. Here is the link I would like to share.
>
> http://www.hjreggel.net/cardspeed/cs_sdxc.html
> Section: Summary of SD modes
>
> https://en.wikipedia.org/wiki/Secure_Digital
> Section: Power consumption
>
> Their different requirement for voltage requirement for UHS-I, the max
> value is around 3.3V
Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> + regulator-ramp-delay = <12000>;
>>
>> NAK
>>
>> We've been talking about this. Sooo mn times.
>>
>> If you are going to send v3 please come up with detailed reasoning,
>> which will convince my stubborn mind.
>>
>
> Look like I missed this point. my typo. Will drop this in next version.
> No matter I try hard, it turn out I make silly and annoying mistake.
>
> -Anand Moon
>
Well I will drop this.
>> Best regards,
>> Krzysztof
>>
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
hi Krzysztof,
On 21 November 2015 at 15:22, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>> wrote:
>>>
>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>> > (pwm: Set enable state properly on failed call to enable)
>>> > introduce double lock of mutex on pwm_enable
>>> >
>>> > Changes fix the following debug lock warning.
>>> >
>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> Hi Anand!
>>>
>>> Yeah, I am hitting this as well. Annoying. However your description is
>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>> locking in atomic context (if you build with debug sleep atomic you will
>>> see different warning). More over you are partially reverting the commit
>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>> without proper explanation:
>>> 1. why this locking is inappropriate;
>>> 2. why it is safe to remove the mutex_lock().
>>>
>>> Please find the real problem, fix the real problem and throughly explain
>>> the real issue.
>>>
>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>> should be scheduled from function called by timer?
>>>
>>> Warning with debug atomic sleep:
>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>> ../kernel/locking/mutex.c:617
>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>> [ 16.061402] INFO: lockdep is turned off.
>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>> [ 16.070524]
>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 16.086215] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [ 16.093938] [] (show_stack) from []
>>> (dump_stack+0x70/0xbc)
>>> [ 16.101122] [] (dump_stack) from []
>>> (mutex_lock_nested+0x24/0x474)
>>> [ 16.109009] [] (mutex_lock_nested) from []
>>> (pwm_enable+0x20/0x7c)
>>> [ 16.116799] [] (pwm_enable) from []
>>> (led_heartbeat_function+0xdc/0x140)
>>> [ 16.125119] [] (led_heartbeat_function) from []
>>> (call_timer_fn+0x6c/0xf4)
>>> [ 16.133606] [] (call_timer_fn) from []
>>> (run_timer_softirq+0x1a8/0x230)
>>> [ 16.141846] [] (run_timer_softirq) from []
>>> (__do_softirq+0x134/0x2c0)
>>> [ 16.149982] [] (__do_softirq) from []
>>> (irq_exit+0xd0/0x114)
>>> [ 16.157255] [] (irq_exit) from []
>>> (__handle_domain_irq+0x70/0xe4)
>>> [ 16.165056] [] (__handle_domain_irq) from []
>>> (gic_handle_irq+0x4c/0x94)
>>> [ 16.173376] [] (gic_handle_irq) from []
>>> (__irq_svc+0x58/0x98)
>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>> [ 16.185823] df40:
>>>c0010dcc
>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>> c08ce4bc c08c7364 c08ce4b4
>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>> c0010dd0 600f0013
>>> [ 16.210291] [] (__irq_svc) from []
>>> (arch_cpu_idle+0x20/0x3c)
>>> [ 16.217661] [] (arch_cpu_idle) from []
>>> (cpu_startup_entry+0x17c/0x26c)
>>> [ 16.225899] [] (cpu_startup_entry) from []
>>> (start_kernel+0x368/0x3d0)
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> > [2.701737] Modules linked in:
>>> > [2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f
>>> > #24
>>> > [2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> > [2.701787] [] (unwind_backtrace) from []
>>> > (show_stack+0x10/0x14)
>>> > [2.701808] [] (show_stack) from []
>>> > (dump_stack+0x84/0xc4)
>>> > [2.701824] [] (dump_stack) from []
>>> > (warn_slowpath_co
[PATCH] pwm: Avoid double mutex lock on pwm_enable
Commit d1cd21427747f15920cd726f5f67a07880e7dee4
(pwm: Set enable state properly on failed call to enable)
introduce double lock of mutex on pwm_enable
Changes fix the following debug lock warning.
[2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
__mutex_lock_slowpath+0x3bc/0x404()
[2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
[2.701737] Modules linked in:
[2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f #24
[2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[2.701787] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.701808] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[2.701824] [] (dump_stack) from []
(warn_slowpath_common+0x80/0xb0)
[2.701836] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x30/0x40)
[2.701849] [] (warn_slowpath_fmt) from []
(__mutex_lock_slowpath+0x3bc/0x404)
[2.701864] [] (__mutex_lock_slowpath) from []
(mutex_lock+0xc/0x24)
[2.701884] [] (mutex_lock) from []
(pwm_enable+0x20/0x7c)
[2.701903] [] (pwm_enable) from []
(led_heartbeat_function+0x74/0x144)
[2.701919] [] (led_heartbeat_function) from []
(call_timer_fn+0x24/0x98)
[2.701932] [] (call_timer_fn) from []
(run_timer_softirq+0x160/0x21c)
[2.701946] [] (run_timer_softirq) from []
(__do_softirq+0x110/0x228)
[2.701959] [] (__do_softirq) from []
(irq_exit+0xc0/0xfc)
[2.701976] [] (irq_exit) from []
(__handle_domain_irq+0x80/0xec)
[2.701990] [] (__handle_domain_irq) from []
(gic_handle_irq+0x54/0x94)
[2.702001] [] (gic_handle_irq) from []
(__irq_svc+0x54/0x90)
[2.702008] Exception stack(0xee8bdf88 to 0xee8bdfd0)
[2.702019] df80: 0001 c001b720
ee8bc000 c0573354
[2.702031] dfa0: ee8bdfe0 c07f92e4 c08004b4 c08004bc
f0806640 ee8bdfd8
[2.702039] dfc0: c0010180 c0010184 6013
[2.702053] [] (__irq_svc) from []
(arch_cpu_idle+0x38/0x3c)
[2.702073] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x1ec/0x270)
[2.702086] [] (cpu_startup_entry) from [<4000956c>] (0x4000956c)
[2.702093] ---[ end trace 539af70491f4f1a9 ]---
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
drivers/pwm/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..b8f035a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -506,16 +506,12 @@ int pwm_enable(struct pwm_device *pwm)
if (!pwm)
return -EINVAL;
- mutex_lock(>lock);
-
if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
if (err)
clear_bit(PWMF_ENABLED, >flags);
}
- mutex_unlock(>lock);
-
return err;
}
EXPORT_SYMBOL_GPL(pwm_enable);
--
2.1.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] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 14:06, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Anand, > > On 10/22/2015 07:03 AM, Anand Moon wrote: >> Hi Javier, >> >> On 22 October 2015 at 08:22, Javier Martinez Canillas >> <jav...@osg.samsung.com> wrote: >>> Hello Krzysztof, >>> >>> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>>>> >>>>> Thanks for your feedback. >>>>> >>>>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>>>> logic) to be able to read the second stage from the eMMC. >>>>>>> >>>>>>> But this has to be called before a system reboot handler and while most >>>>>>> of them use the priority 128, there are other restart handlers (such as >>>>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>>>> >>>>>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> >>>>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de> >>>>>>> Tested-by: Anand Moon <linux.am...@gmail.com> >>>>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com> >>>>>>> >>>>>>> --- >>>>>>> Hello, >>>>>>> >>>>>>> This patch was needed since a recent series from Alim [0] added >>>>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>>>> >>>>>>> But the PMU and syscon-reboot restart handler have a different >>>>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>>>> >>>>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>>>> >>>>>>> So this patch must be merged before [0] to avoid regressions. >>>>>>> >>>>>>> Best regards, >>>>>>> Javier >>>>>>> >>>>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>>>> mmc_host *host, >>>>>>> >>>>>>>/* >>>>>>> * register reset handler to ensure emmc reset also from >>>>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>>>> - * system reboot >>>>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>>>> + * so it will be executed before any system reboot handler. >>>>>>> */ >>>>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>>>> - pwrseq->reset_nb.priority = 129; >>>>>>> + pwrseq->reset_nb.priority = 255; >>>>>> >>>>>> I see the problem which you are trying to solve but this may be tricker >>>>>> then just kicking the number. Some of restart handlers are registered >>>>>> with priority 192. I found few of such, like: at91_restart_nb, >>>>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>>>> much). >>>>>> >>>>> >>>>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>>>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>>>> handler priority is 128. >>>>> >&
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 06:31, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 20.10.2015 21:56, Anand Moon wrote:
>> Changes need for host controller to detect UHS-I highspeed cards.
>> Changes in VDDQ_MMC2 voltage range help scale
>> the required voltage to detect and load the microSD cards.
>
> Thanks for updating description of commit.
>
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes:
>> Drop the ranp_delay for LDO9.
>>
>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>> me out figure out the mmc core requirement.
>>
>> Also drop the previous changes:
>> use cd-gpio method to detect sd-card.
>> Added UHS-I bus speed support.
>>
>> [4.713553] random: nonblocking pool is initialized
>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>> fimd_component_ops)
>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>> mixer_component_ops)
>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>> hdmi_component_ops)
>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [4.753428] [drm] No driver support for vblank timestamp query.
>> [4.940794] Console: switching to colour frame buffer device 274x77
>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>> status 0x0)
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..a4be3e0 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -182,9 +182,10 @@
>>
>> ldo13_reg: LDO13 {
>> regulator-name = "vdd_ldo13";
>> - regulator-min-microvolt = <280>;
>> + regulator-min-microvolt = <180>;
>
> You did not convinced me in previous discussion about the change to
> 1.8V. I said that:
>> On the same diagram few lines below:
>> VDDQ_MMC2: 2.8V 250mA
>
> You responded:
>> You are correct.
>
> So I am confused. Are you sure that this SD card block can/should
> operate on 1.8V? Have you actually tried this?
>
Look like I missed this point. Here is the link I would like to share.
http://www.hjreggel.net/cardspeed/cs_sdxc.html
Section: Summary of SD modes
https://en.wikipedia.org/wiki/Secure_Digital
Section: Power consumption
Their different requirement for voltage requirement for UHS-I, the max
value is around 3.3V
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>
> NAK
>
> We've been talking about this. Sooo mn times.
>
> If you are going to send v3 please come up with detailed reasoning,
> which will convince my stubborn mind.
>
Look like I missed this point. my typo. Will drop this in next version.
No matter I try hard, it turn out I make silly and annoying mistake.
-Anand Moon
> Best regards,
> Krzysztof
>
>> };
>>
>> ldo15_reg: LDO15 {
>> @@ -213,6 +214,7 @@
>> regulator-min-microvolt = <280>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>> };
>>
>> ldo24_reg: LDO24 {
>> @@ -338,6 +340,7 @@
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> samsung,dw-mshc-hs400-timing = <0 2>;
>> samsung,read-strobe-delay = <90>;
>> + vmmc-supply = <_reg>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>> _rclk>;
>> bus-width = <8>;
>> @@ -355,6 +358,8 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
>> bus-width = <4>;
>> + vmmc-supply = <_reg>;
>> + vqmmc-supply = <_reg>;
>> cap-sd-highspeed;
>> };
>>
>>
>
--
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] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 08:22, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Krzysztof, > > On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>> >>> Thanks for your feedback. >>> >>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>> logic) to be able to read the second stage from the eMMC. >>>>> >>>>> But this has to be called before a system reboot handler and while most >>>>> of them use the priority 128, there are other restart handlers (such as >>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>> >>>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> >>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de> >>>>> Tested-by: Anand Moon <linux.am...@gmail.com> >>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com> >>>>> >>>>> --- >>>>> Hello, >>>>> >>>>> This patch was needed since a recent series from Alim [0] added >>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>> >>>>> But the PMU and syscon-reboot restart handler have a different >>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>> >>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>> >>>>> So this patch must be merged before [0] to avoid regressions. >>>>> >>>>> Best regards, >>>>> Javier >>>>> >>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>> mmc_host *host, >>>>> >>>>>/* >>>>> * register reset handler to ensure emmc reset also from >>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>> - * system reboot >>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>> + * so it will be executed before any system reboot handler. >>>>> */ >>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>> - pwrseq->reset_nb.priority = 129; >>>>> + pwrseq->reset_nb.priority = 255; >>>> >>>> I see the problem which you are trying to solve but this may be tricker >>>> then just kicking the number. Some of restart handlers are registered >>>> with priority 192. I found few of such, like: at91_restart_nb, >>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>> much). >>>> >>> >>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>> handler priority is 128. >>> >>>> I guess they chose the "192" priority on purpose. >>>> >>> >>> I tried to understand what's the policy w.r.t priority numbering for >>> restart handlers but only found this in the register_restart_handler >>> kernel-doc [0]: >>> >>> /** >>> * register_restart_handler - Register function to be called to reset >>> * the system >>> * @nb: Info about handler function to be called >>> * @nb->priority: Handler priority. Handlers should follow the >>> * following guidelines for setting priorities. >>> * 0: Restart handler of last resort, >>> *
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hi Javier, On 21 October 2015 at 16:16, Alim Akhtar <alim.akh...@samsung.com> wrote: > > > On 10/21/2015 04:12 PM, Markus Reichl wrote: >> >> Am 21.10.2015 um 12:16 schrieb Javier Martinez Canillas: >>> >>> Hello Alim, >>> >>> On 10/21/2015 08:09 AM, Alim Akhtar wrote: >>> >>> [snip] >>> >>>>>>>> >>>>>>>> Hi Alim, >>>>>>>> >>>>>>>> I have installed your patch set above with git am on top of >>>>>>>> 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today >>>>>>>> with make exynos_defconfig on Odroid U3. >>>>>>>> >>>>>>> which exynos soc Odroid U3 uses? >>>>>>> >>>>>> OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does >>>>>> include exynos4.dtsi, >>>>>> so these should have worked. >>>>>> >>>>>>>> "halt -p" worked (power 0.0W). >>>>>>>> "reboot" got stuck at 0.5W. >>>>>>>> >>>>>>> reboot stuck mean system does not reboot any more? >>>>> >>>>> >>>>> It freezes when going for reboot. >>>>> Have to power off/on to boot again. >>>>> >>>>> Btw I use an mmc, not an sd-card. >>>>> No other HW connected, just LAN-cable. >>>>> Bootloader is u-boot v2015.10. >>>>> o >>>> >>>> Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach >>>> boards. >>>> Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might >>>> help here to check whats wrong. To me its looks more of a board specific >>>> issue for now. >>>> >>> >>> Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an >>> Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). >>> >>> Having said that I think I know what is the issue here. Markus said that >>> he is using an eMMC instead of an uSD (which is what I used and my guess >>> is that Krzysztof did too). >>> >>> Now, there is a subtle difference between the old PMU restart handler >>> and the syscon-reboot one, and that is the restart handler priorities: >>> >>> notifierpriority >>> >>> pmu_restart_notify 128 >>> mmc_pwrseq_emmc_reset_nb129 >>> syscon_restart_handle 192 >>> >>> So, without Alim's patches, first the eMMC reset handler will be called >>> and then the PMU restart handler but after his series, the syscon reset >>> handler has a higher priority so the eMMC reset will never be called. >>> >>> But the problem is that the eMMC card has to be properly reset on system >>> restart to allow the SoC iROM to be able to read the bootloader from the >>> eMMC since the iROM doesn't have restart logic and the card shouldn't be >>> left in an unknown state. >>> >>> So the problem here is not that the system is not being reset (that I >>> think that works) but that on reboot, the system is not able to boot >>> again since the ROM is not able to read the second stage bootloader. >>> >>> Markus, >>> >>> Can you please test following patch [0] on top of Alim's series? If that >>> works then it should either be part of Alim's series or the patches will >>> have to wait until that patch lands into mainline. I don't have an eMMC >>> to test it in XU4 but I'm pretty confident that it will solve the issue. >> >> >> Hi Javier, >> >> your patch fixes the issue, reboot works now on U3. >> > Good to know that. > Thanks >> >> Tested-by: Markus Reichl <m.rei...@fivetechno.de> >> >> Thanks, >> -- >> Markus >> >> >>> >>> Best regards, >>> >> Tested on OdroidXU3 emmc. Reboot success. Tested-by: Anand Moon <linux.am...@gmail.com> -Anand Moon >> >> > -- > 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 v2 3/6] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
hi Alim,
On 20 October 2015 at 16:00, Javier Martinez Canillas
<jav...@osg.samsung.com> wrote:
> Hello Alim,
>
> On 10/20/2015 11:24 AM, Alim Akhtar wrote:
>> This patch adds syscon-{reboot, poweroff} nodes to allow the
>> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5 SoCs.
>>
>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>> Reviewed-by: Pankaj Dubey <pankaj.du...@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>> Acked-by: Moritz Fischer <moritz.fisc...@ettus.com>
>> ---
>> arch/arm/boot/dts/exynos5.dtsi | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> --
Tested on OdroidXU3.
Tested-by: Anand Moon <linux.am...@gmail.com>
-Anand Moon
> 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
[PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Changes need for host controller to detect UHS-I highspeed cards.
Changes in VDDQ_MMC2 voltage range help scale
the required voltage to detect and load the microSD cards.
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes:
Drop the ranp_delay for LDO9.
Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
me out figure out the mmc core requirement.
Also drop the previous changes:
use cd-gpio method to detect sd-card.
Added UHS-I bus speed support.
[4.713553] random: nonblocking pool is initialized
[4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
[4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
fimd_component_ops)
[4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
mixer_component_ops)
[4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
hdmi_component_ops)
[4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.753428] [drm] No driver support for vblank timestamp query.
[4.940794] Console: switching to colour frame buffer device 274x77
[4.995344] exynos-drm exynos-drm: fb0: frame buffer device
[5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[5.031164] exynos-dwc3 usb@1200: no suspend clk specified
[5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
[5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
[5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
status 0x0)
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1af5bdc..a4be3e0 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -182,9 +182,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
- regulator-min-microvolt = <280>;
+ regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +214,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo24_reg: LDO24 {
@@ -338,6 +340,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+ vmmc-supply = <_reg>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
_rclk>;
bus-width = <8>;
@@ -355,6 +358,8 @@
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
bus-width = <4>;
+ vmmc-supply = <_reg>;
+ vqmmc-supply = <_reg>;
cap-sd-highspeed;
};
--
2.1.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 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Doug/ Krzysztof , On 15 October 2015 at 04:10, Doug Anderson <diand...@chromium.org> wrote: > Hi, > > On Tue, Oct 13, 2015 at 6:06 PM, Alim Akhtar <alim.akh...@gmail.com> wrote: >> +Doug >> Hello, >> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >> and SDR104 modes. >> >> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >> >> What I remember is, one need to set "broken-cd" property also in order >> to make it work because of the vqmmc and vmmc connection on board. I >> didn't find the link right now, but you can search on the web, there >> was a long discussion about handling this. >> Have not checked it recently, so not sure if this got broken somehow. > > Right. It _shouldn't_ be possible to add "vmmc/vqmmc" supplies to > your DTS (which you do in patch 2/3) and also to use the "gpc2-2" pin > for card detect (even if you configure it as a GPIO). Once you add > "vmmc/vqmmc" then Linux ought to be turning these regulators off when > no card is plugged in. Presumably the "vqmmc" regulator is hooked up > to the "VDDQ_MMC2". If you look in the user manual for 5422 you can > see that "GPC2[2]/SD_2_CDn" has power domain "VDDQ_MMC2". Thus you > really shouldn't be using that pin when vqmmc is off. I think at some > point someone claimed that it still worked for them, but nobody could > ever explain why. Full discussion at > <https://patchwork.kernel.org/patch/4763881/> > > --- > > In case it matters, comments on stuff from earlier in the thread: > > * As people pointed out, exynos5422 certainly supports all these modes > (including DDR50) in the SoC. > > * Just because the SoC supports these modes doesn't mean that the > boards do, which is why the SoC .dtsi doesn't include them. Thus, > this patch is "right" in that it changes a board-specific file. > > * As Krzysztof points out this board doesn't "add" support but rather > "enables" support. The distinction is subtle. > > * You might be able to get DDR50 working, but probably better to just > start with SDR modes. Previously I never attempted to get DDR50 cards > working, so possibly the software needs extra work? > Thanks for clarifying all the background details on the mmc changes. Here is what I would conclude from the previous mail chain's. 1 Drop the cd-gpios changes. pinctrl-0 changes. 2 Fix the regulator changes for vmmc/vqmmc with disable of regulator-always-on; 3 Drop this UHS-I changes as if now. Is this ok with you. -Anand Moon > > -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 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req 1Hz, actual 1HZ div = 0)
[4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
[ 4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
[4.650293] IRQ56 no longer affine to CPU7
[4.650581] CPU7: shutdown
[4.658293] mmcblk0: p1 p2
Note: Their is need to reset the PMIC
S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
to support this feature consistently on every reboot.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>>> _rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <_reg>;
>>> +vqmmc-supply = <_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>> Best regards,
>> Krzysztof
>>
>>> cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
>>> cd-inverted;
>>> pinctrl-names = "default";
>>>
>>
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
Setting this DDR50 capability give me this error. That's the reason to
drop this capability.
Sep 24 09:37:04 odroidxu4 kernel: [4.138418] mmc_host mmc1: Bus
speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ
div = 0)
Sep 24 09:37:04 odroidxu4 kernel: [4.138546] mmc1: new ultra high
speed DDR50 SDHC card at address
Sep 24 09:37:04 odroidxu4 kernel: [4.141585] mmcblk0: mmc1:
SL32G 29.7 GiB
Sep 24 09:37:04 odroidxu4 kernel: [4.146477] mmcblk0: error -110
sending status command, retrying
Sep 24 09:37:04 odroidxu4 kernel: [4.146577] mmcblk0: error -115
sending stop command, original cmd response 0x900, card status 0x900
Sep 24 09:37:04 odroidxu4 kernel: [4.146581] mmcblk0: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Jaehoon Chung
On 12 October 2015 at 16:21, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> On 10/12/2015 07:46 PM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>> Looks like I missed it, I will add this in the next patch,
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>>
>>
>>>>
>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>
>>>> ---
>>>> Changes based on
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>> v4.4-next/dt-samsung branch
>>>>
>>>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>>
>>> I don't get what is exactly fixed here. What was the error? What is the
>>> outcome of this fix? The log below is before or after?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>>
>>>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>>>> 1Hz, actual 1HZ div = 0)
>>>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>>>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>>>> [2.461743] mmcblk0: p1 p2
>>>
>>>> ---
>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> index 58c06d3..ba4a87b 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> @@ -364,6 +364,10 @@
>>>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>>>> bus-width = <4>;
>>>> cap-sd-highspeed;
>>>> + sd-uhs-sdr12;
>>>> + sd-uhs-sdr25;
>>>> + sd-uhs-sdr50;
>>>> + sd-uhs-sdr104;
>>>> };
>>>>
>>>> _0 {
>>>>
>>>
>>
>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>> OdroidXU3/XU4 board would not boot up using this card.
>>
>> Depending on the capability of the UHS-I card, the speed of the card
>> is selected.
>> I have just added the enhance capability feature to support them.
>>
>> On warm boot: i.e reboot of the board.
>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [4.657555] mmc1: new high speed SDHC card at address
>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.669206] mmcblk0: p1 p2
>>
>> On cold boot:: ie: power on the board.
>>
>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 10000Hz, actual 1HZ div = 0)
>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.650293] IRQ56 no longer affine to CPU7
>> [4.650581] CPU7: shutdown
>> [4.658293] mmcblk0: p1 p2
>>
>> Note: Their is need to reset the PMIC
>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>> to support this feature consistently on every reboot.
>
> I don't understand...why needs to reset?
> I know it needs to switch the voltage, doesn't it?
>
I was referring to this code.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/regulator/s2mps11.c#L451
I am not sure if this need to fixed in u-boot of hardkernel or
shutdown function.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> -Anand Moon
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 13.10.2015 12:08, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 05:44, Krzysztof Kozlowski >> <k.kozlow...@samsung.com> wrote: >>> On 13.10.2015 00:32, Anand Moon wrote: >>>> Hi Krzysztof, >>>> >>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>>> <k.kozlow...@samsung.com> wrote: >>>>> On 12.10.2015 00:46, Anand Moon wrote: >>>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>>>> >>>>> This description is not entirely correct. The MMC driver already >>>>> supports these UHS speeds (you did not any code) so you rather enabled >>>>> it (description of bindings says "is supported"). >>>>> >>>>> You mentioned DDR50 but I don't see respective property below. >>>>> >>>>> How do you know that these modes are really supported? I don't know. Can >>>>> you convince me? >>>> >>>> Setting this DDR50 capability give me this error. That's the reason to >>>> drop this capability. >>> >>> But you mentioned it in commit message! "Added support for UHS-I ... >>> (DDR50)" >>> >>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>> and SDR104 are really supported". >>> >> >> These changes are related to the microSD card capabilities. >> So SDR50 have better frequency over DDR50. On the same Sandisk card. >> >> When the card select the capability for DDR50 >> --- >> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >> [4.009179] mmcblk0: error -110 sending status command, retrying >> [4.009271] mmcblk0: error -115 sending stop command, original cmd >> response 0x900, card status 0x900 >> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >> cmd response 0x900, card status 0x0 >> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 40Hz, actual 396825HZ div = 63) >> [4.067770] Console: switching to colour frame buffer device 274x77 >> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.099692] mmc1: tried to reset card >> [4.101332] mmcblk0: p1 p2 >> >> >> When the card select the capability for SDR50 >> - >> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >> 1Hz, actual 1HZ div = 0) >> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >> [ 2.461743] mmcblk0: p1 p2 >> >> Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. OK, you are correct.Just ignore these changes. -Anand Moon > > Best regards, > Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> <k.kozlow...@samsung.com> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: >>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 10000HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. -Anand Moon > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>>> Hi Krzysztof,
>>>>
>>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>>> <k.kozlow...@samsung.com> wrote:
>>>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>>>
>>>>>> I can't see the description of a problem which is fixed. If you fix
>>>>>> something, then please describe what is wrong.
>>>>>>
>>>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>>>
>>>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>>>>
>>>>>>> ---
>>>>>>> Changes based on
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>>> v4.4-next/dt-samsung branch
>>>>>>>
>>>>>>> Note:
>>>>>>> Changes need for support of UHS-I highspeed cards.
>>>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>>>
>>>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> index 26decbd..58c06d3 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> @@ -157,6 +157,7 @@
>>>>>>> regulator-min-microvolt = <300>;
>>>>>>> regulator-max-microvolt = <300>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo10_reg: LDO10 {
>>>>>>> @@ -182,9 +183,10 @@
>>>>>>>
>>>>>>> ldo13_reg: LDO13 {
>>>>>>> regulator-name = "vdd_ldo13";
>>>>>>> -regulator-min-microvolt = <280>;
>>>>>>> +regulator-min-microvolt = <180>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo15_reg: LDO15 {
>>>>>>> @@ -213,6 +215,7 @@
>>>>>>> regulator-min-microvolt = <280>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>
>>>>>> Where did you get this value from? It looks wrong... My datasheet does
>>>>>> not have 12000 uV/uS.
>>>>>
>>>>
>>>>> Anand,
>>>>>
>>>>> We have actually been here:
>>&
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
Sorry But I did not change it right way. By looking at the diff.
If the changes are wrong I will drop that changes.
I have to dig in my logs to find out why I have changes this setting.
Here is the log below, I will check If I am able to reproduce this bug
in the current kernel.
Sorry for the mess I have created.
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559940]
==
Oct 6 08:23:21 odroidxu4 kernel: [6.559943] [ INFO: possible
circular locking dependency detected ]
Oct 6 08:23:21 odroidxu4 kernel: [6.559947] 4.2.0-xu4hkdn #7 Not tainted
Oct 6 08:23:21 odroidxu4 kernel: [6.559950]
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559954] swapper/0/1 is trying
to acquire lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559972]
(>mutex){+.+...}, at: [] regmap_lock_mutex+0x1c/0x20
Oct 6 08:23:21 odroidxu4 kernel: [6.559975]
Oct 6 08:23:21 odroidxu4 kernel: [6.559975] but task is already
holding lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559987]
(prepare_lock){+.+.+.}, at: [] clk_prepare_lock+0x20/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559990] which lock already
depends on the new lock.
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993] the existing
dependency chain (in reverse order) is:
Oct 6 08:23:21 odroidxu4 kernel: [6.560004]
Oct 6 08:23:21 odroidxu4 kernel: [6.560004] -> #1 (prepare_lock){+.+.+.}:
Oct 6 08:23:21 odroidxu4 kernel: [6.560019][]
mutex_lock_nested+0x84/0x4e4
Oct 6 08:23:21 odroidxu4 kernel: [6.560026][]
clk_prepare_lock+0x60/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560033][]
clk_unprepare+0x28/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560044][]
exynos5_i2c_xfer+0x2dc/0x3a4
Oct 6 08:23:21 odroidxu4 kernel: [6.560051][]
__i2c_transfer+0x160/0xc60
Oct 6 08:23:21 odroidxu4 kernel: [6.560057][]
i2c_transfer+0x74/0xa0
Oct 6 08:23:21 odroidxu4 kernel: [6.560065][]
regmap_i2c_read+0x58/0x74
Oct 6 08:23:21 odroidxu4 kernel: [6.560072][]
_regmap_raw_read+0x130/0x654
Oct 6 08:23:21 odroidxu4 kernel: [6.560078][]
_regmap_bus_read+0x34/0x6c
Oct 6 08:23:21 odroidxu4 kernel: [6.560083][]
_regmap_read+0x7c/0x350
Oct 6 08:23:21 odroidxu4 kernel: [6.560090][]
regmap_read+0x50/0x70
Oct 6 08:23:21 odroidxu4 kernel: [6.560100][]
regulator_is_enabled_regmap+0x30/0xa4
Oct 6 08:23:21 odroidxu4 kernel: [6.560107][]
_regulator_is_enabled.part.10+0x2c/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560113][]
_regulator_do_set_voltage+0x720/0x9d0
Oct 6 08:23:21 odroidxu4 kernel: [6.560119][]
regulator_set_voltage+0xc4/0x150
Oct 6 08:23:21 odroidxu4 kernel: [6.560129][]
dw_mci_switch_voltage+0x98/0xbc
Oct 6 08:23:21 odroidxu4 kernel: [6.560136][]
mmc_power_up.part.16+0x6c/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560143][]
mmc_start_host+0x54/0x78
Oct 6 08:23:21 odroidxu4 kernel: [6.560149][]
mmc_add_host+0x6c/0x90
Oct 6 08:23:21 odroidxu4 kernel: [6.560156][]
dw_mci_probe+0x660/0xc98
Oct 6 08:23:21 odroidxu4 kernel: [6.560162][]
dw_mci_pltfm_register+0x9c/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560168][]
dw_mci_exynos_probe+0x30/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560176][]
platform_drv_probe+0x54/0xb4
Oct 6 08:23:21 odroidxu4 kernel: [6.560183][]
driver
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
Looks like my changes have introduce another bug so please ignore this changes.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
My mistake, I will drop the changes. Sorry for the whole mess.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
From: Jaehoon Chung <jh80.ch...@samsung.com> To detect sd-card use the cd-gpio method. It can decrease the interrupt for detecting sd-card. Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com> Signed-off-by: Anand Moon <linux.am...@gmail.com> --- Changes based on git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v4.4-next/dt-samsung branch --- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi index 1af5bdc..26decbd 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi @@ -352,8 +352,10 @@ samsung,dw-mshc-ciu-div = <3>; samsung,dw-mshc-sdr-timing = <0 4>; samsung,dw-mshc-ddr-timing = <0 2>; + cd-gpios = < 2 GPIO_ACTIVE_HIGH>; + cd-inverted; pinctrl-names = "default"; - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>; + pinctrl-0 = <_clk _cmd _cd _bus4>; bus-width = <4>; cap-sd-highspeed; }; -- 2.1.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: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Added support for vmmc/vqmmc-supply for emmc/sd cards.
Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
Added ramp-delay for LDO9(VDD33_USB3_0).
Added ramp-delay for LDO13(VDDQ_MMC2).
Added ramp-delay for LDO15(ETH_P3V3).
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Note:
Changes need for support of UHS-I highspeed cards.
changes for vqmmc-supply for emmc is not supported.
[1.831136] vdd_ldo9: ramp_delay not set
[1.843049] vdd_ldo13: ramp_delay not set
[1.850975] vdd_ldo15: ramp_delay not set
[1.862816] vdd_sd: ramp_delay not set
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 26decbd..58c06d3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -157,6 +157,7 @@
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo10_reg: LDO10 {
@@ -182,9 +183,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
- regulator-min-microvolt = <280>;
+ regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +215,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo24_reg: LDO24 {
@@ -338,6 +341,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+ vmmc-supply = <_reg>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
_rclk>;
bus-width = <8>;
@@ -352,6 +356,8 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
+ vmmc-supply = <_reg>;
+ vqmmc-supply = <_reg>;
cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
cd-inverted;
pinctrl-names = "default";
--
2.1.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: exynos5422-odroidxu3: Added UHS-I bus speed support
Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes Fixed the UHS-I bus speed detedtion on cold boot.
[2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
1Hz, actual 1HZ div = 0)
[2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
[2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
[2.461743] mmcblk0: p1 p2
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 58c06d3..ba4a87b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -364,6 +364,10 @@
pinctrl-0 = <_clk _cmd _cd _bus4>;
bus-width = <4>;
cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
};
_0 {
--
2.1.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
[PATCHv4 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon <linux.am...@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> --- Changes: Fixed the commit message thanks to Krzysztof KozlowskAdded reviewed by Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski Build as r8152 as module --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 03deb7f..966ffc1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MICREL_PHY=y CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8152=m CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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
[PATCHv4 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon <linux.am...@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> --- Changes: Fixed the commit message thanks to Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa..5d1937b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_NETDEVICES=y CONFIG_SMSC911X=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Hi Krzysztof, On 9 October 2015 at 16:17, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze: >> On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote: >>> >>>> I realize that building things as modules is a hassle, it is so for >>>> some things more than for others, so I keep asking the question >>>> to everyone to find out what a good balance is to make as much as >>>> possible modules without hurting too much. >>> >>> Fwiw, I don't find building modules overly cumbersome. Getting an >>> initramfs capable of moving on to an NFS root is mostly a one-time >>> thing (not unlike setting up the nfs root itself) and injecting modules >>> into it is relatively simple (doubly so if taking advantage of the >>> multiple cpio archive feature linux has). >>> >>> Interestingly, for me not building things as modules in multi_v7 tends >>> to cause more work as it hides a few categories of bugs that tend to >>> crop up once building distro kernels (e.g. missing module aliases, >>> missing module device table entries, implicitly relying on clocks being >>> active during probe as unused clocks only get turned of late in the >>> init sequence etc). >>> >> >> Ok, let's try to make all future network drivers modules in the >> multi_v7_defconfig then, and get people to use an initramfs >> if they need NFS root. If nobody complains too loudly for the >> next few releases, we can change the existing drivers to =m as well. > > Personally I don't use NFS root and we don't have such configurations at > work. At least I am not aware of such. So from my point of view network > adapters as module is okay. > > Anand, > Can you change it in multi_v7 patch to module? > > Best regards, > Krzysztof Yes I will change this to build as module for multi_v7, and resend the patch. -Anand Moon -- 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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Hi Arnd, On 8 October 2015 at 20:11, Arnd Bergmann <a...@arndb.de> wrote: > On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote: >> On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote: >> > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote: >> > > On 08.10.2015 16:41, Arnd Bergmann wrote: >> > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote: >> > > > > diff --git a/arch/arm/configs/exynos_defconfig >> > > > > b/arch/arm/configs/exynos_defconfig >> > > > > index 1ff2bfa..5d1937b 100644 >> > > > > --- a/arch/arm/configs/exynos_defconfig >> > > > > +++ b/arch/arm/configs/exynos_defconfig >> > > > > @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y >> > > > > CONFIG_DM_CRYPT=m >> > > > > CONFIG_NETDEVICES=y >> > > > > CONFIG_SMSC911X=y >> > > > > +CONFIG_USB_RTL8152=y >> > > > > CONFIG_USB_USBNET=y >> > > > > CONFIG_USB_NET_SMSC75XX=y >> > > > > CONFIG_USB_NET_SMSC95XX=y >> > > > >> > > > Can we make that a loadable module for multi_v7_defconfig? >> > > >> > > What about nfsroot boots? We were discussing this also here: >> > > http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-mu >> > > lti-v7-defconfig-enable-usb3503 >> > > >> > > and actually I would be happy to see a confirmed policy about that. >> > > Everything should be a module for multi_v7? >> > >> > We try to make as much as possible modular here, and NFS root is a >> > corner >> > case: it's possible to do NFS root with an initramfs, but it's easier >> > not >> > to. Is it something you do a lot on this hardware? >> >> It's a workflow thing though, not a hardware specific thing. I >> personally tend to use NFS root quite often and so do various >> colleagues irrespective of the hardware (and an XU4 is bound to appear >> on my desk someday). >> >> Now I personally really don't mind whether NFS root requires a ramdisk >> or not (though some consistency would be nice). However deciding it on >> a per device basis just makes everything quite fuzzy (e.g. my recent >> rockchip multi_v7 patchset first ended up in a similar discussion, >> though v2 was merged without further comments when I indicated in the >> cover letter that i used the NFS root use-case as one of the deciding >> factors for y vs. m). >> >> It would be really good to see someone put their foot down on the >> general policy (e.g. the arm-soc maintainers?), such that this >> discussion doesn't need to happen every time > > Yes, agreed, that what I'm trying to do here ;-) > > I realize that building things as modules is a hassle, it is so for > some things more than for others, so I keep asking the question > to everyone to find out what a good balance is to make as much as > possible modules without hurting too much. > > Once we have a firm policy in place, we should probably change all > the existing symbols. > > Arnd As long as we use correct exynos5422-odroidxu4.dtb is used in the boot.scr/boot.ini ethernet come up, build and tested using CONFIG_USB_RTL8152=m using multi_v7_defconfig. Not sure what is the policy for NFS booting. Do you want CONFIG_USB_RTL8152 to be build as module in exynos/multi_v7_defconfig. -Anand Moon -- 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
[PATCHv3 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon <linux.am...@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> --- Changes: Fixed the commit message thanks to Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 03deb7f..009d714 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MICREL_PHY=y CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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
[PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon <linux.am...@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> --- Changes: Fixed the commit message thanks to Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa..5d1937b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_NETDEVICES=y CONFIG_SMSC911X=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Enable CONFIG_USB_RTL8152 for Odroid-XU4. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 03deb7f..009d714 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MICREL_PHY=y CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
hi Krzysztof, On 5 October 2015 at 12:08, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 05.10.2015 15:29, Anand Moon wrote: >> Enable CONFIG_USB_RTL8152 for Odroid-XU4. > > Why? > > Best regards, > Krzysztof > >> >> Signed-off-by: Anand Moon <linux.am...@gmail.com> >> --- >> arch/arm/configs/exynos_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index 1ff2bfa..5d1937b 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y >> CONFIG_DM_CRYPT=m >> CONFIG_NETDEVICES=y >> CONFIG_SMSC911X=y >> +CONFIG_USB_RTL8152=y >> CONFIG_USB_USBNET=y >> CONFIG_USB_NET_SMSC75XX=y >> CONFIG_USB_NET_SMSC95XX=y >> > Odroid XU4 supports RTL8152/RTL8153 Based USB 3.0 Ethernet Adapters. Will send v2 version of the patch. -Anand Moon -- 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] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Enable CONFIG_USB_RTL8152 for Odroid-XU4. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa..5d1937b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_NETDEVICES=y CONFIG_SMSC911X=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.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
[PATCHv2 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 supports RTL8152/RTL8153 Based USB 3.0 Ethernet Adapters. Support speed upto 10/100/1000 Mbit Ethernet LAN. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- Changes: Fixed the commit log. --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 03deb7f..009d714 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MICREL_PHY=y CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4412-trats2: remove regulator-compatible usage
buck3_reg: BUCK3 {
> regulator-name = "vdd_int";
> regulator-min-microvolt = <85>;
> regulator-max-microvolt = <115>;
> @@ -823,8 +794,7 @@
> };
> };
>
> - buck4_reg: buck4 {
> - regulator-compatible = "BUCK4";
> + buck4_reg: BUCK4 {
> regulator-name = "vdd_g3d";
> regulator-min-microvolt = <85>;
> regulator-max-microvolt = <115>;
> @@ -834,40 +804,35 @@
> };
> };
>
> - buck5_reg: buck5 {
> - regulator-compatible = "BUCK5";
> + buck5_reg: BUCK5 {
> regulator-name = "VMEM_1.2V_AP";
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> regulator-always-on;
> };
>
> - buck6_reg: buck6 {
> - regulator-compatible = "BUCK6";
> + buck6_reg: BUCK6 {
> regulator-name = "VCC_SUB_1.35V";
> regulator-min-microvolt = <135>;
> regulator-max-microvolt = <135>;
> regulator-always-on;
> };
>
> - buck7_reg: buck7 {
> - regulator-compatible = "BUCK7";
> + buck7_reg: BUCK7 {
> regulator-name = "VCC_SUB_2.0V";
> regulator-min-microvolt = <200>;
> regulator-max-microvolt = <200>;
> regulator-always-on;
> };
>
> - buck8_reg: buck8 {
> - regulator-compatible = "BUCK8";
> + buck8_reg: BUCK8 {
> regulator-name = "VMEM_VDDF_3.0V";
> regulator-min-microvolt = <285>;
> regulator-max-microvolt = <285>;
> maxim,ena-gpios = < 2 GPIO_ACTIVE_HIGH>;
> };
>
> - buck9_reg: buck9 {
> - regulator-compatible = "BUCK9";
> + buck9_reg: BUCK9 {
> regulator-name = "CAM_ISP_CORE_1.2V";
> regulator-min-microvolt = <100>;
> regulator-max-microvolt = <120>;
> --
> 2.4.3
>
-Anand Moon
> --
> 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: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hi All, On 4 September 2015 at 05:56, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Krzysztof, > > On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote: >> On 04.09.2015 03:11, Anand Moon wrote: >>> Earlier design of the LED for Odroid XU3 was using gpio-leds >>> Now It was change to using both pwm-leds and gpio-leds. >> >> It is still not a reason for this change. gpio-leds were not enabled >> before. This could be a valid reason of adding LEDS_PWM to existing >> config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on >> the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO? >> > > Agreed, also the commit message doesn't explain why the heartbeat > LED trigger is enabled as I mentioned in the previous version. > >> Actually I gave up on this and I wanted to change the commit message on >> myself when applying. But discussion was brought up again so... clearly >> we have different understanding of the meaning of "WHY". :) >> >> Best regards, >> Krzysztof >> Just of the records. I you agree with following commit message I will resend the patch. -- Exynos boards support GPIO and PWM based LEDs Odroid boards support led activity to indicate the various status Red led - power: hooked up to 5V power Blue led - alive Solid light : u-boot is running flashing : Kernel is running (heart beat) ------- If you want to add some thing more please suggest me. Earlier I was just frustrated. -Anand Moon > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America -- 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: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hi Krzysztof, On 4 September 2015 at 12:18, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 04.09.2015 15:20, Anand Moon wrote: >> Hi All, >> >> On 4 September 2015 at 05:56, Javier Martinez Canillas >> <jav...@osg.samsung.com> wrote: >>> Hello Krzysztof, >>> >>> On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote: >>>> On 04.09.2015 03:11, Anand Moon wrote: >>>>> Earlier design of the LED for Odroid XU3 was using gpio-leds >>>>> Now It was change to using both pwm-leds and gpio-leds. >>>> >>>> It is still not a reason for this change. gpio-leds were not enabled >>>> before. This could be a valid reason of adding LEDS_PWM to existing >>>> config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on >>>> the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO? >>>> >>> >>> Agreed, also the commit message doesn't explain why the heartbeat >>> LED trigger is enabled as I mentioned in the previous version. >>> >>>> Actually I gave up on this and I wanted to change the commit message on >>>> myself when applying. But discussion was brought up again so... clearly >>>> we have different understanding of the meaning of "WHY". :) >>>> >>>> Best regards, >>>> Krzysztof >>>> >> >> Just of the records. I you agree with following commit message I will >> resend the patch. >> -- >> Exynos boards support GPIO and PWM based LEDs >> >> Odroid boards support led activity to indicate the various status >> Red led - power: hooked up to 5V power >> Blue led - alive Solid light : u-boot is running >>flashing : Kernel is running (heart beat) >> --- >> If you want to add some thing more please suggest me. >> >> Earlier I was just frustrated. > > That commit message looks better. Anyway I applied the patch with > changed message. You can find it here: > https://github.com/krzk/linux/commit/8b14e57ae423b676873e542944ed8714be211ded > > although it is not pushed to the for-next branch because we are at merge > window. > > Best regards, > Krzysztof > Thanks you very much. -Anand Moon -- 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
[PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Earlier design of the LED for Odroid XU3 was using gpio-leds Now It was change to using both pwm-leds and gpio-leds. Signed-off-by: Anand Moon <linux.am...@gmail.com> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com> --- Changes from last version dropped following option. CONFIG_LEDS_CLASS_FLASH CONFIG_TRIGGER_ONESHOT CONFIG_LEDS_TRIGGER_TIMER CONFIG_TRIGGER_GPIO fixed the From address fixed the commit message. --- arch/arm/configs/exynos_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..bd6b7f7 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -163,6 +163,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.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: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hi Javier, On 3 September 2015 at 14:50, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Anand, > > On 09/03/2015 07:38 AM, Anand Moon wrote: >> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, >> LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for >> Odroid-XU3/XU4 board. >> >> Signed-off-by: Anand Moon <linux.am...@gmail.com> >> >> --- > > I think Krzysztof already mentioned but a commit message shouln't > describe what the change is (one can look to the patch for that) > but why the change is needed. > > So I would had expect something along these lines: > > Many Exynos boards (i.e: the Exynos5422 Odroid XU3/XU4) have GPIO > and PWM based LEDs, so enable the needed Kconfig options to have > support for these. Also, some boards use the heartbeat LED trigger > so enable support for this as well. > >> Changes from last version >> dropped following option. >> CONFIG_LEDS_CLASS_FLASH >> CONFIG_TRIGGER_ONESHOT >> CONFIG_TRIGGER_GPIO >> fixed the From address >> --- >> arch/arm/configs/exynos_defconfig | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index 9504e77..aaf7aa4 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y >> CONFIG_MMC_DW=y >> CONFIG_MMC_DW_IDMAC=y >> CONFIG_MMC_DW_EXYNOS=y >> +CONFIG_NEW_LEDS=y >> +CONFIG_LEDS_CLASS=y >> +CONFIG_LEDS_GPIO=y >> +CONFIG_LEDS_PWM=y >> +CONFIG_LEDS_TRIGGERS=y >> +CONFIG_LEDS_TRIGGER_TIMER=y > > I don't see an Exynos board using the timer trigger. Do you need it for > some user-space application that uses the sysfs interface? I'm OK with > enabling it but again this should be mentioned in the commit message. > >> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y >> CONFIG_RTC_CLASS=y >> CONFIG_RTC_DRV_MAX77686=y >> CONFIG_RTC_DRV_MAX77802=y >> > Earlier design of the LED for Odroid XU3 was using gpio-leds Now It was change to using both pwm-leds and gpio-leds. Earlier I kept them as loadable module and now build-in. Should I resend this again. Or some body will update the commit message. -Anand Moon > The change looks good to me though so with a better commit message: > > Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com> > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America -- 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: [PATCHv7] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Hi All, On 4 September 2015 at 05:56, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Krzysztof, > > On 09/04/2015 01:55 AM, Krzysztof Kozlowski wrote: >> On 04.09.2015 03:11, Anand Moon wrote: >>> Earlier design of the LED for Odroid XU3 was using gpio-leds >>> Now It was change to using both pwm-leds and gpio-leds. >> >> It is still not a reason for this change. gpio-leds were not enabled >> before. This could be a valid reason of adding LEDS_PWM to existing >> config LEDS_GPIO. But LEDS_GPIO were not enabled... so why the change on >> the board from gpio->(gpio+pwm) means that we have to enable LEDS_GPIO? >> > > Agreed, also the commit message doesn't explain why the heartbeat > LED trigger is enabled as I mentioned in the previous version. > >> Actually I gave up on this and I wanted to change the commit message on >> myself when applying. But discussion was brought up again so... clearly >> we have different understanding of the meaning of "WHY". :) >> >> Best regards, >> Krzysztof >> > I give up. I will not resend any patch. I don't own this changes. sorry for the noise. -Anand Moon > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America -- 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
[PATCHv4] ARM: exynos_defconfig: Enable CONFIG_LEDS_PWM for Odroid-XU3/XU4
Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for Odroid-XU3/XU4 board. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- Changes from last version. Make all modules build-in. Enabled LEDS_GPIO --- arch/arm/configs/exynos_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 2263cd9..c285975 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -168,6 +168,16 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_CLASS_FLASH=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.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: [PATCHv2 2/2] ARM: exynos_defconfig: Enable CONFIG_LEDS_PWM for Odroid-XU3
HI Krzysztof, On 2 September 2015 at 19:42, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > W dniu 08.06.2015 o 02:03, Anand Moon pisze: >> Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for >> Odroid-XU3 board. >> >> Signed-off-by: Anand Moon <linux.am...@gmail.com> > > Dear Anand, > > There was some confusion for this patch (mixed v3 and v2) so overall it > slipped through fingers. > > Can you please: > 1. Rebase and resend. > 2. Enable them as built-ins, not modules. For exynos_defconfig > everything is built-in which makes easier to test on various boards. > 3. Enable LEDS_GPIO. I don't know why it disappeared... > > Best regards, > Krzysztof > > >> --- >> arch/arm/configs/exynos_defconfig | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index 1b7253b..2bbdf80 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -165,6 +165,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y >> CONFIG_MMC_DW=y >> CONFIG_MMC_DW_IDMAC=y >> CONFIG_MMC_DW_EXYNOS=y >> +CONFIG_NEW_LEDS=y >> +CONFIG_LEDS_CLASS=m >> +CONFIG_LEDS_PWM=m >> +CONFIG_LEDS_TRIGGERS=y >> +CONFIG_LEDS_TRIGGER_TIMER=m >> +CONFIG_LEDS_TRIGGER_HEARTBEAT=m >> CONFIG_RTC_CLASS=y >> CONFIG_RTC_DRV_MAX77686=y >> CONFIG_RTC_DRV_MAX77802=y >> > Thanks for you input I will resend this patch. -Anand Moon -- 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
[PATCHv5] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
From: Anand Moon <moon.li...@yahoo.com> Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for Odroid-XU3/XU4 board. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- Changes from last version dropped following option. CONFIG_LEDS_CLASS_FLASH CONFIG_TRIGGER_ONESHOT CONFIG_TRIGGER_GPIO --- arch/arm/configs/exynos_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..aaf7aa4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.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] ARM: exynos_defconfig: Make S3C2410_WATCHDOG as loadable module
S3C2410_WATCHDOG watchdog drivers should not be loaded automatically, but only if a watchdog daemon is installed. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- arch/arm/configs/exynos_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index aaf7aa4..b5d382e 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -101,7 +101,7 @@ CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y CONFIG_EXYNOS_THERMAL=y CONFIG_WATCHDOG=y -CONFIG_S3C2410_WATCHDOG=y +CONFIG_S3C2410_WATCHDOG=m CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_I2C=y CONFIG_MFD_CROS_EC_SPI=y -- 2.1.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
[PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for Odroid-XU3/XU4 board. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- Changes from last version dropped following option. CONFIG_LEDS_CLASS_FLASH CONFIG_TRIGGER_ONESHOT CONFIG_TRIGGER_GPIO fixed the From address --- arch/arm/configs/exynos_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..aaf7aa4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Make S3C2410_WATCHDOG as loadable module
Hi Krzysztof On 3 September 2015 at 10:32, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 03.09.2015 13:10, Anand Moon wrote: >> S3C2410_WATCHDOG watchdog drivers should not be loaded automatically, >> but only if a watchdog daemon is installed. > > First of all: why? > > Secondly: even as a module driver could be loaded automatically to match > enabled device (it has MODULE_DEVICE_TABLE). In the same time loading it > does not hurt - watchdog should be inactive: > > s3c2410-wdt 1006.watchdog: watchdog inactive, reset disabled, irq > disabled > > Best regards, > Krzysztof > >> >> Signed-off-by: Anand Moon <linux.am...@gmail.com> >> --- >> arch/arm/configs/exynos_defconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index aaf7aa4..b5d382e 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -101,7 +101,7 @@ CONFIG_CPU_THERMAL=y >> CONFIG_THERMAL_EMULATION=y >> CONFIG_EXYNOS_THERMAL=y >> CONFIG_WATCHDOG=y >> -CONFIG_S3C2410_WATCHDOG=y >> +CONFIG_S3C2410_WATCHDOG=m >> CONFIG_MFD_CROS_EC=y >> CONFIG_MFD_CROS_EC_I2C=y >> CONFIG_MFD_CROS_EC_SPI=y >> All the watchdog drivers are blacklisted not to be loaded by the ubuntu. Their are some configurable parameters which get configured while loading of the module using watchdog daemon. Watchdog service will reconfigure watchdog driver while loading. -Anand Moon > -- 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: [PATCHv2] ARM: EXYNOS: reset Little cores when cpu is up
Hi All,
On 1 September 2015 at 19:47, Chanho Park <parkc...@gmail.com> wrote:
>
> The cpu booting of exynos5422 has been still broken since we discussed
> it in last year[1]. This patch is inspired from Odroid XU3
> code (Actually, it was from samsung exynos vendor kernel)[2]. This weird
> reset code was founded exynos5420 octa cores series SoCs and only
> required for the first boot core is the Little core (Cortex A7).
> Some of the exynos5420 boards and all of the exynos5422 boards will require
> this code.
>
> There is two ways to check the little core is the first cpu. One is
> checking GPG2CON[1] GPIO value and the other is checking the cluster
> number of the first cpu. I selected the latter because it's more easier
> than the former.
>
> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
> [2]:https://patchwork.kernel.org/patch/6782891/
>
> Cc: Kevin Hilman <khil...@kernel.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Tested-by: Kevin Hilman <khil...@linaro.org>
> Signed-off-by: Chanho Park <parkc...@gmail.com>
> ---
> Changes from v1:
> .kfc to Little (Cortex A7) and eagle to big (Cortex A15)
> .append comments about waiting SPARE2 register
>
> Changes since RFC:
> .drop checking soc_is_exynos5800 to extend this codes to
> exynos5420/5422 boards.
> .kfc cores will be reset only if the cpu0 is kfc core.
> .Rebase top of the kukjin's for-next branch
>
> arch/arm/mach-exynos/mcpm-exynos.c | 25 -
> arch/arm/mach-exynos/regs-pmu.h| 6 ++
> 2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 9bdf547..8926621 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "regs-pmu.h"
> #include "common.h"
> @@ -70,7 +71,29 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned
> int cluster)
> cluster >= EXYNOS5420_NR_CLUSTERS)
> return -EINVAL;
>
> - exynos_cpu_power_up(cpunr);
> + if (!exynos_cpu_power_state(cpunr)) {
> + exynos_cpu_power_up(cpunr);
> +
> + /* This assumes the cluster number of the big cores(Cortex
> A15)
> +* is 0 and the Little cores(Cortex A7) is 1.
> +* When the system was booted from the Little core,
> +* they should be reset during power up cpu.
> +*/
> + if (cluster &&
> + cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
> + /* Before we reset the Little cores, we should wait
> +* the SPARE2 register is set to 1 because the init
> +* codes of the iROM will set the register after
> +* initialization.
> +*/
> + while (!pmu_raw_readl(S5P_PMU_SPARE2))
> + udelay(10);
> +
> + pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
> + EXYNOS_SWRESET);
> + }
> + }
> +
> return 0;
> }
>
> diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
> index b761433..fba9068 100644
> --- a/arch/arm/mach-exynos/regs-pmu.h
> +++ b/arch/arm/mach-exynos/regs-pmu.h
> @@ -513,6 +513,12 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int
> mpidr)
> #define SPREAD_ENABLE 0xF
> #define SPREAD_USE_STANDWFI0xF
>
> +#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
> +#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
> +
> +#define EXYNOS5420_KFC_CORE_RESET(_nr) \
> + ((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
> +
> #define EXYNOS5420_BB_CON1 0x0784
> #define EXYNOS5420_BB_SEL_EN BIT(31)
> #define EXYNOS5420_BB_PMOS_EN BIT(7)
> --
> 2.1.0
>
Looking at the following patch
https://github.com/tobiasjakobi/linux-odroid/commit/c25aae8a02c0e3132df581d1d12be1d6738a08d6
You should also consider some similar logic for platform_do_lowpower
and exynos_boot_secondary.
In that same way to address CPUIdle issue.
I am just trying to put my observation. I may
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. -Anand Moon Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. -Anand Moon -- 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: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. -Anand Moon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mfd: s2mps11: Add manual shutdown method for Odroid XU3
Hi Krzysztof,
On 3 August 2015 at 18:07, Krzysztof Kozlowski k.kozlowsk...@gmail.com wrote:
On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
register must be manually set to 0 before initiating power off sequence.
One of usual power down methods for Exynos based devices looks like:
1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos.
2. Exynos holds up this pin during system operation.
3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
other device.
4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
ACOKB goes high.
On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
This means that PMIC must manually set PWRHOLD field to low and then
wait for signal from Application Processor (the usual change in
PWRHOLD/PSHOLD pin will actually cut off the power).
The patch adds respective binding allowing Odroid XU3 device to be
powered off.
Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
Reported-by: Anand Moon linux.am...@gmail.com
---
Patch is losely based on patch in Hardkernel repository [0] and previous
work of Anand Moon [1].
[0]
https://github.com/hardkernel/linux/commit/6897e62ba328bd1c8c095d918101863250cd73e7
[1] http://www.spinics.net/lists/linux-samsung-soc/msg45959.html
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 +++
drivers/mfd/sec-core.c| 31
+++
include/linux/mfd/samsung/core.h | 2 ++
include/linux/mfd/samsung/s2mps11.h | 1 +
4 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 57a045016fca..90eaef393325 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -15,6 +15,10 @@ Optional properties:
- interrupt-parent: Specifies the phandle of the interrupt controller to
which
the interrupts from s2mps11 are delivered to.
- interrupts: Interrupt specifiers for interrupt sources.
+- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is
+ connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
+ register to turn off the power. Usually the ACOKB is pulled up to VBATT so
+ when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
Optional nodes:
- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered
32.768
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index d206a3e8fe87..a56ab2102a32 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -278,6 +278,8 @@ static struct sec_platform_data
*sec_pmic_i2c_parse_dt_pdata(
* not parsed here.
*/
+ pd-manual_poweroff = of_property_read_bool(dev-of_node,
+
samsung,s2mps11-acokb-ground);
return pd;
}
#else
@@ -440,6 +442,34 @@ static int sec_pmic_remove(struct i2c_client *i2c)
return 0;
}
+static void sec_pmic_shutdown(struct i2c_client *i2c)
+{
+ struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
+ unsigned int reg, mask;
+
+ if (!sec_pmic-pdata-manual_poweroff)
+ return;
+
+ switch (sec_pmic-device_type) {
+ case S2MPS11X:
+ reg = S2MPS11_REG_CTRL1;
+ mask = S2MPS11_CTRL1_PWRHOLD_MASK;
+ break;
+ default:
+ /*
+* Currently only one board with S2MPS11 needs this, so just
+* ignore the rest.
+*/
+ dev_warn(sec_pmic-dev,
+ Unsupported device %lu for manual power off\n,
+ sec_pmic-device_type);
+ return;
+ }
+
+ regmap_update_bits(sec_pmic-regmap_pmic, reg, mask, 0);
+}
+
+
#ifdef CONFIG_PM_SLEEP
static int sec_pmic_suspend(struct device *dev)
{
@@ -491,6 +521,7 @@ static struct i2c_driver sec_pmic_driver = {
},
.probe = sec_pmic_probe,
.remove = sec_pmic_remove,
+ .shutdown = sec_pmic_shutdown,
.id_table = sec_pmic_id,
};
diff --git a/include/linux/mfd/samsung/core.h
b/include/linux/mfd/samsung/core.h
index 75115384f3fc..aa78957e092f 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -132,6 +132,8 @@ struct sec_platform_data {
int buck2_init;
int buck3_init;
int buck4_init;
+ /* Whether or not manually set PWRHOLD to low during shutdown. */
+ boolmanual_poweroff;
};
/**
diff --git a/include/linux/mfd/samsung/s2mps11.h
b/include/linux/mfd/samsung/s2mps11.h
index 7981a9d77d3f..b288965e8101 100644
--- a/include/linux/mfd/samsung
Re: [PATCH v4] ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs
Hi Peter,
On 14/05/2015, Peter Chubb peter.ch...@nicta.com.au wrote:
PWM output wasn't working because it wasn't hooked up to its pincontrol.
This patch:
- hooks up PWM to its pincontrol, and documents what
the outputs are on the XU3
- switches the LEDs that are on PWM outputs to use PWM
rather than GPIO.
The main effect is that the brightness of the LEDs can be controlled, and
user-mode fan control is enabled via /sys/class/pwm
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Peter Chubb peter.ch...@nicta.com.au
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 50
+-
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index f0ce60b..0c62156 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -287,25 +287,35 @@
status = okay;
};
- leds {
- compatible = gpio-leds;
- heartbeat {
- label = blue:heartbeart;
- gpios = gpb2 2 0;
- default-state = off;
- linux,default-trigger = heartbeat;
+ pwmleds {
+ compatible = pwm-leds;
+
+ greenled {
+ label = green:mmc0;
+ pwms = pwm 1 200 0;
+ pwm-names = pwm1;
+ /*
+ * Green LED is much brighter than the others
+ * so limit its max brightness
+ */
+ max_brightness = 127;
+ linux,default-trigger = mmc0;
};
- eMMC {
- label = green:eMMC;
- gpios = gpb2 1 0;
- default-state = off;
- linux,default-trigger = mmc0;
+ blueled {
+ label = blue:heartbeat;
+ pwms = pwm 2 200 0;
+ pwm-names = pwm2;
+ max_brightness = 255;
+ linux,default-trigger = heartbeat;
};
+ };
- microSD {
+ gpioleds {
+ compatible = gpio-leds;
+ redled {
label = red:microSD;
- gpios = gpx2 3 0;
+ gpios = gpx2 3 GPIO_ACTIVE_HIGH;
default-state = off;
linux,default-trigger = mmc1;
};
@@ -415,3 +425,15 @@
shunt-resistor = 1;
};
};
+
+pwm {
+ /*
+ * PWM 0 -- fan
+ * PWM 1 -- Green LED
+ * PWM 2 -- Blue LED
+ * PWM 3 -- on MIPI connector for backlight
+ */
+ pinctrl-0 = pwm0_out pwm1_out pwm2_out pwm3_out;
+ pinctrl-names = default;
+ status = okay;
+};
--
2.1.4
--
Dr Peter Chubbpeter.chubb AT
nicta.com.au
http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA
I wonder how PWM can be enabled on the odroidxu3 board.
I could not find the node getting populated in the /sys/class/leds/
root@odroidxu3:l# la -la /sys/class/leds/
total 0
drwxr-xr-x 2 root root 0 Jul 31 04:56 .
drwxr-xr-x 47 root root 0 Jul 31 04:56 ..
lrwxrwxrwx 1 root root 0 Jul 31 04:56 red:microSD -
../../devices/platform/gpioleds/leds/red:microSD
Well I have enable. following config options in .config.
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=m
CONFIG_LEDS_SYSCON=y
# CONFIG_LEDS_PM8941_WLED is not set
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
# CONFIG_LEDS_TRIGGER_CPU is not set
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_TRANSIENT=y
# CONFIG_LEDS_TRIGGER_CAMERA is not set
Please let me know if I am missing some thing.
-Anand Moon
--
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] clk: s2mps11: Use kcalloc instead of kzalloc for array allocation
Hi Vaibhav,
On 22 July 2015 at 15:04, Vaibhav Hiremath vaibhav.hirem...@linaro.org wrote:
This patch cleans up the driver for,
- Use devm_kcalloc varient instead of devm_kzalloc for array
allocation.
- clk_prepare/unprepare, remove ret variable as it is not required
- use __exit for cleanup function
As I am referring this driver as a reference for my 88pm800 clk driver,
applying same changes here as well.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
Since I do not have platform to test, it would be helpful if someone
tests it for me.
I have build tested it.
drivers/clk/clk-s2mps11.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index 9b13a30..e17c66a 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -58,21 +58,17 @@ static struct s2mps11_clk *to_s2mps11_clk(struct clk_hw
*hw)
static int s2mps11_clk_prepare(struct clk_hw *hw)
{
struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
- int ret;
- ret = regmap_update_bits(s2mps11-iodev-regmap_pmic,
+ return regmap_update_bits(s2mps11-iodev-regmap_pmic,
s2mps11-reg,
s2mps11-mask, s2mps11-mask);
-
- return ret;
}
static void s2mps11_clk_unprepare(struct clk_hw *hw)
{
struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
- int ret;
- ret = regmap_update_bits(s2mps11-iodev-regmap_pmic, s2mps11-reg,
+ regmap_update_bits(s2mps11-iodev-regmap_pmic, s2mps11-reg,
s2mps11-mask, ~s2mps11-mask);
}
@@ -186,15 +182,15 @@ static int s2mps11_clk_probe(struct platform_device
*pdev)
struct clk_init_data *clks_init;
int i, ret = 0;
- s2mps11_clks = devm_kzalloc(pdev-dev, sizeof(*s2mps11_clk) *
- S2MPS11_CLKS_NUM, GFP_KERNEL);
+ s2mps11_clks = devm_kcalloc(pdev-dev, S2MPS11_CLKS_NUM,
+ sizeof(*s2mps11_clk), GFP_KERNEL);
if (!s2mps11_clks)
return -ENOMEM;
s2mps11_clk = s2mps11_clks;
- clk_table = devm_kzalloc(pdev-dev, sizeof(struct clk *) *
-S2MPS11_CLKS_NUM, GFP_KERNEL);
+ clk_table = devm_kcalloc(pdev-dev, S2MPS11_CLKS_NUM,
+ sizeof(struct clk *), GFP_KERNEL);
if (!clk_table)
return -ENOMEM;
@@ -322,7 +318,7 @@ static int __init s2mps11_clk_init(void)
}
subsys_initcall(s2mps11_clk_init);
-static void __init s2mps11_clk_cleanup(void)
+static void __exit s2mps11_clk_cleanup(void)
{
platform_driver_unregister(s2mps11_clk_driver);
}
--
1.9.1
Tested on Odroid-XU3 board.
Tested-by: Anand Moon linux.am...@gmail.com
--
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
[PATCHv2] regulator: s2mps11: Added shutdown function to poweroff
Added .shutdown function to s2mps11 to help poweroff the board successfully.
s2mps11-pmic: S2MPS11_REG_CTRL1 reg value 16:0001
The device driver clears the register to turn off the PMIC.
Signed-off-by: Anand Moon linux.am...@gmail.com
---
Console log for improper shutdown.
root@odroidxu3:~# poweroff
...
* Unmounting temporary filesystems... [ OK ]
* Deactivating swap... [ OK ]
* Unmounting local filesystems... [ OK ]
* Will now halt
[ 209.020280] reboot: Power down
[ 209.122039] Power down failed, please power off system manually.
Console log for proper shutdown.
root@odroidxu3:~# poweroff
...
* Unmounting temporary filesystems... [ OK ]
* Deactivating swap... [ OK ]
* Unmounting local filesystems... [ OK ]
* Will now halt
[ 476.283071] reboo
---
drivers/regulator/s2mps11.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 326ffb5..823180e 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1060,6 +1060,31 @@ out:
return ret;
}
+static void s2mps11_pmic_shutdown(struct platform_device *pdev)
+{
+ struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
+ unsigned int reg_val, ret;
+
+ ret = regmap_read(iodev-regmap_pmic, S2MPS11_REG_CTRL1, reg_val);
+ if (ret 0) {
+ dev_crit(pdev-dev, could not read S2MPS11_REG_CTRL1
value\n);
+ } else {
+ /*
+* s2mps11-pmic: S2MPS11_REG_CTRL1 reg value
+* is 0001
+* clear the S2MPS11_REG_CTRL1 0x10 value to shutdown.
+*/
+ if (reg_val BIT(4)) {
+ ret = regmap_update_bits(iodev-regmap_pmic,
+S2MPS11_REG_CTRL1,
+BIT(4), BIT(0));
+ if (ret)
+ dev_crit(pdev-dev,
+could not write S2MPS11_REG_CTRL1
value\n);
+ }
+ }
+}
+
static const struct platform_device_id s2mps11_pmic_id[] = {
{ s2mps11-pmic, S2MPS11X},
{ s2mps13-pmic, S2MPS13X},
@@ -1074,6 +1099,7 @@ static struct platform_driver s2mps11_pmic_driver = {
.name = s2mps11-pmic,
},
.probe = s2mps11_pmic_probe,
+ .shutdown = s2mps11_pmic_shutdown,
.id_table = s2mps11_pmic_id,
};
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] regulator: s2mps11: Added shutdown function to poweroff
hi Krzysztof,
On 15 July 2015 at 06:33, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
On 15.07.2015 00:41, Anand Moon wrote:
Added .shutdown function to s2mps11 to help poweroff the board successfully.
Which board does not poweroff? The PMIC is used on multiple boards, did
you observed this on all of them?
s2mps11-pmic: S2MPS11_REG_CTRL1 reg value 16:0001
The device driver clears the register to turn off the PMIC.
This is not sufficient explanation for commit message.
I already raised concerns that this does not look to me as a proper way
of doing poweroff. Unfortunately you did not resolved these concerns.
The main questions are unanswered: Why you have to do this and why
standard way does not work?
How can you properly fix some problem if you don't know the cause of
problem? It is blind shooting which may hurt other boards.
Signed-off-by: Anand Moon linux.am...@gmail.com
---
Console log for improper shutdown.
root@odroidxu3:~# poweroff
...
* Unmounting temporary filesystems... [
OK ]
* Deactivating swap... [
OK ]
* Unmounting local filesystems... [
OK ]
* Will now halt
[ 209.020280] reboot: Power down
[ 209.122039] Power down failed, please power off system manually.
Console log for proper shutdown.
root@odroidxu3:~# poweroff
...
* Unmounting temporary filesystems... [
OK ]
* Deactivating swap... [
OK ]
* Unmounting local filesystems... [
OK ]
* Will now halt
[ 476.283071] reboo
---
drivers/regulator/s2mps11.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 326ffb5..823180e 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1060,6 +1060,31 @@ out:
return ret;
}
+static void s2mps11_pmic_shutdown(struct platform_device *pdev)
+{
+ struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
+ unsigned int reg_val, ret;
+
+ ret = regmap_read(iodev-regmap_pmic, S2MPS11_REG_CTRL1, reg_val);
+ if (ret 0) {
regmap_read() returns an int which you assign to an unsigned int which
then you compare against 0? This does not look good.
+ dev_crit(pdev-dev, could not read S2MPS11_REG_CTRL1
value\n);
+ } else {
+ /*
+ * s2mps11-pmic: S2MPS11_REG_CTRL1 reg value
+ * is 0001
+ * clear the S2MPS11_REG_CTRL1 0x10 value to shutdown.
+ */
+ if (reg_val BIT(4)) {
+ ret = regmap_update_bits(iodev-regmap_pmic,
+ S2MPS11_REG_CTRL1,
+ BIT(4), BIT(0));
I don't understand. You want to update BIT(4) but the value is BIT(0)?
This will clear BIT(4) but is totally unreadable.
+ if (ret)
+ dev_crit(pdev-dev,
+ could not write S2MPS11_REG_CTRL1
value\n);
+ }
+ }
The code is not readable, to many unnecessary indentations.
+}
+
static const struct platform_device_id s2mps11_pmic_id[] = {
{ s2mps11-pmic, S2MPS11X},
{ s2mps13-pmic, S2MPS13X},
@@ -1074,6 +1099,7 @@ static struct platform_driver s2mps11_pmic_driver = {
.name = s2mps11-pmic,
},
.probe = s2mps11_pmic_probe,
+ .shutdown = s2mps11_pmic_shutdown,
The purpose of shutdown function is not to shutdown the system but to
prepare the system for shutdown.
The patch is just wrong and you did not answered the major question -
WHY you have to do this? Don't fix the problem blindly (or because some
hardkernel tree for some of the boards use such patch).
Best regards,
Krzysztof
.id_table = s2mps11_pmic_id,
};
I might me missing the bigger picture. So drop it.
-Anand Moon
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: EXYNOS: reset KFC cores when cpu is up
Hi Chanho,
On 15 July 2015 at 07:06, Chanho Park parkc...@gmail.com wrote:
The cpu booting of exynos5422 has been still broken since we discussed
it in last year[1]. I found this resetting codes from odroid-xu3 kernel of
hardkernel, it could help to boot 8 cores well. This patch need to have
more test like STR and other SoC especially exynos5800 which is variant
of exynos5422. If this patch is broken on exynos5800, I'll find another
way to check exynos5422.
This patch is top of my previous exynos5422 cpu ordering patch[2] and
need to enable CONFIG_EXYNOS5420_MCPM=y
[0.047509] CPU0: update cpu_capacity 448
[0.047534] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
[0.047874] Setting up static identity map for 0x400082c0 -
0x40008318
[0.048340] ARM CCI driver probed
[0.048597] Exynos MCPM support installed
[0.065676] CPU1: update cpu_capacity 448
[0.065685] CPU1: thread -1, cpu 1, socket 1, mpidr 8101
[0.070672] CPU2: update cpu_capacity 448
[0.070680] CPU2: thread -1, cpu 2, socket 1, mpidr 8102
[0.075644] CPU3: update cpu_capacity 448
[0.075653] CPU3: thread -1, cpu 3, socket 1, mpidr 8103
[0.080590] CPU4: update cpu_capacity 1535
[0.080600] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
[0.085591] CPU5: update cpu_capacity 1535
[0.085599] CPU5: thread -1, cpu 1, socket 0, mpidr 8001
[0.090590] CPU6: update cpu_capacity 1535
[0.090598] CPU6: thread -1, cpu 2, socket 0, mpidr 8002
[0.095585] CPU7: update cpu_capacity 1535
[0.095593] CPU7: thread -1, cpu 3, socket 0, mpidr 8003
[0.095720] Brought up 8 CPUs
[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
[2]:https://patchwork.kernel.org/patch/6782891/
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Kevin Hilman khil...@kernel.org
Cc: Heesub Shin heesub.s...@samsung.com
Cc: Mauro Ribeiro mauro.ribe...@hardkernel.com
Cc: Abhilash Kesavan a.kesa...@samsung.com
Cc: Przemyslaw Marczak p.marc...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Chanho Park parkc...@gmail.com
---
arch/arm/mach-exynos/mcpm-exynos.c | 13 -
arch/arm/mach-exynos/regs-pmu.h| 6 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 9bdf547..a076dde 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -70,7 +70,18 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned
int cluster)
cluster = EXYNOS5420_NR_CLUSTERS)
return -EINVAL;
- exynos_cpu_power_up(cpunr);
+ if (!exynos_cpu_power_state(cpunr)) {
+ exynos_cpu_power_up(cpunr);
+
+ if (soc_is_exynos5800() cluster) {
+ while (!pmu_raw_readl(S5P_PMU_SPARE2))
+ udelay(10);
+
+ pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
+ EXYNOS_SWRESET);
+ }
+ }
+
return 0;
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index b761433..fba9068 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -513,6 +513,12 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int
mpidr)
#define SPREAD_ENABLE 0xF
#define SPREAD_USE_STANDWFI0xF
+#define EXYNOS5420_KFC_CORE_RESET0 BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0 BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr) \
+ ((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) (_nr))
+
#define EXYNOS5420_BB_CON1 0x0784
#define EXYNOS5420_BB_SEL_EN BIT(31)
#define EXYNOS5420_BB_PMOS_EN BIT(7)
--
2.1.0
It brought all the 8 core up on my Odroid-XU3
Tested-by: Anand Moon linux.am...@gmail.com
--
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] regulator: s2mps11: Added shutdown function to poweroff Odroid-XU3
Hi Krzysztof,
On 24 June 2015 at 16:27, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
2015-06-24 19:32 GMT+09:00 Anand Moon linux.am...@gmail.com:
Hi Krzysztof,
On 24 June 2015 at 13:27, Krzysztof Kozlowski k.kozlow...@samsung.com
wrote:
2015-06-24 16:16 GMT+09:00 Anand Moon linux.am...@gmail.com:
Added .shutdown function to s2mps11 to help poweroff the board succefully.
s/succefully/successfully/
The device drivers set the register to turn off the PMIC.
Driver or drivers?
Signed-off-by: Anand Moon linux.am...@gmail.com
---
Changes fixes the poweroff
root@odroidxu3:~# poweroff
Broadcast message from root@odroidxu3
(/dev/ttySAC2) at 13:08 ...
The system is going down for power off NOW!
root@odroidxu3:~# wait-for-state stop/waiting
* Stopping rsync daemon rsync [
OK ]
* Stopping RDP Session manager [
OK ]
* Stopping NTP server ntpd [
OK ]
* Asking all remaining processes to terminate...[
OK ]
* All processes ended within 1 seconds... [
OK ]
nm-dispatcher.action: Caught signal 15, shutting down...
ModemManager[2134]: warn Could not acquire the
'org.freedesktop.ModemManager1' service name
ModemManager[2134]: info ModemManager is shut down
* Unmounting temporary filesystems... [
OK ]
* Deactivating swap... [
OK ]
* Unmounting local filesystems... [
OK ]
* Will now halt
[ 209.020280] reboot: Power down
[ 209.122039] Power down failed, please power off system manually.
---
drivers/regulator/s2mps11.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index ff82811..871f7b8 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1060,6 +1060,13 @@ out:
return ret;
}
+static void s2mps11_pmic_shutdown(struct platform_device *pdev)
+{
+ struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
+
+ regmap_update_bits(iodev-regmap_pmic, S2MPS11_REG_CTRL1, 0xff,
0x00);
This looks odd to me and interesting in the same time...
1. Why clearing all of the fields from the register? Don't you want to
clear only one of it?
I have followed what the hardkernel source code point at this point.
I will look into which bit need to clear/set to power off successful.
Following other tree is not enough, even when it solves some one
problem. Drivers could be used on different boards, where hardkernel
patches were not tested. This driver is used on many boards so please
explain exactly what is the cause of problem, what have to be done and
how patch achieves this. Such explanation helps understanding impact
on other boards.
2. What exactly you want to do here? What is expected behaviour?
When you power off the board dose not power off cleanly.
[ 209.122039] Power down failed, please power off system manually.
After this changes Its power off the board. Leaving the board with
solid red led blowing.
You described observable issue, which is nice, but I am asking for
technical details. What exactly do you want to achieve here?
Technically. What is expected behaviour. In technical details, not
only observable. I am asking for these technical details not only
because they are important but also because I do not know them.
3. How this relates to PWRHOLD coming from AP to the PMIC?
No Idea right now about this right now. but will update you it I have
some thing.
The PMIC receives two signals - PWREN and PWRHOLD. It seems strange
that PMIC must override PWRHOLD... maybe there is an issue in
mach-exynos code?
4. Why this is needed only for this driver and only for this board (Odroid
XU3)?
Yes It could be generic not specific for the Odroid XU3 will correct
in next patch.
Thanks,
Best regards,
Krzysztof
I don't have much technical knowlegde on the arch side PMIC.
Problem that I am trying to addressed is unclean shutdown. i.e. CPU is
still running in busy loop.
which leads external HDD not able to clean umount or power-off of the board.
[ 27.427485] reboot: Power down
[ 27.529236] Power down failed, please power off system manually.
My investigation lead to the following.
Reading the control register S2MPS11_REG_CTRL1 of s2mps11-pmic shown below.
[ 27.411231] s2mps11-pmic s2mps11-pmic: reg value
16:0001
clearing the bit of the control register S2MPS11_REG_CTRL1 which lead
to proper shutdown of board.
Please share you thought on this.
-Anand Moon
--
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: [PATCHv3] clk samsung exynos5420 add CLK_RECALC_NEW_RATES flag to mout_apll and mout_kpll clock.
Hi AlL,
On 8 May 2015 at 16:37, Anand Moon linux.am...@gmail.com wrote:
Addition of CLK_RECALC_NEW_RATES flag to support Exynos5420 cpu clk so that
correct divider values are re-calculated after both pre/post
clock notifiers had run for mout_apll clock and mout_kpll clock.
Observation their is considerable improvement in cpufreq stats
after applying this patch.
Governer : performance
$ cpupower -c 1 frequency-info
Below is table format of the output.
cpufreq stats: Frequency| Before | After |
CPU 1
200 MHz | 22.07% | 46.57% |
300 MHz | 1.08% | 8.18% |
400 MHz | 0.17% | 1.93% |
500 MHz | 0.24% | 3.51% |
600 MHz | 0.37% | 2.13% |
700 MHz | 0.20% | 0.88% |
800 MHz | 0.09% | 1.69% |
900 MHz | 0.05% | 1.02% |
1000 MHz | 0.02% | 2.55% |
1.10 GHz | 0.12% | 1.17% |
1.20 GHz | 0.05% | 0.88% |
1.30 GHz | 0.07% | 0.38% |
1.40 GHz | 0.04% | 0.38% |
1.50 GHz | 0.02% | 0.00% |
1.60 GHz | 0.00% | 0.15% |
1.70 GHz | 0.00% | 0.44% |
1.80 GHz | 75.43% | 28.26% |
Governer : performance
$ cpupower -c 0 frequency-info
Below is table format of the output.
cpufreq stats: Frequency| Before | After |
CPU0200 MHz | 33.95% | 60.31% |
300 MHz | 4.64% | 2.13% |
400 MHz | 1.50% | 0.79% |
500 MHz | 1.46% | 0.49% |
600 MHz | 0.05% | 0.27% |
700 MHz | 0.68% | 0.21% |
800 MHz | 0.08% | 0.19% |
900 MHz | 0.09% | 0.12% |
1000 MHz | 0.20% | 0.10% |
1.10 GHz | 0.21% | 0.11%, |
1.20 GHz | 0.51% | 0.28%, |
1.30 GHz | 56.64% | 35.01% |
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Anand Moon linux.am...@gmail.com
---
drivers/clk/samsung/clk-exynos5420.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 462aaee..6c7458c 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -618,10 +618,10 @@ static struct samsung_mux_clock exynos5x_mux_clks[]
__initdata = {
MUX(0, mout_mspll_cpu, mout_mspll_cpu_p, SRC_TOP7, 12, 2),
MUX_F(0, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
- CLK_SET_RATE_PARENT, 0),
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, mout_cpu, mout_cpu_p, SRC_CPU, 16, 1),
MUX_F(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1,
- CLK_SET_RATE_PARENT, 0),
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, mout_kfc, mout_kfc_p, SRC_KFC, 16, 1),
MUX(0, mout_aclk200, mout_group1_p, SRC_TOP0, 8, 2),
--
1.9.1
Any comments on this patch.
-Anand Moon
--
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] regulator: s2mps11: Added shutdown function to poweroff Odroid-XU3
Added .shutdown function to s2mps11 to help poweroff the board succefully.
The device drivers set the register to turn off the PMIC.
Signed-off-by: Anand Moon linux.am...@gmail.com
---
Changes fixes the poweroff
root@odroidxu3:~# poweroff
Broadcast message from root@odroidxu3
(/dev/ttySAC2) at 13:08 ...
The system is going down for power off NOW!
root@odroidxu3:~# wait-for-state stop/waiting
* Stopping rsync daemon rsync [ OK ]
* Stopping RDP Session manager [ OK ]
* Stopping NTP server ntpd [ OK ]
* Asking all remaining processes to terminate...[ OK ]
* All processes ended within 1 seconds... [ OK ]
nm-dispatcher.action: Caught signal 15, shutting down...
ModemManager[2134]: warn Could not acquire the
'org.freedesktop.ModemManager1' service name
ModemManager[2134]: info ModemManager is shut down
* Unmounting temporary filesystems... [ OK ]
* Deactivating swap... [ OK ]
* Unmounting local filesystems... [ OK ]
* Will now halt
[ 209.020280] reboot: Power down
[ 209.122039] Power down failed, please power off system manually.
---
drivers/regulator/s2mps11.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index ff82811..871f7b8 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1060,6 +1060,13 @@ out:
return ret;
}
+static void s2mps11_pmic_shutdown(struct platform_device *pdev)
+{
+ struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
+
+ regmap_update_bits(iodev-regmap_pmic, S2MPS11_REG_CTRL1, 0xff, 0x00);
+}
+
static const struct platform_device_id s2mps11_pmic_id[] = {
{ s2mps11-pmic, S2MPS11X},
{ s2mps13-pmic, S2MPS13X},
@@ -1074,6 +1081,7 @@ static struct platform_driver s2mps11_pmic_driver = {
.name = s2mps11-pmic,
},
.probe = s2mps11_pmic_probe,
+ .shutdown = s2mps11_pmic_shutdown,
.id_table = s2mps11_pmic_id,
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: s2mps11: Added shutdown function to poweroff Odroid-XU3
Hi Krzysztof,
On 24 June 2015 at 13:27, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
2015-06-24 16:16 GMT+09:00 Anand Moon linux.am...@gmail.com:
Added .shutdown function to s2mps11 to help poweroff the board succefully.
s/succefully/successfully/
The device drivers set the register to turn off the PMIC.
Driver or drivers?
Signed-off-by: Anand Moon linux.am...@gmail.com
---
Changes fixes the poweroff
root@odroidxu3:~# poweroff
Broadcast message from root@odroidxu3
(/dev/ttySAC2) at 13:08 ...
The system is going down for power off NOW!
root@odroidxu3:~# wait-for-state stop/waiting
* Stopping rsync daemon rsync [
OK ]
* Stopping RDP Session manager [
OK ]
* Stopping NTP server ntpd [
OK ]
* Asking all remaining processes to terminate...[
OK ]
* All processes ended within 1 seconds... [
OK ]
nm-dispatcher.action: Caught signal 15, shutting down...
ModemManager[2134]: warn Could not acquire the
'org.freedesktop.ModemManager1' service name
ModemManager[2134]: info ModemManager is shut down
* Unmounting temporary filesystems... [
OK ]
* Deactivating swap... [
OK ]
* Unmounting local filesystems... [
OK ]
* Will now halt
[ 209.020280] reboot: Power down
[ 209.122039] Power down failed, please power off system manually.
---
drivers/regulator/s2mps11.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index ff82811..871f7b8 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1060,6 +1060,13 @@ out:
return ret;
}
+static void s2mps11_pmic_shutdown(struct platform_device *pdev)
+{
+ struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
+
+ regmap_update_bits(iodev-regmap_pmic, S2MPS11_REG_CTRL1, 0xff,
0x00);
This looks odd to me and interesting in the same time...
1. Why clearing all of the fields from the register? Don't you want to
clear only one of it?
I have followed what the hardkernel source code point at this point.
I will look into which bit need to clear/set to power off successful.
2. What exactly you want to do here? What is expected behaviour?
When you power off the board dose not power off cleanly.
[ 209.122039] Power down failed, please power off system manually.
After this changes Its power off the board. Leaving the board with
solid red led blowing.
3. How this relates to PWRHOLD coming from AP to the PMIC?
No Idea right now about this right now. but will update you it I have
some thing.
4. Why this is needed only for this driver and only for this board (Odroid
XU3)?
Yes It could be generic not specific for the Odroid XU3 will correct
in next patch.
-Anand Moon
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos4412: Audio dies after one day on kernel 4.0
Hi Krzysztof On 23 June 2015 at 05:27, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 23.06.2015 01:00, Anand Moon wrote: Hi Krzysztof On 13 June 2015 at 13:45, Krzysztof Kozlowski k.kozlow...@samsung.com mailto:k.kozlow...@samsung.com wrote: 2015-06-13 14:47 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com mailto:k.kozlow...@samsung.com: W dniu 13.06.2015 o 06:48, gabr...@unseen.is mailto:gabr...@unseen.is pisze: On 06/10/2015 10:22 AM, Krzysztof Kozlowski wrote: Gabriel, I sent a patch which should fix the issue. Could you give it a try? Of course don't revert the other patches and don't use other workarounds. Just apply the patch on clean (vanilla would be the best) kernel. [RFT PATCH] dmaengine: Fix choppy sound because of unimplemented resume hi krzysztof, thanks a lot for your work. having only that patch applied unfortunately brought back the problem after something more than one day. the sound became choppy/noisy again. I will now compile the -next kernel and give it a try. Thanks, I'll try to reproduce the issue on my Odroid. Can you share more details how to reproduce it? The audio must play continuously or just from time to time but the board must be turned on for more than one day? I bought some audio cables and successfully reproduced similar issue (choppy sound) on Odroid XU3-Lite. On current linux-next (next-20150612) the sound is awful (choppy) after few seconds of play. For example first four of: $ aplay /usr/share/sounds/alsa/Front_Right.wav work fine. But then it just gets worse and underruns are reported: $ Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono $ underrun!!! (at least 0.095 ms long) Reverting the commit aee4d1fac887 (dmaengine: pl330: improve pl330_tx_status() function) fixes this issue so this is not related to missing resume function. At least this particular issue on my Odroid is not related to missing resume but I did not try to play sound for 24 hours. My fix does not solve this. Probably cc-stable and fixes tags should be dropped. Anyway I'll try to investigate it more. If anyone has any ideas, please share. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I gave it a try by enabling following config flags. CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_USB_AUDIO=m I am able to play mp3 songs on Odroid-XU3 boards on vlc. Could you give it a try. What do you mean? Which patch are you talking about? Are you aware that I tried to fix this two times? I already tested the latest fix on Odroid XU3 - which I mentioned in commit. However it would be nice to get confirmation for fixing original bug report (that specific conditions on that board which Gabriel reported). Best regards, Krzysztof Looks like I missed the fix. Or I overlooked it. sorry for the noise. -Anand Moon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
[PATCH] ARM: dts: exynos5422-odroidxu3: Add ramp delay for regulators
Adds ramp delay for the vdd_ldo9, vdd_ldo13, vdd_ldo15 and vdd_sd regulator. Changes removes warning ramp_delay not set for all the above regulator. Signed-off-by: Anand Moon linux.am...@gmail.com --- Changes based on https://github.com/krzk/linux.git branch dt-for-next Console message: [3.756440] vdd_ldo9: ramp_delay not set [3.767731] vdd_ldo13: ramp_delay not set [3.775260] vdd_ldo15: ramp_delay not set [3.786269] vdd_sd: ramp_delay not set --- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi index 1565667..7c97740 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi @@ -218,6 +218,8 @@ regulator-name = vdd_ldo9; regulator-min-microvolt = 300; regulator-max-microvolt = 300; + regulator-enable-ramp-delay = 200; + regulator-ramp-delay = 8000; regulator-always-on; }; @@ -246,6 +248,8 @@ regulator-name = vdd_ldo13; regulator-min-microvolt = 280; regulator-max-microvolt = 280; + regulator-enable-ramp-delay = 200; + regulator-ramp-delay = 8000; regulator-always-on; }; @@ -253,6 +257,8 @@ regulator-name = vdd_ldo15; regulator-min-microvolt = 310; regulator-max-microvolt = 310; + regulator-enable-ramp-delay = 200; + regulator-ramp-delay = 8000; regulator-always-on; }; @@ -274,6 +280,8 @@ regulator-name = vdd_sd; regulator-min-microvolt = 280; regulator-max-microvolt = 280; + regulator-enable-ramp-delay = 200; + regulator-ramp-delay = 8000; regulator-always-on; }; -- 2.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
[PATCHv6 1/4] ARM: dts: exynos5422-odroidxu3: Add pwm-fan node
Add pwm-fan node to the Odroid-XU3 board.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index deb8d78..a2f9941 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -107,6 +107,15 @@
clocks = i2s0 CLK_I2S_CDCLK;
};
};
+
+ fan0: pwm-fan {
+ compatible = pwm-fan;
+ pwms = pwm 0 20972 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-levels = 0 130 170 230;
+ };
};
clock_audss {
@@ -461,6 +470,7 @@
*/
pinctrl-0 = pwm0_out pwm1_out pwm2_out pwm3_out;
pinctrl-names = default;
+ samsung,pwm-outputs = 0;
status = okay;
};
--
2.4.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
[PATCHv6 3/4] ARM: dts: exynos5422-odroidxu3: Define default thermal-zones
Trip points corresponding to the one defined in the exynos_tmu_data.c
for Exynos5422 have been included so define thermal-zones attribute.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5 : Rename exynos5-cpu-thermal.dtsi to exynos5422-cpu-thermal.dtsi
as this file belongs to exynos5422 boards
---
arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
new file mode 100644
index 000..c73393a
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Device tree sources for Exynos5422 thermal zone
+ *
+ * Copyright (c) 2015 Lukasz Majewski l.majew...@samsung.com
+ * Anand Moon linux.am...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+/ {
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+ thermal-sensors = tmu_cpu0 0;
+ polling-delay-passive = 0;
+ polling-delay = 0;
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = 5; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = 6; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = 7; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_crit0: cpu-crit-0 {
+ temperature = 12; /* millicelsius
*/
+ hysteresis = 0; /* millicelsius */
+ type = critical;
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = cpu_alert0;
+cooling-device = fan0 0 1;
+ };
+ map1 {
+trip = cpu_alert1;
+cooling-device = fan0 1 2;
+ };
+ map2 {
+trip = cpu_alert2;
+cooling-device = fan0 2 3;
+ };
+ };
+ };
+ };
+};
--
2.4.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
[PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
This changes enables TMU IP block on the Exynos5422 Odroid-XU3
device.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5: Use LDO7 regulator instead of LD010.
The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
I think the schematics are missing some of details but it can be deducted that:
1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
S2MPS11 PMIC.
3. I confirmed with the Exynos5422 datasheet that these
VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
So the LDO7 it is... but before using it there is a caveat. The LDO7
is also connected to VDD of MIPI, HDMI and few more. So when you use
this regulator in TMU it may be turned off by TMU driver (e.g. during
unbind). In such case these other blocks also should be tested and
checked whether they take this regulator and enable it.
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25 ++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index a2f9941..b6570fc 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -474,6 +474,31 @@
status = okay;
};
+tmu_cpu0 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu1 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu2 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu3 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_gpu {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
rtc {
status = okay;
clocks = clock CLK_RTC, s2mps11_osc S2MPS11_CLK_AP;
--
2.4.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
[PATCHv6 4/4] ARM: dts: exynos5422-odroidxu3: Enable thermal-zones
Include exynos5422-cpu-thermal.dtsi to enable thermal_zone support.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index b6570fc..1565667 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include dt-bindings/gpio/gpio.h
#include dt-bindings/sound/samsung-i2s.h
#include exynos5800.dtsi
+#include exynos5422-cpu-thermal.dtsi
/ {
memory {
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
hi Krzysztof
On 15 June 2015 at 05:41, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
On 14.06.2015 19:24, Anand Moon wrote:
This changes enables TMU IP block on the Exynos5422 Odroid-XU3
device.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
This does not look right.
You put this Tested-by since beginning of this patchset (v1) but first
it was LDO10. Then you proposed LDO18 and now you use LDO7 from my
suggestion. Which of this was tested by Markus because I cannot find his
emails with it on LKML?
Markus Reichl tested the earlier version with LDO10.
Commit logs got carry forward by mistake.
-Anand Moon
Krzysztof
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5: Use LDO7 regulator instead of LD010.
The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
I think the schematics are missing some of details but it can be deducted
that:
1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
S2MPS11 PMIC.
3. I confirmed with the Exynos5422 datasheet that these
VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
So the LDO7 it is... but before using it there is a caveat. The LDO7
is also connected to VDD of MIPI, HDMI and few more. So when you use
this regulator in TMU it may be turned off by TMU driver (e.g. during
unbind). In such case these other blocks also should be tested and
checked whether they take this regulator and enable it.
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
++
1 file changed, 25 insertions(+)
--
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
[PATCHv7 3/4] ARM: dts: exynos5422-odroidxu3: Define default thermal-zones
Trip points corresponding to the one defined in the exynos_tmu_data.c
for Exynos5422 have been included so define thermal-zones attribute.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
new file mode 100644
index 000..2b289d7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Device tree sources for Exynos5422 thermal zone
+ *
+ * Copyright (c) 2015 Lukasz Majewski l.majew...@samsung.com
+ * Anand Moon linux.am...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+/ {
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+ thermal-sensors = tmu_cpu0 0;
+ polling-delay-passive = 0;
+ polling-delay = 0;
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = 5; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = 6; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = 7; /* millicelsius
*/
+ hysteresis = 5000; /* millicelsius */
+ type = active;
+ };
+ cpu_crit0: cpu-crit-0 {
+ temperature = 12; /* millicelsius
*/
+ hysteresis = 0; /* millicelsius */
+ type = critical;
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = cpu_alert0;
+cooling-device = fan0 0 1;
+ };
+ map1 {
+trip = cpu_alert1;
+cooling-device = fan0 1 2;
+ };
+ map2 {
+trip = cpu_alert2;
+cooling-device = fan0 2 3;
+ };
+ };
+ };
+ };
+};
--
2.4.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
[PATCHv7 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
This changes enables TMU IP block on the Exynos5422 Odroid-XU3
device.
Signed-off-by: Anand Moon linux.am...@gmail.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5 and v6: Use LDO7 regulator instead of LDO10 regulator to
control TMU.
Fixed the commit log.
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25 ++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 17e6a9a..96d894e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -474,6 +474,31 @@
status = okay;
};
+tmu_cpu0 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu1 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu2 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu3 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_gpu {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
rtc {
status = okay;
clocks = clock CLK_RTC, s2mps11_osc S2MPS11_CLK_AP;
--
2.4.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
[PATCHv7 1/4] ARM: dts: exynos5422-odroidxu3: Add pwm-fan node
Add pwm-fan node to the Odroid-XU3 board.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 8adf455..17e6a9a 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -107,6 +107,15 @@
clocks = i2s0 CLK_I2S_CDCLK;
};
};
+
+ fan0: pwm-fan {
+ compatible = pwm-fan;
+ pwms = pwm 0 20972 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-levels = 0 130 170 230;
+ };
};
clock_audss {
@@ -461,6 +470,7 @@
*/
pinctrl-0 = pwm0_out pwm1_out pwm2_out pwm3_out;
pinctrl-names = default;
+ samsung,pwm-outputs = 0;
status = okay;
};
--
2.4.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
[PATCHv7 4/4] ARM: dts: exynos5422-odroidxu3: Enable thermal-zones
Include exynos5422-cpu-thermal.dtsi to enable thermal_zone support.
Signed-off-by: Anand Moon linux.am...@gmail.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 96d894e..2b65932 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include dt-bindings/gpio/gpio.h
#include dt-bindings/sound/samsung-i2s.h
#include exynos5800.dtsi
+#include exynos5422-cpu-thermal.dtsi
/ {
memory {
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
hi Krzysztof
On 15 June 2015 at 05:21, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
On 14.06.2015 19:24, Anand Moon wrote:
This changes enables TMU IP block on the Exynos5422 Odroid-XU3
device.
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Markus Reichl m.rei...@fivetechno.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5: Use LDO7 regulator instead of LD010.
The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
I think the schematics are missing some of details but it can be deducted
that:
1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
S2MPS11 PMIC.
3. I confirmed with the Exynos5422 datasheet that these
VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
So the LDO7 it is... but before using it there is a caveat. The LDO7
is also connected to VDD of MIPI, HDMI and few more. So when you use
this regulator in TMU it may be turned off by TMU driver (e.g. during
unbind). In such case these other blocks also should be tested and
checked whether they take this regulator and enable it.
Why did you took my email and pasted it here?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/343702.html
It is written now in first person so it pretends that you wrote this.
You are actually doing this for second time - taking my
reply and putting into commit message or changelog. Why?
And where is proper changelog?
Sorry: My intention was never to take credit on what your guidance and
your pointers.
I value ever input of your and try not to repeat the mistakes I am repeating.
I will send updated version soon.
-Anand Moon
Krzysztof
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index a2f9941..b6570fc 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -474,6 +474,31 @@
status = okay;
};
+tmu_cpu0 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu1 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu2 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_cpu3 {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
+tmu_gpu {
+ vtmu-supply = ldo7_reg;
+ status = okay;
+};
+
rtc {
status = okay;
clocks = clock CLK_RTC, s2mps11_osc S2MPS11_CLK_AP;
--
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: [PATCHv5 1/5] ARM: dts: exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board
hi Krzysztof, I will send an update version soon. -Anand Moon On 14 June 2015 at 11:01, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: 2015-05-13 16:46 GMT+09:00 Anand Moon linux.am...@gmail.com: Hi Krzysztof, Will make the changes. Thanks for the review. Hi Anand, Do you plan to continue working on this patchset? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
Hi, On 9 June 2015 at 05:20, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 08.06.2015 02:03, Anand Moon wrote: Enable CONFIG_SND_SOC_ODROIDX2 and CONFIG_SND_SIMPLE_CARD to enable sound on Odroid-XU3 board. Below is the output of boot log. [6.021550] max98090 5-0010: MAX98090 REVID=0x43 [6.025506] random: nonblocking pool is initialized [6.047297] asoc-simple-card sound: HiFi - 383.i2s mapping ok [6.068392] s5m-rtc s2mps14-rtc: setting system clock to 2015-06-07 12:51:06 UTC (1433681466) [6.123650] ALSA device list: [6.135203] #0: Odroid-XU3 Answering the question why and what is device would be sufficient. You answered the first question (enable sound) so you can just add second part - using the max98090 audio codec. This whole dmesg does not bring any benefits here, especially the irrelevant items (like random or RTC). Could you trim the commit message? Beside of that it looks fine however you marked this as v2: 1. I cannot find v1 on Google. The title was the same? 2. Where is changelog? Best regards, Krzysztof Look like I an doom to make mistake. This series of patch got PATCHv2 tag, It's my mistake. not maintain the version of the patch. I will resend it. -Anand Moon -- 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: [PATCHv2 2/2] ARM: exynos_defconfig: Enable CONFIG_LEDS_PWM for Odroid-XU3
Hi On 9 June 2015 at 05:26, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 08.06.2015 02:03, Anand Moon wrote: Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for Odroid-XU3 board. I am a little confused. This is v2. I found version 3, a little different: http://www.spinics.net/lists/linux-samsung-soc/msg44406.html (which Where is the changelog? Which one is newer? Should we drop the v3? While at it, can you add information WHY do you want to enable LEDS? Best regards, Krzysztof Look like I an doom to make mistake. With the introduction of this http://www.spinics.net/lists/linux-samsung-soc/msg44481.html We need to enable CONFIG_LEDS_PWM to make it working. So please drop the v3 patch. -Anand Moon -- 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
[PATCHv2] ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
Enable CONFIG_SND_SOC_ODROIDX2 and CONFIG_SND_SIMPLE_CARD to enable sound on Odroid-XU3 board using the max98090 audio codec. Signed-off-by: Anand Moon linux.am...@gmail.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com --- Changes v2: Fixed the commit log. Signed-off-by: Anand Moon linux.am...@gmail.com --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..1b7253b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -144,6 +144,8 @@ CONFIG_SND=y CONFIG_SND_SOC=y CONFIG_SND_SOC_SAMSUNG=y CONFIG_SND_SOC_SNOW=y +CONFIG_SND_SOC_ODROIDX2=y +CONFIG_SND_SIMPLE_CARD=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_XHCI_HCD=y -- 2.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators
On 8 June 2015 at 10:58, Vivek Gautam gautam.vi...@samsung.com wrote: Hi, On Monday, June 08, 2015 10:44 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: my apologies for being late in replying to this thread. 2015-06-08 13:21 GMT+09:00 Anand Moon linux.am...@gmail.com: Hi Krzysztof , On 8 June 2015 at 07:40, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 07.06.2015 22:20, Anand Moon wrote: Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos. With the patches for regulators' nodes merged in 3.15: c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators. Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers. So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Anand Moon linux.am...@gmail.com Cc: Jingoo Han jg1@samsung.com Cc: Alan Stern st...@rowland.harvard.edu --- Initial version of this patch was part of following series, though they are not dependent on each other, resubmitting after rebasing. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html So you just took Vivek's patch along with all the credits... That is not how we usually do this. I would expect that rebasing a patch won't change the author unless this is fine with Vivek. Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it. http://www.spinics.net/lists/linux-samsung-soc/msg44136.html I don't get it. The patch you are referring to has a proper From field. So please use it as an example. I don't want to take any credit out of it. I just re-base on the new kernel. Perhaps, you would have maintained the authorship ! I could not test this patch as it meant for exynos5440 boards. Are you sure? I think the driver is used on almost all of Exynos SoCs (Exynos4, Exynos5250, Exynos542x). That's correct, as pointed by Krzysztof Kozlowski, the driver is same for Exynos4 and Exynos5 series of SoCs. Untested code should not go to the kernel. Additionally you should mark it as not-tested. Marking such patch as non-tested could help you finding some independent tests (tests performed by someone else). To summarize my point of view: 1. Unless Vivek's says otherwise, please give him the credits with proper from field. 2. Issues mentioned in previous mail should be addressed (missing IS_ERR(), how disabling the regulator during suspend affects waking up). 3. The patchset must be tested, even after rebasing. Unfortunately, I got busy with a different project and lost track of the patches posted upstream. If it's not too late I can post a rebased version of the patch with previous review comments addressed. Best regards, Krzysztof Hi All, I have learned my lesson not to interfere in others work. It will never happen from my side again. Please accept my apology. -Anand Moon -- 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
[PATCHv2 2/2] ARM: exynos_defconfig: Enable CONFIG_LEDS_PWM for Odroid-XU3
Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for Odroid-XU3 board. Signed-off-by: Anand Moon linux.am...@gmail.com --- arch/arm/configs/exynos_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1b7253b..2bbdf80 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -165,6 +165,12 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=m +CONFIG_LEDS_PWM=m +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=m +CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.4.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
[PATCHv2 1/2] ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
Enable CONFIG_SND_SOC_ODROIDX2 and CONFIG_SND_SIMPLE_CARD to enable sound on Odroid-XU3 board. Below is the output of boot log. [6.021550] max98090 5-0010: MAX98090 REVID=0x43 [6.025506] random: nonblocking pool is initialized [6.047297] asoc-simple-card sound: HiFi - 383.i2s mapping ok [6.068392] s5m-rtc s2mps14-rtc: setting system clock to 2015-06-07 12:51:06 UTC (1433681466) [6.123650] ALSA device list: [6.135203] #0: Odroid-XU3 Signed-off-by: Anand Moon linux.am...@gmail.com --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..1b7253b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -144,6 +144,8 @@ CONFIG_SND=y CONFIG_SND_SOC=y CONFIG_SND_SOC_SAMSUNG=y CONFIG_SND_SOC_SNOW=y +CONFIG_SND_SOC_ODROIDX2=y +CONFIG_SND_SIMPLE_CARD=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_XHCI_HCD=y -- 2.4.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
[RESEND] ARM: dts: odroidxu3: Enable USB3 regulators
Enable regulator for usbdrd3_0 and usbdrd3_1.
Looking at the schematic pin diagram for MAX77802
USB3_0 and USB3_1 is regulated by LDO9 and LD011.
Fix the boot message of failed.
[3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device
tree
[3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in
node /usb@1200 failed
[3.503568] usb@1200 supply vdd33 not found, using dummy regulator
[3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device
tree
[3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in
node /usb@1200 failed
[3.509181] usb@1200 supply vdd10 not found, using dummy regulator
[3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device
tree
[3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in
node /usb@1240 failed
[3.917578] usb@1240 supply vdd33 not found, using dummy regulator
[3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device
tree
[3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in
node /usb@1240 failed
Signed-off-by: Anand Moon linux.am...@gmail.com
Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 8adf455..deb8d78 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -477,3 +477,13 @@
usbdrd_dwc3_1 {
dr_mode = otg;
};
+
+usbdrd3_0 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+};
+
+usbdrd3_1 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+};
--
2.4.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
[RESEND 2/2] usb: ohci-exynos: Make provision for vdd regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the exynos systems turn on only minimal number of regulators.
Until now, the VDD regulator supplies were either turned on
by the bootloader, or the regulators were enabled by default
in the kernel, so that the controller drivers did not need to
care about turning on these regulators on their own.
This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary
VDD regulators (if available, unless there are direct VDD rails),
and enable them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Anand Moon linux.am...@gmail.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Initial version of this patch was part of following series, though
they are not dependent on each other, resubmitting after rebasing.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266419.html
---
.../devicetree/bindings/usb/exynos-usb.txt | 4 ++
drivers/usb/host/ohci-exynos.c | 55 +-
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 776fa03..3883baa 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -63,6 +63,10 @@ Required properties:
port 2 is HSIC phy1
- phys: from the *Generic PHY* bindings, specifying phy used by port.
+Optional properties:
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
+
Example:
usb@1212 {
compatible = samsung,exynos4210-ohci;
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 2cd105b..ce757ea 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/phy/phy.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -36,6 +37,8 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
struct exynos_ohci_hcd {
struct clk *clk;
struct phy *phy[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static int exynos_ohci_get_phy(struct device *dev,
@@ -139,7 +142,27 @@ static int exynos_ohci_probe(struct platform_device *pdev)
err = exynos_ohci_get_phy(pdev-dev, exynos_ohci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ohci-vdd33 = devm_regulator_get_optional(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ohci-vdd33)) {
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get_optional(pdev-dev, vdd10);
+ if (!IS_ERR(exynos_ohci-vdd10)) {
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 1.0V Vdd supply\n);
+ goto fail_regulator2;
+ }
+ }
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -191,6 +214,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -206,6 +233,11 @@ static int exynos_ohci_remove(struct platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ if (!IS_ERR(exynos_ohci-vdd33))
+ regulator_disable(exynos_ohci-vdd33);
+ if (!IS_ERR(exynos_ohci-vdd10))
+ regulator_disable(exynos_ohci-vdd10);
+
usb_put_hcd(hcd);
return 0;
@@ -234,6 +266,11 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ if (!IS_ERR(exynos_ohci-vdd33))
+ regulator_disable(exynos_ohci-vdd33);
+ if (!IS_ERR(exynos_ohci-vdd10))
+ regulator_disable(exynos_ohci-vdd10);
+
return 0;
}
@@ -243,6 +280,22 @@ static int exynos_ohci_resume(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int ret;
+ if (!IS_ERR(exynos_ohci
[RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the exynos systems turn on only minimal number of regulators.
Until now, the VDD regulator supplies were either turned on
by the bootloader, or the regulators were enabled by default
in the kernel, so that the controller drivers did not need to
care about turning on these regulators on their own.
This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary
VDD regulators (if available, unless there are direct VDD rails),
and enable them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Anand Moon linux.am...@gmail.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Initial version of this patch was part of following series, though
they are not dependent on each other, resubmitting after rebasing.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html
---
.../devicetree/bindings/usb/exynos-usb.txt | 2 +
drivers/usb/host/ehci-exynos.c | 55 +-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 9b4dbe3..776fa03 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,6 +23,8 @@ Required properties:
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
Example:
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index df538fd..4f8f9d2 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,6 +21,7 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -45,6 +46,8 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
struct phy *phy[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device *pdev)
err = exynos_ehci_get_phy(pdev-dev, exynos_ehci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci-vdd33 = devm_regulator_get_optional(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get_optional(pdev-dev, vdd10);
+ if (!IS_ERR(exynos_ehci-vdd10)) {
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 1.0V Vdd supply\n);
+ goto fail_regulator2;
+ }
+ }
skip_phy:
@@ -231,6 +254,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device *pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ if (!IS_ERR(exynos_ehci-vdd33))
+ regulator_disable(exynos_ehci-vdd33);
+ if (!IS_ERR(exynos_ehci-vdd10))
+ regulator_disable(exynos_ehci-vdd10);
+
usb_put_hcd(hcd);
return 0;
@@ -268,6 +300,11 @@ static int exynos_ehci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ehci-clk);
+ if (!IS_ERR(exynos_ehci-vdd33))
+ regulator_disable(exynos_ehci-vdd33);
+ if (!IS_ERR(exynos_ehci-vdd10))
+ regulator_disable(exynos_ehci-vdd10);
+
return rc;
}
@@ -277,6 +314,22 @@ static int exynos_ehci_resume(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int ret;
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ ret = regulator_enable(exynos_ehci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed
Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators
Hi Krzysztof ,
On 8 June 2015 at 07:40, Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
On 07.06.2015 22:20, Anand Moon wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With the patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the exynos systems turn on only minimal number of regulators.
Until now, the VDD regulator supplies were either turned on
by the bootloader, or the regulators were enabled by default
in the kernel, so that the controller drivers did not need to
care about turning on these regulators on their own.
This was rather bad about these controller drivers.
So ensuring now that the controller driver requests the necessary
VDD regulators (if available, unless there are direct VDD rails),
and enable them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Anand Moon linux.am...@gmail.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
Initial version of this patch was part of following series, though
they are not dependent on each other, resubmitting after rebasing.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html
So you just took Vivek's patch along with all the credits... That is not
how we usually do this.
I would expect that rebasing a patch won't change the author unless this
is fine with Vivek.
Sorry If I have done some mistake on my part.
I just looked at below mail chain. Before I send it.
http://www.spinics.net/lists/linux-samsung-soc/msg44136.html
I don't want to take any credit out of it. I just re-base on the new kernel.
I could not test this patch as it meant for exynos5440 boards.
-Anand Moon
---
.../devicetree/bindings/usb/exynos-usb.txt | 2 +
drivers/usb/host/ehci-exynos.c | 55
+-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 9b4dbe3..776fa03 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,6 +23,8 @@ Required properties:
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
needs to be pulled up for the bus to be powered.
+ - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
+ - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
Example:
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index df538fd..4f8f9d2 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,6 +21,7 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -45,6 +46,8 @@ static struct hc_driver __read_mostly
exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
struct phy *phy[PHY_NUMBER];
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)-priv)
@@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
err = exynos_ehci_get_phy(pdev-dev, exynos_ehci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci-vdd33 = devm_regulator_get_optional(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get_optional(pdev-dev, vdd10);
+ if (!IS_ERR(exynos_ehci-vdd10)) {
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 1.0V Vdd supply\n);
+ goto fail_regulator2;
+ }
+ }
skip_phy:
@@ -231,6 +254,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
if (!IS_ERR()).
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ if (!IS_ERR(exynos_ehci-vdd33))
+ regulator_disable(exynos_ehci-vdd33);
+ if (!IS_ERR(exynos_ehci-vdd10))
+ regulator_disable(exynos_ehci-vdd10);
+
usb_put_hcd(hcd
Re: [PATCH] ARM: dts: odroidxu3: Enable USB3 regulators
On 30 May 2015 at 19:23, Anand Moon linux.am...@gmail.com wrote: On 28 May 2015 at 14:49, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 28.05.2015 17:58, Anand Moon wrote: Enable regulator for usbdrd3_0 and usbdrd3_1 From the schematic pin diagram USB3_0 and USB3_1 is regulated by LDO9 and LD011. Please reformat statement above to proper sentence(s) without before From. Fix the boot message of failed. [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device tree [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in node /usb@1200 failed [3.503568] usb@1200 supply vdd33 not found, using dummy regulator [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device tree [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in node /usb@1200 failed [3.509181] usb@1200 supply vdd10 not found, using dummy regulator [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device tree [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in node /usb@1240 failed [3.917578] usb@1240 supply vdd33 not found, using dummy regulator [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device tree [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in node /usb@1240 failed --- This patch is based on Krzysztof github branch work-next/odroid-xu3-s2mps11-irq --- I mentioned this already on previous postings. Let's make an exercise. Please: 1. Save your email as mbox format (from mailer). 2. Go to a GIT repo with kernel and checkout base branch. 3. git am 0001-the-name-of-file.mbox 4. git show Do you see the signed-off-by in commit? The patch itself looks good, thanks for fixing this. Just please fix the issues with commit message. By the way: 1. The always-on from LDO9 could be probably removed if the ehci-exynos driver had regulator consumer implemented. 2. The Documentation/devicetree/bindings/usb/exynos-usb.txt (or dwc.txt) should proably mention the vdd-supply property. Hi Krzysztof, https://patchwork.kernel.org/patch/4420061/ https://patchwork.kernel.org/patch/4420071/ These patch are missing for this changes to make it work correctly. Can you share you thought on this. -Anand Moon Best regards, Krzysztof Hi Krzysztof Do you want me to resend this. Along with above. https://patchwork.kernel.org/patch/4420061/ https://patchwork.kernel.org/patch/4420071/ -Anand Moon -- 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: [PATCHv3] ARM: dts: odroidxu3: Enable USB3 regulators
On 7 June 2015 at 08:02, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: W dniu 29.05.2015 o 23:30, Anand Moon pisze: Enable regulator for usbdrd3_0 and usbdrd3_1. Looking at the schematic pin diagram for MAX77802 USB3_0 and USB3_1 is regulated by LDO9 and LD011. Fix the boot message of failed. [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device tree [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in node /usb@1200 failed [3.503568] usb@1200 supply vdd33 not found, using dummy regulator [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device tree [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in node /usb@1200 failed [3.509181] usb@1200 supply vdd10 not found, using dummy regulator [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device tree [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in node /usb@1240 failed [3.917578] usb@1240 supply vdd33 not found, using dummy regulator [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device tree [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in node /usb@1240 failed Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Anand Moon linux.am...@gmail.com The patch no longer applies because of creation of common Odroid DTSI. Can you rebase it on Kukjin's for-next? Best regards, Krzysztof Hi Krzysztof Ok will do this. -Anand Moon -- 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
