Re: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

[Kevin Hilman]

Hi Krzystof,

Krzysztof Kozlowski  writes:

> Introduction
> 
> This patchset tries to fix probing of usb3503 on Arndale board
> if the Samsung PHY driver is probed later (or built as a module).
>
> *The patchset was not tested on Arndale board.*
> I don't have that board. Please test it and say if the usb3503 deferred probe
> works fine and the issue is solved.

FYI... I built this series on top of  next-20151009 and using
exynos_defconfig.  I booted it on my arndale, and I still don't see the
networking come up.  Full boot log attached.

Kevin

Connected to arndale console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(arndale console)> hardreset
(user:khilman) Reboot arndale


U-Boot 2013.01.-rc1-dirty (Jun 28 2013 - 07:14:48) for ARNDALE5250

CPU:Exynos5250@1000MHz

Board:  for ARNDALE5250
I2C:   ready
DRAM:  2 GiB
WARNING: Caches not enabled

Checking Boot Mode ... SDMMC
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1, EXYNOS DWMMC: 2
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot: 

# PYBOOT: u-boot: taking control.
 3  0 
ARNDALE5250 # 
ARNDALE5250 # version
version

U-Boot 2013.01.-rc1-dirty (Jun 28 2013 - 07:14:48) for ARNDALE5250
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.2-1ubuntu1) 4.7.2
GNU ld (GNU Binutils for Ubuntu) 2.22.90.20120919
ARNDALE5250 # setenv bootargs console=tty0 console=ttySAC2,115200n8 rw 
root=/dev/mmcblk1p3 rootwait rootfstype=ext4
setenv bootargs console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 
rootwait rootfstype=ext4
ARNDALE5250 # setenv netargs 'setenv bootargs ${bootargs} 
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:::none:192.168.1.3"'
setenv netargs 'setenv bootargs ${bootargs} 
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:::none:192.168.1.3"'
ARNDALE5250 # if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
ARNDALE5250 # if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
ARNDALE5250 # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
ARNDALE5250 #dhcp
 dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
DHCP client bound to address 192.168.1.167
ARNDALE5250 #setenv serverip 192.168.1.2
 setenv serverip 192.168.1.2
ARNDALE5250 # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
ARNDALE5250 # tftp 0x4100 192.168.1.2:tmp/arndale-o13inu/zImage
tftp 0x4100 192.168.1.2:tmp/arndale-o13inu/zImage
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/zImage'.
Load address: 0x4100
Loading: *#
 #
 #
 #
 ###
done
Bytes transferred = 4209056 (4039a0 hex)
ARNDALE5250 # tftp 0x4200 
192.168.1.2:tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz
tftp 0x4200 192.168.1.2:tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz'.
Load address: 0x4200
Loading: *#
 #
 #
 #
 #
 
done
Bytes transferred = 5001043 (4c4f53 hex)
ARNDALE5250 #tftp 0x41f0 192.168.1.2:tmp/arndale-o13inu/tmp_2g_yE.dtb
 tftp 0x41f0 192.168.1.2:tmp/arndale-o13inu/tmp_2g_yE.dtb
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/tmp_2g_yE.dtb'.
Load address: 0x41f0
Loading: *###
done
Bytes transferred = 42207 (a4df hex)
ARNDALE5250 # printenv bootargs
printenv bootargs
bootargs=console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 rootwait 
rootfstype=ext4 
ip=192.168.1.167:192.168.1.2:192.168.1.254:255.255.255.0:::none:192.168.1.3
ARNDALE5250 #bootz 

Re: [PATCH] ARM: EXYNOS: reset KFC cores when cpu is up

[Kevin Hilman]

Abhilash Kesavan  writes:

> On Tue, Sep 1, 2015 at 5:51 AM, Krzysztof Kozlowski
>  wrote:
>> On 01.09.2015 07:46, Javier Martinez Canillas wrote:

[...]

>>> I posted a similar patch that instead disabling CCI for the XU3 board,
>>> it disables in exynos5422-odroidxu3-common.dtsi since all Exynos5422
>>> Odroid boards have the same broken firmware and so the same issue:
>>>
>>> https://lkml.org/lkml/2015/8/29/59

OK, that makes more sense.  Thanks.

>>> Krzysztof tested it on an Odroid XU3 Lite and reported that disabling
>>> CCI caused some CPUs to fail to boot even with $subject applied:
>>>
>>> https://lkml.org/lkml/2015/8/29/65
>>>
>>> Did you succeed booting all CPUs with CONFIG_ARM_BIG_LITTLE_CPUIDLE
>>> enabled and CCI disabled in the the Odroid XU3 DTS?

I thought so, but re-testing I'm seein the same results as Krzysztof:

>> Indeed. On Odroid XU3 Chanho's patch gives me 8 CPUs up. Disabling CCI
>> causes fails on CPU{5,6,7} (Cortex-A15).
>
> Chanho's patch is for the exynos mcpm back-end. However, when we
> disable CCI the mcpm code is bypassed and we default to the code in
> exynos' platsmp.c/firmware.c. If the A7s were failing to boot-up then
> the reason could have been that Chanho's workaround was not being
> executed after applying the CCI disablement patch.
> According to the comments the A15s are not booting and so the
> exynos_boot_secondary function needs to be checked further.

Thanks for the explanation.  That makes sense.  $SUBJECT fix should
be made so it works for both scenarios.

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

Re: [PATCH] ARM: EXYNOS: reset KFC cores when cpu is up

[Kevin Hilman]

Chanho Park <parkc...@gmail.com> writes:

> 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(kingfisher core).
> Some of the exynos5420 boards and all of the exynos5422 boards will be
> required 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.
>
> Changes since RFC[3]:
> - 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
>
> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
> [2]:https://patchwork.kernel.org/patch/6782891/
> [3]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/356610.html
>
> 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 <parkc...@gmail.com>

> ---
>  arch/arm/mach-exynos/mcpm-exynos.c | 18 +-
>  arch/arm/mach-exynos/regs-pmu.h|  6 ++
>  2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 9bdf547..5b69ed2 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,22 @@ 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 eagle is 0 and the
> +  * kfc is 1. When the system was booted from the kfc core,
> +  * they should be reset */

minor: fix multi-line comment style (search for 'multi-line' in
Documentation/CodingStyle)

Also minor, but personally, I prefer seeing A15/A7 instead of eagle/KFC
as those names are fading from my memory and I can't seem to remember
which one is which. :/

> + if (cluster &&
> + cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
> + while (!pmu_raw_readl(S5P_PMU_SPARE2))
> + udelay(10);
> +
> + pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
> + EXYNOS_SWRESET);
> + }
> + }
> +
>   return 0;
>  }

I tested this on top of mainline (v4.2) using exynos_defconfig (with
BL_SWITCHER disabled) and I now see all 8 CPUs booting.  Nice!

Tested-by: Kevin Hilman <khil...@linaro.org>

Also, please note that this does not fix another fundamental problem
with this board in that the firmware puts CCI into secure mode, so
linux/MCPM cannot manage it, causing hangs whenever CPUidle is enabled
(because b.L cpuidle driver tries to use MCPM, which needs to manage
CCI.)

In order for this to not hang when using CPUidle, the following patch is
also needed.

Kevin

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 78e6a502f320..7891bd05bf8e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -49,3 +49,11 @@
shunt-resistor = <1>;
};
 };
+
+/*
+ * Secure firmware prevents CCI access/usage from linux, so must be
disabled
+ * to prevent usage by MCPM.
+ */
+ {
+   status = "disabled";
+};


--
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] Documentation: ARM: EXYNOS: Describe boot loaders interface

[Kevin Hilman]

Krzysztof Kozlowski k.kozlowsk...@gmail.com writes:

 Various boot loaders for Exynos based boards use certain memory
 addresses during booting for different purposes. Mostly this is one of
 following :
 1. as a CPU boot address,
 2. for storing magic cookie related to low power mode (AFTR, sleep).

 The document, based solely on kernel source code, tries to group the
 information scattered over different files. This would help in the
 future when adding support for new SoC or when extending features
 related to low power modes.

 Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com

Very nice, thank you for taking the time to pull all of this together
into one location.

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

Re: [RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?

[Kevin Hilman]

Krzysztof Kozłowski k.kozlowsk...@gmail.com writes:

 2014-11-25 15:21 GMT+09:00 Kevin Hilman khil...@kernel.org:
 From: Kevin Hilman khil...@linaro.org

 Using the current exynos_defconfig on the exynos5422-odroid-xu3, only
 6 of 8 CPUs come online with MCPM boot.  CPU0 is an A7, CPUs 1-4 are
 A15s and CPU5-7 are the other A7s, but with the current code, CPUs 5
 and 7 do not boot:

[...]
Exynos MCPM support installed
CPU1: update cpu_capacity 1535
CPU1: thread -1, cpu 0, socket 0, mpidr 8000
CPU2: update cpu_capacity 1535
CPU2: thread -1, cpu 1, socket 0, mpidr 8001
CPU3: update cpu_capacity 1535
CPU3: thread -1, cpu 2, socket 0, mpidr 8002
CPU4: update cpu_capacity 1535
CPU4: thread -1, cpu 3, socket 0, mpidr 8003
CPU5: failed to come online
CPU6: update cpu_capacity 448
CPU6: thread -1, cpu 2, socket 1, mpidr 8102
CPU7: failed to come online
Brought up 6 CPUs
CPU: WARNING: CPU(s) started in wrong/inconsistent modes
(primary CPU mode 0x13)
CPU: This may indicate a broken bootloader or firmware.

 Thanks to a tip from Abhilash, this patch gets all 8 CPUs booting
 again, but the warning about CPUs started in inconsistent modes
 remains.  Also, not being terribly familiar with Exynos internals,
 it's not at all obvious to me why this register write (done for *all*
 secondaries) makes things work works for the 2 secondary CPUs that
 didn't come online.  It's also not obvious whether this is the right
 general fix, since it doesn't seem to be needed on other 542x or 5800
 platforms.

 I suspect the right fix is in the bootloader someplace, but not
 knowing this hardware well, I'm not sure if the fix is in u-boot
 proper, or somewhere in the binary blobs (bl1/bl2/tz) that start
 before u-boot.  The u-boot I'm using is from the hardkernel u-boot
 repo[1], and I'd welcome any suggestions to try.  I'm able to rebuild
 my own u-boot from there, but only have binaries for bl1/bl2/tz.

 [1] branch odroidxu3-v2012.07 of: https://github.com/hardkernel/u-boot.git


 Cc: Mauro Ribeiro mauro.ribe...@hardkernel.com
 Cc: Abhilash Kesavan a.kesa...@samsung.com,
 Cc: Andrew Bresticker abres...@chromium.org
 Cc: Doug Anderson diand...@chromium.org
 Cc: Nicolas Pitre nicolas.pi...@linaro.org
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
  arch/arm/mach-exynos/mcpm-exynos.c | 2 ++
  arch/arm/mach-exynos/regs-pmu.h| 1 +
  2 files changed, 3 insertions(+)

 Hi,

 +Cc Marek, Bartlomiej, Kukjin Kim,


 I would like to bring back this topic. Unfortunately I don't have
 access to source code of BL1 (or any other firmware blob) so my
 knowledge here comes mostly from experimenting and from looking at
 sources of vendor kernel for Gear 2 (Exynos3250) and SM-G900H (Galaxy
 S5, Exynos5422).

 It seems that some booting firmware (I would suspect BL1 because this
 ships Samsung to Hardkernel) uses SPARE2 as synchronization mechanism.
 For example vendor kernel, when booting little core, it waits till
 SPARE2==1 and then executes software reset for this core.

 Observations shown that BL1 for Odroid, when booting secondary little core:
 1. Expects that SPARE2 register will be initialized to 1.
 2. If it is, then it sets it to 0, proceeds further and little core boots.
 3. If it is not, then it sets it to 1 and waits. Maybe this is a
 notification to userspace - reset me please!

 Unfortunately executing software reset in that time (at point 3)
 stopped kernel from booting. No logs/dmesg and I was unable to turn on
 early printk.

 The answer why two of little cores boot is quite simple now. At
 beginning the SPARE2==0 so first little core will set it to 1 and wait
 till software reset. Kernel timeouts on this CPU bring up so it starts
 the sequence for next little core. Now the SPARE2==1 so the core boots
 fine and SPARE2 is set to 0. The last little core starts from
 SPARE2==0, sets it to 1 and waits for software reset.

 Since no one knows how this exactly works and we are stuck with BL1
 provided as is, then IMHO the patch makes sense.

 Kevin, can you refresh the patch?
 It would be nice to:
 1. set SPARE2 only for Odroid (of_machine_is_compatible()),
 2. extend the explanation.

I'd rather someone else refresh this patch who actually understands
what's going on here and could write a descriptive changelog.  I have no
claims to the authorship as Abhilash is the one who suggested this fix
in the first place.

Also, please note that 8 cores booting doesn't mean all 8 cores fully
working.  This firmware is still horribly broken for low-power modes.

Even with all 8 cores enabled, the firmware also as CCI left in secure
mode which means the kernel MCPM cannot manage CCI, and thus cannot hit
any low-power states.  If CPUidle is enabled, the kernel will hang as
soon as any MCPM state is attempted.  In order to get WFI-only CPUidle
working, I've also had to disable CCI in the DTS by appending something
like this to the board DTS file:

cci

Re: [RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?

[Kevin Hilman]

Przemyslaw Marczak p.marc...@samsung.com writes:

 On 06/15/2015 01:19 PM, Amit Kucheria wrote:
 On Mon, Jun 15, 2015 at 3:49 PM, Przemyslaw Marczak
 p.marc...@samsung.com wrote:
 Hello Krzysztof,


 On 06/14/2015 10:56 AM, Krzysztof Kozłowski wrote:

 snip

 I'm trying port the hardkernel's SPL to the mainline U-Boot at present. The
 mainline SPL is implemented for E5420 and E5800. But there are few
 differences:
 - different DRAM
 - different clocks
 - different boot core (peach-pi boots from A15)
 - bl2 signature
 - hdk's SPL uses smc calls
 ... and some more.

 This is really good news! Would this work leave CCI control to Linux
 so that we may use MCPM to manage cpu and cluster OFF?


 Yes, I would like to get this stuff working.


Do you have access to BL1 sources to change this?

IIUC, what is happening is BL1 is leaving CCI in secure mode, which
means the kernel MCPM cannot manage it.  That means the kernel cannot
manage any low-power CPU or cluster states.

Does anyone know at which stage of the boot secure world is left for
normal world?  in BL1?  in BL2?

If it's in BL2, maybe the CCI issue can also be fixed by ensuring that
CCI is not left in secure mode so the kernel can properly manage CCI.

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

Re: [GIT PULL 4/5] Samsung another DT updates for v4.2

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 Hi,

 Here is another Samsung DT updates for v4.2 but this is based on
 v4.1-rc6 + previous tags/samsung-dt-3 because this touches all of exynos
 DT stuff and some fixes have been merged until -rc6...

In the future, it would be helpful to describe what fixes from -rc6 this
series depends on.

 I thought this is the best way to avoid useless merge conflicts.

 Please pull and if any problems, please kindly let me know.

 Thanks,
 Kukjin


 The following changes since commit b9974fa208d9175a6d1d21f6b1068e1779295934:

   Merge branch 'v4.2-next/dt-samsung-3rd' into v4.2-next/dt-samsung-4th
 (2015-06-03 09:56:00 +0900)

 are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
 tags/samsung-dt-4

 for you to fetch changes up to b7004516781503c0e4782288025ca2ce4a78f020:

   ARM: dts: add sysmmu nodes for exynos5420 (2015-06-04 08:09:42 +0900)

 
 Samsung another DT udpates for v4.2

 - use labels for overriding nodes for all of exynos stuff
   (by Krzysztof Kozlowski)

 - add sysmmu nodes for exynos SoCs (by Marek Szyprowski)

 - for exynos5422-odroidxu3
   : enalbe wake alarm of S2MPS11 RTC
   : Hook up PWM and use it for LEDs
   : add support for Odroid XU3 Lite

 - remove duplicated i2c7 for exynos5250-snow
 - add JPEG codec nodes for exynos5420
 - add vendor prefix for Hardkernel

 

Pulled into next/dt,

Thanks,

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

Re: [GIT PULL 5/5] Samsung mach updates for v4.2

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 Hi,

 Here is Samsung mach updates for v4.2 and this is based on v4.1-rc4
 because of dependencies with previous Samsung fixes during -rc

 Please pull and if any problems, please let me know.

 Thanks,
 Kukjin


 The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:

   Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)

 are available in the git repository at:

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

 for you to fetch changes up to 2be2a3ff42a52e926cbd1cc1d376a161a9a73667:

   ARM: EXYNOS: register power domain driver from core_initcall
 (2015-06-06 02:18:03 +0900)

 
 Samsung updates for v4.2

 - add failure(exception) handling
   : of_iomap(), of_find_device_by_node() and kstrdup()

 - add common poweroff to use PS_HOLD based for all of exynos SoCs
 - add exnos_get/set_boot_addr() helper
 - constify platform_device_id and irq_domain_ops
 - get current parent clock for power domain on/off
 - use core_initcall to register power domain driver
 - make exynos_core_restart() less verbose

 - add support coupled CPUidle for exynos3250

 - fix exynos_boot_secondary() return value on timeout
 - fix clk_enable() in s3c24xx adc
 - fix missing of_node_put() for power domains

 

Pulled into next/soc,

Thanks,

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

Re: [GIT PULL 5/5] Samsung mach updates for v4.2

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 Hi,

 Here is Samsung mach updates for v4.2 and this is based on v4.1-rc4
 because of dependencies with previous Samsung fixes during -rc

 Please pull and if any problems, please let me know.

 Thanks,
 Kukjin


 The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:

   Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)

 are available in the git repository at:

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

 for you to fetch changes up to 2be2a3ff42a52e926cbd1cc1d376a161a9a73667:

   ARM: EXYNOS: register power domain driver from core_initcall
 (2015-06-06 02:18:03 +0900)

 
 Samsung updates for v4.2

 - add failure(exception) handling
   : of_iomap(), of_find_device_by_node() and kstrdup()

 - add common poweroff to use PS_HOLD based for all of exynos SoCs
 - add exnos_get/set_boot_addr() helper
 - constify platform_device_id and irq_domain_ops
 - get current parent clock for power domain on/off
 - use core_initcall to register power domain driver
 - make exynos_core_restart() less verbose

 - add support coupled CPUidle for exynos3250

 - fix exynos_boot_secondary() return value on timeout
 - fix clk_enable() in s3c24xx adc
 - fix missing of_node_put() for power domains

 

Pulled into next/soc,

Thanks,

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

Re: [GIT PULL 2/5] Samsung 2nd defconfig for v4.2

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 Hi,

 Here is 2nd defconfig updates for v4.2 but actually just one patch for
 Samsung updates for multi_v7_defconfig. Please pull or apply the patch
 directly, anyway I'm fine either way.

 Note that this is based on arm-soc/next/defconfig to avoid useless merge
 conflicts and I've merged previous tags/samsung-defconfig-2.

We don't mind the simple conflicts like this.

It's better if you just send an updated pull that's based on your
previous pull.

Anyways, I cherry-picked this patch into next/defconfig.

Thanks,

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

Re: [GIT PULL 3/5] Samsung DT updates for v4.2

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
 tags/samsung-dt-3

 for you to fetch changes up to 5ec1d441a4227b2dfdc47fdc13aa7c6c50496194:

   ARM: dts: Add syscon property to the MIPI DPHY for exynos4415
 (2015-06-03 09:47:05 +0900)

 
 Samsung DT updates for v4.2

 - for exyos3250
   : use s3c6410-rtc instead of exynos3250-rtc
   : add JPEG codec node and support it on exynos3250-rinato
   : use s3c-rtc clock id for exynos3250-rinato and monk boards

 - for exynos4
   : add JPEG codec node and syscon property to MIPI DPHY
   : remove obsolete MIPI DPHY reg property
   : enable s3c-rtc on exynos4412-trats2

 - for exynos5
   : add syscon property to MIPI DPHY for exynos5420
   : enable s3c-rtc on exynos5420-arndale-octa
   : add missing irq pinctrl for max77686 on exynos5250-smdk5250

   : clk: add bindings for 32kHz clocks from s2mps11
   : fix pinctrl for s2mps11-irq on exynos5420-arndale-octa

 - for exynos5422-odroidxu3
   : add mmc detect gpio and LEDs
   : add HS400 support, simple-audio-card and rtc_src clock

 

Pulled into next/dt.

Thanks,

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

Re: [PATCH v2] MAINTAINERS: ARM64: EXYNOS: Extend entry for ARM64 DTS

[Kevin Hilman]

Hi Krzysztof,

On Sat, Jun 6, 2015 at 3:02 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
 Extend the Exynos entry to ARM64 device tree sources.

 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Kevin Hilman khil...@kernel.org
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Olof Johansson o...@lixom.net
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Applied to arm-soc's next/soc branch.

Note I found this by chance.  It almost fell through the cracks
because a...@kernel.org (for arm-soc maintainers) wasn't on the to/cc
list.

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

Re: [PATCH v2] MAINTAINERS: ARM64: EXYNOS: Extend entry for ARM64 DTS

[Kevin Hilman]

On Thu, Jun 11, 2015 at 4:35 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
 W dniu 12.06.2015 o 06:48, Kevin Hilman pisze:
 Hi Krzysztof,

 On Sat, Jun 6, 2015 at 3:02 AM, Krzysztof Kozlowski
 k.kozlow...@samsung.com wrote:
 Extend the Exynos entry to ARM64 device tree sources.

 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Kevin Hilman khil...@kernel.org
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Olof Johansson o...@lixom.net
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

 Applied to arm-soc's next/soc branch.

 Note I found this by chance.  It almost fell through the cracks
 because a...@kernel.org (for arm-soc maintainers) wasn't on the to/cc
 list.

 Thanks. I was not aware of this email/list address. It isn't mentioned
 in MAINTAINERS.

Yes, that's kind of by design as it's not meant for general patch
review/discussion.

 So I suspect that any stuff intended to go directly to
 arm-soc maintainers (not through vendor SoC tree) should be sent there?

Yes, this list is specifically for subarch/platform maintainers (which
now includes you :) to send stuff that would like to be applied to the
arm-soc tree.

Thanks,

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

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello Kevin,

 On 06/04/2015 03:08 AM, Kevin Hilman wrote:
 riku.voi...@linaro.org writes:
 
 From: Riku Voipio riku.voi...@linaro.org

 CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board
 asix network controller. Enable it so networking works with
 multi_v7_defconfig out of box like it does with exynos_defconfig.

 USB3503 is also referenced from exynos4412-odroidu3.dts and
 exynos5250-spring.dts so this patch should improve
 multi_v7_defconfig on those platforms as well.

 Signed-off-by: Riku Voipio riku.voi...@linaro.org
 
 Tyler pointed me to this in order to get arndale networking on mainline,
 but looks like this might need to be revisited for current mainline.  
 
 I tested this and it doesn't work because as of commit 7de7c6717f2c
 (ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this
 depends on is built as a module in multi_v7_config, so having this
 driver built-in doesn't help.  Even after the PHY driver is loaded, this
 driver will not detect the hardware.
 
 So instead, I think this driver should be built as a module as well.
 Testing that, I can get networking by doing loading both the phy and
 this driver after boot:
 
  # modprobe phy-exynos-usb2
  # modprobe usb3503


 Current policy is to have as much as possible built as a module
 in multi_v7_config so regardless of your issue I think that the
 patch should be re-spun to change this.

Correct.

 But I wonder why is not working, shouldn't the driver defer and
 be probed again once the PHY driver probe succeeds?

Yeah, I'm not sure why that isn't working, and didn't look into it.

FWIW, the same problem happens when both are modules.  If you modprobe
usb3503 first, then the phy, it doesn't work.  You have to load the phy
before the usb3503.

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

Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503

[Kevin Hilman]

riku.voi...@linaro.org writes:

 From: Riku Voipio riku.voi...@linaro.org

 CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board
 asix network controller. Enable it so networking works with
 multi_v7_defconfig out of box like it does with exynos_defconfig.

 USB3503 is also referenced from exynos4412-odroidu3.dts and
 exynos5250-spring.dts so this patch should improve
 multi_v7_defconfig on those platforms as well.

 Signed-off-by: Riku Voipio riku.voi...@linaro.org

Tyler pointed me to this in order to get arndale networking on mainline,
but looks like this might need to be revisited for current mainline.  

I tested this and it doesn't work because as of commit 7de7c6717f2c
(ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this
depends on is built as a module in multi_v7_config, so having this
driver built-in doesn't help.  Even after the PHY driver is loaded, this
driver will not detect the hardware.

So instead, I think this driver should be built as a module as well.
Testing that, I can get networking by doing loading both the phy and
this driver after boot:

 # modprobe phy-exynos-usb2
 # modprobe usb3503

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

Re: [PATCH] ARM: dts: add exynos5422.dtsi to correct cpu order

[Kevin Hilman]

Marek Szyprowski m.szyprow...@samsung.com writes:

 Hello,

 On 2015-05-28 06:00, Chanho Park wrote:
 -Original Message-
 From: Joonyoung Shim [mailto:jy0922.s...@samsung.com]
 Sent: Thursday, May 28, 2015 10:59 AM
 To: Chanho Park; kg...@kernel.org; k.kozlow...@samsung.com
 Cc: cw00.c...@samsung.com; linux-samsung-soc@vger.kernel.org;
 javier.marti...@collabora.co.uk; khil...@linaro.org;
 sjoerd.sim...@collabora.co.uk; heesub.s...@samsung.com
 Subject: Re: [PATCH] ARM: dts: add exynos5422.dtsi to correct cpu order

 Hi Chanho,

 On 05/28/2015 12:15 AM, Chanho Park wrote:
 The odroid-xu3 board which is based on exynos5422 not exynos5800 is
 booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu
 order
 is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are
 cortex-a15 cores. To correct this mis-odering, I added exynos5422.dtsi
 and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7
 and
 cpu4-7 are cortex-a15.
 The exynos5422 SoC can boot using cortex-a15 cpu depending on gpio
 GPG2CON[1],
 Yes, But, the pin is not controllable because it's checked in  the iROM
 area.

 i think this is just Odroid-XU3 board problem. Is it
 possible to overwrite cpus information directly from
 exynos5422-odroidxu3.dts?
 It's possible to override the info in the odroidxu3.dts. As you know,
 however, a new exynos5422 board will be added soon. The board also has same
 configuration of the gpio pin and booted cpu0 from a cortex-a7 core.

 BTW, booting of secondary cpus are still broken. Is there any progress of
 the patch[1]?
 This patch is also generated top of the patch with some fixes.

Note that even with that hack/patch from me, all cores may boot, but you
cannot let them hit deeper idle states with CPUidle.  This is because
the firmware appears to have configured CCI in secure mode, which mean
that the kernel cannot control CCI, which essentially breaks MCPM  and
everthing built on it (idle, suspend, etc.)

 Przemyslaw is checking how to solve this issue in the bootloader like it has
 been solved for Exynos 5800 based Chromebooks. The plan is to use the same
 SPL code as mentioned here:
 https://www.mail-archive.com/u-boot@lists.denx.de/msg159960.html

This is good news!   I'd be happy to test any work in progress on this.

We really need the other exynos platforms to follow the bootloader of
the chromebooks which includes a working CCI and thus kernel MCPM
functionality.

Kevin

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

Re: [PATCH 2/2] ARM: dts: Fix pinctrl settings for S2MPS11 RTC alarm IRQ on Arndale Octa

[Kevin Hilman]

Hi Krzystof,

Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 2015-04-02 23:36 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 On Arndale Octa the S2MPS11 RTC alarm interrupt was not handled at all
 because of wrong configuration of interrupt and gpx3-2.
 1. Interrupt is signaled by falling edge.
 2. This GPIO line is hard-wired on the board to PVDD_APIO_1V8 through a
resistor so pull-up/down must be disabled.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

 Dear Kukjin,

 Any comments  on this and other patches. A lot of emails waits for
 your opinion. Is there anything I could do to help you in smooth
 review or applying?

IMO, I think you you should just start collecting fixes and features and
queuing them for Kukjin and then start working as a co-maintainer.

The samsung platforms have been in a near constant state of breakage
over the last *several* cycles, and something really needs to change in
how these are being monitored and maintained.

If someone else is paying closer attention, especially to important
fixes like this and the recent ones for other imprecies aborts etc.,
all of us who are trying to use these Exynos platforms with mainline
will be in much better shape.

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

Re: [RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

[Kevin Hilman]

Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 After adding display power domain for Exynos5250 in commit
 2d2c9a8d0a4f (ARM: dts: add display power domain for exynos5250) the
 display on Chromebook Snow and others stopped working after boot.

 The reason for this suggested Andrzej Hajda: the DP clock was disabled.
 This clock is required by Display Port and is enabled by bootloader.
 However when FIMD driver probing was deferred, the display power domain
 was turned off. This effectively reset the value of DP clock enable
 register.

 When exynos-dp is later probed, the clock is not enabled and display is
 not properly configured:

 exynos-dp 145b.dp-controller: Timeout of video streamclk ok
 exynos-dp 145b.dp-controller: unable to config video

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reported-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Fixes: 2d2c9a8d0a4f (ARM: dts: add display power domain for exynos5250)
 Cc: sta...@vger.kernel.org

 ---

 This should fix issue reported by Javier [1][2].

 Tested on Chromebook Snow (Exynos 5250). More testing would be great,
 especially on other Exynos 5xxx products.

I hoped to try this on my exynos5 boards, but it doesn't seem to apply
to linux-next or to Linus' master branch.

Are there some other dependencies here?

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

Re: [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform

[Kevin Hilman]

Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes:

[...]

 However, with the default governor set to userspace it boots fine until
 my userspace (ubuntu) tries to enable the ondemand governor, and then it
 hangs. 
 
 For it to boot, I have to disable the ondemand governor, and set the
 default governor to userspace.

 I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
 that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
 fails to boot.  This happens even with cpufreq support disabled (hard
 lockup happens during mmc initialization which is done just after cpufreq
 initialization).

Right, the XU3 has broken secure firmware such that MCPM cannot properly
control CCI, so CPUidle will hang when trying to hit low power states,
so you have to disable CCI by adding something like this to the end of
your XU3 .dts file:

cci {
 status = disabled;
};

 Could you please check if disabling cpuidle support helps?

For now, I've disabled CPUidle so we have a similar setup, but it
doesn't change anything on exynos5800-peach-pi

 As I reported earlier on Thomas' series, I suspect this is related to
 the fact that the higher OPPs aren't really functional without voltage
 scaling also supported. 

 Part #4 contains voltage scaling support for arm_big_little[_dt] driver
 so this should not be a problem any longer.

 You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
 branch from my github (with cpufreq debugging printks enabled) to check
 whether the voltage scaling is indeed done on your board.

 I'm also seeing the wait_until_divider_stable errors when switching
 between the available A7 OPPs.  I'd reported this one earlier as well,
 along with the script to reproduce it.

 I've tried your script and it works fine for me (I only needed to change
 cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).

Then it seems something isn't quite right for exynos5800-peach-pi.
Below is the script[1] I'm using on exynos which also checks the voltage
by quering the regulator fwk (and optionally checking the INA2xx sensors
on odroid-xu3 if that support is enabled)

On your debug branch, it just gives -1 for all the voltages, so the
regulator voltage never changes:

# ./dvfs
CPU regulator: cpu0, vdd_arm, /sys/class/regulator/regulator.18
[   45.691483] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new 
cluster: 0, freq: 20
[   45.699581] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 
400 MHz, -1 mV -- 200 MHz, -1 mV
current freq: 20 
current voltage: 1262500
[   46.969821] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new 
cluster: 0, freq: 30
[   46.978272] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 
200 MHz, -1 mV -- 300 MHz, -1 mV
current freq: 30
current voltage: 1262500

I added a bit more debug to the cpufreq driver[1] and found that the
regulator_get_optional is failing:

[3.407295] cpu cpu0: Unable to get regulator cpu-cluster.0
[3.458282] cpu cpu4: Unable to get regulator cpu-cluster.1


Kevin


[1]
#!/bin/sh

if [ ! -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
  echo CPUfreq not enabled in kernel.
  exit 1
fi

# NOTE: odroid-xu3: CPU0 = A7.0, CPU1 = A15.0
cpu=cpu0
reg_name=vdd_arm
hwmon=hwmon0
#cpu=cpu4
#reg_name=vdd_kfc
#hwmon=hwmon3

cpu_reg=$(dirname `find /sys/class/regulator/regulator.*/ -name name -exec grep 
-l $reg_name {} \;`)
echo CPU regulator: $cpu, $reg_name, $cpu_reg

# Cycle through frequencies (and check voltage)
cd /sys/devices/system/cpu/$cpu/cpufreq
echo userspace  scaling_governor
for freq in `cat scaling_available_frequencies`; do
  echo ${freq}  scaling_setspeed
  sleep 0.2

  echo -n current freq: 
  cat scaling_cur_freq
  echo -n current voltage: 
  cat ${cpu_reg}/microvolts

  # odroid-xu3 INA231 monitors
  if [ ! -z $hwmon ]; then
if [ -e /sys/class/hwmon/$hwmon/in1_input ]; then
  echo -n current voltage (ina2xx):
  cat /sys/class/hwmon/$hwmon/in1_input
fi
  fi

  sleep 1
done

[2]
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index 024f185b2154..4108f909cc9c 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -16,6 +16,7 @@
  * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
  */
+#define DEBUG

 #define pr_fmt(fmt) KBUILD_MODNAME :  fmt

@@ -446,6 +447,8 @@ static int _get_cluster_clk_and_freq_table(struct
device *cpu_dev)
ret = regulator_set_voltage_time(reg[cluster], min_uV,
max_uV);
if (ret  0)
transition_latencies[cluster] = ret * 1000;
+   } else {
+   dev_warn(cpu_dev, Unable to get regulator %s, name);
}

ret = dev_pm_opp_init_cpufreq_table(cpu_dev,
freq_table[cluster]);
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in

Re: [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform

[Kevin Hilman]

Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes:

 On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
 Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes:
 
  Hi,
 
  This patch series removes the use of Exynos5250 specific support
  from exynos-cpufreq driver and enables the use of cpufreq-dt driver
  for this platform.  The exynos-cpufreq driver itself is also removed
  as it is no longer used/needed after Exynos5250 support removal.
 
  This patch series has been tested on Exynos5250 based Arndale board.
 
  Depends on:
  - next-20150330 branch of linux-next kernel tree
  - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
platform [1]
  - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
platform [2]
  - [PATCH] cpufreq: exynos: remove dead -need_apll_change method [3]
 
 Any chance you could prepare a branch with all the dependencies for easy
 testing?

 All cpufreq changes with needed dependencies are now availble in

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

 repository and the branch is

 next-20150330-generic-cpufreq-exynos5420-5800-v2

Great, thanks.

 Also, The previous version from Thomas was v12, and this one is neither
 versioned nor has any reference to what may have changed since that

 Please note that Thomas' patchset was split on separate parts (this is
 part #3) and heavily modified so the previous versioning was dropped.

 The cover letter of part #1 ([PATCH 0/6] cpufreq: use generic cpufreq
 drivers for Exynos4210 platform) contains detailed changelog on what has
 been changed since Thomas' original v12 patch series.  Individual Thomas'
 patches which were modified by me also contain such information.

 Part #2 ([PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
 platform) was entirely new code when compared to Thomas' v12 patchset so
 its cover letter doesn't contain such detailed changelog as part #1.

 The newly posted part #4 ([PATCH 0/8] cpufreq: add generic cpufreq driver
 support for Exynos5250/5800 platforms https://lkml.org/lkml/2015/4/21/314)
 also contains the detailed changelog.

 However for part #3 (this one, [PATCH 0/4] cpufreq: use generic cpufreq
 drivers for Exynos5250 platform) such summary changelog got missed for
 some reason.  Here it is:
 - split Exynos5250 support from the original patch
 - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
 - added CPU regulator supply property for Google Spring board
 - removed exynos-cpufreq driver entirely as it is no longer used/needed

Great, thanks for clarifying.

 version.  Also, on v12, I had several comments[1] and wonder if they've
 been addressed.

 All issues previously reported should have been fixed.  If you still see
 some problems please let me know.

 [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
   exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
   been updated to contain CPU cluster regulator supply properties or else
   if the default vdd_arm/vdd_kfc regulator state is set to too low value
   there may be problems with stability when switching to higher than
   default frequencies.  I have posted v2 version of patch #2/8 of part #4
   and pushed v2 combined branch on github.  Sorry for the inconvenience. ]

I've now tested your v2 branch with the bL switcher disabled, CPUidle
enabled and CPUfreq enabled.  

With the default governor set to performance, it fails to boot.  The last
kernel messages on the console are:

[...]
[3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
[3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized

However, with the default governor set to userspace it boots fine until
my userspace (ubuntu) tries to enable the ondemand governor, and then it
hangs. 

For it to boot, I have to disable the ondemand governor, and set the
default governor to userspace.

As I reported earlier on Thomas' series, I suspect this is related to
the fact that the higher OPPs aren't really functional without voltage
scaling also supported. 

I'm also seeing the wait_until_divider_stable errors when switching
between the available A7 OPPs.  I'd reported this one earlier as well,
along with the script to reproduce it.

Kevin



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

Re: [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform

[Kevin Hilman]

Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes:

 Hi,

 This patch series removes the use of Exynos5250 specific support
 from exynos-cpufreq driver and enables the use of cpufreq-dt driver
 for this platform.  The exynos-cpufreq driver itself is also removed
 as it is no longer used/needed after Exynos5250 support removal.

 This patch series has been tested on Exynos5250 based Arndale board.

 Depends on:
 - next-20150330 branch of linux-next kernel tree
 - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
   platform [1]
 - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
   platform [2]
 - [PATCH] cpufreq: exynos: remove dead -need_apll_change method [3]

Any chance you could prepare a branch with all the dependencies for easy
testing?

Also, The previous version from Thomas was v12, and this one is neither
versioned nor has any reference to what may have changed since that
version.  Also, on v12, I had several comments[1] and wonder if they've
been addressed.

Kevin

[1] 
http://article.gmane.org/gmane.linux.power-management.general/53494/match=patch+v12+0+6+use+generic+cpufreq


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

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

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

[...]

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

[...]

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

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

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

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

 Fixes: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
 support v12)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Tested-by: Kevin Hilman khil...@linaro.org

on exynos5800-peach-pi

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

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

[Kevin Hilman]

Abhilash Kesavan kesavan.abhil...@gmail.com writes:

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

 [...]

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

 +1

 Maybe Abhilash can shed some light here?

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

 I think my last mail might not have reached you (was accidentally sent
 as html). 

Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
research and reporting back.

 We are gating the aclk266_g2d clock without checking the
 CG_STATUS0 register bits as specified in the UM. It looks like we need
 to keep several clocks alive or gate them only after checking the
 CG_STATUSx register bits.

I dont' know much about this clock hardware, but to me it sounds like a
clock driver bug.  The suspend fix Javier is proposing would fix it, but
to me it sounds like the clock driver needs to actually start checking
these CG_STATUSx bits before gating clocks.

Otherwise, we might fix this current bug but a similar one will come and
bite us another day.

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

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

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

[...]

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

+1

Maybe Abhilash can shed some light here?

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

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

exynos5800-peach-pi: suspend/resume (still) broken

[Kevin Hilman]

I've tried suspend/resume on peach-pi using v4.0-rc4, next/master and
samsung/for-next, and it doesn't seem to work on any of them.

The first problem was the exynos DRM driver is faulting so I had to set CONFIG_\
DRM_EXYNOS=n for testing in mainline, this is fixed in -next.

Note that RTC wake from suspend to idle seems to work, which
suggests that the RTC wake alarms are working fine.  I tried with both
the s3c and the max77802 RTC drivers (e.g. rtcwake -d rtc0 -m freeze
-s4)

However, trying suspend to RAM (rtcwake -d rtc0 -m mem -s4), it never
resumes, and adding no_console_suspend doesn't give anything useful.

Anyone else having better luck with suspend/resume on peach-pi?

I also tried on exynos5422-odroid-xu3, but that doesn't seem to have
any working RTC drivers. :(

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

Re: [PATCH v2] ARM: EXYNOS: Use platform device name as power domain name

[Kevin Hilman]

Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 The power domain nodes in DTS may be very generic (e.g. power-domain
 for Exynos 5420) making it very hard to debug:

 $ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
 domain  status slaves
 power-domainon

 Use platform device name instead so the names will be a little more user
 friendly:
 domain  status slaves
 100440e0.power-domain   on

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Suggested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Suggested-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Reviewed-by: Kevin Hilman khil...@linaro.org

I still think we need some more detail as wel, but this is a good step
in the right direction.

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

Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 +Gustavo which has been looking at the issues

 Hello,

 On 03/04/2015 09:50 AM, Marek Szyprowski wrote:
 Hello,
 
 On 2015-03-03 21:36, Kevin Hilman wrote:
 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Enabling Exynos DRM IOMMU support for Exynos is currently broken and
 causes a BUG on exynos-iommu driver. This was not an issue since the
 options was disabled in exynos_defconfig but after commit 8dcc14f82f06
 (drm/exynos: IOMMU support should not be selectable by user), it is
 selected if EXYNOS_IOMMU is enabled which is in exynos_defconfig.

 So a kernel built using exynos_defconfig after the mentioned commit
 fails to boot [0]. Disable IOMMU support in Exynos defconfig until
 things get sorted out.
 So some other exynos boards started failing in next-20150303[1], and
 appear are DRM failures.

 Interestingly, (re)enabling CONFIG_EXYNOS_IOMMU for these cause things to
 work again.  Even more intersting, with IOMMU enabled, peach-pi is


 I built both 4.0-rc2 and linux-next (tag next-20150303) with and without
 CONFIG_EXYNOS_IOMMU and boot tested on Snow, Peach Pit and Pi.

 We still don't have a Peach Pit hooked in LAVA so I tested it locally
 and pasted the boot logs.

 4.0-rc2 (which has CONFIG_EXYNOS_IOMMU enabled)
 ---

  * Snow: NULL pointer dereference at fimd_wait_for_vblank [0]

  * Peach Pi: kernel BUG at drivers/iommu/exynos-iommu.c:481 [1]

  * Peach Pit: NULL pointer dereference at fimd_wait_for_vblank [2]

 4.0-rc2 + CONFIG_EXYNOS_IOMMU disabled
 --

  * Snow: NULL pointer dereference at exynos_plane_destroy [3]

  * Peach Pi: no error, kernel booted successfully [4]

  * Peach Pit: NULL pointer dereference at exynos_plane_destroy [5]

 next-20150303 (which has CONFIG_EXYNOS_IOMMU disabled)
 -

  * Snow: no error, kernel booted successfully [6]
  * Peach Pi: no error, kernel booted successfully [7]
  * Peach Pit: no error, kernel booted successfully [8]

 next-20150303 + CONFIG_EXYNOS_IOMMU (re)enabled
 ---

 Snow: no error, kernel booted successfully [9]
 Peach Pi: no error, kernel booted successfully [10]
 Peach Pit: no error, kernel booted successfully [11]

 Is interesting that the only Exynos5 machines that failed to boot in
 next-20150303 were exynos5250-arndale and exynos5422-odroidxu3 [12].

 Also, only the exynos5250-arndale failed to boot with next-20150304 [13]
 while exynos5422-odroidxu3 booted successfully and there were no changes
 for the exynos drm driver between next-20150303 and next-20150304.

My odroid-xu3 failed, but yours and Tyler's booted.  We have different
u-boot versions (mine is mainline), so there may be something bootloader
realted going on with DRM as well:

   http://kernelci.org/boot/?exynos_defconfigexynos5422-odroid

 Another interesting data point is that the error in next-20150303 for
 these 2 boards was the NULL pointer dereference in exynos_plane_destroy
 that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit.

 So it appears the error is not consistent and may be a race condition.

 I'm starting to think it's the DRM driver that needs to be disabled
 until it actually gets some testing, rathre than disabling IOMMU.


 It's true that there are a lot of issues with the Exynos DRM driver
 but OTOH those are exposed because the config is enabled by default.

 My fear is that if we disable the driver, it could silently break
 and be noticed much later when a user enables the option.

This is a concern, but at the same time, exynos has been pretty
consistently broken in -next and in mainline during this cycle (have a
look at this, and set boot reports per page to 100: 
http://kernelci.org/boot/?exynos_defconfig

This kind of constant breakage causes one form of breakage to mask
others, and we end up getting stuck in situations like this in the -rc
cycle when we should be fixing regressions, not problems that have been
around for months already.

 Well, this only shows that broken patch has been merged to exynos-drm-next
 kernel tree. I think that we should keep Exynos DRM enabled and give Exynos
 DRM developers a chance to fix their stuff and then test their stuff.

 Agree, hopefully all these issues are sorted out during the -rc cycle but
 if not then I think we would have to disable the driver as Kevin suggests.

I don't mind so much the brokenness in -next, that's what it's for.  The
brokenness in mainline during this part of the -rc cycle is worrisome,
even more so because it's been broken for most of the cycle.

At this point for v4.0-rc, I don't expect there is time to sort out the
proper DRM and have it broadly tested.  It's time to fix the regression
in mainline (maybe by disabling some options), and sort out the right
fix in -next.

 Another thing that may be useful

Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Enabling Exynos DRM IOMMU support for Exynos is currently broken and
 causes a BUG on exynos-iommu driver. This was not an issue since the
 options was disabled in exynos_defconfig but after commit 8dcc14f82f06
 (drm/exynos: IOMMU support should not be selectable by user), it is
 selected if EXYNOS_IOMMU is enabled which is in exynos_defconfig.

 So a kernel built using exynos_defconfig after the mentioned commit
 fails to boot [0]. Disable IOMMU support in Exynos defconfig until
 things get sorted out.

So some other exynos boards started failing in next-20150303[1], and
appear are DRM failures.

Interestingly, (re)enabling CONFIG_EXYNOS_IOMMU for these cause things to
work again.  Even more intersting, with IOMMU enabled, peach-pi is 

I'm starting to think it's the DRM driver that needs to be disabled
until it actually gets some testing, rathre than disabling IOMMU.

Kevin

[1] http://kernelci.org/boot/?next-20150303fail
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.

There is one sensor for each of these power rails:

- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM

In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.

Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-By: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v3: extend existing i2c_0 node 
v2: use ti,ina231 as compatible string.

Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
Simons.

 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..38694a4a5417 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
 
+   ldo26_reg: LDO26 {
+   regulator-name = vdd_ldo26;
+   regulator-min-microvolt = 300;
+   regulator-max-microvolt = 300;
+   regulator-always-on;
+   };
+
buck1_reg: BUCK1 {
regulator-name = vdd_mif;
regulator-min-microvolt = 80;
@@ -330,3 +337,35 @@
 usbdrd_dwc3_1 {
dr_mode = otg;
 };
+
+i2c_0 {
+   status = okay;
+
+   /* A15 cluster: VDD_ARM */
+   ina231@40 {
+   compatible = ti,ina231;
+   reg = 0x40;
+   shunt-resistor = 1;
+   };
+
+   /* memory: VDD_MEM */
+   ina231@41 {
+   compatible = ti,ina231;
+   reg = 0x41;
+   shunt-resistor = 1;
+   };
+
+   /* GPU: VDD_G3D */
+   ina231@44 {
+   compatible = ti,ina231;
+   reg = 0x44;
+   shunt-resistor = 1;
+   };
+
+   /* A7 cluster: VDD_KFC */
+   ina231@45 {
+   compatible = ti,ina231;
+   reg = 0x45;
+   shunt-resistor = 1;
+   };
+};
-- 
2.1.3

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

Re: [PATCH v2] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Kevin Hilman]

Joonyoung Shim jy0922.s...@samsung.com writes:

 Hi Kevin,

 On 01/15/2015 10:08 AM, Kevin Hilman wrote:
 From: Kevin Hilman khil...@linaro.org
 
 The odroid-xu3 has 4 INA231 current sensors on board which can be
 accessed from the Linux via the hwmon interface.
 
 There is one sensor for each of these power rails:
 
 - A15 cluster: VDD_ARM
 - A7 cluster: VDD_KFC
 - GPU: VDD_G3D
 - memory: VDD_MEM
 
 In addition to adding the sensors, LDO26 from the PMIC needs to be
 enabled because it's powering these sensor.
 
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 v2: use ti,ina231 as compatible string.
 
 Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
 Simons.
 
  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
 ++
  1 file changed, 39 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
 b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 index c29123c0734d..50353d023225 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 @@ -174,6 +174,13 @@
  regulator-always-on;
  };
  
 +ldo26_reg: LDO26 {
 +regulator-name = vdd_ldo26;
 +regulator-min-microvolt = 300;
 +regulator-max-microvolt = 300;
 +regulator-always-on;
 +};
 +
  buck1_reg: BUCK1 {
  regulator-name = vdd_mif;
  regulator-min-microvolt = 80;
 @@ -257,6 +264,38 @@
  };
  };
  
 +i2c_0: i2c@12C6 {

 It's ok but IMHO it can split using label reference, e.g. 

 i2c_0 {
   ...
 };

Yes, you're right.  I'll spin a v3.

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

Re: [PATCH] ARM: dts: exynos5422-odroidxu3: add INA2xx sensors

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 On 01/14/15 09:03, Kevin Hilman wrote:
 From: Kevin Hilman khil...@linaro.org
 
 The odroid-xu3 has 4 INA231 current sensors on board which can be
 accessed from the Linux via the hwmon interface.
 
 There is one sensor for each of these power rails:
 
 - A15 cluster: VDD_ARM
 - A7 cluster: VDD_KFC
 - GPU: VDD_G3D
 - memory: VDD_MEM
 
 In addition to adding the sensors, LDO26 from the PMIC needs to be
 enabled because it's powering these sensor.
 
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
 Simons.
 
  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
 ++
  1 file changed, 39 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
 b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 index c29123c0734d..7874da20939f 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 @@ -174,6 +174,13 @@
  regulator-always-on;
  };
  
 +ldo26_reg: LDO26 {
 +regulator-name = vdd_ldo26;
 +regulator-min-microvolt = 300;
 +regulator-max-microvolt = 300;
 +regulator-always-on;
 +};
 +
  buck1_reg: BUCK1 {
  regulator-name = vdd_mif;
  regulator-min-microvolt = 80;
 @@ -257,6 +264,38 @@
  };
  };
  
 +i2c_0: i2c@12C6 {
 +status = okay;
 +
 +/* A15 cluster: VDD_ARM */
 +ina220@40 {
 +compatible = ti,ina230;
 +reg = 0x40;
 +shunt-resistor = 1;
 +};
 +
 +/* memory: VDD_MEM */
 +ina220@41 {
 +compatible = ti,ina230;
 +reg = 0x41;
 +shunt-resistor = 1;
 +};
 +
 +/* GPU: VDD_G3D */
 +ina220@44 {
 +compatible = ti,ina230;
 +reg = 0x44;
 +shunt-resistor = 1;
 +};
 +
 +/* A7 cluster: VDD_KFC */
 +ina220@45 {
 +compatible = ti,ina230;
 +reg = 0x45;
 +shunt-resistor = 1;
 +};
 +};
 +
  i2c_2: i2c@12C8 {
  samsung,i2c-sda-delay = 100;
  samsung,i2c-max-bus-freq = 66000;

 Looks good to me and applied. To be honest, I'm not sure about the
 values in the node of shunt-resistor though ;)

I didn't measure the values, but used the values from the DTS that's
part of the hardkernel tree.

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

Re: [PATCH] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

Guenter Roeck li...@roeck-us.net writes:

 On Wed, Jan 14, 2015 at 03:57:32PM -0800, Kevin Hilman wrote:
 From: Kevin Hilman khil...@linaro.org
 
 Add support for ina231 as compatible string.
 
 Tested with the Exynos5422-based odroid-xu3 board which has on-board
 INA231 sensors.
 
 Signed-off-by: Kevin Hilman khil...@linaro.org

 Hi Kevin,

 can you also update Documentation/hwmon/ina2xx and 
 Documentation/hwmon/Kconfig ?


Sure... coming right up.

Kevin

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

[PATCH v2] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

Add support for ina231 as compatible string, and update
Documentation and Kconfig accordingly.

Tested with the Exynos5422-based odroid-xu3 board which has on-board
INA231 sensors.

Signed-off-by: Kevin Hilman khil...@linaro.org
---
 Documentation/hwmon/ina2xx | 9 +
 drivers/hwmon/Kconfig  | 4 ++--
 drivers/hwmon/ina2xx.c | 1 +
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 4223c2d3b508..c2f838f65ee4 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -26,6 +26,12 @@ Supported chips:
 Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/
 
+  * Texas Instruments INA231
+Prefix: 'ina231'
+Addresses: I2C 0x40 - 0x4f
+Datasheet: Publicly available at the Texas Instruments website
+   http://www.ti.com/
+
 Author: Lothar Felten l-fel...@ti.com
 
 Description
@@ -44,6 +50,9 @@ The INA226 monitors both a shunt voltage drop and bus supply 
voltage.
 The INA230 is a high or low side current shunt and power monitor with an I2C
 interface. The INA230 monitors both a shunt voltage drop and bus supply 
voltage.
 
+The INA231 is a high or low side current shunt and power monitor with an I2C
+interface. The INA230 monitors both a shunt voltage drop and bus supply 
voltage.
+
 The shunt value in micro-ohms can be set via platform data or device tree.
 Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for 
bindings
 if the device tree is used.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09c46f0..408fb6f5f055 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1420,8 +1420,8 @@ config SENSORS_INA2XX
tristate Texas Instruments INA219 and compatibles
depends on I2C
help
- If you say yes here you get support for INA219, INA220, INA226, and
- INA230 power monitor chips.
+ If you say yes here you get support for INA219, INA220, INA226,
+ INA230, and INA231 power monitor chips.
 
  The INA2xx driver is configured for the default configuration of
  the part as described in the datasheet.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba909c3..8c4a29bd2eaf 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -287,6 +287,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ ina220, ina219 },
{ ina226, ina226 },
{ ina230, ina226 },
+   { ina231, ina226 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
-- 
2.1.3

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

Re: [PATCH] ARM: dts: exynos5422-odroidxu3: add INA2xx sensors

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 Hey kevin,

 On Tue, 2015-01-13 at 16:03 -0800, Kevin Hilman wrote:
 From: Kevin Hilman khil...@linaro.org
 
 The odroid-xu3 has 4 INA231 current sensors on board which can be
 accessed from the Linux via the hwmon interface.
 
 There is one sensor for each of these power rails:
 
 - A15 cluster: VDD_ARM
 - A7 cluster: VDD_KFC
 - GPU: VDD_G3D
 - memory: VDD_MEM
 
 In addition to adding the sensors, LDO26 from the PMIC needs to be
 enabled because it's powering these sensor.
 
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
 Simons.
 
  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
 ++
  1 file changed, 39 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
 b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 index c29123c0734d..7874da20939f 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 @@ -257,6 +264,38 @@
  };
  };
  
 +i2c_0: i2c@12C6 {
 +status = okay;
 +
 +/* A15 cluster: VDD_ARM */
 +ina220@40 {
^ ina231@40 ?
 +compatible = ti,ina230;

 This feels incredibly nitpicky, but would it not better to use ti,ina231
 as it's an INA231 chip not a INA230? (And add the compatibility string
 to the driver)

Hmm, you're right.  Until recently, I thought these were INA230s, but
squinted enough at the schematic yesterday to notice they were marked as
INA231, so updated the changelog, but not the DTS.

Will re-spin with a compatible string update to the driver.

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

[PATCH] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

Add support for ina231 as compatible string.

Tested with the Exynos5422-based odroid-xu3 board which has on-board
INA231 sensors.

Signed-off-by: Kevin Hilman khil...@linaro.org
---
 drivers/hwmon/ina2xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba909c3..8c4a29bd2eaf 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -287,6 +287,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ ina220, ina219 },
{ ina226, ina226 },
{ ina230, ina226 },
+   { ina231, ina226 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
-- 
2.1.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

[PATCH v2] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.

There is one sensor for each of these power rails:

- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM

In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.

Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v2: use ti,ina231 as compatible string.

Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
Simons.

 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..50353d023225 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
 
+   ldo26_reg: LDO26 {
+   regulator-name = vdd_ldo26;
+   regulator-min-microvolt = 300;
+   regulator-max-microvolt = 300;
+   regulator-always-on;
+   };
+
buck1_reg: BUCK1 {
regulator-name = vdd_mif;
regulator-min-microvolt = 80;
@@ -257,6 +264,38 @@
};
};
 
+   i2c_0: i2c@12C6 {
+   status = okay;
+
+   /* A15 cluster: VDD_ARM */
+   ina231@40 {
+   compatible = ti,ina231;
+   reg = 0x40;
+   shunt-resistor = 1;
+   };
+
+   /* memory: VDD_MEM */
+   ina231@41 {
+   compatible = ti,ina231;
+   reg = 0x41;
+   shunt-resistor = 1;
+   };
+
+   /* GPU: VDD_G3D */
+   ina231@44 {
+   compatible = ti,ina231;
+   reg = 0x44;
+   shunt-resistor = 1;
+   };
+
+   /* A7 cluster: VDD_KFC */
+   ina231@45 {
+   compatible = ti,ina231;
+   reg = 0x45;
+   shunt-resistor = 1;
+   };
+   };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
-- 
2.1.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: [RFC v2 0/4] Add basic support for ASV

[Kevin Hilman]

On Tue, Dec 3, 2013 at 10:00 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Hi Abhilash,

 On 3 December 2013 20:16, Abhilash Kesavan kesavan.abhil...@gmail.com wrote:
 Hi Yadwinder and Sachin,

 CC'ing Doug and Andrew who have also worked on ASV.

 I tested these patches on a 5250 Chromebook after modifying the
 cpufreq code and a few other changes for booting the board. The driver
 is retrieving the ASV fused group correctly. The behavior on an
 unfused SMDK5250 is also fine.
 I have a few minor comments on the patches.


 Thank you for testing and reviewing the patchset.
 Will incorporate your comments in the next version.

Has there been an updated version of this series posted?I can't
seem to find one.

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

[PATCH] ARM: dts: exynos5422-odroidxu3: add INA2xx sensors

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.

There is one sensor for each of these power rails:

- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM

In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.

Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
Simons.

 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..7874da20939f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
 
+   ldo26_reg: LDO26 {
+   regulator-name = vdd_ldo26;
+   regulator-min-microvolt = 300;
+   regulator-max-microvolt = 300;
+   regulator-always-on;
+   };
+
buck1_reg: BUCK1 {
regulator-name = vdd_mif;
regulator-min-microvolt = 80;
@@ -257,6 +264,38 @@
};
};
 
+   i2c_0: i2c@12C6 {
+   status = okay;
+
+   /* A15 cluster: VDD_ARM */
+   ina220@40 {
+   compatible = ti,ina230;
+   reg = 0x40;
+   shunt-resistor = 1;
+   };
+
+   /* memory: VDD_MEM */
+   ina220@41 {
+   compatible = ti,ina230;
+   reg = 0x41;
+   shunt-resistor = 1;
+   };
+
+   /* GPU: VDD_G3D */
+   ina220@44 {
+   compatible = ti,ina230;
+   reg = 0x44;
+   shunt-resistor = 1;
+   };
+
+   /* A7 cluster: VDD_KFC */
+   ina220@45 {
+   compatible = ti,ina230;
+   reg = 0x45;
+   shunt-resistor = 1;
+   };
+   };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
-- 
2.1.3

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

Re: [PATCH v3] ARM: dts: Add dts file for odroid XU3 board

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
 same as the vendors naming, which means it's prefixed with exynos5422
 instead of exynos5800 as the SoC name even though it includes the
 exyno5800 dtsi.

 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk

Boot tested on top of next-20150109 (with and without my hack for
bringing up 8 cores.)

Tested-by: Kevin Hilman khil...@linaro.org

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

Re: [PATCH v2] ARM: dts: Add dts file for odroid XU3 board

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 On Wed, 2015-01-07 at 23:49 +, Jonathan Stone -SISA wrote:
 
 On On Wed, 2015-01-07 at 18:37 +, Sjoerd Simons writes wrote:
 On Wed, 2015-01-07 at 18:37 +, Anand Moon wrote:
 [...]
 
  Only 4 core cpu's are on my board. Also CpuFreq is not working.
  
  Can you share some point on this.
 
 The defconfig is using the bL switcher, which pairs up big and
  little cores to make them appear as one core.. So for 8 real
  cores, you'll get
 4 virtual cores.
 
 That configuration is appropriate for the 5420, which allegedly has
 a hardware bug in the cache-coherence between the Cortex-A7 block
 and the Cortex-A15 block.
 Newer Exynos 5 SoCs -- 5422/5800, 5620, etc -- don't have that
 bug. The scheduler should configured to do HMP on all 8 (or 6)
 cores.
 I don't have a 5410, but I assume it has the same bug as the 5420.

 Yes the kernel/scheduler could be configured like that, but
 exynos_defconfig turns on bL rather then HMP. 

 Now it's not unthinkable to add code/dts properties to select the
 right/preferred scheduling strategy depending on the board (HMP vs. bL).
 But proper HMP scheduling is still a work in progress in mainline 

Yes, HMP scheduling is not yet ready for mainline, which is why the
switcher is enabled by default.  If you turn the switcher off, you will
indeed get all 8 cores, but you may get some rather strange and
sub-optimal results with performance since from the scheduler
perspective, it will balance tasks across all 8 CPUs as if they were
identical.

 and iirc specifically on the XU3 there are open issue wrt. MCPM and
 its secure firmware. I've added Kevin to the CC as he's been working
 on this topic so should know the status a lot better then i do.

The broken firmware issues don't affect scheduling directly, but affect
the low-power states that are available to the kernel.  Since the
firwmware doesn't allow proper access to CCI, low-power states that
require MCPM are not available, which, among other things, means the
clusters can not be powered down.

 The XU3 kernel supplied by HardKernel shows all 8 cores, and does HMP 
 scheduling across all 8.

 Yes, that's independant of the dts though as mentioned above. Also there
 are still opne issues to booting up all cores on an XU3 afaik. See 
http://www.spinics.net/lists/linux-samsung-soc/msg39523.html

I haven't looked closely at the hardkernel tree to see what HMP
scheduling patches they're using, but it must be something out of tree.

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

Re: [PATCH RFT 1/2] drivers: bus: check cci device tree node status

[Kevin Hilman]

Abhilash Kesavan kesavan.abhil...@gmail.com writes:

 Hi Arnd/Olof,

 On Fri, Jan 9, 2015 at 10:40 AM, Sudeep Holla sudeep.ho...@arm.com wrote:


 On Thursday 08 January 2015 08:57 PM, Abhilash Kesavan wrote:

 Hi Sudeep,

 On Thu, Jan 8, 2015 at 12:15 PM, Sudeep Holla sudeep.ho...@arm.com
 wrote:

 Hi Abhilash,


 [...]


 What's the status of this patch. It was useful for me on vexpress for
 some
 testing. Please feel free to add

 Tested-by: Sudeep Holla sudeep.ho...@arm.com

 if this is not yet queued.


 Thanks for the tested-by. This patch has not been merged yet; I am not
 quite sure who is supposed to pick this up.


 So far, most of the CCI patches are merged through arm-soc.

 Would you be OK picking this up as is or do you want me to re-send
 this with the RFT tag dropped ?

Please resend without the RFT, and collect the Tested-by tags
you can add mine:

Tested-by: Kevin Hilman khil...@linaro.org

Please send to a...@kernel.org where patches targeted for the arm-soc
tree are collected.

Thanks,

Kevin

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

Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME

[Kevin Hilman]

Rafael J. Wysocki r...@rjwysocki.net writes:

[...]

 Fixed up patch is appended, thanks!


 ---
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Subject: PM: Eliminate CONFIG_PM_RUNTIME

 Having switched over all of the users of CONFIG_PM_RUNTIME to use
 CONFIG_PM directly, turn the latter into a user-selectable option
 and drop the former entirely from the tree.

 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Reviewed-by: Ulf Hansson ulf.hans...@linaro.org

Acked-by: Kevin Hilman khil...@linaro.org

I assume you're planning to get this in early in the v3.19-rc cycle,
correct?  That way we can hopefully avoid conflicts with the various
defconfig changes we're taking through the arm-soc tree.

Also, thanks for taking care of all the tree-wide changes.  This is a
great change.

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

Re: Enable runtime PM automatically?

[Kevin Hilman]

Geert Uytterhoeven ge...@linux-m68k.org writes:

[...]

 On Thu, Dec 18, 2014 at 10:29 PM, Kevin Hilman khil...@kernel.org wrote:
 However, if PM domains are active, drivers must be runtime PM-aware for the
 gpd_dev_ops.start() method to be called in the first place (perhaps this is 
 just
 one bug that's easy to fix --- the device is assumed suspended, but can be
 used). They must
   1. call pm_runtime_enable() to enable runtime PM for the device,
   2. call pm_runtime_get_sync() to prevent the device from being put in a
 low-power state at any time. This second call has the
 side-effect of calling
 gpd_dev_ops.start().

 Hence, if PM domains are enabled, wouldn't it make sense to
   1. enable runtime PM by default, for all devices (bound and unbound),
   2. call pm_runtime_get_sync(), for all devices bound to a driver.
 Of course we have to keep track if drivers call any of the pm_runtime_*()
 methods theirselves, as that would have to move them from automatic to
 manual mode.

 Would this be feasible?

 We have to be careful about where the PM core's _get_sync() call goes.

 Because you're talking about bound devices, I guess you mean after the
 driver probes?  Otherwise, it gets tricky if the _get_sync() is before
 the driver probes, because the device driver may have work it wants to
 do in its runtime PM callbacks, which are not initialized/available
 before the driver probes.  Doing this before probe also makes it rather
 difficult to know for sure the actual physical state of the device, and
 make sure it matches the runtime PM state of the device.  Rafael
 mentioned this also, and I'm not sure how we can be sure of the physical
 state.

 Yes, it's complicated by the fact that there are multiple sets of callbacks
 (PM domain, device type, class type, bus type, driver).
 However, the PM domain one has the highest priority, and is always
 (also for devices not bound to a driver) available.

Yes, but if a _get_sync() is called on a device which has not yet setup
its callbacks (e.g. before it has been probed), then the device may not
be properly initialized, and we may not be able to know its physical state.

 Some thoughts: devices without drivers would be runtime resumed by the
 core, but will never be suspended, so the PM domain will never shut
 down.  I guess the core will have to keep track of the devices it
 automatically runtime resumed and decide to runtime suspend them too?
 Hmm, where would that go?

 No, devices without a driver just need to become runtime PM enabled.
 They will only be resumed when a dependent device (e.g. a child) is resumed,
 and are suspended again after all dependents are suspended. That's how
 simple-pm-bus behaves.

Ah, OK.  I thought you were proposing to _enable() and _get_sync() those
devices.

Thanks for the clarification,

Kevin


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

Re: Enable runtime PM automatically?

[Kevin Hilman]

Geert Uytterhoeven ge...@linux-m68k.org writes:

 On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman khil...@kernel.org wrote:
 At a deeper level, the problem with this approach is that this is more
 generically a runtime PM dependency problem, not a genpd problem.  For
 example, what happens when the same kind of dependency exists on a
 platform using a custom PM domain instead of genpd (like ACPI.) ?

 What's needed to solve this problem is a generalized way to have runtime
 PM dependencies between devices.  Runtime PM already automatically
 handles parent devices as one type of dependent device (e.g. a parent
 device needs to be runtime PM resumed before its child.)  So what's
 needed is a generic way to other PM dependencies with the runtime PM
 core (not the genpd core.)

 If runtime PM handles the dependencies corretcly, then genpd (and any
 other PM domain) will get them for free.

 Having the proper dependencies is not sufficient. Currently drivers have to do
 something to use runtime PM.

Well, yes.  I've been assuming runtime-PM aware drivers.  But I agree
with the goal of not having to assume that.

 By default, runtime PM is disabled for a device
 (device.power.disable_depth = 1).

 However, if PM domains are active, drivers must be runtime PM-aware for the
 gpd_dev_ops.start() method to be called in the first place (perhaps this is 
 just
 one bug that's easy to fix --- the device is assumed suspended, but can be
 used). They must
   1. call pm_runtime_enable() to enable runtime PM for the device,
   2. call pm_runtime_get_sync() to prevent the device from being put in a
 low-power state at any time. This second call has the
 side-effect of calling
 gpd_dev_ops.start().

 Hence, if PM domains are enabled, wouldn't it make sense to
   1. enable runtime PM by default, for all devices (bound and unbound),
   2. call pm_runtime_get_sync(), for all devices bound to a driver.
 Of course we have to keep track if drivers call any of the pm_runtime_*()
 methods theirselves, as that would have to move them from automatic to
 manual mode.

 Would this be feasible?

We have to be careful about where the PM core's _get_sync() call goes.

Because you're talking about bound devices, I guess you mean after the
driver probes?  Otherwise, it gets tricky if the _get_sync() is before
the driver probes, because the device driver may have work it wants to
do in its runtime PM callbacks, which are not initialized/available
before the driver probes.  Doing this before probe also makes it rather
difficult to know for sure the actual physical state of the device, and
make sure it matches the runtime PM state of the device.  Rafael
mentioned this also, and I'm not sure how we can be sure of the physical
state.

Some thoughts: devices without drivers would be runtime resumed by the
core, but will never be suspended, so the PM domain will never shut
down.  I guess the core will have to keep track of the devices it
automatically runtime resumed and decide to runtime suspend them too?
Hmm, where would that go?

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

Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated

[Kevin Hilman]

On Wed, Dec 17, 2014 at 10:58 PM, Mike Turquette mturque...@linaro.org wrote:
 Quoting Mike Turquette (2014-12-17 07:23:22)
 Quoting Krzysztof Kozlowski (2014-12-16 00:20:15)
  On pon, 2014-12-15 at 14:26 -0800, Kevin Hilman wrote:
   Kevin Hilman khil...@kernel.org writes:
  
Sylwester Nawrocki s.nawro...@samsung.com writes:
   
On 09/12/14 13:59, Krzysztof Kozlowski wrote:
On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote:
 Audio subsystem clocks are located in separate block. On Exynos 
 5420 if
 clock for this block (from main clock domain) 'mau_epll' is gated 
 then
 any read or write to audss registers will block.

 This kind of boot hang was observed on Arndale Octa and Peach 
 Pi/Pit
 after introducing runtime PM to pl330 DMA driver. After that 
 commit the
 'mau_epll' was gated, because the amba clock was disabled and 
 there
 were no more users of mau_epll.

 The system hang on one of steps:
 1. Disabling unused clocks from audss block.
 2. During audss GPIO setup (just before probing i2s0 because
samsung_pinmux_setup() tried to access memory from audss block 
 which was
gated.

 Add a workaround for this by enabling the 'mau_epll' clock in 
 probe.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos-audss.c | 29 
 -
  1 file changed, 28 insertions(+), 1 deletion(-)
   
Sorry for pinging so quick but merge window is open and it looks like
booting Exynos542x boards will be broken (because pl330 will no 
longer
hold adma clock enabled so whole audss domain will be gated).
   
This is a non-intrusive workaround for that issue, as wanted by
Sylwester:
https://lkml.org/lkml/2014/12/5/223
   
Any comments on this?
   
The patch looks OK to me, it would be good though if someone else
has confirmed it fixes the bug. I don't have any clock patches queued
at the moment. Perhaps you could apply it directly, Mike ?
   
I confirm it fixes the boot hang in linux-next (next-20141210) on my
exynos5800-peach-pi and exynos5420-arndale-octa.  Tested both
exynos_defconfig and multi_v7_defconfig.
   
Tested-by: Kevin Hilman khil...@linaro.org
  
   What's the status of this patch?  linux-next is still broken for several
   Exynos5 platforms without this fix.
 
  I believe not only next is broken but also current mainline because
  runtime PM for pl330 was merged yesterday...
 
  The patch received two tested-bys (Kevin's and Javier's) and Sylwester's
  ack.
 
  Mike, could you pick the patch and send it to Linus after rc1?

 Will do.

 To be clear, I pulled this into clk-next towards -rc1, so it won't need
 to go through as an -rc fix.

This hit today's linux-next, and exynos5 platforms are happily booting
again.  Thanks!

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

Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types

[Kevin Hilman]

amit daniel kachhap amit.dan...@samsung.com writes:

 On Wed, Dec 17, 2014 at 3:40 AM, Kevin Hilman khil...@kernel.org wrote:
 Marek Szyprowski m.szyprow...@samsung.com writes:

 Hello,

 On 2014-12-13 17:51, Amit Daniel Kachhap wrote:
 Instead of using bool to restore suspended devices initially, use flags
 like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
 The first two flags will be similar to the existing true/false 
 functionality.
 The third flag may be used to force restore of suspended devices
 whenever their associated power domain is turned on.

 Currently, PD power off function powers off all the associated unused
 devices. The functionality added in this patch is similar to it.

 This feature may be used for those devices which are always in ON state
 if the PD associated with them is ON but may need local runtime resume
 and suspend during PD On/Off. These devices (like clock) may not implement
 complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to
 subsystems interaction behaviour or any other reason.

 The model works like,
  DEV1 (Attaches itself with PD but no calls to pm_runtime_get and
  /   pm_runtime_put. Its local runtime_suspend/resume is invoked 
 via
 /GPD_DEV_RESTORE_FORCE option)
/
 PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and
\ pm_runtime_put. This in turn invokes PD On/Off)
 \
  DEV3 (Similar to DEV1)

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

 The idea of adding new gen_pd flag and reusing runtime pm calls intead
 of additional notifiers looks promising, but I have some doubts.

 I agree, this is better than notifiers, but I have some doubts too.

 Thanks,


 don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag
 will be suspended after all normal devices and restored before
 them. Without such assumption it will be hard to use this approach for
 iommu related activities, because device might need to use (in its
 suspend/resume callbacks) the functionality provided by the other
 device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags
 like suspend/resume priority (or more flags) will solve somehow this
 dependency.

 At a deeper level, the problem with this approach is that this is more
 generically a runtime PM dependency problem, not a genpd problem.  For
 example, what happens when the same kind of dependency exists on a
 platform using a custom PM domain instead of genpd (like ACPI.) ?

 This patch does not try to solve runtime PM dependencies between
 devices. As an example, if there are three devices D1, D2, D3 in a
 power domain. Device D3 would update the power domain state
 requirement using runtime PM API but devices D1 and D2 do not want to
 control the domain but just want to be notified when the power domain
 state changes.

Yes, I understand that.  

The question is: what do you do when you have the same dependency
problem and you're not using genpd (for example, some SoCs have
implmeented their own PM domains, and ACPI devices are managed by their
own PM domain, not genpd.)

 What's needed to solve this problem is a generalized way to have runtime
 PM dependencies between devices.  Runtime PM already automatically
 handles parent devices as one type of dependent device (e.g. a parent
 device needs to be runtime PM resumed before its child.)  So what's
 needed is a generic way to other PM dependencies with the runtime PM
 core (not the genpd core.)

 Considering the example above with three devices, device D1 and D2 are
 passive components in this power domain. These devices only need to
 know the state changes of the power domains but would not control the
 power domain themselves nor put forth constraints in the power domain
 state changes. So I did not clearly understand as to how this example
 could be solved by introducing changes in runtime PM core.

Your solution only solves the problems for devices managed by genpd.

If I understood your example correctly, what you really want to solve
this problem more generically is to be able to tell the runtime PM core
that D3 has a dependency on D1 and D2.  Then, whenver the runtime PM
core is doing get/put operations for D3, it needs to also do them for D1
and D2.

This will accomplish the same as your proposed approach, but work for
any devices in any PM domains.

Kevin

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

Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types

[Kevin Hilman]

Marek Szyprowski m.szyprow...@samsung.com writes:

 Hello,

 On 2014-12-13 17:51, Amit Daniel Kachhap wrote:
 Instead of using bool to restore suspended devices initially, use flags
 like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
 The first two flags will be similar to the existing true/false functionality.
 The third flag may be used to force restore of suspended devices
 whenever their associated power domain is turned on.

 Currently, PD power off function powers off all the associated unused
 devices. The functionality added in this patch is similar to it.

 This feature may be used for those devices which are always in ON state
 if the PD associated with them is ON but may need local runtime resume
 and suspend during PD On/Off. These devices (like clock) may not implement
 complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to
 subsystems interaction behaviour or any other reason.

 The model works like,
  DEV1 (Attaches itself with PD but no calls to pm_runtime_get and
  /   pm_runtime_put. Its local runtime_suspend/resume is invoked via
 /GPD_DEV_RESTORE_FORCE option)
/
 PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and
\ pm_runtime_put. This in turn invokes PD On/Off)
 \
  DEV3 (Similar to DEV1)

 Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com

 The idea of adding new gen_pd flag and reusing runtime pm calls intead
 of additional notifiers looks promising, but I have some doubts. 

I agree, this is better than notifiers, but I have some doubts too.

 don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag
 will be suspended after all normal devices and restored before
 them. Without such assumption it will be hard to use this approach for
 iommu related activities, because device might need to use (in its
 suspend/resume callbacks) the functionality provided by the other
 device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags
 like suspend/resume priority (or more flags) will solve somehow this
 dependency.

At a deeper level, the problem with this approach is that this is more
generically a runtime PM dependency problem, not a genpd problem.  For
example, what happens when the same kind of dependency exists on a
platform using a custom PM domain instead of genpd (like ACPI.) ?

What's needed to solve this problem is a generalized way to have runtime
PM dependencies between devices.  Runtime PM already automatically
handles parent devices as one type of dependent device (e.g. a parent
device needs to be runtime PM resumed before its child.)  So what's
needed is a generic way to other PM dependencies with the runtime PM
core (not the genpd core.)

If runtime PM handles the dependencies corretcly, then genpd (and any
other PM domain) will get them for free.

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

Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated

[Kevin Hilman]

Kevin Hilman khil...@kernel.org writes:

 Sylwester Nawrocki s.nawro...@samsung.com writes:

 On 09/12/14 13:59, Krzysztof Kozlowski wrote:
 On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote:
  Audio subsystem clocks are located in separate block. On Exynos 5420 if
  clock for this block (from main clock domain) 'mau_epll' is gated then
  any read or write to audss registers will block.
  
  This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit
  after introducing runtime PM to pl330 DMA driver. After that commit the
  'mau_epll' was gated, because the amba clock was disabled and there
  were no more users of mau_epll.
  
  The system hang on one of steps:
  1. Disabling unused clocks from audss block.
  2. During audss GPIO setup (just before probing i2s0 because
 samsung_pinmux_setup() tried to access memory from audss block which 
  was
 gated.
  
  Add a workaround for this by enabling the 'mau_epll' clock in probe.
  
  Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
  ---
   drivers/clk/samsung/clk-exynos-audss.c | 29 
  -
   1 file changed, 28 insertions(+), 1 deletion(-)

 Sorry for pinging so quick but merge window is open and it looks like
 booting Exynos542x boards will be broken (because pl330 will no longer
 hold adma clock enabled so whole audss domain will be gated).
 
 This is a non-intrusive workaround for that issue, as wanted by
 Sylwester:
 https://lkml.org/lkml/2014/12/5/223
 
 Any comments on this?

 The patch looks OK to me, it would be good though if someone else
 has confirmed it fixes the bug. I don't have any clock patches queued
 at the moment. Perhaps you could apply it directly, Mike ?

 I confirm it fixes the boot hang in linux-next (next-20141210) on my
 exynos5800-peach-pi and exynos5420-arndale-octa.  Tested both
 exynos_defconfig and multi_v7_defconfig.

 Tested-by: Kevin Hilman khil...@linaro.org

What's the status of this patch?  linux-next is still broken for several
Exynos5 platforms without this fix.

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

Re: [PATCH v4 0/3] Fix Arndale Octa/Peach Pi boot on Audio subsystem clocks

[Kevin Hilman]

Hi Krzysztof,

Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 Changes since v3
 
 1. Patch 1/3: Fix issues pointed by Sylwester.
 2. Add Javier's tested-by [1]

I tested this series on top of next-20141210 (exynos_defconfig and
multi_v7_defconfig) on exynos5800-peach-pi and exynos5420-arndale-octa
it fixes the boot hangs I was seeing with linux-next on those platforms.

Feel free to add:

Tested-by: Kevin Hilman khil...@linaro.org

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

Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated

[Kevin Hilman]

Sylwester Nawrocki s.nawro...@samsung.com writes:

 On 09/12/14 13:59, Krzysztof Kozlowski wrote:
 On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote:
  Audio subsystem clocks are located in separate block. On Exynos 5420 if
  clock for this block (from main clock domain) 'mau_epll' is gated then
  any read or write to audss registers will block.
  
  This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit
  after introducing runtime PM to pl330 DMA driver. After that commit the
  'mau_epll' was gated, because the amba clock was disabled and there
  were no more users of mau_epll.
  
  The system hang on one of steps:
  1. Disabling unused clocks from audss block.
  2. During audss GPIO setup (just before probing i2s0 because
 samsung_pinmux_setup() tried to access memory from audss block which 
  was
 gated.
  
  Add a workaround for this by enabling the 'mau_epll' clock in probe.
  
  Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
  ---
   drivers/clk/samsung/clk-exynos-audss.c | 29 -
   1 file changed, 28 insertions(+), 1 deletion(-)

 Sorry for pinging so quick but merge window is open and it looks like
 booting Exynos542x boards will be broken (because pl330 will no longer
 hold adma clock enabled so whole audss domain will be gated).
 
 This is a non-intrusive workaround for that issue, as wanted by
 Sylwester:
 https://lkml.org/lkml/2014/12/5/223
 
 Any comments on this?

 The patch looks OK to me, it would be good though if someone else
 has confirmed it fixes the bug. I don't have any clock patches queued
 at the moment. Perhaps you could apply it directly, Mike ?

I confirm it fixes the boot hang in linux-next (next-20141210) on my
exynos5800-peach-pi and exynos5420-arndale-octa.  Tested both
exynos_defconfig and multi_v7_defconfig.

Tested-by: Kevin Hilman khil...@linaro.org

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

Re: [PATCH v2] ARM: dts: Add dts file for odroid XU3 board

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
 same as the vendors naming, which means it's prefixed with exynos5422
 instead of exynos5800 as the SoC name even though it includes the
 exyno5800 dtsi.

 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
 Changes since v1:
   * Add chosen/linux,stdout-path to point the serial console device
   * Change memory start offset to 0x4000 to match the vendors DTS (pointed
 out by Heesub Shin)
   * Declare base address  size for the memory banks to be used by the MFC

 Kevin, Tyler, even though the changes are small i didn't want to just stick
 your Tested-By on. Could you both be so kind to retest this on your XU3's ?

Tested-by: Kevin Hilman khil...@linaro.org

Tested on top of linux-next(ish) and Javier's dp-integ branch and it's
booting fine including HDMI display output.

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

Re: [PATCH] ARM: dts: Add dts file for odroid XU3 board

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 Add DTS for the Hardkernel Odroid XU3. The name of the DTS file is kept the
 same as the vendors naming, which means it's prefixed with exynos5422
 instead of exynos5800 as the SoC name even though it includes the
 exyno5800 dtsi.

 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk

Tested-by: Kevin Hilman khil...@linaro.org

Tried this on top of linux-next (next-20141125 and next20141203) and
boots fine on my odroid-xu3. 

Thanks for doing this, I've been meaning to get a DTS upstream for this
platform myself.  I also noticed that the imprecise aborts I've been
seeing when booting this board with the smdk5420 DTS are gone, so I
don't have to dig into those now either.  Thanks!  :)

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

Re: [PATCH v2 2/7] ARM: Exynos: add support for sub-power domains

[Kevin Hilman]

Marek Szyprowski m.szyprow...@samsung.com writes:

 Hello,

 On 2014-12-03 13:36, Geert Uytterhoeven wrote:
 Hi Marek,

 On Wed, Dec 3, 2014 at 1:33 PM, Marek Szyprowski
 m.szyprow...@samsung.com wrote:
 diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
 b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 index abde1ea8a119..b884358ebb1a 100644
 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 @@ -22,6 +22,8 @@ Optional Properties:
  - pclkN, clkN: Pairs of parent of input clock and input clock to 
 the
  devices in this power domain. Maximum of 4 pairs (N = 0 to 
 3)
  are supported currently.
 +- samsung,power-domain: phandle to a master power domain that the given 
 domain
 +  is a part of
 For new DTSes I'd recommend using the generic power-domains only.

 I think that some consistency in dts style will be really an added
 value. In my opinion for
 all existing DTSes we should keep using 'samsung,power-domain' (even
 for defining a parent
 power domains) and for all new DTSes, the generic 'power-domains'
 binding should be used.

Or even better, convert the existing DTSs to use generic power-domain
first, and then use generic ones going forward also.

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

Re: [PATCH] ARM: dts: Add dts file for odroid XU3 board

[Kevin Hilman]

Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:

 On Wed, 2014-12-03 at 11:53 -0800, Kevin Hilman wrote:
 Sjoerd Simons sjoerd.sim...@collabora.co.uk writes:
 Tried this on top of linux-next (next-20141125 and next20141203) and
 boots fine on my odroid-xu3. 
 
 Thanks for doing this, I've been meaning to get a DTS upstream for this
 platform myself.  I also noticed that the imprecise aborts I've been
 seeing when booting this board with the smdk5420 DTS are gone, so I
 don't have to dig into those now either.  Thanks!  :)

 For completeness, the problem with running the smdk5420 DTS on the XU3
 is that the XU3 runs secure firmware while the SMD5420 doesn't.. Hence
 the imprecise aborts you were seeing.

OK, that's what I suspected but didn't take the time to verify.  Thanks
for the update.

BTW, I'll have some DTS updates for the xu3 to enable the on-board
INA2xx current sensors for easy power measurements without external
instrumentation.  Will send a patch for those soon.

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

Re: [PATCH RFT 2/2] arm: dts: disable CCI on exynos420 based arndale-octa

[Kevin Hilman]

Abhilash Kesavan a.kesa...@samsung.com writes:

 The arndale-octa board was giving imprecise external aborts during
 boot-up with MCPM enabled. CCI enablement of the boot cluster was found
 to be the cause of these aborts (possibly because the secure f/w was not
 allowing it). Hence, disable CCI for the arndale-octa board.

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

Tested-by: Kevin Hilman khil...@linaro.org

Tested on top of next-20141128 with exynos_defconfig on my Octa board
and I'm not seeing the imprecise aborts anymore.  

Thanks,

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

Re: [PATCH V4 1/3] PM / Domains: Initial PM clock support for genpd

[Kevin Hilman]

Ulf Hansson ulf.hans...@linaro.org writes:

 It's quite common for PM domains to use PM clocks. Typically from SOC
 specific code, the per device PM clock list is created and
 pm_clk_suspend|resume() are invoked to handle clock gating/ungating.

 A step towards consolidation is to integrate PM clock support into
 genpd, which is what this patch does.

 In this initial step, the calls to the pm_clk_suspend|resume() are
 handled within genpd, but the per device PM clock list still needs to
 be created from SOC specific code. It seems reasonable to have gendp to
 handle that as well, but that left to future patches to address.

 It's not every users of genpd that are keen on using PM clocks, thus we
 need to provide this a configuration option for genpd. Therefore let's
 add flag field in the genpd struct to keep this information and define
 a new GENDP_FLAG_PM_CLK bit for it.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 Acked-by: Geert Uytterhoeven geert+rene...@glider.be

Acked-by: Kevin Hilman khil...@linaro.org

Are you also planning to add a way to enable this option from DT?

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

Re: [RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?

[Kevin Hilman]

Hello,

Heesub Shin heesub.s...@samsung.com writes:

 Using the current exynos_defconfig on the exynos5422-odroid-xu3, only
 6 of 8 CPUs come online with MCPM boot.  CPU0 is an A7, CPUs 1-4 are
 A15s and CPU5-7 are the other A7s, but with the current code, CPUs 5
 and 7 do not boot:
 
[...]
Exynos MCPM support installed
CPU1: update cpu_capacity 1535
CPU1: thread -1, cpu 0, socket 0, mpidr 8000
CPU2: update cpu_capacity 1535
CPU2: thread -1, cpu 1, socket 0, mpidr 8001
CPU3: update cpu_capacity 1535
CPU3: thread -1, cpu 2, socket 0, mpidr 8002
CPU4: update cpu_capacity 1535
CPU4: thread -1, cpu 3, socket 0, mpidr 8003
CPU5: failed to come online
CPU6: update cpu_capacity 448
CPU6: thread -1, cpu 2, socket 1, mpidr 8102
CPU7: failed to come online
Brought up 6 CPUs
CPU: WARNING: CPU(s) started in wrong/inconsistent modes
(primary CPU mode 0x13)
CPU: This may indicate a broken bootloader or firmware.
 
 Thanks to a tip from Abhilash, this patch gets all 8 CPUs booting
 again, but the warning about CPUs started in inconsistent modes
 remains.  Also, not being terribly familiar with Exynos internals,
 it's not at all obvious to me why this register write (done for *all*
 secondaries) makes things work works for the 2 secondary CPUs that
 didn't come online.  It's also not obvious whether this is the right
 general fix, since it doesn't seem to be needed on other 542x or 5800
 platforms.

 Very interesting to see your post. I was also suffering from the same 
 problem with my Odroid-XU3 board. With your patch 8 CPUs are brought up, 
 but Cortex-A15 CPUs are always offline, showing low performance.

 heesub@odroid:~$ cat /sys/devices/system/cpu/online
 0,5-7
 heesub@odroid:~$ cat /sys/devices/system/cpu/offline
 1-4

 Any suggestion?

That's probably because you have the big.LITTLE switcher enabled in your
.config (which is the default when using exynos_defconfig).

If you modify your .config and set CONFIG_BL_SWITCHER=n, you will see
all 8 cores online.

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

Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

Abhilash Kesavan kesavan.abhil...@gmail.com writes:

 Hi Kevin,

 On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman khil...@kernel.org wrote:
 Hi Abhilash,

 Abhilash Kesavan kesavan.abhil...@gmail.com writes:

 [...]

 To be honest, since I don't have the exynos5420 arndale, chromebook...but 
 smdk
 which has different bootloader, I couldn't test it...I'll try to make a 
 test
 farm like you guys...

 Do you have some colleagues with any other 542x hardware?  I had
 assumed that linux-next was being better tested on the publicaly
 available, and widely available boards like odroid-xu3 and
 Chromebook2, but I've come to realize the hard way that that is not

 Are you seeing this on Chromebook2 (Peach-Pi 5800) too ?

 No, it seems that my exynos5800-peach-pi is not having this problem,
 which suggests it's a bootloader setup issue.

 the case.  You mention your board has a different bootloader.  Do you
 suspect there's a bootloader issue on these other platforms?  If so,
 could you elaborate on possible fixes?  I'm more than willing to test
 any proposed fixes, but I'm not familiar enough yet with these SoCs to
 figure out the underlying issues alone.

 Until you have a working board farm, you could start having a closer
 look at the boot logs we're already producing.  Admittedly linux-next
 broken in many ways besides this one for exynos currently, but it has
 been having these imprecise aborts well before the other recent
 issues.

 Also, It's very possible that this issue is not even MCPM related at
 all, and MCPM is just uncovering a previously hidden bug.  It would be
 very helpful if people more familiar with this hardware and SoC would
 investigate bug reports like these.

 The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and
 Chromebook Peach-Pit) work fine with MCPM enabled.

 Thanks for helping look into this.

 I am not sure why
 it is failing only on the above mentioned boards as there is nothing
 specific to them in the MCPM back-end.

 I assume that when you default to platsmp (on disabling MCPM), the
 non-working boards boot all cores upto userspace without any issues ?

 Nope.  With MCPM disabled:

   - 5420/arndale-octa: CPU0-3 come up (A15s)
   - 5422/odroid-xu3: only CPU0 (A7)
   - 5800/peach-pi: only CPU0 (A15)

 Note that with MCPM enabled, the arndale-octa gets the same result.
 Peach-pi on the other hand gets all 8 CPUs, and the odroid-xu3 only gets
 6/8 CPUs (see other thread on that topic.)

 Based on the timeline (problems started about 2.5 months back), there
 have only been a couple of changes in the 5420 MCPM back-end. Could
 you revert the following commits and check if things improve.

 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800
 fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster
 using the MCPM loopback

 These might not revert cleanly, so instead of the above you could also
 comment the following 2 lines:


 diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
 b/arch/arm/mach-exynos/mcpm-exynos.c
 index dc9a764..9a07188 100644
 --- a/arch/arm/mach-exynos/mcpm-exynos.c
 +++ b/arch/arm/mach-exynos/mcpm-exynos.c
 @@ -152,7 +152,7 @@ static void exynos_power_down(void)
 exynos_cpu_power_down(cpunr);

 if (exynos_cluster_unused(cluster)) {
 -   exynos_cluster_power_down(cluster);
 +   //exynos_cluster_power_down(cluster);
 last_man = true;
 }
 2 } else if (cpu_use_count[cpu][cluster] == 1) {
 @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void)
 ret = mcpm_platform_register(exynos_power_ops);
 if (!ret)
 ret = mcpm_sync_init(exynos_pm_power_up_setup);
 -   if (!ret)
 -   ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
 +   //if (!ret)
 +   //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI 
 */
 if (ret) {
 iounmap(ns_sram_base_addr);
 return ret;



 If you still get aborts then I suspect that the problem is with the
 bootloader configuration but am not sure.

 Nice.  With those lines commented out, the arndale-octa is not geting
 imprecise aborts anymore, and this is the platform where those aborts
 seem to prevent booting into a full userspace (as originally reported by
 Tyler.)

 More specifically, with only the loopback call to turn off CCI commented
 out, the imprecise aborts go away.

 I can't see how enabling snoops for the boot cluster is causing these
 aborts. Perhaps as Krzysztof commented it has something to do with the
 secure firmware/tz software on these boards ? Other than there does
 not appear to be any difference between the working/non-working
 setups.

Perhaps the secure firmware is preventing the CCI to be enabled by the
kernel, and that is causing the imprecise abort?

Is there a way to update/replace the BL1/BL2/TZ firmware blobs with
something that is known

Re: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

[Kevin Hilman]

Kevin Hilman khil...@kernel.org writes:

 Hi Thomas,

 Thomas Abraham thomas...@samsung.com writes:

 Changes since v11:
 - Rebased on top of git://linuxtv.org/snawrocki/samsung.git 
 for-v3.19-exynos-clk

 Thanks for rebasing/reposting.

 This patch series removes the use of Exynos4210 and Exynos5250 specific 
 cpufreq
 drivers and enables the use of cpufreq-dt driver for these platforms. This
 series also enables cpufreq support for Exynos5420 using arm_big_little 
 cpufreq
 driver.

 This series is based on the following branch.
 git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk

 This series depends on the following patch which can be picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git samsung/dt
 e540920cf21c (ARM: dts: add CPU nodes for Exynos4 SoCs).

 This patch series has been tested on Exynos4210/5250/5420 based boards.
 Tomasz Figa had plans to take this in the Samsung clock tree for v3.19
 (http://www.spinics.net/lists/linux-samsung-soc/msg37933.html).
 Sylwester, could you consider to merge this in your tree?

 I tested this on exynos5800-peach-pi, and noticed a few things.

 First, since voltage scaling is not currently supported, the CPU cluster
 regulators (vdd_arm, and vdd_kfc) have to be set at sufficietnly high
 voltage to support all the OPPs, otherwise things will likely hang.  I
 think you should include something like the patch below[1] in this
 series as well.

 Second, as with earlier versions of this series, I'm still seeing lots
 of wait_until_divider_stable: timeout in divider stablization messages
 coming out when running powertop.

And, I just found another issue:

On exynos5800-peach-pi, setting the cpufreq default governor to
performance at compile time (CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y)
makes the kernel boot hang when the cpufreq driver is initialized.

However, setting the compile-time default to the userspace governor, and
then setting the performance governor via sysfs after the boot finishes
seems to work fine.

Kevin


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

Re: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

[Kevin Hilman]

Hi Thomas,

On Mon, Nov 24, 2014 at 10:58 AM, Kevin Hilman khil...@kernel.org wrote:

[...]

 Second, as with earlier versions of this series, I'm still seeing lots
 of wait_until_divider_stable: timeout in divider stablization messages
 coming out when running powertop.

I found a simpler way to reproduce these messages.  If I simply use
the userspace governor and cycle through all the A7 OPPs, I'll hit
this message (script below[1]).  Note that I'm also using my DTS
change that fixes the vdd_arm and vdd_kfc voltages to a voltage that
is high enough for all the OPPs.

Kevin

[1]
#!/bin/sh
cpu=cpu4
reg_name=vdd_kfc
cpu_reg=$(dirname `find /sys/class/regulator/regulator.*/ -name name
-exec grep -l $reg_name {} \;`)
echo $cpu_reg

# Cycle through frequencies (and check voltage)
cd /sys/devices/system/cpu/$cpu/cpufreq
echo userspace  scaling_governor
for freq in `cat scaling_available_frequencies`; do
  echo ${freq}  scaling_setspeed
  echo -n current freq: 
  cat scaling_cur_freq
  echo -n current voltage: 
  cat ${cpu_reg}/microvolts
  sleep 1
done
--
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: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

Hi Abhilash,

Abhilash Kesavan kesavan.abhil...@gmail.com writes:

[...]

 To be honest, since I don't have the exynos5420 arndale, chromebook...but 
 smdk
 which has different bootloader, I couldn't test it...I'll try to make a test
 farm like you guys...

 Do you have some colleagues with any other 542x hardware?  I had
 assumed that linux-next was being better tested on the publicaly
 available, and widely available boards like odroid-xu3 and
 Chromebook2, but I've come to realize the hard way that that is not

 Are you seeing this on Chromebook2 (Peach-Pi 5800) too ?

No, it seems that my exynos5800-peach-pi is not having this problem,
which suggests it's a bootloader setup issue.

 the case.  You mention your board has a different bootloader.  Do you
 suspect there's a bootloader issue on these other platforms?  If so,
 could you elaborate on possible fixes?  I'm more than willing to test
 any proposed fixes, but I'm not familiar enough yet with these SoCs to
 figure out the underlying issues alone.

 Until you have a working board farm, you could start having a closer
 look at the boot logs we're already producing.  Admittedly linux-next
 broken in many ways besides this one for exynos currently, but it has
 been having these imprecise aborts well before the other recent
 issues.

 Also, It's very possible that this issue is not even MCPM related at
 all, and MCPM is just uncovering a previously hidden bug.  It would be
 very helpful if people more familiar with this hardware and SoC would
 investigate bug reports like these.

 The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and
 Chromebook Peach-Pit) work fine with MCPM enabled. 

Thanks for helping look into this.

 I am not sure why
 it is failing only on the above mentioned boards as there is nothing
 specific to them in the MCPM back-end.

 I assume that when you default to platsmp (on disabling MCPM), the
 non-working boards boot all cores upto userspace without any issues ?

Nope.  With MCPM disabled:

  - 5420/arndale-octa: CPU0-3 come up (A15s)
  - 5422/odroid-xu3: only CPU0 (A7)
  - 5800/peach-pi: only CPU0 (A15)

Note that with MCPM enabled, the arndale-octa gets the same result.
Peach-pi on the other hand gets all 8 CPUs, and the odroid-xu3 only gets
6/8 CPUs (see other thread on that topic.)

 Based on the timeline (problems started about 2.5 months back), there
 have only been a couple of changes in the 5420 MCPM back-end. Could
 you revert the following commits and check if things improve.

 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800
 fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster
 using the MCPM loopback

 These might not revert cleanly, so instead of the above you could also
 comment the following 2 lines:


 diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
 b/arch/arm/mach-exynos/mcpm-exynos.c
 index dc9a764..9a07188 100644
 --- a/arch/arm/mach-exynos/mcpm-exynos.c
 +++ b/arch/arm/mach-exynos/mcpm-exynos.c
 @@ -152,7 +152,7 @@ static void exynos_power_down(void)
 exynos_cpu_power_down(cpunr);

 if (exynos_cluster_unused(cluster)) {
 -   exynos_cluster_power_down(cluster);
 +   //exynos_cluster_power_down(cluster);
 last_man = true;
 }
2 } else if (cpu_use_count[cpu][cluster] == 1) {
 @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void)
 ret = mcpm_platform_register(exynos_power_ops);
 if (!ret)
 ret = mcpm_sync_init(exynos_pm_power_up_setup);
 -   if (!ret)
 -   ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
 +   //if (!ret)
 +   //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
 if (ret) {
 iounmap(ns_sram_base_addr);
 return ret;



 If you still get aborts then I suspect that the problem is with the
 bootloader configuration but am not sure. 

Nice.  With those lines commented out, the arndale-octa is not geting
imprecise aborts anymore, and this is the platform where those aborts
seem to prevent booting into a full userspace (as originally reported by
Tyler.)

More specifically, with only the loopback call to turn off CCI commented
out, the imprecise aborts go away.

The odroid-xu3 is still getting them, but these seem to happen whether
or not MCPM is enabled, so must a different issue related to the
bootloader setup.

 I am OK with disabling
 5420_MCPM in the default configuration in such a case. This would
 however mean that S2R also stops working by default on 5420.

Disabling the option isn't my first choice either, I would rather see
this issue debugged and fixed by folks that are more familiar with MCPM
on Exynos.

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

Re: screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2

[Kevin Hilman]

Hi Vivek,

Vivek Gautam gautamvivek1...@gmail.com writes:

 On Sat, Nov 22, 2014 at 12:53 AM, Kevin Hilman khil...@kernel.org wrote:
 Hi Ajay,

 AJAY KUMAR RAMAKRISHNA SHYMALAMMA ajaykumar...@samsung.com writes:

 I tried to reproduce the issue which you reported,

 but I am sorry I am not able to reproduce it.

 I tried with my patches for DRM on top of Linux-next.

 I don't see the issue on linux-next either.  As I mentioned in the
 original post, I only see it on the v3.18 branch in the exynos-reference
 tree.

 While checking the issue along with Ajay on exynos5-v3.18-rc2 branch
 on exynos-reference
 tree, we found out the culprit to be FIMD-SYSMMU.
 The IOMMU on exynos systems is still WIP, and that's the reason it is
 disabled in
 exynos_defconfig too.
 So we have a small workaround in this branch to stop using FIMD-SYSMMUs.

 Now, at the bootup time things are OK, since the FIMD-SMMU clocks
 (CLK_SMMU_FIMD**)
 are still available. But after bootup all unused clocks are disabled
 (since we don't want to
 use clk_ignore_unused in boot arguments), and the consequent 
 blanking-unblanking
 causes the system to hang.

 So we have pushed a patch on the same branch exynos5-v3.18-rc2 which sets
 CLK_IGNORE_UNUSED flag for these SMMU_FIMD** clocks.

 This fixes the issue of hang what we were seeing.

 There's another branch exynos5-v3.18-rc5 available, and we have
 pushed the same patch
 on that branch too.
 Please test on your side, and do let us know if things are working fine for 
 you.

I've tested the -rc5 branch, and I'm not seeing this issue anymore.

Thanks,

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

Re: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

[Kevin Hilman]

Hi Thomas,

Thomas Abraham thomas...@samsung.com writes:

 Changes since v11:
 - Rebased on top of git://linuxtv.org/snawrocki/samsung.git 
 for-v3.19-exynos-clk

Thanks for rebasing/reposting.

 This patch series removes the use of Exynos4210 and Exynos5250 specific 
 cpufreq
 drivers and enables the use of cpufreq-dt driver for these platforms. This
 series also enables cpufreq support for Exynos5420 using arm_big_little 
 cpufreq
 driver.

 This series is based on the following branch.
 git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk

 This series depends on the following patch which can be picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git samsung/dt
 e540920cf21c (ARM: dts: add CPU nodes for Exynos4 SoCs).

 This patch series has been tested on Exynos4210/5250/5420 based boards.
 Tomasz Figa had plans to take this in the Samsung clock tree for v3.19
 (http://www.spinics.net/lists/linux-samsung-soc/msg37933.html).
 Sylwester, could you consider to merge this in your tree?

I tested this on exynos5800-peach-pi, and noticed a few things.

First, since voltage scaling is not currently supported, the CPU cluster
regulators (vdd_arm, and vdd_kfc) have to be set at sufficietnly high
voltage to support all the OPPs, otherwise things will likely hang.  I
think you should include something like the patch below[1] in this
series as well.

Second, as with earlier versions of this series, I'm still seeing lots
of wait_until_divider_stable: timeout in divider stablization messages
coming out when running powertop.

Speaking of powertop, in the frequency stats tab, I'm not seeing 0%
time spent in all the P-states, so not sure what's going on there.  The
stats/time_in_state sysfs files under cpufreq seem to show the right
values, so I'm not sure what's going on with powertop there.

Kevin

[1]
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e8fdda827fc9..5160735aad3b 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -195,8 +195,8 @@

buck2_reg: BUCK2 {
regulator-name = vdd_arm;
-   regulator-min-microvolt = 80;
-   regulator-max-microvolt = 150;
+   regulator-min-microvolt = 125;
+   regulator-max-microvolt = 125;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
@@ -230,8 +230,8 @@

buck6_reg: BUCK6 {
regulator-name = vdd_kfc;
-   regulator-min-microvolt = 80;
-   regulator-max-microvolt = 150;
+   regulator-min-microvolt = 1275000;
+   regulator-max-microvolt = 1275000;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;



 Thomas Abraham (6):
   clk: samsung: add infrastructure to register cpu clocks
   clk: samsung: add cpu clock configuration data and instantiate cpu clock
   ARM: dts: Exynos: add CPU OPP and regulator supply property
   ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
   cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
   clk: samsung: remove unused clock aliases and update clock flags

  arch/arm/boot/dts/exynos4210-origen.dts |4 +
  arch/arm/boot/dts/exynos4210-trats.dts  |4 +
  arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +
  arch/arm/boot/dts/exynos4210.dtsi   |   14 ++-
  arch/arm/boot/dts/exynos5250-arndale.dts|4 +
  arch/arm/boot/dts/exynos5250-smdk5250.dts   |4 +
  arch/arm/boot/dts/exynos5250-snow.dts   |4 +
  arch/arm/boot/dts/exynos5250.dtsi   |   25 +++-
  arch/arm/boot/dts/exynos5420.dtsi   |   38 
  arch/arm/mach-exynos/exynos.c   |   26 +++-
  drivers/clk/samsung/Makefile|2 +-
  drivers/clk/samsung/clk-exynos4.c   |   63 +---
  drivers/clk/samsung/clk-exynos5250.c|   44 -
  drivers/clk/samsung/clk-exynos5420.c|   72 +++-
  drivers/cpufreq/Kconfig.arm |   22 ---
  drivers/cpufreq/Makefile|2 -
  drivers/cpufreq/exynos4210-cpufreq.c|  184 
  drivers/cpufreq/exynos5250-cpufreq.c|  210 
 ---
  include/dt-bindings/clock/exynos5250.h  |1 +
  include/dt-bindings/clock/exynos5420.h  |2 +
  20 files changed, 266 insertions(+), 463 deletions(-)
  delete mode 100644 

Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

Kukjin,

On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote:
 Kukjin Kim kg...@kernel.org writes:

 Kevin Hilman wrote:

 From: Kevin Hilman khil...@linaro.org

 The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
 during boot testing, causing various userspace startup failures.

 Disable until it has gotten more testing.

 Cc: Kukjin Kim kgene@samsung.com,
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
 Cc: Sachin Kamat sachin.ka...@samsung.com,
 Cc: Doug Anderson diand...@chromium.org,
 Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
 Cc: Tushar Behera tushar.beh...@linaro.org,
 Cc: sta...@vger.kernel.org # v3.17+
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 This has been reported by a few people[1], but not investigated or fixed, 
 so it's
 time to disable this feature until it can be fixed.

 Hi Kevin,

 Yeah I agree with your opinion.

 But as you can see my tree, I've queued regarding mcpm patches for 3.19 will
 be shown in -next in this weekend.

 Which of the recently queued patches are expected to address the
 imprecise abort issue?  I'd be happy to test them out.

Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort.

What is the status of $SUBJECT patch?

 Anyway let me apply this into -fixes and
 then let's enable after test its functionality in -next in a couple of days.

 Yes, I think this needs to be applied until these aborts are understood
 and fixed.

Is anyone at Samsung actually looking into these MCPM issues?

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

Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote:
 On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote:
 Kukjin,

 On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote:
 Kukjin Kim kg...@kernel.org writes:

 Kevin Hilman wrote:

 From: Kevin Hilman khil...@linaro.org

 The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
 during boot testing, causing various userspace startup failures.

 Disable until it has gotten more testing.

 Cc: Kukjin Kim kgene@samsung.com,
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
 Cc: Sachin Kamat sachin.ka...@samsung.com,
 Cc: Doug Anderson diand...@chromium.org,
 Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
 Cc: Tushar Behera tushar.beh...@linaro.org,
 Cc: sta...@vger.kernel.org # v3.17+
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 This has been reported by a few people[1], but not investigated or fixed, 
 so it's
 time to disable this feature until it can be fixed.

 Hi Kevin,

 Yeah I agree with your opinion.

 But as you can see my tree, I've queued regarding mcpm patches for 3.19 
 will
 be shown in -next in this weekend.

 Which of the recently queued patches are expected to address the
 imprecise abort issue?  I'd be happy to test them out.

 Exynos5 MCPM is still broken in linux-next and still causing an imprecise 
 abort.

 What is the status of $SUBJECT patch?

 Anyway let me apply this into -fixes and
 then let's enable after test its functionality in -next in a couple of 
 days.

 Yes, I think this needs to be applied until these aborts are understood
 and fixed.

 Is anyone at Samsung actually looking into these MCPM issues?

 Hi Kevin,

 What hardware are you having problems with? 5420 or 5422/5800?

Yes.  :)

exynos5420-arndale-octa:
http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
exynos5422-odroid-xu3:
http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html

My boot tests seem to pass fine because I have such a minimal
userspace, but Tyler Baker reported that with a real userspace, he
can't boot to a shell:

  
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html

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

Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote:
 On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote:
 On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote:
 On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote:
 Kukjin,

 On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote:
 Kukjin Kim kg...@kernel.org writes:

 Kevin Hilman wrote:

 From: Kevin Hilman khil...@linaro.org

 The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
 during boot testing, causing various userspace startup failures.

 Disable until it has gotten more testing.

 Cc: Kukjin Kim kgene@samsung.com,
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
 Cc: Sachin Kamat sachin.ka...@samsung.com,
 Cc: Doug Anderson diand...@chromium.org,
 Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
 Cc: Tushar Behera tushar.beh...@linaro.org,
 Cc: sta...@vger.kernel.org # v3.17+
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 This has been reported by a few people[1], but not investigated or 
 fixed, so it's
 time to disable this feature until it can be fixed.

 Hi Kevin,

 Yeah I agree with your opinion.

 But as you can see my tree, I've queued regarding mcpm patches for 3.19 
 will
 be shown in -next in this weekend.

 Which of the recently queued patches are expected to address the
 imprecise abort issue?  I'd be happy to test them out.

 Exynos5 MCPM is still broken in linux-next and still causing an imprecise 
 abort.

 What is the status of $SUBJECT patch?

 Anyway let me apply this into -fixes and
 then let's enable after test its functionality in -next in a couple of 
 days.

 Yes, I think this needs to be applied until these aborts are understood
 and fixed.

 Is anyone at Samsung actually looking into these MCPM issues?

 Hi Kevin,

 What hardware are you having problems with? 5420 or 5422/5800?

 Yes.  :)

 exynos5420-arndale-octa:
 http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
 exynos5422-odroid-xu3:
 http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html

 My boot tests seem to pass fine because I have such a minimal
 userspace, but Tyler Baker reported that with a real userspace, he
 can't boot to a shell:

   
 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html

 I'm not surprised that 5420 has issues, but I have not seen any
 external aborts on neither Chromebook that I have in my farm.

 Sounds like the secondary cpus should be disabled on those device
 trees instead, doesn't it?

That's possible.

Unfortunately, I've gotten very little support from Samsung on this
and it was originally reported 2.5 months ago[2], so I think that the
5420 MCPM should be disabled until they can propose the right fix, and
actually test it.

Also, I tried disabling some CPUs at boot time, but the
exynos5422-odroid-xu3 wont' even boot with nr_cpus=1 or 4 (or anything
less than 8)

Kevin

[1]  
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.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] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

On Mon, Nov 24, 2014 at 5:50 PM, Kukjin Kim kg...@kernel.org wrote:
 Olof Johansson wrote:

 On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote:
  On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote:
  On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote:
  On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org 
  wrote:
  Kukjin,
 
  On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org 
  wrote:
  Kukjin Kim kg...@kernel.org writes:
 
  Kevin Hilman wrote:
 
  From: Kevin Hilman khil...@linaro.org
 
  The option CONFIG_EXYNOS5420_MCPM is causing imprecise external 
  aborts
  during boot testing, causing various userspace startup failures.
 
  Disable until it has gotten more testing.
 
  Cc: Kukjin Kim kgene@samsung.com,
  Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
  Cc: Sachin Kamat sachin.ka...@samsung.com,
  Cc: Doug Anderson diand...@chromium.org,
  Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
  Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
  Cc: Tushar Behera tushar.beh...@linaro.org,
  Cc: sta...@vger.kernel.org # v3.17+
  Signed-off-by: Kevin Hilman khil...@linaro.org
  ---
  This has been reported by a few people[1], but not investigated or 
  fixed, so it's
  time to disable this feature until it can be fixed.
 
  Hi Kevin,
 
  Yeah I agree with your opinion.
 
  But as you can see my tree, I've queued regarding mcpm patches for 
  3.19 will
  be shown in -next in this weekend.
 
  Which of the recently queued patches are expected to address the
  imprecise abort issue?  I'd be happy to test them out.
 
  Exynos5 MCPM is still broken in linux-next and still causing an 
  imprecise abort.
 
  What is the status of $SUBJECT patch?
 
  Anyway let me apply this into -fixes and
  then let's enable after test its functionality in -next in a couple 
  of days.
 
  Yes, I think this needs to be applied until these aborts are understood
  and fixed.
 
  Is anyone at Samsung actually looking into these MCPM issues?
 
  Hi Kevin,
 
  What hardware are you having problems with? 5420 or 5422/5800?
 
  Yes.  :)
 
  exynos5420-arndale-octa:
  http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-
 arndale-octa.html
  exynos5422-odroid-xu3:
  http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-
 odroid-xu3.html
 
  My boot tests seem to pass fine because I have such a minimal
  userspace, but Tyler Baker reported that with a real userspace, he
  can't boot to a shell:
 

  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html
 
 Hmm...his report was in Sep...I think it should be fine with current -next?

No, it is still broken in linux-next (as I stated above.)

Moreover, earlier in this thread you mentioned you were merging some
MCPM patches that should address this, but did not respond when I
asked which patches you thing should address this issue

 To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk
 which has different bootloader, I couldn't test it...I'll try to make a test
 farm like you guys...

Do you have some colleagues with any other 542x hardware?  I had
assumed that linux-next was being better tested on the publicaly
available, and widely available boards like odroid-xu3 and
Chromebook2, but I've come to realize the hard way that that is not
the case.  You mention your board has a different bootloader.  Do you
suspect there's a bootloader issue on these other platforms?  If so,
could you elaborate on possible fixes?  I'm more than willing to test
any proposed fixes, but I'm not familiar enough yet with these SoCs to
figure out the underlying issues alone.

Until you have a working board farm, you could start having a closer
look at the boot logs we're already producing.  Admittedly linux-next
broken in many ways besides this one for exynos currently, but it has
been having these imprecise aborts well before the other recent
issues.

Also, It's very possible that this issue is not even MCPM related at
all, and MCPM is just uncovering a previously hidden bug.  It would be
very helpful if people more familiar with this hardware and SoC would
investigate bug reports like these.

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

[RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

Using the current exynos_defconfig on the exynos5422-odroid-xu3, only
6 of 8 CPUs come online with MCPM boot.  CPU0 is an A7, CPUs 1-4 are
A15s and CPU5-7 are the other A7s, but with the current code, CPUs 5
and 7 do not boot:

   [...]
   Exynos MCPM support installed
   CPU1: update cpu_capacity 1535
   CPU1: thread -1, cpu 0, socket 0, mpidr 8000
   CPU2: update cpu_capacity 1535
   CPU2: thread -1, cpu 1, socket 0, mpidr 8001
   CPU3: update cpu_capacity 1535
   CPU3: thread -1, cpu 2, socket 0, mpidr 8002
   CPU4: update cpu_capacity 1535
   CPU4: thread -1, cpu 3, socket 0, mpidr 8003
   CPU5: failed to come online
   CPU6: update cpu_capacity 448
   CPU6: thread -1, cpu 2, socket 1, mpidr 8102
   CPU7: failed to come online
   Brought up 6 CPUs
   CPU: WARNING: CPU(s) started in wrong/inconsistent modes
   (primary CPU mode 0x13)
   CPU: This may indicate a broken bootloader or firmware.

Thanks to a tip from Abhilash, this patch gets all 8 CPUs booting
again, but the warning about CPUs started in inconsistent modes
remains.  Also, not being terribly familiar with Exynos internals,
it's not at all obvious to me why this register write (done for *all*
secondaries) makes things work works for the 2 secondary CPUs that
didn't come online.  It's also not obvious whether this is the right
general fix, since it doesn't seem to be needed on other 542x or 5800
platforms.

I suspect the right fix is in the bootloader someplace, but not
knowing this hardware well, I'm not sure if the fix is in u-boot
proper, or somewhere in the binary blobs (bl1/bl2/tz) that start
before u-boot.  The u-boot I'm using is from the hardkernel u-boot
repo[1], and I'd welcome any suggestions to try.  I'm able to rebuild
my own u-boot from there, but only have binaries for bl1/bl2/tz.

[1] branch odroidxu3-v2012.07 of: https://github.com/hardkernel/u-boot.git


Cc: Mauro Ribeiro mauro.ribe...@hardkernel.com
Cc: Abhilash Kesavan a.kesa...@samsung.com,
Cc: Andrew Bresticker abres...@chromium.org
Cc: Doug Anderson diand...@chromium.org
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by: Kevin Hilman khil...@linaro.org
---
 arch/arm/mach-exynos/mcpm-exynos.c | 2 ++
 arch/arm/mach-exynos/regs-pmu.h| 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
index b0d3c2e876fb..612a770d5284 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -88,6 +88,8 @@ static int exynos_power_up(unsigned int cpu, unsigned int 
cluster)
cluster = EXYNOS5420_NR_CLUSTERS)
return -EINVAL;
 
+   pmu_raw_writel(0x1, S5P_PMU_SPARE2);
+
/*
 * Since this is called with IRQs enabled, and no arch_spin_lock_irq
 * variant exists, we need to disable IRQs manually here.
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index b5f4406fc1b5..70d9eb5a4fcc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -49,6 +49,7 @@
 #define S5P_INFORM50x0814
 #define S5P_INFORM60x0818
 #define S5P_INFORM70x081C
+#define S5P_PMU_SPARE2 0x0908
 #define S5P_PMU_SPARE3 0x090C
 
 #define EXYNOS_IROM_DATA2  0x0988
-- 
2.1.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: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 [adding Kukjin as cc and dropping dri-devel]

 Hello Kevin,

 On 11/20/2014 07:22 PM, Kevin Hilman wrote:
 My kernel command line is almost the same with the difference that
 I'm using clk_ignore_unused and I just checked that not passing
 that parameter, makes linux-next to hang showing the same output
 log that Kevin reported.
 
 Ah!  Good find.  I confirm that adding clk_ignore_unused is getting
 me booting again, but of course that is just masking a problem, so I
 hope someone can shed light on which clock isn't being correctly
 managed.
 

 True, I'm renaming the thread subject to track these issues separately
 of the original Exynos DRM bug since these are unrelated.

 So, I see two different boot failures on the Peach Pi[t] Chromebooks:

 1) next20141121 boot fails due snd-soc-snow

 Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further
 but still fails with the second issue:

 2) next20141121 boot hangs if unused clocks are disabled.

 I tried to root cause these two issues but didn't see anything evident
 so I'll find a last known good commit and bisect. If anyone has an
 idea of the possible causes for these issues that would be appreciated.

FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot
failures in next-20141121 on the exynos5420-arndale-octa[1].  Adding
clk_ignore_unused gets things booting there as well.

What's interesting is that my exynos5422-odroid-xu3 is booting fine as
well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as
exynos5410-smdk5410)

Whatever the issue, it definietly seems like a problem that was came
through a driver/subsystem tree because that these boards are all
booting fine with Kukjin's for-next, arm-soc/for-next and
mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without
clk_ignore_unused.)  For example, just looking at peach-pi across all
these trees[2], you can see that it's only failing in linux-next.

Kevin

[1] http://status.armcloud.us/boot/?next-2014112?exynos
[2] http://status.armcloud.us/boot/?exynos5800-peach-pi

NOTE: the exynos5422-odroid-xu3 is shown as exynos5420-smdk5420 since
  that's the DTS being used, and exynos5410-odroid-xu is shown as
  exynos5410-smdk5410, again due to the DTS being used.
--
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: screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2

[Kevin Hilman]

Hi Ajay,

AJAY KUMAR RAMAKRISHNA SHYMALAMMA ajaykumar...@samsung.com writes:

 I tried to reproduce the issue which you reported,

 but I am sorry I am not able to reproduce it.

 I tried with my patches for DRM on top of Linux-next.

I don't see the issue on linux-next either.  As I mentioned in the
original post, I only see it on the v3.18 branch in the exynos-reference
tree.

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

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Hi Vivek,

Vivek Gautam gautamvivek1...@gmail.com writes:

[...]

 I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
 two
 patches $Subject and [0].

 Below is my git hash:
 4d9e6ee drm/exynos: Move platform drivers registration to module init
 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 36391a5 Add linux-next specific files for 20141119
 9b1ced1 Merge branch 'akpm/master'
 282497e mm: add strictlimit knob

 With this display works for me.
 Without $Subject patch i get lookup in drm.

The current linux-next (next-20141120) is still not fully booting for
me.  I do see the penguins come up on the display, but it doesn't finish
booting.   Full boot log below.

I'm building using exynos_defconfig with CONFIG_SND_SOC_SNOW=n due to
other errors previously reported.  (Vivek, BTW, I'm curious how your peach-pi
is booting with the audio support enabled.)

Here's how I'm creating the tree, which appears to be the same as what
you guys are doing, but just to be thorough:

$ git reset --hard next/master
HEAD is now at 5b83d7ad9106 Add linux-next specific files for 20141120

$ pwclient git-am 5197701
Applying patch #5197701 using 'git am'
Description: [v2,2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for 
dp phy
Applying: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

$ pwclient git-am 5328881
Applying patch #5328881 using 'git am'
Description: [RFC,1/1] drm/exynos: Move platform drivers registration to module 
init
Applying: drm/exynos: Move platform drivers registration to module init

$ git log --oneline -n5
b16800da58a3 drm/exynos: Move platform drivers registration to module init
87541edf8a17 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
5b83d7ad9106 Add linux-next specific files for 20141120
fd7e97b09f45 Merge branch 'akpm/master'
11729160b2d7 mm: add strictlimit knob

Kevin


[1] 
Connected to chromebook2 console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(chromebook2 console) hardreset
(user:khilman) Reboot chromebook2
Reboot: chromebook2 ; phidget 4 2 :  ('off', 1, 'on')


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach

CPU:Exynos5422@1800MHz

Board: Google Peach Pi, rev 13.6
I2C:   ready
DRAM:  3.5 GiB
PMIC max77802-pmic initialized
CPU:Exynos5422@1800MHz
TPS65090 PMIC EC init
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:cros-ec-keyb
Out:   serial
Err:   lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net:   No ethernet found.
Hit any key to stop autoboot:  2 

# PYBOOT: u-boot: taking control.
 0 
Exynos DP init done
Peach # 
Peach setenv stdout serial
# setenv stdout serialversion

Peach # versionsetenv preboot usb start; sleep 1


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.7.2_cos_gg_c8f69e0) 4.7.x-google 20130114 
(prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22
Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 
console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait 
rootfstype=ext3

Peach # setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk 
rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3if test -n ${initenv}; then run 
initenv; fi

Peach # if test -n ${initenv}; then run initenv; fiif test -n ${preboot}; then 
run preboot; fi

Peach # if test -n ${preboot}; then run preboot; fisetenv autoload no; setenv 
autoboot no

(Re)start USB...
USB0:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Peach # dhcp
dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.110
Peach # setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
Peach # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
Peach # tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.110
Filename 'tmp/chromebook2-3T8ptb/uImage-48m8WK'.
Load address: 0x4100
Loading: *#
 #
 #
 ##
 1.2 MiB/s
done
Bytes transferred = 3473930 (35020a hex)
Peach # printenv bootargs
printenv bootargs
bootargs=console=tty1 

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello,

 For completeness I'll comment what we talked with Kevin on IRC
 since probably this is the same issue that Paolo is facing.

 On 11/20/2014 05:41 PM, Kevin Hilman wrote:
 Peach # setenv preboot usb start; sleep 1setenv bootargs
 console=tty1 console=ttySAC3,115200 debug earlyprintk rw
 root=/dev/mmcblk1p3 rootwait rootfstype=ext3

 My kernel command line is almost the same with the difference that I'm using
 clk_ignore_unused and I just checked that not passing that parameter, makes
 linux-next to hang showing the same output log that Kevin reported.

Ah!  Good find.  I confirm that adding clk_ignore_unused is getting me
booting again, but of course that is just masking a problem, so I hope
someone can shed light on which clock isn't being correctly managed.

Might I also suggest that folks have their default command-line to *not*
use clk_ignore_unused, since it's primary job is to workaround clock
bugs.

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

Re: exynos boot falures in linux-next

[Kevin Hilman]

On Mon, Nov 17, 2014 at 7:49 PM, Kevin Hilman khil...@kernel.org wrote:
 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello Kevin,

 On 11/17/2014 11:24 PM, Kevin Hilman wrote:

 As might have been expected, reverting the change that enables the
 DRM/display options in exynos_defconfig fixes the problem.

 Kevin


 I'm sorry for causing a boot failure but when I first posted that patch,
 the Exynos DRM driver was working correctly (at least on the Exynos boards
 I've access to)

 Yeah, I tested it at the time as well, so I know it was working.

 so it seems the regression was introduced while the patch
 was posted but not yet picked.

 I'm not sure what is the correct step in this case but I'm OK with
 reverting the patch until the Exynos DRM driver bug is fixed.

 I didn't have time to dig, but I'd rather someone track down the DRM
 problem and fix that, since it was known to be working. I'm guessing
 it's something simple that can be fixed before the merge window opens.

OK, so this DRM problem is turning out to be non-trivial, so I think
the defconfig patch should be reverted until the DRM issue is sorted
out.

Otherwise, we risk having boot failures in linux-next which may be
hiding other problems.

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

Re: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420

[Kevin Hilman]

Hi Thomas,

On Mon, Oct 20, 2014 at 4:41 AM, Thomas Abraham thomas...@samsung.com wrote:
 The new CPU clock type allows the use of generic CPUfreq drivers. So for
 Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
 which did not have CPUfreq driver support, enable the use of generic
 CPUfreq driver.

 Suggested-by: Tomasz Figa tomasz.f...@gmail.com
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 Reviewed-by: Tomasz Figa tomasz.f...@gmail.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Chander Kashyap k.chan...@samsung.com

What's the status of the exynos5 CPUfreq support for upstream?  This
was pretty broadly reviewed and tested, but I still don't see this
either in linux-next or Kukjin's for-next.

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

Re: [PATCH] ARM: multi_v7_defconfig: fix failure setting CPU voltage by enabling dependent I2C controller

[Kevin Hilman]

Kukjin Kim kgene@samsung.com writes:

 On 11/19/14 04:10, Tyler Baker wrote:

 Hi,

 + Arnd, Olof and Kevin

 This patch fixes a long standing issue introduced during the 3.16 merge 
 window.
 Shortly after the merge, exynos5250-based arndale boards began to produce 
 the 
 following errors:
 
 kern.err kernel:  exynos-cpufreq exynos-cpufreq: failed to set cpu voltage
 kern.err kernel:  cpufreq: __target_index: Failed to change cpu frequency: 
 -22
 
 Further analysis revealed that the S5M8767 voltage regulator used on the 
 exynos5250-based arndale board utilizes the S3C2410 I2C controller. If the 
 S3C2410 I2C controller driver is not enabled, the S5M8767 voltage regulator 
 fails to probe. Therefore a dependency exists between these two drivers. 
 In the exynos_defconfig both CONFIG_REGULATOR_S5M8767 and CONFIG_I2C_S3C2410 
 options are enabled, and no errors are produced. However, in the 
 multi_v7_defconfig only the CONFIG_REGULATOR_S5M8767 option is enabled and 
 the 
 errors are present. So let's enable the CONFIG_I2C_S3C2410 option in the 
 multi_v7_defconfig to allow the S5M8767 voltage regulator to probe.
 
 Signed-off-by: Tyler Baker tyler.ba...@linaro.org

 Acked-by: Kukjin Kim kgene@samsung.com

Applied to arm-soc/fixes, which is merged into arm-soc/for-next.

Thanks,

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

screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2

[Kevin Hilman]

As I'm hunting around trying to figure out how to make exynos-drm work
with v3.18 or linux-next, I noticed there was an exynos5-v3.18-rc2
branch in the exynos-reference tree[1], so I gave that a spin on my
exynos5800-peach-pi.

It seemed to work OK, but I noticed that as soon as the screen blanked
after timeout, typing on the serial console would still work, but any
typing on the keyboard caused a silent lockup, with no output on the
serial console.

I was able to easily reproduce this by doing

  # echo 3  /sys/class/graphics/fb0/blank

on the serial console, verifying I could still type on the serial
console. Then, touch any key on the physical keyboard and then I can
no longer type on the serial console, ping the target, etc.

Kevin

[1] https://github.com/exynos-reference/kernel.git
--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Kevin Hilman]

Paolo Pisati p.pis...@gmail.com writes:

 On Wed, Nov 19, 2014 at 10:35:40AM +0100, Javier Martinez Canillas wrote:
 Hello Ajay,
 
 On 11/18/2014 07:20 AM, Ajay kumar wrote:
  On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar ajaykumar...@samsung.com 
  wrote:
  This series is based on master branch of Linus tree at:
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 I applied your series on top of 3.18-rc5 + linux-next's commit:
 
 0ef76ae (ARM: exynos_defconfig: Enable options for display panel support).
 
 I think you should had mentioned what other patches are needed as a
 dependency since I spent quite a bit of time figuring out why the
 ps8622 bridge driver probe was always deferred due of_drm_find_panel()
 failing and then I noticed that a patch from linux-next was needed:
 
 e35e305 (drm/panel: simple: Add AUO B116XW03 panel support)
 
 With that commit the ps8622 drm bridge driver probe succeed but I still
 don't have display working on an Exynos5240 Peach Pit, the kernel log shows:
 
 platform 145b.dp-controller: Driver exynos-dp requests probe deferral
 exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
 exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops 
 exynos_dp_ops): -517
 exynos-drm exynos-drm: master bind failed: -517
 platform 145b.dp-controller: Driver exynos-dp requests probe deferral

 do you have this in your dmesg?

 ...
 exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
 ...

 to get a working framebuffer out of linus 318rc4 on my peach pi, i had
 to cherry pick these 3 patches:

 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 drm/exynos: dp: Remove support for unused dptx-phy

Excellent, thank you for pointing these out.  I've been struggling to
get the display working on v3.18-rc and had missed these.

 ARM: exynos_defconfig: Enable options for display panel support

 Check if you have those.

With the 3 patches you mention, the display is working on my peach-pi as
well.

Thanks,

Kevin



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

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 [adding Paolo and Vivek as cc]

 Hello,

 On 11/18/2014 07:41 PM, Kevin Hilman wrote:
 
 It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
 it proceeds to panic in the workqueue code called by the asoc max98090
 codec[1].
 
 If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
 but I still don't have display output.
 

 Paolo Pisati pointed out in another thread that he needed the patch
 [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 is also needed to get display working for exynos on linux-next.

 I've pinged Kukjin to apply this as a -rc fix since is needed after
 a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register)
 landed in 3.18 which broke the Exynos Display Port PHY:

 exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap

 I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
 $subject
 and [0] should be enough to have display working on Peach Pi 

Yes, with those two patches, peach-pi display working on v3.18-rc5 for me.

 with linux-next but
 it fails to me with:

 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
 [mem 0x10040714-0x1004071f]

 The same issue was reported by Paolo a couple of days ago [1].

For me, with linux-next, I'm still getting the DRM deadlock.  Trying
your patch that moves things to module_init gets past the deadlock, but
still doesn't boot unless I disable CONFIG_SND_SOC_SNOW.  Doing that I
see the same video-phy error though.

Kevin



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

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Kevin Hilman khil...@kernel.org writes:

 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 [adding Paolo and Vivek as cc]

 Hello,

 On 11/18/2014 07:41 PM, Kevin Hilman wrote:
 
 It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
 it proceeds to panic in the workqueue code called by the asoc max98090
 codec[1].
 
 If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
 but I still don't have display output.
 

 Paolo Pisati pointed out in another thread that he needed the patch
 [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 is also needed to get display working for exynos on linux-next.

 I've pinged Kukjin to apply this as a -rc fix since is needed after
 a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register)
 landed in 3.18 which broke the Exynos Display Port PHY:

 exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap

 I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
 $subject
 and [0] should be enough to have display working on Peach Pi 

 Yes, with those two patches, peach-pi display working on v3.18-rc5 for me.

 with linux-next but
 it fails to me with:

 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
 [mem 0x10040714-0x1004071f]

 The same issue was reported by Paolo a couple of days ago [1].

 For me, with linux-next, I'm still getting the DRM deadlock.  Trying
 your patch that moves things to module_init gets past the deadlock, but
 still doesn't boot unless I disable CONFIG_SND_SOC_SNOW.  Doing that I
 see the same video-phy error though.

Another interesting data point is that the 2 patches which get things
working on v3.18-rc5, when applied on Kukjin's for-next branch, result
in a kernel that boots (which is better than linux-next), but without
a working display. :(

Kevin

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

Re: [PATCH 0/3] PM / Domains: Add initial PM clock support to genpd

[Kevin Hilman]

Ulf Hansson ulf.hans...@linaro.org writes:

 It's quite common for PM domains to use PM clocks. Typically from SOC specific
 code, the per device PM clock list is created and pm_clk_suspend|resume() are
 invoked to handle clock gating/ungating.

 A step towards consolidation is to integrate PM clock support into genpd, 
 which
 is what this patchset does.

 In this initial step, the calls to the pm_clk_suspend|resume() are handled
 within genpd, but the per device PM clock list still needs to be created from
 SOC specific code. It seems reasonable to have gendp to handle that as well, 
 but
 that left to future patchsets to address.

I think we need to get rid of the SoC specific code already.  For
example, we're already seeing SoCs where the arm32 core is being
replaced by an arm64 core but the other IPs, and power-domain logic is
staying more or less the same.  

 It's not every users of genpd that are keen on using PM clocks thus we need
 to provide this a configuration option for genpd.

Or more likely, probably some compatible string, or property in the
domain node.  Grygorii, Arnd and myself were discussing this elsewhere
in the context of the TI Keystone2 PM domain support[1].

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304099.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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 The Exynos DRM driver register its sub-devices platform drivers in
 the probe function but after commit 43c0767 (of/platform: Move
 platform devices under /sys/devices/platform), this is causing
 a deadlock in __driver_attach(). Fix this by moving the platform
 drivers registration to exynos_drm_init().

 Suggested-by: Andrzej Hajda a.ha...@samsung.com
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].

 Inki Dae said that he will fix it property by separating the Exynos DRM
 driver in different sub-modules but I post this patch as RFC anyways so
 others can test if this fixes their boot issue.

It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
it proceeds to panic in the workqueue code called by the asoc max98090
codec[1].

If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
but I still don't have display output.

Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
would really be nice if your linux-next work was tested on these
publically-available 542x/5800 platforms (peach-pi, peach-pit,
odroid-xu3) which would also allow lots of others to help you test and
validate.

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

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Gustavo Padovan gust...@padovan.org writes:

 2014-11-18 Kevin Hilman khil...@kernel.org:

 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
 
  The Exynos DRM driver register its sub-devices platform drivers in
  the probe function but after commit 43c0767 (of/platform: Move
  platform devices under /sys/devices/platform), this is causing
  a deadlock in __driver_attach(). Fix this by moving the platform
  drivers registration to exynos_drm_init().
 
  Suggested-by: Andrzej Hajda a.ha...@samsung.com
  Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
  ---
 
  This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman 
  [1].
 
  Inki Dae said that he will fix it property by separating the Exynos DRM
  driver in different sub-modules but I post this patch as RFC anyways so
  others can test if this fixes their boot issue.
 
 It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
 it proceeds to panic in the workqueue code called by the asoc max98090
 codec[1].
 
 If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
 but I still don't have display output.
 
 Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
 would really be nice if your linux-next work was tested on these
 publically-available 542x/5800 platforms (peach-pi, peach-pit,
 odroid-xu3) which would also allow lots of others to help you test and
 validate.

 It would also be good to add drm-exynos-next to the daily linux-next build.
 Currently drm-exynos-next is ahead of linux-next. This patch from Javier for
 example only applies on linux-next.

Which tree is the drm-exynos-next branch in?

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

exynos boot falures in linux-next (was: next boot: 94 boots: 79 pass, 13 fail, 2 untried (next-20141117))

[Kevin Hilman]

FYI...

Various new exynos5 boot failures starting next-20141117.  Looking in
the boot logs, the boot stops during DRM initialization.

Note that the boot failures are only on exynos_defconfig, and not
multi_v7_defconfig.

Excerpt from boot report below, or recent exynos boots can also be
explored here:

   http://status.armcloud.us/boot/?exynos

Kevin


Kevin's boot bot khil...@kernel.org writes:

 Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/
 Full Boot report:  
 http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/

 Tree/Branch: next
 Git describe: next-20141117

 Failed boot tests
 =

[...]

exynos5422-odroid-xu3: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html
   exynos5250-arndale: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html
  exynos5800-peach-pi: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.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] PM / Domains: Power on the PM domain right after attach completes

[Kevin Hilman]

Ulf Hansson ulf.hans...@linaro.org writes:

 The amba bus, amba drivers and a vast amount of platform drivers which
 enables runtime PM, don't invoke a pm_runtime_get_sync() while probing
 their devices.

 Instead, once they have turned on their PM resourses during -probe()
 and are ready to handle I/O, these invokes pm_runtime_set_active() to
 synchronize its state towards the runtime PM core.

 From a runtime PM point of view this behavior is perfectly acceptable,

In the context of PM domains that can be dynamically powered on/off, I'm
not so sure it's perfectly acceptable anymore.

Why doesn't the bus do a _get_sync() instead of a _get_noresume()
followed by a _set_active().  

By using the _get_noresume() you're bypassing the paths that would bring
up your PM domain.

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

Re: exynos boot falures in linux-next

[Kevin Hilman]

Kevin Hilman khil...@kernel.org writes:

 FYI...

 Various new exynos5 boot failures starting next-20141117.  Looking in
 the boot logs, the boot stops during DRM initialization.

 Note that the boot failures are only on exynos_defconfig, and not
 multi_v7_defconfig.

As might have been expected, reverting the change that enables the
DRM/display options in exynos_defconfig fixes the problem.

Kevin

 Excerpt from boot report below, or recent exynos boots can also be
 explored here:

http://status.armcloud.us/boot/?exynos

 Kevin


 Kevin's boot bot khil...@kernel.org writes:

 Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/
 Full Boot report:  
 http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/

 Tree/Branch: next
 Git describe: next-20141117

 Failed boot tests
 =

 [...]

exynos5422-odroid-xu3: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html
   exynos5250-arndale: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html
  exynos5800-peach-pi: FAIL:arm-exynos_defconfig
   
 http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.html

[1]
commit 0ef76aea7a344ac520b02822a8080797fa06124c
Author: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date:   Thu Nov 13 11:51:42 2014 +0900

ARM: exynos_defconfig: Enable options for display panel support

Many Exynos devices have a display panel. Most of them just have
a simple panel while others have more complex configurations that
requires an embedded DisplayPort (eDP) to LVDS bridges.

This patch enables the following features to be built in the kernel
image to support both setups:

- Direct Rendering Manager (DRM)
- DRM bridge registration and lookup framework
- Parade ps8622/ps8625 eDP/LVDS bridge
- NXP ptn3460 eDP/LVDS bridge
- Exynos Fully Interactive Mobile Display controller (FIMD)
- Panel registration and lookup framework
- Simple panels
- Backlight  LCD device support

Signed-off-by: Javier Martinez Canillas
javier.marti...@collabora.co.uk
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Kukjin Kim kgene@samsung.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

Re: exynos boot falures in linux-next

[Kevin Hilman]

Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello Kevin,

 On 11/17/2014 11:24 PM, Kevin Hilman wrote:
 
 As might have been expected, reverting the change that enables the
 DRM/display options in exynos_defconfig fixes the problem.
 
 Kevin


 I'm sorry for causing a boot failure but when I first posted that patch,
 the Exynos DRM driver was working correctly (at least on the Exynos boards
 I've access to) 

Yeah, I tested it at the time as well, so I know it was working.

 so it seems the regression was introduced while the patch
 was posted but not yet picked.

 I'm not sure what is the correct step in this case but I'm OK with
 reverting the patch until the Exynos DRM driver bug is fixed.

I didn't have time to dig, but I'd rather someone track down the DRM
problem and fix that, since it was known to be working. I'm guessing
it's something simple that can be fixed before the merge window opens.

Kevin

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

Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

Kukjin Kim kg...@kernel.org writes:

 Kevin Hilman wrote:
 
 From: Kevin Hilman khil...@linaro.org
 
 The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
 during boot testing, causing various userspace startup failures.
 
 Disable until it has gotten more testing.
 
 Cc: Kukjin Kim kgene@samsung.com,
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
 Cc: Sachin Kamat sachin.ka...@samsung.com,
 Cc: Doug Anderson diand...@chromium.org,
 Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
 Cc: Tushar Behera tushar.beh...@linaro.org,
 Cc: sta...@vger.kernel.org # v3.17+
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 This has been reported by a few people[1], but not investigated or fixed, so 
 it's
 time to disable this feature until it can be fixed.
 
 Hi Kevin,

 Yeah I agree with your opinion.

 But as you can see my tree, I've queued regarding mcpm patches for 3.19 will
 be shown in -next in this weekend. 

Which of the recently queued patches are expected to address the
imprecise abort issue?  I'd be happy to test them out.  

 Anyway let me apply this into -fixes and
 then let's enable after test its functionality in -next in a couple of days.

Yes, I think this needs to be applied until these aborts are understood
and fixed.

Thanks,

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

Re: [PATCH 03/12] PM / Domains: Add notifier support for power domain transitions

[Kevin Hilman]

Sylwester Nawrocki s.nawro...@samsung.com writes:

 On 04/11/14 07:44, amit daniel kachhap wrote:
 On Mon, Nov 3, 2014 at 11:53 PM, Kevin Hilman khil...@kernel.org wrote:
 Rafael J. Wysocki r...@rjwysocki.net writes:
 On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote:
 These power domain transition notifiers will assist in carrying
 out some activity associated with domain power on/off such as
 some registers which may lose its contents and need save/restore
 across domain power off/on.

 The runtime PM framework already provides callbacks that are useful for
 context save/restore for devices.  Could you please describe in more
 detail which registers in which kind of devices need to be
 saved/restored, and why they cannot be saved/restored using existing
 mechanisms.

 Basically the requirement is mandated by exynos7 manual. It tells that
 before turning off the power domain, some clock registers need to saved
 and should be restored just after turning the power domain. These clock
 registers are not necessarily gate clocks but could be mux clocks etc.
 The driver may not have all information of these clocks also. I suppose
 these are Soc specific changes but drivers should work across Socs.
 This behavior is almost similar to suspend/resume case where a whole
 list of clock registers are saved/restored.

 Indeed, the somehow complicated power domain power on/off sequences
 are SoC specific.  They involve not only groups of clocks (usually
 gate, mux clock registers of all devices in a power domain) but also
 SoC-specific PMU (Power Management Unit) registers.
 I assume it would be inappropriate to push such details to device 
 drivers.  Moreover, a device driver could not be even loaded.

 Since the clocks' state is already maintained by clk driver we came 
 up with an idea of having generic calls from power domain driver back 
 to the clock controller driver.

For the clock tree, it still seems to me that this is better handled in
the SoC clock driver.  For example, when a power domain is about to be
gated, all the devices in that domain are runtime suspended, and
presumably all of their gate clocks are disabled.  Now, doesn't the
clock driver know the clock tree parent-child hierarchy and shouldn't it
be capable of saving the state of parent clocks (like mux clocks) etc?

Stated diffrently, it still seems to me like we're pushing functionality
in PM core notifiers that should be the responsibility of subsystem
drivers. 

 It might not to be the prettiest solution, nevertheless I couldn't come 
 up with a better one which would satisfy all the requirements.  The power
 domain should only be provided for use with all the clk/PMU sequences 
 handling in place.

 Clocks need to also be touched before a power domain switch on or off,
 so attaching the clock controller to some power domain wouldn't help,
 unless we modify/add to existing power domain related callbacks for 
 devices.  Another issue is the clock controller device would need to 
 be attached to multiple power domains, and for each power domain the 
 power on/off sequence is usually slightly different.

 There are also hierarchical power domains where each: the master and
 the sub-domain need they own sequence and device usually is attached
 only to a sub-domain.  

 Even earlier post by Sylwester (https://lkml.org/lkml/2014/8/5/182) 
 also points to the need of this feature.

 Personally, I'm uncomfortable with notifiers like this because it
 suggests that underlying frameworks are not doing the right thing, or
 are not being used.  (I also don't like the implementation here where a
 single global notifier list is maintained by the core, but the notifiers
 are actually triggered by SoC specific code.)

 Yes right the global notifier block can be moved to per genpd structure.
 Also SoC trigger can be moved to core files.

 IIUC, the usage in this series seems to be that certain clock related
 registers need to be saved/restored across a power domain transition.

 Wouldn't an alternative solution be to add a feature to the clock driver
 such that the state of each clock is saved when the clock is disabled,
 and restored when the clock is enabled?   That would allow any clock
 context to survive any power domain transtion also, correct?

 I also thought about same. But the trigger point for this would be
 driver calling clk disable/enable and not the power domain. so this 
 will lead to lot of save/restore for each power domain child.

 Even though we would have saved/restored at that points still the power
 domain driver would need to enforce some specific clock/PMU registers 
 state before/after a power domain state transition. And this is what I 
 found difficult with the existing APIs.

This is what I'm not understanding.

Why can't the power domain driver's power_on/power_off callback just
call the PMU APIs and/or the clk_enable/_disable calls it needs?

Kevin



--
To unsubscribe from this list: send the line unsubscribe

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

[Kevin Hilman]

Ulf Hansson ulf.hans...@linaro.org writes:

 The initial state of the device's need_restore flag should'nt depend on
 the current state of the PM domain. For example it should be perfectly
 valid to attach an inactive device to a powered PM domain.

 The pm_genpd_dev_need_restore() API allow us to update the need_restore
 flag to somewhat cope with such scenarios. Typically that should have
 been done from drivers/buses -probe() since it's those that put the
 requirements on the value of the need_restore flag.

 Until recently, the Exynos SOCs were the only user of the
 pm_genpd_dev_need_restore() API, though invoking it from a centralized
 location while adding devices to their PM domains.

 Due to that Exynos now have swithed to the generic OF-based PM domain
 look-up, it's no longer possible to invoke the API from a centralized
 location. The reason is because devices are now added to their PM
 domains during the probe sequence.

 Commit ARM: exynos: Move to generic PM domain DT bindings
 did the switch for Exynos to the generic OF-based PM domain look-up,
 but it also removed the call to pm_genpd_dev_need_restore(). This
 caused a regression for some of the Exynos drivers.

 To handle things more properly in the generic PM domain, let's change
 the default initial value of the need_restore flag to reflect that the
 state is unknown. As soon as some of the runtime PM callbacks gets
 invoked, update the initial value accordingly.

 Moreover, since the generic PM domain is verifying that all device's
 are both runtime PM enabled and suspended, using pm_runtime_suspended()
 while pm_genpd_poweroff() is invoked from the scheduled work, we can be
 sure of that the PM domain won't be powering off while having active
 devices.

 Do note that, the generic PM domain can still only know about active
 devices which has been activated through invoking its runtime PM resume
 callback. In other words, buses/drivers using pm_runtime_set_active()
 during -probe() will still suffer from a race condition, potentially
 probing a device without having its PM domain being powered. That issue
 will have to be solved using a different approach.

 This a log from the boot regression for Exynos5, which is being fixed in
 this patch.

 [ cut here ]
 WARNING: CPU: 0 PID: 308 at ../drivers/clk/clk.c:851 clk_disable+0x24/0x30()
 Modules linked in:
 CPU: 0 PID: 308 Comm: kworker/0:1 Not tainted 3.18.0-rc3-00569-gbd9449f-dirty 
 #10
 Workqueue: pm pm_runtime_work
 [c0013c64] (unwind_backtrace) from [c0010dec] (show_stack+0x10/0x14)
 [c0010dec] (show_stack) from [c03ee4cc] (dump_stack+0x70/0xbc)
 [c03ee4cc] (dump_stack) from [c0020d34] (warn_slowpath_common+0x64/0x88)
 [c0020d34] (warn_slowpath_common) from [c0020d74] 
 (warn_slowpath_null+0x1c/0x24)
 [c0020d74] (warn_slowpath_null) from [c03107b0] (clk_disable+0x24/0x30)
 [c03107b0] (clk_disable) from [c02cc834] (gsc_runtime_suspend+0x128/0x160)
 [c02cc834] (gsc_runtime_suspend) from [c0249024] 
 (pm_generic_runtime_suspend+0x2c/0x38)
 [c0249024] (pm_generic_runtime_suspend) from [c024f44c] 
 (pm_genpd_default_save_state+0x2c/0x8c)
 [c024f44c] (pm_genpd_default_save_state) from [c024ff2c] 
 (pm_genpd_poweroff+0x224/0x3ec)
 [c024ff2c] (pm_genpd_poweroff) from [c02501b4] 
 (pm_genpd_runtime_suspend+0x9c/0xcc)
 [c02501b4] (pm_genpd_runtime_suspend) from [c024a4f8] 
 (__rpm_callback+0x2c/0x60)
 [c024a4f8] (__rpm_callback) from [c024a54c] (rpm_callback+0x20/0x74)
 [c024a54c] (rpm_callback) from [c024a930] (rpm_suspend+0xd4/0x43c)
 [c024a930] (rpm_suspend) from [c024bbcc] (pm_runtime_work+0x80/0x90)
 [c024bbcc] (pm_runtime_work) from [c0032a9c] 
 (process_one_work+0x12c/0x314)
 [c0032a9c] (process_one_work) from [c0032cf4] (worker_thread+0x3c/0x4b0)
 [c0032cf4] (worker_thread) from [c003747c] (kthread+0xcc/0xe8)
 [c003747c] (kthread) from [c000e738] (ret_from_fork+0x14/0x3c)
 ---[ end trace 40cd58bcd6988f12 ]---

 Fixes: a4a8c2c4962bb655 (ARM: exynos: Move to generic PM domain DT bindings)
 Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org

Reviewed-by: Kevin Hilman khil...@linaro.org

And looks like we need this for v3.18-rc since it does fix the
regression.

A minor nit: you add a few new multi-line comment blocks which should
have a new empty line before them, but currently they're right up
against the previous code.  Please add a blank line for separation and
to be consisitent with the rest of the file.

Thanks,

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

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

[Kevin Hilman]

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 On Fri, Nov 07, 2014 at 11:47:53AM -0800, Kevin Hilman wrote:
 Ulf Hansson ulf.hans...@linaro.org writes:
 
  The initial state of the device's need_restore flag should'nt depend on
  the current state of the PM domain. For example it should be perfectly
  valid to attach an inactive device to a powered PM domain.
 
  The pm_genpd_dev_need_restore() API allow us to update the need_restore
  flag to somewhat cope with such scenarios. Typically that should have
  been done from drivers/buses -probe() since it's those that put the
  requirements on the value of the need_restore flag.
 
  Until recently, the Exynos SOCs were the only user of the
  pm_genpd_dev_need_restore() API, though invoking it from a centralized
  location while adding devices to their PM domains.
 
  Due to that Exynos now have swithed to the generic OF-based PM domain
  look-up, it's no longer possible to invoke the API from a centralized
  location. The reason is because devices are now added to their PM
  domains during the probe sequence.
 
  Commit ARM: exynos: Move to generic PM domain DT bindings
  did the switch for Exynos to the generic OF-based PM domain look-up,
  but it also removed the call to pm_genpd_dev_need_restore(). This
  caused a regression for some of the Exynos drivers.
 
  To handle things more properly in the generic PM domain, let's change
  the default initial value of the need_restore flag to reflect that the
  state is unknown. As soon as some of the runtime PM callbacks gets
  invoked, update the initial value accordingly.
 
  Moreover, since the generic PM domain is verifying that all device's
  are both runtime PM enabled and suspended, using pm_runtime_suspended()
  while pm_genpd_poweroff() is invoked from the scheduled work, we can be
  sure of that the PM domain won't be powering off while having active
  devices.
 
  Do note that, the generic PM domain can still only know about active
  devices which has been activated through invoking its runtime PM resume
  callback. In other words, buses/drivers using pm_runtime_set_active()
  during -probe() will still suffer from a race condition, potentially
  probing a device without having its PM domain being powered. That issue
  will have to be solved using a different approach.
 
  This a log from the boot regression for Exynos5, which is being fixed in
  this patch.
 
  [ cut here ]
  WARNING: CPU: 0 PID: 308 at ../drivers/clk/clk.c:851 
  clk_disable+0x24/0x30()
  Modules linked in:
  CPU: 0 PID: 308 Comm: kworker/0:1 Not tainted 
  3.18.0-rc3-00569-gbd9449f-dirty #10
  Workqueue: pm pm_runtime_work
  [c0013c64] (unwind_backtrace) from [c0010dec] (show_stack+0x10/0x14)
  [c0010dec] (show_stack) from [c03ee4cc] (dump_stack+0x70/0xbc)
  [c03ee4cc] (dump_stack) from [c0020d34] 
  (warn_slowpath_common+0x64/0x88)
  [c0020d34] (warn_slowpath_common) from [c0020d74] 
  (warn_slowpath_null+0x1c/0x24)
  [c0020d74] (warn_slowpath_null) from [c03107b0] (clk_disable+0x24/0x30)
  [c03107b0] (clk_disable) from [c02cc834] 
  (gsc_runtime_suspend+0x128/0x160)
  [c02cc834] (gsc_runtime_suspend) from [c0249024] 
  (pm_generic_runtime_suspend+0x2c/0x38)
  [c0249024] (pm_generic_runtime_suspend) from [c024f44c] 
  (pm_genpd_default_save_state+0x2c/0x8c)
  [c024f44c] (pm_genpd_default_save_state) from [c024ff2c] 
  (pm_genpd_poweroff+0x224/0x3ec)
  [c024ff2c] (pm_genpd_poweroff) from [c02501b4] 
  (pm_genpd_runtime_suspend+0x9c/0xcc)
  [c02501b4] (pm_genpd_runtime_suspend) from [c024a4f8] 
  (__rpm_callback+0x2c/0x60)
  [c024a4f8] (__rpm_callback) from [c024a54c] (rpm_callback+0x20/0x74)
  [c024a54c] (rpm_callback) from [c024a930] (rpm_suspend+0xd4/0x43c)
  [c024a930] (rpm_suspend) from [c024bbcc] (pm_runtime_work+0x80/0x90)
  [c024bbcc] (pm_runtime_work) from [c0032a9c] 
  (process_one_work+0x12c/0x314)
  [c0032a9c] (process_one_work) from [c0032cf4] 
  (worker_thread+0x3c/0x4b0)
  [c0032cf4] (worker_thread) from [c003747c] (kthread+0xcc/0xe8)
  [c003747c] (kthread) from [c000e738] (ret_from_fork+0x14/0x3c)
  ---[ end trace 40cd58bcd6988f12 ]---
 
  Fixes: a4a8c2c4962bb655 (ARM: exynos: Move to generic PM domain DT 
  bindings)
  Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
  Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 
 Reviewed-by: Kevin Hilman khil...@linaro.org
 
 And looks like we need this for v3.18-rc since it does fix the
 regression.

 I guess we do need it for 3.18, but when we are talking about 3.19,
 before we make any more changes can we outline how power domains are
 supposed to work?

Yes, I agree, we have some things to sort out for v3.19, but as this one
is a regression fix, I think it needs to be in v3.18-rc.

Kevin

 1. How do we attach a device to power domain? Right now it seems that
 individual buses are responsible for attaching their devices to power
 domains. Should we move it into driver core (device_pm_add?) so that
 device starts its life in its proper

Re: [PATCH] PM / Domains: Change prototype for the -attach_dev() callback

[Kevin Hilman]

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 On Thu, Oct 30, 2014 at 01:38:30PM -0700, Kevin Hilman wrote:
 Rafael J. Wysocki r...@rjwysocki.net writes:
 
  On Thursday, October 30, 2014 01:02:49 PM Ulf Hansson wrote:
  Convert the prototype to return and int. This is just an initial step,
  needed to support error handling.
  
  Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 
 Acked-by: Kevin Hilman khil...@linaro.org
 
  
  This patch is intended as fix for 3.18 rc[n]. Why?
  
  There are other SOC specific patches around that adds genpd support and 
  which
  implements the -attach_dev() callback. To prevent having an atomic 
  patch
  during the next release cycle, let's change the prototype now instead.
  
  Further patches will add the actual error handling in genpd and these can 
  then
  be reviewed and tested thoroughly.
 
  So we have no users of -attach_dev at the moment, right?
 
 Not in mainline, but there are a couple getting ready to hit -next, so
 we wanted to fix this before they arrive so that adding the error
 handling will be easier.

 BTW, while we are at it, can we also pass the domain itself to
 attach_dev() and detach_dev()? If anything it helps with debugging (you
 can print domain name from the callbacks).

Agreed, and it makes it match the other callbacks (power_off, power_on)
which currently take struct generic_pm_domain *domain.  

Updated version of $SUBJECT patch below.

Kevin


- 8 --
From 353a62ffae2f9228142c8a2093108f9eda8dc6b4 Mon Sep 17 00:00:00 2001
From: Ulf Hansson ulf.hans...@linaro.org
Date: Thu, 30 Oct 2014 13:02:49 +0100
Subject: [PATCH] PM / Domains: Change prototype for the -attach_dev()
 callback

Convert the prototype to return and int. This is just an initial step,
needed to support error handling.

Cc: Dmitry Torokhov dmitry.torok...@gmail.com
[khilman: added domain as parameter to callbacks, as suggested by Dmitry]
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Kevin Hilman khil...@linaro.org
---
 drivers/base/power/domain.c | 4 ++--
 include/linux/pm_domain.h   | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 40bc2f4072cc..b520687046d4 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1437,7 +1437,7 @@ int __pm_genpd_add_device(struct generic_pm_domain 
*genpd, struct device *dev,
spin_unlock_irq(dev-power.lock);
 
if (genpd-attach_dev)
-   genpd-attach_dev(dev);
+   genpd-attach_dev(genpd, dev);
 
mutex_lock(gpd_data-lock);
gpd_data-base.dev = dev;
@@ -1499,7 +1499,7 @@ int pm_genpd_remove_device(struct generic_pm_domain 
*genpd,
genpd-max_off_time_changed = true;
 
if (genpd-detach_dev)
-   genpd-detach_dev(dev);
+   genpd-detach_dev(genpd, dev);
 
spin_lock_irq(dev-power.lock);
 
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 73e938b7e937..b3ed7766a291 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -72,8 +72,10 @@ struct generic_pm_domain {
bool max_off_time_changed;
bool cached_power_down_ok;
struct gpd_cpuidle_data *cpuidle_data;
-   void (*attach_dev)(struct device *dev);
-   void (*detach_dev)(struct device *dev);
+   int (*attach_dev)(struct generic_pm_domain *domain,
+ struct device *dev);
+   void (*detach_dev)(struct generic_pm_domain *domain,
+  struct device *dev);
 };
 
 static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
-- 
2.1.0

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

Re: [RFC 1/2] PM / Domains: Power on domain early during system resume

[Kevin Hilman]

Andrzej Hajda a.ha...@samsung.com writes:

 On 10/30/2014 08:36 AM, Krzysztof Kozlowski wrote:
 On śro, 2014-10-29 at 10:46 -0700, Kevin Hilman wrote:
 Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 When resuming the system the power domain has to be powered on early so
 any runtime PM aware devices could resume.

 This fixes following scenario reproduced on Exynos DRM:
 1. Power domain is off before suspending the system.
 2. System is suspended to RAM.
 3. Resuming starts. The Exynos DRM driver resume callback is called.
 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
 Dumb Q: if the device (and power domain) were off before (and during)
 suspend, why are they being resumed?

 Shouldn't the resume path restore things to the same state they were
 before suspend?
 One could expect that... but the Exynos DRM driver behaves differently
 (and some other drivers also). In resume method it calls
 drm_helper_resume_force_mode() which forces restoring mode setting
 configuration. Apparently setting a mode needs DPMS on:
 static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
 {
  ...
  exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  ...

 The previous DPMS status (status during suspend) is completely ignored
 here.

 Suspend callback switches off all connectors (thus all other devs in
 their pipeline) by calling dpms_off,
 in restore callback all devs are restored to their previous state by
 calling appropriate dpms.
 So I guess drm_helper_resume_force_mode() call at the end of resume is
 incorrect.

Though I'm not terribly familiar with DRM, it seems incorrect because I
expect resume to restore the state of things when suspend happened, not
forcibly resume everything.

 On the other side it is present in many other drivers, so I am also
 little bit confused.

Many other DRM drivers?  or other drivers too?

Kevin

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

Re: pm_runtime_enable() in -probe()

[Kevin Hilman]

Rafael J. Wysocki r...@rjwysocki.net writes:

 On Saturday, November 01, 2014 02:08:57 AM Rafael J. Wysocki wrote:
 On Saturday, November 01, 2014 01:20:38 AM Rafael J. Wysocki wrote:
  On Friday, October 31, 2014 10:16:14 AM Ulf Hansson wrote:
   On 24 October 2014 18:12, Kevin Hilman khil...@kernel.org wrote:
 
 [cut]
 
   
   1)
   It's bad practice to use pm_runtime_get_sync() in the -probe() path,
  
  Honestly, I'm no longer amused.
  
   to bring your resources to full power. The consequence would be a
   driver that requires CONFIG_PM_RUNTIME to be even functional, which
   just isn't acceptable.
  
  Sorry, but this is utter nonsense.
  
  CONFIG_PM_RUNTIME unset means no runtime PM at all, so all drivers can 
  expect
  everything they need to be always on.  If that is not the case, then 
  someone is
  doing runtime PM behind the scenes and therefore cheating.  Or in different
  words, for CONFIG_PM_RUNTIME unset bus types, platforms etc must ensure 
  that
  everything is on from the drivers' perspective.
  
  If that is the case, then calling pm_runtime_get_sync() from -probe
  for CONFIG_PM_RUNTIME unset simply doesn't matter.
  
  Now, for CONFIG_PM_RUNTIME enabled, if power domains are in use, doing
  pm_runtime_get_sync() from -probe is the only way the driver can ensure
  in a non-racy way that the device will be accessible going forward.
  
  Why?  Simply because the probing need not happen during system 
  initialization.
  It very well may take places when the other devices in the same domain have
  beein in use for quite a while and have been using runtime PM (in which
  case the domain may go off at any time unless it is explicityly prevented 
  from
  doing that).
  
  One thing that you may be missing is that, for CONFIG_PM_RUNTIME set,
  runtime PM has to be either enabled or disabled for all devices in one
  domain (and if it is disabled, then the domain needs to be always on for
  all practical purposes).  Otherwise you can't just make all of them happy
  at the same time.  The documentation doesn't cover this, because it had 
  been
  written before we even started to consider power domains.
  
   Drivers that behaves well within this context, follows the runtime PM
   documentation/recommendation.
  
  So please go to Documentation/power/runtime_pm.txt and read it again.  
  Quote:
  
  If the default initial runtime PM status of the device (i.e. 'suspended')
  reflects the actual state of the device, its bus type's or its driver's
  -probe() callback will likely need to wake it up using one of the PM 
  core's
  helper functions described in Section 4.  In that case, pm_runtime_resume()
  should be used.  Of course, for this purpose the device's runtime PM has 
  to be
  enabled earlier by calling pm_runtime_enable().
 
 All that said there is a logical error related to calling pm_runtime_enable()
 and its derivatives from -probe() that I've been overlooking pretty much
 from the start.
 
 Namely, really_probe() sets dev-driver to drv before calling -probe()
 for either the bus type or the driver itself, so if the driver's probe
 calls pm_runtime_enable(), it will execute the driver's own runtime PM
 resume callback before the driver can check whether or not it wants to handle
 the device in the first place.  That doesn't sound quite right to me.
 
 This means we need a different mechanism to ensure that the device will
 be accessible to the driver and/or the bus type in -probe().
 
 At one point we had pm_runtime_get_sync() before really_probe() in
 driver_proble_device() IIRC, but people complained about it, so we dropped it
 and put a barrier in there instead, but that's not sufficient.

 So we actually had pm_runtime_get_noresume() before the barrier, but then
 we dropped it due to complaints.

 We need to explicitly ensure that the device won't be powered off while
 -probe() is in progress *but* we need to avoid calling the driver's runtime
 PM resume callback before -probe() returns.

 I wonder, then, if we just need to do pm_runtime_get_sync() instead of the
 barrier and then pm_runtime_put() instead of pm_request_idle() in
 driver_probe_device()?

Won't we still have the same problems in the case of -probe failure
that were fixed by removing those calls[1]?

IOW, after the driver's -probe returns failure, it's no longer safe to
call the driver's runtime PM callbacks, since they may be accessing
resources that no longer exits.

Hmm, thinking a little more, maybe this kind of failure is a good time
for the driver to use pm_runtime_force_suspend(), then later when the PM
core does the _put(), it will see the device aleady suspended and there
shouldn't be any problems.

So I think I'm OK with this approach, in theory.

Kevin

[1]
commit eed5d2150752bd08b22333d739f3120151773d28
Author: Rafael J. Wysocki r...@sisk.pl
Date:   Thu Jul 12 11:51:48 2012 +0200

PM / Runtime: Do not increment device usage counts before probing

The pm_runtime_get_noresume() calls before

Re: [PATCH 03/12] PM / Domains: Add notifier support for power domain transitions

[Kevin Hilman]

+Mike Turquette

Hi Amit,

Rafael J. Wysocki r...@rjwysocki.net writes:

 CC: Kevin, Ulf, Geert.

 On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote:
 These power domain transition notifiers will assist in carrying
 out some activity associated with domain power on/off such as
 some registers which may lose its contents and need save/restore
 across domain power off/on.

The runtime PM framework already provides callbacks that are useful for
context save/restore for devices.  Could you please describe in more
detail which registers in which kind of devices need to be
saved/restored, and why they cannot be saved/restored using existing
mechanisms.

Personally, I'm uncomfortable with notifiers like this because it
suggests that underlying frameworks are not doing the right thing, or
are not being used.  (I also don't like the implementation here where a
single global notifier list is maintained by the core, but the notifiers
are actually triggered by SoC specific code.)

IIUC, the usage in this series seems to be that certain clock related
registers need to be saved/restored across a power domain transition.

Wouldn't an alternative solution be to add a feature to the clock driver
such that the state of each clock is saved when the clock is disabled,
and restored when the clock is enabled?   That would allow any clock
context to survive any power domain transtion also, correct?

I have some issues with the implementaion as well, but I think we need
to first sort out the real need for this before going into those
details.

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

Re: exynos5420/arndale-octa: imprecise external aborts on exynos_defconfig

[Kevin Hilman]

On Wed, Sep 17, 2014 at 5:39 PM, Kevin Hilman khil...@kernel.org wrote:
 Thomas Abraham ta.oma...@gmail.com writes:

 On Thu, Sep 11, 2014 at 12:16 AM, Kevin Hilman khil...@kernel.org wrote:
 Tyler Baker tyler.ba...@linaro.org writes:

 Exynos5420-based Arndale octa boards have recently started failing boot
 tests due to imprecise external aborts.  This only appears to happen
 when using exynos_defconfig and boots fine with multi_v7_defconfig.  The
 issue seems to be intermittent, so is not reliably reproducable and
 difficult to bisect.  Here are a few boot logs from recent
 mainline/linux-next kernels that are failing:

 FYI, I'm seeing the same periodic aborts.  For example, here's my boot
 of next-20140910:
 http://images.armcloud.us/kernel-ci/next/next-20140910/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html

 However, my userspace is much simpler and doesn't seem to cause a panic,
 so my boot tests report passing. (I should fixup my scripts so these
 imprecise aborts are reported as a FAIL.)

 I'm glad you pointed out that it happens only with exynos_defconfig and
 not multi_v7_defconfig because I noticed that too.  I haven't had the
 time to track it any further than that, so maybe the exynos folks can
 help track it down from here.

 Thanks for reporting this,

 Kevin

 Hi Tyler, Kevin,

 From the bootlog you have shared,

 [1.060016] CPU4: failed to come online
 [2.070031] CPU5: failed to come online
 [3.080049] CPU6: failed to come online
 [4.090066] CPU7: failed to come online
 [4.090099] Brought up 4 CPUs
 [4.090109] SMP: Total of 4 processors activated.
 [4.090119] CPU: WARNING: CPU(s) started in wrong/inconsistent
 modes (primary CPU mode 0x13)
 [4.090128] CPU: This may indicate a broken bootloader or firmware.

 Would it be possible to set max cpus to 1, disable switcher and try
 again. I don't have a arndale octa board but I have tested mainline
 kernel with smdk5420 board. It boots all eight CPUs, switcher works
 fine and there are no imprecise aborts seen.

 Sorry for the delay, I'm travelling this week.

 FWIW, the same CPU boot failures you hilight above are happening on
 multi_v7_defconfig[1] which is not getting the imprecise abort.  This is
 only happening on exynos_defconfig[2], so I'm curious why you think the
 switcher or NR_CPUS might be the issues.

 Anyways, I narrowed this down a bit and discovered it's
 CONFIG_EXYNOS5420_MCPM=y that's the root cause.  If I use
 exynos_defconfig and then disable that option, I don't get any more
 imprecise aborts.

These imprecise aborts are still happening, and preventing running
full userspace.

I'm going to send a patch to disable this CONFIG_EXYNOS5420_MCPM until
someone can figure out what's going on.

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

[PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
during boot testing, causing various userspace startup failures.

Disable until it has gotten more testing.

Cc: Kukjin Kim kgene@samsung.com,
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk,
Cc: Sachin Kamat sachin.ka...@samsung.com,
Cc: Doug Anderson diand...@chromium.org,
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com,
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com,
Cc: Tushar Behera tushar.beh...@linaro.org,
Cc: sta...@vger.kernel.org # v3.17+
Signed-off-by: Kevin Hilman khil...@linaro.org
---
This has been reported by a few people[1], but not investigated or fixed, so 
it's
time to disable this feature until it can be fixed.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288344.html

 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 72058b8a6f4d..a250dcbf34cd 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -10,7 +10,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_EXYNOS3=y
-CONFIG_EXYNOS5420_MCPM=y
+CONFIG_EXYNOS5420_MCPM=n
 CONFIG_SMP=y
 CONFIG_BIG_LITTLE=y
 CONFIG_BL_SWITCHER=y
-- 
2.1.0

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

Re: [PATCH] PM / Domains: Change prototype for the -attach_dev() callback

[Kevin Hilman]

Rafael J. Wysocki r...@rjwysocki.net writes:

 On Thursday, October 30, 2014 01:02:49 PM Ulf Hansson wrote:
 Convert the prototype to return and int. This is just an initial step,
 needed to support error handling.
 
 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org

Acked-by: Kevin Hilman khil...@linaro.org

 
 This patch is intended as fix for 3.18 rc[n]. Why?
 
 There are other SOC specific patches around that adds genpd support and which
 implements the -attach_dev() callback. To prevent having an atomic patch
 during the next release cycle, let's change the prototype now instead.
 
 Further patches will add the actual error handling in genpd and these can 
 then
 be reviewed and tested thoroughly.

 So we have no users of -attach_dev at the moment, right?

Not in mainline, but there are a couple getting ready to hit -next, so
we wanted to fix this before they arrive so that adding the error
handling will be easier.

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

Re: [PATCH v3 0/9] PM / Domains: Fix race conditions during boot

[Kevin Hilman]

Mark Brown broo...@kernel.org writes:

 On Fri, Oct 24, 2014 at 09:12:39AM -0700, Kevin Hilman wrote:
 Ulf Hansson ulf.hans...@linaro.org writes:

  There may be more than one device in a PM domain which then will be
  probed at different points in time.

  Depending on timing and runtime PM support, in for the device related
  driver/subsystem, a PM domain may be advised to power off after a
  successful probe sequence.

  A general requirement for a device within a PM domain, is that the
  PM domain must stay powered during the probe sequence. To cope with
  such requirement, let's add two new APIs, dev_pm_domain_get|put().

 I'm confused. Why arent' pm_runtime_get*() and pm_runtime_put*() working?

 What's not explained here (or what I'm not understanding) is why a PM
 domain is powering off if it has active devices.

 The issue AIUI is what happens during system boot - if one device in a
 domain probes and marks itself runtime idle then that will trigger
 domain powerdown even if there is another device in the domain that
 hasn't yet been probed.  This can cause undesirable glitches (or worse)
 during boot depending on what's getting powered down.

I'm not quite seeing how this series fixes that problem.

Looking at platform devices in PATCH 4/9, the new _get() and _put() are
still happening around -probe(), so if a platform device runtime suspends
after probe, don't we still have a PM domain that can turn off?

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

Re: [PATCH v3 4/9] drivercore / platform: Keep PM domain powered during -probe()

[Kevin Hilman]

Ulf Hansson ulf.hans...@linaro.org writes:

 To sucessfully probe some devices their corresponding PM domains may
 need to be powered.

Isn't that what pm_runtime_get*() is supposed to be doing?  Why isn't
that working?

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

Re: [RFC 1/2] PM / Domains: Power on domain early during system resume

[Kevin Hilman]

Krzysztof Kozlowski k.kozlow...@samsung.com writes:

 When resuming the system the power domain has to be powered on early so
 any runtime PM aware devices could resume.

 This fixes following scenario reproduced on Exynos DRM:
 1. Power domain is off before suspending the system.
 2. System is suspended to RAM.
 3. Resuming starts. The Exynos DRM driver resume callback is called.
 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.

Dumb Q: if the device (and power domain) were off before (and during)
suspend, why are they being resumed?

Shouldn't the resume path restore things to the same state they were
before suspend?

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