Re: Feedback on hardware support for Odroid U3
2015-08-05 22:07 GMT+09:00 Thomas Pietrowski thopie...@gmail.com: Sorry for the long delay. Got now linux-stable 4.2.0-rc5 running here, but I still miss the fan support. Searched the web again for the patch and found this on LKML: https://lkml.org/lkml/2014/12/18/138 Then looked at the arm-soc repository but found this patch nowhere. Are you planing to add this in future releases? Me? No, I am not planning to work on this. Also I don't have an Odroid U3 with a fan. I think you should ask the author of the patchset. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?
2015-06-15 19:19 GMT+09:00 Przemyslaw Marczak p.marc...@samsung.com: Hello Krzysztof, On 06/14/2015 10:56 AM, Krzysztof Kozłowski wrote: 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. Best regards, Krzysztof 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. The BL1 keeps signature key and some part of code, but it's code is proprietary - but we should be able to setup the secondary cores in BL2. When, I get the basic setup working, then I'm going to focus on the secondary CPU's init. I don't have the documentation for iROM code, so everything takes a while. Great, good luck! If you looking for the lowlevel code, which is executed after wakeup, please check this : https://github.com/hardkernel/u-boot/blob/odroidxu3-v2012.07/board/samsung/smdk5422/lowlevel_init.S The 'lowlevel_init' label is always executed on boot. I already looked at it without any success. I couldn't find the reason of this SPARE2 behaviour in that code. However I found there one small funny fact about magic values for low power modes - kernel and u-boot expect some of the values in different places. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?
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. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: ARM: EXYNOS: Describe boot loaders interface
2015-06-06 20:01 GMT+09:00 Peter Chubb peter.ch...@nicta.com.au: Krzysztof == Krzysztof Kozlowski k.kozlowsk...@gmail.com writes: Krzysztof Various boot loaders for Exynos based boards use certain Krzysztof memory addresses during booting for different Krzysztof purposes. Mostly this is one of following : 1. as a CPU Krzysztof boot address, 2. for storing magic cookie related to low Krzysztof power mode (AFTR, sleep). Krzysztof The document, based solely on kernel source code, tries to Krzysztof group the information scattered over different files. This Krzysztof would help in the future when adding support for new SoC or Krzysztof when extending features related to low power modes. Is it worth grabbing the info from u=boot and documenting it here (it's not documented other than in the hardkenel U=Boot source)? I can send you the info, or you can see it in https://github.com/hardkernel/u-boot/blob/odroidxu3-v2012.07/board/samsung/smdk5420/lowlevel_init.S at symbol nscode_base near line 104 Hi, +CC Łukasz Majewski (u-boot) The patch actually covers u-boot. What is missing: 1, Reset - I think kernel does not set it. 2. LPA - There is no mainline support for it yet so I did not add it. It should be added along with cpuidle LPA. 3. MCPM and Exynos542x stuff. There are some exceptions and weird comments in the kernel (like To increase the stability of KFC reset we need to program the PMU SPARE3 register). It would take me some more time to understand it so I wanted to start with basic version and get comments. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exynos 5410 support (was [PATCH 6/6] ARM: dts: exynos5420: add sysmmu nodes)
2015-06-02 17:13 GMT+09:00 Ben Gamari b...@smart-cactus.org: On 06/01/2015 07:51 PM, Krzysztof Kozłowski wrote: 2015-06-02 4:12 GMT+09:00 Ben Gamari b...@smart-cactus.org: (...) Worse, the few patches that have been submitted for the 5410 have languished in queue-purgatory. What patches do you have in mind? Hmm, my apologies; I guess the reference was dropped somewhere. In particular I was referring to this set[1], which added pinctrl support for the 5410 and a devicetree for the Odroid XU. Thanks. I will take a look at them. If you have any other stuff which was missed/skipped/ignored, don't hesitate to resend (if you're the author) or ping. Best regards, Krzysztof Cheers, - Ben [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330819.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: Exynos 5410 support (was [PATCH 6/6] ARM: dts: exynos5420: add sysmmu nodes)
2015-06-02 4:12 GMT+09:00 Ben Gamari b...@smart-cactus.org: On 06/01/2015 06:10 AM, Marek Szyprowski wrote: This patch adds System MMU nodes to all defined devices that are specific to Exynos5420/5800/5422 series. (...) Worse, the few patches that have been submitted for the 5410 have languished in queue-purgatory. What patches do you have in mind? Beside of that actually many submissions for different Exynos SoCs and parts of it were ignored on the list. It is a pity because that means someone's effort got lost. Recently I tried to help in that matter and replied to some emails about resubmitting. If you have anything pending just please let me know. To make it clear - I am speaking for myself, not for any company or employer. Also I do not know anything about other people's motivation behind doing patches only for chosen SoCs. I leave these questions to them. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: dts: exynos4412: Enable AX88760 USB hub on Origen board
2015-04-14 2:02 GMT+09:00 Matthew Leach matt...@mattleach.net:
Enable the Origen's usb phy and ohci devices in the device tree. Also
add the samsung,vbus-gpio property to enable the GPX3(5) gpio pin so
the AX88760 hub is powered.
Signed-off-by: Matthew Leach matt...@mattleach.net
---
arch/arm/boot/dts/exynos4412-origen.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index bd8b730..c810ca3 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -531,4 +531,19 @@
clock-frequency = 2400;
};
};
+
+ exynos-usbphy@125B {
Could you use label notation here?
exynos_usbphy {
...
}
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 02/11] dts: exynos4: add node for the HDMI CEC device
2015-05-05 2:32 GMT+09:00 Kamil Debski k.deb...@samsung.com: This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski k.deb...@samsung.com Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/10] clk: samsung: exynos5433: Fix wrong parent clock of sclk_apollo clock
2015-04-27 20:36 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com: This patch fixes the wrong parent clock of sclk_apollo clock from 'div_apollo_pll' to 'div_apollo2'. Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Hi, Reviewed-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/10] clk: samsung: exynos5433: Add CLK_IGNORE_UNUSED flag to clocks for sercure monitor call
2015-04-27 20:36 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com: From: Jonghwa Lee jonghwa3@samsung.com This patch adds 'CLK_IGNORE_UNUSED' flag to clocks which is required for operation of secure monitor call (smc). System will hang when it executes 'smc' with one of those clock is gated. All related clocks must be enabled. Signed-off-by: Jonghwa Lee jonghwa3@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Hi, Reviewed-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] clk: samsung: exynos5433: Fix CLK_PCLK_MONOTONIC_CNT's register correctly.
2015-04-27 20:36 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com: From: Jonghwa Lee jonghwa3@samsung.com CLK_PCLK_MONOTONIC_CNT's register is now assigned with wrong one. Its correct register is ENABLE_PCLK_MIF_SECURE_MONOTONIC_CNT. Signed-off-by: Jonghwa Lee jonghwa3@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Hi, Reviewed-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/10] clk: samsung: exynos5433: Add CLK_IGNORE_UNUSED flag to prevent the hang for suspend-to-ram
2015-04-27 20:36 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com:
From: Jonghwa Lee jonghwa3@samsung.com
Some clocks are required being unmasked for suspend-to-ram. Otherwise,
PMU (Power Management Unit) will stick and power line never down.
You mean will stuck and never power down?
One minor nit below, but overall looks good:
Reviewed-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
Best regards,
Krzysztof
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/clk/samsung/clk-exynos5433.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 39c9564..84f02ec 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -697,11 +697,14 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_SCLK_PCM1_PERIC, sclk_pcm1_peric, div_sclk_pcm1,
ENABLE_SCLK_TOP_PERIC, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART2_PERIC, sclk_uart2_peric, div_sclk_uart2,
- ENABLE_SCLK_TOP_PERIC, 5, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP_PERIC, 5, CLK_SET_RATE_PARENT |
+ CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_UART1_PERIC, sclk_uart1_peric, div_sclk_uart1,
- ENABLE_SCLK_TOP_PERIC, 4, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP_PERIC, 4, CLK_SET_RATE_PARENT |
+ CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_UART0_PERIC, sclk_uart0_peric, div_sclk_uart0,
- ENABLE_SCLK_TOP_PERIC, 3, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP_PERIC, 3, CLK_SET_RATE_PARENT |
+ CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_SPI2_PERIC, sclk_spi2_peric, div_sclk_spi2_b,
ENABLE_SCLK_TOP_PERIC, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI1_PERIC, sclk_spi1_peric, div_sclk_spi1_b,
@@ -862,7 +865,7 @@ static struct samsung_div_clock cpif_div_clks[]
__initdata = {
static struct samsung_gate_clock cpif_gate_clks[] __initdata = {
/* ENABLE_SCLK_CPIF */
GATE(CLK_SCLK_MPHY_PLL, sclk_mphy_pll, mout_mphy_pll,
- ENABLE_SCLK_CPIF, 9, 0, 0),
+ ENABLE_SCLK_CPIF, 9, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_UFS_MPHY, sclk_ufs_mphy, div_sclk_mphy,
ENABLE_SCLK_CPIF, 4, 0, 0),
};
@@ -1444,6 +1447,7 @@ static struct samsung_gate_clock mif_gate_clks[]
__initdata = {
GATE(CLK_PCLK_ASYNCAXI_NOC_P_CCI, pclk_asyncaxi_noc_p_cci,
div_aclk_mif_133, ENABLE_PCLK_MIF, 21,
CLK_IGNORE_UNUSED, 0),
+
This new line seems unrelated.
GATE(CLK_PCLK_ASYNCAXI_CP1, pclk_asyncaxi_cp1, div_aclk_mif_133,
ENABLE_PCLK_MIF, 19, 0, 0),
GATE(CLK_PCLK_ASYNCAXI_CP0, pclk_asyncaxi_cp0, div_aclk_mif_133,
--
To unsubscribe from this list: send the line unsubscribe linux-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] ASoC: samsung: s3c24xx-i2s: Fix return value check in s3c24xx_iis_dev_probe()
2015-04-16 21:18 GMT+09:00 weiyj...@163.com: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- sound/soc/samsung/s3c24xx-i2s.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Good catch. Reviewed-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: dts: Refactor Exynos5 boards for phandle notation
2015-04-13 5:07 GMT+09:00 Arnd Bergmann a...@arndb.de:
On Sunday 12 April 2015 21:24:47 Krzysztof Kozlowski wrote:
The phandle notation reduces possible mistakes when overriding nodes
by child board files and reduces duplication of addresses.
The patchset refactors Exynos5 boards to use the phandle way.
Tested by comparison of decompiled DTB for each commit.
The patches look fine, but the description is wrong as you are not
using 'phandles' here, you are using 'labels'.
Heh, I suspected this but some docs I found referred to label { ...
} also as a phandle. Thanks for pointing this out. I'll respin.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] ARM: EXYNOS: suspend requires regulator access
W dniu poniedziałek, 2 marca 2015 Arnd Bergmann a...@arndb.de napisał(a): Building an exynos kernel without regulators but with suspend enabled results in a link error: arch/arm/mach-exynos/built-in.o: In function `exynos_suspend_finish': arch/arm/mach-exynos/suspend.c:532: undefined reference to `regulator_suspend_finish' arch/arm/mach-exynos/built-in.o: In function `exynos_suspend_prepare': arch/arm/mach-exynos/suspend.c:515: undefined reference to `regulator_suspend_prepare' This adds an appropriate 'select' statement in Kconfig to ensure the symbols are available. Signed-off-by: Arnd Bergmann a...@arndb.de Isn't this fixed already by: https://lkml.org/lkml/2015/2/4/119 (applied by Mark Brown)? I can't test it now (I am out of office) but issue looks quite similar. Best regards, Krzysztof --- arch/arm/mach-exynos/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 603820e5aba7..f4bd06370ad8 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -22,6 +22,7 @@ menuconfig ARCH_EXYNOS select PINCTRL select PINCTRL_EXYNOS select PM_GENERIC_DOMAINS if PM + select REGULATOR if PM_SLEEP select S5P_DEV_MFC select SRAM select MFD_SYSCON -- 2.1.0.rc2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-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: smdk4412 (Samsung Galaxy S3 i9300) status
2015-02-28 11:57 GMT+01:00, Nicolae Rosia nicolae.ro...@gmail.com: Hello, I want to boot my i9300 to a framebuffer console with the mainline kernel. Did anyone tried this already and have a device tree for the device? Hi, The Trats2 device is the other name for S3, so you can use exynos defconfig and exynos4412-trats2.dts. P.S. I am resending the mail because Google produced HTML which is banned on LKML. Best regards, Krzysztof Best regards, Nicolae Rosia -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
2015-01-30 15:21 GMT+01:00 Damian Eppel d.ep...@samsung.com:
This is to fix an issue of sleeping in atomic context when processing
hotplug notifications in Exynos MCT(Multi-Core Timer).
The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
(Arndale Octa board).
Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
request_irq() and free_irq() in the context of hotplug notification
(which is in this case atomic context).
root@target:~# echo 0 /sys/devices/system/cpu/cpu1/online
[ 25.157867] IRQ18 no longer affine to CPU1
...
[ 25.158445] CPU1: shutdown
root@target:~# echo 1 /sys/devices/system/cpu/cpu1/online
[ 40.785859] CPU1: Software reset
[ 40.786660] BUG: sleeping function called from invalid context at
mm/slub.c:1241
[ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 40.786678] Preemption disabled at:[ (null)] (null)
[ 40.786681]
[ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.19.0-rc4-00024-g7dca860 #36
[ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 40.786728] [c0014a00] (unwind_backtrace) from [c0011980]
(show_stack+0x10/0x14)
[ 40.786747] [c0011980] (show_stack) from [c0449ba0]
(dump_stack+0x70/0xbc)
[ 40.786767] [c0449ba0] (dump_stack) from [c00c6124]
(kmem_cache_alloc+0xd8/0x170)
[ 40.786785] [c00c6124] (kmem_cache_alloc) from [c005d6f8]
(request_threaded_irq+0x64/0x128)
[ 40.786804] [c005d6f8] (request_threaded_irq) from [c0350b8c]
(exynos4_local_timer_setup+0xc0/0x13c)
[ 40.786820] [c0350b8c] (exynos4_local_timer_setup) from [c0350ca8]
(exynos4_mct_cpu_notify+0x30/0xa8)
[ 40.786838] [c0350ca8] (exynos4_mct_cpu_notify) from [c003b330]
(notifier_call_chain+0x44/0x84)
[ 40.786857] [c003b330] (notifier_call_chain) from [c0022fd4]
(__cpu_notify+0x28/0x44)
[ 40.786873] [c0022fd4] (__cpu_notify) from [c0013714]
(secondary_start_kernel+0xec/0x150)
[ 40.786886] [c0013714] (secondary_start_kernel) from [40008764]
(0x40008764)
Solution:
Clockevent irqs cannot be requested/freed every time cpu is
hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
that signals hotplug or unplug events are sent with both preemption
and local interrupts disabled. Since request_irq() may sleep it is
moved to the initialization stage and performed for all possible
cpus prior putting them online. Then, in the case of hotplug event
the irq asociated with the given cpu will simply be enabled.
Similarly on cpu unplug event the interrupt is not freed but just
disabled.
Note that after successful request_irq() call for a clockevent device
associated to given cpu the requested irq is disabled (via disable_irq()).
That is to make things symmetric as we expect hotplug event as a next
thing (which will enable irq again). This should not pose any problems
because at the time of requesting irq the clockevent device is not
fully initialized yet, therefore should not produce interrupts at that point.
For disabling an irq at cpu unplug notification disable_irq_nosync() is
chosen which is a non-blocking function. This again shouldn't be a problem as
prior sending CPU_DYING notification interrupts are migrated away
from the cpu.
Fixes: 7114cd749a12 (clocksource: exynos_mct: use (request/free)_irq calls
for local timer registration)
Signed-off-by: Damian Eppel d.ep...@samsung.com
Cc: sta...@vger.kernel.org
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/clocksource/exynos_mct.c | 45
1 file changed, 32 insertions(+), 13 deletions(-)
Hi,
Look fine from my point of view.
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Tested on Arndale Octa Board. Fixes the sleep-in-atomic.
Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 83564c9..9beca58 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt-base + MCT_L_TCNTB_OFFSET);
if (mct_int_type == MCT_INT_SPI) {
- evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
- if (request_irq(evt-irq, exynos4_mct_tick_isr,
- IRQF_TIMER | IRQF_NOBALANCING,
- evt-name, mevt)) {
- pr_err(exynos-mct: cannot register IRQ %d\n,
- evt-irq);
+
+ if (evt-irq == -1)
return -EIO;
- }
- irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu],
cpumask_of(cpu));
+
+ irq_force_affinity(evt-irq, cpumask_of(cpu));
+
Re: Exynos4 CONFIG_HZ
2015-01-18 17:57 GMT+01:00 Sten Spans s...@blinkenlights.nl: With the improvements in upstream support for exynos4 devices I've been looking into adding support odroid devices to Debian's armmp kernel. The kernel config changes needed are quite minimal as can be seen here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774896 Mostly enabling support and various modules. However as Ian Campbell notes, enabling ARCH_EXYNOS4 triggers the following from arch/arm/Kconfig: config HZ_FIXED int default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \ ARCH_S5PV210 || ARCH_EXYNOS4 default AT91_TIMER_HZ if ARCH_AT91 default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY default 0 This forces CONFIG_HZ=200 for the entire armmp kernel, which is undesirable. The reason for this setting isn't very clear to either me or Ian. I personally have verified that HZ=250 (the default for debian armmp kernels) boots fine. Is there a particular reason for this setting? Would a patch removing this requirement for ARCH_EXYNOS4 be accepted? +Cc Kukjin Kim I cannot find a valid reason for fixed 200 Hz, especially that other values (100, 1000) are working. Maybe Kukjin will share some light on this? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Weird/Unneeded call to msleep in exynos_mipi_dsi_wr_data in exynos_mipi_dsi_common.c
On 17.12.2014 23:57, nick wrote: Greetings Fellow Maintainers, Sorry if I wasting your time but it seems there is a unneeded call to msleep Hi, 1. Please describe exactly why do you think this is not needed. 2. Do you have Exynos-based hardware to test your changes? Best regards, Krzysztof and rather trivial fix me to fix in the file,exynos_mipi_dsi_common.c for the function,exynos_mipi_dsi_wr_data . If there is a valid reason for this call please let me known when any of you have some free time. Otherwise I will send in a patch to remove this unneeded call to msleep. Thanks, Nick -- To unsubscribe from this list: send the line unsubscribe linux-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] iommu/exynos: Fix arm64 allmodconfig build
On 15.12.2014 14:00, Mark Brown wrote: The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and outer_flush_range() functions. This breaks the build on arm64 allmodconfig in -next since support has been merged for some Exynos ARMv8 SoCs. Add a dependency on ARM to keep things building until either the driver has the ARM dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Hi Mark, Few days ago I posted similar patch: https://lkml.org/lkml/2014/12/5/268 but no one have picked it up. Anyway the fix of yours seems fine to me. Best regards, Krzysztof Signed-off-by: Mark Brown broo...@kernel.org --- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 01e8bfae569b..325188eef1c1 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,7 +187,7 @@ config TEGRA_IOMMU_SMMU config EXYNOS_IOMMU bool Exynos IOMMU Support - depends on ARCH_EXYNOS + depends on ARCH_EXYNOS ARM select IOMMU_API select ARM_DMA_USE_IOMMU help -- To unsubscribe from this list: send the line unsubscribe linux-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] mfd: max77686: Fix parent of rtc device
On 02.12.2014 13:45, Yadwinder Singh Brar wrote:
rtc have different i2c client than power(pmic) block. So rtc device should
sit under its own i2c client in device hierarchy, which reflects in sysfs
also.
This patch modifies code to register rtc cell with rtc-dev as parent.
Without this patch :
# ls /sys/class/i2c-adapter/i2c-0/0-0009/
driver max77686-pmic modalias power uevent
max77686-clk max77686-rtc name subsystem
After applying patch :
# ls /sys/class/i2c-adapter/i2c-0/0-0006/
driver/modalias power/ uevent
max77686-rtc/ name subsystem/
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
Or Can we follow another (exhaustive but more cleaner) approach, which will
be more like code refactoring and cleanup rather than only fix:
Since rtc uses i2c client, which gets created using i2c_new_dummy() and is not
shared by any other cell of max77686. So we can covert rtc platform driver
itself to i2c client driver. It will also allow to expilicitly describe
max77686-rtc in DT which we can't do now.
It can be applicable to some other existing and new mfd pmic drivers.
Any suggestion/comments ?
Hi,
What kind of problem is solved by this patch?
Best regards,
Krzysztof
---
drivers/mfd/max77686.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 929795e..22c0948 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -39,10 +39,13 @@
static const struct mfd_cell max77686_devs[] = {
{ .name = max77686-pmic, },
- { .name = max77686-rtc, },
{ .name = max77686-clk, },
};
+static const struct mfd_cell max77686_rtc_dev[] = {
+ { .name = max77686-rtc, },
+};
+
static const struct mfd_cell max77802_devs[] = {
{ .name = max77802-pmic, },
{ .name = max77802-clk, },
@@ -332,14 +335,27 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
goto err_del_irqc;
}
+ if (max77686-type == TYPE_MAX77686) {
+ ret = mfd_add_devices(max77686-rtc-dev, -1, max77686_rtc_dev,
+ 1, NULL, 0, NULL);
+ if (ret 0) {
+ dev_err(max77686-rtc-dev,
+ failed to add RTC device %d\n, ret);
+ goto err_del_rtc_irqc;
+ }
+ }
+
ret = mfd_add_devices(max77686-dev, -1, cells, n_devs, NULL, 0, NULL);
if (ret 0) {
dev_err(i2c-dev, failed to add MFD devices: %d\n, ret);
- goto err_del_rtc_irqc;
+ goto err_del_rtc_dev;
}
return 0;
+err_del_rtc_dev:
+ if (max77686-type == TYPE_MAX77686)
+ mfd_remove_devices(max77686-rtc-dev);
err_del_rtc_irqc:
regmap_del_irq_chip(max77686-irq, max77686-rtc_irq_data);
err_del_irqc:
@@ -356,6 +372,8 @@ static int max77686_i2c_remove(struct i2c_client *i2c)
struct max77686_dev *max77686 = i2c_get_clientdata(i2c);
mfd_remove_devices(max77686-dev);
+ if (max77686-type == TYPE_MAX77686)
+ mfd_remove_devices(max77686-rtc-dev);
regmap_del_irq_chip(max77686-irq, max77686-rtc_irq_data);
regmap_del_irq_chip(max77686-irq, max77686-irq_data);
--
To unsubscribe from this list: send the line unsubscribe linux-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
On 17.11.2014 16:57, Kevin Hilman wrote: 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. Cc: +Inki Dae, +dri-devel This came up on Trats2 board (Exynos 4412) since next-20141105: https://lkml.org/lkml/2014/11/6/125 Disabling DRM helps. Best regards, Krzysztof 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 -- To unsubscribe from this list: send the line unsubscribe linux-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] drm/exynos: resolve infinite loop issue on multi-platform
On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Does not help for Rinato board.
On Rinato:
---
Failed to find PMU node
Registering SWP/SWPB emulation handler
mmc0: BKOPS_EN bit is not set
mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req 1Hz,
actual 1HZ div = 0)
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmc0: new HS200 MMC card at address 0001
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: mmc0:0001 F5X5MA 3.64 GiB
mmcblk0boot0: mmc0:0001 F5X5MA partition 1 4.00 MiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmcblk0boot1: mmc0:0001 F5X5MA partition 2 4.00 MiB
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0rpmb: mmc0:0001 F5X5MA partition 3 512 KiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: p1 p2 p3 p4 p5 p6 p7
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
and so on...
---
I do not know whether it is related but Trats2 board cannot boot due to
lockup after:
[drm] Initialized drm 1.1.0 20060810
(with or without the patch)
https://lkml.org/lkml/2014/11/6/125
Best regards,
Krzysztof
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 443a206..ecc86aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -734,6 +734,18 @@ static int exynos_drm_init(void)
{
int ret;
+ /*
+ * Register device object only in case of Exynos SoC.
+ *
+ * Below codes resolves temporarily infinite loop issue incurred
+ * by Exynos drm driver when using multi-platform kernel.
+ * So these codes will be replaced with more generic way later.
+ */
+ if (!of_machine_is_compatible(samsung,exynos3)
+ !of_machine_is_compatible(samsung,exynos4)
+ !of_machine_is_compatible(samsung,exynos5))
+ return -ENODEV;
+
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/3] ARM: dts: Add board dts file for Exynos3250-based Rinato board
On 24.10.2014 13:39, Chanwoo Choi wrote:
This patch add support for device tree sources for Samsung Rinato baord
(Gear 2) based on Exynos3250 SoC.
This dts file support following features:
- eMMC
- Main PMIC (Samsung S2MPS14)
- Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
- RTC of Exynos3250
- ADC of Exynos3250 with NTC thermistor
- I2S of Exynos3250
- TMU of Exynos3250
- MFC of Exynos3250
- Secure firmware for Exynos3250 secondary cpu boot
- Serial ports of Exynos3250
- gpio-key for power key
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 433
2 files changed, 435 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos3250-rinato.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4a75e29..91cd4d0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,7 +67,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
+ exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos4210-universal_c210.dtb \
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
new file mode 100644
index 000..be0ba8d
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -0,0 +1,433 @@
+/*
+ * Samsung's Exynos3250 based Rinato board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Rinato board which is based on
+ * Samsung Exynos3250 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos3250.dtsi
+#include dt-bindings/input/input.h
+
+/ {
+ model = Samsung Rinato board;
+ compatible = samsung,rinato, samsung,exynos3250, samsung,exynos3;
+
+ aliases {
+ i2c7 = i2c_max77836;
+ };
+
+ memory {
+ reg = 0x4000 0x1ff0;
+ };
+
+ chosen {
+ bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15
rootwait earlyprintk panic=5;
+ };
+
+ firmware@0205F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0205F000 0x1000;
+ };
+
+ gpio_keys {
+ compatible = gpio-keys;
+
+ power_key {
+ interrupt-parent = gpx2;
+ interrupts = 7 0;
+ gpios = gpx2 7 1;
+ linux,code = KEY_POWER;
+ label = power key;
+ debounce-interval = 10;
+ gpio-key,wakeup;
+ };
+ };
+
+ vemmc_reg: voltage-regulator-0 {
+ compatible = regulator-fixed;
+ regulator-name = V_EMMC_2.8V-fixed;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpk0 2 0;
+ enable-active-high;
+ };
Hi Chanwoo,
I wonder if this regulator-fixed is needed. The LDO11 and LDO12 has
external GPIO control set up. So maybe this could be removed?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish
On 20.10.2014 23:05, Javier Martinez Canillas wrote: Hello, This series add support for Exynos platforms to prepare regulators for system suspend. The regulator core has a set of helpers functions to be used when the system is entering and leaving from a suspend state but currently there is only one user in mainline. This user is drivers/mfd/sec-core.c but it calls regulator_suspend_prepare() from within the driver power-management suspend function. This does not seems to be correct since the regulator suspend prepare function affects all regulators in the system and not only the ones managed by this device. So patch #1 in this series revert the commit that introduced that change and patch #2 calls the regulator framework suspend/finish functions from the Exynos platform power-management code. The first patch should be queued through the mfd tree and the second through the linux-samsung tree. Changes since v2: - Check for regulator_suspend_finish() return value for an error. Suggested by Doug Anderson. Changes since v1: - Remove the call to regulator_suspend_prepare() from drivers/mfd/sec-core.c as suggested by Doug Anderson. - Call regulator_suspend_prepare() before s3c_pm_check_prepare() as suggested by Doug Anderson. - Added Lee Jones to cc list since there is a change for the mfd framework. Javier Martinez Canillas (2): Revert mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption ARM: EXYNOS: Call regulator core suspend prepare and finish functions arch/arm/mach-exynos/suspend.c | 23 +++ drivers/mfd/Kconfig| 1 - drivers/mfd/sec-core.c | 10 -- 3 files changed, 23 insertions(+), 11 deletions(-) Patchset tested on Trats2 board (Exynos4412 with max77686 PMIC, modified DTS to disable buck[134] during suspend to RAM). Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exynos build failure in -next allmodconfig
On 15.09.2014 19:57, Russell King - ARM Linux wrote: On Mon, Sep 15, 2014 at 09:34:58AM -0700, Mark Brown wrote: On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown wrote: Today's -next got a build failure in ARM allmodconfig due to platsmp.c: | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in return expression (different address spaces) | arch/arm/mach-exynos/platsmp.c:198:31:expected void [noderef] asn:2* | arch/arm/mach-exynos/platsmp.c:198:31:got void * | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in return expression (different address spaces) | arch/arm/mach-exynos/platsmp.c:198:31:expected void [noderef] asn:2* | arch/arm/mach-exynos/platsmp.c:198:31:got void * | CC arch/arm/mach-exynos/platsmp.o | /tmp/ccC9fkwF.s: Assembler messages: | /tmp/ccC9fkwF.s:423: Error: selected processor does not support ARM mode `isb ' | /tmp/ccC9fkwF.s:428: Error: selected processor does not support ARM mode `isb ' | /tmp/ccC9fkwF.s:429: Error: selected processor does not support ARM mode `dsb ' | scripts/Makefile.build:257: recipe for target 'arch/arm/mach-exynos/platsmp.o' failed Looks like we need a compiler flags override for that file. Or.. the question is why a .c file is not using the proper macros. Actually I am the one to blame for build failure (commit: ARM: EXYNOS: Move code from hotplug.c to platsmp.c). The problem is v7_exit_coherency_flush() which I think does not make sense on ARMv6. I'll replace the ISB and DSB commands with macros but the real question is whether the mach-exynos/platsmp.c file and mach-exynos directory should be compiled when CONFIG_ARCH_EXYNOS is not defined? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: exynos5260: fix typo in clock name
On 10.09.2014 07:56, Pankaj Dubey wrote:
From: Chander Kashyap k.chan...@samsung.com
The parent name added in parent list as
mout_phyclk_mipi_dphy_4l_m_txbyte_clkhs_p, is different
than the defined parent due to typo.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
drivers/clk/samsung/clk-exynos5260.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
diff --git a/drivers/clk/samsung/clk-exynos5260.c
b/drivers/clk/samsung/clk-exynos5260.c
index 64596ba..4db4e8d 100644
--- a/drivers/clk/samsung/clk-exynos5260.c
+++ b/drivers/clk/samsung/clk-exynos5260.c
@@ -1579,7 +1579,7 @@ struct samsung_fixed_rate_clock fixed_rate_clks[]
__initdata = {
FRATE(PHYCLK_HDMI_LINK_O_TMDS_CLKHI, phyclk_hdmi_link_o_tmds_clkhi,
NULL, CLK_IS_ROOT, 12500),
FRATE(PHYCLK_MIPI_DPHY_4L_M_TXBYTECLKHS,
- phyclk_mipi_dphy_4l_m_txbyteclkhs , NULL,
+ phyclk_mipi_dphy_4l_m_txbyte_clkhs , NULL,
CLK_IS_ROOT, 18750),
FRATE(PHYCLK_DPTX_PHY_O_REF_CLK_24M, phyclk_dptx_phy_o_ref_clk_24m,
NULL, CLK_IS_ROOT, 2400),
--
To unsubscribe from this list: send the line unsubscribe linux-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: exynos3250: fix mout_cam_blk parent list
On 06.09.2014 15:03, Pankaj Dubey wrote:
As per user manual of Exynos3250 SRC_CAM can select
div_cam_blk_320 if it's value is 0xC, so placing
div_cam_blk_320 at proper index in parent list of mout_cam_blk.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c |1 +
1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index e1cb464..ba8f073f 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -248,6 +248,7 @@ PNAME(group_sclk_cam_blk_p) = { xxti, xusbxti,
none, none, none,
none, div_mpll_pre,
mout_epll_user, mout_vpll,
+ none, none, none,
div_cam_blk_320, };
PNAME(group_sclk_fimd0_p) = { xxti, xusbxti,
m_bitclkhsdiv4_2l, none,
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
