Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: Hi Ajay, On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: On 20/09/14 14:22, Ajay kumar wrote: Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. The discussion did digress somewhat. As a clarification, I'm in no way nack'ing this series because it doesn't use the graphs for video connections. I don't see the simple phandle bindings used here as broken as such. Well, I am okay with any approach you guys decide on. I desperately want this to get this in since it has been floating around for quite sometime. The more we drag this, the more rework for me since the number of platforms using bridge support is increasing daily! I won't nack this patch either. I'm however concerned that we'll run straight into the wall if we don't come up with an agreement on a standard way to describe connections in DT for display devices, which is why I would prefer the ps8622 bindings to use OF graph to describe connections. I think there's not really an easy way out here. It's pretty bold trying to come up with a common way to describe bridges when we have only a single one (and a single use-case at that). The worst that can happen is that we need to change the binding at some point, in which case we may have to special-case early drivers, but I really don't think that's as much of an issue as everybody seems to think. This series has been floating around for months because we're being overly prudent to accept a binding that /may/ turn out to not be generic enough. Thierry pgpVFLkLDYrm9.pgp Description: PGP signature
Re: [PATCH v9 2/2] ARM: exynos5: Add Suspend-to-RAM support for 5420
On Tue, Oct 7, 2014 at 6:19 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: Hello Vikas, On Tue, Oct 7, 2014 at 11:22 AM, Vikas Sajjan vikas.saj...@samsung.com wrote: Adds Suspend-to-RAM support for EXYNOS5420 Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- arch/arm/mach-exynos/suspend.c | 151 +++- 1 file changed, 149 insertions(+), 2 deletions(-) Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thank you, Javier. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 1/2] ARM: exynos5: Add PMU support for 5420
Hi Javier, On Tue, Oct 7, 2014 at 6:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: Hellos Vikas, On Tue, Oct 7, 2014 at 11:22 AM, Vikas Sajjan vikas.saj...@samsung.com wrote: From: Abhilash Kesavan a.kesa...@samsung.com Adds intial PMU settings for exynos5420. This is required for future S2R and Switching support. Signed-off-by: Thomas Abraham thomas...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com --- arch/arm/mach-exynos/pmu.c | 287 +++ arch/arm/mach-exynos/regs-pmu.h | 227 +++ 2 files changed, 514 insertions(+) S2R is working on my Exynos5420 Peach Pit Chromebook with your series: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thanks for testing. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Hi Kukjin, On Tue, Oct 7, 2014 at 3:07 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Rebased on 1] Kukjin Kim's tree, for-next branch https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2] Pankaj Dubey's v9 PMU patchset http://www.spinics.net/lists/arm-kernel/msg367939.html changes since v8: - addressed abhilash's comments to remove the restoring of the CPU0 low power state register, since it will taken care in mcpm s2r patch from abhilash. changes since v7: - rebased on pankaj's latest patchset. changes since v6: - rebased on 3.17.rc1. changes since v5: - Refactored pm.c to use DT based lookup as suggested by Tomasz Figa. changes since v4: - Adressed comments from Tomasz figa and rebased on Pankaj Dubey's v5 PMU patchset changes since v3: Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz, Tomasz Figa and Alim Akhtar: - Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h. - Merged exynos5420_set_core_flag function into powerdown_conf. - Removed XXTI_DURATION3 register setting. - Updated the commit message and ordered the clock registers in clock patch. - Removed the code for SYS_DISP1_BLK_CFG handling. - Modified SoC checks to A9 specific checks in PM code. - Updated some comments in the code and added macros for register offsets. - Fixed code which was changing pad retention code for older SoCs. changes since v2: - Addressed comments from Tomasz figa - rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612 - dropped patch ARM: dts: Add node for GPIO keys on SMDK5420, will be sent separately. changes since v1: - Addressed comments from Tomasz figa. - restructured/consolidated as per Tomasz figa's PM consolidations for exynos Tested on Kukjin Kim's tree, for-next branch + 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html 2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK on Exynos5420 based chromebook (peach-pit board) Below procedures were followed to test S2R: Procedure A: 1. make multi_v7_defconfig 2 enable MCPM for 5420 3. enable S3C RTC 5. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Procedure B: 1. make exynos_defconfig 4. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Abhilash Kesavan (1): ARM: exynos5: Add PMU support for 5420 Vikas Sajjan (1): ARM: exynos5: Add Suspend-to-RAM support for 5420 arch/arm/mach-exynos/pmu.c | 287 +++ arch/arm/mach-exynos/regs-pmu.h | 227 +++ arch/arm/mach-exynos/suspend.c | 151 +++- 3 files changed, 663 insertions(+), 2 deletions(-) Can you please pick this series. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Vikas Sajjan wrote: Hi Kukjin, Hi, On Tue, Oct 7, 2014 at 3:07 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Rebased on 1] Kukjin Kim's tree, for-next branch https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2] Pankaj Dubey's v9 PMU patchset http://www.spinics.net/lists/arm-kernel/msg367939.html changes since v8: - addressed abhilash's comments to remove the restoring of the CPU0 low power state register, since it will taken care in mcpm s2r patch from abhilash. changes since v7: - rebased on pankaj's latest patchset. changes since v6: - rebased on 3.17.rc1. changes since v5: - Refactored pm.c to use DT based lookup as suggested by Tomasz Figa. changes since v4: - Adressed comments from Tomasz figa and rebased on Pankaj Dubey's v5 PMU patchset changes since v3: Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz, Tomasz Figa and Alim Akhtar: - Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h. - Merged exynos5420_set_core_flag function into powerdown_conf. - Removed XXTI_DURATION3 register setting. - Updated the commit message and ordered the clock registers in clock patch. - Removed the code for SYS_DISP1_BLK_CFG handling. - Modified SoC checks to A9 specific checks in PM code. - Updated some comments in the code and added macros for register offsets. - Fixed code which was changing pad retention code for older SoCs. changes since v2: - Addressed comments from Tomasz figa - rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612 - dropped patch ARM: dts: Add node for GPIO keys on SMDK5420, will be sent separately. changes since v1: - Addressed comments from Tomasz figa. - restructured/consolidated as per Tomasz figa's PM consolidations for exynos Tested on Kukjin Kim's tree, for-next branch + 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html 2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK on Exynos5420 based chromebook (peach-pit board) Below procedures were followed to test S2R: Procedure A: 1. make multi_v7_defconfig 2 enable MCPM for 5420 3. enable S3C RTC 5. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Procedure B: 1. make exynos_defconfig 4. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Abhilash Kesavan (1): ARM: exynos5: Add PMU support for 5420 Vikas Sajjan (1): ARM: exynos5: Add Suspend-to-RAM support for 5420 arch/arm/mach-exynos/pmu.c | 287 +++ arch/arm/mach-exynos/regs-pmu.h | 227 +++ arch/arm/mach-exynos/suspend.c | 151 +++- 3 files changed, 663 insertions(+), 2 deletions(-) Can you please pick this series. Yes, sure I will queue this series after -rc1 release. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hello Abhilash,
On Wed, Oct 8, 2014 at 7:41 AM, Abhilash Kesavan a.kesa...@samsung.com wrote:
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Acked-by: Nicolas Pitre n...@linaro.org
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
Changes in v7:
- Add the suspend check in exynos_cpu_power_down() rather
than the MCPM back-end.
- Clean-up unnecessary changes related to earlier versions.
Changes in v8:
- Rebased on the latest exynos PMU/PM support patches.
Changes in v9:
- Fixed rebasing issues in v8
- Used pmu_raw_readl instead of __raw_readl
This patch is based on kgene's for-next branch.
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next
Here are the dependencies:
1) Decouple syscon interface from platform devices - v7
http://lkml.org/lkml/2014/9/30/156
2) ARM: Exynos: Convert PMU implementation into a platform driver - v9
https://lkml.org/lkml/2014/10/6/89
3) Exynos5420 PMU/S2R Series - v9
http://www.spinics.net/lists/arm-kernel/msg368207.html
arch/arm/mach-exynos/mcpm-exynos.c | 32 +++
arch/arm/mach-exynos/platsmp.c | 12 +
arch/arm/mach-exynos/suspend.c | 49
3 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index dc9a764..b0d3c2e 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include linux/delay.h
#include linux/io.h
#include linux/of_address.h
+#include linux/syscore_ops.h
#include asm/cputype.h
#include asm/cp15.h
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -318,10 +321,26 @@ static const struct of_device_id exynos_dt_mcpm_match[]
= {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+* U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+* as part of secondary_cpu_start(). Let's redirect it to the
+* mcpm_entry_point(). This is done during both secondary boot-up as
+* well as system resume.
+*/
+ __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0]
*/
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -387,16 +406,9 @@ static int __init exynos_mcpm_init(void)
pmu_raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
- /*
-* U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
-* as part of secondary_cpu_start(). Let's redirect it to the
-* mcpm_entry_point().
-*/
- __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0]
*/
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index adb36a8..7a1ebfe 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -126,6 +126,18 @@ static inline void platform_do_lowpower(unsigned int
cpu, int *spurious)
*/
void exynos_cpu_power_down(int cpu)
{
+ if (cpu == 0 (of_machine_is_compatible(samsung,exynos5420) ||
+ of_machine_is_compatible(samsung,exynos5800))) {
+ /*
+* Bypass power down for CPU0 during suspend. Check for
+
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
On Wed, Oct 8, 2014 at 2:22 PM, Kukjin Kim kg...@kernel.org wrote: Vikas Sajjan wrote: Hi Kukjin, Hi, On Tue, Oct 7, 2014 at 3:07 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Rebased on 1] Kukjin Kim's tree, for-next branch https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2] Pankaj Dubey's v9 PMU patchset http://www.spinics.net/lists/arm-kernel/msg367939.html changes since v8: - addressed abhilash's comments to remove the restoring of the CPU0 low power state register, since it will taken care in mcpm s2r patch from abhilash. changes since v7: - rebased on pankaj's latest patchset. changes since v6: - rebased on 3.17.rc1. changes since v5: - Refactored pm.c to use DT based lookup as suggested by Tomasz Figa. changes since v4: - Adressed comments from Tomasz figa and rebased on Pankaj Dubey's v5 PMU patchset changes since v3: Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz, Tomasz Figa and Alim Akhtar: - Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h. - Merged exynos5420_set_core_flag function into powerdown_conf. - Removed XXTI_DURATION3 register setting. - Updated the commit message and ordered the clock registers in clock patch. - Removed the code for SYS_DISP1_BLK_CFG handling. - Modified SoC checks to A9 specific checks in PM code. - Updated some comments in the code and added macros for register offsets. - Fixed code which was changing pad retention code for older SoCs. changes since v2: - Addressed comments from Tomasz figa - rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612 - dropped patch ARM: dts: Add node for GPIO keys on SMDK5420, will be sent separately. changes since v1: - Addressed comments from Tomasz figa. - restructured/consolidated as per Tomasz figa's PM consolidations for exynos Tested on Kukjin Kim's tree, for-next branch + 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html 2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK on Exynos5420 based chromebook (peach-pit board) Below procedures were followed to test S2R: Procedure A: 1. make multi_v7_defconfig 2 enable MCPM for 5420 3. enable S3C RTC 5. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Procedure B: 1. make exynos_defconfig 4. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Abhilash Kesavan (1): ARM: exynos5: Add PMU support for 5420 Vikas Sajjan (1): ARM: exynos5: Add Suspend-to-RAM support for 5420 arch/arm/mach-exynos/pmu.c | 287 +++ arch/arm/mach-exynos/regs-pmu.h | 227 +++ arch/arm/mach-exynos/suspend.c | 151 +++- 3 files changed, 663 insertions(+), 2 deletions(-) Can you please pick this series. Yes, sure I will queue this series after -rc1 release. Thank you. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board
On 8 October 2014 02:19, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, On 10/07/2014 01:51 AM, Doug Anderson wrote: Bartlomiej, On Thu, Oct 2, 2014 at 10:24 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, On Thursday, October 02, 2014 09:45:41 AM Doug Anderson wrote: Bartiomiej On Thu, Oct 2, 2014 at 9:39 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: On Thursday, October 02, 2014 09:19:08 AM Doug Anderson wrote: Bartiomiej, On Thu, Oct 2, 2014 at 9:10 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc. Currently the device tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is not specified. Fix it. Without this patch: - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators patch causes a SD card detection to fail - mmc: dw_mmc: Support voltage changes patch causes a boot hang This patch fixes both above problems. Suggested-by: Doug Anderson diand...@google.com Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com Cc: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: b/arch/arm/boot/dts/exynos5420-arndale-octa.dts === --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 15:44:53.014826886 +0200 +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 17:35:24.110600398 +0200 @@ -74,7 +74,8 @@ samsung,dw-mshc-ddr-timing = 1 2; pinctrl-names = default; pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4; - vmmc-supply = ldo10_reg; + vmmc-supply = ldo19_reg; + vqmmc-supply = ldo13_reg; This looks right to me. ...but I notice that ldo13 and ldo19 are not always-on in the DTS. Are you sure card detect works for you if you eject your card and try to put it back in? ...eventually the always-on won't be needed, but for now I think it is... Card detection works fine without always-on. That's weird. 1. In the schematics I see XMMC2CDN has an external pullup to PVDD_TFLASH_2V8. 2. The internal pullup should (I think) be to VDDQ_MMC2 which is PVDD_APIO_MMCOFF_2V8. 3. In (51da224 mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators) we should be turning off both regulators in MMC_POWER_OFF. 4. If I understand correctly MMC_POWER_OFF is called when the card is ejected, which means that both regulators should be off when the card is ejected. 5. I don't think card detect can work if neither regulator is powered. One of the above points must be wrong. Any idea which one? Can you check to see if MMC_POWER_OFF is called for you when the card is ejected? Can you check to see if these regulators are off? MMC_POWER_OFF is called on card removal and both regulators get disabled (I have verified that they are really off with regulator_is_enabled() which returns 1 before and 0 after disabling regulator). It seems that 5. is wrong? This really doesn't make a lot of sense to me, so I'm still kinda confused. If you want to call it good then that's your (and Ulf's) decision, but it's the kind of thing that would keep me up at night. How can this pin be high if all the regulators pulling it up are off? Is there a current leak somewhere and that's why it's working? How this is supposed to work (as I understand it): 1. When no card is inserted then this pin is supposed to be pulled up to VDDQ_MMC2. That could be either an internal or an external pullup. It should be pulled up to VDDQ_MMC2 (as opposed to any other voltage) since the exynos manual documents that this pin lives in the VDDQ_MMC2 io domain. Note that it could be pulled up externally to a different supply than the one going to VDDQ_MMC2, but for correctness it should be the same voltage. 2. When a card is inserted, the pin will be grounded (AKA this is an open drain pin). With your patch, can you probe the pin and see if card detect is high when all the regulators are off? Any idea how it gets high? If you turn off the internal pullup is it still high? I remembered that I and Doug were discussed for this problem with exynos5420-peach board(?), right? Is arndale-octa board the same circuit with peach? If it's same, I think Doug's comment is right. But if card-detect pis is used with other power, we don't need to consider the VDDQ_MMC2 power domain. It needs more information and checks its schematic. May I suggest we go ahead and apply this patch to fix the problems for Arndale Octa!? I am soon about to send the PR for 3.18. We should then follow up on this discussion and sort
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Hello Vikas, On Wed, Oct 8, 2014 at 11:26 AM, Vikas Sajjan vikas.saj...@samsung.com wrote: Can you please pick this series. Yes, sure I will queue this series after -rc1 release. Not related to your series but did you figure out why the aclk200_disp1 and aclk300_disp1 clocks are left unused? I'm carrying your patch to flag those clocks as CLK_IGNORE_UNUSED to prevent being disabled by the CCF. And while that allows me to test, I'm afraid that it may not be the proper solution since it could just be hiding the real cause of the issue. Of course this should not block your series from been merged but I just wondered if you found the cause since it would be nice to have s2r properly working on exynos5420. Thank you. Thanks, Kukjin best regards, Javier -- 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/6] Add initial support for pinctrl on Exynos7
On Mon, Oct 6, 2014 at 5:42 AM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: On Tue, Sep 30, 2014 at 8:00 PM, Abhilash Kesavan a.kesa...@samsung.com wrote: Changes since v3: - Changed variable name from exynos_wkup_irq_chip to irq_chip - Added acked-by tag from Tomasz Figa Changes since v2: - Added a .irq_chip field to the samsung_pin_bank struct - Consolidated the wakeup and gpio irqd_ops Changes since v1: - Marked the newly created irq_chip instances as __initdata - Used kmemdup to keep a copy of the irq_chip - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM - Moved the pinctrl enablement for exynos7 into a separate patch - Added tested-by and reviewed-by tags from Thomas Abraham OK... Does this series look OK to you ? I'm waiting for review comments form Tomasz Figa. I have just applied his 5 refactoring patches as the first base for v3.19, I don't know if this stuff will fit nicely on top of these or not, expect to find out during review. Tomasz patches have priority since they have been in-flight for a while and he is listed as maintainer for this driver. So could you make sure to get Tomasz review tag and make sure that these patches work on top of his patches? His patches are on my devel branch in the pin control tree, but will not be pushed to linux-next until the merge window ends. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] pinctrl: samsung: Data structure clean-up
On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This series intends to clean up data structures used by pinctrl-samsung driver. More specifically, it separates initial compile time constants from data used at runtime, allowing unused variant data to be dropped and selected structures constified to improve safety. Thanks! The patches missed the v3.18 merge window, but I have queued them up as the first thing to go into v3.19. Now I need you to help me check the patch set from Abhilash so I know what to do about that, whenever you have some time... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Add initial support for pinctrl on Exynos7
Hi Linus, On Wed, Oct 8, 2014 at 3:52 PM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Oct 6, 2014 at 5:42 AM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: On Tue, Sep 30, 2014 at 8:00 PM, Abhilash Kesavan a.kesa...@samsung.com wrote: Changes since v3: - Changed variable name from exynos_wkup_irq_chip to irq_chip - Added acked-by tag from Tomasz Figa Changes since v2: - Added a .irq_chip field to the samsung_pin_bank struct - Consolidated the wakeup and gpio irqd_ops Changes since v1: - Marked the newly created irq_chip instances as __initdata - Used kmemdup to keep a copy of the irq_chip - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM - Moved the pinctrl enablement for exynos7 into a separate patch - Added tested-by and reviewed-by tags from Thomas Abraham OK... Does this series look OK to you ? I'm waiting for review comments form Tomasz Figa. Tomasz had ack'ed my v3 patchset (http://www.spinics.net/lists/linux-samsung-soc/msg37387.html). This version fixed the minor issues raised by Tomasz in v3 as well. I have just applied his 5 refactoring patches as the first base for v3.19, I don't know if this stuff will fit nicely on top of these or not, expect to find out during review. Tomasz patches have priority since they have been in-flight for a while and he is listed as maintainer for this driver. So could you make sure to get Tomasz review tag and make sure that these patches work on top of his patches? His patches are on my devel branch in the pin control tree, but will not be pushed to linux-next until the merge window ends. I will re-base this series on your devel branch and post a new version after testing. Regards, Abhilash -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Hi Javier, On Wed, Oct 8, 2014 at 3:42 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: Hello Vikas, On Wed, Oct 8, 2014 at 11:26 AM, Vikas Sajjan vikas.saj...@samsung.com wrote: Can you please pick this series. Yes, sure I will queue this series after -rc1 release. Not related to your series but did you figure out why the aclk200_disp1 and aclk300_disp1 clocks are left unused? As mentioned earlier, I recently noticed that these clocks are preventing system from suspending. These clocks are used by the in-flight DRM display driver and once it is merged the display driver will be handling the clock during boot-up and suspend/resume. In our internal tree (3.17-rc5 based) where we have DRM display driver enabled, we do not see any issues and do not need to add the CLK_IGNORE_UNUSED flag. I'm carrying your patch to flag those clocks as CLK_IGNORE_UNUSED to prevent being disabled by the CCF. And while that allows me to test, I'm afraid that it may not be the proper solution since it could just be hiding the real cause of the issue. Till the DRM display driver gets merged, we can continue to use this for testing purposes. Of course this should not block your series from been merged but I just wondered if you found the cause since it would be nice to have s2r properly working on exynos5420. Thank you. Thanks, Kukjin best regards, Javier ___ 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: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Hello Vikas, On Wed, Oct 8, 2014 at 1:51 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Not related to your series but did you figure out why the aclk200_disp1 and aclk300_disp1 clocks are left unused? As mentioned earlier, I recently noticed that these clocks are preventing system from suspending. These clocks are used by the in-flight DRM display driver and once it is merged the display driver will be handling the clock during boot-up and suspend/resume. Perfect, that was exactly what I was wondering. Thanks a lot for the information! Best regards, Javier -- 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: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)
On 7 October 2014 21:09, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Hi Ulf,
On Tue, Sep 30, 2014 at 2:43 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
Instead, let's improve the situation, by preventing genpd from powering
off any of the PM domains until late_init. At that point genpd already
tries to power off unused PM domains, so it seems like a decent match.
Note that powering off unused PM domains is currently limited to
CONFIG_PM_RUNTIME=y.
If CONFIG_PM_RUNTIME is disabled, unused PM domains are not powered down,
and may even stay powered-up during system suspend.
Right. That's obviously not an acceptable behaviour, we can do better.
With CONFIG_PM_RUNTIME=y, we have:
A1. All PM domains are powered up during initialization.
A2. After initialization, all unused PM domains are powered down by the
genpd_poweroff_unused() late_initcall.
unused means PM domains containing no active devices and no active
subdomains. I.e. PM domains containing (a) only suspended devices, or
(b) no[*] devices at all will be powered down.
A3. PM domains will be powered up or down, depending on devices moving from
inactive to active state, or vice versa. This includes system suspend,
which can be considered some form of devices moving to an inactive
state.
In contrast, with CONFIG_PM_RUNTIME=n, we have:
B1. All PM domains are powered up during initialization,
B2. After initialization, PM domains just stay powered up,
B3. PM domains will be powered down on system suspend, and powered up on
system resume, based on the dev_pm_ops of the PM domain each device
belongs to.
While operation A2 is PM domain-centric (it walks the list of genpd domains),
A3 and B3 are device-centric (A3 operates on one specific device, B3 walks the
list of devices).
Hence B3 never touches PM domains that don't contain any devices[*].
So these PM domains are kept powered-up if CONFIG_PM_RUNTIME=n, even on
system suspend.
Shouldn't PM domains without devices be powered down at some point?
When? In B2, or in B3?
I agree with Rafael and Sylwester, that it would be an advantage if PM
domains can be initialized in powered off state. Simply because, those
may then be left in powered off state all the time, if they are
unused.
That's been my long term approach, but let's see if we can get there
without the intermediate step proposed in this patchset...
Now, to support the above and to solve the race conditions, we need to
be able to power up the PM domain, prior probing of a device. I am
thinking of a solution aimed to affect subsystem level code (buses)
and not drivers, since we need keep the impact on a reasonable level.
Let's see what I will come up with. I have some ideas that I am trying out...
Thanks for your suggestions!
[*] It may sound strange to have a PM domain without devices. However, this
may
happen due to incomplete device trees, or for devices without existing
bindings or without Linux support.
I understand.
I guess another valid argument is the kernel configuration. The
corresponding driver which normally would handle the device may
intentionally not even been build into the kernel. Certainly we must
not leave those unused PM domains in powered up state.
Gr{oetje,eeting}s,
Geert
P.S. Will any of you be at ELC-E next week, for further PM domain discussions?
That would have been great, but I won't be there. Unless I schedule a
last minute trip. :-)
Kind regards
Uffe
--
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: fix MMC2 regulators for Exynos5420 Arndale Octa board
On Thursday 02 October 2014 20:16:44 Ulf Hansson wrote: On 2 October 2014 18:10, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc. Currently the device tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is not specified. Fix it. Without this patch: - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators patch causes a SD card detection to fail - mmc: dw_mmc: Support voltage changes patch causes a boot hang This patch fixes both above problems. Suggested-by: Doug Anderson diand...@google.com Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com Cc: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Unless it causes a bunch non-trivial conflicts, I suggest we take this through my mmc tree to not break bisectability. Have you tried if it conflicts with arm-soc? If not, Acked-by: Arnd Bergmann a...@arndb.de -- 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: fix MMC2 regulators for Exynos5420 Arndale Octa board
On 8 October 2014 14:07, Arnd Bergmann a...@arndb.de wrote: On Thursday 02 October 2014 20:16:44 Ulf Hansson wrote: On 2 October 2014 18:10, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc. Currently the device tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is not specified. Fix it. Without this patch: - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators patch causes a SD card detection to fail - mmc: dw_mmc: Support voltage changes patch causes a boot hang This patch fixes both above problems. Suggested-by: Doug Anderson diand...@google.com Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com Cc: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Unless it causes a bunch non-trivial conflicts, I suggest we take this through my mmc tree to not break bisectability. Have you tried if it conflicts with arm-soc? If not, Acked-by: Arnd Bergmann a...@arndb.de In conflicts, but it's trivial to fix it. Since it actually fixes a regression which is inserted from my mmc tree, I thought it makes sense to take it through here. Anyway, the decision is yours. Br Uffe -- 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: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)
On Wednesday, October 08, 2014 02:00:50 PM Ulf Hansson wrote: On 7 October 2014 21:09, Geert Uytterhoeven ge...@linux-m68k.org wrote: Hi Ulf, On Tue, Sep 30, 2014 at 2:43 PM, Ulf Hansson ulf.hans...@linaro.org wrote: Instead, let's improve the situation, by preventing genpd from powering off any of the PM domains until late_init. At that point genpd already tries to power off unused PM domains, so it seems like a decent match. Note that powering off unused PM domains is currently limited to CONFIG_PM_RUNTIME=y. If CONFIG_PM_RUNTIME is disabled, unused PM domains are not powered down, and may even stay powered-up during system suspend. Right. That's obviously not an acceptable behaviour, we can do better. With CONFIG_PM_RUNTIME=y, we have: A1. All PM domains are powered up during initialization. A2. After initialization, all unused PM domains are powered down by the genpd_poweroff_unused() late_initcall. unused means PM domains containing no active devices and no active subdomains. I.e. PM domains containing (a) only suspended devices, or (b) no[*] devices at all will be powered down. A3. PM domains will be powered up or down, depending on devices moving from inactive to active state, or vice versa. This includes system suspend, which can be considered some form of devices moving to an inactive state. In contrast, with CONFIG_PM_RUNTIME=n, we have: B1. All PM domains are powered up during initialization, B2. After initialization, PM domains just stay powered up, B3. PM domains will be powered down on system suspend, and powered up on system resume, based on the dev_pm_ops of the PM domain each device belongs to. While operation A2 is PM domain-centric (it walks the list of genpd domains), A3 and B3 are device-centric (A3 operates on one specific device, B3 walks the list of devices). Hence B3 never touches PM domains that don't contain any devices[*]. So these PM domains are kept powered-up if CONFIG_PM_RUNTIME=n, even on system suspend. Shouldn't PM domains without devices be powered down at some point? When? In B2, or in B3? I agree with Rafael and Sylwester, that it would be an advantage if PM domains can be initialized in powered off state. Simply because, those may then be left in powered off state all the time, if they are unused. That's been my long term approach, but let's see if we can get there without the intermediate step proposed in this patchset... Now, to support the above and to solve the race conditions, we need to be able to power up the PM domain, prior probing of a device. I am thinking of a solution aimed to affect subsystem level code (buses) and not drivers, since we need keep the impact on a reasonable level. That sounds like a good approach to me. Also that should work regardless of whether or not the drivers in question implement runtime PM callbacks. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support
Regulators can run on different operating modes (opmodes). This allows systems to choose the most efficient opmode for each regulator. The regulator core defines a set of generic modes so each system can define the opmode in these generic terms and drivers are responsible to map the generic modes to the ones supported by each hardware according to their data-sheet. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Documentation/devicetree/bindings/regulator/regulator.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index ccba90b..a9d6767 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -23,6 +23,14 @@ Optional properties: state among following defined suspend states: 3: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem 4: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk +- regulator-initial-mode: initial regulator operating mode. One of following: + 1: REGULATOR_MODE_FAST- Regulator can handle fast changes. + 2: REGULATOR_MODE_NORMAL - Normal regulator power supply mode. + 4: REGULATOR_MODE_IDLE- Regulator runs in a more efficient mode. + 8: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode. + modes are defined in the dt-bindings/regulator/regulator.h header and can be + used in device tree sources files. If no mode is defined, then the OS will not + manage the operating mode and the HW default values will be used instead. - regulator-state-mem sub-root node for Suspend-to-RAM mode : suspend to memory, the device goes to sleep, but all data stored in memory, only some external interrupt can wake the device. -- 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
[PATCH 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards
The regulator core now has support to choose a default initial
operating mode for regulators from DT. Set the initial opmode
for the max77802 PMIC regulators with the same modes that are
used in the downstream ChromeOS kernel, in order to allow the
system to lower power at suspend time.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 26 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 26 ++
2 files changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..f7eb70d 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
#include dt-bindings/gpio/gpio.h
#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/clock/maxim,max77802.h
+#include dt-bindings/regulator/regulator.h
#include exynos5420.dtsi
/ {
@@ -192,6 +193,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck2_reg: BUCK2 {
@@ -201,6 +203,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck3_reg: BUCK3 {
@@ -210,6 +213,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck4_reg: BUCK4 {
@@ -219,6 +223,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck5_reg: BUCK5 {
@@ -227,6 +232,7 @@
regulator-max-microvolt = 120;
regulator-always-on;
regulator-boot-on;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck6_reg: BUCK6 {
@@ -236,6 +242,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck7_reg: BUCK7 {
@@ -244,6 +251,7 @@
regulator-max-microvolt = 135;
regulator-always-on;
regulator-boot-on;
+ regulator-initial-mode =
REGULATOR_MODE_NORMAL;
};
buck8_reg: BUCK8 {
@@ -252,6 +260,7 @@
regulator-max-microvolt = 285;
regulator-always-on;
regulator-boot-on;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
buck9_reg: BUCK9 {
@@ -260,6 +269,7 @@
regulator-max-microvolt = 200;
regulator-always-on;
regulator-boot-on;
+ regulator-initial-mode =
REGULATOR_MODE_NORMAL;
};
buck10_reg: BUCK10 {
@@ -268,6 +278,7 @@
regulator-max-microvolt = 180;
regulator-always-on;
regulator-boot-on;
+ regulator-initial-mode =
REGULATOR_MODE_NORMAL;
};
ldo1_reg: LDO1 {
@@ -275,6 +286,7 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
+ regulator-initial-mode = REGULATOR_MODE_IDLE;
};
ldo2_reg: LDO2 {
@@ -288,6 +300,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
+
[PATCH 4/5] regulator: max77802: Add regulator operating mode set support
Add a function handler for the struct regulator_ops .set_mode so an
operating mode (opmode) can be set for regulators.
Regulators opmode are defined using the generic REGULATOR_MODE_*
modes so the driver maps these generic modes to the device-specific
operating modes as stated in the hardware data-sheet.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/max77802.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index d89792b..04ed5cf 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -83,6 +83,34 @@ static int max77802_get_opmode_shift(int id)
return -EINVAL;
}
+static int max77802_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
+ unsigned int val;
+ int id = rdev_get_id(rdev);
+ int shift = max77802_get_opmode_shift(id);
+
+ switch (mode) {
+ case REGULATOR_MODE_NORMAL:
+ val = MAX77802_OPMODE_NORMAL;
+ break;
+ case REGULATOR_MODE_IDLE:
+ val = MAX77802_OPMODE_LP;
+ break;
+ case REGULATOR_MODE_STANDBY:
+ val = MAX77802_OPMODE_STANDBY;
+ break;
+ default:
+ dev_warn(rdev-dev, %s: regulator mode: 0x%x not supported\n,
+rdev-desc-name, mode);
+ return -EINVAL;
+ }
+
+ max77802-opmode[id] = val;
+ return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+ rdev-desc-enable_mask, val shift);
+}
+
/*
* Some BUCKS supports Normal[ON/OFF] mode during suspend
*
@@ -247,6 +275,7 @@ static struct regulator_ops max77802_ldo_ops_logic1 = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_mode = max77802_set_mode,
.set_suspend_mode = max77802_ldo_set_suspend_mode_logic1,
};
@@ -262,6 +291,7 @@ static struct regulator_ops max77802_ldo_ops_logic2 = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_mode = max77802_set_mode,
.set_suspend_mode = max77802_ldo_set_suspend_mode_logic2,
};
@@ -274,6 +304,7 @@ static struct regulator_ops max77802_buck_16_dvs_ops = {
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_mode = max77802_set_mode,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_4bit,
.set_suspend_disable= max77802_buck_set_suspend_disable,
@@ -288,6 +319,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_mode = max77802_set_mode,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_2bit,
.set_suspend_disable= max77802_buck_set_suspend_disable,
--
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
[PATCH 2/5] regulator: dt-bindings: Add DT include for constants
Device Tree source files can set a regulator operating mode to be used as an initial default. Instead of using magic numbers, a header file can be included that provides macro definitions for the opmodes. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- include/dt-bindings/regulator/regulator.h | 16 1 file changed, 16 insertions(+) create mode 100644 include/dt-bindings/regulator/regulator.h diff --git a/include/dt-bindings/regulator/regulator.h b/include/dt-bindings/regulator/regulator.h new file mode 100644 index 000..5051093 --- /dev/null +++ b/include/dt-bindings/regulator/regulator.h @@ -0,0 +1,16 @@ +/* + * This header provides constants for regulator bindings. + */ + +#ifndef _DT_BINDINGS_REGULATOR_REGULATOR_H +#define _DT_BINDINGS_REGULATOR_REGULATOR_H + +/* + * Regulator operating modes. + */ +#define REGULATOR_MODE_FAST0x1 +#define REGULATOR_MODE_NORMAL 0x2 +#define REGULATOR_MODE_IDLE0x4 +#define REGULATOR_MODE_STANDBY 0x8 + +#endif -- 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
[PATCH 1/5] regulator: of: Add regulator-initial-mode parse support
The regulator core allows boards to define an initial operating mode to
be used as a default for regulators. With board files and platform data,
it is possible to fill a struct regulation_constraints .initial_mode to
set an initial mode for each regulator.
But currently there isn't a way to do the same with DeviceTrees. Argubly
the operating modes are Linux-specific so that information should not be
in the DT which should be used to only describe hardware. But regulators
having different operating modes is also a hardware property since many
PMICs have support to set different modes for their regulators.
So, the generic REGULATOR_MODE_{FAST,NORMAL,IDLE,STANDBY} modes can be
used to describe different level of power efficiency required for each
regulator and drivers can map those levels to the real modes supported
by the hardware as stated on their data-sheet.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/of_regulator.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 18236be..a076b7f 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -93,6 +93,9 @@ static void of_get_regulation_constraints(struct device_node
*np,
};
}
+ if (!of_property_read_u32(np, regulator-initial-mode, pval))
+ constraints-initial_mode = pval;
+
for (i = 0; i ARRAY_SIZE(regulator_states); i++) {
switch (i) {
case PM_SUSPEND_MEM:
--
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
[PATCH 0/5] regulator: Add support for initial operating modes
Hello Mark, This series add support to setup an initial operating mode for regulators. There were previous attempts to solve the same issue by adding DT bindings that were driver-specific like Abhilash Kesavan's Add MAX77686 Operating mode support [0] or Krzysztof Kozlowski's regulator: s2mps11: Add opmode for S2MPS14 regulators [1] series. But there are many IC with regulators that can be configured with different operating modes so this is a problem that has to be solved generically and in fact the regulator core already has a .initial_mode field in the struct regulation_constraints that is used to call the regulator driver .set_mode function handler with an initial mode, when regulator constraints are set. So with the old days of platform data, board files could fill this but with Device Trees is not possible. The same issue happens with suspend states since there isn't currently a way to fill this information on DT booting. That's why there were also different attempts to solve the suspend states issue like [2] and [3]. Chanwoo's series [4] seems to be close to finally fix the suspend states issue by filling this data from DT but it does not support the initial regulator operating mode so this series do that on top of Chanwoo's work. Possible use cases for default operating mode support in DT are: a) Boards wants to set different operating modes for regulators in order to lower power at suspend time. For example some SoCs have a dedicated pin that is pulled high during normal operation and is pulled down when the system enters in sleep mode. A PMIC may support automatically disabling a regulator, put it in low power mode or changing the voltage when is signalled by the SoC that has entered in sleep mode. Each regulator could have different constraints so being able to choose the mode is useful. b) Regulator drivers that read the operating mode from a HW register may be reading OFF if the regulator was disabled and the PMIC is not reset on warm reboot. In this case the .enable function may set OFF as the default mode thus the regulator failing to be enabled. This can be worked around by setting the mode to NORMAL if OFF is read from a hardware register but is more robust to explicitly configure that from the DT. These patches do not really depend on Chanwoo's series but are based on top since both series are complementary to solve the same general issue and to avoid merge conflicts. But I can resend to just base on top of the regulator for-next branch if that is easier for you. The series is composed of the following patches: Javier Martinez Canillas (5): regulator: of: Add regulator-initial-mode parse support regulator: dt-bindings: Add DT include for constants regulator: dt-bindings: Add regulator-initial-mode support regulator: max77802: Add regulator operating mode set support ARM: dts: Add initial regulator mode on exynos Peach boards .../devicetree/bindings/regulator/regulator.txt| 8 ++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 26 ++ arch/arm/boot/dts/exynos5800-peach-pi.dts | 26 ++ drivers/regulator/max77802.c | 32 ++ drivers/regulator/of_regulator.c | 3 ++ include/dt-bindings/regulator/regulator.h | 16 +++ 6 files changed, 111 insertions(+) create mode 100644 include/dt-bindings/regulator/regulator.h Patch #1 adds support to set the .initial_mode from DT, patch #2 adds a include header to avoid DTS using magic numbers for the regulator modes, patch #3 describes the new regulator-initial-mode property in the DT binding doc, patch #4 adds supports to the max77802 for setting modes and finally patch #5 adds the initial regulator modes for the regulators in the max77802 PMIC of the Exynos Peach Chromebooks. Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2012/12/10/18 [1]: https://lkml.org/lkml/2014/2/13/82 [2]: https://lkml.org/lkml/2012/12/10/434 [3]: https://lkml.org/lkml/2013/7/25/592 [4]: https://lkml.org/lkml/2014/7/9/16 -- 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/5] regulator: of: Add regulator-initial-mode parse support
On Wed, Oct 08, 2014 at 03:44:03PM +0200, Javier Martinez Canillas wrote: But currently there isn't a way to do the same with DeviceTrees. Argubly the operating modes are Linux-specific so that information should not be in the DT which should be used to only describe hardware. But regulators having different operating modes is also a hardware property since many PMICs have support to set different modes for their regulators. That doesn't mean that the definition of those modes is something we can sensibly provide in generic code, especially in a completely undocumented fashion (perhaps you've done that later in the patch series but bisection also applies to reviewability). signature.asc Description: Digital signature
Re: [PATCH 4/5] regulator: max77802: Add regulator operating mode set support
On Wed, Oct 08, 2014 at 03:44:06PM +0200, Javier Martinez Canillas wrote: Add a function handler for the struct regulator_ops .set_mode so an operating mode (opmode) can be set for regulators. Regulators opmode are defined using the generic REGULATOR_MODE_* modes so the driver maps these generic modes to the device-specific operating modes as stated in the hardware data-sheet. Why is this implementing a set operation but not a get operation? signature.asc Description: Digital signature
Re: [PATCH 1/5] regulator: of: Add regulator-initial-mode parse support
Hello Mark, Thanks for the feedback. On 10/08/2014 04:25 PM, Mark Brown wrote: On Wed, Oct 08, 2014 at 03:44:03PM +0200, Javier Martinez Canillas wrote: But currently there isn't a way to do the same with DeviceTrees. Argubly the operating modes are Linux-specific so that information should not be in the DT which should be used to only describe hardware. But regulators having different operating modes is also a hardware property since many PMICs have support to set different modes for their regulators. That doesn't mean that the definition of those modes is something we can sensibly provide in generic code, especially in a completely undocumented fashion (perhaps you've done that later in the patch series but bisection also applies to reviewability). Yes, patch #3 updates the regulator DT binding doc and documents what each regulator mode is supposed to be. Basically is just a short description of what is already documented in linux/regulator/consumer.h [0]. If what is enough for you I can reorganize the patch-set so that patch is the first one. As a general question, now that the convention is for DT binding docs to go in a separate patch, should the DT documentation be added before or after that code using these bindings is added? That is something that is not explained in Documentation/devicetree/bindings/submitting-patches.txt. Best regards, Javier [0]: http://lxr.free-electrons.com/source/include/linux/regulator/consumer.h#L40 -- 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 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards
On Wed, Oct 08, 2014 at 03:44:07PM +0200, Javier Martinez Canillas wrote:
The regulator core now has support to choose a default initial
operating mode for regulators from DT. Set the initial opmode
for the max77802 PMIC regulators with the same modes that are
used in the downstream ChromeOS kernel, in order to allow the
system to lower power at suspend time.
The stated goal of this change doesn't appear to correspond to what it
actually does. It's saying that we want to be able to set the regulator
into low power modes on suspend which is a sensible and useful thing to
want to do (especially for regulators which don't have physical suspend
modes which we currently make any effort to handle) but what the change
actually does is cause us to set the default state of supplies on boot.
The device tree should describe what it's trying to achieve, otherwise
even if things happen to work right now it's going to be vulnerable to
being broken by future kernel changes which take what it's saying at
face value.
buck2_reg: BUCK2 {
@@ -201,6 +203,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+ regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
This appears to set the supply which is labelled as VDD_ARM into standby
mode by default (from a first glance the change appears to set all
supplies into standby mode) and of course we currently have no way of
changing the mode at runtime in DT systems. Are you *really* sure this
is a good idea of which an electrical engineer would approve, CPU cores
are typically one of the most demanding workloads available for a
regulator?
signature.asc
Description: Digital signature
Re: [PATCH 1/5] regulator: of: Add regulator-initial-mode parse support
On Wed, Oct 08, 2014 at 04:38:53PM +0200, Javier Martinez Canillas wrote: On 10/08/2014 04:25 PM, Mark Brown wrote: That doesn't mean that the definition of those modes is something we can sensibly provide in generic code, especially in a completely undocumented fashion (perhaps you've done that later in the patch series but bisection also applies to reviewability). As a general question, now that the convention is for DT binding docs to go in a separate patch, should the DT documentation be added before or after that code using these bindings is added? It fairly obviously needs to go before so that reviewers can tell if the code is actually implementing the binding. signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board
On Wednesday 08 October 2014 14:50:46 Ulf Hansson wrote: On 8 October 2014 14:07, Arnd Bergmann a...@arndb.de wrote: On Thursday 02 October 2014 20:16:44 Ulf Hansson wrote: On 2 October 2014 18:10, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc. Currently the device tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is not specified. Fix it. Without this patch: - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators patch causes a SD card detection to fail - mmc: dw_mmc: Support voltage changes patch causes a boot hang This patch fixes both above problems. Suggested-by: Doug Anderson diand...@google.com Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com Cc: Ulf Hansson ulf.hans...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Unless it causes a bunch non-trivial conflicts, I suggest we take this through my mmc tree to not break bisectability. Have you tried if it conflicts with arm-soc? If not, Acked-by: Arnd Bergmann a...@arndb.de In conflicts, but it's trivial to fix it. Since it actually fixes a regression which is inserted from my mmc tree, I thought it makes sense to take it through here. Anyway, the decision is yours. Why does it cause a regression though? Does this mean you are breaking any boot with an old DT file and a new kernel? That would be very bad, the driver is supposed to keep working with an existing dtb. Arnd -- 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: fix MMC2 regulators for Exynos5420 Arndale Octa board
Hi, On Wed, Oct 8, 2014 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote: Why does it cause a regression though? Does this mean you are breaking any boot with an old DT file and a new kernel? That would be very bad, the driver is supposed to keep working with an existing dtb. The old dts file specified completely the wrong regulator. It happened that the old code didn't really care, but when the code was fixed to care then things broke. If we need to keep old dts files working then the most sensible place to do it would be in a fixup old broken device trees stage somewhere in kernel boot. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] regulator: max77802: Add regulator operating mode set support
On 10/08/2014 04:36 PM, Mark Brown wrote: On Wed, Oct 08, 2014 at 03:44:06PM +0200, Javier Martinez Canillas wrote: Add a function handler for the struct regulator_ops .set_mode so an operating mode (opmode) can be set for regulators. Regulators opmode are defined using the generic REGULATOR_MODE_* modes so the driver maps these generic modes to the device-specific operating modes as stated in the hardware data-sheet. Why is this implementing a set operation but not a get operation? Right, I'll add it on the next version. Thanks for pointing out this. Best regards, Javier -- 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 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards
On 10/08/2014 04:56 PM, Mark Brown wrote:
On Wed, Oct 08, 2014 at 03:44:07PM +0200, Javier Martinez Canillas wrote:
The regulator core now has support to choose a default initial
operating mode for regulators from DT. Set the initial opmode
for the max77802 PMIC regulators with the same modes that are
used in the downstream ChromeOS kernel, in order to allow the
system to lower power at suspend time.
The stated goal of this change doesn't appear to correspond to what it
actually does. It's saying that we want to be able to set the regulator
into low power modes on suspend which is a sensible and useful thing to
want to do (especially for regulators which don't have physical suspend
modes which we currently make any effort to handle) but what the change
actually does is cause us to set the default state of supplies on boot.
Well, setting a regulator into low power mode on suspend is something
that Chanwoo's series tried to address. At least on v3 since he removed
regulator-mode property for the regulator-state-{standby,mem,disk} on v4.
What this series tried to solve is when you have to set a opmode on boot
to change how the physical suspend is managed by the PMIC.
In the Maxim77802 PMIC is even trickier since not all the modes have the
semantics. That is the value 0x1 could have different meanings depending
of the regulator.
The device tree should describe what it's trying to achieve, otherwise
even if things happen to work right now it's going to be vulnerable to
being broken by future kernel changes which take what it's saying at
face value.
buck2_reg: BUCK2 {
@@ -201,6 +203,7 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
+regulator-initial-mode =
REGULATOR_MODE_STANDBY;
};
This appears to set the supply which is labelled as VDD_ARM into standby
mode by default (from a first glance the change appears to set all
supplies into standby mode) and of course we currently have no way of
changing the mode at runtime in DT systems. Are you *really* sure this
is a good idea of which an electrical engineer would approve, CPU cores
are typically one of the most demanding workloads available for a
regulator?
Well, the standby mode for this regulator is actually:
Output ON/OFF Controlled by PWRREQ
PWRREQ=HIGH (1): Output ON in Normal Mode
PWRREQ=LOW (0): Output OFF
this means that when the Soc enters into suspend mode a pin is toggled
and that pin is connected to the PWRREQ line in the PMIC to signal that
the SoC has entered in sleep mode so the regulator has to be OFF.
When the SoC leaves sleep mode and is resumed again, the pin is toggled
so the PMIC puts the regulator in ON again.
There is other mode that instead of turning off the regulator, keeps it
enabled but in low power mode.
Best regards,
Javier
--
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/5] regulator: of: Add regulator-initial-mode parse support
On 10/08/2014 05:12 PM, Mark Brown wrote: On Wed, Oct 08, 2014 at 04:38:53PM +0200, Javier Martinez Canillas wrote: On 10/08/2014 04:25 PM, Mark Brown wrote: That doesn't mean that the definition of those modes is something we can sensibly provide in generic code, especially in a completely undocumented fashion (perhaps you've done that later in the patch series but bisection also applies to reviewability). As a general question, now that the convention is for DT binding docs to go in a separate patch, should the DT documentation be added before or after that code using these bindings is added? It fairly obviously needs to go before so that reviewers can tell if the code is actually implementing the binding. Well, is not fairly obvious to me. One can also say the opposite, why the kernel is documenting a DT binding that is not (currently) implemented? That's why what makes the most sense for me is what the old convention did, add the DT binding docs in the same patch that implements the binding. Anyways, thanks for letting me know what is the convention today. -- 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: fix MMC2 regulators for Exynos5420 Arndale Octa board
On Wednesday 08 October 2014 08:29:16 Doug Anderson wrote: On Wed, Oct 8, 2014 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote: Why does it cause a regression though? Does this mean you are breaking any boot with an old DT file and a new kernel? That would be very bad, the driver is supposed to keep working with an existing dtb. The old dts file specified completely the wrong regulator. It happened that the old code didn't really care, but when the code was fixed to care then things broke. If we need to keep old dts files working then the most sensible place to do it would be in a fixup old broken device trees stage somewhere in kernel boot. Ok, got it. I guess it's better to apply this one first then. Arnd -- 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] input: cros_ec_keyb: Add of match table
On Fri, Sep 19, 2014 at 10:08:13AM +0200, Sjoerd Simons wrote:
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Applied, thank you.
---
Changes in v2: Fixed some indentation issues
drivers/input/keyboard/cros_ec_keyb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..e1903ec 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,19 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
+ { .compatible = google,cros-ec-keyb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = cros-ec-keyb,
+ .of_match_table = of_match_ptr(cros_ec_keyb_of_match),
.pm = cros_ec_keyb_pm_ops,
},
};
--
2.1.0
--
Dmitry
--
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
exynos5422-odroid-xu3: MCPM: only 6 of 8 CPUs coming online
Hi Chander, Abhilash, I'm using the exynos5422 odroid-xu3 and only 6 of 8 cores are coming online when using MCPM[1]. All the A15s are booting but only 2 of the A7s, one of which is the primary CPU. After booting, if I try to manually bring one of the CPUs online via /sys/devices/.../cpuX/online, I hit the BUG() in mcpm-exynos.c:exynos_power_up(). Any ideas why 2 of the A7s aren't booting up? Kevin [1] [0.001719] CPU: Testing write buffer coherency: ok [0.002171] CPU0: update cpu_capacity 448 [0.002187] CPU0: thread -1, cpu 0, socket 1, mpidr 8100 [0.002429] Setting up static identity map for 0x4046df70 - 0x4046dfc8 [0.002732] ARM CCI driver probed [0.002815] exynos_mcpm_usage_count_init: cpu 0 cluster 1 [0.003010] Exynos MCPM support installed [0.030310] mcpm_boot_secondary: logical CPU 1 is physical CPU 0 cluster 0 [0.030326] exynos_power_up: cpu 0 cluster 0 [0.030626] CPU1: Booted secondary processor [0.030686] CPU1: update cpu_capacity 1535 [0.030693] CPU1: thread -1, cpu 0, socket 0, mpidr 8000 [0.040314] mcpm_boot_secondary: logical CPU 2 is physical CPU 1 cluster 0 [0.040340] exynos_power_up: cpu 1 cluster 0 [0.040629] CPU2: Booted secondary processor [0.040672] CPU2: update cpu_capacity 1535 [0.040679] CPU2: thread -1, cpu 1, socket 0, mpidr 8001 [0.050321] mcpm_boot_secondary: logical CPU 3 is physical CPU 2 cluster 0 [0.050347] exynos_power_up: cpu 2 cluster 0 [0.050659] CPU3: Booted secondary processor [0.050703] CPU3: update cpu_capacity 1535 [0.050710] CPU3: thread -1, cpu 2, socket 0, mpidr 8002 [0.060316] mcpm_boot_secondary: logical CPU 4 is physical CPU 3 cluster 0 [0.060343] exynos_power_up: cpu 3 cluster 0 [0.060631] CPU4: Booted secondary processor [0.060675] CPU4: update cpu_capacity 1535 [0.060682] CPU4: thread -1, cpu 3, socket 0, mpidr 8003 [0.070316] mcpm_boot_secondary: logical CPU 5 is physical CPU 1 cluster 1 [0.070343] exynos_power_up: cpu 1 cluster 1 [1.070007] CPU5: failed to come online [1.080322] mcpm_boot_secondary: logical CPU 6 is physical CPU 2 cluster 1 [1.080337] exynos_power_up: cpu 2 cluster 1 [1.080625] CPU6: Booted secondary processor [1.080691] CPU6: update cpu_capacity 448 [1.080699] CPU6: thread -1, cpu 2, socket 1, mpidr 8102 [1.090331] mcpm_boot_secondary: logical CPU 7 is physical CPU 3 cluster 1 [1.090356] exynos_power_up: cpu 3 cluster 1 [2.090023] CPU7: failed to come online [2.090055] Brought up 6 CPUs [2.090067] SMP: Total of 6 processors activated. [2.090079] CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x13) [2.090089] CPU: This may indicate a broken bootloader or firmware. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Vikas Sajjan vikas.saj...@samsung.com writes: [...] Tested on Kukjin Kim's tree, for-next branch + 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html 2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK on Exynos5420 based chromebook (peach-pit board) Below procedures were followed to test S2R: Procedure A: 1. make multi_v7_defconfig 2 enable MCPM for 5420 3. enable S3C RTC 5. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Procedure B: 1. make exynos_defconfig 4. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state I went tried to this on exynos5800-peach-pi and found first that exynos_defonfig is missing the MAX77802 kconfig options for the RTC source clock: CONFIG_REGULATOR_MAX77802=y CONFIG_COMMON_CLK_MAX77802=y With those, rtc0 then comes up, but isn't waking from suspend. However, writing something to rtc0/wakealarm does result in /proc/interrupts having an interrupt for the RTC, it's just not waking the system. Anyone else tried this on 5800/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: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Hi Kevin, On Thu, Oct 9, 2014 at 4:49 AM, Kevin Hilman khil...@kernel.org wrote: Vikas Sajjan vikas.saj...@samsung.com writes: [...] Tested on Kukjin Kim's tree, for-next branch + 1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html 2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html 3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK on Exynos5420 based chromebook (peach-pit board) Below procedures were followed to test S2R: Procedure A: 1. make multi_v7_defconfig 2 enable MCPM for 5420 3. enable S3C RTC 5. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state Procedure B: 1. make exynos_defconfig 4. echo +20 /sys/class/rtc/rtc0/wakealarm echo mem /sys/power/state I went tried to this on exynos5800-peach-pi and found first that exynos_defonfig is missing the MAX77802 kconfig options for the RTC source clock: CONFIG_REGULATOR_MAX77802=y CONFIG_COMMON_CLK_MAX77802=y I am using exynos_defconfig (no changes) with the internal SoC RTC which is enabled by default. I did not enable the MAX77802 RTC. With those, rtc0 then comes up, but isn't waking from suspend. However, writing something to rtc0/wakealarm does result in /proc/interrupts having an interrupt for the RTC, it's just not waking the system. Anyone else tried this on 5800/peach-pi? I have tested this on a Peach-Pi and the system is resuming fine. The patches applied on kgene's for-next branch along with the aclk200_disp1 fix are: http://lkml.org/lkml/2014/9/30/156 https://lkml.org/lkml/2014/10/6/89 http://www.spinics.net/lists/arm-kernel/msg368207.html http://www.spinics.net/lists/linux-samsung-soc/msg37647.html Abhilash -- 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: fix vblank handling during dpms off
On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
Hi,
+CC possible victims
On 10/02/2014 12:52 PM, Inki Dae wrote:
On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
Hi Andrzej,
On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagefilp has
not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
It fixes issue with page_flip ioctl not being able to acquire vblank counter.
This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).
We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .
This patch should break also other drivers, it seems at least following
drms could be affected:
armada, sti, tegra.
Indeed we (tegra) have just been hit by this. The problem seems to come
from the fact that we have been using drm_vblank_pre_modeset,
drm_vblank_post_modeset and drm_vblank_off conjointly. All these
functions depend on the value of vblank-inmodeset, and 7ffd7a68511
increases the vblank reference counter only in drm_vblank_off, which can
result in the acquired reference never being released.
The following seems to fix this for Tegra, by stopping using
drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b08df07cad47..3955d81236d0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {
static void tegra_crtc_disable(struct drm_crtc *crtc)
{
- struct tegra_dc *dc = to_tegra_dc(crtc);
struct drm_device *drm = crtc-dev;
struct drm_plane *plane;
@@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
}
}
- drm_vblank_off(drm, dc-pipe);
+ drm_crtc_vblank_off(crtc);
}
static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
u32 value;
int err;
- drm_vblank_pre_modeset(crtc-dev, dc-pipe);
+ drm_crtc_vblank_off(crtc);
err = tegra_crtc_setup_clk(crtc, mode);
if (err) {
@@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
- drm_vblank_post_modeset(crtc-dev, dc-pipe);
+ drm_crtc_vblank_on(crtc);
}
static void tegra_crtc_load_lut(struct drm_crtc *crtc)
Thierry, does this look ok to you?
But there might be another issue, which is that calls to
drm_vblank_get() will return -EINVAL if invoked between drm_blank_off
and drm_blank_on. Is this really the desired behavior? Can it at least
happen? If so, how are drivers supposed to react to this situation?
--
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
